How Not to CISO - Tools Before Capabilities

This is the first of a series of articles about lessons learned from the battlefield of doing enterprise infosec on how not to do things in the leadership/management space. In this one, we talk about something I've seen several times: a fixation "shiny new toys" over understanding how to build capabilities.

Just like we have the "security vs usability" trade-off, there's a "time/effort vs money" tradeoff that we must do when solution designing in infosec. Sure I could review web proxy logs and make a glorified VLOOKUP table of URLs/IPs to cloud services (it would take a lot of time and effort), or I could just buy a CASB.

Tools are stepping stones in maturity and capability of infosec within an organization. With a CASB, I can now make the management of this VLOOKUP someone else's problem, and I can focus on problems further down the maturity curve (like shadow IT usage and feedback loops into said web proxy to block unsanctioned cloud apps). Understanding where your team and business need to land on the maturity curve is important, because you're likely not delivering just one capability but a full host of infosec capabilities.

Be smart about what you accelerate and what you keep manual.

But one thing to understand is that you must have a clear objective of why you're doing this (why I'm trying to correlate web traffic with cloud services), otherwise you're risking failure. This is a simplistic example, but gets harder as the scale increases. Understanding the outcome of a tool is important, and not just the first order outcome. Continuing my CASB example, it's great to understand shadow IT usage, but how am I going to understand if a SaaS is sanctioned?

Blocking that cloud financial platform that the CFO really cares about will likely kill further efforts in this space, so who from IT or the business can you engage (second order) and do they have bandwidth for this process (third order)?

Any foray into purchasing a tool should have this understanding, regardless of how complicated or intricate the problem: there comes an upper limit on time/effort within all teams involved in the web of operating this process.

Now that you've thought about what you want to get out of this tool, there's the crucial step of making a capability out of the tool. All of our infosec tools just enable us to deliver a capability: an EDR contributes to our malware protection capability, DLP contributes to our data protection capability, a SIEM contributes to our monitoring and logging capability.

Meaning, that if we don't build processes or conceptual models on how these tools enable us to do an activity (i.e. a DLP agent makes us able to detect credit cards being sent through email, but the process tells us how to triage, who to engage, how to respond).

Just because you bought a DLP product, it does not mean you suddenly have a data protection program! And building/buying a tool before you understand what you and, more importantly, your business need is just a recipe for disaster. Additionally, when you start thinking of the process and human overhead is when you start to understand the true total cost to operate (TCO).

In summary:

• Define the capability you're trying to deliver, then design your solution around that and fit in the tooling as needed.
• Don't forget the additional "costs" like defining supporting processes and human training/operation for said tool.
• Don't invest in tools without understanding the business drivers for buying a tool and the gains to be made from that tool.