Post-Production Application Security Testing

Tuesday, May 17, 2011

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

Hey there, the Wh1t3 Rabbit here with a friendly Public Service Announcement (PSA) reminding you that you have apps that you've deployed that are starting to feel forgotten.  

I'm writing this post on behalf of all those apps that were security tested and deployed with the "Secure" stamp on them... but haven't heard from you in >6 months... some even more than that.  

Quite frankly, they're starting to feel unloved.

All joking aside, I've spent several meetings in the last few months reminding people that even though they perform security testing and validation of their apps before they deploy they're leaving those apps running, in some cases for years, without looking back in on them.  

This is a bad thing.  Just sayin'.

...But 'scanners' can damage production apps!

Yup, they absolutely can... if used in an unplanned, unpredictable manner.  I've read lots of hype about how certain services/tools are 'safe for production apps'... it all comes down to common sense.

If you've got a sensitive app, running a SQL-based database, you probably should have a backup and not run tests which include inserting or deleting records -right?  

Most of your application security testing technologies these days, if they're worth anything, have "production safe" check groups... and you can get best-practices from the vendors too.

I know we provide all of the above to our customers... and if you're ultra-paranoid you can at worst-case use some of the wonderful virtualization technology to snapshot your current environment, stub out the external connections, and go to town testing on a non-production-impacting system.

...But we don't have those kinds of resources!

Boo... if you've got worthwhile technology you can utilize a scheduler on 'permanent repeat' with some pre-defined interval to run security scans on your apps once they've been deployed into the 'wild'.  

Scans run, if nothing is found then nothing is reported ...the only time you should hear from your technology is when something important is found!

If you are averse to automation (or you're one of those that believe you have to manually test) you should schedule regular security evaluations of production systems... although you know that will cost significantly more, but it may be a worthwhile expenditure.  

Just don't bail on a critical step because you don't think you have the resources!

...But I'm afraid I'll find things... then what?!

There I can't help you... just kidding.  The 'then what?' question is one you have to answer as part of building out your SSA program. This is one of the many, many reasons 'security validation' as a single step pre-production is a very, very bad idea.

Your holistic SSA program needs to account for the "what if" conditions ...and one of those is "what if I find a critical bug 6 months after the project is completed?".

Resources have been re-allocated, you probably have no project money allocated, and no one's got time - there are great ways and tricks to overcoming this condition and many other "but, but" scenarios.  You just need to have an SSA program in place... not just a scanner you use once per release.

So, ya... go give those apps that haven't heard from you in a while some love.

Best case? You'll find nothing but a happily running, well-secured application.  Worst case?  Well... you'll find what one of my customers found once... a bunch of SQL Injection problems which had already been exploited... yea.  Oops.

Good luck, you know where to go if you have any questions regarding HP's Application Security Testing Technology... or anything else related to App Sec.  Drop me an email, IM, Skype me or hit me up on Twitter ...

Until next time!

Cross-posted from Following the White Rabbit

Possibly Related Articles:
13662
Webappsec->General
Software
Budgets Application Security Scanners Security Testing Development Software Security Assurance
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.