If I had a Dollar (part 2) – penetration testing and security myths from Steve Darrall, Securus Global Practice Manager

September 12, 2012

After a too long hiatus, our popular list of things that we see go wrong on a regular basis is back. As I’m sat here writing this, I’ve obviously not had a dollar for every time that I’ve heard the following. I can only hope…

“An attacker wouldn’t know that”. Attackers are sneaky people. They generally know more than you think, and unfortunately for those defending against them they have time on their side. With enough effort and desire to compromise something, an attacker will know what they need to.

“We don’t store unencrypted credit card data anywhere”. This one always makes us raise our eyebrows. If we had a dollar for every time somebody said this alone we would retire to our private island somewhere nice and warm and spend the rest of our days sipping mojitos and smoking Cuban cigars.

“We have a web application firewall, we’re safe”. Good security practice is all about defence in depth and implemented smart. No security product or appliance is a magical silver bullet that will make your problems go away. A wise man once said that rather than buying a single security appliance, people would be better off buying a Ferrari as a company pool car – TCO would be similar to an enterprise grade appliance over a 2-3 year period and there would probably be a better return to the company. (Happier security staff!).

“If something did happen, we’d only be down for a short time”. Potential downtime is just one impact of a compromise. Other impacts are loss of data, a lack of system integrity and time to fix the underlying problem. While an organisation may only be ‘down’ for a short period of time after a compromise, the financial and ongoing intangible impacts can be very significant.

“I’ll send the password in another email”. Please don’t send me an encrypted attachment in an e-mail, then send the password in another e-mail. It defeats the point of the exercise. Any information needed to decrypt sensitive data should be sent out of band – either in person, verbally or if it’s a short enough passphrase, sending it by SMS may be appropriate.

“We’re not a bank, we don’t need to be that secure”. An organisation may not have data that would be important to an attacker, but they have resources – it may be a wireless network or computer system used to launch attacks from. You don’t need to be at the big end of town to be a target for an attacker.

“We’ve had this site tested before. You won’t find anything”. Security is a journey, not a destination. Don’t you love these old clichés? Sorry, but it had to be said. Any penetration test, audit or security assessment is only a point in time view. New code gets rolled out and new attacks are discovered on an all too regular basis. If systems and applications were secure because they were tested once, sysadmins would have a pretty boring patch Tuesday once a month.

“We’ve never been hacked before”. If you know that you’ve been successfully compromised, it’s quite likely that you’ve been compromised previously and just haven’t noticed.

“It’s a security product, it must be secure!”. A product designed to improve the security posture of an environment isn’t necessarily secure itself. Many ‘security appliances’ are based on commodity operating systems. For stability, they may not be upgraded on a regular basis. As anything on top of the standard operating system has to be custom written, there’s always the good chance that ‘unintended functionality’ favoured by attackers and penetration testers alike will be introduced.

“We’ll test it next time”. No you won’t. Actually, that’s probably a bit rude of me. A system or environment may well have security testing performed against it once it’s in production but making any fundamental architectural changes at this late stage is often received very negatively due to the cost of implementing them and also of any potential downtime.

Until next time…

We’d love to hear from you. Why not post some of your own here as responses.

Leave a Reply

Your email address will not be published. Required fields are marked *