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.

                                  Friday, March 15, 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:


                                  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.


                                  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.


                                  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.

                                  Thursday, July 24, 2008

                                  Exprimental economics helps solve complex business problems

                                  How do you predict demand from your distributors? Would you try demand simulation, predictive analytics, or a complex mathematical model? Try experimental economics. Wired points us to a story (found via Techdirt) of Kay-Yut Chen who is an experimental economist at HP solving the complex demand forecast problems.

                                  One of Chen's recent projects involved finding a way for H.P. to more accurately predict demand from its nine distributors, who collectively sell as much as $3 billion worth of H.P.'s products. The problem? Its distributors' forecasts for demand were frequently off by as much as 100 percent, wreaking havoc on H.P.'s production planning.

                                  Chen's solution to the planning problem, which H.P. intends to test soon with one distributor, was to develop an incentive system that rewarded distributors for sticking to their forecasts by turning those forecasts into purchase commitments. In the lab, the overlap between distributors' forecasts and their actual orders using this system increased to as high as 80 percent. "That's pretty astonishing given that the underlying demand is completely random," Chen says.

                                  The human beings are terrible at making rational decisions and the complex problems such as demand forecast cannot really be solved by complex modeling algorithms or predictive analytics. Applying the economics of incentives to such problems is likely to yield better results. Freakonomics explains the creative use of economics of incentives in great depth. Dan Ariely writes in Predictably Irrational about people predictably making irrational decisions and how it breaks the rules of traditional economics and free markets that are purely based on demand and supply ignoring the human irrationality.

                                  There is a lesson for an enterprise software vendor to design human-centric software that supports human beings in complex decision management process. Good news is that I do see the enterprise software converging towards social computing. Topics such as security that have been considered highly technical are being examined with a human behavior lens ranging from cognitive psychology to anthropology of religion.

                                  I would welcome a range of tools that could help experimental economics gain popularity and dominance in the mainstream business. For instance behavior-based AB testing can be set up in a lab to test out hypothesis based on experimental economics and the results of the experiment could be directly fed to a tool that reconfigures an application or a website in real-time.

                                  Monday, February 11, 2008

                                  Data encryption as a new class of DoS

                                  Not to sure what to make out of this argument. Experts from IBM Internet Security Systems, Juniper, nCipher argue that data encryption is a new class of DoS. The post says "It's a new class of DoS attack.. If you can go in and revoke a key and then demand a ransom, it's a fantastic way of attacking a business." This does not make any sense. If someone can get your private key revoked you would have a lot to worry about other than data encryption.

                                  It also says "Another risk is that over-zealous use of encryption will damage an organization's ability to legitimately share and use critical business data". The storage is encrypted but the access is not, so I am not sure what sharing issues the post is talking about. The leading database vendors such as Oracle provides column level encryption where data is encrypted before it is stored but it is decrypted on-the-fly when accessed and it is very transparent to the user or to the application. Though a limited set of real-time data should be encrypted since there is an overhead of decryption every time the data is accessed and the physical and digital security of the real-time data store is much better than an off-line storage such as backup tapes . On the other hand the backups should always completely be encrypted because they are not supposed to be accessed in real time and there is a greater risk of loosing a tape from a UPS truck or get stolen by baggage handlers. In fact Oracle once considered not to allow taking unencrypted backups at all.

                                  What really matters is the encryption strategy of the organization for the data accessed in real time and the data that gets backed up on a tape. Some simple key management solutions and the right decisions and governance can solve the supposed DoS problems that are being discussed. You could take any tool and use it a wrong way and then complain about the tool itself. Encryption is just a tool and an enabler and you have to figure out how to use it. If you closely look at the "experts" in the post they are into the key management business and want you to believe that your keys will be revoked one day and you might end up paying ransom and also risk your data so why not pay us now and buy our software.

                                  Saturday, August 11, 2007

                                  SOA Security – A crystal ball?

                                  Well, I hope not. The enterprise architecture should always consider the security aspects of various systems – authentication, authorization, audit trail, and non-repudiation. These fundamentals do not change when extended to SOA. Any SOA implementation should address these concerns. As this article suggests, there are multiple competing standards when it comes to SOA security and I personally believe that it is a good thing (at least in the beginning). Competition keeps vendors on their toes to follow a standard that works well and satisfies customers' needs. Loose consensus over rigid agreement works well for standards. CORBA is a good example of that. It took a lot of people many years to come up with this bloated standard and eventually what people got as a standard was a superset of all the possible features that addressed all the OMG members' needs and satisfied their egos. The end result was a comprehensive but useless standard.

                                  In the SOA security world, there are competing standards, but they do not compete at the same level. If you are using WS-Federation, you can still use SAML tokens and if you are using SAML you can still use Liberty Alliance standards. All these standards will evolve and eventually the one that works well, and easy to use will win. I understand that organizations have concerns over investing too much into single identity management standard, but that does not justify organizations not investing into any security standards at all.

                                  The companies are hard-pressed to open up their services to their partners to stay relevant in this competitive market. Don't listen to your IT department if they use the security card to scare you on your SOA efforts, instead work with them and prototype few simple ad-hoc federation solutions before venturing full-throttle into hub-and-spoke or complete identity federation solutions. This is similar to a kid learning how to bike. Use the training wheels, get rid of your fear, and once you understand how security works, get rid of the training wheels and go for a full-fledged solution. SOA security should not be a crystal ball; do your homework, follow your SOA governance and decision making framework, and most importantly have faith in your decisions – you will be fine.