Beruflich Dokumente
Kultur Dokumente
Version 1.1
TABLE OF CONTENTS
1 INTRODUCTION..1
1.1 PURPOSE.1
1.2 SCOPE...1
1.3 COMPLIANCE LAWS AND REGULATIONS..1
1.4 ROLES AND RESPONSIBILITIES1
2 RISK MANAGEMENT PROCEDURE..2
2.1 RISK PLANNING2
2.2 RISK MONITORING..2
2.3 RISK REPORTING.2
2.4 ACTION PLAN2
3 TOOLS AND PRACTICES.3
4 RISK MANAGEMENT PLAN APPROVAL4
Version 1.1
Introduction:
Information security continuous monitoring (ISCM) is defined as maintaining ongoing
awareness of information security, vulnerabilities, and threats to support organizational risk
management decisions. This publication specifically addresses assessment and analysis of
security control effectiveness and of organizational security status in accordance with
organizational risk tolerance. Security control effectiveness is measured by correctness of
implementation and by how adequately the implemented controls meet organizational needs in
accordance with current risk tolerance. Organizational security status is determined using metrics
established by the organization to best convey the security posture of an organizations
information and information systems, along with organizational resilience given known threat
information. This necessitates:
Maintaining situational awareness of all systems across the organization;
Purpose:
The purpose of this guideline is to assist organizations in the development of an ISCM strategy
and the implementation of an ISCM program that provides awareness of threats and
vulnerabilities, visibility into organizational assets, and the effectiveness of deployed security
controls. The ISCM strategy and program support ongoing assurance that planned and
implemented security controls are aligned with organizational risk tolerance, as well as the
ability to provide the information needed to respond to risk in a timely manner. Senior
management at Defense Logistics Information Service has decided that the risk management
plan for the organization is out of date. Because of the importance of risk management a new
plan needs to be developed. The risk management plan is for the organizations use only. This
new risk management plan will not only minimize the amount of risk for future endeavors, but
will also be in compliance with regulations such as the Federal Information Security
Management Act (FISMA), Department of Defense (DOD), Department of Homeland Security
(DHS), National Institute of Standards and Technology (NIST), Control Objects for Information
and Technology (COBIT), and Information Assurance Certification and Accreditation Process
(DAICAP).
Version 1.1
Scope:
This risk management plan is for the organizations use only and its network including remote
access. Any outside sources from the scope and risk management plan may cause the network
infrastructure to fail or will make it a high risk structure due to outside sources that are not
protected to interact with other outside sources allowing hackers to infiltrate the system is steal
important files. The scope of this project will include the planning, scheduling, budgeting, and
consultation needed to perform an in depth risk assessment and research to determine which
compliance laws this organization must follow. We must identify all the risks and vulnerabilities
associated with this organization and create viable solutions that may mitigate these risks as
quickly and as inexpensively as possible without compromising the integrity and confidentiality
of any business assets. A cost benefit analysis should also be conducted prior to the planning
phase of this project as well. Implementing and executing these policies and procedures in order
to mitigate these risks is a critical part of this projects process. Security features such as controls,
auditing logs, applying patches, etc. will be implemented, monitored, reported, and documented.
Other risks such as natural disasters and accidental fires/floods may also be considered risks and
should be accommodated accordingly to include a backup and disaster recovery plan.
Risk Analysis
Risks may vary greatly from natural disasters, operational errors, software vulnerabilities,
financial hardships, or even human interactions such as; attackers, buffer overflow attacks, syn
flood attacks, etc. Network and Server crashes, loss of connectivity, broken or damaged
equipment/hardware including workstations, employees calling in sick, hard deadlines not being
met, costs, no IDs, and open ports on the firewall can all be considered risks. Not having any
anti-virus software, not updating the operating systems, running unneeded services and
protocols, and not having any backups of your business assets such as files and applications are
some of the risks that should be considered critical to an organization. The severity of the
loss/impact will depend greatly on the risk associated with it.
Threat
Users
Version 1.1
Vulnerability
Lack of access
controls
Workstations/
Equipment
Failure
Malware and
viruses
Denial of Service
(DoS) or
distributed denial
of service
(DDoS) attack
Public facing
servers not
protected with
firewalls and
intrusion
detection
systems
Access controls
not properly
implemented
Stolen data
Social
engineering
Hurricane,
earthquake,
tornado
Lack of security
awareness
Lack of fire
detection and
suppression
equipment
Location
Harmful
event/loss
Loss of
production data
and
confidentiality
Loss of data
availability
(impact of loss
determined by
value of data)
Infection (impact
of loss
determined by
payload of
malware)
Loss of service
availability
Mitigation
Implement both
authentication and
access controls
Backup data
regularly, keep
copies of backup offsite
Install antivirus
software, update
definitions at least
weekly
Probability
of
occurrence
High
Medium
Medium
Implement firewalls,
implement intrusion
detection systems
High
Loss of
confidentiality of
data
Loss depends on
the goals and
success of
attacker
Implement both
authentication and
access controls, use
principle of need to
know
Provide training,
raise awareness
through posters,
occasional e-mails,
and minipresentations
Install fire detection
and suppression
equipment. Purchase
insurance
Purchase insurance,
designate alternate
backup sites
Medium
Low
Low
Low
Version 1.1
Head of Agency. The agency head is likely to participate in the organizations ISCM
program within the context of the risk executive (function). Risk Executive (Function).
The risk executive (function) oversees the organizations ISCM strategy and program.
The risk executive (function) reviews status reports from the ISCM process as input to
information security risk posture and risk tolerance decisions and provides input to
mission/business process and information systems tier entities on ISCM strategy and
requirements; promotes collaboration and cooperation among organizational entities;
facilitates sharing of security-related information; provides an organization-wide forum
to consider all sources of risk; and ensures that risk information is considered for
continuous monitoring decisions.
Chief Information Officer (CIO). The CIO leads the organizations ISCM program.
The CIO ensures that an effective ISCM program is established and implemented for the
organization by establishing expectations and requirements for the organizations ISCM
program; working closely with authorizing officials to provide funding, personnel, and
other resources to support ISCM; and maintaining high-level communications and
working group relationships among organizational entities.
Senior Information Security Officer (SISO). The SISO establishes, implements, and
maintains the organizations ISCM program; develops organizational program guidance
(i.e., policies/procedures) for continuous monitoring of the security program and
information systems; develops configuration management guidance for the organization;
consolidates and analyzes POA&Ms to determine organizational security weaknesses and
deficiencies; acquires or develops and maintains automated tools to support ISCM and
ongoing authorizations; provides training on the organizations ISCM program and
process; and provides support to information owners/information system owners and
common control providers on how to implement ISCM for their information systems.
Version 1.1
Version 1.1
Organizations may define other roles (e.g., information system administrator, ISCM program
manager) as needed to support the ISCM process. Roles and Responsibilities provided by the
National Institute of Standards and Technology (NIST) Information Security Continuous
Monitoring (ISCM) for Federal Information Systems and Organizations, Special Publication
800-137.
Take steps to respond to risk as needed (e.g., request new or revised metrics, additional or
revised assessments, modifications to existing common or PM security controls, or
additional controls) based on the results of ongoing monitoring activities and assessment
of risk.
Review new or modified legislation, directives, policies, etc., for any changes to security
requirements.
Determine the security impact of changes to the information system and its environment
of operation, including changes associated with commissioning or decommissioning the
system.
Assess ongoing security control effectiveness.
Version 1.1
Take steps to respond to risk as needed (e.g., request additional or revised assessments,
modify existing security controls, implement additional security controls, accept risk,
etc.) based on the results of ongoing monitoring activities, assessment of risk, and
outstanding items in the plan of action and milestones.
Provide ongoing input to the security plan, security assessment report, and plan of action
and milestones based on the results of the ISCM process.
Report the security status of the information system including the data needed to inform
Tiers 1 and 2 metrics.
Review the reported security status of the information system to determine whether the
risk to the system and the organization remains within organizational risk tolerances.
Version 1.1
Operational Controls comprise the operational procedures that are performed with
respect to an information system. More often than not, these vulnerabilities stem from
the lack of (or an insufficiency in) the various practices and procedures that are critical to
the secure operation of a system. Examples of operational vulnerabilities include the lack
of (adequate) security awareness and training, security monitoring and detection
provisions, personnel and physical security controls and security auditing, and the
absence of some or all of the procedural documentation critical to an effectively applied
and managed security program.
After analyzing system management, operational, and technical security controls for the Defense
Logistics Agency in its fielded environment, system vulnerabilities are then identified, mitigated,
and then monitored and reported. The analysis of the Defense Logistics Agencys systems
vulnerabilities, the threats associated with them, and the probable impact of that vulnerability
exploitation resulted in a risk rating for each missing or partially implemented control. The risk
level was determined on the following two factors:
Version 1.1
Likelihood of Occurrence - The likelihood to which the threat can exploit vulnerabilities
given the system environment and other mitigating controls that are in place.
Impact The impact of the threat exploiting the vulnerability in terms of loss of tangible
assets or resources and impact on the organizations mission, reputation or interest.
To determine overall risk levels, the analyst must first look at how important the availability,
integrity, and confidentiality of the system is in relation to it being able to perform its function,
and the types of damage that could be caused by the exercise of each threat-vulnerability pair.
Exploitation of vulnerability may result in one or more of the following types of damage to a
system or its data:
The level of risk on a project will be tracked, monitored and reported throughout the project
lifecycle. A Top 10 Risk List will be maintained by the project team and will be reported as a
component of the project status reporting process for this project. All project change requests
will be analyzed for their possible impact to the project risks. Management will be notified of
important changes to risk status as a component to the Executive Project Status Report.
Deliverable 1:
Risk Assessment- a determination of what the company will need will be made outlining what
requires attention first and in what priority if multiple items are at risk or vulnerable. The risk
assessment will also determine which threat or risk would cause the most expensive/harmful
damage to that business and the time required making those repairs.
Deliverable 2:
Security Controls- will identify how the data and resources housing the data will be protected
from unauthorized entry.
Deliverable 3:
Disaster Recovery Plan- will include back-up and redundancy; if something breaks/fails or is
Version 1.1
damaged due to fire/floods and other natural disasters this plan will outline how to repair it.
Action Plan
Create a regularly scheduled maintenance plan and include a backup and updating policy.
Create redundancy on the servers by using multiple hard drives and raid cards.
Create a firewall policy and determine what traffic should be allowed into the network
then set up these firewalls on network routers for an added layer of security.
Have extra materials onsite along with a 24 hour on call IT support for emergency calls.
Create a password policy for the organization to use complex passwords within the
network and have employees change their passwords regularly. Security breaches in the
network such as user/hacker threats may occur when passwords are stolen because
unprotected wireless networks were used.
An intrusion detection system should be put in place and monitored. Hackers may use
packet sniffers and password cracking software to gain access into the network and create
denial of service attacks. In either case security breaches can lead to serious business
damages.
Use encryption when sending and receiving data across the network. Business and
personal information may be compromised, network services could be interrupted, and
damage would depend on the type of attack suffered. Anywhere from network/server
crashes to stolen information could result in loss of production, and even loss of revenue.
A fire suppression system should be made available in the building in the event of a fire.
Version 1.1
Develop the contingency planning policy statement. A formal policy provides the
authority and guidance necessary to develop an effective contingency plan.
Backup and Recovery warm-sites. Formal Backup and Recovery policies and
procedures.
Conduct the business impact analysis (BIA). The business impact analysis helps to
identify and prioritize critical IT systems and components.
Identify preventive controls. These are measures that reduce the effects of system
disruptions and can increase system availability and reduce contingency life cycle costs.
Develop recovery strategies. Thorough recovery strategies ensure that the system can be
recovered quickly and effectively following a disruption.
Develop an IT contingency plan. The contingency plan should contain detailed guidance
and procedures for restoring a damaged system.
Plan testing, training and exercising. Testing the plan identifies planning gaps, whereas
training prepares recovery personnel for plan activation; both activities improve plan
effectiveness and overall agency preparedness.
Plan maintenance. The plan should be a living document that is updated regularly to
remain current with system enhancements
Version 1.1
Types of Teams
Recovery Scenarios
Change employee login information when an employee leaves the company. Monitor
audit logs and surveillance for more potential employee threats.
Redundancy servers, backups and off-site back-up facilities. Maintain a log of all data
stored. Have a temporary or mobile network site available for operations until the site can
be brought back online.
Recovery Activities
DLIS will define roles and responsibilities and where to assemble employees if forced to
evacuate the building and lists of key contacts and their contact information, purchased for ease
of authorizing and launching the disaster recovery plan.
Version 1.1
Date:
Print Name:
Title:
Role:
Signature:
Date:
Print Name:
Title:
Role:
Signature:
Date:
Print Name:
Title:
Role:
Signature:
Print Name:
Title:
Role:
Date: