SlideShare a Scribd company logo
1 of 298
Implementing NIST for Local
Governments
Rev 1 (JUN 2010)© 2010 Maze & Associates1
Introductions
Name
Employer
Security Experience
NIST Experience
Rev 4 (Jan 2010)2 © 2010 Maze & Associates
Suggested Materials
 Building and Implementing a Security
Certification and Accreditation Program,
Official (ISC)2 Guide to the CAP CBK, by
Patrick D. Howard
 NIST SP 800-100
 NIST SP 800-37 rev 1
Rev 4 (Jan 2010)3 © 2010 Maze & Associates
Introduction
Rev 4 (Jan 2010)© 2010 Maze & Associates4
Introduction
 Due Diligence
 Standards
 NIST / FISMA Background
 A Risk Based Approach
 What is Certification and Accreditation
 Systems Security Approach
 Benefits
 External Drivers
Rev 4 (Jan 2010)5 © 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 andTechnology
(NIST) encourages state, local and tribal governments to
consider the use of these guidelines, as appropriate.
 In adopting NIST standards the local government
demonstrates due diligence.
"State, local, and tribal governments, as well as private sector organizations are
encouraged to consider using these guidelines, as appropriate."
- NIST SP 800-37 Rev 1 pg 11
State of California
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
Other Standards
 Yes there are other standards
 PCI
 ISO 27002 (ISO 17799)
 COBIT
 Etc..
 If ever a local government is required to follow a standard
it would be NIST
 NIST is recommend by DOJ for local police
 NIST is a Government friendly standard
PCI & NIST
 PCI has a narrow focus (just card holder data)
 NIST has a broad focus (all of IT)
 If you focus on PCI only you may sacrifice in other areas
 If you implement a standard like NIST you are 90% there
for PCI
 If a new regulation comes up you are already prepared
NIST/FISMA Background
 E-Government Act (Public Law 107-347) passed and
signed into law in December 2002
 Title III of the E-Government Act, Federal Information
Security Management Act (FISMA)
 Required for all government agencies
 To develop, document, and implement an agency-wide
information security program
 To provide information security for the information and
systems that support the operations and assets of the
agency
 Applies to contractors and other sources
Rev 4 (Jan 2010)13 © 2010 Maze & Associates
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
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
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
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
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
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
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
Building a Successful Enterprise Certification
and Accreditation (C & A) Program
Section I
Rev 4 (Jan 2010)© 2010 Maze & Associates21
Key Elements of an Enterprise C & A
Program
Chapter 1
The C & A business case
 What is the benefit to the organization?
 Due diligence
 Accountability
 Implementation of risk management
 Visibility of risk
 Cost-effectiveness
 A strong business case will help enlist support
 The C & A program will help them meet their
organizational needs, reach their goals and accomplish
their mission
 C & A is a business enabler
Rev 4 (Jan 2010)23 © 2010 Maze & Associates
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
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
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
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
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
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
Sample C & A Policy
Reference: http://www.tess-llc.com/Certification%20&%20Accreditation%20PolicyV4.pdf
Rev 4 (Jan 2010)30 © 2010 Maze & Associates
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
C & A Roles and Responsibilities
Chapter 2
Primary roles and responsibilities
 The five primary roles
 Chief Information Security Officer (CISO)
 System Owner
 Information Systems Security Officer (ISSO)
 Certifying Agent
 Approving Authority (AA)
 Authorizing Official (AO)
 Designated Approving Authority (DAA)
 Different C & A framework use different names
 NIST, DCID 6/3, DITSCAP, DIACAP, NIACAP, ISO
Rev 4 (Jan 2010)48 © 2010 Maze & Associates
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
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
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
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
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
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
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
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
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
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
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
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
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
Facility Manager
 Responsible for physical security
 Responsible for environmental controls
Rev 4 (Jan 2010)62 © 2010 Maze & Associates
Executive Management
 Crucial Role
 Establish Policy
 Enforce Policy
 Allocate Resources
 Maintain visibility of program
Rev 4 (Jan 2010)63 © 2010 Maze & Associates
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
Role Relationships
IG
CA
CISO
ISSO
CIO
SA
BUM
EU
Independence
SOD
SOD
IOSO
AA
Program
System
Rev 4 (Jan 2010)65 © 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.
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
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
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
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
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
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
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
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
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
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
Certifications
CISSP
CISM
CISSP
ISSMP
CAP CISA
GSNA
SSCP
Security+
CISSP
ISSEP/
ISSAP
CSSLP
Management / Risk
Audit
Software
Dev
Network /
Communications
Rev 4 (Jan 2010)76 © 2010 Maze & Associates
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
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
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
The C & A Life Cycle
Chapter 3
Certification and Accreditation in the SDLC
Reference: NIST SP 800-100, Information Security Handbook:A Guide for ManagersRev 4 (Jan 2010)81 © 2010 Maze & Associates
Initiation phase
 Document the sensitivity of the system with the risk
assessment
 Identify threats and vulnerabilities
 Control selection
 With limited resources you will have to prioritize
All information technology (IT) projects have a starting point, what is commonly referred
to as the initiation phase. During the initiation phase, the organization establishes the
need for a particular system and documents its purpose.The information to be processed,
transmitted, or stored is typically evaluated, as well as who is required access to such
information and how (in high-level terms). In addition, it is often determined whether the
project will be an independent information system or a component of an already-defined
system.A preliminary risk assessment is typically conducted in this phase, and security
planning documents are initiated (system security plan). NIST SP 800-100
Rev 4 (Jan 2010)82 © 2010 Maze & Associates
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
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
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
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
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
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
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
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
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
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
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
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
NISTSP800-100
Rev 4 (Jan 2010)95 © 2010 Maze & Associates
Summary
Reference: NIST SP 800-100, Information Security Handbook:A Guide for ManagersRev 4 (Jan 2010)96 © 2010 Maze & Associates
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
Why C & A Programs Fail
Chapter 4
Program Risks
 Programs run risks as well
 Programs don’t always fail
 Sometimes the program is not as effective as it could be
 Sometimes the program is not as efficient as it could be
Rev 4 (Jan 2010)99 © 2010 Maze & Associates
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
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
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
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
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
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
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
Lack of enforcement
 Accountability
 Inconsistency can lead to failure
 Everyone must be onboard for the program
Rev 4 (Jan 2010)107 © 2010 Maze & Associates
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
Poor timing
 If the organization is not ready for implementation
 Organization may have more pressing needs
Rev 4 (Jan 2010)109 © 2010 Maze & Associates
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
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
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
C & A Process
Section II
Rev 4 (Jan 2010)© 2010 Maze & Associates113
C & A Project Planning
Chapter 5
Quote
If you fail to plan,
you plan to fail!
Rev 4 (Jan 2010)115 © 2010 Maze & Associates
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
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
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
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
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
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
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
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
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
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
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
Other tasks
 Don’t forget training
 Most forgotten aspect is training
