Thoughts on How We've Gotten Here

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.