BREAKING NEWS
latest

728x90

468x60

Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Thursday, June 13, 2013

Hacking Into The Indian Education System Reveals Score Tampering


Debarghya Das has a fascinating story on how he managed to bypass a silly web security layer to get access to the results of 150,000 ISCE (10th grade) and 65,000 ISC (12th grade) students in India. While lack of security and total ignorance to safeguard sensitive information is an interesting topic what is more fascinating about this episode is the analysis of the results that unearthed score tampering. The school boards changed the scores of the students to give them "grace" points to bump them up to the passing level. The boards also seem to have tampered some other scores but the motive for that tampering remains unclear (at least to me).

I would encourage you to read the entire analysis and the comments, but a tl;dr version is:

32, 33 and 34 were visibly absent. This chain of 3 consecutive numbers is the longest chain of absent numbers. Coincidentally, 35 happens to be the pass mark.
Here's a complete list of unattained marks -
36, 37, 39, 41, 43, 45, 47, 49, 51, 53, 55, 56, 57, 59, 61, 63, 65, 67, 68, 70, 71, 73, 75, 77, 79, 81, 82, 84, 85, 87, 89, 91, 93. Yes, that's 33 numbers!


The comments are even more fascinating where people are pointing out flaws with his approach and challenging the CLT (central limit theorem) with a rebuttal. If there has been no tampering with the score it would defy the CLT with a probability that is so high that I can't even compute. In other words, the chances are almost zero, if not zero, of this guy being wrong about his inferences and conclusions.

He is using fairly simple statistical techniques and MapReduce style computing to analyze a fairly decent size data set to infer and prove a specific hypothesis (most people including me believed that grace points existed but we had no evidence to prove it). He even created a public GitHub repository of his work which he later made it private.

I am not a lawyer and I don't know what he did is legal or not but I do admire his courage to not post this anonymously as many people in the comments have suggested. Hope he doesn't get into any trouble.

Spending a little more time trying to comprehend this situation I have two thoughts:

The first shocking but unfortunately not surprising observation is: how careless the school boards are in their approach in making such sensitive information available on their website without basic security. It is not like it is hard to find web developers in India who understand basic or even advanced security; it's simply laziness and carelessness on the school board side not to just bother with this. I am hoping that all government as well as non-government institutes will learn from this breach and tighten up their access and data security.

The second revelation was - it's not a terribly bad idea to publicly distribute the very same as well as similar datasets after removing PII (personally identifiable information) from it to let people legitimately go crazy at it. If this dataset is publicly available people will analyze it, find patterns, and challenge the fundamental education practices. Open source has been a living proof of making software more secured by opening it up to public to hack it and find flaws in it so that they can be fixed. Knowing the Indian bureaucracy I don't see them going in this direction. Turns out I have seen this movie before. I have been an advocate of making electronic voting machines available to researchers to examine the validity of a fair election process. Instead of allowing the security researchers to have access to an electronic voting machine Indian officials accused a researcher of stealing a voting machine and arrested him. However, if India is serious about competing globally in education this might very well be the first step to bring in transparency.

Sunday, April 21, 2013

Use Guided Access for iOS to Safely Lend Your Phone to Friends



Has someone ever asked to borrow your iPhone to call home, but then went through your personal information? Hopefully not, but it has happened to many kind-hearted phone lenders. Luckily using the built in Guided Access feature you can hand over your phone with less worry. Guided Access is designed as an accessibility feature but can be used by everyone. To learn more about Guided Access click here. Even with this feature use caution and common sense when lending your phone to people.


To get started, go to "settings" then "general" and then "accessibility". Guided Access is only avalible in iOS 6. In the accessibility menu go to Guided Access and turn it on. Then you will have to set a passcode. Make sure you remember your passcode. Now when you want to lend your phone to someone go to the app you want them to use and triple click the home button to start Guided Access. After turning on Guided Access no one will be able to access any other app without knowing your passcode. When you get your phone back just triple click the home button again and type in your passcode to unlock your phone. Watch the video above to learn more.

Saturday, March 16, 2013

We Got Hacked, Now What?



Hopefully you really have a good answer for this. Getting hacked is no longer a distant probability; it's a harsh reality. The most recent incident was Evernote losing customer information including email addresses and passwords to a hacker. I'm an Evernote customer and I watched the drama unfold from the perspective of an end user.  I have no visibility into what level of security response planning Evernote had in place but this is what I would encourage all the critical services to have:

Prevent

You are as secured as your weakest link; do anything and everything that you can to prevent such incidents. This includes hardening your systems, educating employees on social engineering, and enforce security policies. Broadly speaking there are two kinds of incidents - hijacking of a specific account(s) and getting unauthorizd access to a large set of data. Both of these could be devastating and they both need to prevented differently. In the case of Evernote they did turn on two-factor authentication but it doesn't solve the problem of data being stolen from their systems. Google has done an outstanding job hardening their security to prevent account hijacking. Explore shared-secret options where partial data loss doesn't lead to compromised accounts.

