Thoughts on How We've Gotten Here

| 4 Comments | 1 TrackBack

You might be wondering how it is that we got to this point in industry evolution. It seems like very little has actually improved over the past decade+. Sure, there are a lot more products out there, but many seem to fall short on delivery (shocking, I'm sure), and the threats have only grown exponentially in number and skill. If you don't think you're pwnd or on the verge of being pwnd, well, I'm here to tell you that nothing could be further from the truth (FUD? maybe, but only if it's not true!).

There's a lot of history in this industry, despite the fact that we seem to keep reinventing ourselves every few years. The irony is that, the more things change, the more things stay the same. That being said, while I'm sure you all know these things, I think it bears covering some of the history, at least as I've seen it first-hand over the past 15+ years.

In The Beginning...

When I started my career in IT and infosec some 16.5 years ago (seriously? almost 17 years? sheesh!!), we were just starting to network everybody. I very clearly remember pulling cable, terminating cable, installing NICs and drivers into Windows for Workgroups PCs, including installing Trumpet Winsock (which reminds me: go thank its creator!). Back then, our main concern was with viruses that were communicated machine-to-machine either via bad email attachments or infected boot sectors on floppy disks.

Our primary focus for security was around basic anti-virus and OS hardening. If you had a firewall, cool, if not, then bastion host it was! Eventually web servers became commonplace, and then CGI gateways were deployed, typically leveraging PERL modules to run things server-side... and then it all exploded from there. Suddenly you had basic web applications, forms, etc., that were exploitable and spewing data everywhere. In the span of about 5 years, things grew at an alarming rate, with very little security could do to keep pace... it became an outlandish firefight, and we were losing.

Then Came The Auditors...

Starting sometime in the '90s (maybe earlier) the Big N accounting firms added IT audit as part of their normal financial audit activities. The objective at the time was to establish via the IT audit process that the financial systems were "trusted," which would then allow the financial audit to just use automated controls built into these systems to run their activities. Unfortunately, the requirements were fairly stringent, and thus systems rarely, if ever, achieved that "trusted" status.

The real driver behind this push for "trusted" status was the bottom line. Most audit firms sign mulit-year deals with their clients, with only nominal rate increases year-over-year. It's a fairly common practice and good for business. However, most companies are under pressure to continue increasing profitability each year, which becomes a bit of a challenge when you're essentially on a fixed income with your clients. Enter automated controls (in the audit world). If you can rely on your financial systems, then you don't have to allocate as much time or resources to perform the financial audit, which means reducing your overhead on the project and, as a result, your profits increase. The economics are simple and straightforward, really.

However, at some point we got off track. Groups like ISACA and the IT Governance Institute (associated with ISACA), which have historically grown directly out of the IT audit industry with Big N firm backing, started taking things a bit farther. Rather than simply being satisfied with optimizing audits to help facilitate the financial audit, now IT audit became an entirely independent beast. We started seeing SAS-70 applied everywhere for everything (even though it really doesn't tell you much of anything, since it's not actually tied to any specific security or governance requirements - it's merely a standard process for performing an audit).

Out of this environment came COBIT, which was initially postured as an audit framework that, if implemented by the clients, would help further reduce IT audit costs. At the same time, the "trusted system" criteria went by the wayside, reducing the bar for making use of automated controls. The cumulative result has been increased dictation of approaches and requirements by auditors to the business without having any real stake in the well-being of the business.

Scandals+SOX: The Tipping Point

The real tipping point for this shift in the IT audit industry, and it's resultant impact on the security industry, occurred in 2000-2002 after a variety of accounting scandals (Enron, WorldCom, and Tyco) rocked the U.S., leading to the creation and implementation of the Sarbanes-Oxley Act of 2002. It was at this point that the regulatory environment sharply shifted to the compliance-driven mentality. The Public Company Accounting Oversight Board (PCAOB) was created, and it immediately aligned itself with the American Institute of Certified Public Accountants (AICPA) and, by extension, ISACA.

A couple things happened almost immediately... first, I saw external auditors start aggressively ramming COBIT down the throats of their clients... they would literally come into an environment that they knew nothing about, which they visited at most once per year, and would tell businesses "you have to implement COBIT as part of SOX compliance." It was one of the most ridiculous and egregiously incorrect things I'd seen in my career. COBIT has never been mandated in any legislation (moreover, if something was going to be mandated, it's far more likely that it would take the form of the COSO Enterprise Risk Framework).

The truly irritating thing that would happen next, though, was that execs and internal audit teams - who also didn't really understand the internal IT or security landscape - would start parroting these comments from external auditors. Fortunately, when pressed, these IT auditors would not generally hold their ground on this point, and would eventually relent and admit that it may not be the best approach for our organization.

The second, and more significant, impact of SOX was the sudden shift to the compliance-driven mindset. GRC was soon to follow, again coming largely from these Big N audit firms who were looking for ways to shrink overhead costs and find opportunities for additional "consulting" (coming out of their audit practices). The compliance-driven approach to "security" seems to have come into its own as a direct result of SOX and the related fall-out, and it's only gotten worse over the past decade, thanks in part to adding PCI DSS into the mix (another regulation of dubious purpose).

Differing Viewpoints

One of the more interesting debates that has arisen over the past 10+ years has been over core approaches to infosec. Ultimately, you have about four main viewpoints that enter into consideration.

* Auditors: As already discussed, the auditor viewpoint has shifted from the "trusted systems" mindset in the '90s that had been oriented toward supporting the financial audit to the compliance-oriented mindset that we see today. This viewpoint tends to be top-down in nature and is often aligned with the CFO or other governance-minded interests, though rarely with technical executives. It's often derisively referred to as "checklist security."

* Security People: The security industry is largely dominated by discourse from the security perspective (shocking!). This viewpoint tends to diverge around the exact preferred approach (more below), but for the most part we get a healthy dose of threat research, vulnerability research, hands-on technical testing, policy, architecture, etc. This viewpoint tends to use a very bottom-up approach, and is most often aligned with IT (for better or for worse).

* Ops Folks: Or, maybe IT folks. This group is operationally focused, which means the viewpoint is by nature very bottom-up. Their mission is keeping things running as best as possible. Unfortunately, there's a gulf between them and senior management, which can lead to major problems. They don't necessarily like many of the things that security people will require, but they also don't generally like the auditors, since in both cases these distinct groups will require more work for them.

* Execs / Management: It would be foolish to omit our puppet masters. ;) In all seriousness, though, this top-down viewpoint tends to be oriented toward business administration and does not, on average, care too much about technical (IT) details. Unfortunately, this is where major communication breakdowns will occur. They tend to understand the auditors better than the security or ops folks, which tends to lead to more problems than it solves. If there's one area where we in infosec should be investing our energies, it's in finding creative and effective ways to inform and educate executives without asking them to change what they're doing or to revise their focus.

Incidentally, one perspective I've not represented here is that of the "risk managers." I'm not convinced that they are, or should be, their own distinct viewpoint, or if they fall under a combination of security and executives (depending on org). It is, however, worth keeping them in mind.

Taking these viewpoints into consideration, it's then interesting to look at where some of the battle-lines have been drawn, particularly over the past decade. There are three general groups that are worth noting today:

* Enterprise Risk Management (ERM): A subset of the populace believes in a risk-based approach. Such an outlook is worthwhile because, at it's core, business is risk-oriented (though they're talking about financial and legal risk, as well as things like opportunity costs, vs looking at information risk). ERM has matured a lot in the past decade, in particular as it has moved away from simplistic ALE-based analyses. Most ERM practices have adopted some quantitative analysis methods, and we're starting to see evidence-based risk management emerge as the preferred hybridized approach.

