Erin O'MalleyPeople are creatures of habit. If we learn something one way, we’re prone to stick to it. Less in a “my way or the highway” sense and more so in a “if it ain’t broke, don’t fix it” one.
Not every security tool is right for every environment, and just because one set of tools works well for you now at one job and company doesn’t mean it will work well – or at all – if you change jobs or especially, verticals.
At an established financial institution, for example, you may be part of a large team of experienced professionals who’ve worked together to build out a highly refined, capable infrastructure. You may have 1,000 routers and do configuration management in a certain way because it’s been proven and improved upon by 100 people over the course of decades. By contrast, if you were to join a newly emerged startup, you may have four routers, limited personnel and not yet a hint of a config management process in place.
It makes sense that each of these businesses would have different tools and different expectations for how to configure and use them. Still, it’d be tough to argue that both – regardless of infrastructure, technical capabilities or even, tolerance for risk – couldn’t benefit from the ability to test and deploy new tools in a more expeditious, cost-effective manner.
A Better, Faster Way to Test New Tools
Testing new technology can be a real drag. No doubt, different businesses face different problems at different times, but for every business, it’s important to weigh the opportunity cost of testing tools. In other words, how important is bringing on a new solution versus working on some other critical task?
Just to try a new firewall, it’s not uncommon to have to involve your legal team for a non-disclosure agreement, your purchasing department for a zero-dollar purchase order, your network team to manually reconfigure servers and network devices … The list of those you need to involve is long and the process can be tedious, time-consuming and expensive.
If you’re lucky, you test a firewall and it works great. Of course, to get there, you typically would have had to involve network operations (NetOps) to install it and because they often have their own fires to fight, it’s likely they pushed your “new product evaluation” out by weeks or even, months. Not exactly a lickety-split process. If you’re not so lucky, you test a firewall and it doesn’t work as anticipated. When that happens, get ready to lather-rinse-repeat the multi-month NetOps process to bring on a different tool to test.
Unfortunately, the bad guys aren’t so constrained by process. They are wily and relentless as they work to exploit security gaps and defeat your defenses. So, you need to be equally prepared to adapt and evolve – and that can begin with a better, faster way not only to test, choose and deploy new security solutions, but also to help ensure that those tools are afforded the opportunity to do what they do best. That’s right. Set those tools up to succeed!
All Right, All Right, All Right
Like the five-time-Super-Bowl-winning New England Patriots – yeah, not six – Bill Belichick tells his players, “Do your job.” In short, trust your tools to do their specific jobs and don’t have them try to do another tool’s job. For instance, don’t have your firewalls decrypting SSL, which can significantly degrade their performance as per an NSS Labs report.
Designed for specific purposes, security tools should be fed only the data they need to do what they do best; they shouldn’t be burdened with irrelevant data. For example, why send a web application firewall (WAF) anything besides web traffic? Or why send an intrusion prevention system (IPS) traffic that’s already been inspected in another zone? They need the right traffic, and the right traffic only – and that’s exactly what a security delivery platform can deliver.
A security delivery platform lets you test new technology quickly, at your discretion and with much less friction. It can replicate traffic to multiple tool ports so that any number of tools can access the same traffic. This way, you can simultaneously test a variety of security solutions out of band for true side-by-side bake-offs that provide actual comparison data instead of serially and thus, different test sets.
With this enhanced capacity to test, InfoSec management can develop strategic plans for testing – based on the urgency of an issue, availability of staff, complexity of a tool and other dependencies – without becoming prohibitively bogged down by tactical realities. In short, security teams can be their own master; and once they decide which tools to test and which they prefer, they can instantly move them inline – again, while not needing to involve or burden NetOps.
They say nobody ever got fired for buying IBM, but what if you could be the one to find the right tool to solve a long-standing organizational problem? I’ve heard tell you can catapult a career that way.
Originally posted on SecurityWeek.
