The Growing Cyber Threat And The Tester’s Call To Arms

I talk to a lot of testers about where they should focus their professional development. There’s no simple answer of course— it’s a personal choice but it’s still a good conversation to have. Given our profession is so broad and individuals so different, a lot of ideas come up. When discussing what particular areas testers might focus on, three seem to come up repeatedly: the broad field of functional / system testing and the more specific areas of performance and security testing.
Upon further questioning, the conversation seems to take on a very similar pattern. Testers say they’ve got a good level of experience in functional / system testing, have ‘done a bit’ of performance testing and almost always leave security ‘to the professionals’ who know how it’s done.

Even when talking to owners of other small to medium sized testing consultancies like Test Hats, the story can be the same. They’ll of course state that system testing is trivial for them to deliver, talk up capability and experience around performance or in some cases say they’ve ‘done a bit’ of performance testing, which is a little worrying. Then when it comes to security testing, they either say they’ve not touched on it (generally no ‘done a bit’ for security thankfully) or again they claim to have it in hand, which I rarely believe.

I’ve spoken about security testing to founders of three SME sized consultancies who said they deliver it, asking what they provide. As before, there was a lack of clarity over the different levels of security testing or hints about how different forms of security testing get delivered.

Just like performance testing, this appears to be a case of ‘doing a bit’ of security. Have I used the word ‘worrying’ yet?

Stand in Your Corners

The current state of affairs for how the majority of security testing gets delivered appears to be through consultancies that specialise in the field. (If you just mentally said ‘yep…’, thank you)

However, they tend to not do all-the-other-testing or provide related services that a regular testing consultancy would. Of course there are some huge service companies out there that are exceptions, but in the main we have the ‘regular’ testing profession on one side and then on the other side we have the security testing consultancies. It’s always struck me as an odd disconnect from our side, but perhaps understandable from theirs. Security is complex and it’s much easier to achieve the required competence and competitiveness if you specialise.

How many projects have we worked on where security testing consists of bringing in a third party to do Pen Testing? As any astute tester will realise, this approach isn’t good practice in terms of securing the application or the network it sits on. Certainly it’s of no use in making sure both remain secure, perhaps in a way some external authority requires.

Let’s just summarise the three glaring issues we’ve already mentioned.

• There’s a worrying level of ignorance over security testing amongst testing professionals and testing consultancies.
• Security is often bolted-on at the end of the project to assure the application is secure, in a way that’s similar to doing testing at the end to bolt-on quality. It doesn’t work in either case.
• Professionals with the same essential goals are often separated project wise and professionally.

Ignorance is Not Bliss

As testing professionals we’re on the front line of assuring the quality and correctness of the applications we’re charged with testing. That means more than just ticking requirements boxes, as seems to be the accepted norm these days.

However, while we might consider getting involved in conversations about defining and clarifying functionality, compatibility, usability, etc. how often does the conversation extend to application security?

When was the last time you got involved in a Threat Modelling session at the design stage of an application you’d later have to test? When was the last time you even heard of this taking place? It’s rare, so don’t think it’s your oversight if you haven’t picked up on it happening on your projects.

Here’s an example of another risk that ignorance of the need to consider security brings. No threat modelling suggests an assumption that a secure application will just emerge.

This lack of consideration about security testing has already introduced two risks,

• Not considering how to make the application secure at the design stage Expecting it to become or be proven (magically) secure at the end of development.
• These are the same issues we still see too often with testing and QA, pulling in regular testers or security testers at the end of development. Yes, it still happens even with all the talk of agile.

Unlike regular testing though, there is an even bigger risk that not considering security can bring. Whereas a website with bad functionality might result in a loss of sales or users for the site alone, an insecure site can risk the privacy and finances of everyone who ever visits the site, and the business will suffer a reputation hit just to compound the situation.

Add to that the risk of non-compliance to standards such as PCI and the potential for fines. Clearly, security is not something to be lightly considered.

The Growing Cyber Threat

Each year the cyber threat increases – with more and more sites being hacked and personal or proprietary information being stolen. This cyber threat applies to individuals, companies and nation states alike. In 2010 the US Secret Service arrested 1200 people in relation to cybercrime. These individuals were located across the US and Europe.

Hacktivist groups like Anonymous have attacked many targets and released personal details of hundreds of their customers. From Sony, Apple and BART to PayPal, MasterCard and Visa any company website can be attacked and data compromised. Add to that the activities of Lulzsec and Team Poison (TeaMp0isoN) and sites like RankMyHack.com encouraging hacking, it’s clear the problem is not going away.

It’s not just websites that are under threat either, as we learned in the McAfee report this year. [1] Governments around the world have been subject to hacker attacks, along with companies in construction, energy, electronics, news, defence, accounting, insurance, sport and more. The UK Cabinet Office estimates the cost of cybercrime to the UK economy to be £27bn, incredible when you consider the cost from drug crime is said to be £13bn. [2]