* Governance, Risk, and Compliance (GRC): In this context, GRC tends to be very narrowly defined by the audit folks. In fact, if you look at audit-grown GRC materials and programs, they're almost completely compliance-centric (this is not the "GRC as a discipline" that I wrote about previously). In conversations, then, the focus is on what your regulatory requirements are and how best to meet them. The auditors can then come in on a regular basis, run down the list, check the boxes, and life is grand. They don't generally look much at risk, at least not in the way and to the same degree as ERM folks would. Risk management in the GRC context is really just a basic due diligence approach for prioritizing workload (something, incidentally, that PCI DSS even advocates with their official "prioritized approach"). To the audit-originating GRC crowd, the 'C' tends to be more important than the 'G' or the 'R' even though we in security would argue that just the opposite should be true.

* Unified Compliance (UC): There's another middle ground in all of this talk, and it's what we've come to think of as the "unified compliance" crowd. Under unified compliance we're looking at a very sound approach to central requirements management and mapping, which then translates into interlaced and correlated control frameworks. UC is not really at odds with either the ERM or GRC camp, and in fact helps out in both areas (most GRC platforms, for example, leverage a UC approach - typically from IT UCF). It's unclear, really, if ERM makes enough use of UC, but they're very compatible in that they both tend to see the worlds through the filter of building frameworks, whereas GRC is often focused almost fatally on compliance initiatives. The UC folks do tend to dislike the compliance-centric approach of the narrowly-focused GRC crowd, because such a focus overlooks the importance and value of frameworks.

