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

Copyright, 2013 ©

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

TIM

E

RE

SO

UR

CE

S

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

TIM

E

RE

SO

UR

CE

S

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

93

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 ©


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).


Copyright, 2013 ©

Date post:	08-May-2015
Category:	Technology
Upload:	dave-sweigert-cisa-cissp-hcispp-pmp-sec
View:	906 times
Download:	0 times