Introduction of project risk in an information assurance environment

Copyright, 2013 ©
A Hybrid Framework for Risk Management in the
Project Management and Information Assurance Domains
August 2013
AUTHOR:
Dave Sweigert, M.Sci., CISSP, CISA, PMP

Copyright, 2013 ©
ABSTRACT
This document embodies an approach to ensuring Information Assurance (IA)
risks are probably identified and mitigated within the project-centric environment,
an environment where project management (PM) techniques are used.
This project-centric IA risk management approach is a departure from the
enterprise-based information technology (IT) risk management techniques so
prevalent today. As a project is a temporary endeavor to create a value-added
system, not a static configuration of IT components, dynamic IA techniques are
needed that can be assimilated into a PM framework.
Described herein are the risk mitigation approaches of two subject matter
domains: IA and PM. An approach is suggested that has been tailored to the
complex project-centric environment to graceful integrate IA techniques within
the PM context.
This document provides project managers and staff with a framework for
implementing risk management when designing, engineering or deploying IT
solutions in an IA impacted project-centric environment using standard PM
techniques.
This framework is based upon industry best practices and is designed to reduce
the probabilities of errors, mistakes, schedule problems, etc. that may impact
delivered services and products that may be impacted by information assurance.

Copyright, 2013 ©
Table of Contents
Table of Contents................................................................................................................ 3
Description of document................................................................................................. 5
Content............................................................................................................................ 5
Supporting rationale for such a document ...................................................................... 6
Contrasting concepts of these two domains.................................................................... 7
Summary......................................................................................................................... 8
Classic definition of risk in the PM venue...................................................................... 9
The IT Project manager ................................................................................................ 10
Understanding differences between project and business operations........................... 12
Understanding IT project failure................................................................................... 13
Contrasting the IA and PM mindsets............................................................................ 14
Summary....................................................................................................................... 15
Risk mitigation sensitivity ............................................................................................ 16
Figure 5. ........................................................................................................................ 16
Developing a risk mitigation process (non project-centric).......................................... 17
Developing a risk mitigation plan (project-centric)...................................................... 18
A hybrid combination of these two risk mitigation approaches ................................... 18
A workable hybrid that mediates project and non-project centric methodologies ....... 19
Applying the CobiT model as mediator........................................................................ 20
Benefits of the CobiT mediation approach ................................................................... 21
Summary....................................................................................................................... 22
Content of RMP............................................................................................................ 23
Developing an RMP Scope Statement.......................................................................... 23
Methodolgy to be used in risk mitigation ..................................................................... 25
Roles and responsibilities ............................................................................................. 26
Resources required for RM........................................................................................... 26
Summary....................................................................................................................... 27
Risk Identification methods.......................................................................................... 28
Risk analysis methods................................................................................................... 30
Caveat about SDLC Iteration........................................................................................ 32
National Institute of Standards and Technology Special Bulletin 800-18.................... 34
REFERENCES: ................................................................................................................ 37

Risk Management Integration 5
Copyright, 2013 ©
1. Background
Description of document
This document describes a project-centric Information Assurance (IA) Risk
Management (RM) framework appropriate for planners and managers of
Information Technology (IT) projects. This IA-RM framework is over-arching and
policy-based in nature. Examples of specific IA risks are given for instructive and
tutorial purposes later in this document.
This document provides the framework for a risk mitigation strategy that
combines the risk mitigation concepts of the IA and project management (PM)
domains of knowledge.
This document may be used as the first tier in a multi-tier documentation system
describing the risk management system that can be used to empower the design,
engineering, and deployment of interoperable IT architectures and systems.
Content
The document is intended to be:
 A repository of information on risk mitigation of IA concerns and
the supporting rationale for the use of those practices,
 Provides tutorial material to enable project managers and IA
professionals to better understand the holistic nature of unified
risk management.
Caveat: as a preliminary matter, the reader should be aware of system
development life cycle (SDLC) techniques. Risk mitigation techniques may need
to be applied to various stages of the SDLC to enable protection of the final work
product.

Copyright, 2013 ©
Supporting rationale for such a document
The PM domain is characterized by the timely and cost-effective completion of a
project. A project is a temporary endeavor undertaken to create a unique
product or service. (PMBOK 2003)
The IA domain is characterized by is the protection of the data manipulated,
stored, and transmitted by static IT systems. IA concerns should be addressed,
where appropriate, by the IT project manager. The IA practitioner should help
the IT project manager by presenting IA concepts in a familiar vocabulary, such
as the lexicon of the PM domain. This document attempts to help educate the IT
project manager about IA concepts and vice versa.
These two domains (IA and PM) can be harmonized in a cross-domain approach
to help IT project managers understand IA objectives and help IA practitioners
build better communications with such project managers.
The importance of IA
Bill Gates recently articulated such an approach to software engineering:
“..There’s a whole new way of looking at code and saying,
“How do you reduce that attack surface? How do you have
tools that can look through and find areas where there might
be vulnerabilities? And we call this the Trustworthy
Computing process, and it’s something we rolled out in
2002…”.(GATES, 2004)
One of the senior advisors to Mr. Gates has articulated the problem this way:
“..We are seeing the advent of mega-scale computing
systems built out of loose affiliations of services, machines,
and application software. The emergent (and very different)
behavior of such systems is a growing long-term risk…”
(MUNDIE, 2002)