Mitigate

If you do get hacked, is your system instrumented to respond to such an incident? It includes locking acconts down, taking critical systems offline, assess the extent of damage etc. In the case of Evernote I found out about the breach from Twitter long before Evernote sent me an email asking to change the password. This approach has a major flaw: if someone already had my password (hard to decrypt a salted and hashed value but still) they could have logged in and changed the password and would have had full access to my account. And, this move—logging in and changing the password—wouldn't have raised any alarms on the Evernote side since that's exactly what they would expect users to do. A pretty weak approach. A slightly better way would have been to ask users to reset the password and then follow up with an email verification process before users could access the account.

Manage

If the accounts did get hacked and the hackers did get control over certain accounts and got access to certain sensitive information what would you do? Turns out the companies don't have a good answer or any answer for this. They just wish such things won't happen to them. But, that's no longer true. There have been horror stories on people losing access to their Google accounts. Such accounts are further used for malicious activities such as sending out emails to all contacts asking to wire you money due to you being robbed in . Do you have a multi-disciplinary SWAT team—tech, support, and communication—identified when you end up in such a situation? And, lastly, have you tested your security response? Impact of many catastrophes, natural or otherwise, such as flood earthquakes, and terrorist attacks can be reduced if people were prepared to anticipate and respond. Getting hacked is no different.

Photo courtesy: Daniele Margaroli

Wednesday, June 15, 2011

5 Techniques To Deal With Spam: Open Letter To Twitter


I love Twitter, but lately, I am getting annoyed by Twitter spam and I'm not the only one. I don't want Twitter spam to become email spam. I don't want to whine about that either, so I spent some time thinking about what Twitter could do to deal with spam. Consider this an open letter to Twitter.

Facebook's privacy settings are the new programming a VCR. Google has been criticized a lot about profiting from content farms. I believe that all the major players are playing a catch-up game. A lot of people have stared to complain about LinkedIn spam as well. Quora went into different direction — where they started out with a strict upfront policy regarding who can join Quora, ask questions, answer questions etc. — to maintain the quality of their service. Strict upfront policy hampers new user acquisition and adoption but could ensure better quality where as liberal policy accelerates the user acquisition with a risk of service being abused. I do believe that there's a middle ground that these services could thrive for by implementing clever policies.

Here are five techniques that Twitter could use to deal with spam:

1. Rely on weighted rank based on past performance: I ran a highly unscientific experiment. I kept a record of all the accounts that I reported as spammers on Twitter in the last few days. I went back every few minutes, after reporting an account, to see whether that account was suspended. It took Twitter some time before that happened. Every single account that I have reported so far has been suspended. I don't think Twitter is using that knowledge. If it did, my subsequent actions would have resulted into quicker suspension. Learn from Craigslist. Craig Newmark will tell you all about community-based flagging. Instrument the system to rely on reputation of power users — who are savvy enough to detect spam — to suspend a spammer's account. If it turns out that it's not a spam, give an opportunity to the account owner to appeal. Spammers don't waste time arguing; they simply move on.

2. Expand categories to match how people consume: Create a separate "unsolicited" category to receive mentions and replies from people whom you don't follow. This could be a separate window in a Twitter client that replaces the current "replies and mentions" window. Require Captcha for direct replies (and not mentions) for the conversations where both the accounts don't follow each other to stop automated spam. Everything else, including real spam, goes into "mentions", which is now a new category, that can be consumed in a separate window leaving the "replies" window clean.

3. Remove spam tweets from the stream: Many users don't consume their mentions or replies in real-time or even in near real-time. Mark the tweets spam once you suspend the account and require the Twitter clients to remove them from users' stream in real time. No API restrictions and no throttling. If you do it right and spam gets detected within a few seconds, the account can be suspended in no time, and the tweets are removed even before the most users would even see them. Emails can't be recalled, the tweets can be, if Twitter wants it to. Let's do it.

4. Focus on new accounts: Set a reasonably low limit on number of tweets per hour on a new account. A first-time genuine Twitter user doesn't go from 0-100 in a day, but a new spammer certainly would. Focus energy on new accounts; spammers don't wait for a few weeks or months to start spamming. The current "verified" account feature is a black magic. Open it up to all the people and use standard means such as cell phone, credit cards, and other identities to verify their Twitter accounts. These accounts enjoy the benefit of doubt - an upfront requirement of multiple signals before their accounts are suspended. Spammers don't want to verify themselves.


