In my previous column, I highlighted the incredible urgency around creating a strategy and executing on it—maniacally. Of course, it’s never that simple, is it? Strategy requires a solid understanding of your business, your assets, capabilities and limitations. If we’re honest with ourselves, very few of us in enterprise security can claim to have all those components sorted.
For this post, I will focus on three things it takes to develop a good strategy. In my experience, these are likely the three things that are the most undervalued. They are requirements and stakeholder engagement, feedback loops and proportionality. Let’s dive in.
With the many strategy development workshops in which I’ve successfully engaged, it’s hard to believe how many companies struggle with stakeholders as a starting point. In our quest to find and fix perceived issues at a reasonable pace, it’s fairly simple to assume you understand the problem. The trouble is that without proper stakeholder involvement, you can not only misperceive the problem, but you aren’t engaging the most important part of the company—the people for whom you’re problem-solving.
The above issue is akin to someone walking by your car in the parking lot and seeing you have a punctured tire, then replacing the tire and tacking the bill onto your windshield. Stakeholder not engaged. This ends pretty much the same way every time–with you gaining an adversary. And if there is one group you don’t want as an adversary in your enterprise, it’s the actual enterprise.
Once you’ve got those stakeholders engaged you need to learn how to get requirements in a way that doesn’t create the acquisitions and implementation of a hundred niche solutions that are one-off, non-repeatable and very expensive. How many times have you designed a solution for a specific part of your organization that was just different enough that it needed its own approach, only to figure out this approach cost the company more money than necessary? Sadly, that’s probably occurred at least a few times. You’ll want to avoid that situation, as you won’t survive in your role if you continue down that path.
Next, you’ll want to carefully establish feedback loops and strategically place and integrate them into business planning, and operational and IT cycles. I’m sure you’ve heard the phrase, “fail fast,” but how do you know you’re failing? If you don’t have good feedback mechanisms, you easily can end up blissfully ignorant of the cloud of failure you’re creating around yourself until it’s too late. Generally, by then you’ll want to have a polished resume.
Feedback can be verbal or written. For the sake of protecting your decisions and having something to back you up when you need it, I recommend written. Written feedback, in a more mature organization, happens on a regular and more formal basis. That isn’t to say that nothing else is valuable. However, I prefer to have feedback directly attached to a project page, entered by the person who is giving the feedback, which I then can acknowledge. This creates a record. Records are good.
Last, but certainly not least, we get to proportionality. You may know this by another name, as some people refer to “right-sized” security. Basically, you want to be crystal clear that the effort you’re putting forth and the resources you’re burning will have a proportional good. Way back in my career, I once proposed a fantastic fix to a broken web application, which included a complex infrastructure defense mechanism, a WAF and special monitoring. The result was me being laughed at (literally) by a CIO who told me the fix isn’t worth deploying the app. I learned proportionality that day.
Proportionality can make or break your effort. People will know whether you’re actually in-tune with the organization and its mission when you propose outrageous solutions to problems that would be easier decommissioned. “Don’t spend a million to mitigate a thousand-dollar risk,” my old boss would say. He was right.
These are all important components to developing a sound strategy that will be driven from business need while solving actual problems. Find and engage your stakeholders. In fact, spend more time on that than on the technical solution, if necessary. Get their requirements and buy-in. Model so that your solution is reusable where possible. If you’re destined to fail, fail fast, but make sure you’re not blissfully ignorant. And definitely be proportional in your security strategy. The fact that I don’t think some of us take seriously is that security is simply a lower priority risk than some other risks in the business. Yes, that’s right. Sometimes patching takes a back seat to running payroll. The trick is to figure out how to behave, and have the hard data to back your decision up, when these two priorities collide.