While reading through the blog post that discusses how Sony’s Playstation network was breached, was I the only one that noticed that playstation network usernames AND passwords were stolen. Perhaps they left out the specifics but, why were the passwords stored using encryption thereby increasing the amount of time and effort required to decrypt the passwords?
Nevertheless, this breach is rather interesting in that the blog post states “While there is no evidence at this time that credit card data was taken, we cannot rule out the possibility.” One point of doing proper log management and risk assessments is to be able to see how far the rabbit hole goes when a breach occurs. The ability to know that only a portion of records were affected during a breach can save thousands of even hundreds of thousands of dollars.
Image via Wikipedia
When companies come to me because they want to draft a security policy, the first question I ask them should be the most obvious: “Why?”
It may seem like a simple question, but more often than not it is met with confusion as if the answer was so obvious that it cannot be articulated. At other times, the answer is that they are simply compelled to have a security policy by law and regulations. But bandwagon mentality or compliance reasons will not generate a successful security policy. Starting with the “why” is the most important step when crafting a security policy, and the answer to “why?” comes from a risk assessment.
Risk assessment is an endeavor to find out why you need this policy and what it hopes to achieve. Risk assessment determines the magnitude of potential loss and the probability that the loss will occur. For security, this means classifying information into separate levels of sensitivity, then, discovering the possible risks, and the probability of those risks, that this information may be compromised.
It is not possible or sensible to protect all information, regardless of sensitivity, with the same maximum level of protection. And there is no cookie-cutter, one-size-fits-all approach to creating a security policy since every business has unique risks and places different values on different kinds of information. This is why an individual risk assessment must be performed. Once this has been determined, a security policy can be crafted based on protecting information based on its value and risk unique to that organization.
The problem is that too much policy work is driven by compliance rather than need. Without first identifying the need (the “why”) a security policy is destined to miss its mark and be nothing more than a symbol of intent rather than a useful procedure.
By relying simply on compliance to dominate a security policy, you may live up to laws and regulations but remain vulnerable. Compliance alone has not saved many companies from data breaches, including the credit card processor Heartland Payment Systems, who suffered an unauthorized disclosure of 100 million credit and debit card transactions while remaining compliant.
We presented a webinar(it will be online shortly) a couple weeks ago on Secure Software Development Life cycle practices and we talked about OWASP, The Open Web Application Security Project. An attendee asked where they could find the OWASP Top Ten and I thought it would be useful to let everyone know about the OWASP Top Ten.
OWASP has released a draft of their top 10 web application security risks for 2010.(NOTE: large PDF)
This draft will consider public comment and release a final version finished up by the end of the first quarter of 2010.
As you know, web applications are usually the most vulnerable components of a website so OWASP is doing a great service by including these attacks, the risks, and the prevention methods. Two new security risks have replaced last Malicious File Execution and Information Leakage and Improper Error Handling from the previous 2007 list. These new security risks are Security Misconfiguration and Unvalidated Redirects and Forwards. The inclusion of Security Misconfiguration demonstrates how OWAS is now focusing on a risk view instead of just the software development.
But what enterprises will most appreciate about this new list is that it seems to be accessible by not just security professionals but by the company decision-makers. Rather than just discuss the security exploits, the document goes on to explain the technical impacts and business ramifications. OWASP takes on a risk assessment approach with this list, which is a mature viewpoint in terms of providing security.
The 2007 list relied on the frequency associated with each weakness to determine, but now the list ranks each item based on risk. In this way, the list is about the top risks rather than simply the most common weaknesses.
Risks are broken down into attack vector exploitability, security prevalence and detectability, and technical and business impacts. Each part of the risk is ranked in red, orange, or yellow to show the threat.
Attack vectors shown in red are those which are easily exploited by an attacker. For example, Injection attacks are easily exploitable because they only require a simple text-based attack. The prevalence risk shows how often these vulnerabilities occur and the detectability risk shows how easy the vulnerabilities are to detect. Finally, the technical and business impacts discuss how much damage an attacker could cause from the weakness.
This risk assessment approach to security is a very wise step for OWASP and something we have been doing for clients since 2004. It is neither possible nor economically feasible to guarantee 100% security, so security issues must instead be budgeted based on risk. The list allows companies to consider which risks to worry about by considering their frequency, prevention costs, and impact.
