The Neverending Quest for IT Security

If you ever have a need to burn off some excess optimism, try taking a look through some of the statistics out there about success and failure rates for enterprise IT projects — it’s pretty ugly. Although specifics of statistic and survey data vary, studies have historically suggested failure rates as high as 75 percent for technology projects. That means it’s quite a bit more likely for an IT project to fail than succeed — including projects that don’t complete at all, as well as projects that have time, budget or quality “challenges.”

In general, this isn’t the best news — but those of us in information security should take particular notice of it. Why? Because security has the same challenges — it’s just more difficult to measure the failures.

Failure vs. Success in Information Security

With an IT project like an application deployment, software development project, or cloud migration — it’s easy to tell whether we’re in the successful 25 percent. That’s because a successful end state is easy to recognize.

For example, if we’re chartered with building a new application, we know we’re done when we decommission the old infrastructure and users are actively using the new system. Because the effort is time-bound, we can understand how efficient we were throughout the process as well: we can compare how long it actually took (and how much it cost) with our initial budgets to see if we met expectations or if we were off.

Security, on the other hand, is different: There’s no end-state where we can call ourselves “secure” and move on to something else. Because of this, gauging success and failure is difficult. It’s not that security doesn’t have the same challenges and complexities that other projects have — like resource availability, competing priorities, and implementation complexity. It’s just that it’s so very easy to assume we are doing well when we’re really not.

We can assume that we are doing well, but it’s important for us to note two things: 1) There are some pretty significant forces acting against us — forces sufficient to cause most IT projects to fail, and 2) These are forces that we have very little in the way of instrumentation to measure. In practice, this is a dangerous place to be — it’s like flying a plane in zero visibility without reliable instruments to provide guidance. It’s a place where we can’t stay long term.

Toward a Security PMO

Given these facts, it should be clear from a management standpoint why we’d want to change the model. The strategy that has worked most successfully in increasing the success of IT projects is the PMO (project management office.)

By building out formalized governance processes to standardize how IT projects are managed and run, a PMO seeks to contain the most frequently occurring difficulties that projects encounter: inadequate project management implementation (32 percent of project failures); lack of communication (20 percent); and scope/complexity issues (17 percent). By implementing a consistent, reproducible, and disciplined approach to project management, the PMO mitigates these issues and thereby drives down the incidence of project failure.

When it comes to security, though, much of what we do is outside the scope of the PMO. Sure, there could be potential overlap when it comes to discrete security tasks like deploying a new technical control or a new security system, but the daily management activities of security tend to be “distanced” or stovepiped away from the PMO. This leaves security at a disadvantage: The organization as a whole has invested in better reporting and governance through the PMO — but we don’t realize direct results in the security office.

We can seek to implement our own security program (or, depending on parlance, an “information security management system”), but that doesn’t always directly translate. For example, the reporting output from the ISMS might not be directly translatable into the management reporting and project metrics being collected by the PMO.

In the interests of building a better management framework for IT as a whole — and to realize the benefits that our organizations are trying to realize by rolling out a PMO in the first place, it’s incumbent on us in security to look for opportunities to tie what we’re doing into the broader structure of the management framework of our firm’s project management efforts.

Integrating Security

So, assuming you do wish to integrate security into your organization’s PMO, what are some strategies you can use to do that? The ideal case is to be involved from the get-go while your organization is bootstrapping a new PMO. However, that’s likely to be the exception rather than the rule.

The more likely case is that your firm will already have a PMO that doesn’t include security (or if it does, only marginally), and you’ll need to demonstrate a willingness to cooperate. This may mean voluntarily taking on documentation and reporting efforts that you didn’t have before you sought to integrate. If this sounds like more work than you might be doing currently, you’re probably right — but the benefits, in most cases, are worth it.

Integrating the work that the security office does into the PMO’s framework means that you understand the management framework that the PMO has set up and that you do your best to abide by it to the extent possible. This might include reviews and management approval along the trajectory of a project’s lifecycle; it might include gathering metrics about resource utilization and performance for particular tasks that you undertake; and it might include documentation of status according to a predefined format.

Specifics will vary, but starting with work that can be easily “projectized” (for example, time- and resource-constrained efforts like audits, deployment of controls, etc.) is likely to be a better choice than highly operational tasks that have no start or end date.

The benefits of finding ways to work with the PMO in this way — and allowing your projects to be governed using the same methodologies — are direct. First, you gain visibility into ongoing projects and their milestones. This means you know what the projects are and who owns them (not always a given for the security team) — from a very early point in the planning cycle. This gives you time to deploy specialized personnel (like application security team members) to evaluate and work with them on building a better and more secure end result.

Secondly, you can capitalize on upcoming projects to help forward security initiatives. For example, if you know about an effort to improve an existing legacy system, maybe some of that budget can go to helping alleviate known security problems associated with it that might not be directly addressed by the project team.

Lastly, by being involved in the PMO, you gain the same executive oversight that the PMO enjoys. Given the importance and visibility of the PMO in most organizations that take this seriously, that benefit can’t be understated.