NIST IT Standards for Local Governments 2010

Implementing NIST for Local
Governments
Rev 1 (JUN 2010)© 2010 Maze & Associates1

Introductions
Name
Employer
Security Experience
NIST Experience
Rev 4 (Jan 2010)2 © 2010 Maze & Associates

Suggested Materials
 Building and Implementing a Security
Certification and Accreditation Program,
Official (ISC)2 Guide to the CAP CBK, by
Patrick D. Howard
 NIST SP 800-100
 NIST SP 800-37 rev 1

Introduction
Rev 4 (Jan 2010)© 2010 Maze & Associates4

Introduction
 Due Diligence
 Standards
 NIST / FISMA Background
 A Risk Based Approach
 What is Certification and Accreditation
 Systems Security Approach
 Benefits
 External Drivers

Question
 How do you explain to someone
who does not understand firewalls
that your organization has done
everything it should to protect your
organization?
 How do you demonstrate due
diligence in IT?

Solution
 The only way to show you have done
everything you should, to someone
who does not understand the technical
aspects, is to show you follow an
industry standard.
 The only way to show due diligence is
to use an industry standard.
 An industry standard properly vetted
by professionals or authorities

Following a standard
 Actions and needs are
explainable and defendable
 Help when you need to fight for
resources
 In accounting you have GAAP
 In IT you have NIST

NIST
 There is no compulsory IT standard required for local
governments.
 The National Institute of Standards andTechnology
(NIST) encourages state, local and tribal governments to
consider the use of these guidelines, as appropriate.
 In adopting NIST standards the local government
demonstrates due diligence.
"State, local, and tribal governments, as well as private sector organizations are
encouraged to consider using these guidelines, as appropriate."
- NIST SP 800-37 Rev 1 pg 11

State of California
 The State of
California is going
to adopt NIST
standards
 Modified version
 NIST SP 800-53
 NIST SP 800-37

Other Standards
 Yes there are other standards
 PCI
 ISO 27002 (ISO 17799)
 COBIT
 Etc..
 If ever a local government is required to follow a standard
it would be NIST
 NIST is recommend by DOJ for local police
 NIST is a Government friendly standard

PCI & NIST
 PCI has a narrow focus (just card holder data)
 NIST has a broad focus (all of IT)
 If you focus on PCI only you may sacrifice in other areas
 If you implement a standard like NIST you are 90% there
for PCI
 If a new regulation comes up you are already prepared

NIST/FISMA Background
 E-Government Act (Public Law 107-347) passed and
signed into law in December 2002
 Title III of the E-Government Act, Federal Information
Security Management Act (FISMA)
 Required for all government agencies
 To develop, document, and implement an agency-wide
information security program
 To provide information security for the information and
systems that support the operations and assets of the
agency
 Applies to contractors and other sources

A Risk Based Approach
 Emphasize a risk-based policy for cost-effective security
 FISMA
 The Paperwork Reduction Act of 1995
 The Information Technology Management Reform Act of 1996
(Clinger-Cohen Act)
 Supported by Office of Management and Budget (OMB)
through Circular A-130,Appendix III, Security of Federal
Automated Information Resources
 OMB defines as adequate security, or security commensurate
with risk, to include the magnitude of harm resulting from the
unauthorized access, use, disclosure, disruption, modification,
or destruction of information.

Certification and Accreditation
“Certification and accreditation is the methodology
used to ensure that security controls are established
for an information system, that these controls are
functioning appropriately, and that management has
authorized the operation of the system in is current
security posture.”
- Official (ISC)2 Guide to the CAP CBK

Certification
 Detailed security review of an information system
 Comprehensive assessment of
 Management security controls
 Operational security controls
 Technical security controls
 To determine the extent to which the controls are
 Implemented correctly
 Operating as intended
 Producing the desired outcome
 Providing the factual basis for an authorizing official to
render a security accreditation decision

Accreditation
 Security accreditation is the official management decision
to operate
 Given by a senior agency official (management)
 The official should have the authority to oversee the
budget and business operations of the information system
 Explicitly accept the risk to
 operations
 assets
 individuals
 Accepts responsibility for the security of the system
 Fully accountable for the security of the system

System Security Approach
 Security not at the application, device, data or user level
 Security that encompasses a system made up of
applications, devices, data and users.
 Easier and more cost effect to define ‘systems’ with
boundaries and perimeters
 Implement controls based upon the system and not the
entire enterprise

Benefits
 Information security visibility
 Management involvement
 Management due diligence
 Integrate security
 Consistent implementation
 Common goal
 Ensure minimum security
 Ensure proper controls in place
 Ensure risk-based controls
 Efficient use of resources and funds

External Drivers
 Security Incidents
 Financial scandals
 Terrorist attacks
 Natural disasters
 Sarbanes-Oxley
 Health Insurance Portability and Accountability Act
 Gramm-Leach-Bliley Act
 Clinger-Cohen
 FISMA
 PCI

Building a Successful Enterprise Certification
and Accreditation (C & A) Program
Section I

Key Elements of an Enterprise C & A
Program
Chapter 1

The C & A business case
 What is the benefit to the organization?
 Due diligence
 Accountability
 Implementation of risk management
 Visibility of risk
 Cost-effectiveness
 A strong business case will help enlist support
 The C & A program will help them meet their
organizational needs, reach their goals and accomplish
their mission
 C & A is a business enabler

C & A goal setting
 Typical project management
 Goals must be:
 Realistic
 Comprehensive
 Integrated
 Achievable
 Effective
 Supported
 Enduring
 The organizations management, culture, personality and
security posture all play a part.

Establishing program tasks and milestone
 Typical project management
 Project management is the discipline of planning, organizing and
managing resources to bring about the successful completion
of specific project goals and objectives.
 A Project is made up of multiple stages, tasks and
milestones.
 A milestone is the end of a stage that marks the
completion of a work phase
 A task is an activity that needs to be accomplished within
a defined period of time

Overseeing program execution
 Constant measurement, metrics
 Ensure program requirements are
being met
 Tracking process
 Need to have some way to enforce
project management and include
escalation
 A security oversight committee can
provide oversight to the C&A
program

Maintaining program visibility
 Need consistent management support
 Without management support people
will not fulfill their obligations to the
project
 Without management support you will
not have access to needed resources
and funding
 The Chief Information Security Officer
(CISO) can keep the program visible by
giving regular updates to c-level
management

Resources
 What types of resources might the project need?
 Funds, money, budget
 People, man-hours
 Processes
 Technology
 Outside expertise
 Training
 Automated tools
 Use realistic requirements

Developing guidance
 Document what the program is
 Document how you plan to implement
 Sample Documents
 Policies
 Standards
 Guidelines
 Procedures
 Should meet organizational business
needs
 Describe the process
 Precise, clear and brief

Sample C & A Policy
Reference: http://www.tess-llc.com/Certification%20&%20Accreditation%20PolicyV4.pdf

C & A Guidance Development Life Cycle
• Awareness
• Monitoring
• Enforcement
• Maintenance
• Retirement
• Communication
• Compliance
• Exceptions
• Creation
• Review
• Approval
Development Implementation
MaintenanceDisposal
Life-cycle for the development of the documentation for the C & A process

Guidance caution
 Too many rules limit the
latitude and innovation that
may be needed at lower levels
 Long, cumbersome guidance
documents will be ignored
 Limits agility
 Should be easy to access
 Intranet site
 System administrators need to
use regularly

C & A process flow
Conduct Minimum
Security Baseline
Assessment
•Minimum Security
Baseline Report
Assess Risks
•Risk Assessment
Report
Perform Vulnerability
Scanning
•Vulnerability Scan
Results
Develop Security Plan
•Draft System
Security Plan
Perform Certification
Testing
•Certification Test
Plan
Prepare Certification
Package
•Certification Test
Results
•Updated System
Security Plan
•Certification
Statement
Submit Certification
Package
•Transmittal
Accredit System
•Accreditation
Statement