Rev 4 (Jan 2010)127 © 2010 Maze & Associates
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
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
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
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
System Inventory Process
Chapter 6
Inventory Project Work Plan
1
• Identify General Support Systems and Applications
• Identify Business Functions
• Identify automated information resources & categorize as GSS or application
2
• Classify GSS and applications
• Determine information sensitivity
• Determine mission criticality
3
• Determine what applications qualify as major applications
• Determine major applications support systems
• Non-major application become GSS
4
• Submit to CIO for review
• Business unit executive review
• Publish inventory
Rev 4 (Jan 2010)133 © 2010 Maze & Associates
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
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
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
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
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
System and Subsystem
NIST SP 800-100
System 1
Subsystem A
Subsystem B
Subsystem C
Rev 4 (Jan 2010)139 © 2010 Maze & Associates
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
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
Rev 4 (Jan 2010)142 © 2010 Maze & Associates
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
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
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
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
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
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
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
Inventory Is Central
Rev 4 (Jan 2010)150 © 2010 Maze & Associates
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
Assessing Data Sensitivity and Criticality
Chapter 7
Defining sensitivity
 The data is what dictates the sensitivity of the system
 Not the value of the hardware
 Not the value of the software
 Based on the following factor
 Confidentiality
 Availability
 Integrity
 Not all data needs the same level of protection
 Different requirements based on factors
 National defense – confidentiality
 Life safety – availability
 Financial – integrity
Rev 4 (Jan 2010)153 © 2010 Maze & Associates
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
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
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
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
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
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
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
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
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
NIST SP 800-60
DataType
Data
Description Data Sensitivity
Rev 4 (Jan 2010)163 © 2010 Maze & Associates
Data Explanation (NIST SP 800-60)
Rev 4 (Jan 2010)164 © 2010 Maze & Associates
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
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
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
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
System Security Plan (SSP)
Chapter 8
Paper Tiger?
 GCN, February 2007, Reported a pair
of security experts say FISMA is
fundamentally flawed.
 “FISMA wasn’t written badly, but the
measuring system they are using is
broken. What we measure now is,
‘Do you have a plan?’ Not whether
the plan actually improves security.
Too often, the plans do not improve
security”
Rev 4 (Jan 2010)170 © 2010 Maze & Associates
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
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
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
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
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
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
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
Plan format
 Should be flexible
 There are a number of different forms
Rev 4 (Jan 2010)178 © 2010 Maze & Associates
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
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
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
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
Rev 4 (Jan 2010)183 © 2010 Maze & Associates
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
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
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
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
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
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
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
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
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
Scoping Guidance
 System security plans should clearly identify which
security controls used scoping guidance and include a
description of the type of considerations that were made.
 Reasons for tailored controls
 Assessment of risk
 Organization-specific security requirements
 Specific threat information
 Cost-benefit analyses
 Availability of compensating controls
 Special circumstances
Source: NIST SP 800-100 § 8.4.1 Rev 4 (Jan 2010)193 © 2010 Maze & Associates
Scoping Guidance Example
 PE-11 EMERGENCY POWER
 Control:The organization provides a short-term
uninterruptible power supply to facilitate an orderly
shutdown of the information system in the event of a
primary power source loss.
 System consists of desktop computers
Criteria Rating
Confidentiality Moderate
Availability Low
Integrity Low
Rev 4 (Jan 2010)194 © 2010 Maze & Associates
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
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
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
Coordinating Security for Interconnected
Systems
Chapter 9
The solution
 How do you protect your organization’s data when it is
someone else's system?
 A formal agreement establishing
 Required levels of protection
 Required reporting
 Time period
 Called a memorandum of understanding (MOU) or
memorandum of agreement (MOA)
 Interconnection security agreement (ISA) supports the
MOU/MOA – specifics
Rev 4 (Jan 2010)199 © 2010 Maze & Associates
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
Systems Interconnection
NIST SP 800-100
Rev 4 (Jan 2010)201 © 2010 Maze & Associates
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
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
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
Sample MOU/MOA
NIST SP 800-100 Chapter 6 Rev 4 (Jan 2010)205 © 2010 Maze & Associates
Sample ISA
NIST SP 800-100 Chapter 6 Rev 4 (Jan 2010)206 © 2010 Maze & Associates
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
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
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
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
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
Minimum Security Baselines and Best
Practices
Chapter 10
Levels of control
NIST SP 800-100 and NIST SP 800-53 Rev 4 (Jan 2010)213 © 2010 Maze & Associates
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
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
NIST 800-60
Rev 4 (Jan 2010)216 © 2010 Maze & Associates
NIST SP 800-60
DataType
Data
Description Data Sensitivity
Rev 4 (Jan 2010)217 © 2010 Maze & Associates
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
NIST SP 800-60
Rev 4 (Jan 2010)219 © 2010 Maze & Associates
Security Control Selection Process
NIST SP 800-53A Rev 2 Rev 4 (Jan 2010)220 © 2010 Maze & Associates
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
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
Assessing Risk
Chapter 11
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
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
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
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
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
Risk Assessment
Asset
Vulnerability
Threat
Threat
Asset
Vulnerability
Countermeasure
Rev 4 (Jan 2010)229 © 2010 Maze & Associates
Risk assessment process
1. System Characterization
2. Threat Identification
3. Vulnerability Identification
4. Control Analysis
5. Likelihood Determination
6. Impact Analysis
7. Risk Determination
8. Control Recommendation
9. Results Document
NIST SP 800-30 Rev 4 (Jan 2010)230 © 2010 Maze & Associates
Asset identification
Input
• Hardware
• Software
• System interfaces
• Data
• People
• Mission
• Reputation
Output
• System boundary
• System functions
• Criticality
• Sensitivity
System Characterization
Rev 4 (Jan 2010)231 © 2010 Maze & Associates
Threat identification
Input
• History of
attacks
• Intelligence
• Media
• Advisories
Output
• Threat
statement
Threat Identification
Rev 4 (Jan 2010)232 © 2010 Maze & Associates
Example Threats
NIST SP 800-30 Rev 4 (Jan 2010)233 © 2010 Maze & Associates
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
Control Analysis
Input
• Current
controls
• Planned
controls
Output
• List of
current and
planned
controls
Control Analysis
Rev 4 (Jan 2010)235 © 2010 Maze & Associates
Risk calculation
Input
• Threat-source
motivation
• Threat capacity
• Nature of
vulnerability
• Current controls
Output
• Rating
Likelihood Determination
Rev 4 (Jan 2010)236 © 2010 Maze & Associates
Impact analysis
Input
• Mission impact
analysis
• Asset criticality
assessment
• Criticality
• Sensitivity
Output
• Impact Rating
Impact Analysis
Rev 4 (Jan 2010)237 © 2010 Maze & Associates
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
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
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
Residual Risk
NIST SP 800-30 Rev 4 (Jan 2010)241 © 2010 Maze & Associates
Accepted or Unacceptable Risk
NIST SP 800-100 Rev 4 (Jan 2010)242 © 2010 Maze & Associates
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
NISTSP800-37Rev1Draft
Rev 4 (Jan 2010)244 © 2010 Maze & Associates
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
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
Security Procedures
Chapter 12
Security Procedures
 Purpose
 Procedure ensure that there is a uniform application
(repeatable)
 Provide users with instructions on “how to”
 Problems
 Administrator may not follow because it is routine or take
longer to complete a given task
 Responsibility
 System owner should develop
 Administrators should consider them mandatory
 Disciplinary action for failure to follow
