CSOL 530 Risk Management Framework Final Assignment Marc Leeka

This presentation will identify all aspects of the Risk Management Framework and introduces a detailed
plan for effective continuous monitoring.

Adopting a Risk Management Framework is mandatory for large organizations. Smaller organizations
might ignore the methodology because they believe it is too complicated to follow, too expensive to
implement, or perhaps it is only for big companies and would not apply to the small guys.

Untrue. The small guys need a Framework because they are small and they dont have few of the
resources larger companies take for granted. This Framework is practical for every organization.

Our information assets face many threats. Threats can be grouped into four principal domains: people,
processes, systems and external events. Examples include employees negligently failing to follow
internal policies; the inadequacy of a procedure when conducting an electronic transaction with one of
our business suppliers; an inadequate security mechanism in one of our technical systems; or an
external threat such as a power failure or earthquake.

Bad people inside our organization and bad actors outside are not the only threats to our information
system. There are legal and regulatory compliance that varies among the countries in which we
operate. A breach of confidential customer information could present a public relations nightmare. Even
ethics can pose a threat if we do not adequately filter spam and websites that are offensive to the
religious or sexual beliefs held by our employees.

Reference: Sherwood, J., Clark, A., Lynas, D. (2005). Enterprise Security Architecture. CRC Press, Boca Raton, FL.

Thats a lot to manage and probably why many organizations to not have a strong Risk Management
Framework in place. To get a handle on all the threats, we will follow a six-step process to create and
organize an enterprise risk management framework as recommended by the National Institute of
Standards and Technology.

The six steps guide us to:

know what we have to protect;
know what threats are probable;
know how our assets are protected and how well;
and identify the gaps in our protection;
And finally we need to remember that this is a cyclical, ongoing process.

Risk is the combination of what could happen, the likelihood that it will happen, and the consequences
when it does happen. Risk Management therefore identifies, evaluates and mitigates risk to an
organization.

The first step is an organization-wide participation to identify all enterprise architecture and the
information security architecture assets. A thorough inventory will help the leadership ensure that
individual information systems are categorized based on the mission and business objectives of the
organization.

The results from this inventory will then lead to categorization by security risk. Security
categorization is the process of determining the amount of risk the system causes. The results of the
security categorization process influence the nature of protections required and the minimum assurance
requirements for that system.

Estimating risk likelihood is a complex and an imperfect science and decisions should be consistent
with the organizations overall risk management strategy. Documentation that is traceable at a future
date will allow us to identify the decisions we made today and revise our estimations if necessary in the
future.
1
CSOL 530 Risk Management Framework Final Assignment Marc Leeka

Risk management is more than just the identification and resolution of identified threats; it is about the
environment, decisions and ability to accept risk as part of daily operations. It is a process to understand
and respond to factors that could lead to failure and to the compromise of confidentiality, integrity and
availability of an information system.

Risk categorization is an activity that requires participation by most of our company leadership. The
categorization process requires that we identify information assets as a group and as a group we classify
assets based on risk. The Federal government categorizes potential security impacts as low, moderate
and high. Rarely will the leadership achieve a unanimous vote on what risk level to assign to an asset,
but the government has made our consensus easier by giving us broad definitions and many good
examples in its publications.

Reference: FIPS 199

It would be difficult to assign mitigation solutions to so many individual risk assessments, so the
Federal government suggests we establish information systems boundaries and combine multiple
system risk categorizations into a single risk categorization.

This culmination results in the high-water mark, i.e. what is the maximum risk for the confidential
value, the integrity value and the availability value when you look at multiple categorizations.

The first system confidentiality assessment is moderate and the second is low, therefore the final risk
categorization for confidentiality is moderate. Both system integrity assessments are low, and both
system availability assessments are low.

The initial security impact high-water values for the payroll system are moderate, low, and low. This
initial value may change over the lifetime of the asset due to requirements that change from what they
are today.

Security controls are the management, operational and technical safeguards for our information system
to protect confidentiality, integrity and availability.

Based on our previous risk assessment high-water values, we want to choose a set of baseline controls.
If you alter or remove minimum security baseline controls, you must always document why you
removed the control. Controls are derived and justified from our risk assessment; on the converse,
traceability is necessary from controls back to risk assessment.

We may also choose to supplement the controls with enhancements and/or additional controls and
document accordingly.

2
CSOL 530 Risk Management Framework Final Assignment Marc Leeka

Here are three examples of families of security controls we proposed for the Payroll system. There are
other Access Control family controls necessary to adequately protect our payroll system. This
assignment was not to identify every Control but to propose examples. This is how the controls are
selected, first by baselines and then tailored to our circumstances.

Tailoring also allows us to remove recommended controls because we have not identified any related
risk in our unique system.

Additional controls or enhancements may be necessary because of industry standards, laws, regulations,
policies and directives. Common controls are most often sought because they are generic, well-
understood and tend to be the least expensive. Our requirements may also call for system-specific
controls and/or hybrid controls. Common controls spare us the time and expense to secure individual
systems and instead secure all systems

