A New Way to Tie Security to Business
As security professionals, sometimes the advice we get is to think about the security controls we deploy as some mix of “cloud access security brokerage” and “user and entity behavioral analytics” and “next generation endpoint protection.” We’re also supposed to “hunt”, “comply,” and ensure people have had their “awareness” raised. Or perhaps they mean “training,” but how people are expected to act post-training is often maddeningly vague, or worse, unachievable. Frankly, I have trouble making sense of it, and that’s before I read about how your new innovative revolutionary disruptive approach is easy to deploy to ensure that APT can’t get into my network to cloud my vision.
I’m making a little bit of a joke, because otherwise it’s a bit painful to talk about.
Really, we communicate badly. It hurts our ability to drive change to protect our organizations.
A CEO once explained his view of cyber. He said “security folks always jump directly into details that just aren’t important to me. It’s as if I met a financial planner and he started babbling about a mutual fund’s beta before he understood what my family needed.” It stuck with me. Executives are generally smart people with a lot on their plates, and they want us, as security leaders, to make ourselves understood.
I’ve been heads down with a small team, building a new kind of risk management software. It’s designed to improve executive communication. Our first customers are excited and finding that it’s changing the way they engage with their management teams. Right now, we’re looking for a few more forward-looking organizations that want to improve their security, allocate their resources better and link what they’re doing to what the business needs.
If you’re a leader at such a company, please send me an email [first]@[last].org, leave a comment or reach out via linkedin.
At the risk of underlining the point of the article (and yesterdays’ episode of Silicon Valley) I’ll make a suggestion. As you develop your software, take a page from an Architectural framework to map dependencies between layers of points of view, and columns of categories.
– Business is the top layer, and for the sake of simplicity limit that to three: Capabilities, Processes, Units
– Business depends on Data which breaks down into layers something like: Masters, Replication, and Integration
– Data depends on Applications which looks something like: Modules, Platforms and Integration
– Cloud or Infrastructure breaks down into something like: Servers, Storage and Networks
If you begin to link dependencies from Business to Data to Application to Cloud service or Infrastructure, you begin to at least understand the importance of something like a specific server that supports the Order-to-Cash business process, vs. a server that used to send email confirmation for orders until someone redesigned the business process.
To understand each layer better, ask the ‘5 W’s’ for each: Who, What, Where, When, and Why. Or, Owner, Inventory, Location, Calendar, Work performed, and I like to add some Health metric. So for example, who is the owner of the Business Processes, what are all the business processes, where do the business processes run, the calendar events that affect these business processes, why are these processes important, and how do we know these processes are running well (health metrics).
The realization that we all support the business, takes the religious view out of our area of expertise, and helps us prioritize what we do.