ISO 27001:2022 A.5.8 Information security in project management

by Pretesh Biswas

For a project manager, a bad week might go something like this:

• You open your email and see that one of your technical resources has inadvertently forwarded a network diagram to a competitor of your client.
• You’re rolling out server builds during a weekend Go-Live and you realize your inventory spreadsheet is corrupted.
• You’re about to walk into a meeting with your project sponsor and discover the laptop where you’ve stored the presentation you’ve been working on for three days has bluescreened.

Each scenario represents a security failure, a failure to maintain the CIA triad of information security:

• Confidentiality
• Integrity
• Availability

Project managers have special interests in all three components of the CIA triad. IT projects warrant special consideration for maintaining confidentiality. The business case for any IT project will include strategic business goals whether the project delivers an exciting new technology or a mundane but essential upgrade to maintain enterprise productivity. IT project documentation also frequently includes intimate details of network and systems architecture that presents an attractive target for industrial espionage and hackers. Failed changes to IT systems can also impact availability and integrity. Special attention to backups, back-out plans, and security risks early in the project will pay big dividends when project rollout leaves little time to consider how to undo the changes made during a Go-Live or react to an unexpected risk occurrence that may cause systems to go down, or cause data loss, corruption or breach. Project managers should develop plans to mitigate risks to the project documentation and methodology itself. Do you really want to go into that big meeting with the project sponsor and not be able to access crucial files or find that the most recent version of the project issues log was overwritten with the previous week’s version?

 A good week for a project manager might look something like this:

• You open your email and see that one of your technical resources has flagged an email containing a network diagram as confidential, preventing it from being forwarded to a competitor of your client.
• You’re rolling out server builds during a weekend Go-Live and you realize your inventory spreadsheet is corrupted. Your change window gives you time to retrieve a pristine copy of the inventory from backup, verified with your document versioning system, and your team completes the builds successfully.
• You’re about to walk into a meeting with your project sponsor and discover the laptop where you’ve stored the presentation you’ve been working on for three days has bluescreened. An authorized member of Operations Staff you’ve been working with closely since requirements gathering pulls up the file in the encrypted cloud storage backup for you and the presentation continues as planned.

PMs are not expected to be security experts, but by including security considerations in every phase and process of a project, especially in initiating and planning, communications and deliverables, PMs have the opportunity to deliver more secure systems in a more secure manner.
 Information security is to be addressed in project management regardless of the type of project.

1. Understand what is “PROJECT” for your organization. Simple examples could be:
   • Implementation of DLP, Anti-Virus, Firewall, BYOD or any technology solutions
   • Buying a new office location
   • Develop or procure new business application
   • Adding a new client or new process (depend upon size and complexity)
2. Understand the business & security purpose of the PROJECT: You cannot start the project unless you know the Value (Benefits) project is going to contribute to the organization
3. Understand end to end project flow from the respective owner. This could be data flow diagram, application architecture, network diagram, input-process-output etc
4. Define security baseline for a particular project; Complete the Project; verify security baseline (project risk management)
   • Define security baseline for a particular project→Complete the Project → verify security baseline (project risk management)

Let’s take an example of “Implementation of DLP”

Purpose: Prevent organization’s IPR and customer’s information from information leakage.

Project Understanding:

• Organization has developed/customized an internal application for processing customer’s information. Protection of application source code and customer information is utmost important
• Customer sends input file through FTP, project user downloads file from FTP and upload on application to process. There are 50 users working on this project and has access to FTP and application. Once processing is completed, the project user sends and output file back to the customer through FTP.

Security Baseline for DLP Project

• Data stored on Code Repository shall not go out of the organization (through any medium E-mail, FTP, internet, file upload etc)
• Data stored on “File Server”→ Folder Name “Prising” shall not go out of the organization
• Any data stored on “DB and App Server” shall not go out of the organization.
• User shall be able to send data with file extension .xml only
• Any attempt to information leakage shall be logged in DLP server
• Any attempt to Source code leakage shall be alerted to management immediately through email or SMS

Verification of baseline

• Security professional to verify the compliance of each and every security baseline, in case there is any non-compliance; same shall be documented in risk management methodology.

For example in this example, customer data (input and output file) can be leaked through FTP as FTP is accessible from anywhere

Project Management

Project Management Body of Knowledge defines project management as the Application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Project management is accomplished through the use of processes such as: initiating, planning, executing, controlling, and closing. Project management involves temporary assemblage resources to complete a project. Some projects are iterative and occur regularly.

• Benefits for organizations that make project management skills a priority include:
  • Implementation of a methodology
  • Improved planning
  • Less ambiguity about roles
  • Simplify project monitoring
  • Early identification of deviations in quality, time, or budget
• Generally, the project has deemed a success when:
  • Completed on time or early as compared to the baseline project plan
  • Comes in at or below planned expenditures for baseline budget
  • Meets all specifications as outlined in the approved project definition
  • Deliverables are accepted by end-user and/or assigning entity
• In order to apply project management to information security, you must first identify an established project management methodology

Project Management Knowledge areas