Copyright, 2013 ©
Contrasting concepts of these two domains
The formalistic approach to assessing risk in an IA and PM differs, and
contrasting these two domains provides a foundational understanding of the two
different philosophies of each, with risk mitigation as a common thread. The end
goal is to help the IA and PM practitioner understand the suitable interplay
between these two subjects.
For example, it is standard practice to assess the value of an asset (or data) as
well as the probability of impact/loss in the information security arena. The
information security industry view of risk:
“Risk: “The potential for the realization of unwanted, adverse
consequences to human life, health, property, or the environment;
estimation of risk is usually based on the expected value of
conditional probability of the event occurring times the
consequence of the event given that is has occurred..:”. (ISAAC,
2003)
Simultaneously, the project management industry also has a formalistic approach
to “project risk management” (PRM). Quoting from an industry source:
“Project risk is an uncertain event or condition that, if it occurs, has
a positive or negative effect on the project objective. A risk has a
cause and, if it occurs, a consequence. … Project risk includes
both threats to the project’s objectives and opportunities to improve
those objectives. …Organizations perceive risk as it relates to
threats to project success….” (PMBOK, 2003)
Both domains (IA and PM) should be harmonized in the practitioner’s approach
to risk management so as to compliment, rather than conflict with, each other.
This will provide the practitioner with an appropriate risk mitigation framework
that will provide value in the IA and PM areas of endeavor.

Copyright, 2013 ©
A working IA/PM hybrid definition of risk might be:
“…In any project, risk is linked to the probability of attaining a
specific outcome. Risk is thus closely intertwined with uncertainty –
uncertainty about delivering on time, uncertainty ok keeping within
the budget, and uncertainty of meeting expected performance,
quality standards and client needs. And if the project is also
innovative and complex, risk is dramatically multiplied..”.
(PREFONTAINE, 2003)
or
“…Project risk management is the art and science of identifying,
analyzing and responding to risk throughout the life of a project in
the best interests of meeting project objectives….” (SCHWALBE,
2004)
Summary
The premise of the project-centric risk management framework presented herein,
is that these two domains (IA and PM) both have formalized approaches to risk
management. However, aspects of these approaches may be in conflict.
Therefore, these risk management approaches require harmonization and should
be unified under a common aegis. Hence, the descriptive term for this cross-
domain framework: Risk Management Framework.

Copyright, 2013 ©
2. Understanding risk management
This section provides a clear baseline of basic terminology that will enable the
reader to absorb some of the more complex concepts presented later in this
paper. This section is designed to be tutorial in nature and provide foundational
concepts for the reader.
Classic definition of risk in the PM venue
IT project managers essentially balance time, resources and scope to provide a
certain quality of deliverable. Every project is constrained in different ways by
scope, time and cost goals (SCHWALBE 2004). Managing the triple constraints
involves balancing scope, resources (cost) and scope to meet quality objectives.
Algebraically stated time + resources + scope = quality. Risk represents an
unknown influence on these factors, as seen in the diagram below.
Figure 1.
The paradigm of project management
Scope. Scope is the general description and parameters of what is to be
accomplished. To be considered a project, there should be some tangible
outcome of the endeavor. The dimension of the project should be identified; e.g.
new credit portal for automotive dealers, etc. Artifacts of scope can be:
 Project goals and objectives
 Project requirements
 Project deliverables
QUALITY
SCOPE
TIME
RESOURCES
RISK

Copyright, 2013 ©
Time. Time describes the timeline the project shall be accomplished. Time is a
constraint that must be balanced by the project managers as well. Projects must
have a beginning and ending date.
Resources. Resources include the “costs” associated with the project. They are
those tangible “things” that will be needed to accomplish the project scope.
Examples of resources:
 People
 Equipment
 Supplies
 Software
 Hardware
Quality. Quality is the overall measurement of what the final product of the
project will be. Quality may be measured in various ways, for example:
 Network response time
 Heuristics of web site usability
 Customer satisfaction with new web site
 Data protection and confidentiality measures
Risk. In this venue represents those threats to project constraints that can harm
the project or impact any constraint, which indirectly effects quality. Risks can be
external forces that impact the project, or project constraints in a negative
manner. For example:
 Lead systems architect walks off the job
 Innovative technology makes project deliverable obsolete
 Radical change in market conditions demand faster deployment
 Corporate financial pressures require cutting project budget
The IT Project manager
The successful IT project manager must accommodate the constraints described
above, and many more. One view of a successful IT project manager:

Copyright, 2013 ©
Effective project managers Ineffective project managers
Lead by example Set bad examples
Are visionaries Are not self-assured
Are technically competent Lack technical expertise
Are decisive Are poor communicators
Are good communicators Are poor motivators
Are good motivators
Stand up to top management when
necessary
Support team members
Encourage new ideas
Figure 2.
Attributes of successful project managers
(ZIMMERER, 1998)
Of particular interest to this discussion are the following attributes: “visionaries”,
“technically competent”, and “stand up to top management”. The identification
and management of risk are not popular activities, in fact, “shoot the messenger”
can be a risk in of itself.
As the reader will learn in later sections, risks must be identified. A “visionary”
project manager that is “technically competent” enough to understand the impact
to the project may “have to stand up to management”. Suffice to say, that some
individuals will not have the “stomach” for balancing IA and PM issues.
Therefore, care should be taken to select appropriate individuals for such tasks
that have the emotional resiliency to accommodate such potentially hostile
environments.

