In most organizations, project management is the mechanism in which everything is built.

Whether it is a complex data center, a custom application, or a new payroll process. Simply stated, it enables an idea to be turned into reality. This common framework provides the ability to guide an effort efficiently; ensuring that the objective is produced according to the required specifications, in a timely manner, and utilizing only the forecasted resources. Further, it provides an organization with the ability to measure the success or failure of any given initiative. Wow…that was a mouthful. Now that we have a common definition of Project Management, let’s discuss its value to security?

There are countless “touch-points” in which a security program can interact within an organization in an effort to improve the risk profile. A touch-point for your program for the context of this article is defined as any area that enables you to work together with others outside of the security program to reduce risk. Some examples would be through employee training, the internal audit function, or even the creation of a reporting framework. The value and efficiency of these touch-points often are derived from three primary considerations: the amount of risk they enable you to identify and reduce for the organization, how quickly they can reduce risk, and how many resources will be consumed by the creation and utilization of the touch-point. Using these three considerations, project management provides one of the most valuable touch-points that a security program can utilize. Let’s take a closer look.

The best time to reduce risk in an organization is before the risk is manifested. Creating a touch-point with the various entities that are responsible for the creation and construction of new elements within the enterprise allows for the circumvention of potential risks prior to the deployment of all new solutions. In situations where there is a solution that has an irreconcilable security flaw, compensating design features can be recommended to limit the probability of exploitation by that risk. Let’s take a minute to expound on this issue with a simple example:

The security program is participating in a project to deploy a new public website for the company. As part of the project, new servers are to be built. By participating with the project team, the security program has added the requirement that all of the operating system security updates must be applied prior to the server’s deployment into production. During the process, it is determined that one of the security updates cannot be applied without compromising the functionality of a specific web component. A detailed review of the security update reveals that its primary function is to patch a service that is unnecessary; thus presenting the team with a compensating control: disable the service. Reducing the risk in this manner accomplishes many of the considerations required to make a touch-point for the security program valuable. But more importantly, it was achieved in a proactive manner, reducing the risk prior to its appearance.

Upon analysis of the example, we see several concepts that are worth further discussion. The first involves that of a proactive position for the security program. Patching a server prior to deployment is a fundamental security element designed to reduce risk. However, would the project team have introduced this process without the participation of the security program? Maybe. Would the project team have addressed the need for a compensating control? Probably not. By participating in the project team, the security program is not just hoping for the inclusion of security considerations into the product, it guides their development. Once again, this risk reduction is accomplished in the most efficient manner; before the server ever reaches production. But what about the resources required in utilizing this “touch-point? “

The answer to this is often a bit more complex than it may seem at first glance. It is common for a security program to believe that reducing risk during the development phase is too resource intensive for their program. What is often not considered though is that most of the time it is much less resource intensive to correct a security flaw before rather than after it is in production. Most budgets often do not consider the costs of the latter participation in their forecasts, thus underestimating the true cost of resources. It is really a “pay me now or pay me latter” kind of situation, yet most often do not address it in that way.

Aside from the reasons described above, there are also some qualitative benefits for a security program that uses project management as a touch-point. The most important of these is the proactive position that is achieved through participation in formal project teams. Even in situations when a risk many not be correctable, the awareness of the risk itself is a victory in that it eliminates an “unknown” from the environment.

Another benefit is that formal project management often provides a strong framework for roles and responsibilities. This is crucial since the role of security is often misunderstood by many within an organization. A highly defined role for security can help alleviate friction between the security program and the rest of the organization.

The final point that we would like to make is that it is easier to build a strong relationship with others within an organization when you participate in the process, rather than solely identify problems post-facto. No one likes a “Monday Morning Quarterback”; it is much easier to avoid this title when you are not always identifying issues after the fact.

Though every security program and project management office is different, identifying the synergies between the two can be the key to enabling your program to reduce risk quickly and efficiently. Hopefully, this article has demonstrated the importance of project management to a comprehensive security program. Though the Project Management Office is one of our favorite touch-points, there are many other places to look within an organization. It may be easier to identify these areas by thinking in terms of “Before,” “During,” and “After.” This touch point is obviously a “Before.” Covering touch points that are a “During” or “After” is another article for another time.