OWASP Top 10 #6: Sensitive Data Exposure
Since 2003, The Open Web Application Security Project (OWASP) has provided the information security community with the “Ten Most Critical Web Application Security Risks.” With the recent release of the 2017 update, not surprisingly, sensitive data exposure remains a major concern affecting almost every company around the globe that uses web applications.
To put it in simple terms, sensitive data such as credit cards and cardholder Information, access credentials, health records, personal Information, finance data, or any other data your business may deem relevant can be inadvertly exposed by web applications if the necessary security controls are not properly implemented.
It is quite simple to understand why protecting sensitive data from exposure should be a concern for most businesses: Since most, if not all, companies use web applications for their operations, data is constantly exposed to both internal and external threats. If you have not done so, you should give some thought to understanding who could gain unauthorized access to your sensitive data in any form (e.g., at rest, in transit, or backups) and consider how your business could be affected based on the lost/leaked data value and the subsequent impact on reputation. If your company falls under specific legislation (e.g., the Sarbanes-Oxley 404, EU’s General Data Protection Regulation, or even a contract requirement from a client) the results of sensitive data exposure can be quite lasting and have a profound effect over the financial results.
The best approach to avoiding such an undesirable scenario is making sure that proper security controls are in place, but how can you be sure of that? For instance, most web application nowadays will, hopefully, implement some sort of cryptography for authentication or data in transit. That may sound very nice (if you are not doing it, your data is transmitted in clear-text and can be easily captured), but this control may give a false sense of protection. Most of the time, cybercriminals will not waste time trying to break crypto-protection directly, instead they look for easier targets such as poorly managed keys, applications vulnerable to man-in-the-middle attacks, SQL injection flaws, session hijacking. The list of possible attack scenarios is quite comprehensive, and you should also keep in mind that, while the cybersecurity team must win every time, from an attacker point of view, a single exploit success could lead to a major data exposure.
So, back to the real question: How do we make sure company data on web applications has adequate protection? If you think that this issue can be solved using technology alone, I am very sorry to be the bearer of bad news, but that will not suffice. Please understand that I am not saying that implementing security solutions is not relevant—it actually is one of the major factors for data protection. But if you put all your efforts into the tech aspect alone, even if using the best available solutions, it may lead to a failure of epic proportions.
There is no shortage of recent cases of extreme data exposure. For instance, in 2016, UK’s Tesco Bank lost an estimated £2.5m from approximately 9,000 customer accounts. This incident was considered the biggest cyber-heist of its kind to affect a UK bank. According to publicly available information, apparently Tesco Bank’s security procedures were not the real issue, but the fact that the bank is owned by Tesco led to allowing the use of not-so-secure systems from the parent company. Similar to many other major security incidents, the real cause was not disclosed, but a representative from the bank said they knew “exactly” what the attack was, but could not say more because it was part of an ongoing criminal investigation. On official records, Tesco Bank’s chief executive has blamed “a systematic, sophisticated attack” for the data leak, but one of the main theories based on a study by team at Newcastle University claimed something much simpler: guesswork. In what they called a “distributed guessing attack,” discovering sensitive information such as the card number, expiry date, and security code of any Visa credit or debit card could take a criminal “as little as six seconds” and involved nothing more than using deduction as a form to exploit the bank’s web application.
It is important to understand that, depending on what your organization does and the kind of information you have on your systems, you may become a prime target for cybercriminals or hacktivist groups, such as in the case of the Philippines’ Commission on Elections (COMELEC), yet another example from the never-ending cases of unwanted data exposure due to security lacking web applications in 2016. COMELEC’s website was defaced on March 2016 by a hacker group and, as unreasonable as it may sound, they were attacked by another non-related hacker team. The second attack was way more damaging than a simple defacement, due to a SQL injection flaw, as disclosed on a YouTube video posted by Anonymous Philippines, COMELEC’s entire database was made available online and it exposed information from 55 million registered voters. This leakage is considered to be amongst the biggest government-related breaches in recent history.
It is reasonable to assume that, given the size and type of organizations involved in the aforementioned examples, some sort of security measures were in place. So why did they fail? Again, technology is but a single factor for data protection and the whole picture should include well-designed processes and a special focus on the people involved with security measures, especially the ones creating your systems. Why is that? Well, even the most technically advanced security solution can only provide a limited level of protection. For real, efficient, top-level protection for web applications, security should be considered early on, even before actual development starts.
It is not all that unusual to have a developer, with reasonable coding experience, unaware of what vulnerabilities may be introduced without a secure development standard. A great approach is ensuring that your development team fully understands the security risks involved.
Educating developers, designers, architects, and even organizations can be of great benefit. Your team should have a profound understanding of the role of security in the software development lifecycle, the causes and possible outcomes of coding errors and mistakes, what may be exploited by cybercriminals, and especially how to discover and fix these issues. This is a sound approach to providing real security for applications.
Working on evolving your team to understand and adhere to secure development best practices may sound like a daunting challenge but, in truth, it is way simpler than you may think. The Infosec Institute has several options for growing skills at a fast pace. For instance, Security IQ is the perfect online learning platform, providing dedicated modules to each to each of the OWASP Top 10 Web Application Security Risks. Still unsure? Why not try it? Enrolling can be done in a matter of minutes, and the “Personal” membership option allows up to ten learners to check for the basic functions of Security IQ.
Another great option is our OWASP Top 10 Boot Camp, a unique experience that focuses on providing a good mix of attention-getting lectures, hands-on secure coding lab activities, and engaging group exercises. There is no doubt about it: This is the most current, up-to-date, hands-on secure coding training. We take pride in providing the opportunity to learn from the very people who do it: Our instructors are active and expert developers, with proven field experience in secure coding. Our track record says it all: We have trained more developers of secure coding courses than any other training company.
Do not miss this opportunity, whether you are a manager in charge of a large team or a developer with a knack for information security and the desire to advance in your career, the Infosec Institute can provide the best value and ensure that you are ready to secure web applications.
 Source: http://www.theregister.co.uk/2016/11/30/tesco_bank_breach_former_insider_breach_theory
 Source: https://www.theguardian.com/technology/2016/dec/02/tesco-bank-cyber-attack-involved-simply-guessing-details-study-claims
 Source: http://blog.trendmicro.com/trendlabs-security-intelligence/55m-registered-voters-risk-philippine-commission-elections-hacked/