1. Project Integration Management
   Project integration management includes the processes required to ensure that effective coordination occurs within and between the project’s many components, including personnel. Major elements of project management effort that require integration include the following processes:
   • Development of the initial project plan
   • Monitoring of progress as the project plan is executed
   • Control of revisions to the project plan
   • Control of changes made to resource allocations as measured performance causes adjustments to the project plan
2. Project Scope Management
   Project scope management ensures that the project plan includes only those activities necessary to complete it. The scope is the quantity or quality of project deliverables expanding from the original plan and Includes the following processes:
   • Initiation
   • Scope planning
   • Scope definition
   • Scope verification
   • Scope change control
3. Project Time Management
   Project time management ensures that the project is finished by identified completion date while meeting objectives.  Failure to meet project deadlines is among the most frequently cited failures in project management. Many missed deadlines are rooted in poor planning. Project Time Management includes the following processes:
   • Activity definition
   • Activity sequencing
   • Activity duration estimating
   • Schedule development
   • Schedule control
4. Project Cost Management
   Project cost management ensures that a project is completed within resource constraints. Some projects are planned using only a financial budget from which all resources must be procured. Project Cost Management includes the following processes:
   • Resource planning
   • Cost estimating
   • Cost budgeting
   • Cost control
5. Project Quality Management
   Project quality management ensures that the project adequately meets project specifications. If project deliverables meet the requirements specified in the project plan, the project has met its quality objective. The good plan defines project deliverables in unambiguous terms against which actual results are easily compared. Project Quality Management includes the following processes:
   • Quality planning
   • Quality assurance
   • Quality control
6. Project Human Resource Management
   Project human resource management ensures personnel assigned to the project are effectively employed. Staffing project requires careful estimates of the required effort. In information security projects, human resource management has unique complexities, such as Extended clearances and Deploying technology new to the organization. Project  Human Resource Management includes the following processes:
   • Organizational planning
   • Staff acquisition
   • Team development
7. Project Communications Management
   Project communications convey details of activities associated with the project to all involved. It includes the creation, distribution, classification, storage, and ultimately destruction of documents, messages, and other associated project information. Project Communications Management includes the following processes:
   • Communications planning
   • Information distribution
   • Performance reporting
   • Administrative closure
8. Project Risk Management
   Project risk management assesses, mitigates, manages, and reduces the impact of adverse occurrences on the project.  Information security projects do face risks that may be different from other types of projects. Project Risk Management includes the following processes:
   • Risk identification
   • Risk quantification
   • Risk response development
   • Risk response control
9. Project Procurement Management
   Project procurement acquires needed resources to complete the project. Depending on common practices of the organization, project managers may simply requisition resources from the organization, or they may have to purchase. Project Procurement Management includes the following processes:
   • Procurement planning
   • Solicitation planning
   • Solicitation
   • Source selection
   • Contract administration
   • Contract closeout

The need for project management skills within the practice of information security may not at first be self-evident. It is emphasized that information security is a process, not a project. However, each element of an information security program must be managed as a project, even if the overall program is perpetually ongoing. This implies, among other things, that the security of the information is present in any establishment of the organization, being a pillar of the same, and serving as cross support to the entire organization. Project management involves identifying and controlling the resources applied to the project as well as measuring progress and adjusting the process as progress is made toward the goal.  It is, in fact, a continuous series or chain of projects, each link in this chain could be a specific project, and each of these projects would be guided by the security systems development life cycle (Sec SDLC). Some aspects of information security are not project-based; rather, they have managed processes. These managed processes include the monitoring of the external and internal environments during incident response, ongoing risk assessments of routine operations, and continuous vulnerability assessment and vulnerability repair. These activities are called operations and are ongoing.

• Clear definition of project constraints, including a time frame, budget, and minimum quality requirements increases the likelihood that the project stays within them.
• Establishing measures of performance and creation of project milestones simplifies project monitoring.
• Early identification of deviations in quality, time, or budget enables early correction.

Successful project management relies on careful and realistic project planning coupled with aggressive, proactive control. The project success may be defined differently in each organization, but in general, a project has deemed a success when:

• It is completed on time or early.
• It comes in at or below the expenditures planned for in the baseline budget.
• It meets all specifications outlined in the approved project definition, and the deliverables are accepted by the end-user and/or assigning entity.

To lead information security projects, some organizations assign technically skilled IT or information security experts; others assign an experienced project and general managers. Some organizations use both approaches simultaneously. Regardless of the approach, the goal is the same: to have all elements of the information security program completed with quality deliverables, on a timely basis, and within budget.

it is not the same to say that we are going to establish a methodology to manage projects in the field of information security (for example, use a methodology such as PRINCE2 project management to implement a project of ISO 27001), as to say that we are going to establish a methodology to treat the security of information in project management (for example, to use a risk management methodology to analyze security risks of the information relating to a project).
The ISO 27001 standard talks about the second issue and this will be what we will focus on, but we should take into account the order of the words – as you have seen, it is not the same. The information security will always be a component of the management of any project in the organization, and the organization will also comply with the requirement established by ISO 27001. This control also helps to provide greater importance and presence to the information security in the organization, which is always positive for this sector, since it is not seen as a simple requirement of a standard, but as a critical parameter in addressing and implementing any project in the organization.