Rev 4 (Jan 2010)248 © 2010 Maze & Associates
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
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
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
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
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
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
Certification Testing
Chapter 13
Certification and Accreditation
“The security certification and
accreditation process is designed to
ensure that an information system will
operate with the appropriate
management review, that there is
ongoing monitoring of security controls,
and that reaccreditation occurs
periodically.”
NIST SP 800-100
Rev 4 (Jan 2010)256 © 2010 Maze & Associates
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
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
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
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
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
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
Changes with NIST SP 800-37 Rev 1 Draft
Rev 4 (Jan 2010)263 © 2010 Maze & Associates
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
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
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
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
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
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
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010
NIST IT Standards for Local Governments 2010

More Related Content

What's hot

Introduction to Risk Management via the NIST Cyber Security Framework
Introduction to Risk Management via the NIST Cyber Security FrameworkIntroduction to Risk Management via the NIST Cyber Security Framework
Introduction to Risk Management via the NIST Cyber Security FrameworkPECB
 
Vulnerability Management: What You Need to Know to Prioritize Risk
Vulnerability Management: What You Need to Know to Prioritize RiskVulnerability Management: What You Need to Know to Prioritize Risk
Vulnerability Management: What You Need to Know to Prioritize RiskAlienVault
 
Cisco Security Presentation
Cisco Security PresentationCisco Security Presentation
Cisco Security PresentationSimplex
 
Improve Cybersecurity posture by using ISO/IEC 27032
Improve Cybersecurity posture by using ISO/IEC 27032Improve Cybersecurity posture by using ISO/IEC 27032
Improve Cybersecurity posture by using ISO/IEC 27032PECB
 
Reporting about Overview Summery of ISO-27000 Se.(ISMS)
Reporting about Overview Summery  of ISO-27000 Se.(ISMS)Reporting about Overview Summery  of ISO-27000 Se.(ISMS)
Reporting about Overview Summery of ISO-27000 Se.(ISMS)AHM Pervej Kabir
 
Introduction to NIST’s Risk Management Framework (RMF)
Introduction to NIST’s Risk Management Framework (RMF)Introduction to NIST’s Risk Management Framework (RMF)
Introduction to NIST’s Risk Management Framework (RMF)Donald E. Hester
 
Basic introduction to iso27001
Basic introduction to iso27001Basic introduction to iso27001
Basic introduction to iso27001Imran Ahmed
 
NIST Cybersecurity Framework Intro for ISACA Richmond Chapter
NIST Cybersecurity Framework Intro for ISACA Richmond ChapterNIST Cybersecurity Framework Intro for ISACA Richmond Chapter
NIST Cybersecurity Framework Intro for ISACA Richmond ChapterTuan Phan
 
Introduction: CISSP Certification
Introduction: CISSP CertificationIntroduction: CISSP Certification
Introduction: CISSP CertificationSam Bowne
 
Introduction to NIST Cybersecurity Framework
Introduction to NIST Cybersecurity FrameworkIntroduction to NIST Cybersecurity Framework
Introduction to NIST Cybersecurity FrameworkTuan Phan
 
How To Handle Cybersecurity Risk PowerPoint Presentation Slides
How To Handle Cybersecurity Risk PowerPoint Presentation SlidesHow To Handle Cybersecurity Risk PowerPoint Presentation Slides
How To Handle Cybersecurity Risk PowerPoint Presentation SlidesSlideTeam
 
NIST CyberSecurity Framework: An Overview
NIST CyberSecurity Framework: An OverviewNIST CyberSecurity Framework: An Overview
NIST CyberSecurity Framework: An OverviewTandhy Simanjuntak
 
CISSP - Chapter 2 - Asset Security
CISSP - Chapter 2 -  Asset SecurityCISSP - Chapter 2 -  Asset Security
CISSP - Chapter 2 - Asset SecurityKarthikeyan Dhayalan
 
Guide to Risk Management Framework (RMF)
Guide to Risk Management Framework (RMF)Guide to Risk Management Framework (RMF)
Guide to Risk Management Framework (RMF)MetroStar
 
Cybersecurity Frameworks and You: The Perfect Match
Cybersecurity Frameworks and You: The Perfect MatchCybersecurity Frameworks and You: The Perfect Match
Cybersecurity Frameworks and You: The Perfect MatchMcKonly & Asbury, LLP
 
Cybersecurity Framework - Introduction
Cybersecurity Framework - IntroductionCybersecurity Framework - Introduction
Cybersecurity Framework - IntroductionMuhammad Akbar Yasin
 

What's hot (20)

Introduction to Risk Management via the NIST Cyber Security Framework
Introduction to Risk Management via the NIST Cyber Security FrameworkIntroduction to Risk Management via the NIST Cyber Security Framework
Introduction to Risk Management via the NIST Cyber Security Framework
 
Vulnerability Management: What You Need to Know to Prioritize Risk
Vulnerability Management: What You Need to Know to Prioritize RiskVulnerability Management: What You Need to Know to Prioritize Risk
Vulnerability Management: What You Need to Know to Prioritize Risk
 
ISO 27001
ISO 27001ISO 27001
ISO 27001
 
Cisco Security Presentation
Cisco Security PresentationCisco Security Presentation
Cisco Security Presentation
 
Improve Cybersecurity posture by using ISO/IEC 27032
Improve Cybersecurity posture by using ISO/IEC 27032Improve Cybersecurity posture by using ISO/IEC 27032
Improve Cybersecurity posture by using ISO/IEC 27032
 
Reporting about Overview Summery of ISO-27000 Se.(ISMS)
Reporting about Overview Summery  of ISO-27000 Se.(ISMS)Reporting about Overview Summery  of ISO-27000 Se.(ISMS)
Reporting about Overview Summery of ISO-27000 Se.(ISMS)
 
Introduction to NIST’s Risk Management Framework (RMF)
Introduction to NIST’s Risk Management Framework (RMF)Introduction to NIST’s Risk Management Framework (RMF)
Introduction to NIST’s Risk Management Framework (RMF)
 
Basic introduction to iso27001
Basic introduction to iso27001Basic introduction to iso27001
Basic introduction to iso27001
 
NIST Cybersecurity Framework Intro for ISACA Richmond Chapter
NIST Cybersecurity Framework Intro for ISACA Richmond ChapterNIST Cybersecurity Framework Intro for ISACA Richmond Chapter
NIST Cybersecurity Framework Intro for ISACA Richmond Chapter
 
Introduction: CISSP Certification
Introduction: CISSP CertificationIntroduction: CISSP Certification
Introduction: CISSP Certification
 
Introduction to NIST Cybersecurity Framework
Introduction to NIST Cybersecurity FrameworkIntroduction to NIST Cybersecurity Framework
Introduction to NIST Cybersecurity Framework
 
27001.pptx
27001.pptx27001.pptx
27001.pptx
 
How To Handle Cybersecurity Risk PowerPoint Presentation Slides
How To Handle Cybersecurity Risk PowerPoint Presentation SlidesHow To Handle Cybersecurity Risk PowerPoint Presentation Slides
How To Handle Cybersecurity Risk PowerPoint Presentation Slides
 
