More Related Content Similar to NIST IT Standards for Local Governments 2010 (20) More from Donald E. Hester (20) NIST IT Standards for Local Governments 20103. 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)3 © 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)5 © 2010 Maze & Associates
6. 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?
7. 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
8. 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
9. NIST
There is no compulsory IT standard required for local
governments.
The National Institute of Standards andTechnology
(NIST) encourages state, local and tribal governments to
consider the use of these guidelines, as appropriate.
In adopting NIST standards the local government
demonstrates due diligence.
"State, local, and tribal governments, as well as private sector organizations are
encouraged to consider using these guidelines, as appropriate."
- NIST SP 800-37 Rev 1 pg 11
10. State of California
Rev 4 (Jan 2010)© 2010 Maze & Associates10
The State of
California is going
to adopt NIST
standards
Modified version
NIST SP 800-53
NIST SP 800-37
11. 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
12. 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)13 © 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)14 © 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)15 © 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)16 © 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)17 © 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)18 © 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)19 © 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)20 © 2010 Maze & Associates
21. Building a Successful Enterprise Certification
and Accreditation (C & A) Program
Section I
Rev 4 (Jan 2010)© 2010 Maze & Associates21
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)23 © 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)24 © 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)25 © 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)26 © 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)27 © 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)28 © 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)29 © 2010 Maze & Associates
30. Sample C & A Policy
Reference: http://www.tess-llc.com/Certification%20&%20Accreditation%20PolicyV4.pdf
Rev 4 (Jan 2010)30 © 2010 Maze & Associates
31. C & A Guidance Development Life Cycle
• Awareness
• Monitoring
• Enforcement
• Maintenance
• Retirement
• Communication
• Compliance
• Exceptions
• Creation
• Review
• Approval
Development Implementation
MaintenanceDisposal
Life-cycle for the development of the documentation for the C & A process
Rev 4 (Jan 2010)31 © 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)32 © 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)33 © 2010 Maze & Associates
34. System Owner
Authorizing Official
Certification Agent
Prepare
Documentation
Initiation Phase 1
1. Describe the System
2. Categorize its C.I.A.
3. Identify Threats to it
4. Identify its Vulnerabilities
5. Identify In-Place and
Planned Security Controls
6. Determine its Initial Risks
Initiation
NIST 800-37 Risk Management & Certification and Accreditation Tasks
Notify Officials &
Identify
Resources
Planning Phase 3
1. Notify Program Officials
2. Identify Resources Needed
and Plan execution of
Activities
Initiation
Report & Document
Status
O&M Phase 9
1. Update Security Plan
2. Update Plan of Action
& Milestones
3. Report Status
Monitoring
Monitor Security
Controls
O&M Phase 9
1. Select In-Place Security
Controls
2. Assess Selected
Security Controls
Monitoring
Manage & Control
Configuration
O&M Phase 9
1. Document System
Changes
2. Analyze Security
Impacts
Monitoring
Analyze, Update
& Accept System
Security Plan
Multiple Phases 4-6
1. Review Security C.I.A.
Categorizations
2. Analyze Security Plan
3. Update Security Plan
4. Obtain Authorizing
Official Acceptance of
Security Plan
Initiation
Assess & Evaluate
Security Controls
Integration & Test
Phase 7
1. Prepare Documentation &
Supporting Materials
2. Review Methods and
Test Procedures
3. Assess & Evaluate In-
Place Security Controls
4. Report Security
Assessment Results
Certification
Document Security
Accreditation
Integration & Test
Phase 7
1. Transmit Security
Accreditation Package
2. Update Security Plan
Accreditation
Document Security
Certification
Integration & Test
Phase 7
1. Provide Findings and
Recommendations
2. Update Security Plan
3. Prepare Plan of Action &
Milestones
4. Assemble Accreditation
Package
Certification
Make Security
Accreditation
Decision
Integration & Test
Phase 7
1. Determine Final Risk
Levels
2. Accept Residual Risk
Accreditation
System Owner
Phase 1 – Task 1
Phase 3 – Task 6
Phase 1 – Task 2 Phase 1 – Task 3 Phase 2 – Task 4 Phase 2 – Task 5
Phase 3 – Task 7 Phase 4 – Task 8 Phase 4 – Task 9 Phase 4 – Task 10
Primary Responsibility
SDLC
NIST 800-37
Phases
Rev 4 (Jan 2010)34 © 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)35 © 2010 Maze & Associates
36. Establishing C & A points of contact
Chief Information Security Officer (CISO) is directly
responsible.
Other key players
System Owners
C & AWorkgroup
Security Steering Committee
IT administrators
Key areas of knowledge for Organizations
Operations
Hierarchy
Management
Strategies
Initiative
Rev 4 (Jan 2010)36 © 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)37 © 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)38 © 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)
RecertificationTriggers or Reassessment Risk
NewVulnerabilities
New Risks
Environment changes
Control failure
Audit findings
Rev 4 (Jan 2010)39 © 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)40 © 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
NewVulnerabilities (major possibly, minor are handled by patch
management)
New Risks (brought about by changes)
Environment changes (Application or OS change)
Control failure (Controls not working as intended)
Audit findings (Missing controls)
Rev 4 (Jan 2010)41 © 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)42 © 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)43 © 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)44 © 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)45 © 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)46 © 2010 Maze & Associates
47. 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)48 © 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)49 © 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)50 © 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)51 © 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)52 © 2010 Maze & Associates
53. Certifying Agent
AKA: Assessor or Auditor
Independent authority
Impartial and unbiased (separation of duties)
Measures effectiveness and completeness of controls
The certification agent is an individual, group, or organization
responsible for conducting a security certification, or
comprehensive assessment of the management, operational,
and technical security controls in an information system to
determine the extent to which the controls are implemented
correctly, operating as intended, and producing the desired
outcome with respect to meeting the security requirements
for the system. - NIST SP 800-37
Rev 4 (Jan 2010)53 © 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)54 © 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)55 © 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)56 © 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)57 © 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)58 © 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)59 © 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)60 © 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)61 © 2010 Maze & Associates
63. Executive Management
Crucial Role
Establish Policy
Enforce Policy
Allocate Resources
Maintain visibility of program
Rev 4 (Jan 2010)63 © 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)64 © 2010 Maze & Associates
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)66 © 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 Prevention
Rev 4 (Jan 2010)67 © 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)68 © 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)69 © 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)70 © 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)71 © 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)72 © 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)73 © 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)74 © 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)75 © 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)77 © 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)78 © 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)79 © 2010 Maze & Associates
81. Certification and Accreditation in the SDLC
Reference: NIST SP 800-100, Information Security Handbook:A Guide for ManagersRev 4 (Jan 2010)81 © 2010 Maze & Associates
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)82 © 2010 Maze & Associates
83. Certification and Accreditation in the SDLC
Reference: NIST SP 800-100, Information Security Handbook:A Guide for ManagersRev 4 (Jan 2010)83 © 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)84 © 2010 Maze & Associates
85. Certification and Accreditation in the SDLC
Reference: NIST SP 800-100, Information Security Handbook:A Guide for ManagersRev 4 (Jan 2010)85 © 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)86 © 2010 Maze & Associates
87. Certification and Accreditation in the SDLC
Reference: NIST SP 800-100, Information Security Handbook:A Guide for ManagersRev 4 (Jan 2010)87 © 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)88 © 2010 Maze & Associates
89. Certification and Accreditation in the SDLC
Reference: NIST SP 800-100, Information Security Handbook:A Guide for ManagersRev 4 (Jan 2010)89 © 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)90 © 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)91 © 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)92 © 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
Accreditation
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)93 © 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)94 © 2010 Maze & Associates
96. Summary
Reference: NIST SP 800-100, Information Security Handbook:A Guide for ManagersRev 4 (Jan 2010)96 © 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)97 © 2010 Maze & Associates
98. 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)99 © 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)100 © 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)101 © 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)102 © 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)103 © 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)104 © 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)105 © 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)106 © 2010 Maze & Associates
107. Lack of enforcement
Accountability
Inconsistency can lead to failure
Everyone must be onboard for the program
Rev 4 (Jan 2010)107 © 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)108 © 2010 Maze & Associates
109. Poor timing
If the organization is not ready for implementation
Organization may have more pressing needs
Rev 4 (Jan 2010)109 © 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)110 © 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)111 © 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)112 © 2010 Maze & Associates
113. C & A Process
Section II
Rev 4 (Jan 2010)© 2010 Maze & Associates113
114. C & A Project Planning
Chapter 5
115. Quote
If you fail to plan,
you plan to fail!
Rev 4 (Jan 2010)115 © 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 Baseline
2. Identify Prioritization Requirements
3. Conduct Enterprise-Level Prioritization
4. Conduct System-Level Prioritization
5. Develop Supporting Materials
6. Implement Investment Review Board (IRB)
and Portfolio Management
7. Submit Exhibit 300s, Exhibit 53, and
Conduct Program Management
CPIC = Capital Planning and Investment Control
Rev 4 (Jan 2010)116 © 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)117 © 2010 Maze & Associates
118. Dealing with people
Project manager
Need to be a people-person
Manage expectations
Manage objectives
Need to identify the individuals
in the project
Develop a contact list
Rev 4 (Jan 2010)118 © 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)119 © 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)120 © 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)121 © 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)122 © 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)123 © 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)124 © 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)125 © 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)126 © 2010 Maze & Associates
127. Other tasks
Don’t forget training
Most forgotten aspect is training
Rev 4 (Jan 2010)127 © 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)128 © 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)129 © 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)130 © 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)131 © 2010 Maze & Associates
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)133 © 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)134 © 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)135 © 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)136 © 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)137 © 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)138 © 2010 Maze & Associates
139. System and Subsystem
NIST SP 800-100
System 1
Subsystem A
Subsystem B
Subsystem C
Rev 4 (Jan 2010)139 © 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)140 © 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)141 © 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)143 © 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)144 © 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)145 © 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)146 © 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)147 © 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)148 © 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)149 © 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)151 © 2010 Maze & Associates
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)153 © 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)154 © 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)155 © 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)156 © 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)157 © 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)158 © 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)159 © 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)160 © 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)161 © 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)162 © 2010 Maze & Associates
165. Document All Data Forms
DataType Confidentiality Integrity Availability
Personal Identity and Authentication Moderate Moderate Moderate
Help Desk Services Low Low Low
Budget & Finance Moderate Moderate Low
Accounting Low Moderate Low
Space Operations Low High High
Rev 4 (Jan 2010)165 © 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)166 © 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)167 © 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)168 © 2010 Maze & Associates
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)170 © 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)171 © 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)172 © 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)173 © 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)174 © 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)175 © 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
Implementation
Plan
Maintenance
Recertification
or Retirement
Rev 4 (Jan 2010)176 © 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)177 © 2010 Maze & Associates
178. Plan format
Should be flexible
There are a number of different forms
Rev 4 (Jan 2010)178 © 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)179 © 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)180 © 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)181 © 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)182 © 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)184 © 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)185 © 2010 Maze & Associates
186. Component Example
Implementation Detail:
Component 1 (Network Devices)
Control satisfied via the following:A configuration management
system retrieves a baseline configuration from all network
devices and reports changes via a version control system.The
checklist for installation includes a requirement to register
new devices in the version control system.The system
compares deltas in configurations and notifies technical staff
about changes.
Component 2 (Workstations)
Control satisfied via the workstation benchmark documentation
which records what has changed in the baseline. Agency
Incident Response team performs vulnerability Scans on a
regular basis. InformationTechnology Department reports
changes system admin evaluates materiality.
Rev 4 (Jan 2010)186 © 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)187 © 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)188 © 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)189 © 2010 Maze & Associates
190. Common Control Example
Implementation Detail:
Common Control: Item (i) Control satisfied via Security of
InformationTechnology Policy, Chapter 19 – Identification
and Authentication, and Chapter 20 – Logical Access
Controls. Item(ii) defined by Common Access Controls
Procedures for IT Systems Policy (when finalized).
Rev 4 (Jan 2010)190 © 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)191 © 2010 Maze & Associates
192. Hybrid Control Example
PS-3 PERSONNEL SCREENING
Control: The organization screens individuals requiring access to organizational
information and information systems before authorizing access.
Implementation Detail:
Center Hybrid Control; see System Owner action(s) needed
Control is satisfied via the following:
Guard Service Actions:
All Center Level access is managed by Guard Service.
Human Resources Actions:
Civil Servants and contractors are screened by Human Resources.
System Owner Action:
Access is not granted to users until screening by Guard Service and Human Resources.
No screening beyond what is provided by Guard Service and Human Resources.
Rev 4 (Jan 2010)192 © 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)193 © 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 computers
Criteria Rating
Confidentiality Moderate
Availability Low
Integrity Low
Rev 4 (Jan 2010)194 © 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)195 © 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)196 © 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)197 © 2010 Maze & Associates
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)199 © 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)200 © 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 systems
OMB recommends that agencies use NIST SP
800-47 to ensure compliance for connections
to non-agency systems.
Rev 4 (Jan 2010)202 © 2010 Maze & Associates
203. Communication between parties is Important
NIST SP 800-100
Ensure that the interconnection is properly maintained
and that security controls remain effective;
Facilitate effective change management activities by
making it easy for both sides to notify each other about
planned system changes that could affect the
interconnection; and
Enable prompt notification by both sides of security
incidents and system disruptions and facilitate
coordinated response, if necessary.
Rev 4 (Jan 2010)203 © 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)204 © 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)207 © 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)208 © 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)209 © 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)210 © 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)211 © 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)214 © 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)215 © 2010 Maze & Associates
218. Document All Data Forms
DataType Confidentiality Integrity Availability
Personal Identity and Authentication Moderate Moderate Moderate
Help Desk Services Low Low Low
Budget & Finance Moderate Moderate Low
Accounting Low Moderate Low
Space Operations Low High High
High Watermark Moderate High High
Overall High Watermark High
Rev 4 (Jan 2010)218 © 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)221 © 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)222 © 2010 Maze & Associates
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)224 © 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)225 © 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)226 © 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)227 © 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)228 © 2010 Maze & Associates
230. Risk assessment process
1. System Characterization
2. Threat Identification
3. Vulnerability Identification
4. Control Analysis
5. Likelihood Determination
6. Impact Analysis
7. Risk Determination
8. Control Recommendation
9. Results Document
NIST SP 800-30 Rev 4 (Jan 2010)230 © 2010 Maze & Associates
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)231 © 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)234 © 2010 Maze & Associates
237. Impact analysis
Input
• Mission impact
analysis
• Asset criticality
assessment
• Criticality
• Sensitivity
Output
• Impact Rating
Impact Analysis
Rev 4 (Jan 2010)237 © 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-30
Rev 4 (Jan 2010)238 © 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)239 © 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)240 © 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)243 © 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)245 © 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)246 © 2010 Maze & Associates
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)248 © 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)249 © 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)250 © 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)251 © 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)252 © 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)253 © 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)254 © 2010 Maze & Associates
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)256 © 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)257 © 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)258 © 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 AuditTools)
Rev 4 (Jan 2010)259 © 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)260 © 2010 Maze & Associates
261. Security Control Assessment Tasks
Task 1“Assemble any documentation and supporting materials
necessary for the assessment of the security controls in the
information system; if these documents include previous assessments
of security controls, review the findings, results, and evidence.”
Task 2 “Select, or develop when needed, appropriate methods and
procedures to assess the management, operational, and technical
security controls in the information system.”
Task 3 “Assess the management, operational, and technical security
controls in the information system using methods and procedures
selected or developed.”
Task 4 “Prepare the final security assessment report.”
NIST SP 800-37
Rev 4 (Jan 2010)261 © 2010 Maze & Associates
262. Security Documentation Tasks
Task 1“Provide the information system owner with the security
assessment report.”
Task 2 “Update the system security plan (and risk assessment) based
on the results of the security assessment and any modifications to
the security controls in the information system.”
Task 3 “Prepare the plan of action and milestones based on the
results of the security assessment.”
Task 4 “Assemble the final security accreditation package and submit
to authorizing official.”
NIST SP 800-37
Rev 4 (Jan 2010)262 © 2010 Maze & Associates
263. Changes with NIST SP 800-37 Rev 1 Draft
Rev 4 (Jan 2010)263 © 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)264 © 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)265 © 2010 Maze & Associates
266. Developing the test plan
ST&E (SecurityTesting & Evaluation Procedures)
Aka:Audit approach
Detailed description of the testing methodology that will be
used
Will include the following
Scope
Testing requirements
Testing approach
Tests to be used
Timeline
Responsibilities
Test team
Remediation plan, recommendations
Rev 4 (Jan 2010)266 © 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)267 © 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)268 © 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)269 © 2010 Maze & Associates