Copyright, 2013 ©
3. Understanding differences between project and business operations
An IT project, to use PM terminology, is a “temporary endeavor undertaken to
create a unique product or service” (PMBOK, 2003). This distinction is made to
differentiate an IT project from the day-to-day administration of IA policies,
standards or guidelines (PSGs), which typically guide the organization’s
operation and management of IT resources.
An IT project will ‘change” some aspect of the organization’s operation. It will
impact the current configuration of the organization’s enterprise, it may store
federally regulated confidential and sensitive data, it will require manpower and
resources, etc.
Example of a process, that is not project-centric
It is instructive to note that the Office of Management and Budget (see OMB,
Executive Office of the President) sets policy for all executive agencies in the
U.S. Government. OMB policy provides an example of what is NOT project-
centric risk management; but, what is policy and process-centric.
OMB Circular A-130 addresses the management and acquisition of major IT
systems and specifically addresses the security of federal executive branch IT
systems.
Quoting OMB A-130 in relevant part:
“…Agencies should continually assess the risk to their computer
systems and maintain adequate security commensurate with that
risk. Conduct reviews of security practices to ensure that processes
are in place that permit program officials and security managers to
understand the risk to agency systems and take necessary steps to
mitigate it…”. (OMB A-130)
The “risk assessment” methodology in the IA arena assumes a static computer
enterprise or architecture. This static enterprise is the subject of a risk
assessment. However, this does not speak to the “temporary endeavor” qualities
of “project management”.
This distinction is provided to avoid confusion on the part of the IT project
manager in the area of “risk” mitigation.

Copyright, 2013 ©
Basic risk terminology used in IA
An IA professional will have been exposed to the basics of risk mitigation.
Proper IA risk management terminology in this context includes:
 Risk: The possibility of suffering harm or loss, measured in qualitative or
quantitative terms.
 Threat: An expression of a force of some nature that can cause the
organization harm.
 Vulnerability: Something is susceptible to harm or loss.
Understanding IT project failure
The Center for Technology in Government at the State University of New York
(Albany) made the following observations concerning the risk of IT innovation
(DAWES, 2004):
 Unrealistic expectations
 Lack of organizational support and acceptance
 Failure to evaluate and redesign business processes
 Lack of organizational alignment between organizational goals and project
objectives
 Failure to understand the strengths and limitations of new technology
 Projects are too specialized or ambitious to manage successfully
Interestingly, the Centre Francophone d’Informatisation des Organizations
identified IT project risks into two major categories: (1) risks of the project itself
and (2) organizational risks. Their findings are very similar to the “failures”
identified above.

Copyright, 2013 ©
Risks associated
with the project itself
Organizational risks
 Characteristics of the
users/clients of the new service
 Scope of the project
 Complexity of the project
 Definition and structure of the
project
 Lack of resources
 Project team competencies
 Management strategy
 Technical know-how
Figure 3.
Sources of IT project risk
(PREFONTAINE, 2003)
Contrasting the IA and PM mindsets
It is ironic that IA itself can represent a “risk” to the project-centric project
manager. IA embodies policies, regulatory oversight, legislative mandates,
criminal mis-conduct, possibility of civil litigations and sanctions, etc. In the purist
sense, IA is a PM “risk”.
Figure 4.
The risk of IA to a project
QUALITY
SCOPE
TIME
RESOURCES
RISK
•Information assurance
•Privacy and confidentiality issues
•Laws, regulatory compliance
•Theft of intellectual property
•Introduction of malicious code
•Employee misconduct
•Sabotage, disruption of environment

Copyright, 2013 ©
Summary
Harmonizing PM and IA risk management begins with a common understanding
of the different philosophies of risk management. The modern day, flexible,
project manager understands that it is incumbent upon him/her to identify those
risks that may jeopardize the objectives and goals of a project (impacting time,
scope, resources or quality).
Therefore, those “visionary” project managers will attempt to become better
acquainted and “technically competent” in IA-based risks to better understand the
impact such risks may have on the project.

Copyright, 2013 ©
4. Risk mitigation process
This section discusses the over-arching steps in managing IA-based risks that
may threaten a project’s goals and objectives.
Risk mitigation sensitivity
The software development industry tends to neglect the importance of project
risk management (SCHWALBE, 2004). According to one survey the information
systems industry has one of the lowest rates of adoption of risk mitigation
techniques (IBBS, 2000)
The degree of interest by an organization developing IT systems or software can
be viewed in three basic categories; risk-averse, risk-neutral, and risk-seeking.
The degree of appreciation of risk mitigation techniques may vary greatly
depending on the type of organizational environment the IA or PM practitioner
finds him or herself in.
Figure 5.
Risk tolerance of different organizations
(SCHWALBE, 2004)
Potential pay-off 
Utility
RA
RS
RN
RA = Risk-averse organization. Lower
Tolerance for risk. As pay-off increase
tolerance decreases.
RN = Risk-neutral organization. Balancing
of risk and potential pay-off.
RS = Risk-seeking organization. As
potential for pay-off increases tolerance to
risk increases as well.