NIST CyberSecurity Framework: An Overview
NIST CyberSecurity Framework: An OverviewNIST CyberSecurity Framework: An Overview
NIST CyberSecurity Framework: An Overview
 
NIST Cybersecurity Framework (CSF) 2.0: What has changed?
NIST Cybersecurity Framework (CSF) 2.0: What has changed?NIST Cybersecurity Framework (CSF) 2.0: What has changed?
NIST Cybersecurity Framework (CSF) 2.0: What has changed?
 
CISSP - Chapter 2 - Asset Security
CISSP - Chapter 2 -  Asset SecurityCISSP - Chapter 2 -  Asset Security
CISSP - Chapter 2 - Asset Security
 
Guide to Risk Management Framework (RMF)
Guide to Risk Management Framework (RMF)Guide to Risk Management Framework (RMF)
Guide to Risk Management Framework (RMF)
 
Defense In Depth Using NIST 800-30
Defense In Depth Using NIST 800-30Defense In Depth Using NIST 800-30
Defense In Depth Using NIST 800-30
 
Cybersecurity Frameworks and You: The Perfect Match
Cybersecurity Frameworks and You: The Perfect MatchCybersecurity Frameworks and You: The Perfect Match
Cybersecurity Frameworks and You: The Perfect Match
 
Cybersecurity Framework - Introduction
Cybersecurity Framework - IntroductionCybersecurity Framework - Introduction
Cybersecurity Framework - Introduction
 

Viewers also liked

NIST Cybersecurity Framework - Mindmap
NIST Cybersecurity Framework - MindmapNIST Cybersecurity Framework - Mindmap
NIST Cybersecurity Framework - MindmapWAJAHAT IQBAL
 
Marcos seguridad-v040811
Marcos seguridad-v040811Marcos seguridad-v040811
Marcos seguridad-v040811faau09
 
Review of NIST Security Controls SC-28 SC-10
Review of NIST Security Controls SC-28 SC-10Review of NIST Security Controls SC-28 SC-10
Review of NIST Security Controls SC-28 SC-10Fuad Khan
 
Updated Use Case Narratives
Updated Use Case NarrativesUpdated Use Case Narratives
Updated Use Case NarrativesJhoy Pedreza
 
Information Security Management. Security solutions copy
Information Security Management. Security solutions copyInformation Security Management. Security solutions copy
Information Security Management. Security solutions copyyuliana_mar
 
Information Security Committee Presentation Sample
Information Security Committee Presentation SampleInformation Security Committee Presentation Sample
Information Security Committee Presentation Sampleoaes2006
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 8: Implement ...
Understanding the Risk Management Framework & (ISC)2 CAP Module 8: Implement ...Understanding the Risk Management Framework & (ISC)2 CAP Module 8: Implement ...
Understanding the Risk Management Framework & (ISC)2 CAP Module 8: Implement ...Donald E. Hester
 
Presentation on Effectively and Securely Using the Cloud Computing Paradigm v26
Presentation on Effectively and Securely Using the Cloud Computing Paradigm v26Presentation on Effectively and Securely Using the Cloud Computing Paradigm v26
Presentation on Effectively and Securely Using the Cloud Computing Paradigm v26Bill Annibell
 
Coso internal control integrated framework
Coso internal control   integrated frameworkCoso internal control   integrated framework
Coso internal control integrated frameworkIrfan Ahmed - ACA, CICA
 
EAS-SEC: Framework for securing business applications
EAS-SEC: Framework for securing business applicationsEAS-SEC: Framework for securing business applications
EAS-SEC: Framework for securing business applicationsERPScan
 
CYBERSECURITY - Best Practices,Concepts & Case Study (Mindmap)
CYBERSECURITY - Best Practices,Concepts & Case Study (Mindmap)CYBERSECURITY - Best Practices,Concepts & Case Study (Mindmap)
CYBERSECURITY - Best Practices,Concepts & Case Study (Mindmap)WAJAHAT IQBAL
 
FedRAMP 2.0 Control-Implementation-Summary (CIS) v2 1 cross-matrixed with Fed...
FedRAMP 2.0 Control-Implementation-Summary (CIS) v2 1 cross-matrixed with Fed...FedRAMP 2.0 Control-Implementation-Summary (CIS) v2 1 cross-matrixed with Fed...
FedRAMP 2.0 Control-Implementation-Summary (CIS) v2 1 cross-matrixed with Fed...James W. De Rienzo
 
From ISO to Implementation A framework for ECM Implementation
From ISO to Implementation  A framework for ECM ImplementationFrom ISO to Implementation  A framework for ECM Implementation
From ISO to Implementation A framework for ECM Implementationgbroadbent67
 
NISTs Cybersecurity Framework -- Comparison with Best Practice
NISTs Cybersecurity Framework -- Comparison with Best PracticeNISTs Cybersecurity Framework -- Comparison with Best Practice
NISTs Cybersecurity Framework -- Comparison with Best PracticeDavid Ochel
 
COBIT 5 IT Governance Model: an Introduction
COBIT 5 IT Governance Model: an IntroductionCOBIT 5 IT Governance Model: an Introduction
COBIT 5 IT Governance Model: an Introductionaqel aqel
 
ISO27001: Implementation & Certification Process Overview
ISO27001: Implementation & Certification Process OverviewISO27001: Implementation & Certification Process Overview
ISO27001: Implementation & Certification Process OverviewShankar Subramaniyan
 
Security architecture frameworks
Security architecture frameworksSecurity architecture frameworks
Security architecture frameworksJohn Arnold
 

Viewers also liked (20)

NIST Cybersecurity Framework - Mindmap
NIST Cybersecurity Framework - MindmapNIST Cybersecurity Framework - Mindmap
NIST Cybersecurity Framework - Mindmap
 
Práctica calificada 2
Práctica calificada 2Práctica calificada 2
Práctica calificada 2
 
Marcos seguridad-v040811
Marcos seguridad-v040811Marcos seguridad-v040811
Marcos seguridad-v040811
 
Review of NIST Security Controls SC-28 SC-10
Review of NIST Security Controls SC-28 SC-10Review of NIST Security Controls SC-28 SC-10
Review of NIST Security Controls SC-28 SC-10
 
Acitivity diagram
Acitivity diagramAcitivity diagram
Acitivity diagram
 
Updated Use Case Narratives
Updated Use Case NarrativesUpdated Use Case Narratives
Updated Use Case Narratives
 
Information Security Management. Security solutions copy
Information Security Management. Security solutions copyInformation Security Management. Security solutions copy
Information Security Management. Security solutions copy
 
Information Security Committee Presentation Sample
Information Security Committee Presentation SampleInformation Security Committee Presentation Sample
Information Security Committee Presentation Sample
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 8: Implement ...
Understanding the Risk Management Framework & (ISC)2 CAP Module 8: Implement ...Understanding the Risk Management Framework & (ISC)2 CAP Module 8: Implement ...
Understanding the Risk Management Framework & (ISC)2 CAP Module 8: Implement ...
 
Presentation on Effectively and Securely Using the Cloud Computing Paradigm v26
Presentation on Effectively and Securely Using the Cloud Computing Paradigm v26Presentation on Effectively and Securely Using the Cloud Computing Paradigm v26
Presentation on Effectively and Securely Using the Cloud Computing Paradigm v26
 