Just in case you thought you weren’t involved, the Damballa half year report for 2011 informed us that the number of systems running Botnets [3] for malicious purposes on the internet, was a staggering 9.2 million just in North America. [4]

Not only is the matter of needing secure software not going away, the attacks are increasing and the risks are getting more diverse while increasing in number [5]. If you look over the Web Hacking Incident Database (WHID) [6] and compare it against the OWASP Top 10 [7], you’ll see there are far more attack types than just the 10 we’re used to hearing about.
SQL injection, which is a basic method of hacking, still remains the number one way to attack a site. In 2010 it accounted for 15% of all recorded attacks in the WHID and ranked number 1 on the OWASP list.

Remember, with the WHID not every attack makes it to the database as not every attack or breach gets disclosed. As with other sources these numbers have to be taken as indicative. Perhaps more worrying than the 11% of attacks using stolen credentials, 6.7% using Cross Site Scripting or 5.3% using good old fashioned Brute Force attacks, is the massive 21% of an unknown attack type. Either there is a serious classification problem or some very sophisticated attacks are happening.
The point is clearly made – the problem is not going away and it is becoming more widespread.

Proceed to the Door Marked Security

The message running through all of this is that there’s a need for robust security testing of software. As software testers we should be in a strong position to lend our support to the Cyberwar, yet are we playing our part?

If we want to, we can step-up to the front lines. Whilst we are not perhaps the ones who should test across the whole security programme, we can certainly prepare the ground for a more complete assault on the application to root out those dangerous security vulnerabilities.

In fact, it’s my view that just as we often bridge the gap between different departments, coercing them into collaboration to help improve software quality, we can also do the same to improve software security. Who’s been in the situation as a testing professional where we’re bringing together Product Owners and Developers, Operations Teams and Support Teams, all in the name of improving quality? Well, now we can be the ones who do the same by pulling together Security teams and System Architects, in the name of improving software security.

What’s more, it’s something we really should be paying more attention to given all-of-the-above and given our profession’s increasing use of exploratory testing. This is the killer technique in our toolbox that we can bring to security testing. As we’ve stated before here at Test Hats, it’s our contention that testers who practice exploratory testing techniques have learned a number of essential skills for testing in a security context.

Thinking, observing, questioning, reasoning and testing ideas and insights, applying knowledge and acting on new information as it arises — these are essential skills for a security tester. Those who regularly practice exploratory techniques are well equipped to test in a security context.

First Steps Into Security

What needs to happen is for testers to decide they want to take part in security-related testing and define the level at which they will be involved. It’s certainly essential that we take responsible and measured steps, only committing to deliver what we are capable of doing. Perhaps it’s helping make sure those Threat Assessment meetings happen and being the facilitator and note taker, or maybe helping ensure the design is created with security in mind. Maybe it’s doing an Application Vulnerability Assessment in line with the OWASP Top 10, bearing in mind the results of the Threat Assessment to make sure the testing conducted is relevant.

For those who are now focused on testing management, it could even be a more QA focused approach, rallying the business to develop an Information Security Management System (ISMS) in line with ISO27001. There’s a lot we can do in the security space as testing and QA professionals, even where that is just ‘facilitating’ or laying the groundwork for the more experienced professionals.

It’s up to us to bridge the gap and the real challenge is in thinking how to get started. Here are some ideas to start things off:

• Over at the Software Testing Club, you’ll find the Security Testing Group that’s free to join. The group has a growing list of resources and links to websites, blogs and security forums.
• Start reading a general security blog such as www.ehacking.net/. It’s not a community forum but has lots of interesting posts on tools, tutorials, etc.
• Have a look at www.securityweek.com and similar sites to get an idea of security in the broader industry and some of the big issues that are happening.
• Read the OWASP Testing Guide or Open Source Security Testing Methodology Manual to get an idea of how to approach security testing in a structured way.
• Practice on a system you are allowed to practice on but be sure to practice, practice, practice.

Be sure to head over to the Software Testing Club’s Security group and join in the conversation and share your experiences and ideas. Together we can add security testing to our testers’ arsenal and help defend against the growing cyber threat.

References

[1] – http://www.mcafee.com/us/resources/white-papers/wp-operation-shady-rat.pdf
[2] – http://www.cabinetoffice.gov.uk/resource-library/cost-of-cyber-crime
[3] – http://searchsecurity.techtarget.com/definition/botnet
[4] – http://media.scmagazineus.com/documents/28/damballa_threat_report-first_h_6879.pdf
[5] – http://www.cso.com.au/slideshow/397747/10_scariest_hacks_from_black_hat_defcon_/
[6] – http://projects.webappsec.org/w/page/13246995/Web-Hacking-Incident-Database
[7] – https://www.owasp.org/index.php/Top_10_2010-Main

Author Profile – Mark Crowther

Mark Crowther is the founder and Principle Test Architect at Test Hats. His focus is on doing hands-on system and security testing and helping others learn how. You can follow Mark on Twitter at @MarkCTest.