This is a follow-up to my last post ("3 Common Ways Security Fails People"). After posting it, someone on twitter quickly asked if I had any ideas for fixing these common problems. Well, of course I have ideas! :)
Soooo... rather than be one of those non-constructive criticizers of all things infosec, here are three solutions to the three problems:
1) De-Operationalize "Security"
I first wrote about this notion in 2009 (see here), and it's started to gain traction in a few places, but it still bears reiterating.
There are several problems created when security exists as the responsibility of a standalone team or organization. First and foremost, you have the "enablement culture" problem where people conclude that "security is their responsibility, not mine" and thus proceed without making good decisions. The big take-away point here is this: security is an emergent property or an attribute of existing functions. It's not a role so much as a responsibility.
As such, it's time to disband those dedicated security teams and return operational responsibilities, such as for managing firewalls, IDS, AV, etc., to the operational teams that specialize in, well, operations. At the same time, it's imperative that security become a shared responsibility of everyone in the organization, and that an accountability culture be instantiated around these "new" responsibilities (I put that in quotes because it's not technical new, but will likely be perceived as such).
There are potentially exceptions to this rule as some teams may be justifiable, depending on how your organization is structured. For example, it may be useful to have dedicated resources for incident response management, business continuity management, and audit & assessment. However, those functions can just as easily be rolled under the resultant team or department, assuming they don't have a better home elsewhere. This leads to the next point...
2) Elevate "Security" to "GRC Program"
Once operational responsibilities are abstracted from your "security" team, it is then time to change focus - and name! You're now talking about a Governance, Risk Management, and Compliance (GRC) program. Note here that I'm talking about GRC as a discipline, not as a tool (see here for more on what that means).
Your main objective in elevating the previous practice to a GRC program is to start working as a peer at the senior management or executive level of the business, helping bring together the best information available to assist in making quality decisions while also actively managing liability and various risk factors. The GRC program needs to interface with business leaders, HR, Legal, IT, and any other key teams in your organization.
The GRC program does not exist purely as oversight or reporting, but also as an intelligence function. We've all heard about business intelligence over the past few years, and this is a natural extension of that capability (much as Operational Risk Management is a sub-component and extension of Enterprise Risk Management). The bottom line is that the GRC program will own Operational Risk Management (of which IT/security "risk" is a part), which will in turn feed into the overall Enterprise Risk Management program (formal or not).
One key in transforming into a GRC program is to become a liaison and bridge-builder, as well as an integral part of all decision paths (and not in a bureaucratic way!). The only way to start actively managing liability and risk factors is to have insight into what's going on, an understanding of what's important, and a voice in decisions being made. This position becomes increasingly vital as we continue to see cloud computing, social media, and mobile computing transform enterprise technology and how data is handled.
Lastly, the GRC program needs to take an active lead in helping transform the traditional approach to security awareness. With security being everyone's shared responsibility (and now, per #1, included in everyone's job description and duties), it becomes important to provide people with better tools and support so that they can understand the impact of their decisions before making them. In the future, this may include setting up collaboration and communication centers, as well as possibly exploring the "gamification" of awareness training.
3) Understand the Business
Your GRC program should reflect the core drivers of the business, and your models should be aligned to that purpose. What does this mean? In practical terms, it starts with concepts like "impact" and "value" (a topic for another post), which may mean focusing on key business processes, or assets, or some other vital aspect of the overall business structure. It's important to understand what the business does, how it does it, and how you can make small improvements throughout to improve security without negatively impacting overall value.
Case-in-point... compliance requirements, in many ways, drive me nuts. On the one hand, these requirements are beneficial (especially for consumers). Take healthcare as an example: it's good to have requirements around the handling of nuclear materials used in medical imaging. After all, you don't want radioactive materials just laying around unprotected. On the other hand, regulations can be distracting, if not outright repressive (and depressing!). For example, think of regulations like SOX, which are not very prescriptive, and which gave rise to a renewed audit complex that, for a short time, tried to dictate unhelpful things to public companies.
That said, compliance requirements aren't going anywhere anytime soon. That creates a unique challenge for the GRC program. Learn the business first, and then find out how to introduce and integrate the mandated changes with as little negative impact as possible. The alternative is what we've all seen fail in the past: breaking out the hammers and jack-boots to forcefully drive home the "you must change" message. We're all part of the business, and our jobs are dependent on the shared success of the organization. As such, driving toward a team approach that encourages collaboration and cooperation will be far more useful than a dictated approach; and that means getting to know the business better than anybody else in order to identify opportunities for mutually beneficial improvement.
Wrapping Up...
Obviously, much more could be said (and, if you know me at all, you know that I could probably do just that!;)... however, keeping this as short as possible, I'll just leave you with this one final thought:
"Perfection is not attainable, but if we chase perfection we can catch excellence." -Vince Lombardi
Good luck!
P.S. - Are these solutions "uncommon"? Maybe not (especially with #3). Hopefully in another couple years they'll be mainstream and commonplace! ;)