Coso internal control integrated framework
Coso internal control   integrated frameworkCoso internal control   integrated framework
Coso internal control integrated framework
 
EAS-SEC: Framework for securing business applications
EAS-SEC: Framework for securing business applicationsEAS-SEC: Framework for securing business applications
EAS-SEC: Framework for securing business applications
 
CYBERSECURITY - Best Practices,Concepts & Case Study (Mindmap)
CYBERSECURITY - Best Practices,Concepts & Case Study (Mindmap)CYBERSECURITY - Best Practices,Concepts & Case Study (Mindmap)
CYBERSECURITY - Best Practices,Concepts & Case Study (Mindmap)
 
FedRAMP 2.0 Control-Implementation-Summary (CIS) v2 1 cross-matrixed with Fed...
FedRAMP 2.0 Control-Implementation-Summary (CIS) v2 1 cross-matrixed with Fed...FedRAMP 2.0 Control-Implementation-Summary (CIS) v2 1 cross-matrixed with Fed...
FedRAMP 2.0 Control-Implementation-Summary (CIS) v2 1 cross-matrixed with Fed...
 
From ISO to Implementation A framework for ECM Implementation
From ISO to Implementation  A framework for ECM ImplementationFrom ISO to Implementation  A framework for ECM Implementation
From ISO to Implementation A framework for ECM Implementation
 
NISTs Cybersecurity Framework -- Comparison with Best Practice
NISTs Cybersecurity Framework -- Comparison with Best PracticeNISTs Cybersecurity Framework -- Comparison with Best Practice
NISTs Cybersecurity Framework -- Comparison with Best Practice
 
COBIT 5 IT Governance Model: an Introduction
COBIT 5 IT Governance Model: an IntroductionCOBIT 5 IT Governance Model: an Introduction
COBIT 5 IT Governance Model: an Introduction
 
ISO27001: Implementation & Certification Process Overview
ISO27001: Implementation & Certification Process OverviewISO27001: Implementation & Certification Process Overview
ISO27001: Implementation & Certification Process Overview
 
8 Access Control
8 Access Control8 Access Control
8 Access Control
 
Security architecture frameworks
Security architecture frameworksSecurity architecture frameworks
Security architecture frameworks
 

Similar to NIST IT Standards for Local Governments 2010

FFIEC and NIST: What You Need to Know About Two Prevalent New IT Security Com...
FFIEC and NIST: What You Need to Know About Two Prevalent New IT Security Com...FFIEC and NIST: What You Need to Know About Two Prevalent New IT Security Com...
FFIEC and NIST: What You Need to Know About Two Prevalent New IT Security Com...West Monroe Partners
 
Compliance Framework
Compliance FrameworkCompliance Framework
Compliance Frameworkbarnetdh
 
The Virtual Security Officer Platform
The Virtual Security Officer PlatformThe Virtual Security Officer Platform
The Virtual Security Officer PlatformShanmugavel Sankaran
 
Information Security Program & PCI Compliance Planning for your Business
Information Security Program & PCI Compliance Planning for your BusinessInformation Security Program & PCI Compliance Planning for your Business
Information Security Program & PCI Compliance Planning for your BusinessLaura Perry
 
Info Security & PCI(original)
Info Security & PCI(original)Info Security & PCI(original)
Info Security & PCI(original)NCTechSymposium
 
Business Continuity And Disaster Recovery Are Top IT Priorities For 2010 And ...
Business Continuity And Disaster Recovery Are Top IT Priorities For 2010 And ...Business Continuity And Disaster Recovery Are Top IT Priorities For 2010 And ...
Business Continuity And Disaster Recovery Are Top IT Priorities For 2010 And ...Citrix Online
 
Automatski - The Internet of Things - Security Standards
Automatski - The Internet of Things - Security StandardsAutomatski - The Internet of Things - Security Standards
Automatski - The Internet of Things - Security Standardsautomatskicorporation
 
This domain reviews the diverse areas of knowledge needed to develop and man...
This domain reviews the diverse areas of  knowledge needed to develop and man...This domain reviews the diverse areas of  knowledge needed to develop and man...
This domain reviews the diverse areas of knowledge needed to develop and man...bikheet
 
Security architecture rajagiri talk march 2011
Security architecture  rajagiri talk march 2011Security architecture  rajagiri talk march 2011
Security architecture rajagiri talk march 2011subramanian K
 
Information Governance Checklist and Privacy Impact Ass.docx
Information Governance Checklist and Privacy Impact  Ass.docxInformation Governance Checklist and Privacy Impact  Ass.docx
Information Governance Checklist and Privacy Impact Ass.docxcarliotwaycave
 
IT Governance and Compliance: Its Importance and the Best Practices to Follow...
IT Governance and Compliance: Its Importance and the Best Practices to Follow...IT Governance and Compliance: Its Importance and the Best Practices to Follow...
IT Governance and Compliance: Its Importance and the Best Practices to Follow...GrapesTech Solutions
 
Iso27001- Nashwan Mustafa
Iso27001- Nashwan MustafaIso27001- Nashwan Mustafa
Iso27001- Nashwan MustafaFahmi Albaheth
 
OEB Cyber Security Framework
OEB Cyber Security FrameworkOEB Cyber Security Framework
OEB Cyber Security FrameworkNorbi Hegedus
 
Protecting business interests with policies for it asset management it-tool...
Protecting business interests with policies for it asset management   it-tool...Protecting business interests with policies for it asset management   it-tool...
Protecting business interests with policies for it asset management it-tool...IT-Toolkits.org
 
Trackment
TrackmentTrackment
Trackmentmeaannn
 
General Data Protection Regulation (GDPR)
General Data Protection Regulation (GDPR) General Data Protection Regulation (GDPR)
General Data Protection Regulation (GDPR) Karina Matos
 
Cyber Critical Infrastructure Framework Panel
Cyber Critical Infrastructure Framework PanelCyber Critical Infrastructure Framework Panel
Cyber Critical Infrastructure Framework PanelPaul Di Gangi
 

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

FFIEC and NIST: What You Need to Know About Two Prevalent New IT Security Com...
FFIEC and NIST: What You Need to Know About Two Prevalent New IT Security Com...FFIEC and NIST: What You Need to Know About Two Prevalent New IT Security Com...
FFIEC and NIST: What You Need to Know About Two Prevalent New IT Security Com...
 
Compliance Framework
Compliance FrameworkCompliance Framework
Compliance Framework
 
The Virtual Security Officer Platform
The Virtual Security Officer PlatformThe Virtual Security Officer Platform
The Virtual Security Officer Platform
 
Information Security Program & PCI Compliance Planning for your Business
Information Security Program & PCI Compliance Planning for your BusinessInformation Security Program & PCI Compliance Planning for your Business
Information Security Program & PCI Compliance Planning for your Business
 
Compliance Awareness
Compliance AwarenessCompliance Awareness
Compliance Awareness
 
Info Security & PCI(original)
Info Security & PCI(original)Info Security & PCI(original)
Info Security & PCI(original)
 
