What can we help you find?
In my previous Blog, I spoke about the fact that Information Security requires us to“do something” and not stick our head in the sand. The road is never ending and daunting but every step we take raises our security posture and hopefully reduces our overall risk. That however is not always the case, so in today’s blog, I want to discuss the benefits and risks of playing “Whack-A-Mole” with your security practice.
First, let us clarify what I mean when I talk about “Whack-A-Mole”. Quite simply, it refers to purely reactive security deployments in which you see a problem and deploy a tool (or control)to fix that problem. There is a definite benefit to this in most cases; if you don’t have a Firewall, deploying one is better than not, or if you aren’t running antivirus on all of your hosts you should obviously do that, and an Intrusion Detection System will give you better insight into the events on your network.
However, there is a downside to just deploying products to fill the next gap you see in your security portfolio, and that can be boiled down to either a false sense of security or a complete sense of hopelessness and ambivalence.
Let’s take the Intrusion Detection System (IDS) as a prime example. Beyond the antivirus and firewall deployments, this is often the next tool security experts deploy to raise their security posture, providing real-time alerts and notifications to odd behaviours occurring within the network. Unfortunately, anyone who has deployed such a tool will quickly find a stream of alerts pouring out of the device, with messages like "SERVER-OTHER Squid HTTP Vary response header denial of service attempt" filling the logs at an alarming rate.
IDS’s are often left ignored, and the potentially critical messages of warning become noise that at best, is reviewed during the forensics phase of the catastrophic attack against your network. IDS customers are left incorrectly thinking they are secure, or more often feel completely overwhelmed by the number of alerts and their inability to handle them. But I hear you saying, “That’s why we useIPS, not IDS”, so the game of “Whack-A-Mole” goes on.
I am happy to acknowledge that using Intrusion Prevention Systems go a step beyond IDS systems by allowing the IPS device to automatically identify and block threats automatically occurring in the network, however, this does not eliminate the issue with monitoring of other events. Many attacks use standard application behaviour to propagate through your network, and the IPS is typically configured to play a conservative role, ensuring business critical applications are not impacted. All this means that many stages of an attack must be identified through IPS monitoring event logs, just as they would have to with an IDS only solution.
This scenario continues to play out as we look at the entire security framework for your business. Patching of applications and operating systems cannot be a one-time event, but instead there must be an ongoing patch management processing place across your entire organization. Addressing the OWASP Top 10 vulnerabilities requires constant vigilance for every new application deployed and every new Web Server you spin up. User account management policies and enforcement processes must be constantly validated and improved. The list goes on, and on, and on.
Don’t get me wrong, if a mole shows up in you front lawn, feel free to give it a good hard whack with a mallet, but you need to take a step back and prevent the moles getting into the lawn in the first place. That’s where the framework models I mentioned last time come in, SANS CIS Controls, NIST’s Cybersecurity Framework, ISO 27001 – Information Security Management to name but a few. These frameworks help structure your security model into several manageable chunks, each assisting in addressing policies, people, and process, for a more wholistic approach to information security.
Whilst the controls defined in these frameworks are great tools to help guide you through the security hardening process, there is one other tool that may be helpful, and that’s understanding why we are applying them, and that brings us to the 5pillars of security. There are five objectives we are trying to meet, and all controls we deploy should be aimed at meeting one more of these targets:
These five pillars can be used to determine what your priorities are, or reciprocally, used to determine the value of a given control. For example, when working with your business decision makers, we can now use this as a business justification to describe why we need to deploy a certain control and what the business benefit will be. Likewise, we can define the desired outcomes by which we can determine if a given control will meet our objectives.
Remember that no given security control can completely protect you from the vast array of threats out in the Internet, except maybe unplugging from the network and turning everything off. That, being said, good security is based on defense in depth. Deploying a number of complimentary controls, in a framework that aligns with your business objectives will drive the best outcomes.
At Charter, we are always increasing our portfolio of products to allow our customers to build secure networks that protect against a large array of threats, but we don’t just want to be your vendor for a bunch of “Whack-A-Mole” mallets. Instead, we want to bring our breadth of experience and knowledge to work with you, identifying your risk points, building a suitable roadmap towards a safer, more resilient future. Feel free to reach out if you want to hear how we can work together with you on this.
Next time, I will talk about how security goes beyond just deploying controls to being an organizational lifestyle.
Author: Ronnie Scott (CTO)