Differing Approaches

I've already made allusion to several of these points, but I think it's worth spelling them out in a bit more detail. We're probably all familiar with them, but it's still good to call them out and discuss them. It's intriguing to me that there's much debate about one approach over another as I think that, with a couple exceptions, the best approach is readily apparent. Unfortunately, we're living through a transitional period in time where IT is really still in the "emerging" category, which means that senior management is still not fully comfortable with it. My guess is that it will likely be another 25 years before all of this is considered mainstream common sense.

* Compliance-Driven Security: I've touched on this several times throughout the post. In general, the compliance-driven approach to security starts with regulatory requirements and simply focuses on ticking off those check boxes. Unfortunately, these approaches are rarely comprehensive in nature, leaving many holes still to be exploited (e.g. Heartland Payment Systems). Just because your environment can cleanly pass an audit does not mean that you've done nearly enough to secure your environment. By way of comparison, consider a car passing a limited multi-point inspection that doesn't take into consideration a leaking fuel line. Would you consider it to be safe? Probably not, and yet, unless the checklist covers "ensure fuel line is not leaking," then it'll pass without issue. A compliance-driven focus will only lead to deficiencies and failure in the (near) future.

* Risk-Driven Security: For 10 years we've heard a lot about leveraging risk management to drive our security programs. And, for the most part, this isn't the wrong thing to want. However, that said, information risk analysis is still in its infancy, and there are still many detractors. Whereas actuarial sciences are generally accepted without question, inforisk does not enjoy such a degree of acceptance. Until risk analysis methods mature a little further, and until we see evidence-based risk management become the mainstream approach, we're simply not going to get enough traction. Interestingly, if you consider v2 of my TEAM Model, you'll notice that risk is a key part, but it's not the only part, just as requirements (a nod to compliance) are a key part, but not the only part.

* Ops-Driven Security: We've seen this approach in effect for probably 20 years, and it's simply not been overly effective. Using a bottom-up operational focus can be fine, to a point, but eventually you need executive buy-in and support. The ops-driven approach focuses largely on securing the environment using technical solutions, such as firewalls, identity & access management, SSL, encryption, etc. There's nothing wrong with this, per se, but there are limitations. More importantly, ops-driven security tends to be susceptible to manager bias, which can lead to significantly wasteful spending. Moreover, making decisions that are strictly focused on operational needs without having a broader perspective on the overall environment and associated impacts to users and business processes can be downright devastating.

* Process-Driven Security: I started advocating for process-driven security around '99-2000. In my view of things, too much money was being wasted on ops-driven security efforts, while at the same time people loved to talk about security policies that meant little to anybody. These things were not successful or useful. Unfortunately, ITIL became popular a couple years later, which corrupted the vision of process-driven security, and then things went completely off the rails as compliance-driven security began to come into its own. To this day, I still strongly believe that we should be investing time and energy into processes rather than policies, but I'm afraid it's an uphill battle. Perhaps the most telling sign of the demise of this approach is how process has become bureaucracy, such as in the federal sector. Deming is, I'm sure, spinning in his grave.

* Networked Systems Survivability ("survivability"): The latest and greatest thinking in infosec these days is that we should shift away from this faulty and failed zero-sum approach and instead change the rules altogether to focus on survivability. Overall, I think that this will emerge as the preferred approach in most areas, though it does have a few limitations. For example, once someone makes a copy of your protected data, then there may be little you can do to reduce the impact of that loss. Nonetheless, from an infrastructure and services perspective, survivability absolutely makes sense, and will, as I've noted, likely become the standard approach. In this security model, you put a premium on detection and response, with the goal being to minimize the negative impact of an event so that operations can continue despite degraded conditions. There's still a component of defense that combines risk-driven and ops-driven approaches, taking reasonable steps to protect oneself from attack; but, the philosophy openly acknowledges that the asymmetric manner of threats makes complete protection impossible. As such, plan for failures, maximize detection and recovery, and build systems that fail in a reasonably predictable and safe manner. Add in a healthy dose of processes to cover response so that hard decisions are already made ahead of time, rather than relying on making good in-the-heat-of-the-moment decisions during an event.

Closing Thoughts

It's interesting to look at where we came from to better understand how we've gotten to this current point in infosec evolution. What's particularly interesting to me is that I think we're now on the cusp of entering the 2nd generation era of GRC, wherein the narrow, compliance-centric focus created by the audit firms will start to erode and become replaced by something more comprehensive and useful. It's very clear that no one approach is necessarily best on its own, but that, rather, we need to look to hybridized approaches like survivability that seek to maximize the best in these various approaches.

