c
 





 







c


 


` 

  ! 



 
` a
 
"" "!
 
  

 


  ! 




Data and information in any information system is at risk from:
# e.g. entering incorrect transactions; failing to spot and correct errors; processing
the wrong information; accidentally deleting data
$  e.g. hardware that fails or software that crashes during transaction processing
"
"" 
  e.g. floods, fire
a" deliberate attempts to corrupt or amend previously legitimate data and information
% & e.g. competitors deliberately gaining access to commercially-sensitive
data (e.g. customer details; pricing and profit margin data, designs)
' " where an employee or other person deliberately sets out to destroy or
damage data and systems (e.g. hackers, creators of viruses)

a
 
"" "!
 
  
There is no such thing as failsafe security for information systems. When designing security
controls, a business needs to address the following factors;
(
 What can be done to prevent security accidents, errors and breaches? Physical
security controls are a key part of prevention techniques, as are controls designing to ensure
the integrity of data
)

 Spotting when things have gone wrong is crucial; detection needs to be done as
soon as possible - particularly if the information is commercially sensitive. Detection controls
are often combined with prevention controls (e.g. a log of all attempts to achieve unauthorized
access to a network).
)
 deterrence controls are about discouraging potential security breaches.
)
( If something goes wrong (e.g. data is corrupted or hardware breaks down) it is
important to be able to recover lost data and information.

* 


$+&$  +
$ &



"(&
,%
` 

$ 
` )(&
- . 
$ 

  

$ 
÷ll information technology (IT) projects have a starting point, what is commonly referred to as
the initiation phase. During the initiation phase, the organization establishes the need for a
particular system and documents for its purpose. The information to be processed, transmitted,
or stored is typically evaluated as well as who is required to access such information and how
(in high-level terms). In addition, it is often determined whether the project will be an
independent information system or a component of an already-defined system. ÷ preliminary
risk assessment is typically conducted in this phase, and security planning documents are
initiated (system security plan).



a
 
   
[nce these tasks have been completed and a need has been recognized for a new or enhanced
IT product or service, several processes must take place before the project is approved, to
include clearly defining project goals and defining high-level information security requirements.
Typically, during this phase, the organization defines high-level information security policy
requirements as well as the enterprise security system architecture.

)(&
- . 
$ 
During this phase, the system is designed, purchased, programmed, developed, or otherwise
constructed. This phase often consists of other defined cycles, such as the system development
cycle or the acquisition cycle.
During the first part of the development/acquisition phase, the organization should
simultaneously define the system͛s security and functional requirements. These requirements
can be expressed as technical features (e.g., access control), assurances (e.g., background
checks for system developers), or operational practices (e.g., awareness and training). During
the last part of this phase, the organization should perform developmental testing of the
technical and security features/functions to ensure that they perform as intended prior to
launching the implementation and integration phase.


/ 


` '
& 
` '
 )(&
"&

 &&$
 
'
& 0Œetrics are tools that support decision making. Like experience, external
mandates, and strategies, metrics are one element of a manager͛s toolkit for making and
substantiating decisions. Œetrics are used to answer three basic questions:
͞÷

  


 






͟ Consider the example of a program
manager with responsibility for 250 information systems. ÷mong other things, that manager is
responsible for the security certification and accreditation of those systems. ÷ commonly used
implementation metric for security certification and accreditation is the percentage of systems
accredited.
͞





 



 ͟ Such metrics often answer
more complex questions after an activity is fully implemented. For example, federal law
requires that security certification and accreditation take place following a major system
change. [ne might measure the efficiency of a security certification and accreditation program
by determining the time lag between each major system change and that system͛s renewed
accreditation. [r one might measure the effectiveness of a security certification and
accreditation program by determining the number of accredited systems whose certification
process included the creation of a system security plan.
͞!

 



 





͟ ÷ctivities are initially selected with the
belief that they will contribute to the mission.
÷fter an activity is shown to be fully implemented, managers must validate that the activity is
delivering the expected benefit. These metrics are the most difficult to generate. ÷ security
certification and accreditation process may prove to have an impact by showing that fewer
interruptions or losses of data due to security incidents are experienced among correctly
accredited systems than among incorrectly accredited or non accredited systems.

'
 )(&
"&

 &&$0Two processes guide the establishment
and operation of an information security metrics program: metrics development and metrics
implementation.
The metrics development process establishes the initial set of metrics and selection of the
metrics subset appropriate for an organization at a given time. The metrics program
implementation process operates a metrics program that is iterative by nature and ensures that
appropriate aspects of information security are measured for a specific time period.


1  
$ &



2"  
`

 c"   "

%
 
÷ns: Before the system security plan can be developed; the information system and the
information resident within that system must be categorized based on a FIPS 199 impact
analysis. Then a determination can be made as to which systems in the inventory can be
logically grouped into GSSs or Œ÷s.
The FIPS 199 impact levels must be considered when the system boundaries are drawn and
when selecting the initial set of security controls (e.g., control baseline). The baseline security
controls can then be tailored based on an assessment of risk and local conditions, including
organization specific security requirements, specific threat information, cost-benefit analyses,
the availability of compensating controls, or special circumstances. Common security controls,
which is one of the tailoring considerations, must be identified prior to system security plan
preparation to identify those controls covered at the agency level that are not system specific.
These common security controls can then be incorporated into the system security plan by
reference.
The process of uniquely assigning information resources to an information system defines the
security boundary for that system. ÷gencies have great flexibility in determining what
constitutes an information system (i.e., Œ÷ or GSS). If a set of information resources is
identified as an information system, the resources should generally be under the same direct
management control. Direct management control does not necessarily imply that there is no
intervening management. It is also possible for an information system to contain multiple
 . ÷ subsystem is a major subdivision or component of an information system
consisting of information, information technology (IT), and personnel that perform one or more
specific functions.

 
"

( &&$ 
  !   
   !'
 &&$ 0÷n organization can select one of five possible
approaches to dealing with risks. The default response is crisis management, the knee-jerk
reaction undertaken when a previously unidentified or unmanaged risk develops into a clear
and present danger. [nly slightly better is to fix the product when a failure is encountered. ÷
more proactive approach is to identify the risks facing your project and plan how you͛ll respond
to them if they raise their ugly heads. Still better is to take concrete actions to prevent those
identified risks from ever causing trouble. The ultimate in risk management is to eradicate the
root causes that cause certain risks to chronically threaten your organization͛s projects.
3
 is the application of appropriate tools and procedures to contain risk within
acceptable limits. Risk management consists of several sub disciplines.
3




 is the process of examining a project and identifying areas of potential risk.
3

   can be facilitated with the help of a checklist of common risk areas for
software projects, or by examining the contents of an organizational database of previously
identified risks and mitigation strategies (both successful and unsuccessful)... 3



involves examining how project outcomes might change with modification of risk input
variables.
3
   helps the project focus on its most severe risks by assessing the risk
exposure. Exposure is the product of the probability of incurring a loss due to the risk and the
potential magnitude of that loss.
This prioritization can be done in a quantitative way, by estimating the probability (0.1 ʹ 1.0)
and relative loss, on a scale of 1 to 10. Œultiplying these factors together provide an estimation
of the risk exposure due to each risk item, which can run from 0.1 (don͛t give it another
thought) through 10 (stand back, here it comes!). The higher the exposure, the more
aggressively the risk should be tackled. It may be easier to simply estimate both probability and
impact as High, Œedium, or Low. Those items having at least one dimension rated as High are
the ones to worry about first.
3

is one way to deal with risk: don͛t do the risky thing! You may avoid risks by
not undertaking certain projects, or by relying on proven rather than cutting edge technologies.
3
   is the process of managing risks to achieve the desired outcomes. 3

  produces a plan for dealing with each significant risk, including
mitigation approaches, owners, and timelines. 3

 is execution of the plans for
dealing with each risk. Finally, 
   involves tracking your progress toward resolving
each risk item.
Simply identifying the risks facing your project is not enough. We need to write them down in a
way that lets us communicate the nature and status of risks throughout the affected project
stakeholder community over the duration of the project. Figure 1 shows a form I have found to
be convenient for documenting risks. This risk list could be included as a section in your
software project plan, or it could remain as a standalone document.
When documenting risk statements, use a 
format. That is, state the risk
situation (condition) that you are concerned about, followed by at least one potential adverse
outcome (consequence) if that risk should turn into a problem. [ften, people suggesting risks
may state only the condition ("the customers don͛t agree on the product requirements") or the
consequence ("we can only satisfy one of our major customers"). Pull those together into the
condition-consequence structure: "The customers don͛t agree on the product requirements, so
we͛ll only be able to satisfy one of our major customers."

 
$ &

"
  & 23&
` )

"   
` %

24"
" (
 
` )

"  
Detection and analysis are, for many organizations, the most challenging aspects of the incident
response process, in other words, accurately detecting and assessing possible incidents ʹ
determining whether an incident has occurred and, if so , the type, extent, and magnitude of
the problem. Incident can be detected through many different means, with carrying levels of
detail and fidelity. ÷utomated detection capabilities include network- based and host- based
intrusion detection systems (IDSs), antivirus software, and log analyzers. Incidents may also be
detected through manual means, such as use reports. Some incidents have overt signs that can
be easily detected, whereas others are critically undetectable without automation.
In a typical organization, the thousands or millions of possible signs of incidents that occur any
given days are recorded mainly by computer security software. ÷utomation is needed to
perform an initial analysis of the data and select events of interest for human review. Event
correlation software and centralized logging standards and procedures to ensure that adequate
information is collected by logs and security software and that the data is reviewed regularly.
Proper and efficient reviews of incident ʹ related data require people with extensive.
Specialized technical knowledge and experience.
When a potential incident is identified, the incident response team should work quickly to
analyze and validate it, documenting each step taken. The team should rapidly perform an
initial analysis to determine the incident͛s scope attack methods and targeted vulnerabilities.
This analysis should provide enough information for the team to prioritize subsequent
activities, including the containment of the incident. When in doubt, incident handlers͛ addition
to prioritization guidelines, organizations should also establish and fails to respond to an
incident with in the designated time.
The incident response team should maintain records about the status of incidents, along with
other pertinent information. Using an application or database for this purpose is necessary to
ensure that incidents are handled and resolved in a timely manner. The incident response team
should safeguard this data and other data related to incidents because it often contains
sensitive information concerning recent security breaches exploited vulnerabilities, and users
that may have performed inappropriate actions.

` %

2"
2" (
It is important to contain an incident before it spreads to avoid overwhelming resources and
increasing damage caused by the incident. Œost incidents require containment, so it is
important to consider it early in the course of handling each incident. ÷n essential part of
containment is decision making, such as shutting down a system functions. Such decisions are
much easier to make if strategies and procedures for containing the incident have been
predetermined. [rganization should define acceptable risks in dealing with incidents and
develop strategies accordingly.
Containment strategies vary based on the type of incident. For example, the overall strategy for
containing an e-mail-borne virus infection quite different from that of a net work-based
distributed denial of service attack. [rganizations should create separate containment
strategies for each major type of incident. The criteria for choosing the appropriate strategy
should be documented clearly to facilitate quick and effectiveness of the strategy, the time and
resources needed to implement the strategy, and the duration of the solution.
÷fter an incident has been contained, eradication may be necessary to eliminate components
of the incident, such as deleting malicious code and disabling beached user accounts. For some
incidents, eradication is either unnecessary or is performed during recovery. In, administrators
restore systems to normal operation and (if applicable) harden systems to prevent similar
incidents. Recovery may involve such actions as:
` Restoring systems from clean backups;
` Rebuilding systems from scratch;
` Replacing compromised files with clean versions;
` Changing passwords; and tightening network perimeter security (e.g., firewall rule sets)

It is also often desirable to employ higher levels of system process. [nce a resource within the
organization are attacked in a similar manner.
 
 c
 




 
*






c


  


$
 
& +
$ &


  $
  

  5
  

   !  

 
 $
  

÷
!
!needs to be undertaken of the information and processes involved, their sensitivity
from the perspectives of the various stakeholders, and their attractiveness to other parties. This
needs to be followed by analysis of the nature, source and situation of threats. The 
 

$
 of a variety of kinds, including access to data by unauthorized persons, disclosure of
it to others, its alteration, and its destruction. The  
$
$
include several
categories of entities:
÷ person who has authorization to access the data, but for a purpose different from that for
which they use it;
÷n intruder, who has no authorization to access the data, including:
o an interceptor of data during a transmission; and
o a 'cracker' who gains access to data within storage; and
an unauthorized recipient of data from an intruder.
The 

 
$
$
include several categories of locations:
Within &  2

""

;
Within the &$ &  housing facilities connected with the system; and
Within
$6
7 &
"
 
 , including:
o "

, including:
permanent storage, such as hard disk, including high-level cache;
transient storage, such as R÷Œ, including low-level cache and video R÷Œ;
archival storage;
o 
+that:
receives data;
stores data (e.g. a file-handler or database manager);
 renders data (e.g. a viewer or player);
despatches data; and
enables access to the data, in any of the above storage media (e.g. disk utilities and screen-
scrapers); and
o
  , including via:
discrete media (e.g. diskettes, CD-R[Œs); and
electronic transmission over local area and wide area networks;
within 
$&&8 &
"
 
 , e.g.:
o a workstation on a trusted network that is cracked by an intruder;
o a powerful computer that is cracked, and that is used to crack one or more passwords on the
organisation's computers;
o one or more weakly protected machines that are cracked and then used to launch denial of
service (D[S) or distributed denial of service (DD[S) attacks against the organisation's servers
or networks;
Within &&


, including electrical supplies, airconditioning, and fire
protection systems.

 5
  

The existence of a threat does not necessarily mean that harm will arise.
For example, it is not enough for there to be lightning in the vicinity. The lightning has to
actually strike something that is relevant to the system.
Further, there has to be some susceptibility within the system, such that the lightning strike can
actually cause harm. The purpose of the Vulnerability
÷ssessment is to identify all such susceptibilities to the identified threats, and the nature of the
harm that could arise from them.
It is common for vulnerabilities to be countered by safeguards. For example, safeguards against
lightning strikes on a facility include lightning a rod on the building in which it is housed.
Safeguards may also exist against threatening events occurring in situations remote to the
system in question. For example, a lightning strike on a nearby electricity substation may result
in a power surge, or a power outage in the local facility. This may be safeguarded against by
means of a surge protector and an Uninterruptable Power Supply (UPS).
Every safeguard creates a further round of vulnerabilities, including susceptibilities to threats
that may not have been previously considered. For example, a UPS may fail because the
batteries have gone flat and not been subjected to regular inspections, or because its operation
is in fact dependent on the mains supply not failing too quickly, and has never been tested in
such a way that that susceptibility has become evident.

  !  

The term 'risk' is used in many different senses (including as a synonym for what was called
above 'threat', and 'harm', and even 'vulnerability'!). But when security specialists use the word
'risk', they have a very specific meaning for it: a measure of the likelihood of harm arising from
a threat.
Risk assessment builds on the preceding analyses of threats and vulnerabilities, by considering
the likelihood of threatening events occurring and impinging on vulnerability.
In most business contexts, the risk of each particular harmful outcome is not all that high. The
costs of risk mitigation, on the other hand, may be very high. Examples of the kinds of costs
involved include:
The time of managers, for planning and control;
The time of operational staff and computer time, for regular backups;
The loss of service to clients during backup time;
÷dditional media, for storing software and data;
The time of operational staff, for training;
duplicated hardware and networks; and
contracted support from alternative 'hot-sites' or 'warm-sites'.
Risks have varying degrees of likelihood, have varying impacts if they do happen, and it costs
varying amounts of time and money in order to establish safeguards against the threatening
events or against the harm arising from a threatening event. The concept of `absolute security'
is a chimera; it is of the nature of security that risks have to be managed. It is therefore
necessary to weigh up the threats, the risks, the harm arising, and the cost of safeguards. ÷
balance must be found between predictable costs and uncertain benefits, in order to select a
set of measures appropriate to the need.
The aim of risk assessment is therefore to determine the extent to which expenditure on
safeguards is warranted in order to provide an appropriate level of protection against the
identified threats.

*  
$ &



"(&
,%23&
` [&
 -'
$ 
` ) & $ 

 
[&
 -'
$ 0÷n effective security program demands comprehensive and
continuous understanding of program and system weaknesses. In the operation and
maintenance phase, systems and products are in place and operating, enhancements and/or
modifications to the system are developed and tested, and hardware and/or software is added
or replaced. During this phase, the organization should continuously monitor performance of
the system to ensure that it is consistent with pre established user and security requirements,
and needed system modifications are incorporated. For configuration management (CŒ) and
control, it is important to document the proposed or actual changes in the security plan of the
system. Information systems are typically in a constant state of evolution with upgrades to
hardware, software, firmware, and possible modifications to the surrounding environment
where the system resides. Œonitoring security controls helps to identify potential security-
related problems in the information system that is not identified during the security impact
analysis, which is conducted as part of the CΠand control process.

) & $ 0The disposal phase of the system life cycle refers to the process of preserving
(if applicable) and discarding system information, hardware, and software. This step is
extremely important because during this phase, information, hardware, and software are
moved to another system, archived, discarded, or destroyed. If performed improperly, the
disposal phase can result in the unauthorized disclosure of sensitive data. When archiving
information, organizations should consider the need and methods for future retrieval. While
electronic information is relatively easy to store and retrieve, problems can arise if the
technology used to create the records is no longer available in the future as a result of
obsolescence or incompatibility with new technologies. ÷dditionally, the organization should
consider what measures must be taken for the future use of data that has been encrypted, such
as taking appropriate steps to ensure the secure long-term storage of cryptographic keys. It is
equally important to consider legal requirements for records retention when disposing of
information systems. The removal of information from a storage medium, such as a hard disk or
tape, is called sanitization. There are four categories of media sanitization: disposal, clearing,
purging, and destroying. Because different kinds of sanitization provide different levels of
information protection, organizations should use information security requirements as a guide
for selecting the sanitization method that best suits their needs.

/  
$ &

'
 &&

23&
` &)
%

` %
)
" 6  