5. Find and fight bots with bots: There are a bunch of bots out there that look for the words such as iPad, iPhone, and XBOX in your tweets and then they spam you. Twitter can crate their own bots to tweet these words to catch these spam bots and more importantly harvest the links that they are tweeting to detect other spammers. Twitter's own bots would obviously be far more intelligent than the spam bots since they would have access to a lot more information that the spam bots don't.

The spammers do catch up, but if Twitter spends a little time and energy, they can stay ahead in this game. They can even lead the pact of social media companies on how to deal with spam.

Update: As soon as I published this post, I tweeted it and copied Del Harvey on it. She immediately responded to the post. You can read her response here. I really appreciate Twitter responding to this. My take on the response is that they seem to understand what the issues are and how they might solve them, but they haven't fully managed to execute on it, so far. I don't agree with their feedback on issue #2 calling it non-safety. Users see Twitter as one integral product where spam is very much part of it. Personally, I don't think of spam as a security issue for me. It's just plain annoyance. Executing on these ideas will matter the most. Let's hope Twitter gets behind this with full momentum and it doesn't become a "project".

Friday, July 17, 2009

Debunking The Cloud Security Issues

Forrester recently published a report on the security of cloud computing that grossly exaggerates the security threats. To point out few specific instances:

"Users who have compliance requirements need to understand whether, and how, utilizing the cloud services might impact your compliance goals. Data privacy and business continuity are two big items for compliance. A number of privacy laws and government regulations have specific stipulation on data handling and BC planning. For instance, EU and Japan privacy laws demand that private data—email is a form of private data recognized by the EU—must be stored and handled in a data center located in EU (or Japan) territories"

This is a data center design 101. One of the biggest misconceptions the organizations have about the cloud computing is that they don't have control over where their information is being stored. During my discussion with the Ron Markezich, corporate vice president of Microsoft Online, at the launch of Microsoft's Exchange on the cloud he told me that Microsoft already supports the regional regulatory requirements to store data in regional data centers. Cloud is fundamentally a logically centralized and physically decentralized medium that not only offers utility and elasticity but also allows the customers to specify policies around physical locations.

"Government regulations that explicitly demand BC planning include the Health Insurance Portability and Accountability Act (HIPAA) ...."

Amazon EC2 fully supports HIPAA [pdf] with few customers already using it. It is rather strange that people think of cloud as a closed and proprietary system against an on-premise system. A CIO that I met few weeks back told me that "on-premise systems are like an on-premise vault that you don't have a key to". The cloud vendors are under immense pressure to use open source and open standards for their infrastructure and publicize their data retrieval and privacy policies. In fact many people suggest that the United States should force the public companies to put their financial information on the cloud so that SEC can access it without any fears of the companies sabotaging their own internal systems. The cloud vendors have an opportunity to implement a common compliance practice across the customer. The customers shouldn't have to worry about their individual compliance needs.


"The security and legal landscape for cloud computing is rife with mishaps and uncertainties."

And the rest of the landscape is not? What about T.J. Maxx loosing 45.7 million credit and debit cards of shoppers, Ameritrade loosing backup tapes that had information of 200,000 of its customers, and UPS loosing Nelnet's backup tape that had personal information of approximately 188,000 customers?

"With the rising popularity of cloud computing and the emergence of cloud aggregators and integrators, the role of an internal IT security officer will inevitably change—we see that an IT security personnel will gradually move away from its operations-centric role and step instead into a more compliance and requirements-focused function."

Staying in current operational role still requires the IT to be compliant. Just because the information is stored on-premise it does not automatically make the system compliant. I would expect the the role of operational IT to change from a tactical cost center to a strategic service provider. If the IT does not embrace this trend they might just become a service consolidation organization. The role of a security officer will evolve beyond the on-premise systems to better understand the impact of the cloud and in many cases help influence the open cloud standards to manage and mitigate the security risks.

"In other cases, the division is not quite so clear. In software mashups, or software components-as-a-service, it can be difficult to delineate who owns what and what rights the customer has over the provider. It is therefore imperative that liability and IP issues are settled before the service commences."

I partially agree. The customers should absolutely pay attention to what they are signing up for and who will own what. The critical aspect of the IP is not the ownership but the IP indemnification. After the SCO case customers should know what are their rights as a customer if someone sues a cloud provider for IP infringement.

"Other contractual issues include end-of-service support—when the provider-customer relationship ends, customer data and applications should be packaged and delivered to the customer, and any remaining copies of customer data should be erased from the provider's infrastructure."

This is what happens when we apply the same old on-premise contracts to the new SaaS world. There are no copies of the software to be returned. Customer simply stop receiving the "service" when the relationship ends. Vendors such as Iron Mountain advocates the role of a SaaS escrow for business continuity reasons. It is up to the customers to decide what level of escrow support they need and what's their data strategy once the relationship with a SaaS vendor ends. It is certainly important to understand the implications of SaaS early on but there is absolutely no reason to shy away from the cloud.