System Owner
Authorizing Official
Certification Agent
Prepare
Documentation
Initiation Phase 1
1. Describe the System
2. Categorize its C.I.A.
3. Identify Threats to it
4. Identify its Vulnerabilities
5. Identify In-Place and
Planned Security Controls
6. Determine its Initial Risks
Initiation
NIST 800-37 Risk Management & Certification and Accreditation Tasks
Notify Officials &
Identify
Resources
Planning Phase 3
1. Notify Program Officials
2. Identify Resources Needed
and Plan execution of
Activities
Initiation
Report & Document
Status
O&M Phase 9
1. Update Security Plan
2. Update Plan of Action
& Milestones
3. Report Status
Monitoring
Monitor Security
Controls
O&M Phase 9
1. Select In-Place Security
Controls
2. Assess Selected
Security Controls
Monitoring
Manage & Control
Configuration
O&M Phase 9
1. Document System
Changes
2. Analyze Security
Impacts
Monitoring
Analyze, Update
& Accept System
Security Plan
Multiple Phases 4-6
1. Review Security C.I.A.
Categorizations
2. Analyze Security Plan
4. Obtain Authorizing
Official Acceptance of
Security Plan
Initiation
Assess & Evaluate
Security Controls
Integration & Test
Phase 7
1. Prepare Documentation &
Supporting Materials
2. Review Methods and
Test Procedures
3. Assess & Evaluate In-
Place Security Controls
4. Report Security
Assessment Results
Certification
Document Security
Accreditation
Integration & Test
Phase 7
1. Transmit Security
Accreditation Package
Accreditation
Document Security
Certification
Integration & Test
Phase 7
1. Provide Findings and
Recommendations
3. Prepare Plan of Action &
Milestones
4. Assemble Accreditation
Package
Certification
Make Security
Accreditation
Decision
Integration & Test
Phase 7
1. Determine Final Risk
Levels
2. Accept Residual Risk
Accreditation
System Owner
Phase 1 – Task 1
Phase 3 – Task 6
Phase 1 – Task 2 Phase 1 – Task 3 Phase 2 – Task 4 Phase 2 – Task 5
Phase 3 – Task 7 Phase 4 – Task 8 Phase 4 – Task 9 Phase 4 – Task 10
Primary Responsibility
SDLC
NIST 800-37
Phases

Program integration
 Security needs to be baked into the
organization
 C & A program should integrate
with other organizational programs,
processes and activities
 For example
 Integrate with human resources for
background checks
 Guard service for physical security
 Accounting for procurement and
budget

Establishing C & A points of contact
 Chief Information Security Officer (CISO) is directly
responsible.
 Other key players
 System Owners
 C & AWorkgroup
 Security Steering Committee
 IT administrators
 Key areas of knowledge for Organizations
 Operations
 Hierarchy
 Management
 Strategies
 Initiative

Measuring progress
 Need to have a method for measuring progress and
effectiveness.
 Dashboard for an over-all status and where additional
resources are needed.
 Scope
 Tasks
 Systems
 Risk
 Need and Sensitivity
 Time
 Effort
 Budget
 Cost

Tracking program activities
 Keep your eyes on the road
 Know where you are
 Determine potential hazards (Problem forecasting)
 Determine outside influences (Track external projects)
 Keep people informed (Reporting)
 Know what you have (Resource monitoring)

Tracking compliance
 How do you hit a moving target?
 Maintenance Phase (keep your guard up)
 Updates and maintenance (systems and documentation)
 Plan of Actions and Milestones (POA&M)
 Open items that need to be addressed (mitigation)
 RecertificationTriggers or Reassessment Risk
 NewVulnerabilities
 New Risks
 Environment changes
 Control failure
 Audit findings

Providing advise & assistance
 Need to strive for a consistent approach within the
program
 Multiple systems and system owners (Enterprise wide)
 Maintain flexibility for individual systems
 Seek advice of professionals
 Take suggestions
 Document understandings

Responding to change
 Need a process to know when a change has been made
that will effect the C & A of a system
 Is the change a material change?
 Significant changes modify the risk to the system
 Recertification Triggers or Reassessment Risk
 NewVulnerabilities (major possibly, minor are handled by patch
management)
 New Risks (brought about by changes)
 Environment changes (Application or OS change)
 Control failure (Controls not working as intended)
 Audit findings (Missing controls)

Program awareness, training and education
 In order to maintain the C & A program
 Constant reminders – awareness
 Training – program training – depending on
role
 Education – security and C & A related
continuing education
 Possible to integrate with other training
and awareness programs within the
organization
 Track training

Use of expert systems
 Automated tools
 Tracking systems
 C & A document management systems
 Audit log management
 Dashboards
 Intrusion Prevention Systems
 Etc.

Waivers and exceptions to policy
 There needs to be a process to handle exceptions
 How will you consider waivers?
 Who makes the decision?
 Can the decision be made in a timely fashion?
 How will the decision be documented?
 Does the system owner accept the risk?
 Don’t let the process control you.
 C & A is not supposed to be a paper exercise.
 C & A is based on risk!
 C & A helps the organization meets its goals.
 Waivers should be based on business need.

Summary
 Business Case
 Setting up the program
 Establishing tasks, milestones and goals
 Resources
 Program Integration
 Program Phases
 Points of contact
 Measuring results
 Tracking progress
 Education, training and awareness
 Exceptions and waivers

Class Discussion
 What are some of the tools you use or would use to help
your organization have an effective certification and
accreditation program?
 Should all agencies use the same processes and tools to
implement a certification and accreditation program?
 What would you say to a manager who thinks
certification and accreditation is a waste of time and
money?
 You are responsible for the certification and accreditation
program for your organization. What things would you
do to ensure the program was successful?

C & A Roles and Responsibilities
Chapter 2

Primary roles and responsibilities
 The five primary roles
 Chief Information Security Officer (CISO)
 System Owner
 Information Systems Security Officer (ISSO)
 Certifying Agent
 Approving Authority (AA)
 Authorizing Official (AO)
 Designated Approving Authority (DAA)
 Different C & A framework use different names
 NIST, DCID 6/3, DITSCAP, DIACAP, NIACAP, ISO

Approving Authority (AA)
 Also Known As
 Designated Approving Authority
(DAA)
 Authorizing Official (AO)
 Senior management
 Formally accepts responsibility for
operating an information system
 Accepts residual risk to the system
 Must be a Government Employee
 May have a designated
representative – can do everything
but sign or decide Accreditation
“A senior management official or
executive with the authority to
formally assume responsibility for
operating an information system at
an acceptable level of risk to
agency operations, agency assets,
or individuals.” - NIST SP 800-37

Chief Information Security Officer (CISO)
 AKA: Senior Agency Information Security Officer
(SAISO)
 Senior manager in charge of Information Security
 Accountable for most aspects of security within
an organization
 Security is primary duty
 Head of the certification and accreditation
program within the organization
 Establish the program
 Enforce the program
 Responsible for the success of a C & A program
 Professional Qualifications

System Owner
 Also Known As
 Information System Owner
 Primary responsibility for the system
 Establishes the systems sensitivity level
 Full lifecycle of the system
 Often it is the IT department
“Official responsible for the overall procurement,
development, integration, modification, or operation
and maintenance of an information system.“ -
(NIST SP 800-37)

Information Systems Security Officer (ISSO)
 Principal advisor to the Approving Authority
 Serves as an agent to the system owner
 Monitors day to day security on the system
 Coordinate with physical security, personal, incident
handling and security awareness.
 Does not touch the system
“The information system security officer often plays an
active role in developing and updating the system security
plan as well as in managing and controlling changes to
the system and assessing the security impact of those
changes.“ NIST SP 800-37

Certifying Agent
 AKA: Assessor or Auditor
 Independent authority
 Impartial and unbiased (separation of duties)
 Measures effectiveness and completeness of controls
The certification agent is an individual, group, or organization
responsible for conducting a security certification, or
comprehensive assessment of the management, operational,
and technical security controls in an information system to
determine the extent to which the controls are implemented
correctly, operating as intended, and producing the desired
outcome with respect to meeting the security requirements
for the system. - NIST SP 800-37

Other roles and responsibilities
 Secondary Roles
 Chief Information Officer (CIO)
 IT Security Program Steering Committee
 Auditor
 Information Owner/Custodian
 System Administrator
 Business Unit Manager
 Project Manager
 Facility Manager
 Executive Management

Chief Information Officer (CIO)
 Overall responsibility for organization’s security
 Delegates authority to CISO
 Provision resources
 Provide oversight
 Maintain visibility
“The Chief Information Officer, with the support of the senior agency information security
officer, works closely with authorizing officials and their designated representatives to
ensure that an agency-wide security program is effectively implemented, that the
certifications and accreditations required across the agency are accomplished in a timely
and cost-effective manner, and that there is centralized reporting of all security-related
activities.“ NIST SP 800-37

IT Security Program Steering Committee
 Provides high-level oversight
 Provides direction
 Indirect supervision
 Advisory group to the program
 Does not exercise authority

Auditor
 Provides independent (unbiased) assessment of the C & A
program
 Looks at individual program components
 Ensures documentation is adequate
 Weaknesses identified
 Corrective actions specified
 Example: Certification Agent or Inspector General

Information Owner/Custodian
 Information Owner
 Also known as
 Custodian
 Data Owner
 Information owner typically owns business process
 Aware of the required protection for the data
 Establish impact level on the business process
“The information owner is an agency official with statutory or
operational authority for specified information and responsibility for
establishing the controls for its generation, collection, processing,
dissemination, and disposal.” NIST SP 800-37

System Administrator
 In charge of the day-to-day operation and administration
 Implements technical and operational controls
 IT administrators
 Separation of duties from ISSO
 Implement hardware changes
 Implement software changes
 Backups
 Monitoring
 Maintenance

Business Unit Manager
 Often function as system owner
 Might be manager or director
 Disseminate security information to subordinates
 Report security incidents to higher management
 Respond to security incidents
 Determine resources
 Set priorities