Copyright, 2013 ©
For example, an IA practitioner with a history in government organizations and
government contractors may need to adjust to private organizations engaged in
speculative new Internet-based services. Private organizations, answering to
stockholders, may be driven to faster project completion and regulatory
compliance and oversight issues may not be as important to such an
organization as, say, a defense contractor engaged in a military contract.
A PM or IA practitioner cannot form a judgmental opinion about these
organizations, that would be counter-productive. Rather, it seems more
productive to understand the environment one shall work and work within such
an organization to achieve acceptable results.
Developing a risk mitigation process (non project-centric)
The U.S. General Accounting Office has cited several basic elements of a risk
mitigation approach for use within IT environments. These phases do not
represent a specific project-centric approach to risk management. However, they
are instructive to recognize how the IA practitioner may approach risk
management. They are:
 Identify threats that could cause serious harm to critical operations and
functions: intruders, criminals, disgruntled employees, and terrorists.
 Estimating the likelihood that such threats will materialize based on
historical information and judgment of knowledgeable individuals.
 Identifying and ranking the value, sensitivity, and criticality of the
operations and assets that could be affected should threat materialize in
order to determine which operations and assets are the most important.
 Estimating, for the most critical and sensitive assets and operations,
the potential losses or damages that could occur if a threat materializes,
including recovery costs.
 Identifying cost-effective actions to mitigate or reduce the risk. These
actions can include implementing new organizational policies and
procedures as well as technical or physical controls.
 Documenting the findings described above and developing an action
plan (GAO 1999)

Copyright, 2013 ©
Developing a risk mitigation plan (project-centric)
Project management advocates have developed a six-phase approach to project
risk management (SCHWALBE, 2004). This approach is considered industry
best practice within the project-centric context.
 Risk management planning. Deciding how to approach and plan risk
management projects within the project context. A risk management plan
is formulated by reviewing the project charter; work breakdown structure,
organizational risk management policies, etc.
 Risk identification. Determine which risks are likely to affect the project
and documenting the characteristics of each. Review of project planning
documents, historical information, etc.
 Qualitative risk analysis. Characterizing and analyzing risks and
prioritizing their effects on project objectives. After identifying risks rank
risks by criticality.
 Quantitative risk analysis. Measuring the probability and consequences
of risks. Prioritize quantifiable risks and estimate probabilities of
consequence.
 Risk response planning. Taking steps to enhance opportunities and
reduce threats that may interfere with project objectives. Develop a risk
response plan.
 Risk monitoring and control. Monitoring known risks, identifying new
risks, reducing risks, and evaluating effectiveness of risk reduction.
A hybrid combination of these two risk mitigation approaches
It is instructive to note the similarities between these two generalized risk
management methodologies (described above).
Table 1. Mitigation approaches
Non-project centric risk mitigation Project-centric risk mitigation
Risk management planning
Identification of threats Identification of risks
Estimating likelihood Qualitative analysis
Identification and ranking Quantitative analysis
Identifying cost-effective actions Risk response planning
Risk monitoring and control

Copyright, 2013 ©
A workable hybrid that mediates project and non-project centric
methodologies
The Information Systems Audit and Control (ISACA) Information Technology (IT)
Governance Institute has created the Control Objectives for Information and
related Technology (CobiT) model to provide IT governance. Many aspects of
the CobiT are relevant to this discussion of PM and IA harmonizing.
The IT governance process begins by executive management establishing over-
arching goals and objectives for the organization. After these high-level
objectives have been established a continuous loop is established to measure
performance of IT delivery compared with IT objectives.
IT delivery is focused on realizing the benefits of increasing automation to make
the enterprise more effective and decreasing costs while managing risks
(security, reliability and compliance).
Provide
Direction
Compare
Measure
Performance
IT Objectives:
 IT is aligned with
the business
 IT enables the
busienss
 IT resources are
used responsibly
 IT-related risks
are managed
appropriately
IT Activities:
 Increase automation
(make business
effective)
 Decrease cost (make
the enterprise
efficient)
 Manage risks
(security, reliability,
compliance)
Figure 7: CobiT IT quality model
(CobiT 2000)

Copyright, 2013 ©
Applying the CobiT model as mediator
The author asserts that the CobiT model, and aspects of the model, can be
applied to resolve inconsistencies between risk mitigation from the IA and PM
domains. In this sense, the CobiT model acts as a “mediator” between the
two domains, as illustrated in the figure below.
Figure 8. CobiT as a domain mediator
As seen above, CobiT must be endorsed at the governance level of the
corporation or organization. The CobiT model lends itself to a tool that can
bridge business objectives and goals to the execution of policy within the IT
environment. This close proximity to the business objectives of the
organization (“board room issue”) allows CobiT to act as the arbitrator of
issues between IA and PM. Additionally, CobiT provides for significant
auditing requirements to ensure that the business objectives are being carried
out by IT processes and controls.
CobiT uses the terminology of “control objectives”. These control objectives
provide for the use of auditable artifacts that demonstrate how lower-level
processes are, indeed, meeting the higher-level over-arching business goals.
The relevant aspects of the CobiT model that apply to mediating IA and PM
risk management are codified in the high-level CobiT control objective “PO9 –
Assess Risks”.
CobiT as an overarching governance tool (mediation)
Project
Management
risk mitigation
techniques
(PMBOK)
Information
Assurance
risk
mitigation
techniques
Project-centric environment

