Acceptance is the first step

There’s a line. It’s an imaginary line, but it’s there and I’ve seen it manifest itself. It usually appears when an organization’s security division has to deliver a third party security assessment to their executive management. On one side of the line is the sincere quest for security improvement, on the other, internal politics and finger pointing. I have seen good people step right over that line in a well-intentioned act of self-preservation. When this happens, it can bring into question the role of the third party assessor.

As a third party security assessor, it’s my organization’s role to identify our clients’ risks and to rate the severity of those risks. We do this in a number of ways: through interview based assessments, vulnerability scans, internal or external penetration tests, and compliance gap analyses just to name a few. The problem is that once we identify a risk and attach a rating to it, it’s still the responsibility of our client to determine the level of acceptability within their organization. It’s that last piece of the puzzle that sometimes gets lost.
For example, we recently conducted an external attack and penetration assessment for a client that resulted in a complete compromise of a backend database using a simple SQL injection attack. Following the compromise, we were able to dump the entire database and retrieve administrative usernames and passwords which led to email account access which provided us with the opportunity to steal sensitive data.
In addition to the above, we quickly identified the following vulnerabilities on our client’s externally exposed IP addresses as well:

• Hash Dumping\Obtaining Credentials
• Persits AspUpload Default Scripts Exploitable Vulnerability
• JBoss JMX Console Unrestricted Access
• Cross Site Scripting
• Plaintext Protocols in Use
• Apache 1.3 HTTP Server Expect Header Cross-Site Scripting
• Apache HTTP Server 413 Error HTTP Request Method Cross-Site Scripting Weakness
• Default Error Handling
• HTTP TRACE Method Enabled
• SSLv2 Enabled Vulnerability
• SSL Server Supports Weak Encryption Vulnerability
• Directory Listing
• Netscape/OpenSSL Cipher Forcing Bug
• File Metadata Information Leakage
• CONNECT Method Allowed in HTTP Server Or HTTP Proxy Server Vulnerability
• WebDAV HTTP Method 'PROPFIND' Enabled
• Microsoft IIS Internal IP Address/Internal Network Name Disclosure Vulnerability
• Test and Debug Pages in Production Area


As a result of these findings, we provided our client with a Risk Rating of Level 4 or “Extreme Risk” in regard to their external web presence. To SecureState, it was quite clear that the ease with which the application was compromised, as well as the nature of the data that was accessible, constituted an “extreme risk.”
However, our client had a different opinion.
As I said in the beginning of this article, there is a line. Seeing the words “Extreme Risk” sent our client into a defensive mode; and suddenly their desire for improving their overall security program was eclipsed by their desire to soften the message of a horribly unsecured web application to their Senior Management. This resulted in a plea from our client for us to downgrade our “Extreme” rating to “High.” Their reasoning for this was that the web application itself did not contain personal, classified company or financial data. Therefore, how “extreme” could the risk really be?
This is where we, the third party assessor, have to take a step back. To quote ISO 27005:

“Risk acceptance criteria should be developed and specified. Risk acceptance criteria often depend on the organization's policies, goals, objectives and the interests of stakeholders… Risk acceptance criteria may include multiple thresholds, with a desired target level of risk, but provision for senior managers to accept risks above this level under defined circumstances”

In other words, we can’t tell our clients how to measure risk acceptability within their organization. That’s their job. The argument that the risk is acceptable and therefore not extreme should not be made to us, the assessor, but rather to the senior managers within the organization who have to live with the risk. If they choose to accept that level of risk, that’s great. If not, we can help to establish mitigation plans and move forward. In either scenario, it’s the interest of the stakeholders, not the assessors, that establishes the acceptance criteria.
That way, everyone stays on the right side of the line.

By Chaz Braman