As I pointed out on a previous slide, risk assessment changes over time and should be reviewed
periodically. So too do the controls we employ to mitigate the risk. Controls may require change
because of incidents or newly-discovered threats. Significant changes to our risk management strategy,
the configuration of our system, new regulations or even the organizations business mission can also
require that we modify our controls.

Now lets look at the implementation of the controls we selected. We want to invoke a strategy that
includes procedures and techniques that establish and maintain assurance and trust. Implementation is
all about assurance and confidence.

Let me introduce the idea of assurance. Some of our information subsystems may be out of our direct
control, for example our payroll system concludes with ADP processing the information we submit and
delivering payroll checks to our accounting department, or we purchase a control from a vendor. Good
controls contribute to greater assurance. if our controls are tested, evaluated or validated by approved,
independent, third-party facilities, we are going to get that extra level of security. This is like getting the
Underwriters Laboratory seal on an electrical device or NHTSA ratings on the side of an automobile
tire.

Assurance and Chains of Trust are considerations that must be factored in to the overall level of
confidence in the information system when we make risk assessments and select controls.
Furthermore, if we have a high-risk system, something that could be considered a high-value target,
then we clearly need to consider additional assurance measures to mitigate risk.

3
CSOL 530 Risk Management Framework Final Assignment Marc Leeka

Safety, reliability, and fault tolerance each have constructs and techniques that are shared with security.
However, the application of those constructs and techniques to achieve safety, reliability, and fault
tolerance does not necessarily achieve security.

So the take-home message here is that it is not sufficient to accurately identify and choose the security
controls; you have to implement them correctly to establish assurance and confidence in the system.

The security controls weve chosen for deployment within our information system and subsystems have
been allocated to specific system components responsible for providing specific security results. Not all
security controls need to be allocated to every subsystem. Our previous identification of risks and the
subsequent selection of high water security controls was a way to achieve a suitable balance of
prevention. Allocating some security controls as common controls or hybrid controls is how we share
controls among related systems and minimize cost, implementation and maintenance.

We also may have inherited common controls that were implemented for another related system and
now may be used for our payroll system. But, if the common controls do not meet our requirements for
the payroll, we will have to identify and implement compensating controls.

And lets not forget that our implementation must meet state and federal laws, industry standards and
regulations.

System security is a condition that results from the establishment and sustainment of protective
measures that contribute to continuous achievement of mission and business objectives despite risks
posed by potential threats throughout the system life cycle.

The trustworthiness of a system is determined from the assurance and confidence that the system is
adequate to provide the specified protections and enforce the security policy, given its intended use.

System security engineering can provide trustworthiness of a system that enforces the organization
security policy and presents residual risk that is deemed acceptable and manageable to stakeholders.

System engineering is both technical and non-technical. Technical processes include stakeholder
requirements definition, analysis, architectural design and implementation. Non-technical processes
include configuration and infrastructure management, risk management, verification and validation.

Having previously identified assets, assigned risk and implemented controls, the enterprise now enters a
re-evaluation phase to determine if the initial plan worked as intended, and whether the discovery of
new information requires reassessment or modifications to the initial plan.

In this step the enterprise addresses the remaining weaknesses and deficiencies in the information
system and its operation.

4
CSOL 530 Risk Management Framework Final Assignment Marc Leeka

So given the complexity of selection and implementation, how do we know everything is working as
intended? What if we did everything correctly and there were other events that triggered a change in the
threats to our system or the risk assessments we made based on a previous environment or knowledge
of the threats?

These triggers could be something we have the power to change, such as modify our business mission
and objectives, or we can make significant changes to the information system, common controls, or the
environment of operation.

Significant changes are defined as any change that is likely to affect the security state of an information
system. Significant changes to an information system may include installation of a new or upgraded
operating system, middleware component, or application; modifications to system ports, protocols, or
services; or installation of a new or upgraded hardware platform.

Our operations environment may change significantly. For example, moving to a new facility; adding
new core missions or business functions; acquiring specific and credible threat information that the
organization is being targeted by a threat source; or the establishment of new or modified laws,
directives, policies, and regulations.

The Security Plan we created was an overview of the security requirements of the system and
described the controls in place or planned to meet those requirements. Furthermore it delineated
responsibilities of individuals who access the system, and included tailoring decisions and the
justification for those alterations from standard recommended baselines. It also included objectives for
the control assessment and a detailed roadmap of how to conduct the assessments.

We tested the Security Plan in order to quantitatively measure the effectiveness and thoroughness of the
controls we selected. Those tests resulted in the Security Assessment Report and any recommended
corrective actions for any weaknesses or deficiencies our testing has revealed.

We then created a Plan of Action and Milestones that described the specific measures planned to
correct weaknesses or deficiencies noted in the security controls during the assessment, and to address
residual vulnerabilities in the information system. Our POA&M also included the organizations
rationale for accepting certain weaknesses or deficiencies in the security controls, and any
noncompliant security controls.