A. 5.8 Information security in project management

Control

Information security should be integrated into project management.

Purpose

To ensure information security risks related to projects and deliverables are effectively addressed in project management throughout the project life cycle.

ISO 27002 Implementation guidance

Information security should be integrated into project management to ensure information security risks are addressed as part of the project management. This can be applied to any type of project regardless of its complexity, size, duration, discipline or application area (e.g. a project for a core business process, ICT, facility management or other supporting processes). The project management in use should require that:

• information security risks are assessed and treated at an early stage and periodically as part of project risks throughout the project life cycle;
• information security requirements (e.g. application security requirements , requirements for complying with intellectual property rights, etc.) are addressed in the early stages of projects;
• information security risks associated with the execution of projects, such as security of internal and external communication aspects are considered and treated throughout the project life cycle;
• progress on information security risk treatment is reviewed and effectiveness of the treatment is evaluated and tested.

The appropriateness of the information security considerations and activities should be followed up at predefined stages by suitable persons or governance bodies, such as the project steering committee. Responsibilities and authorities for information security relevant to the project should be defined and allocated to specified roles. Information security requirements for products or services to be delivered by the project should be determined using various methods, including deriving compliance requirements from information security policy, topic-specific policies and regulations. Further information security requirements can be derived from activities such as threat modelling, incident reviews, use of vulnerability thresholds or contingency planning, thus ensuring that the architecture and design of information systems are protected against known threats based on the operational environment. Information security requirements should be determined for all types of projects, not only ICT development projects. The following should also be considered when determining these requirements:

• what information is involved (information determination), what are the corresponding information security needs (classification) and the potential negative business impact which can result from lack of adequate security;
• the required protection needs of information and other associated assets involved, particularly in terms of confidentiality, integrity and availability;
• the level of confidence or assurance required towards the claimed identity of entities in order to derive the authentication requirements;
• access provisioning and authorization processes, for customers and other potential business users as well as for privileged or technical users such as relevant project members, potential operation staff or external suppliers;
• informing users of their duties and responsibilities;
• requirements derived from business processes, such as transaction logging and monitoring, non- repudiation requirements;
• requirements mandated by other information security controls (e.g. interfaces to logging and monitoring or data leakage detection systems);
• compliance with the legal, statutory, regulatory and contractual environment in which the organization operates;
• level of confidence or assurance required for third parties to meet the organization’s information security policy and topic-specific policies including relevant security clauses in any agreements or contracts.

Other information

The project development approach, such as waterfall life cycle or agile life cycle, should support information security in a structured way that can be adapted to suit the assessed severity of the information security risks, based on the character of the project. Early consideration of information security requirements for the product or service (e.g. at the planning and design stages), can lead to more effective and cost-efficient solutions for quality and information security. ISO 21500 and ISO 21502 provide guidance on concepts and processes of project management that are important for the performance of projects. ISO/IEC 27005 provides guidance on the use of risk management processes to identify controls to meet information security requirements.

The operation of each company is determined by the constant execution of projects in the short, medium, and long term (internal projects to maintain the structure of the organization, and external projects to provide services to customers). But security is something that is usually forgotten in projects; i.e., when a project is addressed in an organization, it does not usually take into account the information security. However, I’ve found some organizations, mainly large companies, that have included the information security in their projects as just one more activity (for example, running a risk assessment, focused on information security, at the beginning of any project to identify threats/vulnerabilities and risks). And this is basically what ISO 27001 requests in Annex A.6.1.5 Information security in project management: Information security shall be addressed in project management, regardless of the type of the project.
All projects basically need resources, activities to develop, and established time objectives. Information security can be integrated into project management activities in several ways:

• Include information security objectives in project objectives.
• Perform a risk assessment in an early stage of the project.
• Carry out treatment of the identified risks and implement security measures
• Make the information security policy an indispensable part of all stages of the project

It’s particularly important (independent of the size of the organization) to include information security in project activities for those projects, e.g., which deal with or target integrity, availability, and confidentiality of the information.

To make security a higher priority, project teams or managers need to implement or address the following:

1.Secure development Policy (SDP)
Secure development is a requirement to build up a secure service, architecture, software and system. Within a secure development policy, the following aspects should be put into consideration:  

1. Security of the development environment;
2. Guidance on the security in the Project life cycle(PCL);
3. Secure coding guidelines for each programming language used;
4. Security requirements in the design phase;
5. Security checkpoints within the project milestones;
6. secure repositories; version control, access control
7. Developers’ capability of avoiding, finding and fixing vulnerabilities.

An Organization Information Security Governance Team needs to create or document Secure Development Policy (This may be a part of corporate Information Security Policy). If there were no formal documented Policy, then organization personnel at any level would have no guidance on how to make decisions during entire Project life cycle. This helps employees to initiate actions and take responsibility without constant reference to management. Increase the accountability of business or organization’s and its staff. In reality, however, the existence of Policy provides many benefits provided they are written well and kept up to date. This Policy needs to be reviewed at least once in a Year or update in case of any changes in Policy. After review and changes (if any), this should be approved by Chief Information Officer (CIO), Chief Information Security Officer (CISO) or Department Heads only.

