When a new CISO arrives in an organization, they will often walk in expecting to review, assess, build upon, and (sometimes) undo the work of their predecessor. Obviously, this can be a daunting and unique challenge. Sometimes they may find that there is nothing but a green field in front of them. That can be even more terrifying and thrilling. On the one hand, you have an opportunity to build the program you have always dreamed of. On the other, you have to build the whole damned thing!
Regardless of the maturity level of the program, you are walking into, there are many things that every CISO must remember when starting a new position:
- Understand the business
- Establish a baseline
- Communicate the risk
In this series, Intrinium’s Stephen Heath will cover critical lessons that new CISOs must learn when taking on the monumental responsibility of building from scratch.
Chose the right tool
A long time ago, I had a boss who had a saying; “You can use any tool for a hammer and a hammer for any tool; just don’t expect great results.” Things were much simpler back then, but I still think the adage is still true today, even in InfoSec. You can use a vulnerability scanner as your asset inventory. You can use a log management tool as a SIEM. You can use Active Directory logging as an FIM. The real question is… should you? You can but, it is not something that we recommend to our clients.
Part of the joy of being an engineer (or dare I say it, “hacker”), is pushing the limits of the software beyond the confines of its intended use to make things work for your needs. It is rewarding and makes you feel like you are smarter than everyone else because you have developed a solution for the fraction of the cost. However, no solution can be good, cheap and compliant.
Early on in my career, I fell into this trap with a client who couldn’t afford a real SIEM, but needed me to come up with a solution to meet their PCI requirements on their budget. This was filled with only the best intentions in the world, and so I came up with a series of batch files that collected all the logs across the enterprise and parsed them to look for suspicious events. It was barely a SIEM, but it checked the box. How do you think that worked out long term?
I share this story because I am certainly not the only one who has done something like this. As a matter of fact, I’m pretty sure a lot of you hackers-turned-CISOs are nodding your head with embarrassment (and a little pride) regarding just how close to home it hits. Furthermore, if you weren’t this guy, I’m pretty sure a lot of you have this guy on your team, and despite the promises of how “simple” it was going to be, the project turned into a nightmare because you let him try and hack your way to a checkbox.
We must rise above this trap and make sure we are consciously choosing the right tool for the job (and not trying to hack some other tool into doing the job).
Three very simple questions should be at the top of mind:
- Do you need it?
- Can it do it?
- Can you use it?
Do you need it? This seems obvious, but it isn’t. Ask yourself – does the product I am looking at solve one of my Top 3 security risks? If the answer is no, you are already buying the wrong product.
Can it do it? Create a plan before you start by listing out the core features that you need from the products and risk(s) they address. Break the list into must-have and nice-to-have. The product should be able to do the must-have things today. Stick to the plan when you start evaluating the product. If the product isn’t at the core of what the vendor does, you should be cautious. If the vendor is just launching a product or feature as part of a new offering, you should be suspicious. If the feature is “on the roadmap” you should be very suspicious. If your engineer thinks that he can “make it work,” run the other way!
Can you use it? Do you have the headcount and skillset to support the solution? Despite vendor promises, no security product will be able to take care of itself. It will take people to set it up, people to maintain it, and people to respond to the alerts it generates. If you can’t get the bandwidth on your team to support the product, you are better off choosing something you can support, or going a different route altogether by choosing a service rather than a product.
If you can answer yes to these three simple questions, congratulations! Maybe the product deserves closer inspection and you are on your way to solving a business risk. If the answer is no, you probably aren’t choosing the right tool.