Secure project management is a concept that blends the needs of project management and security.
For the purposes of this article, project security should be thought of separately from product security. Security, as it relates to project management, is defined by the need to protect the confidentiality, integrity, and availability of project information, which can include data from the following sources: risk, scheduling, costs, communications, contract information, staffing, and procurement. Organizations will have differing needs to protect this information depending on the project and organization. An intelligence organization may have a need to protect all of the information associated with a project whereas a construction company may want to only protect its contract or procurement information.
The discipline of project management was borne out of the construction industry and has become formalized over the past few decades. Security and project management are both relatively young professions. Today, especially in IT and increasingly in other industries, security is becoming a paramount concern for project managers. What is most distressing is that there is not a standard, guideline, or methodology that deals with security of projects. According to the Project Management Body of Knowledge (PMBOK), a project is a temporary endeavor undertaken to create a unique product or service. A project may also have a unique set of security challenges that an organization may never have encountered or envisaged and that test the bounds of organizational policy.
The PMBOK is the de-facto standard for project management. The PMBOK applies to most types of projects and is applicable and relevant to projects that send people into space and those that build homes. Unfortunately, the PMBOK does not address the area of project security. It is left to a project manager to define the security requirements for how the project team: communicates, separates duties, handles information, responds to security incidents, and stays current with regulations affecting the project.
Project-based organizations, such as government contractors, may find it difficult to propagate corporate security policies and procedures through all projects, project team members, and subcontractors. These project teams are often spread out across a wide area in different buildings or possibly different states, making the job of communicating security policy exceptionally difficult. Project-based organizations have traditionally relied on project and program managers to take responsibility for the security of the projects they manage. Project managers that contract to the Federal government have the additional burden of staying current with new security requirements coming from Congress, the Office of Management and Budget, the National Institute of Standards and Technology, Department of Defense, and the Director of Central Intelligence. Project managers also have to align their project with the security requirements coming from the Government agency they support.
Projects are becoming progressively more reliant on information and information systems. Often these systems and their applications contain security flaws and vulnerabilities that, if exploited, can have a devastating affect on the success of the project. The levels of confidentiality, integrity, and availability required for project information varies depending on the project, product, and customer. Project information can vary from unclassified to Top Secret and everything in between, each requiring different classification, handling, storage, and destruction restrictions.
Security is, at its root, essentially a people problem. What is important to take from this statement is that people are a security professional’s most powerful resource in protecting information. For intelligence community projects the difference between success and failure may be the security practices of each project team member. Likewise, a project manager should leverage his project team to increase project security by making everyone aware of their responsibilities and why security is important to project success. In this respect, security becomes an input to communications planning. Often, especially in the intelligence community, how information is communicated is as important as who receives the information.
Project managers should document the project security requirements in a Security Management Plan (SMP). Security management should be a facilitating process in the PMBOK due to its importance in project success. Security cuts across all of the process groups of a project: Initiation, Planning, Execution, Controlling, and Closing. Each process group has its own unique security issues, i.e. the security issues faced in the initiation phase will not be the same as those faced in closeout. The SMP consolidates the project security requirements in one document that can be used as a reference by project team members throughout the project life cycle. The SMP is a living document and as project scope changes then the SMP may change also. An information system developed initially as an unclassified system could be changed to process classified information which would require considerable changes to the SMP and how the project is managed as a whole.
The inputs to the project security management process bring together key project information such as: the Project Charter, Risk Management Plan, Work Breakdown Structure, Communications Requirements, and Scope Statement. Security-related information is also included such as: the organization’s security policies, defined roles and responsibilities, regulations, legislation, and standards. Other important information that will serve as inputs to the SMP are historical information and expert judgment. The inputs are designed to provide everything the team needs to develop the SMP.
The tools and techniques are applied to the inputs to produce the SMP. Paramount among the tools and techniques are document reviews, interviewing, planning meetings, and benefit/cost analysis. Project security controls contemplated for the SMP should be subjected to a benefit/cost analysis prior to acceptance. The project manager and stakeholders may choose to accept the risk of not implementing a project security control as a result of a benefit/cost analysis. Once the tools and techniques have been applied to the inputs then the SMP can be developed.
In the world of Government contracting there sometimes exists a dichotomy between the contractor’s and the Government agency’s security policies. The SMP should make it clear what organization’s security policies and procedures will be used to securely manage the project. Often, there will be a medley of contractor policies, client policies, and regulations that comprise the project security anthology. The SMP should also include a list of laws and regulations applicable to the project. These issues are especially important when projects include classified materials that must be handled and stored according to Federal standards. Making stakeholders and project team members aware of the standards and their responsibilities is an important concern early in the project. Project managers of sensitive projects may want to consider a series of project security awareness seminars aimed at stakeholders and project team members that focus on topics such as information handling, need to know, and information classification.
Projects generate information. Information handling is foremost among the security concerns associated with a sensitive project. A given project will generate information of different sensitivity levels. Risk and cost information may be more sensitive than quality planning information and therefore will have different handling, storage, and destruction requirements. The use on the project of mobile devices such as laptops, wireless devices, PDAs, and cell phones should be clearly discussed in the SMP. In some Government agencies the association of a person’s name with a phone number is considered classified information and therefore should not be entered into a team member’s personal cell phonebook. The project team should be made aware of these issues early in the project to avoid security incidents and/or project failure. Another consideration of information handling within the project is domestic/international travel. Project team members should know their responsibilities for securing information when traveling.
The concept of “need to know” is important in intelligence community projects and, to a lesser extent, in private industry. The SMP should address the issue of need to know as it relates to the project’s unique set of circumstances. The issue of subcontractors and their level of exposure to project information should be addressed in the SMP. The PMBOK stresses the need for collaboration and communication among the project team; however, compartmentalization and strict need to know guidelines are a necessity in the intelligence community. These issues underscore the occasional dichotomy between widely held project management principles and information security principles. Information dissemination restrictions within a project can improve security but can also increase the likelihood of project failure and/or information compromise. Project managers on classified, compartmentalized projects have an especially difficult job integrating security into their projects. Large, multi-million dollar projects may consider including a Project Security Officer (PSO) position on the project team to monitor project security. Project management software can be configured to enhance project security. Microsoft Project Enterprise includes settings to restrict the permissions of project team members. As with other aspects of security, technology solutions are only a contributing factor to project security.
The SMP should include incident response information and what constitutes a security incident. Incident response analysis is a tool and technique that is used to develop the SMP. Project team members should be made aware of their responsibilities when a security incident occurs. The SMP may specify detailed response actions for a given security incident such as project cancellation or postponement.
Project managers are entrusted with precious resources from their organizations such as time, money, and personnel. They are expected to be familiar with the basic concepts of information security and how they are applied within their projects. Today’s business environment has become more competitive and security conscious. Corporate officers are being held accountable for security in their organizations. It is no longer acceptable to promote the best engineer to project manager and expect projects to be managed successfully and securely.
The old adage applies to project security: What’s worth doing is worth protecting. Organizations expend enormous resources performing projects and yet have no standard to securely manage their projects. A lack of project security management represents a significant risk to project success. Today’s emphasis on homeland security and information assurance necessitates the need for a holistic approach to security which not only includes the product or deliverable but also the security of the project that produced it.
Dan Emory is a Senior Security Engineer at NetSec, a leading provider of managed security services for global corporations and federal government agencies.