Smart Contracts

Updating Solidity code and Testing a Smart Contract

Books on the Blockchain

Publica Self Publishing

Goodbye Contracting

Hello brave new old world...

Ruby-Selenium Webdriver

In under 10 Minutes

%w or %W? Secrets revealed!

Delimited Input discussed in depth.

Friday, 4 November 2011

You don’t want to do ‘Penetration’ Testing, probably

Here’s an interesting thing, when people talk about Security testing they usually talk in terms of Penetration testing. You can imagine the scenario, “We need to make sure our site is secure, let’s hire a security consultant to do some penetration testing”. However, they rarely mean Penetration Testing. It’s the same as people talking about software quality assurance when they mean software testing. It’s similar to Performance testing when they mean Load or Stress testing.

It’s not that we don’t understand why people use these terms in a slightly inaccurate way, hey they’re not all 24/7 live and breathe testers like us, we can give them a break regarding the terms they use.

The point is, Penetration testing is more correctly thought of as; “A sub-type of Security testing focused on exploiting vulnerabilities present in the underlying design, application code and functionality and the network the application is deployed on. This includes exploiting interconnected software systems, networks, access controls and physical security.“ to quote the Test Hats ‘Software Testing Dictionary’.

Another good definition comes from the book, ‘Backtrack 4: Assuring Security by Penetration Testing’, “The basic difference between a vulnerability assessment and penetration testing is that vulnerability assessments identify flaws… without measuring impact, while penetration testing… exploits these vulnerabilities”.

Here’s the punch line that gets missed, the active exploitation of vulnerabilities should be expected to leave systems in a compromised state and that means they’ll need to be rebuilt. You did make a back-up of the data, configuration, etc. right?

That previous bit is the bit that doesn’t get mentioned very often it appears. No, not the need for back-ups… the bit about Penetration testing of live systems leaving them in a compromised state. Truth is, Penetration testing proper is a risky business and a service that most clients don’t really want and don’t need.

Most often what’s needed and what’s being asked for is an audit and assessment of how secure the network and application is. Of more value to them is seeing how robust their ‘security posture’ is in terms of technology, configuration, patch cycles and so on. They can then take a Vulnerability Assessment or Audit report and remediate any issues on there. This is far more valuable than Penetration testing on its own.

However/But… because there’s always a but… Penetration testing has its own unique value in that if you want to truly harden your systems, your need to do Penetration testing. The fact is that Compliance Audits, Patch Audits and Vulnerability Assessments are, in the main, checks. Audits are checks of compliance against a given standard, such as PCI-DSS or your own standards, they’re fairly static. Vulnerability Assessments are more dynamic, given the threat landscape changes day to day it isn’t possible to statically define some threats in an ‘audit file’ and merrily check them.

Penetration testing is not only more dynamic the testing approach required is far different too. This is testing, not checking or auditing. But… that’s a topic for another time!


Thursday, 3 November 2011

Best Practices - Smoke and Mirrors or Cognitive Fluency?

Simon Morely made reference to a blog post I wrote over at the Software Testing Club recently. It relates to Best Practices and a conversation we had in house here at Test Hats. He makes some great points and the post is well worth a read.

The Tester's Headache: Best Practices - Smoke and Mirrors or Cognitive Fluency?

The original blog post I made is linked to from his.