Case-in-point, there is a place for leveraging a compliance-driven focus, but it's not as part of a GRC program. Rather, the compliance focus should be split between routine audit & assessment activities and defining the requirements that are provided as input to governance and risk analysis activities. Ultimately, I think that we'll see decision analysis emerging to supersede much of the risk analysis discussion, using various risk analysis techniques (e.g. evidence-based risk analysis) as an appropriately weighted input for overall corporate governance.

At the same time, we need to actively work to keep evolving and maturing these various disciplines. We need to actively resist the undue influence of the big audit/accounting firms and instead insist that they fit within our models, rather than letting them continue to run roughshod over organizations with their audit- and compliance-focused approaches that benefit few but them.

For me, it's an exciting time to start getting a foothold in GRC (the discipline) as I think the timing is right for initiating change and helping organizations launch into the next phase of growth and management. Hopefully others will join me in welcoming the opportunity for evolution such that we can jump to the next curve.

1 TrackBack

I've already written a bit about how we've gotten to where we are today in the infosec industry, as well as having talked a bit about my definition of GRC as a discipline. However, I think there's value in taking... Read More


This is actually one of the better articles on the various blogs I read. While I don't agree with every opinion here it is directionally very accurate. Good work Ben!


Excellent post. I cut my teeth in 94. In the 90’s and early 00’s, security wasn’t a requirement and systems/tools weren’t widely available to develop secure solutions. I remember session state via hidden form fields, NT (restrict anon…), win2k with everything enabled, etc. By 03, we had the capability to develop resilient solutions and incidents to enable educated tradeoff decisions.

I think you’re missing the most important approach: process maturity. SDL, change mngt, device config, data protection, education. The tools are there for security to be part of the cost of doing business vs an additional tax. The desire to measure processes and hold stakeholders accountable is lacking. The VZ breach report shows what, 90ish% of breaches from fundamental control lapses. Execs who measure process maturity, metrics, enforce accountability, and leverage evidence to make informed business decisions are successful.

So if process maturity is the answer, why aren’t more folks doing it? In my experience, it’s difficult to prioritize the investment when executive management doesn’t require mature process. Leadership achieves goals. It’s rare when a leader equates spending resources on process maturity as the optimal path to make money.

I think we’ll continue to vacillate until incidents reach a level where leadership is forced to act on the root cause.

The state of compliance is another symptom. Audit’s job is to compare actual vs. policy. For compliance to make a difference, policies should include mature process reqs (SLA’s, metrics, service catalogs, defined roles, failure mode analysis, compensation carrots and sticks). Now that’s an audit report I’d like to read.

On a positive note, I see more folks heading in this direction. It’s often new CISO/CIOs who have exec support and the opportunity to affect change without self-incrimination.

I love security because the technology evolves constantly, even though the problems have been the same for 7 years. It’s also incredibly rewarding to see morale shift as a team moves from reactive to proactive. One of my favorite metrics as a manager was the % time bitching during happy hour. My secret way to measure process maturity :-)

Thanks, Jared,

I agree with you, to a point. However, as noted in the piece, process-driven security has gotten a bad rep because it's turned into ugly bureaucracy that actual detracts rather than adding value. Moreover, organizations (or, sr+exec mgmt) lack the willpower to mandate process definition and improvement. This is where I believe survivability comes into play. It puts the focus on the financials with an emphasis on facilitating the continued existence of the business. That much of the implementation supporting survivability ends up being in process maturity is not coincidental. ;)

My belief is that it will take until we're completely through the current boomer generation before the real changes start sticking for good. I think Gen X and younger are far more comfortable with IT, the Internet, and all its trappings; in ways that my parents' generation simply can't grasp. Due to longer lifespans, I think it'll be another 20 years before we're fully through this phase and into the next and beyond.

I'm glad to hear that you think folks are moving that way. I would generally agree, though change is hard and simply takes time. My hope is that we'll be able to "jump the curve" and finally make up a little of the lost ground over the course of the next decade or two.

Thanks for your comments!


Having some internal auditor background and working in infosec consulting at the moment, I literally enjoyed every word of the post.

Thank you very much.

About this Entry

This page contains a single entry by Ben Tomhave published on March 30, 2011 3:36 PM.

Lord Kelvin Was Wrong was the previous entry in this blog.

GRC: What Does It Mean? is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Monthly Archives


  • about
Powered by Movable Type 6.3.7