• Don’t test your Web applications because they’re too critical…? What!?

    17 Oct 2007

    I can’t tell you how many times I’ve come across network managers who choose to ignore their most critical business applications – all in the name of system uptime. I had a recent event that sparked this very post. The general perception is “We haven’t tested our e-commerce/online banking/employee portal/ fill-in-the-blank Web application for security vulnerabilities – we’re afraid it may go down if it’s hit too hard…” My initial (and unspoken) response is: “You’re joking right!? So, literally everything your business takes in, manages, and maintains has never been checked for security flaws – all because you’re worried that the system may crash..?”

    Wow – what a business philosophy. No checks and balances, no insight into just how insecure you are, and no real responsibility and leadership doing the right thing. How’s that going to look in the eyes of customers, business partners, auditors, regulators, and boards of directors? I’m truly shocked at this bury-head-in-sand-and-hope-nothing-bad-happens mode of operation. I couldn’t make this up – I’m actually seeing and hearing this folks!

    So if you haven’t tested your Web app(s) for security weaknesses that both untrusted outsiders and trusted users can exploit to their advantage, do something – soon. Be it an automated scan using a good Web application assessment tool, a manual analysis using a malicious mindset, or both – security testing needs to be done somehow some way. You’ll be amazed at what the automated scanners can uncover – things that we humans would never detect in a million years. Vice-versa: you wouldn’t believe what a sharp eye can find when manually poking around a Web application – things automated scanners will never find.

    If you use a reputable commercial tool, throttle back the number of requests being sent to the server, and stay away from denial of service checks, everything will likely be fine. Manual assessments logged in as a trusted user should have no effect at all. If there’s any doubt, then schedule your testing during off-peak hours with a contingency plan in place in the event of trouble. Or, just test your QA or staging environment. That may be close enough to the real app to get good results.

    Imagine if Amazon.com, eBay, or other highly critical systems were not tested for security flaws just because they may crash. No way – there’s too much to lose if they’re NOT tested. Ask yourself what’s worse: a brief yet HIGHLY unlikely system outage or a Web application hack and the subsequent ‘splainin’ you’ll be doing when a vulnerability is exploited.

    There’s just no excuse not to test….