Project Manager
 May work for the system owner for complex system
security plans
 May aid the CIO or CISO in the overall program
implementation

Facility Manager
 Responsible for physical security
 Responsible for environmental controls

Executive Management
 Crucial Role
 Establish Policy
 Enforce Policy
 Allocate Resources
 Maintain visibility of program

User Representative
 Represents a user group or community
 Looks out for the interests of users
 Helps to keep it real!

Role Relationships
IG
CA
CISO
ISSO
CIO
SA
BUM
EU
Independence
SOD
SOD
IOSO
AA
Program
System
Large local governments may have a similar stratified approach. While smaller local
governments will most likely only have a single level of management. Remember
separation of duties is still a needed control for smaller organizations.

Delegation of Roles
“At the discretion of senior agency officials, certain security certification and
accreditation roles may be delegated and if so, appropriately documented.Agency
officials may appoint appropriately qualified individuals, to include contractors, to
perform the activities associated with any security certification and accreditation role
with the exception of the Chief Information Officer and authorizing official.The Chief
Information Officer and authorizing official have inherent United States Government
authority, and those roles should be assigned to government personnel only.
Individuals serving in delegated roles are able to operate with the authority of agency
officials within the limits defined for the specific certification and accreditation
activities.Agency officials retain ultimate responsibility, however, for the results of
actions performed by individuals serving in delegated roles.“ NIST SP 800-37

Documenting roles and responsibilities
 Document contact information for each role
 In other documents, refer to the roles not the person
 Letters of appointment
 May create contact database
Sample System Security Plan from Centers for Disease Control and Prevention

Job descriptions
 Describe responsibilities
 Don’t forget the C & A responsibilities
 Outline expectations of performance
 Used for accountability

Position sensitivity designations
 Some key roles should be designated highly sensitive
 People who know security of the system
 People who know the controls
 People with knowledge of the security posture
 Need trustworthy people
 Avoid frequent turnover

Personnel transitions
 Make sure individuals have adequate replacements before
they leave, if possible
 Overlapping smooth transition
 Acclimatize the individual with the C & A process and
organizational specifics
 Make sure they understand their new roles and
responsibilities

Time requirements
 C & A duties do not require full time, unless you dedicate
the tasks
 Collateral duties to normal ones
 Dedicated employee help with consistency
 Size of the organization
 Number of systems

Expertise requirements
 Skills and abilities
 Project management
 System development life-cycle
 Technical controls
 Operational controls
 IT terminology
 Security terminology
 Clear background
 Administrative skills – technical writing skills
 Certifications like CAP, CISSP, CISA, CISM

Using contractors
 Want to have stability in the following positions, thus
employees are preferred
 CIO, CISO
 System Owner
 Authorizing Authority
 ISSO
 Need for independence, often contractors used for
certifying agent
 Contractors can make for effective partners
 Need to have background checks, statements of work,
contracts and timetables

Routine duties
 Scheduling
 Reporting
 Providing advice
 Meetings
 Quality control
 Monitor compliance
 Intermediary
 Offer solutions
 Educate and train
 Systems development
 Explain technical issues to non-technical management

Organizational skills
 Well organized
 Proficient in C & A
 Project management skills
 Scheduling
 Task lists
 Meeting notes
 Manage email

Certifications
CISSP
CISM
CISSP
ISSMP
CAP CISA
GSNA
SSCP
Security+
CISSP
ISSEP/
ISSAP
CSSLP
Management / Risk
Audit
Software
Dev
Network /
Communications

Organizational placement of C & A function
 Where it will be able to be the most effective?
 Reach the highest and lowest parts of the organizational
chart
 As wide as the enterprise
 CISO may work for the CIO or COO for whistle blower

Summary
 People are the most important part of the process
 The right people make the program
 5 key roles and supporting roles

Class Discussion: Roles & Responsibility
 What are some of the biggest challenges within your
current role?
 How would you respond to a business unit owner,
information owner or approving authority who says C&A
is an IT issue and that he/she does not need to be
involved?
 If staffing is an issue, what roles would you combine?
Which roles would you not combine?
 In order to have a successful C&A program you have
been tasked to make an education system for your
organization. What are some key features you would
include?

The C & A Life Cycle
Chapter 3

Certification and Accreditation in the SDLC
Reference: NIST SP 800-100, Information Security Handbook:A Guide for ManagersRev 4 (Jan 2010)81 © 2010 Maze & Associates

Initiation phase
 Document the sensitivity of the system with the risk
assessment
 Identify threats and vulnerabilities
 Control selection
 With limited resources you will have to prioritize
All 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 its purpose.The information to be processed,
transmitted, or stored is typically evaluated, as well as who is required access to 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.A preliminary risk assessment is typically conducted in this phase, and security
planning documents are initiated (system security plan). NIST SP 800-100

Acquisition / Development phase
 Cost-benefit analysis
 Control selection
 Develop SSP
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.
NIST SP 800-100

Implementation phase
 Ensure controls are in place and functioning correctly
 SSP updated as needed
 Certification test
 Certification test results reporting
 Authorization to operate (go live)
In the implementation phase, the organization configures and
enables system security features, tests the functionality of these
features, installs or implements the system, and finally, obtains a
formal authorization to operate the system. Design reviews and
system tests should be performed before placing the system into
operation to ensure that it meets all required security specifications.
NIST SP 800-100

Operations / Maintenance phase
 Make sure the system stays secure
 Continuous monitoring
 Configuration management
 Patch management
 Recertification and reaccreditation
An 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 preestablished user and security requirements, and
needed system modifications are incorporated. NIST SP 800-100

Disposition Phase
 Disposal of the system
 System replacement and/or upgrade
 Secure disposal
 Archive data
 Data migration
The 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.
NIST SP 800-100

Additional Study Resource
 Check out Section 3.6 Security Activities within the
SDLC, NIST SP 800-100, Information Security Handbook:
A Guide for Managers (March 2007)

Challenges to implementation
 Failing to follow the System Development Life Cycle
(SDLC)
 Rapid deployment
 Alternative is to have multiple tracks
 Normal full C & A track
 Fast track for interim authorization to operate, followed by full
C & A
 Flexibility, should be risk-based

Comparison C & A Methodology
Methodology Phase 1 Phase 2 Phase 3 Phase 4
NIST SP
800-37
Initiation Security
Certification
Security
Accreditation
Continuous
Monitoring
(ISC)2 CAP Preparation Execution Maintenance
NIACAP Definition Verification Validation Postaccreditation
DITSCAP Definition Verification Validation Postaccreditation
DIACAP Definition Verification Validation Postaccreditation

SDLC and C & A overlay
Reference: NIST SP 800-100, Information Security Handbook:A Guide for Managers
Initiation /
Definition
Certification
/Verification
Accreditation
/Validation
Continuous Monitoring
/ Post accreditation

NISTSP800-100

Summary

Class Discussion: Life Cycle
 You are an auditor assessing a system for the certification
phase. You notice the last time the system security plan
and risk assessment were modified was prior to the last
accreditation. What would this indicate to you as an
auditor?
 What is the benefit of using a cycle to describe the
process of certification and accreditation?
 What is the best time to start the C&A process when
developing or purchasing a new system? What happens in
reality?

Why C & A Programs Fail
Chapter 4

Program Risks
 Programs run risks as well
 Programs don’t always fail
 Sometimes the program is not as effective as it could be
 Sometimes the program is not as efficient as it could be

Problems in program scope
 Accurate inventory
 Without an accurate inventory you don’t know what is in your
system or what data is on the system
 Make sure you have 100% accurate inventory

Assessment focus
 Problems
 Only focus on control assessment
 Must remediate failed controls
 Management failed to allocate adequate resources
 Systems change constantly
 Need to have a system of assessment and remediation
 Need to have adequate resources

Short-term thinking
 Failing to think of the long-term because they focus on
short-term projects neglecting long-term
 Dealing with problems in fire-fight mode

Long-term thinking
 If an organization fails to
think of the short-term
because they focus on long-
term projects neglecting
short-term
 Focus so much on strategy
they fail to implement

Poor planning
 Programs don’t implement themselves
 Failure to set realistic requirements
 Failure to assign responsibility
 Failure to integrate C & A (bake it in)
 Failure to train people
 Misconceptions about program
 Failure to recognize limitation

Lack of responsibility
 Responsibility needs to be assigned
 If no one is made responsible for the C & A program you
will not be able to hold anyone accountable

Too much paperwork
 C & A program in danger of becoming a paper exercise
 If it becomes a paper exercise, it will not be based on risk

Lack of enforcement
 Accountability
 Inconsistency can lead to failure
 Everyone must be onboard for the program

Lack of foresight
 Fail to see the benefit of Certification and Accreditation
 Perform a cost benefit analysis to see the benefit

Poor timing
 If the organization is not ready for implementation
 Organization may have more pressing needs

Lack of support
 Need for resources
 Need for management support
 Need to be supported at the highest and lowest level
 Management may not understand the value

