Date post: | 06-May-2015 |
Category: |
Technology |
Upload: | donald-hester |
View: | 238 times |
Download: | 6 times |
1
Implementing NIST for Local Governments
Rev 1 (JUN 2010)© 2010 Maze & Associates
2
Introductions
NameEmployerSecurity ExperienceNIST Experience
Rev 4 (Jan 2010)© 2010 Maze & Associates
3
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
4
Introduction
Rev 4 (Jan 2010)© 2010 Maze & Associates
5
Introduction Due Diligence Standards NIST / FISMA Background A Risk Based Approach What is Certification and Accreditation Systems Security Approach Benefits External Drivers
Rev 4 (Jan 2010)© 2010 Maze & Associates
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 and
Technology (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
10
State of California
Rev 4 (Jan 2010)© 2010 Maze & Associates
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
13
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
14
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.
Rev 4 (Jan 2010)© 2010 Maze & Associates
15
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
16
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
17
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
18
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
19
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
20
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
21
Building a Successful Enterprise Certification and Accreditation (C & A) Program
Section I
Rev 4 (Jan 2010)© 2010 Maze & Associates
Key Elements of an Enterprise C & A Program
Chapter 1
23
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
24
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.
Rev 4 (Jan 2010)© 2010 Maze & Associates
25
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
26
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
27
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
28
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
29
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
30
Sample C & A Policy
Reference: http://www.tess-llc.com/Certification%20&%20Accreditation%20PolicyV4.pdf
Rev 4 (Jan 2010)© 2010 Maze & Associates
31
C & A Guidance Development Life Cycle
• Awareness• Monitoring• Enforcement• Maintenance
• Retirement
• Communication
• Compliance• Exceptions
• Creation• Review• Approval
Development
Implementation
Maintenance
Disposal
Life-cycle for the development of the documentation for the C & A process
Rev 4 (Jan 2010)© 2010 Maze & Associates
32
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
33
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
34
System Owner
Authorizing OfficialCertification Agent
Prepare Documentation
Initiation Phase 1
1. Describe the System2. Categorize its C.I.A.3. Identify Threats to it4. Identify its Vulnerabilities5. Identify In-Place and Planned Security Controls6. Determine its Initial Risks
Initiation
NIST 800-37 Risk Management & Certification and Accreditation Tasks
Notify Officials & IdentifyResourcesPlanning Phase 3
1. Notify Program Officials2. Identify Resources Needed and Plan execution of Activities
Initiation
Report & DocumentStatus
O&M Phase 9
1. Update Security Plan2. Update Plan of Action & Milestones3. Report Status
Monitoring
Monitor SecurityControls
O&M Phase 9
1. Select In-Place Security Controls2. Assess Selected Security Controls
Monitoring
Manage & ControlConfiguration
O&M Phase 9
1. Document System Changes2. Analyze Security Impacts
Monitoring
Analyze, Update& Accept System Security PlanMultiple Phases 4-6
1. Review Security C.I.A. Categorizations2. Analyze Security Plan 3. Update Security Plan 4. Obtain Authorizing Official Acceptance of Security Plan
Initiation
Assess & EvaluateSecurity Controls
Integration & Test Phase 7
1. Prepare Documentation & Supporting Materials2. Review Methods and Test Procedures3. Assess & Evaluate In- Place Security Controls4. Report Security Assessment Results
Certification
Document SecurityAccreditation
Integration & Test Phase 7
1. Transmit Security Accreditation Package2. Update Security Plan
Accreditation
Document SecurityCertification
Integration & Test Phase 7
1. Provide Findings and Recommendations2. Update Security Plan3. Prepare Plan of Action & Milestones4. Assemble Accreditation Package
Certification
Make Security AccreditationDecisionIntegration & Test Phase 7
1. Determine Final Risk Levels2. 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
Rev 4 (Jan 2010)© 2010 Maze & Associates
35
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 Rev 4 (Jan 2010)© 2010 Maze & Associates
36
Establishing C & A points of contact Chief Information Security Officer (CISO) is directly
responsible. Other key players
System Owners C & A Workgroup Security Steering Committee IT administrators
Key areas of knowledge for Organizations Operations Hierarchy Management Strategies Initiative
Rev 4 (Jan 2010)© 2010 Maze & Associates
37
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
38
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)
Rev 4 (Jan 2010)© 2010 Maze & Associates
39
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)
Recertification Triggers or Reassessment Risk New Vulnerabilities New Risks Environment changes Control failure Audit findings
Rev 4 (Jan 2010)© 2010 Maze & Associates
40
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
41
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 New Vulnerabilities (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)
Rev 4 (Jan 2010)© 2010 Maze & Associates
42
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
43
Use of expert systems Automated tools
Tracking systems C & A document management systems Audit log management Dashboards Intrusion Prevention Systems Etc.
Rev 4 (Jan 2010)© 2010 Maze & Associates
44
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.
Rev 4 (Jan 2010)© 2010 Maze & Associates
45
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
46
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
C & A Roles and Responsibilities
Chapter 2
48
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
49
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
50
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
51
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)
Rev 4 (Jan 2010)© 2010 Maze & Associates
52
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
53
Certifying Agent AKA: Assessor or Auditor Independent authority Impartial and unbiased (separation of duties) Measures effectiveness and completeness of
controlsThe 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
Rev 4 (Jan 2010)© 2010 Maze & Associates
54
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
55
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
56
IT Security Program Steering Committee Provides high-level oversight Provides direction Indirect supervision Advisory group to the program Does not exercise authority
Rev 4 (Jan 2010)© 2010 Maze & Associates
57
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
58
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
59
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
60
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
61
Project Manager May work for the system owner for complex
system security plans May aid the CIO or CISO in the overall
program implementation
Rev 4 (Jan 2010)© 2010 Maze & Associates
62
Facility Manager Responsible for physical security Responsible for environmental controls
Rev 4 (Jan 2010)© 2010 Maze & Associates
63
Executive Management Crucial Role Establish Policy Enforce Policy Allocate Resources Maintain visibility of program
Rev 4 (Jan 2010)© 2010 Maze & Associates
64
User Representative Represents a user group or community Looks out for the interests of users Helps to keep it real!
Rev 4 (Jan 2010)© 2010 Maze & Associates
65
Role Relationships
IG
CA
CISO
ISSO
CIO
SA
BUM
EU
Independence
SO
D
SO
D
IOSOAA
Program
System
Rev 4 (Jan 2010)© 2010 Maze & Associates
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.
66
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
67
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 PreventionRev 4 (Jan 2010)© 2010 Maze & Associates
68
Job descriptions Describe responsibilities Don’t forget the C & A responsibilities Outline expectations of performance Used for accountability
Rev 4 (Jan 2010)© 2010 Maze & Associates
69
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
70
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
71
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
72
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
73
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
74
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
75
Organizational skills Well organized Proficient in C & A Project management skills
Scheduling Task lists Meeting notes Manage email
Rev 4 (Jan 2010)© 2010 Maze & Associates
76
Certifications
CISSP
CISM
CISSP ISSMP
CAP CISA
GSNA
SSCP
Security+
CISSP ISSEP/ ISSAP
CSSLP
Management / Risk
AuditSoftware
Dev
Network / Communicati
ons
Rev 4 (Jan 2010)© 2010 Maze & Associates
77
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
78
Summary People are the most important part of the
process The right people make the program 5 key roles and supporting roles
Rev 4 (Jan 2010)© 2010 Maze & Associates
79
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
The C & A Life Cycle
Chapter 3
81
Certification and Accreditation in the SDLC
Reference: NIST SP 800-100, Information Security Handbook: A Guide for Managers
Rev 4 (Jan 2010)© 2010 Maze & Associates
82
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
83
Certification and Accreditation in the SDLC
Reference: NIST SP 800-100, Information Security Handbook: A Guide for Managers
Rev 4 (Jan 2010)© 2010 Maze & Associates
84
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
85
Certification and Accreditation in the SDLC
Reference: NIST SP 800-100, Information Security Handbook: A Guide for Managers
Rev 4 (Jan 2010)© 2010 Maze & Associates
86
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 Rev 4 (Jan 2010)© 2010 Maze & Associates
87
Certification and Accreditation in the SDLC
Reference: NIST SP 800-100, Information Security Handbook: A Guide for Managers
Rev 4 (Jan 2010)© 2010 Maze & Associates
88
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
89
Certification and Accreditation in the SDLC
Reference: NIST SP 800-100, Information Security Handbook: A Guide for Managers
Rev 4 (Jan 2010)© 2010 Maze & Associates
90
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
91
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)
Rev 4 (Jan 2010)© 2010 Maze & Associates
92
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
93
Comparison C & A Methodology
Methodology
Phase 1 Phase 2 Phase 3 Phase 4
NIST SP 800-37
Initiation Security Certification
Security Accreditatio
n
Continuous Monitoring
(ISC)2 CAP Preparation
Execution Maintenance
NIACAP Definition Verification Validation Postaccreditation
DITSCAP Definition Verification Validation Postaccreditation
DIACAP Definition Verification Validation Postaccreditation
Rev 4 (Jan 2010)© 2010 Maze & Associates
94
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
95
NIS
T SP
800
-100
Rev 4 (Jan 2010)© 2010 Maze & Associates
96
Summary
Reference: NIST SP 800-100, Information Security Handbook: A Guide for Managers
Rev 4 (Jan 2010)© 2010 Maze & Associates
97
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
Why C & A Programs Fail
Chapter 4
99
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
100
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
101
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
102
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
103
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
104
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
105
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
106
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
107
Lack of enforcement Accountability Inconsistency can lead to failure Everyone must be onboard for the program
Rev 4 (Jan 2010)© 2010 Maze & Associates
108
Lack of foresight Fail to see the benefit of Certification and
Accreditation Perform a cost benefit analysis to see the
benefit
Rev 4 (Jan 2010)© 2010 Maze & Associates
109
Poor timing If the organization is not ready for
implementation Organization may have more pressing needs
Rev 4 (Jan 2010)© 2010 Maze & Associates
110
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
111
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
112
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
113
C & A Process
Section II
Rev 4 (Jan 2010)© 2010 Maze & Associates
C & A Project Planning
Chapter 5
115
Quote
If you fail to plan, you plan
to fail!
Rev 4 (Jan 2010)© 2010 Maze & Associates
116
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 Baseline2. Identify Prioritization Requirements3. Conduct Enterprise-Level
Prioritization 4. Conduct System-Level
Prioritization5. Develop Supporting Materials6. Implement Investment Review
Board (IRB) and Portfolio Management
7. Submit Exhibit 300s, Exhibit 53, and Conduct Program Management
CPIC = Capital Planning and Investment Control
Rev 4 (Jan 2010)© 2010 Maze & Associates
117
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
118
Dealing with peopleProject manager Need to be a people-
person Manage expectations Manage objectives Need to identify the
individuals in the project Develop a contact list
Rev 4 (Jan 2010)© 2010 Maze & Associates
119
Team member selection Should be based on
Knowledge Skills Abilities
Such as Critical Impartial, Fair People skills Analytical Familiar with C & A
Rev 4 (Jan 2010)© 2010 Maze & Associates
120
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
121
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.
Rev 4 (Jan 2010)© 2010 Maze & Associates
122
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.
Rev 4 (Jan 2010)© 2010 Maze & Associates
123
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
124
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
125
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.
Rev 4 (Jan 2010)© 2010 Maze & Associates
126
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
127
Other tasks Don’t forget training Most forgotten aspect is training
Rev 4 (Jan 2010)© 2010 Maze & Associates
128
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
129
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
130
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!Rev 4 (Jan 2010)© 2010 Maze & Associates
131
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.
Rev 4 (Jan 2010)© 2010 Maze & Associates
System Inventory Process
Chapter 6
133
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
134
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
135
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
136
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
137
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
138
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
139
System and Subsystem
NIST SP 800-100
System 1Subsyste
m ASubsyste
m BSubsyste
m C
Rev 4 (Jan 2010)© 2010 Maze & Associates
140
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
141
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
142 Rev 4 (Jan 2010)© 2010 Maze & Associates
143
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
144
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
145
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
146
Inventory tools Inventory Form Inventory Change Form Summary reports Generally this is best done with a database or
website
Rev 4 (Jan 2010)© 2010 Maze & Associates
147
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
148
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
149
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
150
Inventory Is Central
Rev 4 (Jan 2010)© 2010 Maze & Associates
151
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
Assessing Data Sensitivity and Criticality
Chapter 7
153
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
154
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)
Rev 4 (Jan 2010)© 2010 Maze & Associates
155
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
156
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
157
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)
Rev 4 (Jan 2010)© 2010 Maze & Associates
158
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
159
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 Rev 4 (Jan 2010)© 2010 Maze & Associates
160
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 Rev 4 (Jan 2010)© 2010 Maze & Associates
161
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
162
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 Rev 4 (Jan 2010)© 2010 Maze & Associates
163
NIST SP 800-60
Data Type
Data Description Data
Sensitivity
Rev 4 (Jan 2010)© 2010 Maze & Associates
164
Data Explanation (NIST SP 800-60)
Rev 4 (Jan 2010)© 2010 Maze & Associates
165
Document All Data Forms
Data Type 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
Rev 4 (Jan 2010)© 2010 Maze & Associates
166
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
167
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
168
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
System Security Plan (SSP)
Chapter 8
170
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”
Rev 4 (Jan 2010)© 2010 Maze & Associates
171
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
172
Applicability System Security
Plans are required
Helps to implement needed controls
Documents how the controls are in place
NIST SP 800-18 Rev 1
Rev 4 (Jan 2010)© 2010 Maze & Associates
173
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.
Rev 4 (Jan 2010)© 2010 Maze & Associates
174
Plan Contents System Description Description of Controls System Security Roles & Responsibilities External Requirements Information Categories Interconnectivity with the system Certification Level Plan Information
Rev 4 (Jan 2010)© 2010 Maze & Associates
175
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
176
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 Implementati
on
Plan Maintenance
Recertification or
Retirement
Rev 4 (Jan 2010)© 2010 Maze & Associates
177
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)
Rev 4 (Jan 2010)© 2010 Maze & Associates
178
Plan format Should be flexible There are a number of different forms
Rev 4 (Jan 2010)© 2010 Maze & Associates
179
Plan approval Part of the certification and accreditation
package Signed by the person who prepared plan Approved by the system owner
Rev 4 (Jan 2010)© 2010 Maze & Associates
180
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
181
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
182
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
183 Rev 4 (Jan 2010)© 2010 Maze & Associates
184
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
185
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
186
Component ExampleImplementation 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. Information Technology Department reports changes system admin evaluates materiality.
Rev 4 (Jan 2010)© 2010 Maze & Associates
187
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
188
Compensating Controls
1
•Select controls from 800-53
2
•Complete and convincing rationale
3
•Assess and formally accept risk
Rev 4 (Jan 2010)© 2010 Maze & Associates
189
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
190
Common Control Example Implementation Detail: Common Control: Item (i) Control satisfied via
Security of Information Technology 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).
Rev 4 (Jan 2010)© 2010 Maze & Associates
191
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
192
Hybrid Control ExamplePS-3 PERSONNEL SCREENINGControl: 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.
Rev 4 (Jan 2010)© 2010 Maze & Associates
193
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)© 2010 Maze & Associates
194
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 computersCriteria Rating
Confidentiality
Moderate
Availability Low
Integrity Low
Rev 4 (Jan 2010)© 2010 Maze & Associates
195
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.
Rev 4 (Jan 2010)© 2010 Maze & Associates
196
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
197
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
Coordinating Security for Interconnected Systems
Chapter 9
199
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
200
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
201
Systems Interconnection
NIST SP 800-100
Rev 4 (Jan 2010)© 2010 Maze & Associates
202
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 systemsOMB recommends that agencies use NIST SP 800-47 to ensure compliance for connections to non-agency systems.
Rev 4 (Jan 2010)© 2010 Maze & Associates
203
Communication between parties is ImportantNIST 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.
Rev 4 (Jan 2010)© 2010 Maze & Associates
204
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
205
Sample MOU/MOA
NIST SP 800-100 Chapter 6 Rev 4 (Jan 2010)© 2010 Maze & Associates
206
Sample ISA
NIST SP 800-100 Chapter 6 Rev 4 (Jan 2010)© 2010 Maze & Associates
207
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
208
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
209
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
210
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
211
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
Minimum Security Baselines and Best Practices
Chapter 10
213
Levels of control
NIST SP 800-100 and NIST SP 800-53 Rev 4 (Jan 2010)© 2010 Maze & Associates
214
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”
Rev 4 (Jan 2010)© 2010 Maze & Associates
215
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
216
NIST 800-60
Rev 4 (Jan 2010)© 2010 Maze & Associates
217
NIST SP 800-60
Data Type
Data Description Data
Sensitivity
Rev 4 (Jan 2010)© 2010 Maze & Associates
218
Document All Data Forms
Data Type 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
Rev 4 (Jan 2010)© 2010 Maze & Associates
219
NIST SP 800-60
Rev 4 (Jan 2010)© 2010 Maze & Associates
220
Security Control Selection Process
NIST SP 800-53A Rev 2
Rev 4 (Jan 2010)© 2010 Maze & Associates
221
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 Rev 4 (Jan 2010)© 2010 Maze & Associates
222
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
Assessing Risk
Chapter 11
224
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
225
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
226
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
227
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
228
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
229
Risk Assessment
AssetV
uln
erab
ilit
y
Threat
Threat
Asset
Vu
lner
abil
ity
Cou
nte
rmeasu
re
•Rev 4 (Jan 2010)© 2010 Maze & Associates
230
Risk assessment process1. System
Characterization2. Threat Identification3. Vulnerability
Identification4. Control Analysis5. Likelihood
Determination6. Impact Analysis7. Risk Determination8. Control
Recommendation9. Results Document
NIST SP 800-30 Rev 4 (Jan 2010)© 2010 Maze & Associates
231
Asset identification
Input
• Hardware• Software• System
interfaces• Data• People• Mission• Reputation
Output
• System boundary
• System functions
• Criticality• Sensitivity
System Characterization
Rev 4 (Jan 2010)© 2010 Maze & Associates
232
Threat identification
Input
• History of attacks
• Intelligence• Media• Advisories
Output
• Threat statement
Threat Identification
Rev 4 (Jan 2010)© 2010 Maze & Associates
233
Example Threats
NIST SP 800-30 Rev 4 (Jan 2010)© 2010 Maze & Associates
234
Vulnerability assessment
Input
• Prior risk assessments
• Audit comments• Security test
results• Know
vulnerabilities
Output
• List of potential vulnerabilities
• Natural• Environmental• Man-made
Vulnerability Assessment
Rev 4 (Jan 2010)© 2010 Maze & Associates
235
Control Analysis
Input
•Current controls
•Planned controls
Output
• List of current and planned controls
Control Analysis
Rev 4 (Jan 2010)© 2010 Maze & Associates
236
Risk calculation
Input
• Threat-source motivation
• Threat capacity
• Nature of vulnerability
• Current controls
Output
• Rating
Likelihood Determination
Rev 4 (Jan 2010)© 2010 Maze & Associates
237
Impact analysis
Input
• Mission impact analysis
• Asset criticality assessment
• Criticality• Sensitivity
Output
• Impact Rating
Impact Analysis
Rev 4 (Jan 2010)© 2010 Maze & Associates
238
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-30Rev 4 (Jan 2010)© 2010 Maze & Associates
239
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
240
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
241
Residual Risk
NIST SP 800-30 Rev 4 (Jan 2010)© 2010 Maze & Associates
242
Accepted or Unacceptable Risk
NIST SP 800-100 Rev 4 (Jan 2010)© 2010 Maze & Associates
243
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
244
NIS
T SP
800
-37
Rev
1 D
raft
Rev 4 (Jan 2010)© 2010 Maze & Associates
245
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
246
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
Security Procedures
Chapter 12
248
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
249
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
250
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
251
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
252
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
253
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)
Rev 4 (Jan 2010)© 2010 Maze & Associates
254
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
Certification Testing
Chapter 13
256
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
257
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
258
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
259
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 Audit Tools)
Rev 4 (Jan 2010)© 2010 Maze & Associates
260
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
261
Security Control Assessment TasksTask 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
Rev 4 (Jan 2010)© 2010 Maze & Associates
262
Security Documentation TasksTask 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
Rev 4 (Jan 2010)© 2010 Maze & Associates
263
Changes with NIST SP 800-37 Rev 1 Draft
Rev 4 (Jan 2010)© 2010 Maze & Associates
264
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.
Rev 4 (Jan 2010)© 2010 Maze & Associates
265
Changes with NIST SP 800-37 Rev 1 Draft 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.
Rev 4 (Jan 2010)© 2010 Maze & Associates
266
Developing the test plan ST&E (Security Testing & 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
Rev 4 (Jan 2010)© 2010 Maze & Associates
267
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
268
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
269
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) Rev 4 (Jan 2010)© 2010 Maze & Associates
270
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 Rev 4 (Jan 2010)© 2010 Maze & Associates
271
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
Remediation Planning
Chapter 14
273
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
274
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
275
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)© 2010 Maze & Associates
276
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
277
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
278
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
Essential C & A Documentation
Chapter 15
280
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-100Rev 4 (Jan 2010)© 2010 Maze & Associates
281
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-100Rev 4 (Jan 2010)© 2010 Maze & Associates
282
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
283
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
284
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
285
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?
Rev 4 (Jan 2010)© 2010 Maze & Associates
Documenting the Accreditation Decision
Chapter 16
287
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
288
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
289
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
290
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
291
Approving authority qualifications Budget authority Qualities
Integrity Competence Common sense Involvement Initiative
Entrusted position with substantial authority
Rev 4 (Jan 2010)© 2010 Maze & Associates
292
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
293
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. Rev 4 (Jan 2010)© 2010 Maze & Associates
294
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
Rev 4 (Jan 2010)© 2010 Maze & Associates
295
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?Rev 4 (Jan 2010)© 2010 Maze & Associates
Additional Information
Tips & Tricks
297
Each part of the process has a NIST Document
NIST SP 800-100 Chapter 10 Rev 4 (Jan 2010)© 2010 Maze & Associates
298
Key NIST DocumentsDocument 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 Rev 4 (Jan 2010)© 2010 Maze & Associates