Even With Lower Capital Costs on Paper, the Cost of the “Fire, Ready, Aim” Approach is Reputation
It seems these days that the cool thing to do is to be agile. Sounds like a great idea, doesn’t it? The premise that we start moving in a direction and adjust quickly as conditions or feedback warrants it fuels our desire to be innovative and cool. When this is well executed, it is fantastic.
It is never that easy though. Agility comes at a heavy price, from my experience. “We’ll fail fast, learn and adjust,” we tell ourselves. But in security we pay a heavy price even if the price tag isn’t measured in dollars or euros. Remember reputation? How many of you security leaders reading this have the ability to repeatedly say, “Sorry, let’s try something else,” before you’re shown the door?
Even if the capital costs are lower on paper, the cost of the “fire, ready, aim” approach is reputation. I’m not advocating that security shouldn’t be agile, or that security doesn’t have a place in DevOps. Rather, organization that haven’t figured out how to build their reputations with successful business integration should first start with the classic plan, build, run approach. Essentially you need a plan. Start with the simplest question—what are you doing? Then move to more complex questions such as: Why are you doing it? Who is going to be required? What is your expected outcome? My boss likes to quote Martin Fowler—and it applies here— “(Software) architecture is those decisions which are important and hard to change later.” Old school, I know. But bear with me here.
Security is currently being forced into a painful evolution through a combination of ongoing incidents and business forces. I’ll pause while you return from shock. No, this isn’t a new statement because it’s been this way for a while. I should probably say security is still broken. Rather than starting with a sound, business-aligned strategy supported by business-executive stakeholders there are far too many security organizations that just choose the “do something” path. This usually leads down the road of “buy whatever we can to check all the security domains” boxes. Whether you’re on NIST, ISO or whatever – the result is the same. More ‘stuff’ than you can make sense of… broken. Checklists rarely get us to the right place.
I bring this up because with all the chatter about a return to fundamentals, again, I think we’re still missing the point. Yes, we need to slow down to go faster. I want you to be agile, too! But I don’t want you to run off into execution so by the time you look behind you, there’s no one from the business supporting you. Executing the three classic stages—plan it, build it, run it, then repeat—is still your best bet to get security “right” at your organization. Let’s break that down.
• Plan it – Strategy is important. Pull in non-IT stakeholders. Leadership from your business should have a direct stake in your program. If every initiative in your yearly plan doesn’t map back to a key, prioritized requirement from one of your business-level stakeholders you’re doomed. Period. However, strategy should not be written in stone, and inflexible. Prepare yourself for minor adjustments as your year progresses and you execute your strategy. Find your balance. How rigid or flexible you will need to be is unique to your organization, your leadership style and your resources. May I suggest, if you have not already done so, that you go read The Phoenix Project? You’ll thank me later.
• Build it – Building security into the business has been elusive for the last 20 years of my career. I feel like we’ve been chasing this ever-present goal since I started in this field. We get close, then get complacent and miss. Rinse. Repeat. Executing on your strategy is critical. “Build” is where premium-grade rubber meets race track. Finding a team that can translate strategy to build-in security feels like magic. And to some degree, it is. But it needs to be concrete, and real or else…you know. Think back to that quote on security architecture from earlier and make sound, secure decisions. If you don’t do that now, you’ll pay for it later.
• Run it – Operating a security program, that is, the long-term maintenance of the thing you’ve built from the strategy you’ve set, is tricky. Operations feels like it should be handed off to someone else. False. Operations should be part of the job description for the team that built it. No one else knows how to run the vulnerability scanning workflow and tools like the team that build it out.
There’s no arguing that. How do you keep your team engaged so you don’t end up banishing people to operations land? Also, how do you keep them from being overwhelmed? You can’t keep the same three people doing build and run for 20 different processes and tools. That’s the trick. That comes full-circle back to your strategy, which should account for this. There’s more to this topic, and I’m running up against the limitations of even my own attention span in a single sitting. So, I’ll continue this in my next column. For now, let’s discuss this: do you agree or disagree? Have anecdotes to share? Let’s hear them. Find me on social media like Twitter and LinkedIn. I’ll start a conversation and want to hear your experience.
