Since the time of my first household chores, I cannot recall an age when I did not look at a “to do” list of mine and see the need to prioritize things. Whether it was taking out the trash first because trash collection was the next day or recognizing the need to finish edits to a press release going out the next day, prioritization has always been the first step to me getting work done.
I don’t think I’m alone on this one. Prioritization is probably as important to getting things done successfully as the actual taking on of a task.
Not to prioritize is to engage in the infamous placement of “cart before the horse.” That’s a bit like what I think Kevin Casey did in his recent article in InformationWeek when he offered four security strategies for SMBs…only not only did Casey put the cart before the horse, I think he forgot the horse all together.
Casey starts out by noting that security is not an “all or nothing” proposition; in fact, he goes so far as to say that prioritizing is the key. In listing his priorities for security, however, he misses a key priority – fix the security problem!
Casey’s first priority – not to panic – is sound advice; I’m just not sure that it’s the first priority or even an item that can be prioritized. Staying calm is definitely something businesses need to do when faced with a security issue since panicking under any set of unsettling circumstances only leads to failing to do the things needed to undo the adversity. Not panicking is an item that should almost go without saying. So if we need to remind ourselves not to panic as part of every step of handling a security breach, is it really “numero uno” on our priorities list?
And do we really, in this day and age, need to make a business case for why security issues should be addressed? Haven’t the breaches at Sony, the Pentagon, Citi and a multitude of others shown us how security breaches can be extremely costly both in financial and reputation terms?
That brings Casey to his third priority – to prioritize. Isn’t that a bit like defining a word with itself?
As for his idea that “quick wins” should be the fourth priority, I can see his point here. When faced with a security breach, a company should do something fast to make those concerned – both internally, such as executives, and externally, such as customers – acknowledge that the situation is being handled. The easier something is to do, the faster it can get done, so if some immediate show of good faith is necessary, perhaps that would be the first priority…if perception is the company’s primary goal.
Obviously adding security systems after the fact will alert a company and make it look like it is taking on the problem head-on. Those security systems, while good at alerting the company to the existence of a potentially harmful application, virus, malware or unauthorized access, do not repair the point targeted by these things. If SMBs or even large enterprises want to go beyond mere perception, though, the first thing they need to do is find the vulnerability that yielded the breach and fix it.
One thing most security breaches have in common is that they were the result of some structural quality defect in an existing application that served as a point of vulnerability. Evaluating an application for its structural quality defects is critical since these defects are difficult to detect through standard testing; yet these are the defects most likely to cause operational problems such as outages, performance degradation, data corruption and, of course, security breaches by unauthorized users.
A company that truly wants to address a security breach should first analyze the applications in its IT system to find which of them has issues with structural quality that could have been the breaching point (or points). Most companies historically have avoided doing this because all they had available to them was either manual testing – which is grossly inefficient in terms of accuracy, cost and time investment – or comprehensive analysis platforms that only large enterprises could afford.
Today, however, there are automated analysis and measurement tools on the market offered via Software as a Service (SaaS), which makes it cost-effective and much easier to find application vulnerabilities in an IT system. In fact, with these SaaS versions of automated analysis and measurement on the market, finding vulnerabilities should probably be bumped in priority to BEFORE a breach happens. Taking the proactive approach would all but eliminate the need for the rest of the post-breach “to do” list and make things rather easy to prioritize:
1. Analyze all applications for structural quality defects