Business Continuity And Disaster Recovery Are Top IT Priorities For 2010 And ...
Business Continuity And Disaster Recovery Are Top IT Priorities For 2010 And ...Business Continuity And Disaster Recovery Are Top IT Priorities For 2010 And ...
Business Continuity And Disaster Recovery Are Top IT Priorities For 2010 And ...
 
Automatski - The Internet of Things - Security Standards
Automatski - The Internet of Things - Security StandardsAutomatski - The Internet of Things - Security Standards
Automatski - The Internet of Things - Security Standards
 
This domain reviews the diverse areas of knowledge needed to develop and man...
This domain reviews the diverse areas of  knowledge needed to develop and man...This domain reviews the diverse areas of  knowledge needed to develop and man...
This domain reviews the diverse areas of knowledge needed to develop and man...
 
Security architecture rajagiri talk march 2011
Security architecture  rajagiri talk march 2011Security architecture  rajagiri talk march 2011
Security architecture rajagiri talk march 2011
 
Information Governance Checklist and Privacy Impact Ass.docx
Information Governance Checklist and Privacy Impact  Ass.docxInformation Governance Checklist and Privacy Impact  Ass.docx
Information Governance Checklist and Privacy Impact Ass.docx
 
IT Governance and Compliance: Its Importance and the Best Practices to Follow...
IT Governance and Compliance: Its Importance and the Best Practices to Follow...IT Governance and Compliance: Its Importance and the Best Practices to Follow...
IT Governance and Compliance: Its Importance and the Best Practices to Follow...
 
Dss investor presentation
Dss investor presentationDss investor presentation
Dss investor presentation
 
Iso27001- Nashwan Mustafa
Iso27001- Nashwan MustafaIso27001- Nashwan Mustafa
Iso27001- Nashwan Mustafa
 
OEB Cyber Security Framework
OEB Cyber Security FrameworkOEB Cyber Security Framework
OEB Cyber Security Framework
 
Protecting business interests with policies for it asset management it-tool...
Protecting business interests with policies for it asset management   it-tool...Protecting business interests with policies for it asset management   it-tool...
Protecting business interests with policies for it asset management it-tool...
 
Cobit 41 framework
Cobit 41 frameworkCobit 41 framework
Cobit 41 framework
 
Trackment
TrackmentTrackment
Trackment
 
General Data Protection Regulation (GDPR)
General Data Protection Regulation (GDPR) General Data Protection Regulation (GDPR)
General Data Protection Regulation (GDPR)
 
Cyber Critical Infrastructure Framework Panel
Cyber Critical Infrastructure Framework PanelCyber Critical Infrastructure Framework Panel
Cyber Critical Infrastructure Framework Panel
 

More from Donald E. Hester

Cybersecurity for Local Gov for SAMFOG
Cybersecurity for Local Gov for SAMFOGCybersecurity for Local Gov for SAMFOG
Cybersecurity for Local Gov for SAMFOGDonald E. Hester
 
2017 IT Control Environment for Local Gov
2017 IT Control Environment for Local Gov2017 IT Control Environment for Local Gov
2017 IT Control Environment for Local GovDonald E. Hester
 
What you Need To Know About Ransomware
What you Need To Know About RansomwareWhat you Need To Know About Ransomware
What you Need To Know About RansomwareDonald E. Hester
 
CNT 54 Administering Windows Client
CNT 54 Administering Windows ClientCNT 54 Administering Windows Client
CNT 54 Administering Windows ClientDonald E. Hester
 
2016 Maze Live Fraud Environment
2016 Maze Live Fraud Environment2016 Maze Live Fraud Environment
2016 Maze Live Fraud EnvironmentDonald E. Hester
 
2016 Maze Live Changes in Grant Management and How to Prepare for the Single ...
2016 Maze Live Changes in Grant Management and How to Prepare for the Single ...2016 Maze Live Changes in Grant Management and How to Prepare for the Single ...
2016 Maze Live Changes in Grant Management and How to Prepare for the Single ...Donald E. Hester
 
2016 Maze Live Cyber-security for Local Governments
2016 Maze Live Cyber-security for Local Governments2016 Maze Live Cyber-security for Local Governments
2016 Maze Live Cyber-security for Local GovernmentsDonald E. Hester
 
GASB 68 and 71 Planning for the Second Year
GASB 68 and 71 Planning for the Second YearGASB 68 and 71 Planning for the Second Year
GASB 68 and 71 Planning for the Second YearDonald E. Hester
 
Implementing GASB 72: Fair Value Measurement and Application
Implementing GASB 72: Fair Value Measurement and ApplicationImplementing GASB 72: Fair Value Measurement and Application
Implementing GASB 72: Fair Value Measurement and ApplicationDonald E. Hester
 
2016 Maze Live 1 GASB update
2016 Maze Live 1 GASB update2016 Maze Live 1 GASB update
2016 Maze Live 1 GASB updateDonald E. Hester
 
Cyber Security for Local Gov SAMFOG
Cyber Security for Local Gov SAMFOGCyber Security for Local Gov SAMFOG
Cyber Security for Local Gov SAMFOGDonald E. Hester
 
Annual Maze Live Event 2016 – GASB Updates & Best Practices
Annual Maze Live Event 2016 – GASB Updates & Best Practices Annual Maze Live Event 2016 – GASB Updates & Best Practices
Annual Maze Live Event 2016 – GASB Updates & Best Practices Donald E. Hester
 
Payment Card Cashiering for Local Governments 2016
Payment Card Cashiering for Local Governments 2016Payment Card Cashiering for Local Governments 2016
Payment Card Cashiering for Local Governments 2016Donald E. Hester
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 10: Authorize
Understanding the Risk Management Framework & (ISC)2 CAP Module 10: Authorize Understanding the Risk Management Framework & (ISC)2 CAP Module 10: Authorize
Understanding the Risk Management Framework & (ISC)2 CAP Module 10: Authorize Donald E. Hester
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 15: Incident ...
Understanding the Risk Management Framework & (ISC)2 CAP Module 15: Incident ...Understanding the Risk Management Framework & (ISC)2 CAP Module 15: Incident ...
Understanding the Risk Management Framework & (ISC)2 CAP Module 15: Incident ...Donald E. Hester
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 14: Security ...
Understanding the Risk Management Framework & (ISC)2 CAP Module 14: Security ...Understanding the Risk Management Framework & (ISC)2 CAP Module 14: Security ...
Understanding the Risk Management Framework & (ISC)2 CAP Module 14: Security ...Donald E. Hester
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 13: Contingen...
Understanding the Risk Management Framework & (ISC)2 CAP Module 13: Contingen...Understanding the Risk Management Framework & (ISC)2 CAP Module 13: Contingen...
Understanding the Risk Management Framework & (ISC)2 CAP Module 13: Contingen...Donald E. Hester
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 11: Monitor
Understanding the Risk Management Framework & (ISC)2 CAP Module 11: MonitorUnderstanding the Risk Management Framework & (ISC)2 CAP Module 11: Monitor
Understanding the Risk Management Framework & (ISC)2 CAP Module 11: MonitorDonald E. Hester
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 12: Cloud Com...
Understanding the Risk Management Framework & (ISC)2 CAP Module 12: Cloud Com...Understanding the Risk Management Framework & (ISC)2 CAP Module 12: Cloud Com...
Understanding the Risk Management Framework & (ISC)2 CAP Module 12: Cloud Com...Donald E. Hester
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 9: Assess Con...
Understanding the Risk Management Framework & (ISC)2 CAP Module 9: Assess Con...Understanding the Risk Management Framework & (ISC)2 CAP Module 9: Assess Con...
Understanding the Risk Management Framework & (ISC)2 CAP Module 9: Assess Con...Donald E. Hester
 