Summary
 The C & A Program may miss the target if it is not
properly supported by management
 If the organization is not ready for the program
 If the C & A program is looked at as a paper exercise
 If the organization does not assign responsibility
 If the organization does not enforce the C & A program
 If the organization does not properly plan for the C & A
program
 If the program does not get the resources needed

Class Discussion: Why C&A Programs Fail
 You have been tasked with ensuring the certification and
accreditation program does not fail. What would you do
to ensure success?
 Business unit owners, information owners, system owners
or approving authorities are not engaged in the C&A
process. How would you ensure success of the C&A
program?
 We have all been a part of a program or initiative that
failed. What are some reasons programs or initiatives fail?

C & A Process
Section II

C & A Project Planning
Chapter 5

Quote
If you fail to plan,
you plan to fail!

Integrating Security into the CPIC Process
NIST SP 800-65,“Integrating IT Security into the
Capital Planning and Investment Control Process,”
provides a seven-step process, illustrated on
the right, for prioritizing security activities and
corrective actions:
1. Identify the Baseline
2. Identify Prioritization Requirements
3. Conduct Enterprise-Level Prioritization
4. Conduct System-Level Prioritization
5. Develop Supporting Materials
6. Implement Investment Review Board (IRB)
and Portfolio Management
7. Submit Exhibit 300s, Exhibit 53, and
Conduct Program Management
CPIC = Capital Planning and Investment Control

Planning factors
 Key Factors
 Properly Coordinated
 Effectively Organized
 Closely Managed
 Project management usually takes 10% of the required
effort of the program
 Project Managers Skills
 Knowledgeable – understand the C & A process
 Personable – a people-person
 Present – always on the ball
 Involved – the one person who should know everyone's status

Dealing with people
Project manager
 Need to be a people-person
 Manage expectations
 Manage objectives
 Need to identify the individuals
in the project
 Develop a contact list

Team member selection
 Should be based on
 Knowledge
 Skills
 Abilities
 Such as
 Critical
 Impartial, Fair
 People skills
 Analytical
 Familiar with C & A

Scope definition
 How many systems are in the project?
 How complex are the systems?
 Are there any deadlines?
 Locations of the systems?
 How many people are involved?
 What are the available resources?
 What will happen if the scope creeps?
 What are the costs?

Assumptions
 You never have all the information need to make
decisions.
 You have to learn how to make decisions.
 Learn how to deal with fear, uncertainty and doubt.

Project Risks
 Identify risks to the project
 What could prevent this project from being completed?
 Lack of cooperation
 Lack of management support
 Lack of manpower
 Lack of funds
 Lack of time
 Lack of skills needed
 Delays
 Etc.

Project agreements
 Document the project plan
 This serves to inform people of their roles
 It also serves to identify what resources will be needed
 Sets expectations on timing

Project team guidelines
 May be necessary to implement procedures and policy on
how to approach the project
 Such as procedures to follow in the event of a scope
change
 Also helps to ensure consistency

Administrative requirements
 Don’t forget to take into consideration the cost of
administrative support
 File storage
 Copy paper
 Binders
 Media
 Software tools
 Hardware tools
 Reference materials
 Etc.

Reporting
 Reporting status to
management helps to gain
support for the program
 Status reporting
 Monitoring progress
 Inform management
 Reports should be succinct,
clear and concise
 Consider a dashboard approach

Other tasks
 Don’t forget training
 Most forgotten aspect is training

Project kickoff
 Important to have a kick-off meeting
 This meeting will help get everyone on the team on the
same page
 Also shows management’s support for the program
 Should cover
 Deliverables
 Timeline
 Resources
 Roles & Responsibilities
 Procedures
 Scope
 Input from past projects

Wrap-up
 Helpful to have a close out-meeting
 Cover
 Deliverables
 Success or failure
 What went wrong
 What went right
 Lessons learned
 Recommendations
 Any handoffs necessary
 Quality assurance, what do we do next time

Summary
 Project management is necessary for a successful C & A
program
 Planning is necessary for a successful C & A program
If you fail to plan,
you plan to fail!

Class Discussion: Project Planning
 You are a project manager for a certification and
accreditation program. You have one team member who
continuously misses deadlines causing delays in the
program implementation. How would you solve this
problem?
 You have had projects successfully complete in the past
without a project manager. How would you decide when
you would need one?
 Explain project risk.

System Inventory Process
Chapter 6

Inventory Project Work Plan
1
• Identify General Support Systems and Applications
• Identify Business Functions
• Identify automated information resources & categorize as GSS or application
2
• Classify GSS and applications
• Determine information sensitivity
• Determine mission criticality
3
• Determine what applications qualify as major applications
• Determine major applications support systems
• Non-major application become GSS
4
• Submit to CIO for review
• Business unit executive review
• Publish inventory

Responsibility
 Inventory roles should be defined in writing
 System Owners are the primary contact of the inventory
process
 CISO is the owner of the inventory process
 Need to appoint an ISSO for each system
 Information technology security manager – actual count
 Inventory is a function of the security process
 It is also an accounting process

System identification
 System owner is the primary role for the initial system
identification
 Assisted by others, such as the CIO and CISO
“The term ‘information system’ means a discrete set of information resources
organized for the collection, processing, maintenance, transmission and
dissemination of information in accordance with defined procedures, whether
automated or manual.” OMB Circular A-130

General Support System v. Major
Application
General Support System
“An interconnected set of information resources under the same direct
management control that shares common functionality. It normally
includes hardware, software, information, data, applications,
communications, and people.” OMB Circular A-130
Major Application
“An application that requires special attention to security due to the risk
and magnitude of harm resulting from the loss, misuse, or unauthorized
access to or modification of the information in the application.” OMB
Circular A-130

Small systems
 Generally are supported by the GSS
 For example
 Database
 Spreadsheets
 Etc.
 Technical security controls usually not a part of the small
system
 Unlike major applications that have security control designed in
 Normally addressed under the GSS system

Large systems
 Difficult to define because they are large and complex
 May contain subsystems
 May contain multiple processes
 May have different managers for different parts
 For example
 ERP system
 May be best to manage subsystems

System and Subsystem
NIST SP 800-100
System 1
Subsystem A
Subsystem B
Subsystem C

Combining systems
 A possible way to streamline the C & A
process
 Group similar systems together
 You can only group them if they will
have the same owner
 Also need to be in the same
environment
 Must be protected within a common
security perimeter
 Even if all the systems are in the same
datacenter, that does not mean they
will be in the same system

Accreditation boundaries
 Everything (System, application, hardware) must be in the
C & A program
 The idea of a system boundary is to establish
responsibility
 Where to draw the line
 Business process
 Security perimeter
 Ownership
 Make the boundaries as small as you can with sensitive
systems
 Flexibility is required

The process
 Inventory
 GSS
 Major Applications
 Identify business function
 Identify supporting information technology
 Categorize into types of systems
 Classified by need for protection
 Disclosure
 Modification
 Destruction
 Denial

Validation
 Time for a sanity check
 Does the system boundary
make sense?
 Is the system properly classified
based on risk not what the
system owner wants
 Don’t rush the process and miss
critical issues

Inventory information
 Capture only the needed information
 If you don’t need it for the C & A program, don’t collect it
 The additional information may be needed for a different
purpose
 May already exist, for maintenance purposes
 You just need to know the name of the system, what it is
doing to what type of data, what applications are involved
 Typically 3 or 4 sentences

Inventory tools
 Inventory Form
 Inventory Change Form
 Summary reports
 Generally this is best done with a database or website

Using the inventory
 Funding may be tied to the Inventory
 Disputes and disagreements will naturally arise
 The CISO should handle these disagreements
 Inventory can be used to solve these issues

Maintenance
 Need to have a formalized (meaning documented and
supported) Inventory
 Annual review (required)
 Timely update as it changes
 Automated system
 Can help trigger an evaluation of recertification
 Closely tied to risk-management
 Closely tied to business continuity
 Typically, obtaining an up-to-date inventory is a challenge

Summary
 Need to have a sound process for
 Create inventory
 Classification of systems inventory
 Update systems inventory
 Review systems inventory
 Goal
 To provide assurance that systems that need protection are
identified
 Need to be able to understand where one systems starts
and where it ends

Inventory Is Central

Class Discussion: Inventory
 Due to timing restraints you have been asked to
complete the certification and accreditation for a system
without a complete inventory. What can you do?
 What are the risks of an inaccurate and out-of-date
inventory?
 It is a challenge to keep an accurate and up-to-date
inventory. How would you ensure an accurate and up-to-
date inventory?
 What other processes suffer from an inaccurate and out-
of-date inventory?

Assessing Data Sensitivity and Criticality
Chapter 7

Defining sensitivity
 The data is what dictates the sensitivity of the system
 Not the value of the hardware
 Not the value of the software
 Based on the following factor
 Confidentiality
 Availability
 Integrity
 Not all data needs the same level of protection
 Different requirements based on factors
 National defense – confidentiality
 Life safety – availability
 Financial – integrity