2.Standard Operating Procedures (SOP)
Operating procedures shall be documented and made available to all developers/ users who need them. The SOP should be in place so that Project (development) team should know the security requirements on each and every phase during project phases of the life cycle. All step by step instructions should be incorporated into the document with the individual’s roles & responsibilities. The approved procedure is documented in a format that is easy to follow and reduces the chance of errors being made. The idea behind it is to reduce the possibility of human error and to provide guidelines for employees to follow.

3.Segregation of Development, testing and production environments:
Development, testing and production environment shall be separated to reduce risks and threats of unauthorized access or changes to the operational environment. The intent of this requirement is to ensure that development/ test functions are separated from production functions. For example, a developer may use an administrator-level account with elevated privileges for use in the development environment and have a separate account with user-level access to the production environment. In environments where one individual performs multiple roles (for example application development and implementing updates to production systems), duties should be assigned such that no one individual has end-to-end control of a process without an independent checkpoint. For example, assign responsibility for development, authorization and monitoring to separate individuals. Reducing the number of personnel with access to the production environment minimizes risk and helps ensure that access is limited to those individuals with a business need to know. Organization IT Services or Technology (Network & Server) team is responsible for the segregation of all environments i.e. Development, Testing and Production and access control as per business needs. Network team recommends separate VLAN for the environments and the Server team is responsible for Server deployment in Data Center or Server Room. Security processes such as Change Management, Secure guidelines as per standard operating environment to be followed as per Industry best practices.

4.Protection from Malware
Malware is “malicious software.” This is software that is specifically designed to gain access or damage a computer without the knowledge of the owner. There are various types of malware including spyware, key loggers, true viruses, worms, or any type of malicious code that infiltrates a computer. Generally, the software is considered malware based on the intent of the creator rather than its actual features. Malware creation is on the rise due to the sheer volume of new types created daily and the lure of money that can be made through organized Internet crime. The malware was originally created as experiments and pranks but eventually led to vandalism and destruction of targeted machines. Today, much of malware is created for profit through forced advertising (adware), stealing sensitive or confidential information (spyware), and spreading email spam. Various factors can make computers more vulnerable to malware attacks, including defects in the operating system design, having all of the computers on a network run the same OS, giving users to many permissions or just using the Windows OS (due to its popularity, it gets the most malware written for it). During the Project Life Cycle (PLC), we need to ensure that information and information processing facilities are protected against malware. Detection, prevention and recovery controls shall be implemented to protect against malware. The best protection from malware continues to be the usual advice: be careful about what email attachments you open, be cautious when surfing and stay away from suspicious websites, and install and maintain updated, quality antivirus programs such as Symantec endpoint protection, McAfee Computer security etc.

5.Change Management
A proper Change Management Process should be followed in case of any changes during development up to till production. Threats may occur sometime in case of false changes are made without any testing (or staging). The development environment requires a level of security commensurate with the planned security level of the software product being produced. Appropriate controls and configuration management of the development artefacts are essential. There may be specific tools required, such as for static code analysis, to aid the production or testing of secure software. Change is a necessary part of the overall PLC process. However, many leaders manage to change poorly, causing distrust or confusion for their employees and clients. Organization responsible team should write a change management plan, leaders intentionally design a process that helps everyone know what needs to change, why it needs to change, and how to go about making the change take place smoothly.

6.Risk Assessment
Security Risks, threats and vulnerabilities are the potential attackers and are described in terms of (employee, business partner, contractor or supplier) with an objective (financial gain, project code, company’s IPR or obtaining proprietary corporate information, disabling essential business systems), and with a set of resources (personnel, a computing software, tools, hardware, skill, knowledge of internal systems). A risk assessment explores how a component could be exploited by the identified threats and vulnerabilities (i.e., what could go wrong) and analyzes the possible responses to such attacks. The response options for risk are to (a) mitigate (reduce the probability of the event, reduce impact, improve recovery), (b) transfer (insurance, contracted agreements), (c) ignore (for low impact and highly unlikely threats), or (d) avoid, which may require changes in requirements. The factors involved with a risk assessment that is done early in the development process are predominantly business rather than technical. Project management needs to ensure stakeholder participation in such activities. The attack patterns would be rather abstract for a preliminary system risk assessment and would become more detailed as the software architecture and detailed design are created. Risk management process to be followed by the organization where Information Security experts need to identify, assess, and prioritize the risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events or to maximize the realization of opportunities.