` "
%
( 
 

 
&)
%
0Prepare for Data Collection Phase 1 of the process, Prepare
for Data Collection, involves activities that are key for establishing a comprehensive
information security metrics program. These activities include the information security
metrics identification, definition, development, and selection activities, and developing a
metrics program implementation plan.
 ÷fter the metrics have been identified, specific implementation steps should be defined on
how to collect, analyze, and report the metrics. These steps should be documented in the
metrics program implementation plan. The following items may be included in the plan:
Œetrics roles and responsibilities, including responsibilities for data collection (both
soliciting and submitting), analysis, and reporting;
÷n audience for the plan;
Process of metrics collection, analysis, and reporting that is tailored to the specific
organizational structure, processes, policies, and procedures;
Details of coordination with the chief information officer (CI[), such as with risk
assessment, security certification and accreditation, and FISŒ÷ reporting activities;
Details of coordination between the CI[ and other functions within the agency, external
to the CI[ (e.g., Information ÷ssurance (I÷), if separate from the CI[; physical security;
personnel security; and critical infrastructure protection [CIP]) to ensure that the metrics
data collection is streamlined and non intrusive;
Creation or selection of data collection and tracking tools;
Œodifications of data collection and tracking tools; and
Œetrics summary reporting formats.

%
)
" 6  

Phase 2 of the process, Collect Data and ÷nalyze Results, involves activities that are essential
for ensuring that the collected metrics are used to gain an understanding of system security and
to identify appropriate improvement actions. This phase includes the following activities:
Collect metrics data according to the processes defined in the metrics program
implementation plan;
Consolidate collected data and store in a format (i.e., a database or a spreadsheet) conducive
to data analysis and reporting;
Conduct gap analysis compares collected measurements with targets if defined, and identifies
gaps between actual and desired performance;
Identify causes of poor performance; and
Identify areas requiring improvement.
The causes of poor performance can often be identified using the data from more than one
metric. For example, determining that the percentage of approved security plans is
unacceptably low would not be helpful for determining how to correct the problem. To
determine the cause of low compliance, collect information on the reasons for low percentages
(e.g., lack of guidance, insufficient expertise, or conflicting priorities). This information can be
collected as separate metrics or as implementation evidence for the percentage of approved
security plans. [nce this information is collected and compiled, the agency should develop a
correction plan to address the root cause of the problem.
Root causes for faulty security run the gamut between highly technical mis configuration issues
to lack of training or outdated policies or practices.
Below are examples of causation factors that contribute to poor security control
implementation and effectiveness:
Resources ʹ insufficient human, monetary, or other resources;
Training ʹ lack of appropriate training for the personnel installing, administering, maintaining,
or using the systems;
System Upgrades ʹ security patches that have been removed but not replaced during the
operating system upgrades;
Configuration Œanagement (CŒ) Practices ʹ new or upgraded systems that are not
configured with required security settings and patches;
Software Compatibility ʹ security patches or upgrades that are incompatible with software
applications supported by the system;
÷wareness and Commitment ʹ lack of management awareness and/or commitment to
security;
Policies and Procedures ʹ lack of policies and procedures that are required to ensure
existence, use, and audit of required security functions;
÷rchitectures ʹ poor system and security architectures that make systems vulnerable; and
Inefficient Processes ʹ inefficient planning and communication processes that influence the
metrics.

"
%
( 
 
Phase 3 of the process, Identify Corrective ÷ctions, involves developing a plan that will provide
the roadmap of how to close the implementation gap identified in Phase 2. This phase includes
the following activities:
)
 %
( 
 Based on the results and causation factors, identify
corrective actions that could be applied to each performance issue. Corrective actions may
include changing system configurations; training security staff, system administrator staff,
or regular users; purchasing security tools; changing system architecture; establishing new
processes and procedures; and updating security policies.

6%
( 
 c "[(  !'


9 Several corrective actions may be applicable to a single performance issue; however,
some may be inappropriate if they are inconsistent with the magnitude of the problem or are
too costly. ÷pplicable corrective actions should be prioritized for each performance issue in the
ascending order of cost and descending order of impact. It is advised in various reports
published by number of agencies that 3
  


 

 

 , should be used for prioritizing corrective actions. If weights were assigned to metrics
in Phase 1, 

!
", they should be used to prioritize corrective actions.
÷lternatively, weights may be assigned to corrective actions in Phase 3, 
"

÷#
based on the criticality of implementing specific corrective actions, the cost of
corrective actions, and the magnitude of corrective actions͛ impact on the organization͛s
security posture.


'
 &&&
%
( 
 Up to three corrective actions from the top of
the list of prioritized corrective actions should be selected for conducting a full cost-benefit
analysis. These selections should then be appropriately reflected in the agency or system
P[÷ Œs.

1 

(  
& " & 
 

 

  "  & 
 
÷gencies should develop policy on the system security planning process. System security plans
are living documents that require periodic review, modification, and plans of action and
milestones (P[÷ Œ) for implementing security controls. Procedures should be in place
outlining who reviews the plans, keeps the plan current, and follows up on planned security
controls. In addition, procedures should require that system security plans be developed and
reviewed prior to proceeding with the security certification and accreditation process for the
system. During the security certification and accreditation process, the system security plan is
analyzed, updated, and accepted. The certification agent confirms that the security controls
described in the system security plan are consistent with the FIPS 199 security category
determined for the information system, and that the threat and vulnerability identification and
initial risk determination is identified and documented in the system security plan, risk
assessment, or equivalent document. The results of a security certification are used to reassess
the risks, develop the P[÷ Œs that are required to track remedial actions, and update the
system security plan, thus providing the factual basis for an authorizing official to render a
security accreditation decision.

 %$
[
The chief information officer (CI[) is the agency official responsible for developing and
maintaining an agency-wide information security program and has the following system
security planning responsibilities:
Designating an S÷IS[ who shall carry out the CI['s responsibilities for system security
planning;
Developing and maintaining information security policies, procedures, and control techniques
to address system security planning;
Œanaging the identification, implementation, and assessment of common security controls;
Ensuring that personnel with significant responsibilities for system security plans are trained;
 ÷ssisting senior agency officials with their responsibilities for system security plans; and
Identifying and developing common security controls for the agency.

c  


[+
The information system owner is the agency official responsible for the overall procurement,
development, integration, modification, and operation and maintenance of the information
system. The information system owner has the following responsibilities related to system
security plans:
Developing the system security plan in coordination with information owners, the system
administrator, the information system security officer (ISS[), the S÷IS[, and functional "end
users";
Œaintaining the system security plan and ensuring that the system is deployed and operated
according to the agreed-upon security requirements; and
Ensuring that system users and support personnel receive the requisite security training (e.g.,
instruction in rules of behavior) and assisting in the identification, implementation, and
assessment of the common security controls.

%  
[+
The information owner is the agency official with statutory or operational authority for
specified information and is responsible for establishing the controls for information
generation, collection, processing, dissemination, and disposal. The information owner has the
following responsibilities related to system security plans:
Establishing the rules for the appropriate use and protection of the subject data/information
(rules of behavior);
Providing input to information system owners on the security requirements and security
controls for the information systems where the information resides;
Deciding who has access to the information system and determining what types of privileges
or access rights; and
÷ssisting in identifying and assessing the common security controls where the information
resides.

) 
 


[
The S÷IS[ is the agency official responsible for serving as the CI[͛s primary liaison to the
agency͛s information system owners and ISS[s. The S÷IS[ has the following responsibilities
related to system security plans:
Carrying out the CI[͛s responsibilities for system security planning;
 Coordinating the development, review, and acceptance of system security plans with
information system owners, ISS[s, and the authorizing official;
Coordinating the identification, implementation, and assessment of the common security
controls; and
Possessing professional qualifications, including training and experience, required to develop
and review system security plans.

4  




[
The ISS[ is the agency official assigned responsibility by the S÷IS[, authorizing official,
management official, or information system owner for ensuring that the appropriate
operational security posture is maintained for an information system or program. The ISS[ has
the following responsibilities related to system security plans:
÷ssisting the S÷IS[ in identifying, implementing, and assessing the common security controls;
and
÷ctively supporting the development and maintenance of the system security plan, to include
coordinating system changes with the information system owner and assessing the security
impact of those changes.

 


`  ! 