Data sensitivity and system sensitivity
 Sensitivity of the system is dictated by the data sensitivity
 Data that is stored
 Data that is processed
 Data that is transmitted
 Most systems have data at multiple levels
 Document all data types
 The categorization is the worst case scenario (Impact)

Sensitivity assessment process
 Confidentiality
 Risk of disclosure
 Nation defense data
 Privacy data
 Integrity
 Intentional or unintentional modification or alteration
 Financial data
 Availability
 Risk of destruction or denial of use
 Life safety data

Data classification approaches
 C & A will develop a formal data classification schemes
 FIPS 199 is one example
 Example
 Public – available to the masses
 Internal Use – available within the organization
 Restricted – information that needs to be safe-guarded

Responsibility for data sensitivity assessment
 System owners often make the decision
 Must rely on the judgment of the data owner
 Close coordination between parties
 Ensure proper safeguards (controls, countermeasures)

Ranking data sensitivity
 Need to determine levels of sensitivity for each factor and
document it
 Example
 Low
 Moderate
 High
 Example
 Green
 Yellow
 Red
 Example
 1
 2
 3
Some things that may determine level:
•Contractual
•Regulatory
•Legal
•Operational

Criticality
 Criticality is not the same as sensitivity
 Used to determine the controls, like
sensitivity
 Criticality is based on the whole system
 Importance of the system to the
organization
 Often based on the amount of time an
organization can withstand
 Not solely based on availability
 Sensitivity of that data
 Criticality of the system

Criticality assessment
 How important is the system to the organization?
 How would it affect the ability of the organization to
complete its mission?
 Mission Critical
 National security system
 Interest of national defense or foreign policy
 Debilitating impact to the mission of the organization
 Non-Mission Critical
 Does not meet the above 3 criteria
 May impact efficiency
 Can be done manually

Criticality in the view of the system owner
 System owners may overrate their systems
 Every system is not high criticality or mission critical
 It is a matter of perspective
 Must be balanced

Ranking criticality
 What would be the financial impact to the organization?
 Generally a dollar amount
 What would be the effect on the operational
effectiveness of the organization?
 Is there a life safety impact of the system?
 What is the effect based upon the breadth/scope of the
system?
 Based on the fact that it is used widely in the organization
 Rank
 High, moderate, low
 Critical, noncritical

NIST SP 800-60
DataType
Data
Description Data Sensitivity

Data Explanation (NIST SP 800-60)

Document All Data Forms
DataType Confidentiality Integrity Availability
Personal Identity and Authentication Moderate Moderate Moderate
Help Desk Services Low Low Low
Budget & Finance Moderate Moderate Low
Accounting Low Moderate Low
Space Operations Low High High

Changes in criticality and sensitivity
 Systems are not static
 Systems are dynamic
 A change in the system may change criticality
 A change in the data that is processed, stored or
transmitted on the system
 Review regularly – at least annually
 Review triggered when inventory changes
 Review triggered by change management
 If criticality changes, your controls will need to be
reevaluated

Summary
 Criticality of the system
 Sensitivity of the data
 Both based on the importance to the organization
 The criticality of the system and sensitivity of the data
helps us determine what controls will be used
 Defines requirements

Class Discussion: Sensitivity & Criticality
 After a system has completed accreditation it is found
out that a new data type has been added to the system.
The sensitivity of the new data type has now changed the
criticality of the system. How would you solve this
problem so that it does not happen again?
 Why expend different levels of effort in protecting
systems? Why not treat all systems the same?
 You need to determine the criticality of a new system.
Who would you meet with to determine the criticality of
the system?

System Security Plan (SSP)
Chapter 8

Paper Tiger?
 GCN, February 2007, Reported a pair
of security experts say FISMA is
fundamentally flawed.
 “FISMA wasn’t written badly, but the
measuring system they are using is
broken. What we measure now is,
‘Do you have a plan?’ Not whether
the plan actually improves security.
Too often, the plans do not improve
security”

No Paper Tiger
 Avoid the danger of turning your security plan into a
bureaucratic ‘check the box’
 Should be
 Single reference for what needs to be secured
 Documents controls
 Support oversight, planning and budget
 Document compliance

Applicability
 System Security
Plans are required
 Helps to implement
needed controls
 Documents how
the controls are in
place
NIST SP 800-18 Rev 1

Responsible for the Plan
 System Owner, is responsible for the plan
 Can delegate preparation of the plan
 Cannot delegate responsibility
 Should be familiar with the system
 Multiple people will contribute
 Procedures should be in place outlining who reviews the
plans, keeps the plan current, and follows up on planned
security controls.

Plan Contents
 System Description
 Description of Controls
 System Security Roles & Responsibilities
 External Requirements
 Information Categories
 Interconnectivity with the system
 Certification Level
 Plan Information

What SSP is not
 The System Security Plan is not
proof of the existence of controls
 It is not a security procedures
manual
 Cross reference procedures do not
duplicate them (Hyperlink and name
and location of documentation)
 Plan should not be lengthy and
unusable

Plan initiation
 Can start at any time
 Generally started early
 Needs to be complete before an accreditation decision is
made
Plan Initiation
Plan
Development
Plan
Implementation
Plan
Maintenance
Recertification
or Retirement

Information sources
 Information sources
 Generally comes from existing documentation
 May need to develop from scratch
 SSP development tools
 Automated systems
 Databases
 Document repositories
 Forms (may be web-based)

Plan format
 Should be flexible
 There are a number of different forms

Plan approval
 Part of the certification and accreditation package
 Signed by the person who prepared plan
 Approved by the system owner

Plan Maintenance
 Keep the plan up-to-date
 Don’t wait until recertification to update the plan
 Review of the plan should occur prior to any major
change
 It has to be a living document
 May trigger a recertification

Plan specifics
 Plan Security
 Sensitive information
 Limit to need to know
 Should be labeled
 Plan Metrics
 Documented Plans
 Use of Defined Formats
 Approved Plans
 Consistent Plans
 Documented Implementation Planning

System Boundary
 Flexibility in determination of
the system
 Generally under the same
management control & usually
locally group systems
 May contain multiple
components
 System Security Plan will have
diagrams showing the system
boundary
 Components adds clarity to
system security plan
System 1
Component A
Component B
Component C

Baseline Security Controls
 Selection of baseline security controls is based on system
categorization
 For this system you would select Moderate controls from
NIST SP 800-53 Rev. 1 (High watermark)
Information Criteria Security Impact
Confidentiality Low / Moderate / High
Integrity Low / Moderate / High
Availability Low / Moderate / High
Based on: NIST SP 800-60 and FIPS Pub 199

Implementation Detail
 Control selection based on Risk Assessment
 Fully describe the how the control is implemented
 Document differences with ‘components’ or ‘elements’
 Compensating Controls
 Common Controls
 Hybrid Controls
 Tailored Controls

Component Example
Implementation Detail:
Component 1 (Network Devices)
Control satisfied via the following:A configuration management
system retrieves a baseline configuration from all network
devices and reports changes via a version control system.The
checklist for installation includes a requirement to register
new devices in the version control system.The system
compares deltas in configurations and notifies technical staff
about changes.
Component 2 (Workstations)
Control satisfied via the workstation benchmark documentation
which records what has changed in the baseline. Agency
Incident Response team performs vulnerability Scans on a
regular basis. InformationTechnology Department reports
changes system admin evaluates materiality.

Compensating Controls
“Compensating security controls are the management,
operational, or technical controls used by an agency in
lieu of prescribed controls in the low, moderate, or high
security control baselines, which provide equivalent or
comparable protection for an information system.”
Source: NIST SP 800-100 § 8.4.4

Compensating Controls
1
• Select controls from 800-53
2
• Complete and convincing rationale
3
• Assess and formally accept risk

Common Controls
1
• Agency has developed on documented common controls
2
• Agency has assigned responsibility of the common control
3
• Systems owners should be made aware
4
• Expert in the common control consulted
5
• Agency or Center Common Control

Common Control Example
 Implementation Detail:
 Common Control: Item (i) Control satisfied via Security of
InformationTechnology Policy, Chapter 19 – Identification
and Authentication, and Chapter 20 – Logical Access
Controls. Item(ii) defined by Common Access Controls
Procedures for IT Systems Policy (when finalized).

Hybrid Controls
 A portion of the control is outside the control or scope
of the system owner
 For example physical security may be handled at the gate
and building level by guard service, while access to the
computer room is handled by system staff.
 Document what is done by whom
 Coordination between responsible parties

Hybrid Control Example
PS-3 PERSONNEL SCREENING
Control: The organization screens individuals requiring access to organizational
information and information systems before authorizing access.
Implementation Detail:
Center Hybrid Control; see System Owner action(s) needed
Control is satisfied via the following:
Guard Service Actions:
All Center Level access is managed by Guard Service.
Human Resources Actions:
Civil Servants and contractors are screened by Human Resources.
System Owner Action:
Access is not granted to users until screening by Guard Service and Human Resources.
No screening beyond what is provided by Guard Service and Human Resources.