7.Activities required to complete deliverables:
Regulatory or contractual compliance may require a demonstration that the software provides the necessary controls for accessing the information (i.e., the production of an assurance case). Security governance typically increases the complexity of meeting security requirements. For example, business process compliance may require showing that the composition and interactions of multiple applications maintain the required controls and feedback. Regulatory compliance, Contractual compliance, requirements are set by Customers only and vendors or suppliers should adhere to those guidelines. Delivering “Secure” software requires demonstrating that the desired level of assurance has been achieved. While demonstrating that a system provides the required functionality is an essential aspect of software assurance, software security assurance depends more on demonstrating what a system does not do. An improper input leads to a system failure or enables an attacker to bypass authentication. The production of such an assurance case must be planned and managed. An assurance case provides an argument for how the software meets an identified threat. That argument typically is based on assumptions about how the software behaves under certain operating conditions. Hence, an early step in building an assurance case is to provide evidence that software behavior satisfies the assumptions of the assurance argument. The production of an assurance case is an incremental activity. The assurance case should describe the architecture’s role for meeting security requirements, and the architectural risk assessment and analysis should provide evidence that the architecture satisfies those requirements. Syntactic analysis of the source code reduces the probability of coding errors that might lead to a security vulnerability. Risk-based testing can target the components and interfaces that are most likely to lead to a system compromise.

8.Restrictions on software/ tools installation
Procedures shall be implemented to control the installation of tools/ software’s on development, testing and production systems. The organization should define and enforce strict policy on which types of software users may install. The principle of least privilege should be applied. If granted certain privileges, users may have the ability to install the software. The organization should identify what types of software installations are permitted (e.g. updates and security patches to existing software) and what types of installations are prohibited (e.g. software that is only for personal use and software whose pedigree with regard to being potentially malicious is unknown or suspect). These privileges should be granted having regard to the roles of the users concerned. Uncontrolled installation of software on computing devices can lead to introducing vulnerabilities and then to information leakage, loss of integrity or other information security incidents, or to violation of intellectual property rights.
Note: Software licensing agreements that are such that organizations may become liable for licensing for client software on workstations owned privately by employees or external party users;

9.System and application (code level) access control
Access to information and application system functions should be restricted in accordance with the access control policy. Restrictions to access should be based on individual business application requirements and in accordance with the defined access control policy. The following should be considered in order to support access restriction requirements

• Providing menus to control access to application system functions
• Controlling which data can be accessed by a particular user
• Controlling the access rights of users, e.g. read, write, delete and execute
• Controlling the access rights of other applications
• Limiting the information contained in outputs
• Providing physical or logical access controls for the isolation of sensitive applications, application data, or systems.
• Secure log-on procedures

10.Use of secret authentication information/source code:
Users should be required to follow the secure coding guidelines/ practices in the use of secret authentication information. All users should be advised to:

1. Keep secret code/ authentication information confidential, ensuring that it is not divulged to any other parties, including people of authority
2. Avoid keeping a source code/ important records (e.g. on paper, hand-held device)
3. Information, unless this can be stored securely and the method of storing has been approved (e.g. password vault)
4. Change secret authentication information whenever there is any indication of its possible compromise
5. When passwords are used as secret authentication information, select quality passwords with sufficient minimum length.
6. Ensure proper protection of passwords when passwords are used as secret authentication.
7. Information in automated log-on procedures and are stored.
8. Not use the same secret authentication information for business and non-business purposes.

11.Facilities and Staffing
Security expertise on most projects is limited and may be an internal or a contracted service. The allocation of that resource is often difficult to even when security activity is limited to networks, authentication, and access control, but when security has to be incorporated into application development, that expertise is spread much thinner. An increase in the level of assurance can significantly affect both the security and software engineering expertise required. For this discussion, we divide security expertise into two categories. One category consists of knowledge of security functions such as the specification and implementation of access control, authentication, and encryption functions. Such security functionality may be encapsulated in the system infrastructure. The second category of expertise consists of the skills to identify and mitigate exploitable system vulnerabilities. Historically, a significant number of the vulnerabilities that lead to a security failure were created by application errors and not by failures with the security infrastructure. Vulnerabilities may be in the least exercised parts of the system and depend on pathological aspects of the interface. Such vulnerabilities may be missed by application development teams, who normally concentrate on the core functionality. The security functionality for authentication, authorization, and encryption is typically composed of commercially supplied components that can be tailored for a specific operating environment. Those components must have the required assurance level. It would not be surprising to find the security knowledge associated with the first category to be concentrated within a few teams. The security specialists associated with that infrastructure should be aware of the security issues associated with development and project management. Unfortunately, application development teams rarely have the necessary security expertise. The resources in the second security knowledge category must be spread across multiple development efforts Tasks such as risk assessments, code reviews, threat modeling, Vulnerability assessment, require security expertise. On the other hand, there are security improvement practices that can be implemented without requiring extensive security experience. For example, although security knowledge may be necessary to configure a tool for the static analysis of the source code, the use of such a tool does not require a security background. Testing provides a second example. Penetration testing is often part of an acceptance test or certification process. Penetration testing might be implemented by what is called a red team: security experts who attempt to breach the system defenses. Fuzz testing is a simple form of penetration testing that finds software defects by feeding purposely invalid and ill-formed data as input to program interfaces. Fuzz testing does not replace the need for testing that targets explicit security risks, but it is an example of an approach that can be used without detailed knowledge of security vulnerabilities.