Copyright, 2013 ©
The “PO9” control objective states that:
“…Control over the IT process of assessing risks that satisfies the
business requirement of supporting management decisions through
achieving IT objectives and responding to threats by reducing
complexity, increasing objectivity and identifying important decision
facts is enabled by the organization engaging itself in IT risk-
identification and impact analysis, involving multi-disciplinary
functions taking cost-effective measures to mitigate risks and takes
into consideration:
 Risk management ownership and accountability
 Different kinds of IT risks (technology, security, continuity,
regulatory, etc.)
 Defined and communicated risk tolerance profile
 Root cause analysis and risk brainstorming sessions
 Quantitative and/or qualitative risk measurement
 Risk assessment methodology
 Risk action plan
 Timely reassessment..” (CobiT 2000)
For example, the ability to demonstrate implementation of a risk management
program via risk assessments and risk mitigation strategies is an activity
undertaken to achieve the PO9 high-level control objective.
Benefits of the CobiT mediation approach
The use of CobiT provides a high-level arbitrator to resolve differences between
IA and PM practioners. CobiT also helps in aligning regulatory, oversight, and
legislative mandates that require risk mitigation processess (see OBM Circular A-
130).
It is instructive to note that the following organizations have endorsed the use of
COBIT:
 US Federal Financial Institutions Examination Council (FFIEC). All federal
financial regulatory agencies (such as the Federal Deposit Insurance
Corporation (FDIC)) rely on FFIEC standards.
 National Association of State Chief Information Officers (NASCIO).

Copyright, 2013 ©
 US National Institute of Standards and Technology (NIST) in Special
Publication 800-26, Security Self-Assessment Guide for Information
Technology Systems.
 The Office of Inspector General (OIG) of the US House of
Representatives.
 U.S. General Accounting Office (GAO).
 National Association of State Auditors (NSAA).
Summary
The CobiT goverance model is designed to align business objectoives with
organizational processes and control used within an organization. Some aspects
of CobiT can be used to mediate differences between the IA and PM domains.
As the CobiT model provides for auditable artifacts, it is also a tool to ensure
compliance with evidence of implementation.

Copyright, 2013 ©
5. Building the risk management plan
Documentation of the methodology, roles and responsibilities, budgeting, timing,
reporting formats, etc. for a Risk Management Plan (RMP) is the first step
preparing to mitigate project-centric risk. (HELDMAN, 2002) The RMP will later
become a formal input to the over-arching Project Management Plan.
Project-centric PM techniques discuss how to build a generic RMP within the PM
arena. This section attempts to increase the awareness of IA and IA-specific
issues to be addressed by the RMP.
Content of RMP
The RMP is almost a minature project. The risk mitigation process will require
resources, time, scope, that effect a quality deliverable, etc. From this
perspective the RMP documents the strategies, methodologies, resources
required, etc. to properly identify, assess, and manage risk.
Developing an RMP Scope Statement
The scope statement is really a statement of work (SOW) of what the RMP will
address. The scope statement provides an opportunity for senior management
and IA/PM practitioners to agree on the scope of the risk management activities.
The goals, objectives and issues of the RMP should be discussed. As one
author put it:
“…The scope statement will next address the overall objectives of
the analysis. For information security, these objectives are
normally the impact of threats on the integrity, confidentiality, and
availability of information being processedby specific applications or
systems. Consider the types of information security challenges
facing the organization, and use this to define objectives…”
(PELTIER, 2001)
Sources of risk management governance
At this stage it may be appropriate to cite, or mention, the various high-level
sources of governance that may require a RMP. The RMP may become a critical
document to be reviewed by outside auditors, regulators or even hostile legal
counsel should a lawsuit be underway. Therefore, it may be prudent to mention
over-arching laws that may effect the organization and the organization’s
approach to risk management. Example of federal laws providing risk
management governance:

Copyright, 2013 ©
Table 2. Governance sources
Governance Source
(Examples of laws)
Impact to organization
Health Insurance
Portability and
Accountability Act
(HIPAA), 42 USC 1320d,
et. al.
HIPAA protects a system of records that may maintain individually
identifiable data related to the administration of health benefits for
individuals. This can include delivery of medical of services,
enrollment/de-enrollment in health plans, records of services
provided, payment for services, etc. Law provides for civil and
criminal penalties for violations.
Privacy Act (PA), 5 USC
552a, et. al.
The PA provides for the access, safeguarding, amendment and
correction of a information maintained on an individual within a
“system of records.” Sensitive data maintained on individuals is
considered a protected class of information and must be
safeguarded in a prudent manner.
Sarbanes-Oxley Act, 15
USC 7201, et. Al.
Also known as the Public Accounting Reform and Investor
Protection Act. Created heightened responsibilities for senior
executives and audit committee members
1
. Section 404 requires an
assessment, as of the end of the most recent fiscal year of the
issuer, of the effectiveness of the internal control structure and
procedures of the issuer for financial reporting.
The astute IA and PM practitioner should consult with the organization’s legal
department about any special sources of regulatory, oversight or compliance
mandates that specifically require risk mitigation and analysis.
Federal law impacting federal IT systems
Some federal laws directly impact systems built for the U.S. Government. These
laws should be consulted as well.
Table 3. Specifics of governance sources
E-Government Act of
2002
Section 301 creates information security framework.
Section 3541(5) acknowledges that commercially developed
information security products offer advanced, dynamic, robust and
effective information security solutions.
Suggest strong use of standards developed by the U.S. national
Institute of Standards and Technology (NIST).
Agency heads shall promulgate information security protections
commensurate with the risk and magnitude of the harm resulting
from unauthorized access, use, disclosure, disruption, modification
or destruction.
The Information
Technology (IT)
Management Reform
Act of 1996 (i.e., ITMRA
or the Clinger-Cohen
Act),
The ITMRA is not just about the management of IT; it is an attempt
to incorporate a number of legislative driven activities such as
procurement reform, results based management, financial
accountability, and business process reengineering.
Strong recommendation for use of standards: “INFORMATION
TECHNOLOGY STANDARDS” The Director shall oversee the
development and implementation of standards and guidelines