Scoping Guidance
 System security plans should clearly identify which
security controls used scoping guidance and include a
description of the type of considerations that were made.
 Reasons for tailored controls
 Assessment of risk
 Organization-specific security requirements
 Specific threat information
 Cost-benefit analyses
 Availability of compensating controls
 Special circumstances
Source: NIST SP 800-100 § 8.4.1 Rev 4 (Jan 2010)193 © 2010 Maze & Associates

Scoping Guidance Example
 PE-11 EMERGENCY POWER
 Control:The organization provides a short-term
uninterruptible power supply to facilitate an orderly
shutdown of the information system in the event of a
primary power source loss.
 System consists of desktop computers
Criteria Rating
Confidentiality Moderate
Availability Low
Integrity Low

Scoping Guidance Example
 Implementation Detail:
 Control not implemented, applied scoping guidance per
NIST SP 800-53 rev.1 pages 18-20.
 Desktop systems do not need uninterruptible power
supply. Removing this control does not affect the
security-relevant information within the system. System
rated moderate for confidentiality and low for availability,
control addresses availability not confidentiality. Systems
with low availability do not require uninterruptible power
supplies.

Summary
 A single reference for documenting the controls in place
 Documents current security posture of the system
 Supports oversight and review
 Documents system boundaries
 Helps with planning and budget
 Integrates security into the system
 Does not mean the controls are in place

Class Discussion: System Security Plans
 Are your system security plans kept up-to-date? How
often are they updated?
 How would you ensure the system security plan was
keep up-to-date?
 How does your organization use common controls,
compensating controls, hybrid controls and tailored
controls?
 An auditor/assessor has come to you a number of times
with questions about your control implementation detail.
Is this an indication of something? If so, what?
 How would you use components in a system security
plan?

Coordinating Security for Interconnected
Systems
Chapter 9

The solution
 How do you protect your organization’s data when it is
someone else's system?
 A formal agreement establishing
 Required levels of protection
 Required reporting
 Time period
 Called a memorandum of understanding (MOU) or
memorandum of agreement (MOA)
 Interconnection security agreement (ISA) supports the
MOU/MOA – specifics

Agreements in the C & A process
 The purpose is to ensure that all
systems supporting an
organizations data are accredited at
the same levels
 That systems outside the control of
the system owner provide the
same level of protection for the
data
 Supports the understanding of
different system owners
 Provides a level of assurance

Systems Interconnection
NIST SP 800-100

Initiation
 Explicitly address the subject of interconnecting
information systems by
 Establishing formal agreements
 Specify the technical and security requirements of the
interconnection
 Define the responsibilities of the participating organizations
 Specify the rules governing these interconnections
 Obtaining written management authority before
interconnecting information systems
OMB recommends that agencies use NIST SP
800-47 to ensure compliance for connections
to non-agency systems.

Communication between parties is Important
NIST SP 800-100
 Ensure that the interconnection is properly maintained
and that security controls remain effective;
 Facilitate effective change management activities by
making it easy for both sides to notify each other about
planned system changes that could affect the
interconnection; and
 Enable prompt notification by both sides of security
incidents and system disruptions and facilitate
coordinated response, if necessary.

Lifecycle management approach
Phase 1
• Planning the
interconnection
• Establish joint
planning team
• Define business
case
• Perform C & A
• Determine
interconnection
requirements
• Document
interconnection
agreement
(MOU/MOA)
• Approve or
reject
interconnection
Phase 2
• Establishing the
interconnection
• Develop
implementation
plan
• Execute
implementation
plan
• Activate
interconnection
Phase 3
• Maintaining the
interconnection
• Maintain the
equipment
• Manage users
• Security
reviews
• Analyze audit
logs
• Report and
respond
• Contingency
planning
• Change
management
• Maintain SSP
Phase 4
• Disconnecting
the
interconnection
• Phase out
• Emergency
• Restoration of
interconnection
NIST SP 800-47 details a four-phase “life-cycle management” approach for interconnecting
information systems that emphasizes proper attention to information security

Sample MOU/MOA
NIST SP 800-100 Chapter 6 Rev 4 (Jan 2010)205 © 2010 Maze & Associates

Sample ISA

Time Issues
 Legal document that obligate the organizations
 Ensure the agreements are executed before the
connections are made
 Provisions for prompt and timely notification of security
breach
 Provisions for actions if agreement has been breached
 Provisions for cancellation

Exceptions
 You do not need an agreement between a Major
Application and the GSS system
 Requirements may be in other documentation
 Remote access is covered under rules of behavior
 Service-level agreement
 Maintenance agreements

Maintaining agreements
 Agreement must have an
ending date
 Must be reviewed during
recertification process
 Keep in touch with other
parties
 They may need a change in the
agreement

Summary
 Essential to provide assurance
 Formal understanding between system owners
 Data moves from system to system and security needs to
be ensured
 Indirect control not direct control
 Documented MOU/MOA, ISA

Class Discussion: Interconnection
Agreements
 An interconnection between your system and an external
system predates the accreditation of your system. What
are some likely issues you will face in trying to implement
an MOU/MOA on an existing connection?
 How soon would you require notification from the
owner of interconnected system after they have had an
incident?
 How often should you contact the system owner of an
interconnected system?
 You contact the system owner of an interconnected
system. No one at that organization seems to be aware
of the MOU/MOA. What do you do?

Minimum Security Baselines and Best
Practices
Chapter 10

Selecting baseline controls
 Minimum security baselines
 Based on business needs
 Must be realistic
 Must be based on risk (Don’t implement a control for the
sake of the control)
 Samples
 ISO 17799 (27002)
 GASSP
 NIST SP 800-26
 NIST SP 800-53
 Sometimes called a “control catalog”

Use of the minimum security baseline set
 The idea is that the entire system will meet these
minimum controls
 May have more controls as business needs and risks
require
 If a control is not applicable, it should be justified and
documented (Risk analysis)
 Also should document if the control cannot be
implemented and risk it to be accepted, management sign-
off

NIST 800-60

NIST SP 800-60
DataType
Data
Description Data Sensitivity

Document All Data Forms
DataType Confidentiality Integrity Availability
Personal Identity and Authentication Moderate Moderate Moderate
Help Desk Services Low Low Low
Budget & Finance Moderate Moderate Low
Accounting Low Moderate Low
Space Operations Low High High
High Watermark Moderate High High
Overall High Watermark High

NIST SP 800-60

Summary
 Have to have a place to start
 Categorize the system based on
the data in the system
 This helps you select a minimum
set of security controls
 Document and justify any
deviations for the minimum
security base line
 Update security controls as needed

Class Discussion: Security Baseline
 A business unit manager does not understand what a
minimum security baseline is and why it is necessary.
What do you tell them?
 What reasons might you have for tailoring the security
baseline?

Background
 The principal goal of an organization’s risk-management
process is to protect the organization and its ability to
perform its mission, not just its information assets.
 Risk cannot be completely eliminated
 The purpose of risk-management is to “balance the
operational and economic costs of protective measures and
achieve gains in mission capability” NIST SP 800-100
 Cost benefit analysis

Risk assessment in C & A
 Support the proper selection of controls
 To make sure the controls “fit” (tailoring controls)
 Ensure the controls selected are not excessive
 Based on realistic need for protection
 Cost-effective implementation
 Ensures controls are applicable
 Control Justification

Risk
 “Risk is a function of the likelihood of a given threat-
sources exercising a particular potential vulnerability, and
the resulting impact of that adverse event on the
organization.” NIST SP 800-30

Vulnerability
“Vulnerability: A flaw or weakness in
system security procedures, design,
implementation, or internal controls that
could be exercised (accidentally triggered
or intentionally exploited) and result in a
security breach or a violation of the
system’s security policy.” NIST SP 800-30

Threat and Threat-Source
“Threat: The potential for a threat-source to
exercise (accidentally trigger or intentionally
exploit) a specific vulnerability.” NIST SP 800-30
“Threat-Source: Either (1) intent and method
targeted at the intentional exploitation of a
vulnerability or (2) a situation and method that
may accidentally trigger a vulnerability.” NIST
SP 800-30

Risk Assessment
Asset
Vulnerability
Threat
Threat
Asset
Vulnerability
Countermeasure

Risk assessment process
1. System Characterization
2. Threat Identification
3. Vulnerability Identification
4. Control Analysis
5. Likelihood Determination
6. Impact Analysis
7. Risk Determination
8. Control Recommendation
9. Results Document
NIST SP 800-30 Rev 4 (Jan 2010)230 © 2010 Maze & Associates

Asset identification
Input
• Hardware
• Software
• System interfaces
• Data
• People
• Mission
• Reputation
Output
• System boundary
• System functions
• Criticality
• Sensitivity
System Characterization

Threat identification
Input
• History of
attacks
• Intelligence
• Media
• Advisories
Output
• Threat
statement
Threat Identification