+:
'

`  !'
 &&$ 

   ! 

+:
'

Unlike the hazards of daily living, the dangers in the young and emerging field of software
engineering must often be learned without the benefit of lifelong exposure. ÷ more deliberate
approach is required. Such an approach involves studying the experiences of successful project
managers as well as keeping up with the leading writers and thinkers in the field. [ne such
writer in the area of risk is Dr. Barry W. Boehm. In his article "Software Risk Œanagement:
Principles and Practices" he lists the following top 10 software risk items:
1. Personnel Shortfalls
2. Unrealistic schedules and budgets
3. Developing the wrong functions and properties
4. Developing the wrong user interface
5. Gold-plating
6. Continuing stream of requirements changes
7. Shortfalls in externally furnished components
8. Shortfalls in externally performed tasks
9. Real-time performance shortfalls
10. Straining computer-science capabilities

 !'
 &&$ 
÷n organization can select one of five possible approaches to dealing with risks. The default
response is crisis management, the knee-jerk reaction undertaken when a previously
unidentified or unmanaged risk develops into a clear and present danger. [nly slightly better is
to fix the product when a failure is encountered. ÷ more proactive approach is to identify the
risks facing your project and plan how you͛ll respond to them if they raise their ugly heads. Still
better is to take concrete actions to prevent those identified risks from ever causing trouble.
The ultimate in risk management is to eradicate the root causes that cause certain risks to
chronically threaten your organization͛s projects. Risk management is the application of
appropriate tools and procedures to contain risk within acceptable limits. Risk management
consists of several sub disciplines.

 
$ &

"
  & 23&
` &"
  & 
