It is undisputed that online applications are increasingly open to attack. The world of eCommerce is highly sensitive to a growing number of crimes, so it is of no surprise to find that many clients demand evidence that critical and sensitive applications are appropriately secure.
There are several means to achieving this assurance, and the more comprehensive the security testing, the more likely it is that the software developer can release the application in confidence.
To ensure the most thorough and comprehensive testing, it is a good idea to start with a Threat Profile. A threat is simply the goal of your adversary. A Threat Profile is a comprehensive list of the threats that are relevant to that application. These are expressed in terms of security threats, ie: access to unauthorised financial information, theft of login credentials, impersonation, etc.
For example - The following is a sample set of threats you may see in a Threat Profile of an Online Data Room Application:
Accesses online data rooms he is not authorised to
Modifies/deletes documents from online data rooms without rights
Escalates his level and accesses documents of a higher level
Downgrades the access level of a document and gives it wider access
Adds fake online data room users with high privileges
Resets the passwords of all users
Escalates a room administrator to group administrator
Adds more online data rooms than is entitled to
Impersonates a room administrator and posts documents
Views Click History of groups he is not authorised to
The advantage of this structured, business-driven approach is that each identified threat is systematically subjected to a variety of tests. Once a vulnerability is established, it can immediately be referred back to a specific threat, and a specific page or function of an application.
The Threat Profile is crucial to the testing procedure and, as such, should be the first task that the Test Engineer will undertake. The Threat Profile should subsequently be approved by the client before a Test Plan is created and executed.
1. Create the Threat Profile
2. Create the Test Plan
3. Perform the Tests
4. Prepare the Report, relating the findings to the threats from the Threat Profile.
The security testing report should clearly demonstrate which threats are exploitable and which are not, relating each vulnerability to a threat. For every vulnerability detected, a solution should be recommended, and the means of its implementation.
Not only is the Threat Profile crucial to the overall completeness of the testing, it is also useful to embrace a more targetted approach; the most realistic threats are tested, as opposed to a barrage of testing such as SQL injection, cross-site scripting, or session hi-jacking.
This saves time and unneccessary expense, as well as ensuring that the true business security impact of the threats are disclosed, rather than simply technical issues. This makes for more meaningful and compelling evidence for stakeholders.
What drives a company to perform a penetration test or web application security test? If you are a software company or a service provider, it is most likely that your clients and partners need to know that appropriate security controls are in place within your web applications and systems.
If you are a company or government organisation, your security tests may be driven by the need to meet regulatory compliance requirements, policy compliance or satisfy the needs of an internal or external auditor.
What both scenarios have in common is the need for security tests to go one step further and to provide evidence of the security of an environment. The security needs to be quantified, hence measured against a fixed point, or benchmark.
Large organisations may have specific internal security policies and standards in place, against which they measure their application security. Smaller organisations need external standards against which to measure.
Essential, then, to look to organisations such as OWASP - The Open Web Application Security Project. A non-profit global organisation committed to improving the security of web application software, their OWASP Top 10 represents a broad consensus of the most critical web application security flaws.
The Web Application Security Consortium (WASC) is another non-profit group comprising industry experts and practitioners who produce best practice security standards as well as facilitating an open forum for the exchange of ideas.
The Open Source Security Testing Methodology Manual (OSSTMM) provides a methodology for performing security tests. It focuses on technical details and how to measure results.
The CWE / SANS Top 25 list of The Most Dangerous Software Errors is a collaboration between the SANS Institute, MITRE and top international software security experts, which documents widespread and critical programming errors.
The Plynt Certification Criteria combines all four global industry standards, whilst also focusing on the threat profile relating to specific web applications. This enables us to demonstrate that an application defends against threats that are specific to its business context. For example, a banking application needs to protect against the threat of funds being siphoned off, while a gaming application has to protect against the threat of the rules of the game being violated.
Through security benchmarking, we can clearly see any security gaps within our web applications and any deviance between our security posture and globally accepted good practice, we can then follow recommendations to quickly and effectively fill the gap.
By benchmarking against recognised global standards, software companies and service providers can demonstrate a proactive approach to information security to clients and prospective clients. Organisations driven by compliance and audit requirements can provide clear evidence of their security posture.
OWASP - The Open Web Application Security Project
OSSTMM - The Open Source Security Testing Methodology Manual
WASC - Web Application Security Consortium
CWE / SANS Top25 list
Plynt Certification Criteria
It is not difficult to engage a company to perform a web security test or penetration test - there are many to choose from. Selecting one that is going to deliver reliably and support your endgame is altogether a different challenge.
Chances are you will be diligent in your research and find a selection of companies that are experienced and trustworthy. They will have evidence of the thoroughness and quality of their service - accreditations, awards and customer references - and perhaps security testing is their core business. They should also align with the industry standards, with an ability to work to project timeframes and might even throw a free re-test into the bargain.
Some of these qualities are fundamentally important and help establish trust - but are you actually focusing too much on the company at the expense of the endgame?
What most organisations really need from web application security testing is a complete understanding of real risks, clear guidance to help improve security and comply with industry best practice and a method of maintaining and proving this high level of security going forward, continuously.
A security test should not be simply a snapshot but a means of taking what has been learnt and improving our practices, ensuring that we raise standards and then keep them raised.
In order to achieve this, it is essential that we are aware of the real security risks facing our web applications, our underlying information and our business.
Through a process of threat profiling - or threat modeling - we are able to examine and record the relevant threats to our business applications before any testing actually takes place.
The subsequent tests are then purely focused on a well researched and agreed set of security threats, rather than purely executing a barrage of standardised technical tests.
Having identified and tested against relevant threats, we can then easily relate technical and logical vulnerabilities to security threats. By doing so, we establish the true security risks - this in turn, helps us direct and prioritise our remediation efforts.
As standard, findings should be benchmarked against global security standards in order to see where we fall short. It is important to qualify and quantify the gap between our own security and security best practice - then to raise our game and fill the gap.
Most importantly, we need to turn our attention from the results of the test to the recommendations. These must be set out clearly in an easily accessible, yet private and secure, format.
We need concise and actionable recommendations if we are going to quickly improve our web application security. To help maintain these standards going forward we require access to relevant further reading, training and a process to incorporate these secure practices into the development process.
This is essential not only for our own peace of mind, but for the reassurance of third parties and other stakeholders. We need to be able to prove that our environment is a safe place for others.