Example Threats

Vulnerability assessment
Input
• Prior risk
assessments
• Audit comments
• Security test results
• Know vulnerabilities
Output
• List of potential
vulnerabilities
• Natural
• Environmental
• Man-made
Vulnerability Assessment

Control Analysis
Input
• Current
controls
• Planned
controls
Output
• List of
current and
planned
controls
Control Analysis

Risk calculation
Input
• Threat-source
motivation
• Threat capacity
• Nature of
vulnerability
• Current controls
Output
• Rating
Likelihood Determination

Impact analysis
Input
• Mission impact
analysis
• Asset criticality
assessment
• Criticality
• Sensitivity
Output
• Impact Rating
Impact Analysis

Risk calculation
Low Medium High
Confidentiality Limited Serious Grave or Catastrophic
Integrity Limited Serious Grave or Catastrophic
Availability Limited Serious Grave or Catastrophic
NIST SP 800-30

Risk determination
 Risk determination combines the probability (likelihood)
of threat exploitation and the magnitude of impact
 Determines if the controls are adequate
NIST SP 800-30

Safeguard identification
 Control Recommendations
 What controls are needed to reduce risk to an acceptable
level
 Need more or fewer controls than the minimum security
baseline
 Consider the following factors
 Effectiveness of recommended options (e.g., system
compatibility)
 Legislation and regulation
 Organizational policy
 Operational impact
 Safety and reliability

Residual Risk

Accepted or Unacceptable Risk

Documented risk assessment results
 “Once the risk assessment has been completed (threat-
sources and vulnerabilities identified, risks assessed, and
recommended controls provided), the results should be
documented in an official report or briefing.“ NIST SP 800-
30
 Helps senior management make an educated decision on
risk acceptance
 Management may wish to accept residual risk

NISTSP800-37Rev1Draft

Summary
 Risk assessment determines and/or verifies requirements
for a system
 A process to value assets
 Determine potential threats to those assets
 Determine potential weaknesses in system
 Determine the impact of a threat vulnerability
exploitation
 Determine what controls will reduce risk to an
acceptable level
 Acceptance of residual risk
 Document results

Class Discussion: Assessing Risk
 What is the objective of a risk assessment?
 Can we completely remove risk?
 An authorizing authority is having a difficult time with the
concept of residual risk. How would you explain it to
him/her?
 What information do we need in order to start the risk
assessment?
 How do you determine likelihood that threat-agent will
exploit a vulnerability?
 What is the benefit and the danger of using a risk
assessment template?

Security Procedures
Chapter 12

Security Procedures
 Purpose
 Procedure ensure that there is a uniform application
(repeatable)
 Provide users with instructions on “how to”
 Problems
 Administrator may not follow because it is routine or take
longer to complete a given task
 Responsibility
 System owner should develop
 Administrators should consider them mandatory
 Disciplinary action for failure to follow

Procedures
 Procedure templates
 Proactive development – used
enterprise wide
 Easy deployment
 Tailored for organizations
environment
 Procedure development process
 What procedures are needed
 Write procedures
 Review procedures
 Implement procedures
 Review procedures
 Retire/Update
Needs
analysis
Development
Review
Implement
Review
Retire /
Update

Procedures
 Style
 Concise – Don’t go overboard
 Easy to understand
 Modular fashion – easy navigation and updating
 Not in the System Security Plan
 Formatting
 Need to be written not ‘ad hoc’
 Date and revision
 Signed
 Bulleted lists
 Screen shots

Access
 Access
 Procedures need to be available by those who need them
when they need them
 Stored in multiple locations and by means
 Paper and electronic
 Maintenance
 Living documents, will need to change as the system changes
 Built into the change management process
 May trigger an update or change to disaster recovery
processes
 Keep past versions

Procedures in the C & A process
 Establish process and requirements
 Should be documented in the System Security Plan
 Failure to follow procedures increases risk
 Procedures are tested as a part of security testing
 Weaknesses in procedure should be documented and
placed in remediation

Summary
 Procedures
 Describe the tasks to be done and how to do them
 Adds constancy to the process
 Reference but not in the System Security Plan
 Easily accessible
 Clear and concise
 Updated as needed (Change management)

Class Discussion: Procedures
 System administrators consistently ignore procedures.
 What are some potential reasons for them not following
procedures?
 What would you do to ensure they follow documented
procedures?
 What type of procedures do you typically have problems
with?

Certification Testing
Chapter 13

Certification and Accreditation
“The security certification and
accreditation process is designed to
ensure that an information system will
operate with the appropriate
management review, that there is
ongoing monitoring of security controls,
and that reaccreditation occurs
periodically.”
NIST SP 800-100

Scope
 Scope of the certification
should include the controls
of the entire system being
certified
 Using the SSP the
certification agent will start
by reviewing the listed
controls
 May identify additional
areas of weakness
“Security certification is a comprehensive
assessment of the management,
operational, and technical security controls
in an information system, made in support
of security accreditation, to determine the
extent to which the controls are
implemented correctly, operating as
intended, and producing the desired
outcome with respect to meeting the
security requirements for the system.The
results of a security certification are used
to reassess the risks and update the
system security plan, thus providing the
factual basis for an authorizing official to
render a security accreditation decision.”
NIST SP 800-100

Level of Effort
 Testing levels will be dictated by the sensitivity of the data
and criticality of the system.
 Lower systems
 May allow for a self-assessment
 Checklist based
 Higher systems
 Will require independent review
 Testing
 Sample sizes increase with risk

Independence
 The level of the system will dictate the level of
independence required
 Must be independent of the entire process, especially the
system owner
 Can use internal or external auditors
 Often use independent contractors
 There should be a level of review with the auditors
 May use automated tools for testing such as CAATs
(Computer Aided AuditTools)

Certification Process (NIST SP 800-37)
 Security Control Assessment
 Prepare for Assessment
 Conduct Assessment
 Document Results
 Security Certification Documentation
 Provide the certification findings & recommendations
 Update the system security plan (SSP)
 Prepare the plan of actions and milestones (POA&M)
 Assemble accreditation package

Security Control Assessment Tasks
Task 1“Assemble any documentation and supporting materials
necessary for the assessment of the security controls in the
information system; if these documents include previous assessments
of security controls, review the findings, results, and evidence.”
Task 2 “Select, or develop when needed, appropriate methods and
procedures to assess the management, operational, and technical
security controls in the information system.”
Task 3 “Assess the management, operational, and technical security
controls in the information system using methods and procedures
selected or developed.”
Task 4 “Prepare the final security assessment report.”
NIST SP 800-37

Security Documentation Tasks
Task 1“Provide the information system owner with the security
assessment report.”
Task 2 “Update the system security plan (and risk assessment) based
on the results of the security assessment and any modifications to
the security controls in the information system.”
Task 3 “Prepare the plan of action and milestones based on the
results of the security assessment.”
Task 4 “Assemble the final security accreditation package and submit
to authorizing official.”
NIST SP 800-37

Changes with NIST SP 800-37 Rev 1 Draft

 Task 1: Identify and select the security control assessor(s) and
determine if the selected assessor(s) possess the required
degree of independence for the assessment.
 Task 2: Develop a plan to assess the security controls.
 Task 3: Review and approve the plan to assess the security
controls.
 Task 4: Obtain appropriate documentation, records, artifacts,
test results, and other materials needed to assess the security
controls.
 Task 5:Assess the security controls in accordance with the
assessment procedures defined in the security assessment
plan.
 Task 6: Prepare the preliminary security assessment report
documenting the issues, findings, and recommendations from
the security control assessment.

 Task 7: Review the preliminary security assessment report.
 Task 8: If necessary, conduct remediation actions based on the
preliminary security assessment report.
 Task 9:Assess the remediated security controls.
 Task 10: Update the security assessment report and prepare the
executive summary.
 Task 11: If necessary, prepare an addendum to the security
assessment report that reflects the initial results of the remediation
actions taken and provides the information system owner or
common control provider perspective on the assessment findings
and recommendations.
 Task 12: Update the security plan based on the findings and
recommendations of the security assessment report and any
remediation actions taken.
 Task 13: Prepare the plan of action and milestones based on the
findings and recommendations of the security assessment report.

Developing the test plan
 ST&E (SecurityTesting & Evaluation Procedures)
 Aka:Audit approach
 Detailed description of the testing methodology that will be
used
 Will include the following
 Scope
 Testing requirements
 Testing approach
 Tests to be used
 Timeline
 Responsibilities
 Test team
 Remediation plan, recommendations

The role of the host
 In order for the auditor to finish
on time he/she will need to
have access to documents,
systems and people
 Delays in providing the auditor
with needed items will slow the
process
 The host organization should
ensure the auditor has what
he/she needs in a timely fashion,
preferably before they ask for it

Test execution
 Document the testing procedures
 Who conducted the test
 What was the results of the test
 Signed off by tester
 Reviewed by supervisor
 Rank findings by severity (not required but useful)
 Provide interim results before final report
 No need to test controls that are not in place
 Documented so that another auditor with no knowledge