Copyright, 2013 ©
pertaining to Federal computer systems by the Secretary of
Commerce through the National Institute of Standards and
Technology under section 5131 and section 20 of the National
Institute of Standards and Technology Act (15 U.S.C. 278g-3).”
Government
Performance and
Results Act of 1993; 31
USC 1105(a).
The primary legislative framework through which agencies will be
required to set strategic goals, measure performance, and report on
the degree to which goals were met.
OMB Circulars A-11 and
A-130
OMB Circular A-130, Appendix III, "Security of Federal Automated
Information Resources.” Agencies should continually assess the
risk to their computer systems and maintain adequate security
commensurate with that risk. Conduct reviews of security practices
to ensure that processes are in place that permit program officials
and security managers to understand the risk to agency systems
and take necessary steps to mitigate it.
Examples of goals and objectives within a scope statement
Here are a few types of IA-specific goal and objective statements that may
appear in the scope statement of an RMP:
 Identify risks that would impact compliance with existing federal and state
laws concerning the protection and confidentiality of sensitive data.; and,
 to sIdentify risks related to confidentiality of information stored or
transmitted by the system, such as risks associated with system access
control to protrected information.
 Identitfy risks that impact the intregrity of stored or transmitted data, such
as impacts to accuracy and completeness of data.
 Identify risks that impact the availability of data, such as the need to
safeguard stored data, perform system back-ups, etc.
Methodolgy to be used in risk mitigation
The selcetion of a methodology to meet risk management objectives will directly
impact all other factors of the RMP; like roles and responsbilities, need for
resources, reporting formats, etc. Therefore, the project-centric PM shoud work
closely with the IA practitioner to select an appropriate methodology suitable to
the needs of the project. Some of these methodologies will be discussed in the
section “Risk Indentication” which is a more appropriate venue for instruction on
these methodologies.

Copyright, 2013 ©
Roles and responsibilities
It will become very important to get “buy-in”, or acceptance, from all considered
parties about their roles in the risk identification process. As this will be a
collaborative effort, all parties need to understand the specific expectations of
other team members to avoid confusion, duplication of effort and “blame
gaming”.
An example of a “Roles and Responsibilities” Matrix is presented below for
illustrative purposes.
Table 4. Roles and responsibilities
ROLES Responsibilities
Steering Committee Members shall exercise appropriate management
intervention at key points of risk as described in the
Change Control Document
Chief Information Officer Act as overall sponsor and champion of the RMP.
Empower the Project Manager to act with authority to
ensure that schedules are meet in a timely manner.
Sit on steering committee.
V.P. of IT Operations Provide for the technical implementation of the risk
policies by allocating sufficient technical resources to
accomplish tasks described therein.
Act as technical liaison to the steering committee to
keep members up to date on any technical
implementation details.
Work with the Project Manager to enable timely
submission of technical artifacts that implement the risk
policies.
Project Manager Overall manager of risk mitigation implementation.
Empowered to seek cooperation amongst personnel
tasked with policy implementation.
Act as overall consultant to steering committee on
matters related to schedule and task execution.
Resources required for RM
The RMP will need to identify the resources required for managing risk of the
project. Resources may include systems, hardware, personnel, availability of
documentation personnel, etc.

Copyright, 2013 ©
Summary
A Risk Management Plan (RMP) serves as a document to remove assumptions
and ambiguity about how risk will be identified and managed. The RMP should
address the resources, time, cost and scope needed to conduct such a risk
assessment. Senior management may need to endorse or approve the
allocation of such resources, etc., before the RMP process can begin.
Stakeholders should be educated to understand the importance of the risk
management process by the distribution of the RMP to stakeholders.
Opportunity should be given stakeholders to review and critique the RMP.