12.Project and Product Risks
Poor management of requirements scope is another frequent cause for project failure. Scope management is particularly important where the learning curve is a necessity because of the immaturity of the business usage or the supporting technology. Business integration requirements are pushing the connectivity of networked information systems beyond an organization’s IT systems. Meeting business requirements may depend on using relatively new protocols such as those for Web Services. Those protocols are currently a moving target, as they continue to be revised to reflect the experiences of early adopters. Best practices in this context have short lives, and the lack of well-defined and proven practices adversely affects planning. Plans for these circumstances might include a prototype or use of an iterative or incremental approach. Security mechanisms that mitigate a specific risk may create additional ones. For example, security requirements for managing identity for a large distributed system might be met by implementing authentication and authorization as infrastructure services shared by all applications, but the aggregation of authentication and authorization mechanisms into a shared service makes that service a single point of failure and a possible attack target. Such design decisions should involve a risk assessment to identify any new threats that require mediation, as well as the analysis of the operational costs after the system is deployed.

Security integrated into PM methodology

The Project Management Institute defines a project as an interactively elaborated endeavor and security should be considered within each PM process or stage. Security checkpoints built into the project during several key processes will ensure progress toward the desired security end state at the project closure. The best opportunity to ensure secure project delivery exists in the early stages of the project during initiating and planning. Beginning with the end in mind, i.e. the delivery of a security system will avoid costly scope, budget and schedule impacts.

1.Develop Project Charter
The true business value of a security solution is the amount of risk mitigation provided compared to the cost of solution implementation and maintenance. For eg, A project that proposes to give a sales force access to data on their smartphones may be implemented very differently if security is considered as a basic requirement of the final deliverables rather than an afterthought to be addressed when security breaches occur after implementation. If a particular smartphone that supports better security protocols becomes a requirement, cost and schedule may be impacted, but costly disclosures of intellectual property may be avoided. PMs can make a convincing case that security dollars will accomplish more if security is baked into the project from the outset, rather than applied as a Band-Aid to pass an audit during operational handoff, or worse, spent to recover from damage after a security incident. A security impact analysis as part of a larger cost-benefit analysis should be executed during the initiation phase of every IT project to make a sound financial decision. Security can be considered part of the larger Cost of Quality of the project. Cost of Quality includes both preventative measures and the costs of failure to create a quality product. In the context of security, preventative measures include just about everything that will be recommended in this paper, including planning, requirements collection, change management, risk management, and training. Additional internal costs will include appraisal costs to find quality problems such as inspections, tests and audits. The costs of failure include the costs to recover from a cyber-security incident like a data loss or theft. Those recovery costs would include external failure costs like loss of goodwill, lost sales, fines, liability costs, investigation of incidents and remediation as well as internal failure costs like wasted work, rework, and failed hand off to operations. Large organizations may have a project methodology that requires a security stage gate to be passed; small organizations may need to simply assign a capable reviewer to examine the project proposal at critical points in the project, especially prior to committing funds to the project

2.Identify Stakeholders
A standard Interest vs. Influence stakeholder analysis matrix focused specifically on security considerations may be revealing. Identify the organizational security office, and find out if they have security sign-off on deliverables for your project. Analyze your sponsor’s security attitude, especially if you anticipate the budget is inadequate for security. You may need to move key players higher on the security interest scale, including your project sponsor, technical teams and operations staff. Depending on the formality of the sponsoring organization, the PM may assign a standard list of security roles to project team members. Involving operations staff early in the project and soliciting their input on security requirements during planning will minimize the risk of last-minute security fixes as the system rolls into production.

3.Plan Communications
The bulk of a PM’s work during the executing stage of a project has to do with communications. In fact, the PMBOK (Project Management Institute) states that “Communication has been identified as one of the single biggest reasons for project success or failure.” We will return for a deep dive into securing project communications in the next section of this paper, but the communications plan is the first step toward ensuring information security during project execution. A communications plan should include not only the method, frequency and audience for communications but may also consider guidelines and technical standards for a wide variety of communication channels:

• Secure project document sharing that uses adequate encryption and access control for data transfers and storage.
• Telephone conference calls, including the requirement to password, protect the meetings and/or use the roll call feature of the conferencing provider to ensure only those invited are on the line and periodically changing your meeting passcode, especially when a project closes.
• Distribution of meeting minutes and other project documents via email, including the availability of an encryption mechanism like PGP for sensitive emails.
• Instant messaging via a provider that meets your organization’s security standards.
• Guidelines regarding forwarding work-related email to personal cell phones and what information is acceptable to be left in voice mailboxes and in auto-responders.
• Desktop or application sharing/video conferencing via an approved provider.
• Regular backups to guard against data loss due to computer crashes or user error.
• Guidelines for use of social media.

4. Develop Project Team
Perhaps the most likely risk during project execution is inadvertent data leakage via one of the myriads of communication channels PMs utilize every day: email, phone, VOIP, IM, numerous options for document sharing including cloud collaboration, and the newest threat to information security, social media. The ideal defence against inadvertent data leakage is a project team that is aware of the risk and uses secure information systems intelligently. To achieve that, security training may be needed. A review of the communications plan at a team kickoff meeting can set expectations. Periodic reviews of the plan will remind team members of their critical role in project security.

