Tuesday, June 5, 2012

It's Time to Retire "Security" From Our Lingo - The Falcon's View

The future of security is that it shouldn't have a future; at least, not as its own dedicated profession. Rather, security is merely an attribute of operations or code, which is then reflected through appropriate risk management and governance oversight observations and functions. That we still have dedicated "security" functions belies the simple truth that creating separation ends up causing as many problems as it solves (if not more).

This is not a new line of thinking for me. Nearly 3 years ago I asked whether or not a security department was needed. At the time, I was working as a technical director of security for a SMB tech firm, and as the first dedicated security resource, I had concluded that building a team wasn't going to be fruitful. Rather, it made sense to jump right past the "dedicated security team" phase and go right to the desired end-state.

The Security Lifecycle

I've used this example anecdotally in talks over the past year, but I think it bears relaying here, too. The rise and maturity and "security" practices seems to follow a consistent lifecycle. While there is often a point where having a dedicated security resource or team is useful, there also seems to be a law of diminishing returns. More importantly, having dedicated resources seems to address short-term organizational deficiencies, rather than solving persistent, long-term problems.

In the beginning, we had IT, and it was by-and-large a dedicated, separate function. Out of this grew an environment of sheer hubris wherein business people came to the IT gods and supplicated, asking for resources and assistance. However, the walls of this sanctum began to disintegrate in the mid-90s with the rise of the Internet and the mainstreaming of PC technology. By the turn of the century, IT had become routinely accessible to everyone, and a few years later - thanks in large part to innovations from Apple - technology became demystified and essentially commonplace. No longer can IT personnel play the role of demigods demanding reverence and ritualistic sacrifice. The day of the Bastard Operator From Hell are essentially gone.

Similar to the rise and fall of the IT-as-demigods culture, so has security followed a similar trend. Out of the IT ranks arose dedicated security professionals - many of whom being extremely smart, cynical, and paranoid - who in turn treated IT folks the way that IT historically treated business peers (see Jimmy Fallon's portrayal of Nick Burns, Computer Guy). I'm sure many of you can think of multiple "ID-10-T" errors attributed to "stupid IT people" over the years?

As security resources emerged, it quickly became necessarily to consolidate them into dedicated teams or departments, oftentimes taking on an increasing amount of varied responsibilities ranging from operations to governance. Unfortunately, given the origins in IT, the majority of these teams remain(ed) buried in IT departments, or reporting up through CIOs, with a heavy operational focus (not that this is bad, per se - it just changes how "security" business is done and focused). Fast-forward to modern times, where much of security needs to be driven by risk management programs, and we quickly see a disconnect forming.

The natural evolution, which we've been seeing evolve over the past few years, is to get away from dedicated security teams almost altogether. The first target for transition is to remove operational security duties and dissolve them back into IT operations. After all, operations is operations is operations, and there's really no need to maintain duplicate staff or infrastructure. Second, there are typically a couple areas remaining: incident response and GRC. The incident response team can oftentimes remain in IT, close to the technology that it's supporting. This is logical and easy. However, GRC programs (and, here we're talking about GRC as a discipline, not as a tool or platform) cannot and should not remain buried in IT organizations. Instead, they need to be elevated into the business structure, oftentimes reporting in with other risk managers, such as under a General Counsel (Legal team), CFO, or business analysis team.

It seems to me that this is all widely held and accepted today. Many organizations have already moved to this end state where security-related operations have been dissolved back into IT departments/teams, with oversight functions elevated into GRC programs that pull together risk management, policy, audit, and various related testing and data analysis duties. However, if this is the case, then I wonder why it is that we're still talking about security? In fact, it strikes me as sadly ironic that the politicians and the federal government seems increasingly incensed with "cybersecurity" just as those duties return to ops. Instead of focusing there, where should they be focusing?

Supplanting Security With Reliability and GRC

Last month I heard the inimitable Dan Geer speak on the future of security at the Rocky Mountain Information Security Conference (RMISC) in Denver, CO. During his keynote he discussed the need to do away with "security" in favor of terms that better describe the desired outcome. In particular, he stated that he views security as being an attribute of reliability, and encouraged people to move to a mindset focused on reliability - which, incidentally, has strong roots in engineering - and get away from the sentiment-oriented term "security," which is often meaningless.

I think Geer's idea is excellent, and it further supports the lifecycle described above. Moreover, when it comes to defining metrics for IT operations, we already understand reliability and how to measure it. Sure, there are additional considerations related to the traditional cause of security, such as from all the additional data sources. But, for the most part, this is an easily understood concept. And, more importantly, focusing on reliability aligns with networked systems survivability and the imperative for business survival. Moreover, it also better aligns with risk management approaches, which are themselves focused not on eliminating all risk, but on managing risk within acceptable limits so as to optimize business performance.

This shift in approaches also helps address the question that Michael Santarcangelo recently asked in his CSO Online article "Is your definition of security holding you back?" We oftentimes have difficulties managing security because everyone is not on the same page, which in turn relates to the fact that we aren't generally speaking the same language. Dumping the confusing term of "security" (or "cybersecurity") in favor of reliability and GRC would go a long way toward resolving those concerns.

So, What's My Job?

Making a wholesale change like this is not necessarily easy, but it is necessary. Thinking in terms of my TEAM Model, I think this necessitates a revision, which I believe changes the first two component areas to GRC and Operations (or IT Operations), as depicted below. In terms of the impact on organizational structure, this translates to having a strong operations team/department, elevating a GRC team into the business leadership to help with decision analysis and support, and enhancing quality and performance programs like audit, penetration testing, and code analysis, to have an equal say. At the end of the day, your job should fall under one of those buckets.


At the end of the day, this is not so much about "security" going away as a need, but it evolving and maturing into something more useful. As long as we continue talking about security, then we continue to perpetuate myths that are counter to our desired objectives. Instead, shifting to GRC and reliability as the core focus, we can then leverage well-established engineering practices, as well as help mature them to better account for all relative attributes. This imperative further solidifies when considering modern challenges like "big data" wherein we already have decent analytical islands, but still lack a consistent second-tier level of analysis to pull it all together. Operations teams can have the luxury of working with siloed analytics, but the business as a whole cannot, which necessitates an elevated GRC program that helps provide better quality data to decision-makers. All of these changes culminate in better-informed leaders who can then make decisions that are more defensible legally, which in turns helps improve the risk management posture of the business; a true win-win.

blazing saddles lsu alabama lsu game lsu game beezow doo doo zopittybop bop bop cordova demaryius thomas

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.