More from Donald E. Hester (20)

Cybersecurity for Local Gov for SAMFOG
Cybersecurity for Local Gov for SAMFOGCybersecurity for Local Gov for SAMFOG
Cybersecurity for Local Gov for SAMFOG
 
2017 IT Control Environment for Local Gov
2017 IT Control Environment for Local Gov2017 IT Control Environment for Local Gov
2017 IT Control Environment for Local Gov
 
What you Need To Know About Ransomware
What you Need To Know About RansomwareWhat you Need To Know About Ransomware
What you Need To Know About Ransomware
 
CNT 54 Administering Windows Client
CNT 54 Administering Windows ClientCNT 54 Administering Windows Client
CNT 54 Administering Windows Client
 
2016 Maze Live Fraud Environment
2016 Maze Live Fraud Environment2016 Maze Live Fraud Environment
2016 Maze Live Fraud Environment
 
2016 Maze Live Changes in Grant Management and How to Prepare for the Single ...
2016 Maze Live Changes in Grant Management and How to Prepare for the Single ...2016 Maze Live Changes in Grant Management and How to Prepare for the Single ...
2016 Maze Live Changes in Grant Management and How to Prepare for the Single ...
 
2016 Maze Live Cyber-security for Local Governments
2016 Maze Live Cyber-security for Local Governments2016 Maze Live Cyber-security for Local Governments
2016 Maze Live Cyber-security for Local Governments
 
GASB 68 and 71 Planning for the Second Year
GASB 68 and 71 Planning for the Second YearGASB 68 and 71 Planning for the Second Year
GASB 68 and 71 Planning for the Second Year
 
Implementing GASB 72: Fair Value Measurement and Application
Implementing GASB 72: Fair Value Measurement and ApplicationImplementing GASB 72: Fair Value Measurement and Application
Implementing GASB 72: Fair Value Measurement and Application
 
2016 Maze Live 1 GASB update
2016 Maze Live 1 GASB update2016 Maze Live 1 GASB update
2016 Maze Live 1 GASB update
 
Cyber Security for Local Gov SAMFOG
Cyber Security for Local Gov SAMFOGCyber Security for Local Gov SAMFOG
Cyber Security for Local Gov SAMFOG
 
Annual Maze Live Event 2016 – GASB Updates & Best Practices
Annual Maze Live Event 2016 – GASB Updates & Best Practices Annual Maze Live Event 2016 – GASB Updates & Best Practices
Annual Maze Live Event 2016 – GASB Updates & Best Practices
 
Payment Card Cashiering for Local Governments 2016
Payment Card Cashiering for Local Governments 2016Payment Card Cashiering for Local Governments 2016
Payment Card Cashiering for Local Governments 2016
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 10: Authorize
Understanding the Risk Management Framework & (ISC)2 CAP Module 10: Authorize Understanding the Risk Management Framework & (ISC)2 CAP Module 10: Authorize
Understanding the Risk Management Framework & (ISC)2 CAP Module 10: Authorize
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 15: Incident ...
Understanding the Risk Management Framework & (ISC)2 CAP Module 15: Incident ...Understanding the Risk Management Framework & (ISC)2 CAP Module 15: Incident ...
Understanding the Risk Management Framework & (ISC)2 CAP Module 15: Incident ...
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 14: Security ...
Understanding the Risk Management Framework & (ISC)2 CAP Module 14: Security ...Understanding the Risk Management Framework & (ISC)2 CAP Module 14: Security ...
Understanding the Risk Management Framework & (ISC)2 CAP Module 14: Security ...
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 13: Contingen...
Understanding the Risk Management Framework & (ISC)2 CAP Module 13: Contingen...Understanding the Risk Management Framework & (ISC)2 CAP Module 13: Contingen...
Understanding the Risk Management Framework & (ISC)2 CAP Module 13: Contingen...
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 11: Monitor
Understanding the Risk Management Framework & (ISC)2 CAP Module 11: MonitorUnderstanding the Risk Management Framework & (ISC)2 CAP Module 11: Monitor
Understanding the Risk Management Framework & (ISC)2 CAP Module 11: Monitor
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 12: Cloud Com...
Understanding the Risk Management Framework & (ISC)2 CAP Module 12: Cloud Com...Understanding the Risk Management Framework & (ISC)2 CAP Module 12: Cloud Com...
Understanding the Risk Management Framework & (ISC)2 CAP Module 12: Cloud Com...
 
Understanding the Risk Management Framework & (ISC)2 CAP Module 9: Assess Con...
Understanding the Risk Management Framework & (ISC)2 CAP Module 9: Assess Con...Understanding the Risk Management Framework & (ISC)2 CAP Module 9: Assess Con...
Understanding the Risk Management Framework & (ISC)2 CAP Module 9: Assess Con...
 

Recently uploaded

"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks..."LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...Fwdays
 
My Hashitalk Indonesia April 2024 Presentation
My Hashitalk Indonesia April 2024 PresentationMy Hashitalk Indonesia April 2024 Presentation
My Hashitalk Indonesia April 2024 PresentationRidwan Fadjar
 
My INSURER PTE LTD - Insurtech Innovation Award 2024
My INSURER PTE LTD - Insurtech Innovation Award 2024My INSURER PTE LTD - Insurtech Innovation Award 2024
My INSURER PTE LTD - Insurtech Innovation Award 2024The Digital Insurer
 
Dev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio WebDev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio WebUiPathCommunity
 
Bluetooth Controlled Car with Arduino.pdf
Bluetooth Controlled Car with Arduino.pdfBluetooth Controlled Car with Arduino.pdf
Bluetooth Controlled Car with Arduino.pdfngoud9212
 
costume and set research powerpoint presentation
costume and set research powerpoint presentationcostume and set research powerpoint presentation
costume and set research powerpoint presentationphoebematthew05
 
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
"Federated learning: out of reach no matter how close",Oleksandr LapshynFwdays
 
Build your next Gen AI Breakthrough - April 2024
Build your next Gen AI Breakthrough - April 2024Build your next Gen AI Breakthrough - April 2024
Build your next Gen AI Breakthrough - April 2024Neo4j
 
AI as an Interface for Commercial Buildings
AI as an Interface for Commercial BuildingsAI as an Interface for Commercial Buildings
AI as an Interface for Commercial BuildingsMemoori
 
Pigging Solutions Piggable Sweeping Elbows
Pigging Solutions Piggable Sweeping ElbowsPigging Solutions Piggable Sweeping Elbows
Pigging Solutions Piggable Sweeping ElbowsPigging Solutions
 
Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry InnovationBeyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry InnovationSafe Software
 
Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?Mattias Andersson
 
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024Lorenzo Miniero
 
"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii SoldatenkoFwdays
 