5.Plan Risk Management
Of the project management processes, “Plan Risk Management” often gets less attention than, say, “Create Work Breakdown Structure” or “Estimate Costs,” but information security, and ultimately project management, are fundamentally about risk management. A malware attack may or may not occur during your project; a resource may or may not be available when scheduled; how much time and money should be dedicated to reducing the negative impact of an uncertain event? Risk management attempts to qualify and quantify potential impacts and choose effective mitigation strategies. Qualitatively, organizations may have particular risks they tend to avoid; for example, organizations subject to HIPAA regulations will avoid loss of protected data. Quantifying security risk is even more challenging and numerous models and techniques are available Technical experts designing an IT system will likely use more sophisticated techniques for risk analysis than the PM will use to manage risks to the project, but both aspects of risk management are essential to successful project delivery. Each IT security risk to a project may require custom estimates. As an example, consider the potential impact of a data breach during project execution. Four factors are most important in determining the likelihood that a breach of private consumer data will result in litigation: data type, breach cause, evidence of misuse and size of the incident. These four general factors may also be useful for evaluating the impact of a breach for other types of IT data. More valuable data such as account names and passwords or network details will have a higher impact than publicly available email addresses. Information stolen by bad actors will likely have a higher impact than information inadvertently misdirected. Information that is actively misused will have a higher impact than information stolen with no evidence of intent to misuse. And the loss of larger amounts of data will be higher impact than smaller amounts of data.

6.Secure Communications
Communication is at the heart of project management and every communication channel carries the risk of exposing confidential data. An email sent to the wrong person or worse, distribution list, a team member that stores project documents with an insecure cloud provider, a smartphone lost on the bus, a laptop left in a hotel room. Something as simple as neglecting to sanitize internal document meta-data before forwarding to external customers runs the risk of exposing confidential information.IT project managers often handle intellectual capital that is the equivalent of the keys to the kingdom. IT project records are a rich source of valuable documents and due to the temporary and fast-moving nature of project work, access controls and records systems may not be maintained after the project closes and the team moves on. Industrial espionage targets blue chip companies and small and mid-sized businesses have also been targeted, especially as easy targets for banking fraud, so no organization is immune to the threat.

7.Authentication and Password Management
100% of breaches by Advanced Persistent Threat “bad actors” involve stolen credentials. APT groups are large, well-organized, and well-funded, sometimes by national military organizations. Their mission is to methodically gather broad categories of intellectual property like business plans, email addresses and contact lists of organizational leadership, technology blueprints, and proprietary manufacturing processes. Attackers frequently steal data to make reconnaissance faster, like network infrastructure data and sysadmin guides. In particular, VPN configuration files, systems documentation, and network documentation like firewall configuration files are specifically targeted during reconnaissance. Nearly every aspect of a hacked computer and a user’s online life can be and has been commoditized The argument that “no one would be interested in my data” has been thoroughly debunked. Hackers market lists of stolen credentials for online retailers by the gigabyte. Credentials for critical systems are a prized commodity. LinkedIn, Yahoo and Twitter are just a few of the many sites which have been high-profile victims of password-stealing attacks. Passwords that are reused on a variety of sites and are never changed are a big security risk.

• Use long, complex passwords.
• Don’t reuse passwords on multiple websites or for multiple accounts.
• Change passwords periodically.
• Use a password manager so you can choose difficult to guess and unique passwords for each account.
• Use two-factor authentication where appropriate.

8.Access Management
Members of the project team should have the access they need and only the access they need to systems. In the name of speed, credentials are sometimes handed out fast and loose. Defining and documenting a clear system for on boarding and off-boarding personnel will not only improve the efficiency of these processes but also ensure credentials are current. Team member access rights need to be reviewed and updated periodically. If people leave the project or company, access should be revoked.

• Document and use secure onboarding and off-boarding procedures.
• Schedule periodic reviews of access permissions.

9.Encryption
Encryption protects sensitive and valuable data at rest and in motion by transforming plain text into a coded form referred to as cypher text. Encryption is an almost invisible part of many communications protocols, including web browsing, email, instant messaging, VoIP. Encryption can be especially valuable for the storage of data as another layer of protection against data theft or breaches on cloud infrastructure or mobile devices. The ease and convenience of cloud storage bring new challenges, including inadvertent data leakage during storage or transfer or even through deliberate data harvesting by the cloud provider, and challenges for the availability of project records.
It’s a mistake to choose a cloud vendor based solely on the quality of service and price if their privacy and security standards are not adequate. It has been reported that many organizations had experienced a breach of outsourced consumer data. The vendor should provide verifiable evidence that data is secure on their infrastructures like security certifications that require audits of their practices with respect to NIST and FISMA standards by accredited organizations like Logyx and Veris group, or via STAR or FedRAMP certs. PM  must make sure that they are familiar with and understand the disaster recovery provisions, privacy terms and conditions, and long-term financial viability of the cloud provider before storing project records in the cloud. Cloud storage providers like Microsoft and Amazon have responded to being hacked by improving their default security configuration. However, even strong encryption is only as secure as the password(s) used to unlock the encryption.  Data on mobile devices like laptops and smartphones should be secured with encryption plus strong authentication since they are frequently lost or stolen.