Copyright, 2013 ©
6. Risk Identification
The risk mitigation process begins by the appropriate identification of those risks
that may impact the project. The Project Management Institute’s (PMI) Guide to
the Project Management Body of Knowledge (PMBOK) identifies four (4) basic
categories of risks that may impact a project (see graphic below). The
discussion of this paper will be limited to those risks identified in the right hand
(yellow) column.
Figure 9. General categories of risks that impact a project
(PMBOK 2003)
Risk Identification methods
The RMP would have identified the methodolgy to be used to identify risks. A
short synposis of popular methodologiues is herein presented to acquant both
the IA and PM practitioners with them.
External risks
•Legal or regulatory environment
•Labor issues
•Merger, acquisition, ownership
change
Organizational Risks
•Inconsistent scope objectives
•Improper cost, budget estimates
•Interruption of funding
•Conflict with other projects
Technical, Quality or
Performance Risks
•Use of complex technology
•Unrealistic performance goals
•Changing industry standards
Project Management Risks
•Improper schedule and resource
planning
•Poor project planning
•Poor use of project disciplines

Copyright, 2013 ©
Facilitated Risk Analysis Process (brainstorming)
Facilitated Risk Analysis Process (FRAP) is a discplined approach using
brainstorming techniques. FRAP is more rigorous and structured than
brainstorming per se. However, both approachs are comboned here for brevity
sake.
Both approachs begin with a free flowing “brainstorming session” conducted with
subject matter expert that are familiar with potential threats to the project. In this
sense, the “project is king”. In a purust sense, a governance law or regulation
could be considered a “threat” to the project. It may be very prudent for an IA
practitioner to understand this and not rely on any intrinsic “power” he/she may
percieve to have, rather the IA practitioner may be more beneficial in interpeting
significant policies or laws to the group.
These brainstorming sessions should be structured with appropriate boundaries
(e.g. time limitations, full team participation, etc.) to prevent discussions from
“getting out of control”. The objective is to first identify all the threats that may
impact the project.
“…The team does not usually attempt to obtain or develop specific
numbers for the threat likelihood … unless the data for determining
such factors is readily available…
 Such estimates take an inordinate amount of time and effort
to identify and verify or develop.
 The risk documentation becomes too voluminous to be of
practical use.
 Specific loss estimates are generally not needed to
determine if a control is needed….” (PELTIER, 2001)
In the FRAP method, following the brainstorming session the identified risks or
threats are prioritized or categorized. These risks may be rated as most severe
impact to least, etc. After determining the priority of risks, the team suggests
appropriate counter-measures to control or mitigate these threats (risks).

Copyright, 2013 ©
A list of risks or threats may appear like the following:
Table 5. Risk identification
Risk number Risk description
1 Not encrypting stored consumer data may be comprised and require public announcement
of compromise under SB 1386 (in California)
2 Software developers may inject malicious code into portal software that could cause shut-
down in the future (de facto extortion)
3 Building portal software on Linux open source may require additional security of the
operating system
4 Disgruntled worker may attempt to shut down server room
Other techniques to identify risk include:
 Interviewing
 Use of experts
 Checklists
 Strengths Weaknesses Opportunities Threats
Risk analysis methods
Now that basic risks and threats have been identified sense needs to made of it
all. Analysis techniques are used to provide a structured approach to dealing
with the identified risks..
Qualitative risk analysis
A very popular risk identification techique is known as qualitative risk analysis.
Some of it’s popularity is based on the technique of reducing identified threats to
the probability of a negative outcome and illustrating this information in a tabular
matrix. This enables “consumers” of the risk identification document to better
understand, assimiltate and manage the information presented.
“…A project manager can chart the probability and impact of risks
on a probability/impact matrix or chart..” (SCHWALBE, 2003)

Copyright, 2013 ©
High 5,8 1
Medium 3,6,9
Probability Low 2,4 7
Low Medium High
Impact
Figure 10. One approach to probability catagorization
(by numbered risks)
As demonstrated by the chart above, a qualitative assessment is made in the
terms of probability and impact to the project. Usually such qualitative
assessments are made by subject matter experts that have experience with like
projects. Then the identifified risks are placed in the matrix by the probability of
occurrence and the impact to the project is there is such an ocurrence.
Figure 11. Another graphical approach probability of outcomes
(SCHWALBE, 2003)
High Risk
Medium
Risk
Low
Risk
Consequences of failure
Probability
of failure
.02
.02
.04
.04
.06
.06
.08
.08
1 8
4
2
7
9
3
5
6

Copyright, 2013 ©
7. Integration of risk mitigation techniques with system development life
cycle (SDLC) models
The traditional software development life cycle (SDLC) methodology is depicted
below. Older instantiations of the SDLC have been known as a “waterfall”
approach, so named because it is top-down in nature, or hierarchical.
System
Requirements
and
Validation
Preliminary
Design and
Validation
Detailed
Design
Validation
Unit Test,
Integration Test
Pre-deployment
Testing
Deployment,
Operations and
Maintenance
Figure 12. Traditional SDLC approach
Caveat about SDLC Iiteration
The requirements definition and validation phase of an SDLC is part of an entire
life cycle approach to designing and implementing an infrastructure.
During a SDLC requirements gathering phase there is an emphasis on gathering
requirements from the user community. However, these requirements should be
re-validated during the entire SDLC, as explained below.
Recognizing the structural weaknesses of a rigid “waterfall” SDLC methodology
(depicted above), the approach has been modified to include opportunities for
iteration. An example is seen in the graphic below.

