Whenever I am in the office and not working on other, billable work, an important part of my job involves the review of the final deliverables generated at the conclusion of security assessments done by my consultants.
They make use of a range of QA resources to proof the report before it goes to the client, while I tend to get involved in helping ensure that any key technical issues are explained in such a manner that all the recipients of the report understand the significance of the findings.
It is also down to me to make sure that the end recipients fully comprehend the steps which their organization must take to strengthen their security, regardless of their technical ability.
Unfortunately, this is not as simple as it sounds, especially if the report covers the details of a penetration test that exploited a few frontend, critical-risk flaws to gain access to backend data repositories. In such a case, it is easy for a consultant to fill a report with details of every vulnerability discovered, their significance, and how each one could be (or was) exploited.
But it is a different story trying to explain the underlying problems that led to those flaws being present. What's more, minor flaws and divergences from best practices can often go unnoticed by clients in the face of many red-flagged critical or high-risk vulnerabilities.
There is no real trick to explaining technical issues to non-technical audiences. The key lies in the experience of having been grilled many times over the years during wrap-up management presentations.
The driver to ensure that all security problems within a report are explained in simple terms is self-preservation.
Critical findings are easy to explain – in almost all cases, these are due to the absence of the latest patches or to bad configuration management (user "Oracle," password "oracle," for example) and are equally trivial to fix.
It is with the perhaps more minor security findings that explanation problems are encountered. Often, if these problems are correctly dealt with and fixed, the client organization will find that their defense-in-depth posture increases substantially.
Let's examine a security vulnerability, cross-site scripting, often categorized as "minor" or non-critical. This very common vulnerability has cropped up in every single web application that I have assessed in the past five years and I have seen too many people, whether they are client or consultant, fail to grasp its true significance.
The vulnerability itself stems from poor code development techniques, and occurs when the web-application fails to validate and sanitize content submitted by the application user.
In order to exploit the vulnerability, the attacker has to insert their own code in a data submission to the application, which is then returned by the server and executed within the client-side browser. Therefore, the victim of the attack will always be the user – there is no possibility of the organization's web server being compromised.
Consequently, for the organization that developed or hosts the vulnerable application, it is a low-risk vulnerability because the effect is elsewhere. However, as we are seeing already, an imaginative use of this vulnerability can result in identify theft of the customer.
How is this achieved? The attacker creates a URL that exploits the cross-site scripting flaw and inserts someadditional code which causes an alternative page to be presented within the victim's web browser.
This alternative page might have been designed to look the same as the legitimate page, but any user-submittedcredentials ( login information such as user ID and password, for example) are in fact entered into the attacker's page and recorded on their server.
If the attacker is feeling generous, they might even resubmit the captured message to the legitimate web server and automatically log the user in for real – thus capturing the user's credentials without obviously giving away the theft.
The trick to this attack lies in getting the URL to the customer and making them follow it. Welcome to the world of phishing.
This particular attack vector is now becoming increasingly popular, largely due to poor coding practices. However, having explained all this, a common response is "but we're not a bank" or "our clients can't buy anything online."
But phishing doesn't have to be about financial fraud – it can also be about identity theft. Attackers take many forms, and can abuse these so-called minor security flaws for any numberof reasons.
Even now, there are stories of phishing scams in which the attacker attempts to acquire the name, age, sex and address details of children by luring them to fake or vulnerable sites, such as "The Mickey Mouse & Superman Fanclub," or something similar. What they do with that information probably doesn't bear thinking about.
Gunter Ollmann is professional services director at Next Generation Security Software Ltd.