• Protect data in the cloud or on mobile devices with encryption.
• Enforce strong authentication policies for accessing encrypted data.
• Transmit data only with secure protocols.

10.Wireless Attacks
Employees on Road  will undoubtedly have been faced with the question of whether connecting to a hotel, airport or coffee shop wireless connection is “safe.” Connecting to an open wireless network provides a fast attack surface, including the possibility of bad actors potentially intercepting transmitted information, compromising the computer or smart device, or harvesting passwords or information about secure corporate VPN or wireless systems due to unsecured behaviour of the wireless card. Handhelds like smartphones hold and transmit rapidly increasing amounts of data and deserve special scrutiny since they are easily and frequently lost or stolen and have in many cases minimal built-in provisions for security. If they do not conform to company security policies for passwords, encryption and virus protection they should not have access to company data, including email and voice messaging. The most common cause of data breaches due to smartphones is a lost device.

• Require a secure configuration and security measures for all devices accessing internal data, especially smartphones and laptops, including data encryption, password protection, anti-virus software and remote wipe ability.
• Restrict end-user administrative permissions.
• Avoid using unsecured wireless networks in coffee shops, hotels and airports. If using unsecured networks is unavoidable, use a VPN or another secure tunnel to access all data.
• Keep smartphone software up-to-date by enabling automatic updates.
• Backup smartphone data periodically to avoid losing data, especially contacts, if the device is lost, stolen or damaged.

11.Physical security
If your employer or client has locations in several countries, it is likely they are an attractive target for intellectual property theft or industrial espionage. Any work-related information on your laptop or smartphone will require special consideration for maintaining the confidentiality of that information. Physical security for project records should include not only physical access to the electronic systems that store data such as laptops but also physical access to printouts and paper filing systems. Recycling bin, printer and fax output trays and filing cabinets all need to be covered by the security policy. Sensitive documents should never be left unattended in insecure locations and should be shredded with cross-cut shredders when disposed of. Commercial software can now digitally reassemble most documents shredded on popular and inexpensive strip shredders

• Secure hard copies of data in file cabinets, on fax machines, in printer trays and in wastebaskets/shredders.
• Use security cables. Educate travellers about the risks of theft and data leakage.

12.Secure Deliverables
Requirements gathering is a critical stage for project security. Security requirements should consider the sponsoring organization’s security policy and regulatory environment. The PMBOK (Project Management Institute) notes that security requirements may impact project costs via the scope baseline and procurement. Requirements elicitation is often not straight-forward; security requirements elicitation maybe even less well-defined. A systematic approach may help to achieve a consistent, complete set of security requirements.

13. Monitor and Control Risks – Change Control
Information security is often identified only with hackers and malware, but basic system availability is impacted by a much broader category of events, including planned and even routine system changes. PMs tend to leave technical change management to their technical teams. However, technical change management presents risks to information security availability and integrity and PMs should be familiar with its risks and mitigation of those risks. If a system goes down during a Go-Live event and adequate time has not been reserved to back out changes, the availability of the system to support business functions is compromised. A good change control plan will include enough time to make all changes and complete testing, plus enough time to roll back all changes if the system doesn’t pass operational or functional tests at a scheduled checkpoint(s). Similarly, information integrity is at risk if adequate measures aren’t in place to backup and then restore data from backup during the change window if necessary. Changes should be evaluated on a risk matrix, i.e., probability vs. impact, based on impact urgency, risk, benefits, and costs, and managed to minimize impacts to business needs. Change windows should have longer lead times and be larger for higher-risk changes.

14.Verify Deliverables
Operations may expect the project delivery team to deliver an inherently secure system, while the project delivery team may expect security to be the responsibility of operations management after the system is handed off. Consideration should be given to when and how security concerns are most efficiently and effectively addressed in the total system life cycle, not just during project delivery. Ownership of security should rest with the project manager to the extent that the initial system setup is securable. An organization can either incorporate security guidance into its general project management processes or react to security failures.. If security has been included in requirements gathering with input from the operations team, operational hand-off will be organized around verifying security deliverables as specified and transferring ownership rather than reacting to security problems identified by operations staff as the system is being put into production.  Operational Acceptance Testing checklists for non-functional components of a system (i.e., quality attributes such as performance, availability, and reliability) like backup/recovery, maintenance, and security can guide the hand-off and ensure that operations staff have the documentation and verified configurations they need to support the system.

15.Document Lessons Learned
In the excitement of a completed project and the usual pressure to move on to a new one, it may be often overlooked, but capturing lessons learned is an important part of building Organizational Process Assets and your security expertise as a PM. Lessons learned can be one of the most effective ways to motivate secure behaviors and to establish a culture of security in your organization over the long-term. Any security experiences, risks, or threats that materialized or not should be noted in the risk register and documented for future project evaluation and planning.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion are also welcome.