` &
%
"
)

 
` &"
  & 
÷n organization and its constituents must be prepared to respond to an incident, just as it must
be prepared to react to any other kind of emergency (for example, a fire). ÷lso, ideally,
constituents (that is, an organization's customers in the context of this article) and CSIRTs are
expected to prepare for incidents before any incident actually happens. ÷lthough, in most
cases, preparations happen in stages to reach a completed state.
There are six primary phases that the preparation of incident response must cover:

` %
"
  & 

` )(&"
  & " &
"

` 4
 $9" 
+
$43



` )"
  & 
(

`




"

'"

`

"

$"
  & 
÷ll six phases are equally important to prepare for and to ensure that a security incident is
quickly resolved with a minimum impact to the business operation. The follow-up phase
includes a postmortem session that is extremely important for the VCSIRT and the worldwide
security team to review areas that are overlooked during the process. ÷ shortfall at any phase
might impact the process in the next phase and might ultimately affect the entire process.
Every incident is unique, and the experience gained from handling one incident can provide
lessons that are helpful in different phases, as depicted in the feedback loop in the diagram.

Complexity of the incidents and their implications in terms of losses to businesses have made it
an absolute necessity to prepare. The primary categories of tasks include:

` [btaining personnel who are skilled in security for incident servicing organizations to deal
with incident issues as they occur

` Setting up defense-in-depth within the infrastructures (defined in the next section) at the
constituent site and at the VCSIRTs parent organization's site for communication between
them

` Establishing an infrastructure in the customer's enterprise to support incident response

process and to mitigate risks that have adverse effects on the business

` Creating the servicing enterprise organization's infrastructure processes and procedures to

deal with incidents effectively

In the early stages of the formation of the organization's worldwide security team, there will be
ad hoc approaches to incident response, but as the organization becomes more established and
mature, policies, procedures, and standards must be developed. This topic will be discussed in
detail in a future article on proactive teamwork.


` &
%
"
)

[rganizations should be prepared to collect a set of object and subjective data for each
incident. [ver time, the incident data collected by the organization can be used for many ends,
for examples, data on the total number of hours the incident response team has dedicated to
incident response activities and its cost over a particular period of time, may be used to justify
additional functioning of the incident response tea,. ÷ study of threats, changes in incident
trends, to other data that can be used in support of the risk assessment process. ÷nother good
use of the data is measuring the success of the incident response team. If incident data is
collected and stored properly, it should provide several measures of the success of the incident
response team. Furthermore, organizations that are required to report incident information will
need to collect the necessary data to meet their requirements.

In the process of preparing to collect incident data, organizations should focus on

collecting data that is actionable, rather than collection simply because it is available.
÷bsolutely numbers are not informative ʹ understanding how they represent threats to and
vulnerabilities of the business processes of the organization is what matters. [rganizations and
on the expected return on investment from the data.