of the system can follow the findings

Documenting the results
 Executive report
 Summary
 Geared for managers without the technical background
 Detail report
 Each control covered with either pass or fail
 Results of the test
 Reference
 Recommendations for remediation
 See Appendix P in the text
 Also know as security assessment report (SAR)

Summary
 Certification process needs
 To be performed by professionals
 Level of independence depends on the level of the system
 Should be well-planned
 Should be well-documented
 Should be a basis of remediation
 Certification
 Provides assurance that the implemented controls are
functioning as expected
 “…to determine the extent to which the controls are implemented
correctly, operating as intended, and producing the desired
outcome…” NIST SP 800-100

Class Discussion: Certification Testing
 What are some reasons why an auditor might increase
the amount of testing?
 What can you do to ease the audit / assessment pains?
 Is an audit a adversarial process?
 What are some thing you would consider in selecting an
auditor?
 Why should auditors document what tests they
conducted and the results?

Remediation Planning
Chapter 14

Plan of Actions and Milestones (POA&M)
“The POA&M describes the measures that have been implemented or planned to
correct any deficiencies noted during the assessment of the security controls and to
reduce or eliminate known system vulnerabilities.”
NIST SP 800-100

Remediation plan
 Applicability of the remediation plan
 Not needed if the certification process found all controls in
place and working as expected
 The remediation plan is a list of items that need to be done to
correct those deficiencies
 Responsibility
 System owners have ultimate responsibility
 May assign authority to remediate to others such as ISSO
 Cannot transfer responsibility, accountability remains with the
system owner
 You can transfer authority not responsibility

Risk remediation plan
 Risk remediation plan scope
 Should include all vulnerabilities detected
 Should also include vulnerabilities that the risk is likely to be
accepted
 Plan Format
 At a minimum it should include
 A weakness
 A fix
 A milestone (date)
 Responsible person
 Optional inclusion
 Cross-referencing numbering
 Risk ranking
See Appendix Q in the text for a sample Rev 4 (Jan 2010)275 © 2010 Maze & Associates

The plan
 Using the plan
 It is a living document and may need regular updates
 Measure progress
 When to create the plan
 Don’t wait for the certification
 As soon as a vulnerability is found, add it
 Append additional as needed
 It will be in a continuous state of update
 Should not be excessively detailed
 It will be in close relationship with the CPIC (Capital Planning and
Investment Control)
 Risk mitigation meetings
 Ongoing like the plan

Summary
 The plan lays out what needs to be corrected
 Ensure that vulnerabilities are not forgotten
 Used to track corrections
 Ensures proper documentation of remediation efforts

Class Discussion: Remediation Plan
 What is the purpose of the remediation plan?
 You have a limited budget and cannot afford to remediate
all the missing controls.
 How do you select which controls to remediate?
 Do you complete all the inexpensive ‘low hanging fruit’ or do
you tackle fewer, more expensive high impact controls?
 Which way is risk-based?
 Why do auditors want to see you past remediation plans?

Essential C & A Documentation
Chapter 15

Authority
 CISO will determine the minimum requirements for the
C & A package
 The package is everything that is submitted for
Accreditation
 System owner compiles the package for review
 Authorizing official reviews for accreditation
NIST SP 800-100

Certification package contents
 At minimum
 Approved System Security Plan (SSP)
 Risk assessment
 Security assessment report (certification test results)
 Plan of Actions and Milestones (POA&M) remediation plan
 Take a minimalist point of view
 Avoid becoming a paper exercise
 Exclude unnecessary
NIST SP 800-100

Additional documents
 The certification statement
 Statement, at a high level, the results of the certification test
 Prepared by the certifying agent
 Transmittal Letter
 Coversheet for the entire package
 Concise
 Who prepared the package
 Why it was prepared
 Who it goes to
 What is to be done
 Contains

Administration
 A copy will be submitted to the Accrediting Authority
 System owner should maintain a copy
 Central repository is an excellent idea
 Label the package with appropriate categorization level
 E.g. Unclassified but Sensitive

Summary
 Documents included depend on the need of the
authorizing official
 Approving authority can require all controls to be in
place before authorizing operation
 Documents showing that management has exercised due
diligence
 The C & A package is designed to provide the authorizing
official with the necessary information to make an
informed decision
 Should not overwhelm the authorizing official

Class Discussion: Documentation
 If you were an authorizing authority, what documentation
would you like to see before you made a decision on a
system?
 An authorizing authority does not have questions about
the accreditation package, what might this indicate?

Documenting the Accreditation Decision
Chapter 16

The accrediting authority
 The accreditation letter
fixes responsibility for the
operation of the system
 It established
accountability for system
operation
 Accrediting Authority
owns the business
process not the system
 No system should go into
production that has not
been accredited
“By accrediting an information system, an
agency official accepts the risks associated
with operating the system and the
associated implications on agency
operations, agency assets, or agency
individuals. Completing a security
accreditation ensures that an information
system will be operated with appropriate
management review, that there is ongoing
monitoring of security controls, and that
reaccreditation occurs periodically in
accordance with federal or agency policy and
whenever there is a significant change to the
system or its operational environment.”
NIST SP 800-100

The Accreditation letter
 Also known as “Authorization to
operate”
 Should clearly reflect the stipulations
of the authorizing official
 Are there any conditions which are
excluded
 Generally limited to a 3 year life span
 Must understand personal
consequences
 Must understand operational
consequences

Conditional and interim accreditation
 Full accreditation may not be possible
 Conditional or interim may be used
 Conditional would state that system could operate under
certain circumstances
 Only if certain controls are in place
 Interim is often used when the system needs to be in
place and functional for business reasons and still lacks all
the necessary controls
 Usually has an expiration date

Designation of approval authorities
 Organization must designate who
the approval authorities will be
 Must be senior officials
 Must be able to commit
resources to the system (budget
authority)
 Each organization will have
multiple approving authorities,
usually by business unit or
department

Approving authority qualifications
 Budget authority
 Qualities
 Integrity
 Competence
 Common sense
 Involvement
 Initiative
 Entrusted position with substantial authority

Accreditation decision process
 Submission of package by
system owner to the
authorizing official
 Package should be
complete
 Timing is important
 System owner should
follow up until the
authorization is finalized
 System owner should
remediate any open issues
promptly
“To ensure that the agency's
business and operational needs
are fully considered, the
authorizing official should meet
with the system owner prior to
issuing the security accreditation
decision. In this meeting, the
certification and accreditation
authorities should clearly explain
the rationale for their risk-based
decision and, where appropriate,
fully explain the terms and
conditions of the authorization.”
NIST SP 800-100

Actions following accreditation
 System owner needs to
track any corrective
actions
 Update the approving
authority as needed
 Changes in the
environment may impact
the security controls
 Recertification
The Continuous Monitoring phase is an
essential component in any security
program. During this phase, the status of
the security controls in the information
system are checked on an ongoing basis. …
At a minimum, an effective monitoring
program requires the following:
•Configuration management and
configuration control processes for the
information system;
•Security impact analyses on changes to
the information system; and
•Assessment of selected security controls
in the information system and reporting of
information system security status to
appropriate agency officials.

Summary
 The final event? Ongoing process!
 Approval for senior management to operate the system
 Fixed responsibility and accountability
 Authorization official may have had little or no interaction
with the process up until this point
 Should not delegate this process
 This process demonstrates due care has been exercised
 Establishes accountability

Class Discussion: Accreditation Decision
 Can an authorizing official sign an accreditation letter
before the system has been certified?
 A signed accreditation letter demonstrates what?
 What types of conditions might an AO have with an
authorization to operate?
 Why have a time period on conditional or interim
authorization to operate?
Why should the system owner and AO meet before the
accreditation letter is signed?
 Why is it a good idea to have the business unit manager
or information owner as the AO?

Additional Information
Tips & Tricks

Each part of the process has a NIST Document

Key NIST Documents
Document Remember
NIST SP 800-37 C & A program, overall process, guidelines
FIPS 199 Standard to define criticality / sensitivity
NIST SP 800-60 Guideline to define criticality / sensitivity
FIPS 200 Standard to select controls
NIST SP 800-53 Guidelines to selecting controls, control catalog
NIST SP 800-53A Guidelines for assessing controls, audit
NIST SP 800-30 Risk Assessment guidelines
NIST SP 800-18 Guidelines for System Security Plans
NIST SP 800-64 Guidelines for Security and SDLC
NIST SP 800-70 Security Configuration Checklist Program
NIST SP 800-47 Guideline for System Interconnections (MOU/MOA)
NIST SP 800-34 Contingency Planning Guide
NIST SP 800-61 Computer Security Incident Handling Guide

NIST IT Standards for Local Governments 2010

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to NIST IT Standards for Local Governments 2010 (20)

More from Donald E. Hester (20)

Recently uploaded (20)

NIST IT Standards for Local Governments 2010