5 Lessons from the LinkedIn Breach

The recent LinkedIn security breach wherein approximately 6.5M user account names and passwords were stolen and published online is not something new. Such incidents are quite common place. Though the exact cause of breach is not known we can definitely point out some obvious flaws like lack of sophisticated security control. In this entry I would like to provide what I believe are key learning from the LinkedIn incident. I am sure most would agree with my viewpoints and I welcome comments from those who do or don’t.

 

Learning #1: Have a robust encryption scheme

In the aftermath of the LinkedIn attack, it is observed that site used a very weak encryption system for the passwords which allowed the attackers to obtain the password hashes and decode them easily. LinkedIn should have used “salting” for better security. It is very important to design a robust security architecture and a strong encryption scheme. The best is to use tried and tested methods than creating your own innovations in this area.

(Read more:  5 Best Practices to secure your Big Data Implementation)

 

Learning #2: Get a Security Incident Management Solution and use it!

LinkedIn was largely unaware of any security events leading up to the final breach. The fact that LinkedIn’s security event monitoring regime failed to detect the initial signs of the breach and the actual breach itself, leads us to believe that the security event monitoring and incident response framework has some serious shortcomings that must be identified, acknowledged internally, and ultimately fixed. It is not interesting to know that you are hacked through the media.

Learning #3: Respond to vulnerability disclosures seriously and hire a security team!

LinkedIn is making good money and getting a good security team is not a bad decision. I am not sure if LinkedIn has got the optimum team to respond to security vulnerabilities disclosed to them. From iViZ we sent them several notifications on vulnerabilities in their site but we got no response. Our experience with other companies like Microsoft had been just the opposite. As a part of responsible vulnerability disclosure we report vulnerabilities first to vendors and help them to fix it. LinkedIn needs to be more responsive.

(Read more:   How Should a CISO choose the right Anti-Malware Technology?)

 

Learning #4: Have an Emergency Response Team

Post the discovery of the security breach, the formal remarks and comments originating from senior staff at LinkedIn were unclear and ambiguous and did little in terms of alleviating the concerns of its users For example, LinkedIn was not able to state exactly how many user account passwords were decoded and published online, but categorized the quantum of the breach simply as being “small” (hardly useful in estimating the actual quantum of damage to its users!). Furthermore LinkedIn labeled some of its users as those “at greatest risk” and those “potentially affected”. It is critical to have an Emergency Response Process and a Team for organizations which need serious security.

 

Learning #5: Conduct Penetration Test on your Application during every release! 

LinkedIn is a huge application and they must be having very frequent releases. It is critical to test the application during every release. At iViZ most of our customers conduct Penetration Testing during every release which means more than 12 tests in a year. We have seen that those who test their application during all the release are at least 10 times more secure than who do it once in a year.

 

PS: I am sure there are several other critical learning. But thought that 5 is probably a good number to stick to than trying to figure out all. Your thoughts are welcome!

 

http://www.ivizsecurity.com/blog/penetration-testing/398/

More:  Want to become a speaker and address the security community?  Click here    

Views: 342

Join the Discussion ...

You need to be a member of CISO Platform to join the discussion!

Join CISO Platform

© 2019   Created by CISO Platform.   Powered by

Badges  |  Report an Issue  |  Privacy Policy  |  Terms of Service