Security Testing explained

By 7th May 2012 Testing

There are a number of definitions and terminology in the world of security testing. Many make the choice to cut corners and include security constraints as functional requirements and test these in the same way other functional requirements are tested. Others simply shift the entire security responsibility to an external provider. This may prove to be a cost cutter in the short run, but the actual costs of reducing your security consciousness may not be so favourable in the end.

To implement and maintain a secure software application, dedicated security testing is essential.

Software security is concerned with making software behave and operate in the presence of a malicious attack, even though realistically speaking, most software failures usually occur spontaneously and without any intentional wrongdoing.

Perhaps unsurprisingly, for a time, many were only concerned with what happens when software fails, regardless of the intent. The difference between software safety and software security is therefore the presence of an intelligent adversary with a motivation to break the system.

Security is deemed to be relative to the information and services being protected, the assumed skills and resources of malefactors as well as the costs of any potential assurance remedies. Owing to this, security can be thought of as an exercise in risk management. Risk analysis, most especially at the design stage, can help in identifying any potential security problems as well as their impact. Once these have been identified and ranked, these risks can help guide software security testing.

When we speak of a vulnerability, what is meant is that an error which can be exploited by an attacker is present. Although many types of vulnerabilities exist they are typically placed into one of two categories — bugs at the implementation level and flaws at the design level.

Some of the more common design-level problems include error handling in object-oriented systems, object sharing and trust issues, unprotected data channels of both internal and external nature, incorrect or missing access control mechanisms, a lack of auditing/ and logging or incorrect logging, and ordering and timing errors. These kinds of flaws almost always lead to a security risk.

Before planning for Security Testing, you will need to think about the following parameters:

Authentication – Understand how the authentication process works and attempt to use that information to circumvent the authentication mechanism.

Authorization – Determine that a requester is allowed to receive a service or perform an operation.

Confidentiality – Protects the disclosure of data or information to parties other than the intended.

Integrity – Whether the intended receiver receives the information or data without it being in any way altered in transmission.

Non-repudiation – Interchange of authentication information with some form of provable time stamp e.g. with a session id.

It is only by identifying risks in the system and creating tests driven by those risks that your software security testing can be properly focused on areas of code in which an attack is more likely to succeed. Essentially, this approach provides a higher level of software security assurance than possible with classical black-box testing.

Of course there is no such thing as a silver bullet for software security and even a reasonably ironclad security testing regimen is just a start.

Regrettably, security continues to be sold as a product but many of the defensive mechanisms on the market do very little to address the core of the issue, which is bad software. Instead, these ‘solutions’ operate in a reactive mode: by not allowing allow packets to this or that port, watching for files which include this pattern in them, and discarding partial packets and oversized packets away without looking at them. Network traffic is not always the best way to approach this issue, because the software that processes the packets is the problem.

By adopting a comprehensive and risk-based approach to software security testing, testing professionals can help in solving security problems while software is still in production avoiding costly and embarrassing mishaps later on in the software’s lifecycle.

Join the discussion One Comment

Leave a Reply