APIForce Zurich 5 April Automation LPDG
APIForce Zurich 5 April  Automation LPDGAPIForce Zurich 5 April  Automation LPDG
APIForce Zurich 5 April Automation LPDGMarianaLemus7
 
Bun (KitWorks Team Study 노별마루 발표 2024.4.22)
Bun (KitWorks Team Study 노별마루 발표 2024.4.22)Bun (KitWorks Team Study 노별마루 발표 2024.4.22)
Bun (KitWorks Team Study 노별마루 발표 2024.4.22)Wonjun Hwang
 
Science&tech:THE INFORMATION AGE STS.pdf
Science&tech:THE INFORMATION AGE STS.pdfScience&tech:THE INFORMATION AGE STS.pdf
Science&tech:THE INFORMATION AGE STS.pdfjimielynbastida
 

Recently uploaded (20)

"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks..."LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
 
My Hashitalk Indonesia April 2024 Presentation
My Hashitalk Indonesia April 2024 PresentationMy Hashitalk Indonesia April 2024 Presentation
My Hashitalk Indonesia April 2024 Presentation
 
My INSURER PTE LTD - Insurtech Innovation Award 2024
My INSURER PTE LTD - Insurtech Innovation Award 2024My INSURER PTE LTD - Insurtech Innovation Award 2024
My INSURER PTE LTD - Insurtech Innovation Award 2024
 
Dev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio WebDev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio Web
 
Bluetooth Controlled Car with Arduino.pdf
Bluetooth Controlled Car with Arduino.pdfBluetooth Controlled Car with Arduino.pdf
Bluetooth Controlled Car with Arduino.pdf
 
costume and set research powerpoint presentation
costume and set research powerpoint presentationcostume and set research powerpoint presentation
costume and set research powerpoint presentation
 
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
 
DMCC Future of Trade Web3 - Special Edition
DMCC Future of Trade Web3 - Special EditionDMCC Future of Trade Web3 - Special Edition
DMCC Future of Trade Web3 - Special Edition
 
E-Vehicle_Hacking_by_Parul Sharma_null_owasp.pptx
E-Vehicle_Hacking_by_Parul Sharma_null_owasp.pptxE-Vehicle_Hacking_by_Parul Sharma_null_owasp.pptx
E-Vehicle_Hacking_by_Parul Sharma_null_owasp.pptx
 
Build your next Gen AI Breakthrough - April 2024
Build your next Gen AI Breakthrough - April 2024Build your next Gen AI Breakthrough - April 2024
Build your next Gen AI Breakthrough - April 2024
 
AI as an Interface for Commercial Buildings
AI as an Interface for Commercial BuildingsAI as an Interface for Commercial Buildings
AI as an Interface for Commercial Buildings
 
Pigging Solutions Piggable Sweeping Elbows
Pigging Solutions Piggable Sweeping ElbowsPigging Solutions Piggable Sweeping Elbows
Pigging Solutions Piggable Sweeping Elbows
 
Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry InnovationBeyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
 
Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?
 
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024
 
"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko
 
APIForce Zurich 5 April Automation LPDG
APIForce Zurich 5 April  Automation LPDGAPIForce Zurich 5 April  Automation LPDG
APIForce Zurich 5 April Automation LPDG
 
Vulnerability_Management_GRC_by Sohang Sengupta.pptx
Vulnerability_Management_GRC_by Sohang Sengupta.pptxVulnerability_Management_GRC_by Sohang Sengupta.pptx
Vulnerability_Management_GRC_by Sohang Sengupta.pptx
 
Bun (KitWorks Team Study 노별마루 발표 2024.4.22)
Bun (KitWorks Team Study 노별마루 발표 2024.4.22)Bun (KitWorks Team Study 노별마루 발표 2024.4.22)
Bun (KitWorks Team Study 노별마루 발표 2024.4.22)
 
Science&tech:THE INFORMATION AGE STS.pdf
Science&tech:THE INFORMATION AGE STS.pdfScience&tech:THE INFORMATION AGE STS.pdf
Science&tech:THE INFORMATION AGE STS.pdf
 

NIST IT Standards for Local Governments 2010

  • 1. Implementing NIST for Local Governments Rev 1 (JUN 2010)© 2010 Maze & Associates1
  • 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)3 © 2010 Maze & Associates
  • 4. Introduction Rev 4 (Jan 2010)© 2010 Maze & Associates4
  • 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
  • 22. 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)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
  • 62. Facility Manager  Responsible for physical security  Responsible for environmental controls Rev 4 (Jan 2010)62 © 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
  • 65. Role Relationships IG CA CISO ISSO CIO SA BUM EU Independence SOD SOD IOSO AA Program System Rev 4 (Jan 2010)65 © 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)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
  • 76. Certifications CISSP CISM CISSP ISSMP CAP CISA GSNA SSCP Security+ CISSP ISSEP/ ISSAP CSSLP Management / Risk Audit Software Dev Network / Communications Rev 4 (Jan 2010)76 © 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
  • 80. 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 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
  • 95. NISTSP800-100 Rev 4 (Jan 2010)95 © 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
  • 142. Rev 4 (Jan 2010)142 © 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
  • 150. Inventory Is Central Rev 4 (Jan 2010)150 © 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
  • 152. 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)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
  • 163. NIST SP 800-60 DataType Data Description Data Sensitivity Rev 4 (Jan 2010)163 © 2010 Maze & Associates
  • 164. Data Explanation (NIST SP 800-60) Rev 4 (Jan 2010)164 © 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
  • 169. 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)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
  • 183. Rev 4 (Jan 2010)183 © 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
  • 198. 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)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
  • 201. Systems Interconnection NIST SP 800-100 Rev 4 (Jan 2010)201 © 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
  • 205. Sample MOU/MOA NIST SP 800-100 Chapter 6 Rev 4 (Jan 2010)205 © 2010 Maze & Associates
  • 206. Sample ISA NIST SP 800-100 Chapter 6 Rev 4 (Jan 2010)206 © 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
  • 212. 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)213 © 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
  • 216. NIST 800-60 Rev 4 (Jan 2010)216 © 2010 Maze & Associates
  • 217. NIST SP 800-60 DataType Data Description Data Sensitivity Rev 4 (Jan 2010)217 © 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
  • 219. NIST SP 800-60 Rev 4 (Jan 2010)219 © 2010 Maze & Associates
  • 220. Security Control Selection Process NIST SP 800-53A Rev 2 Rev 4 (Jan 2010)220 © 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
  • 232. Threat identification Input • History of attacks • Intelligence • Media • Advisories Output • Threat statement Threat Identification Rev 4 (Jan 2010)232 © 2010 Maze & Associates
  • 233. Example Threats NIST SP 800-30 Rev 4 (Jan 2010)233 © 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
  • 235. Control Analysis Input • Current controls • Planned controls Output • List of current and planned controls Control Analysis Rev 4 (Jan 2010)235 © 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)236 © 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
  • 241. Residual Risk NIST SP 800-30 Rev 4 (Jan 2010)241 © 2010 Maze & Associates
  • 242. Accepted or Unacceptable Risk NIST SP 800-100 Rev 4 (Jan 2010)242 © 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
  • 244. NISTSP800-37Rev1Draft Rev 4 (Jan 2010)244 © 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