Copyright, 2013 ©
Maintain
Implement
Design
Analysis
Concept
Maintain
Implement
Design
Analysis
Concept
Figure 13. SDLC Modification
As depicted above a second iteration follows the first, but in a hierarchical and
sequential nature. This can be viewed within the context of sequential rapid
releases of systems (release 1.0, 1.1, 1.2, 1.3, etc.).
Security involvement must begin early
SDLC models define preliminary stages in the terms of “requirements gathering”
or “concept exploration”. It is very important that relevant security personnel are
engaged in the process by the software project team in these early phases of the
SDLC.
The gathering of security requirements is an important preliminary activity.
Requirements must be clear and derived from some source or origin. The
student/reader proposes sources of governance allowing requirements to be
“derived” or indirectly linked to regulations, laws, compliance policies, etc.
Caution should be taken to avoid participation of security personnel at early
stages and not later. This is a common phenomenon in commercial software
development areas. As the project pressures begin to build, project team
members may see less and less utility or value-added by security.

Copyright, 2013 ©
MaintainImplementDesignAnalysisConcept
Influence of security
upon software
development.
Decreasing need or interest in
security issues
Figure 14. Importance of early security requirements definition
“Unfortunately, most developers look at security people as
obstacles to overcome, mostly because of the late life cycle
“review”-based approach that many organizations seem to
use..” (VIEGA 2002)
One explanation of the “early intensity” phenomenon is the cost of error
correction. The longer requirements errors go undetected (into subsequent
SDLC stages) the most costly to correct their impact on the system.
Therefore, many organizations see intense value of security participation in
requirements setting at the early stages to avoid such errors (see chart below):
Maintain
Implement
Design
Analysis
Concept
Magnitude of
requirements errors
Increasing cost to fix
requirements errors as
stages develop
Figure 15. Growing impact of poor requirements and associated
costs
A recent study funded by the U.S. Air Force found that nearly 41% of all errors
within a complex software project were based upon requirements errors. (DAVIS
1996)
National Institute of Standards and Technology Special Bulletin 800-18
It is instructive to quote Special Publication 800-18 produced by the U.S. National
Institute of Standards and Technology in relevant part:

Copyright, 2013 ©
“..Although a computer security plan can be developed for a
system at any point in the life cycle, the recommended
approach is to draw up the plan at the beginning of the
computer system life cycle. It is recognized that in some
cases, the system may at any one time be in several phases
of the life cycle…” (NIST 1998).
Summarized in the chart below is SP 800-18’s view of a typical system
development life cycle (SDLC) mapped to specific considerations related to
security.
SDLC Phase Security Characteristics
Initiation Phase A sensitivity assessment should be performed that examines
the sensitivity of the information that will be processed by the
proposed system.
Development/Acquisition
Phase
Security requirements should be developed at the same time
as system planners define the requirements for the system.
These requirements may be expressed as system features
(e.g., access controls).
Implementation Phase The system’s security features should be configured and
enabled. A design review and system test should be
completed to validate security requirements and technical
implementation.
Operation and Maintenance
Phase
System operations such as: system backups, managing
cryptographic materials, maintaining access permissions,
etc.

Copyright, 2013 ©
REFERENCES:
IT Governance Institute. (2000) Governance, Control and Audit for Information
and Related Technology Framework. Rolling Meadows, Illinois:
Information Systems Audit and Control Foundation.
Dawes, s., Pardo, T., Simon, S., Cresswell, A, et. al. Making Smart IT Choices,
Understanding Value and Risk in Government IT Investments. (2004).
Albany, N.Y.: State University of New York (SUNY), Center for
Technology in Government.
U.S. General Accounting Office. (1999). Information Security Risk Assessment,
Practices of Leading Organizations. GAO Report AIMD 99-139.
Washington, D.C.: Library of Congress.
Gates, Bill. Remarks by Bill Gates, Chairman, Microsoft Corporation, on
February 24, 2004 at RSA Security Conference in San Francisco, Calif.
Heldman, K., Project Management Professional Study Guide. Alameda, CA:
SYBEX, Inc.
Ibbs, C. W., “Assessing Project Management Maturity,” Project Management
Journal (March 2000).
Isaac, D., Isaac, M. (2003) The SSCP (System Security Certified Practitioner)
Prep Guide. Hoboken, N.J.: John Wiley and Sons Publishing.
Craig Mundie, C., de Vries, P., Haynes, P., Corwine, Matt (2002). Trustworthy
Computing, Microsoft White Paper. Everett, Washington: Microsoft
Corporation.
Peltier, T. (2001), Information Security Risk Analysis. Washington, D.C.:
Auerbach Publications.
Project Management Institute. (2003). A Guide to the Project Management
Body of Knowledge (PMBOK Guide), Newtown Square, PA 19073.
Prefontaine, L. (2003) New models of collaboration, Risk management in new
models of collaboration. Montreal, Quebec, Canada: Centre Francophone
d’Informatisation des Organizations (CEFRIO).
Scwalbe, K. (2004) Information Technology Project Management. Bostan,
Mass: Thomson Course Technology.
Zimmerer, T., Mahmoud, M., “A Leadership Profile of American project
Managers,” Project Management (March 1998).

Introduction of project risk in an information assurance environment

More Related Content

Similar to Introduction of project risk in an information assurance environment (20)

More from David Sweigert (20)

Recently uploaded (20)

Introduction of project risk in an information assurance environment