The Security Plan, the Security Assessment Report and the Plan of Action and Milestones were
combined into our Security Authorization Package.

Security authorization is the official management decision given by a senior organizational official to
authorize operation of an information system and to explicitly accept the risk to organizational
operations and assets based on the implementation of an agreed-upon set of security controls.

The Authorizing Official determines the degree of acceptable risk based on mission requirements,
reviews the Security Authorization Package, and grants or denies the Authorization to Operate.

We received an Authorization to Operate valid for three years with conditions that must be satisfied
immediately and throughout the period.

With respect to life cycle processes, up to this point it has been assumed that we were looking for an
initial authorization, a start-up initial risk determination and risk acceptance based on a zero-base
review of the information system conducted prior to its entering the operations/maintenance phase of
the system development life. The Authorization could have been an ongoing re-authorization or a re-
authorization due to significant changes to our information systems or failure to meet a conditional goal
specified in the POA&M.

5
CSOL 530 Risk Management Framework Final Assignment Marc Leeka

Continuous monitoring addresses the security impacts on information systems resulting from changes
to the hardware, software, firmware or the operational environment. Because change is inevitable to
both the systems and the environment during what could be a long life cycle, there has to be some
mechanism to determine whether security controls continue to be effective and to revise our security
plans on an ongoing basis.

Monitoring can be automated or non-automated, but automated tools provide near real-time,
unambiguous and cost-effective risk management that non-automated processes often cannot.

And, remembering that our Authorization To Operate has an expiration date, our continuous monitoring
assessment results can be used for the future reauthorization process.

Effective Continuous Monitoring includes configuration management, security impact analyses,

assessment of selected security controls, reporting the results to leadership and active involvement by
authorizing officials in the ongoing management.

Risk assessments usually determine to priority of security controls to be monitored and the frequency of
monitoring. Security controls that have the greatest potential to be changed post-implementation, and
the controls that were previously identified as weak or ineffective in the POA&M are strong candidates
for continuous monitoring.

Configuration management, includes activities such as:

Planning how configuration management will be applied to information systems;
Configuring information systems to a secure state;
Managing and controlling changes to the systems;
Verifying and auditing the information systems to confirm that they have been configured to
the planned security state; and
Reporting on the overall security state of the information system environment.

Having better control of the misconfigurations that lead to vulnerabilities is fundamental to any security
program. Through security configuration management, an organization is able to target and remediate
vulnerabilities. The management process also examines into how well organization-wide vulnerabilities
have been addressed and subsequently how risks have been mitigated.

Configuration management begins by establishing an initial baseline of hardware, software, and

firmware components for the information system and subsequently controlling any changes to the
system, including additions and deletions, and maintaining an accurate record of those changes.

A baseline configuration is a well-defined, documented and current specification to which the system
has been built.

A security configuration checklist is a document that contains instructions or procedures for securely
configuring an information technology product to an operational environment. Examples include a
lockdown guide, hardening guide, security guide, or security technical implementation guide.

Effective checklists also contain instructions or procedures for verifying that the product has been
configured properly.

Well-written, standardized checklists can reduce the inconsistencies across vast and complex
information systems.

6
CSOL 530 Risk Management Framework Final Assignment Marc Leeka

Change management is a formalized and heavily-documented procedure to manage and control any
alteration to the system.

Organizations may use lots of written forms to track and document changes, or larger organizations
may automate the process.

Either way, the process always begins with a written request for the change that is submitted into the
approval process.

Qualified information systems personnel analyze and evaluate the proposed change for effectiveness,
performance and security.

If approved, the change is planned and scheduled. Then the implementation is verified to be correct.

After the configuration management process has been implemented, organizations should focus on
deploying security configurations that put information systems into their most secure state.
Configuration settings are parameters that can be changed in a hardware and software components that
affect the components functionality, performance and security posture.

This is important because configuration settings impact many different aspects of an information system
that the components employ to enforce a particular security policy. There are zillions of settings in any
information system and, without a management process, it would be easy to ignore or overlook
incorrect and potentially insecure settings.

The continuous monitoring process should also be used to update the security control baseline.

In conclusion, creating a risk management framework is doable, but it is a company-wide and

management participatory exercise. The framework can help us identify assets we need to protect, and
identify threats so that we are prepared when the time comes. A risk management framework is
auditable and can provide reasoning and justification for the allocation of resources to protect our
information assets or, in some cases, why we chose to ignore protection because it was unwarranted.
Finally, a risk management framework creates the plan to manage and maintain our information
systems, even as they change over time.

Continuous monitoring is critical to any information systems security because it identifies undiscovered
components, misconfigurations, vulnerabilities and unauthorized changes. If not addressed, any of these
can expose the organization to increased risk.

And way back on slide #1, that was why we began the 6-stage process to employ Risk Management
Framework. I hope you now believe that is what we must do and agree with the reasons why we do it.