Embed Size (px)
Citation preview
SBA SOP 90 47 3
INFORMATION SYSTEM SECURITY PROGRAM
Office of the Chief Information Officer
Effective Date: August 28, 2012
SOP 90 47 3
U.S. SMALL BUSINESS ADMINISTRATION
STANDARD OPERATING PROCEDURE
SOP Information System Security Program 90 47 3
1. Purpose: To serve as a foundational document for the U.S. Small Business Administration’s
Information System Security Program by establishing policies and procedures for
ensuring an adequate level of information security for all unclassified information
to include sensitive data and Personally Identifiable Information (PII) processed,
transmitted, stored or disseminated on the Agency’s information systems.
2. Personnel Concerned: All SBA employees, Contractors and other affiliates
3. Originator: Office of the Chief Information Officer (OCIO)
4. Distribution: Standard
Effective Date: AUTHORIZED BY: August 28, 2012
Eric K. Won
Chief Information Officer PAGE: 1
SBA Form 989 (5-90) Ref: SOP 00 23
SOP 90 47 3
Effective Date: August 28, 2012 2
Table of Contents
Table of Contents ............................................................................................................................ 2
Replacement Highlights .................................................................................................................. 8
Authority/References ...................................................................................................................... 8
Scope ............................................................................................................................................. 10
Implementation ............................................................................................................................. 11
Program Overview ........................................................................................................................ 11
Policy Standards............................................................................................................................ 13
Roles and Responsibilities ............................................................................................................ 14
CHAPTER 1 – Access Control ..................................................................................................... 21
1. Access Control (AC-1) - Common ................................................................................................................ 21
2. Account Management (AC-2) - Hybrid ........................................................................................................ 21
3. Access Enforcement (AC-3) - Hybrid ........................................................................................................... 22
4. Information Flow Enforcement (AC-4) - Hybrid .......................................................................................... 22
5. Separation of Duties (AC-5) - Hybrid ........................................................................................................... 22
6. Least Privilege (AC-6) - Common ................................................................................................................ 23
7. Unsuccessful Login Attempts (AC-7) - Common ......................................................................................... 24
8. System Use Notification (AC-8) - Common ................................................................................................. 24
10. Session Lock (AC-11) - Common ................................................................................................................. 25
11. Permitted Actions without Identification and Authentication (AC-14) - Common ....................................... 25
12. Remote Access (AC-17) - Common .............................................................................................................. 26
14. Access Control for Mobile Devices (AC-19) – Common ............................................................................. 29
15. Use of External Information Systems (AC-20) - Common ........................................................................... 32
CHAPTER 2 – Awareness and Training ...................................................................................... 33
1. Awareness Training Policies and Procedures (AT-1) - Common ................................................................. 33
2. Security Awareness (AT-2) - Common ......................................................................................................... 33
3. Security Training (AT-3) - Common ............................................................................................................ 33
4. Security Training Records (AT-4) – Common .............................................................................................. 34
a. The names of individuals, including contractors, required to take training;.................................................. 34
CHAPTER 3 – Audit and Accountability ..................................................................................... 35
1. Audit and Accountability Policy and Procedures (AU-1) - Common ........................................................... 35
2. Auditable Events (AU-2) - Hybrid ................................................................................................................ 36
3. Content of Audit Records (AU-3) - Hybrid................................................................................................... 37
4. Audit Storage Capacity (AU-4) - Hybrid ...................................................................................................... 37
5. Response to Audit Processing Failures (AU-5) - Hybrid .............................................................................. 37
6. Audit Review, Analysis and Reporting (AU-6) - Hybrid .............................................................................. 38
7. Audit Reduction and Report Generation (AU-7) - Hybrid ............................................................................ 38
SOP 90 47 3
Effective Date: August 28, 2012 3
8. Time Stamps (AU-8) - Hybrid ...................................................................................................................... 39
9. Protection of Audit Information (AU-9) - Hybrid ......................................................................................... 39
10. Non-Repudiation (AU-10) - Hybrid .............................................................................................................. 39
11. Audit Record Retention (AU-11) - Hybrid.................................................................................................... 39
12. Audit Generation (AU-12) – Hybrid ............................................................................................................. 40
CHAPTER 4 – Assessment and Authorization ............................................................................ 41
1. Security Assessment and Authorization Policies and Procedures (CA-1) - Common................................... 41
2. Security Assessments (CA-2) - Hybrid ......................................................................................................... 41
3. Information System Connections (CA-3) - Common .................................................................................... 42
4. Plan of Action and Milestones (POA&M) (CA-5) - Common ...................................................................... 42
5. Security Authorization (CA-6) - Common .................................................................................................... 42
6. Continuous Monitoring (CA-7) - Hybrid ...................................................................................................... 42
CHAPTER 5 – Configuration Management ................................................................................. 44
1. Configuration Management Policies and Procedures (CM-1) - Common .......................................................... 44
2. Baseline Configurations (CM-2) - Hybrid .......................................................................................................... 45
3. Configuration Change Control (CM-3) – Common .......................................................................................... 46
4. Security Impact Analysis (CM-4) - Hybrid ....................................................................................................... 47
5. Access Restrictions for Change (CM-5) - Common ...................................................................................... 48
6. Configuration Settings (CM-6) - Common ................................................................................................... 48
7. Least Functionality (CM-7) - Hybrid ............................................................................................................ 48
8. Information System Component Inventory (CM-8) - Hybrid ....................................................................... 48
CHAPTER 6 – Contingency Planning .......................................................................................... 50
1. Contingency Planning Policies and Procedures (CP-1) - Common............................................................... 50
2. Contingency Plan (CP-2) - Hybrid ................................................................................................................ 51
3. Contingency Training (CP-3) - Common ...................................................................................................... 51
4. Contingency Plan Testing and Exercises (CP-4) - Hybrid ............................................................................ 52
5. Alternate Storage Site (CP-6) - Hybrid ......................................................................................................... 52
6. Alternate Processing Site (CP-7) - Hybrid .................................................................................................... 53
7. Telecommunication Services (CP-8) – Common .......................................................................................... 53
8. Information System Backup (CP-9) - Hybrid ................................................................................................ 53
9. Information System Recovery and Reconstitution (CP-10) - Common ........................................................ 54
CHAPTER 7 – Identification and Authentication ........................................................................ 56
1. Identification and Authentication Policy and Procedures (IA-1) - Common ................................................ 56
2. I&A (Organizational and Non-Organizational Users) (IA-2/IA-8) - Hybrid ................................................ 56
3. Device Identification and Authentication (IA-3) - Common......................................................................... 57
4. Identifier Management (IA-4) - Common ..................................................................................................... 57
5. Authenticator Management (IA-5) - Hybrid ................................................................................................. 58
SOP 90 47 3
Effective Date: August 28, 2012 4
6. Authenticator Feedback (IA-6) - Common ................................................................................................... 58
7. Cryptographic Module Authentication (IA-7) - Common ............................................................................. 58
CHAPTER 8 – Incident Response ................................................................................................ 60
1. Incident Response Policies and Procedures (IR-1) - Common ................................................. 60
2. Incident Response Training (IR-2) - Common .............................................................................................. 61
3. Incident Response Testing and Exercises (IR-3) - Hybrid ............................................................................ 61
4. Incident Handling (IR-4) - Common ............................................................................................................. 62
5. Incident Monitoring (IR-5) - Common .......................................................................................................... 62
6. Incident Reporting (IR-6) – Common ........................................................................................................... 62
7. Incident Response Assistance (IR-7) - Common........................................................................................... 63
8. Incident Response Plan (IR-8) – Common .................................................................................................... 63
CHAPTER 9 - Maintenance ......................................................................................................... 64
1. System Maintenance Policies and Procedures (MA-1) - Common ............................................................... 64
2. Controlled Maintenance (MA-2) - Hybrid .................................................................................................... 64
3. Maintenance Tools (MA-3) - Hybrid ............................................................................................................ 64
4. Non-Local Maintenance (MA-4) - Hybrid .................................................................................................... 64
5. Maintenance Personnel (MA-5) - Hybrid ...................................................................................................... 65
6. Timely Maintenance (MA-6) - Hybrid .......................................................................................................... 65
CHAPTER 10 – Media Protection ................................................................................................ 66
1. Media Protection Policy and Procedures (MP-1) - common ......................................................................... 66
2. Media Access (MP-2) - Hybrid ..................................................................................................................... 66
3. Media Marking (MP-3) - Common ............................................................................................................... 66
4. Media Storage (MP-4) - Common ................................................................................................................. 67
5. Media Transport (MP-5) - Common ............................................................................................................. 67
6. Media Sanitization and Disposal (MP-6) - Common .................................................................................... 67
CHAPTER 11 – Physical and Environmental Protection ............................................................. 70
1. Physical and Environmental Policies and Procedures (PE-1) - Common ..................................................... 70
2. Physical Access Authorizations (PE-2) - Common ....................................................................................... 70
3. Physical Access Control (PE-3) - Common .................................................................................................. 71
4. Access Control for Transmission Medium (PE-4) - Common ...................................................................... 71
5. Access Control for Display Medium (PE-5) - Common ............................................................................... 72
6. Monitoring Physical Access (PE-6) - Common ............................................................................................ 72
7. Visitor Control (PE-7) - Common ................................................................................................................. 72
8. Access Records (PE-8) - Common ................................................................................................................ 72
9. Power Equipment and Power Cabling (PE-9) - Common ............................................................................. 73
10. Emergency Shutoff (PE-10) - Common ........................................................................................................ 74
11. Emergency Power (PE-11) - Common .......................................................................................................... 74
SOP 90 47 3
Effective Date: August 28, 2012 5
12. Emergency Lighting (PE-12) - Common ...................................................................................................... 74
13. Fire Protection (PE-13) - Common ............................................................................................................... 74
14. Temperature and Humidity Controls (PE-14) - Common ............................................................................. 75
15. Water Damage Protection (PE-15) - Common .............................................................................................. 76
16. Delivery and Removal (PE-16) - Common ................................................................................................... 76
17. Alternate Work Site (PE-17) - Hybrid ........................................................................................................... 76
18. Location of Information System Components (PE-18) - Common ............................................................... 76
CHAPTER 12 - Planning .............................................................................................................. 77
1. Security Planning Policy and Procedures (PL-1) - Common ........................................................................ 77
2. System Security Plan (SSP) (PL-2) - Common ............................................................................................. 77
3. Rules of Behavior (PL-4) – Common ........................................................................................................... 77
4. Privacy Impact Assessment (PL-5) - Common ............................................................................................. 78
5. Security-Related Activity Planning (PL-6) - Common ................................................................................. 78
CHAPTER 13 – Personnel Security ............................................................................................. 79
1. Personnel Security Policy and Procedures (PS-1) - Common ....................................................................... 79
2. Position Categorization (PS-2) - Common .................................................................................................... 79
3. Personnel Screening (PS-3) - Common ......................................................................................................... 79
4. Personnel Termination (PS-4) - Common ..................................................................................................... 80
5. Personnel Transfer (PS-5) - Common ........................................................................................................... 80
6. Access Agreements (PS-6) - Common .......................................................................................................... 80
7. Third-Party Personnel Security (PS-7) - Common ........................................................................................ 80
8. Personnel Sanctions (PS-8) - Common ......................................................................................................... 81
CHAPTER 14 – Risk Assessment ................................................................................................ 82
1. Risk Assessment Policy and Procedures (RA-1) - Common ......................................................................... 82
2. Security Categorization (RA-2) - Common ................................................................................................... 82
3. Risk Assessment (RA-3)- Common .............................................................................................................. 82
4. Vulnerability Scanning (RA-5) - Hybrid ....................................................................................................... 82
CHAPTER 15 – System and Services Acquisition....................................................................... 84
1. System and Services Acquisition Policy and Procedures (SA-1) - Common ............................................... 84
2. Allocation of Resources (SA-2) - Common .................................................................................................. 84
3. Life Cycle Support (SA-3) - Common .......................................................................................................... 84
4. Acquisitions (SA-4) - Common .................................................................................................................... 84
5. Information System Documentation (SA-5) - Common ............................................................................... 85
6. Software Usage Restrictions (SA-6) - Common ........................................................................................... 85
7. User-Installed Software (SA-7) - Common ................................................................................................... 86
8. Security Engineering Principles (SA-8) - Common ...................................................................................... 86
9. External Information System Services (SA-9) - Common ............................................................................ 87
SOP 90 47 3
Effective Date: August 28, 2012 6
10. Developer Configuration Management (SA-10) - Common ......................................................................... 87
11. Developer Security Testing (SA-11) - Common ........................................................................................... 88
12. Supply Chain Protection (SA-12) .................................................................................................................. 89
13. Trust Worthiness (SA-13) ............................................................................................................................. 89
CHAPTER 16 – System and Communications Protection ........................................................... 90
1. System and Communications Protection Policy and Procedures (SC-1) - Common .................................... 90
2. Application Partitioning (SC-2) - Common .................................................................................................. 90
3. Security Function Isolation (SC-3) - Common .............................................................................................. 91
4. Information in Shared Resources (SC-4) - Hybrid ........................................................................................ 91
5. Denial of Service Protection (SC-5) - Common ............................................................................................ 91
6. Boundary Protection (SC-7) - Common ........................................................................................................ 93
7. Transmission Integrity (SC-8) - Common ..................................................................................................... 96
8. Transmission Confidentiality (SC-9) - Common .......................................................................................... 96
9. Network Disconnect (SC-10) - Common ...................................................................................................... 97
10. Cryptographic Key Establishment and Management (SC-12) - Common .................................................... 97
11. Use of Cryptography (SC-13) - Hybrid ......................................................................................................... 97
12. Public Access Protections (SC-14) - Common .............................................................................................. 98
13. Collaborative Computing (SC-15) - Common .............................................................................................. 99
14. Public Key Infrastructure Certificates (SC-17) - Common ........................................................................... 99
15. Mobile Code (SC-18) - Common .................................................................................................................. 99
16. Voice Over Internet Protocol (SC-19) - Common ....................................................................................... 100
17. Secure Name /Address Resolution Service (Authoritative Source) (SC-20) - Common ............................. 101
18. Secure Name /Address Resolution Service (Recursive or Caching Resolver) (SC-21) - Common ............ 102
19. Architecture/Provisioning for Name/Address Resolution Service (SC-22) - Common .............................. 102
20. Session Authenticity (SC-23) - Common .................................................................................................... 103
21. Fail in Known State (SC-24) ....................................................................................................................... 104
22. Protection of Information at Rest (SC-28) .................................................................................................. 104
23. Information System Partitioning (SC-32).................................................................................................... 104
CHAPTER 17 – System and Information Integrity .................................................................... 105
1. System and Information Integrity Policy and Procedures (SI-1) - Common ............................................... 105
2. Flaw Remediation (SI-2) - Hybrid .............................................................................................................. 105
3. Malicious Code Protection (SI-3) - Common .............................................................................................. 106
4. Information System Monitoring Tools and Techniques (SI-4) - Hybrid .................................................... 106
5. Security Alerts and Advisories (SI-5) - Common ....................................................................................... 107
6. Security Functionality Verification (SI-6) - Common ................................................................................. 107
7. Software and Information Integrity (SI-7) - Common ............................................................................... 107
8. Spam Protection (SI-8) - Common .............................................................................................................. 108
SOP 90 47 3
Effective Date: August 28, 2012 7
9. Information Input Restrictions (SI-9) - Hybrid ........................................................................................... 108
10. Information Accuracy, Completeness, Validity, and Authenticity (SI-10) - Hybrid ................................... 108
11. Error Handling (SI-11) - Hybrid.................................................................................................................. 108
12. Information Output Handling and Retention (SI-12) - Hybrid .................................................................... 109
Appendix A – Media Sanitation ................................................................................................. 110
Appendix B – Life Cycle Principles ........................................................................................... 113
Appendix C – Glossary of Terms ............................................................................................... 115
Appendix D – Applicable NIST References ............................................................................... 123
Appendix E – Glossary of Acronyms ......................................................................................... 130
Appendix F – Password Management Guidance ........................................................................ 135
Appendix G – Security Measures for SBA’s Open Storage Area and Homeland Secure Data
Network (HSDN) ........................................................................................................................ 136
Appendix H – Contract Security Requirements.......................................................................... 144
Appendix I – Rules of Behavior ................................................................................................. 153
Appendix J – SBA’s POA&M Process ....................................................................................... 159
Appendix K – Security Assessment and Authorization Process ................................................ 171
SOP 90 47 3
Effective Date: August 28, 2012 8
General Overview of the Information Systems Security Program
This standard operating procedure (SOP) serves as a foundational document for the U.S. Small
Business Administration’s (SBA), Information System Security Program (ISSP). SBA’s
Information Systems Security Program (ISS) SOP establishes policies and procedures for
ensuring an adequate level of information security for all unclassified information to include
sensitive data and Personally Identifiable Information (PII) processed, transmitted, stored, or
disseminated on the Agency’s information systems. This document implements relevant Federal
laws, regulations, and policies; and provides a basis for the information security policies for the
Agency. The ISSP provides comprehensive, uniform information security policies and
procedures that must be followed by all SBA employees and contractors throughout the Agency.
As SBA’s ISSP evolves, this document is subject to review and revision. Reviews and updates
will take place annually, or when changes occur that necessitate the revision of this SOP. These
may include:
a. Release of new executive, legislative, technical, or agency guidance;
b. Identification of changes in governing policies; and
c. Changes in vulnerabilities, risks, and threats.
The responsibility for maintaining and updating this policy is delegated to the SBA’s Office of
the Chief Information Officer (OCIO), Office of Information Security (OIS).
Replacement Highlights
The SOP supersedes SBA SOP 90 47 2.
Authority/References
SBA’s ISSP requires all SBA Program areas to implement information system security
requirements within their respective organizations. SBA’s ISSP complies with the Federal
Information Security Management Act of 2002 (FISMA), presidential directives, executive
orders, Office of Management and Budget (OMB) directives, Federal Information Processing
Standards (FIPS), and SBA’s information security policies.
This SOP applies to all SBA systems to include offsite vendor managed information systems,
information systems managed internally and systems that may be interconnected to SBA
regardless of agency or managing entity. The National Institute of Technology and Standards
(NIST) develops and issues standards, guidelines, and other publications to assist Federal
agencies in implementing the Federal Information Security Management Act of 2002 and in
managing cost-effective programs to protect their information and information systems.
This SOP was developed in accordance with laws such as:
a. The Government Performance and Results Act (GPRA) of 1993 establish the foundation
for budget decision making to achieve strategic goals in order to meet agency mission
objectives.
b. The Paperwork Reduction Act (PRA) of 1995 requires agencies to perform their
information resource management activities in an efficient, effective, and economical
manner.
c. The Federal Financial Management Improvement Act (FFMIA) of 1996 requires
accountability of financial and program managers for financial results of actions taken,
control over the federal government's financial resources, and protection of federal assets.
SOP 90 47 3
Effective Date: August 28, 2012 9
d. The Federal Managers Financial Integrity Act (FMFIA) of 1982 requires ongoing
evaluations and reports from each executive on the adequacy of administrative control for
internal accounting systems.
e. The Clinger-Cohen Act of 1996 requires agencies to use a disciplined capital planning
and investment control (CPIC) process to acquire, use, maintain, and dispose of IT
resources, and establishes a role of chief information officer (CIO) within each Federal
agency.
f. E-Government Act of 2002 (Public Law 107-347) promotes better use of the Internet and
other IT resources to improve government services for citizens and internal government
operations, and provide opportunities for citizen participation in government.
g. Federal Information Security Management (FISMA) Act is the primary legislation
governing federal information security programs, building upon earlier legislation
through added emphasis on the management dimension of information security.
h. OMB Circular A-130, Management of Federal Information Resources, Appendix III,
Security of Federal Automated Information Resources, establishes a minimum set of
controls to be included in federal automated information security programs, assigns
federal agency responsibilities for the security of automated information, and links
agency automated information security programs and agency management control
systems.
i. Homeland Security Presidential Directive 12 (HSPD-12) specifies a "policy for a
common identification standard for all Federal employees and contractors." HSPD-12
intends to increase identification security and interoperability by standardizing the
process to issue a Federal employee or contractor an identification credential, and also by
specifying the electronic and physical properties of the credential itself.
j. The Privacy Act of 1974, Section 552a governs the collection, maintenance, use, and
dissemination of personally identifiable information about individuals that is maintained
in systems of records by federal agencies.
k. FIPS 200, Minimum Security Requirements for Federal Information and Information
Systems, specifies minimum security requirements for information and information
systems supporting the executive agencies of the federal government and a risk-based
process for selecting the security controls necessary to satisfy the minimum security
requirements. Note: FIPS are compulsory and binding for federal agencies. FISMA
requires that federal agencies comply with these standards, and therefore, agencies may
not waive their use.
l. FIPS 199, Standards for Security Categorization of Federal Information and Information
Systems, requires agencies to categorize their information systems as low-impact,
moderate-impact, or high-impact for the security objectives of confidentiality, integrity,
and availability. Note: FIPS are compulsory and binding for federal agencies. FISMA
requires that federal agencies comply with these standards, and therefore, agencies may
not waive their use.
m. NIST SP 800 37, Guide for Applying the Risk Management Framework to Federal
Information Systems: A Security Life Cycle Approach, provides a common Risk
Management Framework (RMF) that emphasizes building information security capabilities
SOP 90 47 3
Effective Date: August 28, 2012 10
into federal information systems; maintaining awareness of the security state of information
systems on an ongoing basis; and, providing essential information to senior leaders to facilitate
decisions regarding the acceptance of risk.
n. NIST SP 800-53, Recommended Security Controls for Federal Information Systems and
Organizations, provides guidelines for selecting and specifying security controls for
information systems. Note: FIPS 200 mandates the use of Special Publication 800-53,
as amended.
o. NIST Special Publication 800-53A, Guide for Assessing the Security Controls in Federal
Information Systems, is used to facilitate security control assessments conducted within
the risk management framework.
p. Computer Fraud and Abuse Act defines the federal punishments for certain types of
crimes involving the use of a computer.
Scope
This SOP applies to all SBA employees as well as other Federal agencies, State and local
governments, and private organizations or individuals who use SBA information systems to
accomplish SBA business functions. All of the aforementioned are considered users and are
included wherever the words “user” or “users” are referenced within this SOP.
SBA information systems covered by this directive include all information systems that process,
store, or transmit data in support of SBA’s mission. This includes all computer hardware,
software, telecommunications equipment, or other information resources that comprise SBA’s
network of general support systems or applications and services they support.
Violations of this SOP may result in disciplinary action, including dismissal and legal action
against the offending employee(s), contractors, or visitors, consistent with laws, SBA policy, or
contract terms, as applicable.
The requirements in this SOP must be implemented within 1 year of SOP issuance or revision.
SBA information systems are required to comply with NIST Special Publications within one
year of publication, and to OMB requirements as stated. The one-year compliance date for
revisions to NIST Special Publications applies only to the new and/or updated material in the
publications resulting from the periodic revision process.
System owners/project managers must identify any proposed deviations from the mandatory
practices of this SOP and request a waiver in writing from the Chief Information Security Officer
(CISO) or designee, or the CIO. Approved waivers must be documented as part of the
appropriate IT system security plan (SSP) that covers the system applicable to the waiver.
Identical systems under the same management authority and covered by one SSP require only
one waiver request. Requests for an IT Security Program Policy Waiver must:
a. Cite the specific mandatory practice(s) for which the waiver is requested;
b. Explain the rationale for the requested waiver; and
c. Describe compensating controls (if applicable) in place during the period of the requested
waiver, (until systems are compliant with this policy) and provide an action plan
(including target dates) for compliance.
SOP 90 47 3
Effective Date: August 28, 2012 11
The transmission of requests may be secured in a manner commensurate with the risk of harm of
disclosure of the content (i.e., control vulnerabilities). The CIO or designee must respond within
30 calendar days. The decision letter must address the waiver decision.
Implementation
This SOP must be implemented within one year of issuance. All SBA programs and district
offices must provide an implementation plan that details actions that will be taken to achieve full
compliance with this SOP within 90 days of issuance.
Program Overview
SBA’s ISSP SOP contains a comprehensive list of security controls based on the framework
prescribed by NIST Special Publication 800-53, Recommended Security Controls for Federal
Information Systems.
This publication associates recommended minimum security controls with FIPS 199, Standards
for Security Categorization of Federal Information and Information Systems, low-impact,
moderate-impact, and high-impact security categories.
a. Low: The loss of confidentiality, integrity, or availability could be expected to have a
limited adverse effect on organizational operations, organizational assets, or individuals.
b. Moderate: The loss of confidentiality, integrity, or availability could be expected to
have a serious adverse effect on organizational operations, organizational assets, or
individuals.
c. High: The loss of confidentiality, integrity, or availability could be expected to have a
severe or catastrophic adverse effect on organizational operations, organizational assets,
or individuals.
Another benefit of using the NIST 800-53 framework is that it offers the ability to consolidate
the controls it outlines into “common” controls, “hybrid,” and “system-specific” controls.
Common controls are security controls that are inheritable by one or more organizational
information systems. Common controls can apply to:
a. All SBA information systems, regardless of location;
b. A group of information systems at a specific site; or
c. A common information systems, subsystems, or applications (i.e., common hardware,
software, and/or firmware) deployed at multiple operational sites.
Common security controls have the following properties:
a. The development, implementation, and assessment of common security controls can be
assigned to responsible organizational officials or organizational elements (other than the
information system owners whose systems will implement or use the common security
controls); and
b. The results from the assessment of the common security controls can be used to support
the system security assessment and authorization processes of organizational information
systems where the controls have been applied.
SOP 90 47 3
Effective Date: August 28, 2012 12
A hybrid status may be assigned to security controls in situations where one part of the control is
deemed to be common, while another part of the control is deemed to be system-specific. For
example, an organization may view the AT-3 (Security Training) security control as a hybrid
control, with the policy portion of the control deemed to be common, and the identification and
classification of personnel requiring additional security training to be system-specific. In the
event that a control is determined to by “hybrid,” information regarding the system-specific
portion must be documented in the information system’s SSP, and the common portion must be
documented in the security plan of the supporting system or entity.
Security controls not designated as common controls or hybrid controls are considered to be
system-specific controls, and are the responsibility of the information system owner. Security
plans for individual information systems should clearly identify which security controls have
been designated by the organization as common, hybrid, or system-specific security controls.
SBA information systems relying on common or hybrid controls should include in their SSPs
references to the SSPs containing descriptions of the in-place common or hybrid controls.
This SOP is designed to provide SBA level policy requirements for each of the NIST 800-53
controls. Depending on how an information system is categorized, not all controls listed in this
SOP would be applicable. System owners should refer to NIST 800-53 to determine which
controls are applicable to their information systems based on the FIPS categorization.
SOP 90 47 3
Effective Date: August 28, 2012 13
Policy Standards
All SBA programs and district offices will implement the requirements in this SOP in order to
ensure the security of all IT assets. SBA has implemented a series of standards that detail the
policy requirements for all SBA security controls. The standards are as follows:
1. Roles and Responsibilities
2. Access Control
3. Awareness and Training
4. Audit and Accountability
5. Assessment and Authorization
6. Configuration Management
7. Contingency Planning
8. Identity Management
9. Incident Response
10. Maintenance
11. Media Protection
12. Physical Security
13. Planning
14. Personnel Security
15. Risk Assessment
16. Services and Acquisition
17. System and Communication Protection
18. System and Information Integrity
19. Program Management
SOP 90 47 3
Effective Date: August 28, 2012 14
Roles and Responsibilities
SBA has a specific responsibility to protect information resources and will comply with all
Federal and Agency SOPs, regulations, and requirements. All SBA users have a responsibility to
participate in the ISSP and must perform their duties in a manner that supports SBA’s IT security
goals. More specifically, SBA roles with security responsibilities are described below:
1. SBA Administrator
In accordance with FISMA, SBA’s Administrator must:
a. Ensure that SBA has an established IT Security Program that
(1) Provides information security protections commensurate with the risk and
magnitude of the harm resulting from unauthorized access, use, disclosure,
disruption, modification, or destruction of information and information systems;
(2) Complies with FISMA; and
(3) Ensures that information security management processes are integrated with
SBA’s strategic and operational planning processes.
b. Ensure that Sr. Agency officials provide information security for the information, and
information systems that support the operations and assets under their control. This will
be done by communicating the importance of IT security in the Agency’s mission
statements and by directing Sr. Management in SBA’s program areas to provide adequate
resources to protect data and systems within their respective areas, in accordance with
SBA’s IT Security Program;
c. Delegate to the CIO the authority to ensure compliance with the requirements imposed on
the Agency under FISMA;
d. Ensure the Agency has trained personnel to assist in complying with FISMA; and
e. Ensure that the CIO, in coordination with Sr. Management, reports annually on the
effectiveness of IT security programs within the Agency, including the progress of
remedial actions.
2. Chief Information Officer (CIO)
In accordance with FISMA, SBA’s CIO must:
a. Designate in writing a senior agency information security officer to execute SBA’s IT
Security Program for national and non-national security systems that includes:
(1) Developing and maintaining an Agency-wide IT security program;
(2) Developing and maintaining IT security policies, procedures, and control
techniques;
(3) Training and overseeing personnel with significant information security
responsibilities; and
(4) Assisting Sr. Agency officials with their FISMA responsibilities.
b. Approve and issue SBA IT security program policy and standards that establish a
framework for an Agency-wide IT Security Program; and
SOP 90 47 3
Effective Date: August 28, 2012 15
c. Monitor, evaluate, and report the status of IT security within the Agency to SBA’s
Administrator.
3. Chief Information Security Officer (CISO)
The CISO carries out the function of Senior Agency Information Security Officer as defined by
FISMA. In this capacity, the CISO must:
a. Develop, document, and implement an Agency-wide IT security program to provide
information security for the electronic information and information systems that support
Agency operations and assets, including those provided or managed by another agency,
contractor, or other source. This includes:
(1) Conducting periodic assessments of the risk and magnitude of the harm that could
result from the unauthorized access, use, disclosure, disruption of information and
information systems that support the operations and assets of the Agency;
(2) Developing policies and procedures for SBA systems, to include standards that
must be followed by all SBA program areas, and standards and practices to
establish SBA’s IT security program as an integral part of SBA’s IT management
strategy;
(3) Developing subordinate plans for providing adequate information security for
networks, facilities, and systems or groups of information systems, as appropriate;
(4) Conducting IT security awareness training to inform SBA employees and
contractors and other users of the information systems that support the operations
and assets of the Agency;
(5) Conducting periodic security assessments of the effectiveness of information
security policies, procedures, and practices (to be performed with a frequency
depending on risk, but no less than annually);
(6) Developing a process for planning, implementing, evaluating, and documenting
remedial action to address any deficiencies in the information security policies,
procedures, and practices of the Agency;
(7) Developing procedures for detecting, reporting, and responding to security
incidents, consistent with existing standards and guidelines; and
(8) Developing plans and procedures to ensure continuity of operations for
information systems that support SBA’s operations and assets.
b. Ensure IT security is included in SBA’s Strategic IT Planning and Enterprise
Architecture efforts;
c. Monitor and evaluate the status of SBA’s IT security posture by performing annual
compliance reviews of program areas’ information systems and system controls (to
include reviews of IT system security plans, risk assessments, assessment and
authorization processes, and others);
d. Advise SBA’s CIO and program areas of new advances in IT Security that can be used
on an SBA-wide scale and yet reduce the costs for IT security efforts Agency-wide;
SOP 90 47 3
Effective Date: August 28, 2012 16
e. Report to SBA’s CIO and external entities, such as OMB, GAO, and Congress, on the
status of the Agency’s IT Security Program;
f. Provide IT security guidance and technical assistance to all SBA program areas;
g. Track weaknesses in a specific program area’s information systems reported under self-
assessments and external reviews and track implementation of corrective actions;
h. Maintain a database of IT system inventories for each program area;
i. Work cooperatively with SBA’s Office of Inspector General, program areas, and other
entities, to ensure an effective IT security program;
j. Promote and coordinate Agency-wide IT security program activities;
k. Identify resource requirements (including funds, personnel, and contractors) to manage
SBA’s IT security program; and
l. Plan and chair regular meetings of SBA’s IT Security Coordinating Committee (ITSCC)
which is a forum for exchange and action on Agency-wide security policies, problems,
and potential solutions.
4. Program Area Sr. Management Staff
Senior management staff and/or their representatives must ensure implementation of an effective
IT security program for systems under their responsibility. Program areas’ Sr. Management staff
may serve as the authorizing official (accepting operating risks) for systems that support the
program area’s mission. The program area’s Sr. Management staff is ultimately responsible for
IT security in their respective area and, consequently, they must:
a. Communicate to all SBA employees the importance of IT security to the program area’s
mission as well as to the over-all mission of the Agency;
b. Assign the management of IT systems to responsible program officials;
c. Assign responsibility for daily system operations and security to system owners;
d. Serve as the authorizing official (to include accepting operating risks) for systems that
support the program area’s mission. (If the program area’s Sr. Manager serves as the
authorizing official, the program official may serve as the authorizing official’s
designated representative); and
e. Ensure adequate resources are provided to implement IT security activities to include
security assessments and authorizations.
5. System Owner
A system owner is a manager with day-to-day management and operational control over an
information system and direct oversight of the system/network administrators and operations
staff. Although the Federal government has ultimate ownership of all SBA data and its systems,
the term “owner” is commonly used by NIST to refer to individuals with specific system
oversight responsibilities. System owners have many responsibilities in addition to the day-to-
day operation and maintenance of assigned information systems. The information system owner
is the SBA manager responsible for the overall procurement, development, integration,
modification, or operation and maintenance of the information system. The system owner may
rely on the assistance and advice of the ISSO and other IT staff in the following areas:
a. Developing the IT SSP, including the initial risk assessment;
b. Ensuring the system is operating according to the agreed upon security requirements;
SOP 90 47 3
Effective Date: August 28, 2012 17
c. Deciding who has access to the system (and with what rights and privileges);
d. Ensuring users and support personnel receive the requisite security training;
e. Informing key Agency officials of the need to conduct a security authorization effort;
f. Providing necessary system-related documentation to the independent assessor;
g. Taking appropriate steps to update the risk assessment and to reduce or eliminate
vulnerabilities after receiving security assessment results from an independent assessor;
and
h. Assembling and submitting the security authorization package to the authorizing official
or their designated representative.
The system owner is responsible for the safekeeping of the original security authorization
package used for the authorization decision. The system owner is responsible for updating this
package and ensuring re-accreditation as the system undergoes a significant change or at least
every three years. In this respect, the system owner must:
a. Include security considerations in the procurement of system software, hardware, and
support services, including system development, implementation, operation and
maintenance, and disposal activities (i.e., life cycle management).
b. Ensure assessment and authorization of all systems under their responsibility including:
(1) Ensuring the security of data and application software residing on their systems;
(2) Determining and implementing an appropriate level of security commensurate
with the system impact level;
(3) Developing and maintaining the security authorization package, including IT
SSPs and contingency plans for all systems under their responsibility, which
document the business associations and dependencies of their systems (examine
linked IT resources and flow of information); and
(4) Performing risk assessments to periodically re-evaluate sensitivity of the system,
risks, and mitigation strategies.
c. Conduct annual assessments of system safeguards and program elements.
d. Establish system-level POA&Ms and implement corrective actions in accordance with
SBA’s POA&M standards.
e. Grant individuals the fewest possible privileges necessary for job performance (any
privileges not specifically granted are denied access) so that privileges are based on a
legitimate need to have system access. Access privileges must be re-evaluated annually
and must be timely revoked upon personnel transfer or termination.
f. Establish appropriate “Rules of Behavior” for all systems that apply to all personnel
managing, administering, or accessing SBA’s IT systems.
g. Notify the responsible ISSO or the SOC manager of any suspected incidents in a timely
manner, and assist in the investigation of such incidents, if necessary.
h. Ensure IT system users have proper IT security training relevant to their IT security role
and to the system.
SOP 90 47 3
Effective Date: August 28, 2012 18
i. Ensure IT system and IT service contracts include provisions for necessary security.
j. Ensure systems’ personnel are properly designated, monitored, and trained, including
appointment (in writing) of an individual to serve as the ISSO, if appropriate.
6. Information System Security Officer (ISSO)
Appointed by the program area’s Sr. Management, the program ISSO serves as the central point
of contact for the program area’s overall IT security program. The ISSO is the individual
responsible for ensuring the appropriate operational security posture is maintained for
information systems and programs under their control. The ISSO serves as the principal advisor
to the system owner on all matters (technical and otherwise) involving the security of the
program area’s IT systems, and maintains a copy of each Security Authorization Package (SAP)
for use in performing required IT security monitoring and reporting responsibilities. In this
capacity, the ISSO must:
a. Develop and maintain Program area IT security procedures, standards, and guidance
consistent with Agency and Federal requirements.
b. Ensure the conduct of annual reviews to ensure that all systems have in place effective,
quality security documentation, including:
(1) qualitative risk assessments;
(2) current and effective IT SSPs that accurately reflect system status ( to include
audits of the system);
(3) annual system assessments;
(4) current and tested contingency plans; and
(5) current authorization.
c. Track remedial actions to mitigate risks in accordance with SBA’s POA&M process.
d. Establish a process to ensure that all users complete security awareness briefings,
specialized training, acknowledge “Rules of Behavior”, and are trained to fulfill their IT
security responsibilities.
e. Ensure system owners establish a process for ensuring access privileges are revoked in a
timely manner (e.g., transfer, resignation, retirement, change of job description, etc.) --
immediately for individuals separated for adverse reasons or just prior to notification of a
pending action.
f. Notify system owners of user infractions identified during routine compliance
assessments.
g. Maintain the program area’s IT system inventory in accordance with SBA’s standard for
inventory management.
h. Act as the program area’s central point of contact for all incidents and report incidents to
SBA’s SOC manager.
i. Distribute, information to system administrators and others concerning risks and potential
risks to systems, as necessary.
SOP 90 47 3
Effective Date: August 28, 2012 19
j. Participate in SBA’s ITSCC and special committees under the ITSCC, providing other
support for the ITSCC, as appropriate.
k. Coordinate with the CISO and OIG, as appropriate, concerning incidents, potential
threats, and other issues that may potentially threaten the security of the Agency’s
network and information systems.
7. System/Network Administrator
System/network administrators are responsible for certain aspects of system security. This
includes adding and deleting user accounts as authorized by the system owner, as well as normal
operations of the system in keeping with job requirements. The role of a system administrator
may include security of LAN or application administration. The system/network administrator
must:
a. As directed by the system owner, the system/network administrator shall:
(1) Assist in the development and maintenance of IT system security plans and
contingency plans for all systems under their responsibility;
(2) Participate in risk assessments to periodically re-evaluate sensitivity of the
system, risks, and mitigation strategies;
(3) Participate in annual assessments of system safeguards, program elements and in
assessment and authorization of the system;
(4) Evaluate proposed technical security controls to assure proper integration with
other system operations;
(5) Identify requirements for resources needed to effectively implement technical
security controls;
(6) Ensure integrity in the implementation and operation of technical security controls
by conducting control assessments;
(7) Develop system administration and operational procedures and manuals as
directed by the system owner; and
(8) Evaluate and develop procedures that assure proper integration of service
continuity with other system operations.
b. Notify the responsible ISSO (if available) the SOC manager or CISO, of any suspected
incidents in a timely manner, and assist in the investigation of incidents if necessary.
c. Read and understand all applicable training and awareness materials.
d. Read and understand all applicable use policies or other “Rules of Behavior” regarding
use or abuse of the program area’s IT resources.
e. Know which systems or parts of systems for which they are directly responsible (e.g.,
network equipment, servers, LAN, etc.) and the sensitivity of the data they handle, and
take appropriate measures to protect that data.
f. Know and abide by all applicable SBA IT security policies and procedures.
SOP 90 47 3
Effective Date: August 28, 2012 20
8. Procurement Division
SBA’s Procurement Division ensures the integrity of the Agency’s IT security acquisitions by
ensuring that the statements of work in all IT security contract vehicles appropriately address all
security measures and security clauses in accordance with FISMA and the Federal Acquisitions
Regulations.
9. End User
End users’ responsibilities center upon being aware of the security category of the information
and the proper handling of sensitive information and PII, as well as remaining vigilant in
performing necessary security procedures to maintain the confidentiality, integrity, and
availability of the information. End users must:
a. Complete IT security awareness training annually.
b. Read and understand all applicable use policies and other “Rules of Behavior” regarding
use or abuse of the program area’s IT resources.
c. Know which systems or parts of systems for which they are directly responsible (printer,
desktop, etc.).
d. Know the security category of the data they handle and measures they must take to
protect that data.
e. Notify the appropriate ISSO, SOC or supervisor of any suspected incidents in a timely
manner, and cooperate in the investigation of incidents.
f. Know and abide by all applicable Agency acceptable use policies and procedures. This is
especially true of the Internet Use Policy and Peer-to-Peer File Sharing Policy, which
specify the end user’s responsibility regarding Internet introduction of viruses, spam,
spyware, and malicious codes, normally introduced into a system by a voluntary act of an
end user (e.g., installation of an application, FTP of a file, reading mail, etc.).
10. Managers, Supervisors, and Contracting Officer’s Representatives (CORs)
Managers, supervisors, and CORs must determine whether Federal employees and contractors
require IT access to accomplish their primary duties. Specifically, the manager, supervisor, or
COR must:
a. Determine the Federal employee’s or contractor’s need to know before access is granted.
Access to any SBA IT system must not be authorized for a person who does not have a
need for access to the system in the normal performance of his/her official duties.
b. Ensure users under his/her supervision or oversight comply with this policy, to the extent
practicable, and pursue appropriate disciplinary action for noncompliance.
c. Notify system owners of new users and notify them to revoke access privileges in a
timely manner when a user under his/her supervision or oversight no longer requires
access privileges or he/she fails to comply with this policy.
d. Authorize remote access privileges for personnel and review remote access user security
agreements on an annual basis to verify the continuing need for access, the appropriate
level of privileges, and the accuracy of information contained in the agreement (e.g.,
systems authorized for access, type, version of anti-virus software and personal firewall).
SOP 90 47 3
Effective Date: August 28, 2012 21
CHAPTER 1 – Access Control 1. Access Control (AC-1) - Common
Access controls provide a technical means of controlling what information users can access, the
programs they can run, and the modifications they can make. These controls may be built into
the operating system, may be incorporated into applications programs or major utilities (e.g.,
database management systems or communications systems), or may be implemented through
add-on security packages.
AC-1 is an SBA common control. By centrally managing the development, implementation, and
assessment of the common security controls, security costs can be consolidated across multiple
information systems.
SBA requires program areas and system owners to develop formal, documented procedures to
facilitate the implementation of the access control policy and associated controls and to also
develop procedures that address system specific and hybrid control requirements for the access
control family. Reviews must be conducted every 30 days and updates should be made within
30 days from the date the changes occurred.
2. Account Management (AC-2) - Hybrid
SBA requires program areas and system owners to develop, document and maintain procedures
for establishing, activating, modifying, reviewing, disabling, and removing accounts. The
Program areas are required to document the frequency for reviews of information system
accounts, at least bi-annually in their procedures. The documentation must include:
a. Review information system accounts bi-annually to validate the accounts are still
required. Account validations must confirm the following:
(1) The user has a valid need-to-know/need-to-share, as determined by assigned
official duties; and
(2) The user still requires access for the intended system usage.
b. Authorize and monitor the use of guests/anonymous accounts.
c. Configure systems to automatically terminate temporary and emergency accounts as soon
as no longer needed, but not any later than 24 hours after no longer needed.
d. Configure systems to disable inactive accounts after 60 days.
e. Configure systems to terminate accounts after 120 days of inactivity.
f. Configure systems to ensure that account creation, modification, disabling, and
termination actions are audited, and the audit logs are reviewed daily for unusual activity.
g. Deactivate all computer system accounts for within 24 hours when a user:
(1) Departs the Agency voluntarily or involuntarily;
(2) Transfers to another program area within the Agency;
(3) Is suspended;
(4) Goes on long-term detail; and
SOP 90 47 3
Effective Date: August 28, 2012 22
(5) No longer has a legitimate business need for system access.
h. Notify account managers when system users’ accounts are deactivated and/or when
information system usage or need-to-know/need-to-share changes.
i. In the event that automated mechanisms cannot be developed, manual procedures must
be documented and used. All manual procedures must be reviewed and validated
annually by the system owner.
3. Access Enforcement (AC-3) - Hybrid
SBA requires program areas to ensure that information systems enforce assigned authorizations
for controlling access to the system. Program areas must establish and implement procedures for
the following:
a. Documenting and enforcing user privileges on the information system using access
control lists, constraining user interfaces, security labels, access control matrices,
cryptography, etc.
b. Ensuring user privileges are consistent with documented user authorizations.
c. The information system restricts the functions of privileged users to those functions that
they are explicitly authorized to perform.
4. Information Flow Enforcement (AC-4) - Hybrid
Information flow control regulates where information is allowed to travel within an information
system and between information systems. Program areas must establish and implement standard
operating procedures for the following:
a. Ensuring that all information systems are configured to enforce assigned authorizations
for controlling the flow of information within the system, and between interconnected
systems.
b. Ensuring that interconnection security agreements address the types of permissible and
impermissible flow of information between information systems, and the required level
of authorization to allow information flow.
c. Ensuring that any connections to the Internet, or other external networks or information
systems, occur through managed interfaces consisting of appropriate boundary protection
devices (e.g., proxies, gateways, routers, firewalls, guards, encrypted tunnels) arranged in
an effective architecture (e.g., routers protecting firewalls, and application gateways
residing on a protected subnet work, etc.).
d. Ensuring that information system boundary protections at any designated alternate
processing sites provide the same levels of protection as that of the primary site.
5. Separation of Duties (AC-5) - Hybrid
SBA must employ separation of duties to allow for the appropriate divisions of responsibility;
eliminate conflicts of interest in the responsibilities and duties of individuals; and, prevent users
from having all of the necessary authority or information access to perform fraudulent activity
without collusion. Separation of duties provides:
a. A system of checks and balances;
SOP 90 47 3
Effective Date: August 28, 2012 23
b. Distribution of security responsibilities;
c. The best compromise between usability and security; and
d. Protection against the appearance of impropriety by those in a position to bypass IT
security controls.
Program area’s Senior. Management officials, and system owners must apply this principle to
positions with the ability to circumvent IT security controls, such as those involved with auditing
of systems, network administration, application programming, computer operations, facility
security, and any other security related function. System owners must ensure that logical
controls within an application enforce sound principals of separation of duties. Privileged
accounts shall not be used for non-privileged user account access and activities.
The following categories of “duty” must be kept separate or the compensating controls must be
in place to monitor activity closely.
a. SBA mission functions and distinct information system support functions are divided
among different individuals/roles.
b. Different individuals perform information system support functions. For example,
system management, systems programming, quality assurance/testing, configuration
management, and network security must not be performed by the same person.
c. Security personnel who administer access control functions do not administer audit
functions.
Segregation of duties must be considered for roles within an information system application as
well for the following:
a. Transaction authorization must be separate from transaction processing.
b. Asset custody must be separate from asset record-keeping.
c. The information system roles must be structured so that the perpetration of a fraud
requires collusion between two or more individuals.
d. Position descriptions must accurately reflect assigned duties and segregation of functions.
Where resource limitations make segregation of duties impossible to implement, Sr.
Management must ensure that appropriate supervisory review measures are in place to
compensate for the lack of separation of duties. For example, a system administrator may serve
as a backup for an ISSO who is on leave. However, while individuals serve in a dual role,
compensating management controls must be implemented to ensure that changes to the security
posture are properly authorized.
6. Least Privilege (AC-6) - Common
SBA requires that each employee is granted the most restrictive set of privileges needed for the
performance of authorized daily tasks. The application of this principle limits the damage that
can result from an accident, error, or unauthorized use. The information system must be
configured to enforce least privilege through the use of account management and/or role-based
access control. Administrative access must be used only when necessary to perform official
duties.
SOP 90 47 3
Effective Date: August 28, 2012 24
a. Account management requires that users be given accounts that allow them to perform
only their day-to-day duties.
b. Administrator access must be limited to system administrator personnel.
c. In cases where legacy systems cannot be configured to enforce least privilege,
compensating controls must be implemented and monitored to ensure that least privilege
concepts are enforced, through oversight or alternate means.
d. Access to SBA computer systems is based on a need-to-know/need-to-use basis. User
access to SBA major applications are also based on a least privilege basis; that is, users
will be granted the least amount of privilege needed to perform their duties. User
privileges will be re-evaluated quarterly to ensure that the least amount of access
privilege is continually in force for access to major applications.
7. Unsuccessful Login Attempts (AC-7) - Common
The following parameters shall be enforced for SBA information systems:
a. The system allows a maximum of three (3) invalid login attempts within 5 minutes.
b. The application detects and counts invalid login attempts.
c. The system locks out the account for a pre-set time period of at least 15 minutes (after
which it can automatically reset) when suspicious login activity is detected.
Locked accounts with privileged access (i.e., root or administrator access) will remain locked
until unlocked by the HQ Help Desk, security administration, or other authorized account
management personnel. In all cases, some reasonable and verifiable means of identification will
be employed to request that an account is unlocked. Whenever feasible, users will appear in
person with verifiable official identification.
8. System Use Notification (AC-8) - Common
SBA requires that the Program areas ensure that information systems display an approved system
use notification message, before granting system access, informing potential users that:
a. The user is accessing a U.S. Government information system.
b. System usage may be monitored, recorded, and subject to audit.
c. Unauthorized use of the system is prohibited and is subject to criminal and civil penalties.
d. The use of the system indicates consent to monitoring and recording.
The system use notification message provides appropriate privacy and security notices and
remains on the screen until the user take explicit actions to logon to the information system.
In order to inform users of the system, the system owner must select and configure the system to
display a warning banner screen (or close approximation) at login, and require users to
electronically acknowledge the warning (such as clicking on “OK” or “I agree”) button before
access is granted. The Office of General Counsel must approve the statement or warning banner.
The standard warning banner is displayed below and may be used as the notice for all SBA
systems.
SOP 90 47 3
Effective Date: August 28, 2012 25
9. Concurrent Session Control (AC-10) - Common
SBA requires that the program areas ensure that information systems categorized as High, limit
the number of concurrent sessions for any user to a maximum number of sessions to one (1).
Additional concurrent sessions may be added as needed with appropriate authorization. No more
than three sessions are appropriate without a documented business reason.
10. Session Lock (AC-11) - Common
SBA requires that program areas ensure that the information system is configured to activate a
password protected “screen saver” option after a maximum of five (5) minutes of inactivity and
blocks further access until the user re-establishes the connection using the proper identification
and authentication procedures.
a. Based on sensitivity of information on the system, the system administrator can make the
time limit shorter based on a risk based management decision.
b. Ensure session lock functionality is associated with each information system node (e.g.,
terminal, workstation, notebook computer).
c. SBA Sr. Management with operational responsibility for an SBA program area is
responsible for the protection of the PC hardware, system software, sensitive data and PII
within that specific SBA program area.
d. PCs must be securely maintained. Laptop computer equipment located in open areas
should be secured to a desk using a laptop lock, when possible.
e. PCs must be protected using a password protected screensaver that secures the
workstation after 5 minutes of inactivity. Prior to leaving the workspace for a short
period of time, the user must manually activate the password protected screensaver by
pressing the Ctrl, Alt, and Delete keys simultaneously; the password protected screen
saver will then be invoked. Users should power off their PC when leaving the
workstation for the day.
11. Permitted Actions without Identification and Authentication (AC-14) - Common
SBA does not allow user activity without identification and authentication.
This is a Federal computer system and is the property of the United States Government. It is for authorized use only. Users (authorized or unauthorized) have no explicit or implicit expectation of privacy in anything viewed, created, downloaded, or stored on this system ,Including e-mail, Internet, and Intranet use. Any or all uses of this system (including all peripheral devices and output media) and all files on this system may be intercepted, monitored, read, captured, recorded, disclosed, copied, audited, and/or inspected by authorized Small Business Administration (SBA) personnel, the Office of Inspector General (OIG), and/or other law enforcement personnel, as well as authorized officials of other agencies, both domestic and foreign. Access or use of this computer by any person, whether authorized or unauthorized, constitutes consent to such interception, monitoring, reading, capturing, recording, disclosure, copying, auditing, and/or inspection at the discretion of authorized SBA personnel, law enforcement personnel (including the OIG),and/or authorized officials of other agencies, both domestic and foreign. Unauthorized use of, or exceeding authorized access to, this system is prohibited and may constitute a violation of 18 U.S.C. § 1030 or other Federal laws and regulations and may result in criminal, civil, and/or administrative action. By continuing to use this system, you indicate your awareness of, and consent to, these terms and conditions and acknowledge that there is no reasonable expectation of privacy in the access or use of this computer system. LOG OFF IMMEDIATELY if you do not consent to the conditions stated in this notice.
SOP 90 47 3
Effective Date: August 28, 2012 26
12. Remote Access (AC-17) - Common
Management of remote access to SBA’s network and information systems is critical to ensuring
the integrity, availability, and confidentiality of SBA systems, information, and network
infrastructure. SBA requirements for remote access management are as follows:
a. All users are to conduct only official and approved government business through remote
access.
b. UNIX, Linux, or AIX-based computers requiring remote user logon access must have
authentication software installed that can generate one-time passwords.
c. UNIX-based computers that do not require remote access must have all remote
services/utilities disabled. When possible, users should be isolated from the operating
system through the use of user interfaces or menus.
d. Modems must not be connected to UNIX, Linux, or AIX-based systems. Access to
external information sources (e.g., Internet) must be made through SBA’s network which
is managed by the CIO. Direct connections are prohibited.
Employees must use the following when accessing SBA’s network remotely:
a. Agency standard operating system image;
b. Patch management software agent;
c. Personal firewall; and
d. Anti-virus software and up-to-date virus definition files.
SBA contractors must use approved systems to access SBA’s network and information systems.
a. Requests for remote access for SBA contractors must be submitted by the COR and
reviewed and approved by the authorizing official for the specific SBA program area and
the CISO.
b. All SBA contractor accounts for remote access will have a termination date that coincides
with the cessation date of the work for which access was required.
c. No users with remote access privileges have the right to expect privacy in their use of
SBA’s network and information systems.
To gain approval for non-SBA equipment, they must identify:
a. A valid business reason for requiring remote access to SBA’s network and information
systems;
b. The computer name of the system(s) requiring remote access;
c. The operating system of the computer system(s) requiring remote access;
d. The name and version of the active anti-virus software running on the computer
system(s); and,
e. The name and version of the local firewall protection on the computer system(s).
SOP 90 47 3
Effective Date: August 28, 2012 27
Technical Remote Access Requirements
a. Authentication, encryption, and active monitoring mechanisms will be used for remote
access systems to protect the integrity and confidentially of SBA’s network and
information systems.
b. Two-factor authentication will be used for remote access.
c. No split tunneling will be allowed through remote access sessions. Split tunneling is a
computer networking concept which allows a VPN user to access a public network (e.g.,
the Internet) and a local network at the same time, using the same physical network
connection. This connection service is usually facilitated through a program such as a
VPN client software application.
d. All remote access will be managed and controlled through centrally managed resources.
e. Real-time or near-real-time analysis of remote session events will be employed to detect
system-level alerts.
f. All remote access will be logged using an audit log. Remote access audit logs will be
reviewed daily and retained for one (1) year.
g. Remote access sessions will be automatically disconnected upon logout or session
inactivity lasting longer than 30 minutes.
h. Remote access computers must not be used as servers (e.g., Web servers, private e-mail
servers, File Transfer Protocol (FTP) sites, or chat servers).
13. Wireless Access (AC-18) - Common
No wireless network may be established unless approved by the CIO. The implementation of all
wireless technology requires conducting a formal risk assessment in the environment where this
technology will operate, prior to deployment of the wireless technology. The user’s program area
must implement a mechanism to document and maintain records of wireless access user security
agreements and network access. A “wireless access user security agreement” provides
documentation ensuring that:
a. The user’s manager, supervisor, or COR has approved the wireless access request.
b. The user certifies that he or she has received SBA security training within the last year.
c. The user certifies that he or she understands, and will abide by the terms of the “wireless
access user security agreement” and this wireless access standard.
General Wireless Requirements
a. The wireless network must be separated from the wired network using an authorized
architecture. This separation requires placement of wireless access points and bridges into
a screened subnet, such as a demilitarized zone (DMZ) on firewall separating intranet and
wireless network. Alternatively, the site may use a Virtual LAN (VLAN) or otherwise
separate the WLAN from the wired internal network with a wireless Virtual Private
Network (VPN) concentrator or wireless gateway, firewall, or switch placed between the
access point and the local network.
b. Any implemented WLANs shall be periodically reviewed and audited to identify
unauthorized devices connecting to the network.
SOP 90 47 3
Effective Date: August 28, 2012 28
c. WLAN devices shall not be used to transfer, receive, store or process SBA information
unless Federal Information Processing Standards (FIPS)-compliant cryptographic
modules are used to encrypt data during transmission.
d. Infrared WLAN receivers and transmitters on equipment shall be disabled.
e. Peer-to-peer communications shall not be allowed. WLAN Network Interface Cards
(NICs) that cannot disable peer-to-peer WLAN communications will not be used.
f. The WLAN shall provide a session timeout capability, and the timeout should be set for
30 minutes or less, depending on local security policy.
g. The WLAN shall be periodically screened for rogue access points, stations and bridges.
Wireless Access Point Requirements
a. All WLAN access points shall be placed on an isolated DMZ or VLAN. A VPN
concentrator will be placed between the wireless network and the infrastructure.
b. Host and network based intrusion detection/protection shall be used to monitor the
wireless network.
c. All access points shall be physically secured to prevent unauthorized access.
d. Hyper Text Transfer Protocol (HTTP) and Simple Network Management Protocol
(SNMP) interfaces must be turned off after initial configuration. These services can be re-
enabled for firmware upgrades only, but must be disabled immediately thereafter. If
SNMP must be used, use the latest version of SNMP and change the default community
string to a strong string and traffic encapsulated using encryption.
e. Password access to the wireless access point management console will be turned on and
configured with a password that complies with SBA’s password policy.
f. FIPS-compliant encryption shall be used to encrypt wireless transmissions. WPA2 or
greater is preferable. Consult the NIST FIPS 140-2 Validated Products List prior to
procuring WPA2-certified products to determine if the specific product is also FIPS 140-
2-certified. WEP shall not be used.
g. MAC address filtering will be turned on at each access point. NOTE: MAC address
filtering may not be practical for large WLAN implementations, unless the WLAN
management system allows for MAC distribution lists to be centralized and automatically
distributed to the point of authentication.
h. Wireless access points should maximize the beacon interval. Using a longer beacon
interval forces an adversary to perform what is referred to as “active scanning” using
probe messages with a specific Service Set Identifier (SSID).
i. The SSID broadcast mode shall be disabled. Access points that cannot disable SSID
broadcast will not be used.
j. WLAN access points shall be set to the lowest possible transmit power setting that will
meet the required signal strength of the area serviced by the access point.
Wireless Client Requirements
a. Virus protection, a personal firewall, and intrusion detection shall be implemented on
each wireless client, if feasible.
b. Password protection mechanisms shall be placed on client files and folders.
SOP 90 47 3
Effective Date: August 28, 2012 29
c. All clients will be configured according to SBA’s standard system baseline.
d. Clients will not be connected to SBA’s WLAN and SBA wired infrastructure at the same
time.
e. File system encryption must be used on all WLAN client devices.
Bluetooth
Any use of wireless Bluetooth technologies must be approved by the CISO. The following
guidance must be implemented when the use of Bluetooth devices is approved:
a. Default settings of the Bluetooth device must reflect the Agency’s security policy.
b. Choose PIN codes that are random – not, for example, 1234.
c. Choose PIN codes that are 8 characters or longer.
d. Ensure that no Bluetooth device will default to the zero PIN.
e. Configure Bluetooth devices to delete PINs after initialization to ensure that PIN entry is
required every time, and that the PINs are not stored in memory after power removal.
f. Ensure that encryption is enabled on every link in the communication chain.
g. Ensure mutual authentication for all accesses.
h. Ensure that portable devices with Bluetooth interfaces are configured with a password to
prevent unauthorized access if lost or stolen.
Users must follow these basic security steps when using Bluetooth technologies:
a. Turn off Bluetooth if it is not being used.
b. Make sure the device is set to undiscoverable mode when in use.
c. Do not pair with devices in public.
d. Do not pair with or accept anything from an unknown device.
e. Change your PIN to eight characters or longer, if you have the capability.
f. Routinely check your list of paired devices to ensure that all are appropriate.
System administrators must implement the security standards recommended as described in
applicable NIST and standard configuration guidance.
14. Access Control for Mobile Devices (AC-19) – Common
a. SBA owned portable and mobile devices are only allowed access to SBA information
systems in accordance with Agency’s security policies and procedures.
b. No PII or sensitive Agency data may be stored on any mobile devices without encryption.
Portable and mobile devices include, but are not limited to, the following:
(1) Notebook computers;
(2) Personal digital assistants;
(3) Cellular telephones;
(4) Other computing and communications devices with network connectivity and the
capability of periodically operating in different physical locations;
(5) USB drives; and
(6) CD-ROMs/DVDs.
SOP 90 47 3
Effective Date: August 28, 2012 30
c. OCIO is responsible for implementing and documenting security configurations for
portable and mobile devices, including ensuring that sensitive data and PII are not stored
on user workstations or mobile devices unless the use of this data is required and
approved and encrypted. The following requirements apply:
d. SBA must encrypt all data on laptop or handheld computers unless the data is classified
as "non-sensitive." Encryption must be in accordance with FIPS 140 requirements.
e. Agency employees and contractors must use two-factor authentication. For example, a
password plus a physical device such as the RSA token, to reach a work database via
remote connection.
f. All implementations of wireless technology require a formal risk assessment prior to
deployment.
g. All portable and mobile devices must be configured securely in accordance with NIST
configuration guidelines, which include the following:
(1) Device identification and authentication;
(2) Implementation of mandatory protective software (e.g., malicious code detection,
firewall);
(3) Secure configuration settings;
(4) Scanning devices for malicious code;
(5) Updating virus protection software;
(6) Scanning for critical software updates and patches;
(7) Conducting primary operating system integrity checks;
(8) Ensuring that all Basic Input/Output Systems (BIOS) and sensitive files on the
laptop hard drive are password-protected; and
(9) Based on sensitivity, new laptops should be equipped with “dial home” software
that can be used to communicate with the agency and assist police in recovering
stolen equipment when it is technically and financially feasible.
h. An employee or contractor must not take sensitive data or PII from SBA facilities
(including SBA managed programs housed at contractor facilities under contract), or
access remotely (i.e., from locations other than SBA facilities), without written
permission from the employee’s supervisor, the data owner, and the IT system
authorizing official. This applies to electronic media (e.g. laptops, BlackBerrys, USB
drives), paper, and any other media (e.g., CDs/DVDs) that may contain sensitive data or
PII. All mobile devices must be securely transported. Users of mobile storage devices are
responsible for:
(1) Storing laptops and personal computing or storage devices in a lockable cabinet
when not in use.
(2) and not leaving these devices unattended.
(3) Ensuring that all laptops and personal computing devices used for SBA business,
whether personally- or government-owned, employ antivirus software; and that
users maintain current virus signature files (updated daily).
(4) Backing up critical data before going on travel.
(5) Restricting use of the mobile or personal computing device to only authorized
individuals.
SOP 90 47 3
Effective Date: August 28, 2012 31
(6) Immediately reporting any lost or stolen portable mobile devices belonging to the
Agency, or containing Agency data.
SBA’s procedures for connecting devices to the network pertain to all devices connected
to SBA’s network via cable or wall-jack that are plugged into a PC or laptop or directly
into the network. Such devices include servers, desktop PCs, laptops, printers, scanners,
portable storage devices and hand held devices such as telephones, cameras and USB
drives that may or may not be SBA issued.
Any of the above devices that are not SBA issued must be cleared by OCIO before
connection to the network is allowed. Access to the network is limited to authorized
devices that are in compliance with the Agency’s information security policies. SBA has
implemented several tools to monitor devices approved for connection to the network.
Using these tools, SBA system administrators shall:
(1) Ensure authentication servers uniquely identify and authenticate all devices before
the devices establish a connection with the network;
(2) Ensure that authentication servers only authenticate SBA issued devices; and
(3) Document the procedures required to ensure authentication servers
uniquely identify and authenticate all devices.
i. Reports will be generated by OIS identifying the devices and users violating these
criteria. Users and system administrators responsible for the network segment where the
infraction occurred will be notified.
j. The following special requirements apply to laptops, servers, portable storage devices
and desktop computers connected to SBA’s network. These devices must not:
(1) Run a personal firewall (the firewall will be disabled when scanned for
vulnerabilities by OCIO and must not be enabled);
(2) Have peer-to-peer applications installed;
(3) Have instant messenger applications installed;
(4) Be updated with the most current patches for vulnerabilities; and
(5) Run an antivirus application.
k. SBA-issued devices must be configured and installed by authorized SBA technicians
such as the HQ Help Desk, Field Information Technology Specialists (FITs) assigned to
your specific geographical location or the Local Technical Representative (LTR) at the
closest SBA field office, if you are working at one of SBA’s official remote locations.
l. SBA employees are not allowed to connect personal devices to the Agency’s network.
Contractors may be allowed to use company issued devices upon pre-approval by OCIO
by following the steps below:
(1) The COR must submit requests via email to the CISO stating what device(s) the
contractor is requesting to use and why SBA’s device(s) cannot be used.
(2) The device(s) will be scanned for vulnerabilities by SBA’s SOC. Based upon the
results, the CISO will make a decision to allow or not allow the connection.
(3) Any device that was approved for connection to SBA’s network and later
removed and connected to a foreign network (e.g., the employee’s home or
contractor’s off-site location) must go through the approval process again before
reconnecting to SBA’s network.
SOP 90 47 3
Effective Date: August 28, 2012 32
15. Use of External Information Systems (AC-20) - Common
SBA employees and contractors shall not use external information systems to access the
information system or to process, store, or transmit Agency controlled information unless
specifically authorized. For example, an SBA employee or contractor may not send internal
government documents to another party using a personal e-mail account or forward SBA
information to personal email accounts. Authorized use of external information systems will
occur only when:
a. The organization verifies the employment of required security controls on the external
system as specified in the Agency’s information security policy and SSP;
b. The organization approves information system connection or processing agreements with
another Agency entity hosting the external information system;
c. The organization limits the use of organization controlled portable storage media by
authorized individuals on external information systems, and;
d. OCIO and the Office of General Counsel approve connections to the private network
from any source outside of SBA before connection attempts are made. Documenting an
Interconnection Security Agreement is the responsibility of the program manager
requesting the connection; however, OCIO will assist with the technical details.
16. AC-22 Publicly Accessible Content - Common
In conjunction with assigned duties, SBA employees and support contractors may post
information onto SBA systems that are publically accessible. When assigned these duties, the
employees and contractors who post publicly accessible content must:
a. Be trained in the proper procedures to ensure publicly accessible information does not
contain non-public information; and
b. Review the proposed content of publicly accessible information for non-public
information prior to posting onto any SBA information system;
System owners must:
a. Review content on the publicly accessible organizational information system for
nonpublic information quarterly; and
b. Remove non-public information from the publicly accessible SBA system or website, if
discovered.
SOP 90 47 3
Effective Date: August 28, 2012 33
CHAPTER 2 – Awareness and Training
1. Awareness Training Policies and Procedures (AT-1) - Common
SBA will develop, organize, implement, and maintain an IT Computer Security Awareness and
Training (CSAT) program to ensure the security of SBA information and IT resources. Security
awareness and training procedures will be developed for SBA’s security program in general, for
a particular class of employees supporting a system or program, and for a particular information
system, when required.
2. Security Awareness (AT-2) - Common
SBA’s security awareness training program provides users with a basic understanding of the
need for information security and user actions to maintain security and to respond to suspected
security incidents.
SBA employees and contractors must complete training at least annually, whenever there is a
significant change in the Agency's IT security environment or procedures, or when entering a
new position that deals with sensitive information. All current SBA employees and contractors
must take the CSAT by June 30th
each year. New employees and contractors must take the
CSAT within 10 days from their entry on duty date.
3. Security Training (AT-3) - Common
SBA requires that personnel in significant IT security roles as described below, obtain role-
based training as recommended by NIST Special Publication 800-16, Information Technology
Security Training Requirements: A Role-and Performance-Based Model. It is at the discretion of
the program area to determine cost-effective sources for training and for meeting the training
needs of personnel filling supporting IT roles. SBA requires that role-based security training be
provided before authorizing access to the system or performing assigned duties, when required
by system changes, and annually.
Further, the specific roles identified must be evaluated with respect to security training
requirements. Appropriate training should be identified, developed and delivered at least
annually to those groups identified as having additional security responsibilities. The security
training materials must address the procedures and activities necessary to fulfill the
organization’s defined roles and responsibilities for information system security.
The roles within SBA that require role-based security training include, but are not limited to:
a. Those with significant IT security responsibilities, including those who serve as
authorizing officials (and their designated representatives) and certification agents. These
roles must receive specialized role-based training upon appointment to the role, or within
a reasonable time of appointment, so that they understand the scope of their
responsibilities. A list of those with significant IT security responsibilities includes:
SOP 90 47 3
Effective Date: August 28, 2012 34
Role: IT Management Authority Role: Technical Functions
Administrator Database/Network/System/Web Administrator
CIO, CTO, CISO, and CEA Personnel Information System Security Officer
Authorizing Officials Computer Incident Response personnel
Agency Directors Application/System Developer
IT Security Managers/Officers Security Operations Center
System Owners Programmers/Developers
Role: Those having authority to enter
into user agreements or arrangements on
behalf of SBA
Role: Those receiving a specialized service
Program Officials and other Senior
Managers Telecommuters
Acquisition staff, including Contracting
Officers and Contracting Officers
Representatives
4. Security Training Records (AT-4) – Common
SBA must document and monitor individual information system security training activities. The
activities include training record documentation for:
a. Basic security awareness training, PII and role- based training (if required);
b. Specialized security awareness training;
c. Contractor/non-employee security awareness training; and
d. New hire security awareness training.
The training records must include:
a. The names of individuals, including contractors, required to take training;
b. The specific training each individual is required to take; and
c. The completion date of required training.
SBA employees and contractors should maintain a copy of the certificate of completion for each
training module for their records, provide a copy to their immediate supervisor or COR. The
program area should retain electronic or hardcopy records of employees, contractors,
subcontractors, grantees and co-operators trained to ensure training statistics are included in the
annual FISMA report.
SOP 90 47 3
Effective Date: August 28, 2012 35
CHAPTER 3 – Audit and Accountability
All SBA information systems (general support systems and major applications) shall ensure that
security activity auditing capabilities are employed by both system and application processes.
Information systems shall maintain and protect audit logs for all systems. All activity on SBA
systems is subject to monitoring, and users have no privacy with respect to their activities on the
government owned systems. Audit records are reviewed frequently for signs of unauthorized
activity or other security events. Audit records must be designed to establish individual
accountability, reconstruct a sequence of events, support the detection of security incidents, and
to identify systemic and specific security weaknesses.
SBA requires that system owners define in the IT SSP the requirements to log, monitor, and
investigate possible security violations from activity involving access to and modification of
files. Audit trails maintain a record of authorized and unauthorized system events both by system
and application processes and by user activity of systems and applications. In conjunction with
other processes and controls, such as incident response capabilities and user identification and
authentication, audit trails can assist in detecting security violations, network performance
problems, and flaws in applications. Audit trails can provide a means to help accomplish several
security related objectives, including individual accountability, reconstruction of events,
intrusion detection, and problem analysis.
Audit and accountability requirements for an information system must be established by the
system owner, in conjunction with appropriate security personnel. The level of detail captured by
audit records must be commensurate with the sensitivity of the information being protected, and
with the FIPS categorization of the information system. These determinations must be made and
documented in the SSP.
1. Audit and Accountability Policy and Procedures (AU-1) - Common
All SBA information systems (general support systems and major applications) shall ensure that
security-activity auditing capabilities are configured and active by both system and application
processes.
Information systems shall maintain and protect audit logs for all systems. All activity on SBA
systems is subject to monitoring, and users have no privacy with respect to their activities on
government owned systems. Audit records are reviewed weekly for signs of unauthorized
activity or other security events. Audit records must be designed to establish individual
accountability, reconstruct a sequence of events, support the detection of security incidents, and
to identify systemic and specific security weaknesses. SBA requires system owners define
requirements to log, monitor, and investigate possible security violations from activity involving
access to and modification of files, and document the requirements in the IT SSP.
Audit trails maintain a record of authorized and unauthorized system events both by system and
application processes and by user activity of systems and applications. In conjunction with other
processes and controls, such as incident response capabilities and user identification and
authentication, audit trails can assist in detecting security violations, network performance
problems, and flaws in applications. Audit trails can provide a means to help accomplish several
security-related objectives, including individual accountability, reconstruction of events,
intrusion detection, and problem analysis.
SOP 90 47 3
Effective Date: August 28, 2012 36
Audit and accountability requirements for an information system must be established by the
system owner, in conjunction with appropriate security personnel. The level of detail captured by
audit records must be commensurate with the sensitivity of the information being protected, and
with the FIPS categorization of the information system. These determinations should be made
and documented in the SSP. System administrators and database administrators must follow the
procedures below in order to generate, transmit, store, analyze, and delete information system
audit logs:
a. Ensure logs are maintained for all security related events that may occur during the
processing of financial data, sensitive data, and PII. At a minimum, audit logs must
include user IDs, dates and times of logging on and logging off the system, details of
attempted and successful logon attempts, details of attempted and rejected logon
attempts, system configuration changes, use of privileged accounts and the files accessed.
b. Apply encryption when transmitting audit logs electronically between hosting sites and
SBA.
c. Review and analyze audit logs at least weekly to identify unauthorized user activity and
system errors.
d. Program areas responsible for one or more of the Agency’s information systems must
have someone with the skill sets necessary to identify anomalies, if any, prepare
summary reports, and submit them to OCIO every 30 days.
e. Retain audit logs for at least 1 year, or according to the Agency’s record retention
requirements.
f. Maintain the confidentiality, integrity, and availability of audit logs.
g. Report missing logs or irretrievable logs as security incidents as directed by SBA
Incident Response procedures.
2. Auditable Events (AU-2) - Hybrid
All SBA information systems must establish and document guidelines for the following:
a. A high-level overview of the auditing capabilities provided by the information system;
b. Information regarding and intrusion protection or prevention systems employed in the
information system;
c. Start-up and shutdowns of systems or audit functions;
d. Access attempts that exceed authorized limit;
e. User account lock-outs;
f. Successful and unsuccessful login and logout of users;
g. Actions taken by system administrators, system security administrators, or other super
users;
h. Changes or attempts to change privileges and access controls for users and objects;
i. Unauthorized or unusual activities;
SOP 90 47 3
Effective Date: August 28, 2012 37
j. Threat monitoring (reviewing, analyzing and conducting assessments of audit trails to
search out events that may constitute attempted violations);
k. Resources for availability problems, active attacks, resource slowdowns, and crashes;
l. Systems classified as Moderate and High must ensure that the information system
provides the capability to manage the selection of events audited by individual
components of the system, and must ensure that the list of auditable system and network
events are periodically reviewed at least annually; and
m. Systems classified as High must provide the capability to compile audit records from
multiple components throughout the system into a system-wide (logical or physical),
time-correlated audit trail.
3. Content of Audit Records (AU-3) - Hybrid
All SBA information systems (general support systems and major applications) shall ensure that
audit logs contain the following details:
a. User/system/process name associated with event;
b. Date and time of the event;
c. Type of event;
d. Success or failure of the event;
e. Name of the program or file introduced, accessed, modified, or deleted; and
f. Name of the system where the network event device occurred.
g. Moderate and High systems must employ auditing mechanisms that allow for the
inclusion of additional detailed information, enabling events to be sorted by type,
location, or subject.
h. High systems must provide an auditing mechanism that can manage the content of audit
records generated by multiple individual components of the information system.
4. Audit Storage Capacity (AU-4) - Hybrid
SBA requires that program areas allocate sufficient audit record storage capacity and configure
auditing to prevent such capacity from being exceeded. Information system owners shall ensure
that sufficient storage is available to ensure that audit record retention requirements (as
documented in AU-11) are met, taking into account the auditing to be performed and the online
audit processing requirements. The system must be capable of monitoring the capacity of audit
logs and notifying the system administrator when a threshold is reached.
5. Response to Audit Processing Failures (AU-5) - Hybrid
In the event of an audit processing failure, or the inability to generate required logging, SBA’s
major applications and general support systems shall alert the appropriate organizational officials
of the failure. All SBA information systems must be evaluated and risk based decisions must be
made regarding the appropriate activity to take in the event of an audit processing failure. These
events can include:
a. Overwriting the oldest records;
SOP 90 47 3
Effective Date: August 28, 2012 38
b. Discontinuing the generation of audit logs until the problem can be remedied; and
c. Shutting down the information system.
Audit processing failures include, for example, software/hardware errors, failures in the audit
capturing mechanisms, and audit storage capacity being reached or exceeded.
For SBA Information systems classified as High impact the following enhancements must be
made to the above processes:
a. The system must provide an alert when allocated audit record storage reaches 90% of
capacity; and
b. The system must provide a real-time alert when the following events occur: Program-
defined audit failure events requiring real-time alerts.
6. Audit Review, Analysis and Reporting (AU-6) - Hybrid
The following requirements apply to audit log review, analysis and reporting:
a. Audit logs will be reviewed at least weekly by authorized staff for suspicious activity.
b. Systems categorized as Moderate or High will employ automated mechanisms to
automatically alert security personnel when designated activities are identified.
c. Systems categorized as High will implement mechanisms integrating audit monitoring,
analysis, and reporting into a consolidated process.
Appropriate and timely action will be taken to investigate anomalies and report observations and
findings to OIS by implementing the following appropriate SBA incident handling procedures:
a. All network device events will be collected, retained, reviewed, and correlated to detect
suspicious activity and anomalies;
b. All data telecommunication resources (equipment and services) syslog events must be
collected;
c. Appropriate staff shall perform daily examinations of network IDS/IDP audit logs for
evidence of suspicious activity, such as attempts at unauthorized access to SBA’s
network;
d. Audit log review personnel shall immediately report suspicious activity (e.g., suspected
attempts at unauthorized network access) to appropriate Agency officials, as documented
in the Incident Response policies; and
e. The POC or system owner, or persons other than the system administrator, must conduct
regular analyses of audit trails, although the system administrator may also be permitted
read only access to audit trails.
7. Audit Reduction and Report Generation (AU-7) - Hybrid
SBA information systems categorized as Moderate or High must provide an audit reduction and
report generation capability among the components and operating systems supporting the
information system. Additionally the system must provide the capability to automatically process
audit records for events of interest based on selectable criteria. Audit reduction, review, and
reporting tools must support after-the-fact investigations of security incidents without altering
original audit records. This control is not applicable to Low impact systems.
SOP 90 47 3
Effective Date: August 28, 2012 39
8. Time Stamps (AU-8) - Hybrid
All audit collection systems must receive their timing from a common reliable source in order to
correlate date/time stamps. Time stamps of audit records must be generated using internal system
clocks that are synchronized system-wide at least every 24 hours. General support systems must
use the network time protocol (NTP), or another appropriate mechanism, to synchronize the logs
with other logging systems, such as intrusion detection.
9. Protection of Audit Information (AU-9) - Hybrid
All SBA systems shall ensure that audit records are stored to prevent unauthorized access,
deletion and modification of audit trails. Only authorized security personnel should have access
to modify or delete audit records.
Security auditing and monitoring must not be entirely conducted by individuals whose interest
may conflict with the purpose of the activity. Individuals performing these activities must be
objective and impartial.
In the event that audit log compilation or consolidation occurs, appropriate precautions against
unauthorized deletion or modification of audit trails must be implemented on any consolidated
servers used for reporting or analysis.
10. Non-Repudiation (AU-10) - Hybrid
Non repudiation services can be used to determine if information originated from an individual,
or if an individual took specific actions (e.g., sending an e-mail, signing a contract, approving a
procurement request) or received specific information. Examples of particular actions taken by
individuals include, but are not limited to:
a. Creating information;
b. Sending a message;
c. Approving information (e.g., indicating concurrence or signing a contract); and
d. Receiving a message.
There are currently no required non-repudiation standards for systems in use at SBA. Program
areas may, at their discretion, elect to ensure that non repudiation standards are enforced for
designated activities.
11. Audit Record Retention (AU-11) - Hybrid
All network device events as well as telecommunication resources (equipment and services)
syslog events will be collected, retained, reviewed, and correlated to detect suspicious activity
and anomalies.
Audit logs/records shall be backed up no less than weekly onto a different information system or
media than the system being audited. Documentation pertaining to network auditing, including
audit logs, monthly reports, evidentiary supporting documentation of investigations, and
documentation of corrective actions, will be retained for not less than 1 year (no incremental
disposal).
System owners will retain audit records until it is determined that they are no longer needed for
administrative, legal, audit, or other operational purposes; but not less than 1 year. This
SOP 90 47 3
Effective Date: August 28, 2012 40
includes, for example, retention and availability of audit records relative to Freedom of
Information Act (FOIA) requests, subpoena, and law enforcement actions.
12. Audit Generation (AU-12) – Hybrid
Audits records must be generated from all SBA IT systems various components within the
information system. Audit records must contain a list of audited events as defined in AU-2.
Designated personnel will select which events are to be audited and the system will generate
records for the list of audited events defined in AU-2 with the content defined in AU-3. High
impact systems will compile audit records into a system-wide (logical or physical) audit trail that
is time correlated.
SOP 90 47 3
Effective Date: August 28, 2012 41
CHAPTER 4 – Assessment and Authorization
1. Security Assessment and Authorization Policies and Procedures (CA-1) - Common
SBA must develop, disseminate, and periodically review/update formal, documented, security
assessment and assessment and authorization policies and procedures that address purpose,
scope, roles, responsibilities, management commitment, coordination among organizational
entities, and compliance. All SBA policies and procedures must conform to OMB Cir. A-130,
Appendix III, and the Federal Information Security Management Act. This policy is updated at
least annually.
SBA must formally assess and authorize all federal information systems. This requirement
applies to all information and information systems owned, leased, operated or connected to the
Small Business Administration. SBA has formal documented procedures. (See the Appendix M
- SBA Security Assessment and Authorization Process.)
2. Security Assessments (CA-2) - Hybrid
SBA requires an annual assessment for systems not undergoing the authorization process. SBA
system owners are required to test a third of all controls and enhancements annually using a
NIST SP 800-53 based assessment process. All security controls must be assessed over the three
year accreditation cycle. All SBA system controls and enhancements must be assessed as part
of:
a. Security authorization or reauthorization;
b. Meeting the FISMA requirement for annual assessments;
c. Continuous monitoring; and
d. Testing/evaluation of the information system as part of the system development life cycle
process.
SBA requires ongoing automated monitoring and monthly assessments, as part of the continuous
monitoring process, for the following controls:
a. Vulnerability Management;
b. Patch Management;
c. Configuration Management;
d. Event management;
e. Incident Management;
f. Malware Detection;
g. Asset Management;
h. Network Management; and
i. License Management.
For systems undergoing the authorization process, all controls must be assessed during the
authorization process. SBA must use NIST SP 800-53a as a security assessment framework.
SOP 90 47 3
Effective Date: August 28, 2012 42
For Moderate and High impact systems SBA will employ an independent team to conduct an
assessment of the security controls.
For High impact systems SBA will include as part of security control assessments, annual,
independent technical vulnerability assessment and/or penetration tests.
3. Information System Connections (CA-3) - Common
SBA information systems must use information system connection agreements for connections
to systems outside of its accreditation boundary, and must monitor the connections.
A system interconnection connects two or more IT systems to share data and other information
resources. Interconnecting IT systems can expose all of the participants to risk. Security failures
of one system could be used to compromise the connected systems. SBA requires Authorizing
Officials to authorize all connections from the information system to other information systems
outside of the accreditation boundary and monitors/controls the system interconnections on an
ongoing basis.
System owners must use the methodology for documenting system support and interconnectivity
agreements as developed in accordance with SBA Interconnect Security Agreement Guidelines
and NIST Special Publication 800-47, Security Guide for Interconnecting Information
Technology Systems.
4. Plan of Action and Milestones (POA&M) (CA-5) - Common
All SBA FISMA information systems must develop, update, and maintain a POA&M using an
SBA provided tracking tool. The POA&M must document the planned, implemented, and
evaluated remedial actions to correct deficiencies noted during the assessment of the security
controls and to reduce or eliminate known vulnerabilities in the system. The POA&M updates
are based on the findings from security control assessments, security impact analyses, findings in
OIG reviews, and continuous monitoring activities. The POA&M must describe the weakness to
be addressed and the personnel responsible for the implementation of the solution. At a
minimum, POA&Ms must be created in accordance with Appendix J, SBA’s POA&M Process.
5. Security Authorization (CA-6) - Common
The Security Authorization Process (formerly referred to as the Certification and Accreditation
(C&A) process) is designed to satisfy the OMB A-130, Appendix III and FISMA requirements
that executive agencies periodically review and the security controls in their information
systems, and authorize system processing prior to operations, and periodically thereafter. At a
minimum, POA&Ms must be created in accordance with Appendix M, Assessment and
Authorization Process.
6. Continuous Monitoring (CA-7) - Hybrid
SBA must continuously monitor its systems to ensure on-going security. Continuous monitoring
activities must include configuration management and control of information system
components, security impact analyses of changes to the system, ongoing assessment of security
controls (annual assessments), vulnerability scanning, developer security testing, the
maintenance and review of the Plan of Action and Milestones (POA&M), and status reporting.
An effective continuous monitoring program results in ongoing updates to the information SSP,
the security assessment report, and the POA&M.
SOP 90 47 3
Effective Date: August 28, 2012 43
SBA requires an annual assessment for systems not undergoing the authorization process.
System owners are required to test a third of all controls and enhancements annually using a
NIST SP 800-53 based assessment process. All security controls must be assessed over the three
year accreditation cycle. All SBA system controls and enhancements must be assessed as part
of:
a. Security authorization or re-authorization;
b. Meeting the FISMA requirement for annual assessments;
c. Continuous monitoring; and
d. Testing/evaluation of the information system as part of the system development life cycle
process.
SBA requires ongoing automated monitoring and monthly assessments, as part of the continuous
monitoring process, for the following controls:
a. Vulnerability Management;
b. Patch Management;
c. Configuration Management;
d. Event management;
e. Incident Management;
f. Malware Detection;
g. Asset Management;
h. Network Management; and
i. License Management.
All system controls must be assessed during the security authorization and assessment process.
SBA must use the latest version of NIST SP 800-53a as a security assessment framework.
SOP 90 47 3
Effective Date: August 28, 2012 44
CHAPTER 5 – Configuration Management
1. Configuration Management Policies and Procedures (CM-1) - Common
Configuration management (CM) is the process of managing change in hardware, software,
firmware, documentation, etc. As the nature of change requires both an initial state and an altered
state, documenting these modifications is vitally important.
Configuration management shall apply to all systems, subsystems, and components of SBA,
including the documentation describing the information system. Configuration management
control begins with base-lining the requirements documentation and ends with decommissioning
of equipment or information systems.
All FISMA information systems in use at SBA must develop, implement, and maintain a
configuration management plan. The requirements in the SOP must be incorporated into each
phase of the lifecycle, (i.e., initiation, development/acquisition, implementation, operation and
disposal, for all information systems). SBA personnel must use NIST SP 800-64, “Security
Considerations in the Information System Development Life Cycle” as a guide when managing
security throughout the system’s lifecycle.
The process of configuration management ensures the systematic completion of authorized
changes to the configuration, or structure, of an item. This process consists of four steps:
Step 1: In the configuration identification step, the owner of the item to be configured defines
the configuration baseline -- what the item is (e.g., system specifications, system or program
documentation, or the set-up of a hardware or software component of a system), and assigns the
item a unique identifier such as a number or title and version number.
Step 2: The configuration change control step requires that changes to an item under
configuration management (identified in step 1) are authorized by a management official in
writing, and are tested before implementation. SBA’s Chief Technology Officer (CTO) or
system owner of a vendor operated SBA information system must also make provisions for
processing emergency changes. The CTO or system owner must ensure that the authorizing
official approves significant changes and directs system re-certification/re-accreditation if
deemed necessary.
Step 3: The configuration status accounting step provides for the “cradle-to-grave” tracking of
the authorized change from the point of management authorization to the
point of testing, and final acceptance and implementation of the changed item into the production
computing environment.
SOP 90 47 3
Effective Date: August 28, 2012 45
Step 4: The configuration auditing step provides for the tracing of modifications to existing
system or documents configurations to authorized changes.
Effective configuration management plans must address:
a. Identification of information system components, programs, code, libraries, and
architectural elements that require inclusion in the configuration management process;
b. The processes whereby changes are requested, approved, implemented, and tested;
c. The documentation requirements associated with the change request process; and
d. The capability to record and report on the configuration baselines associated with each
configuration item at any moment of time.
Each CM plan and the extent of actual compliance with the plan and other relevant
documentation must be evaluated as part of the risk management, continuous monitoring and
security assessments for the resource. The SSP and other relevant documentation must be revised
as appropriate when the configuration has been changed. The responsibility for the configuration
management planning process within an information system is generally handled by a
configuration manager.
Configuration changes must be approved and documented. The CCB must be notified of any
deviations from the documented CM Plan. Program area or information system officials must
establish, implement, and enforce configuration management plans and change management
controls in accordance with this standard and applicable NIST guidelines.
2. Baseline Configurations (CM-2) - Hybrid
A standard baseline configuration provides information about a particular component’s makeup
(e.g., the standard software load for a workstation or notebook computer including updated patch
information) and the component’s logical placement within the information system architecture.
The baseline configuration also provides the organization with a well-defined and documented
specification to which the information system is built and deviations, if required, are documented
in support of mission needs/objectives.
SBA information system owners are required to establish or adhere to documented baseline
configurations for components including, but not limited to hardware, software, operating
systems, and applications. The CTO will develop, document and maintain under configuration
control, a current baseline configuration for all SBA general support systems and applications
residing on the general support systems. CORs must ensure that vendors develop, document,
and maintain under configuration control, a current baseline configuration for all SBA owned
information systems.
In the event that NIST approved configuration specifications for a component or operating
system are available, these must be adapted to the extent possible while maintaining system
operability. If NIST approved configuration specifications are not available, it is appropriate to
create a standard baseline based on common and best practices. This SBA developed baseline
must be documented, tested and approved.
In order to facilitate the protection of SBA owned systems, hardware and software configurations
shall be formally managed and controlled through secure system configuration checklists (also
SOP 90 47 3
Effective Date: August 28, 2012 46
referred to as configuration guides or benchmarks). The checklists help to establish settings that
minimize the security risks associated with each system’s hardware and software. Such
checklists, when combined with well-developed processes and procedures, can markedly reduce
the vulnerability exposure of an organization. Baseline configuration sources are as follows:
a. http://nvd.nist.gov/fdcc/index.cfm
b. http://csrc.nist.gov/checklists/SBAs/SP_800-70_20050526.pdf
c. http://www.cisecurity.org/
d. https://iase.disa.mil/techguid/stigs.html
e. NIST Special Publication 800-44, Guidelines on Securing Public Web Servers
For Medium and High impact systems, SBA will review and update baseline configurations at
least annually or when required due to significant changes in the configuration. Older versions
of the baseline will be retained as necessary to support rollbacks.
For Medium impact systems, SBA will develop and maintain a black list of software not
authorized to execute on the system, and employ an “allow all, deny by exception” policy to
identify software authorized on the system. CORs must ensure that vendors retain older version
of baseline configurations as necessary to support rollback activities. CORs must also ensure that
vendors develop and maintain a list of software programs not authorized to execute on SBA
owned information systems.
High impact systems will use automated mechanisms to maintain an up-to-date, complete,
accurate, and readily available baseline configuration of the information system. Additionally
SBA will develop and maintain a white list of software authorized to execute on the system and
employ a “deny all, allow by exception” policy to identify software authorized on the system.
CORs must ensure the following:
a. Vendors review the baseline configuration annually and update the baseline configuration
when the ECCB approves a change to the baseline configuration such as installing new
components or implementing upgrades to SBA owned information systems;
b. Vendors employ automated mechanisms to maintain an up to date, complete, accurate,
and readily available baseline configuration for SBA owned information systems;
c. Vendors retain older versions of baseline configurations as necessary to support rollback
activities;
d. Vendors develop and maintain a list of software programs authorized to execute on SBA
owned information systems;
e. Vendors maintain a baseline configuration for development and test environments that is
managed separately from the operational baseline configuration for SBA owned
information systems.
Finally, SBA will maintain a baseline configuration for development and test environments that
is managed separately from the operational baseline configuration.
3. Configuration Change Control (CM-3) – Common
Change control involves the evaluation, coordination, and approval/disapproval of proposed
changes to the configuration of information systems. Formal control of the configuration of an IT
SOP 90 47 3
Effective Date: August 28, 2012 47
resource begins with the definition and approval of the design requirements baseline and
continues through the IT resource/system's life cycle. Once an IT resource baseline is
determined, all change requests must be presented in writing and require approval by an
Enterprise Change Control Board (ECCB). A separate request is required for each change.
Change requests must:
a. Define the affected baseline items;
b. Include a description of the change along with the justification for the change; and
c. Provide costing and schedule detail, and a pre-impact assessment of change.
There are three basic types of changes: maintenance changes, emergency changes, and major
changes.
A maintenance change is routinely performed, or it may be a major change that is planned
and scheduled. It may involve upgrading hardware, updating a software application, or
installing new software.
An emergency change is a change needed as a result of an unexpected interruption in
service, new or critical security requirements, or an imminent risk affecting the functionality
of the information system. An emergency requires alterations outside of the established
change procedures.
A major change may be either routine or emergency. Major changes can be defined as those
that would cause a significant alteration in the accreditation boundary, FIPS categorization,
functionality, or security posture of an information system. A major or significant change to a
resource affects the resource accreditation status, and must be handled accordingly. The
system owner must be involved in any changes designated as major changes. More
information regarding major changes is documented in RA-2.
The implemented change process shall ensure proposed changes are properly identified,
prioritized, documented, coordinated, evaluated, and adjudicated. Changes shall be scheduled so
as to cause minimal disruption to normal operations.
The change control process shall ensure that production program changes are periodically
reviewed by appropriate organization officials to determine whether access controls and change
controls are being followed.
The system owner ensures the integrity of major application and operating system software by
implementing documented, effective configuration management procedures, including:
a. Restricting the ability to change software (update, upgrade, install and uninstall) to only
those authorized by the system owner;
b. Auditing all changes and maintaining a copy of the audit in a secure manner;
c. Maintaining a copy of changes (old and new software) in a secure manner; and
d. Testing all changes on non-live data prior to deploying changes in a live environment.
4. Security Impact Analysis (CM-4) - Hybrid
Any proposed changes to an SBA information system in use must be evaluated to determine its
effect on the security posture of the system. A security impact analysis must be performed prior
to the implementation or approval of the change.
SOP 90 47 3
Effective Date: August 28, 2012 48
There shall be a technical security lead on any SBA Change Control Boards whose primary
objective is to evaluate the effect of the proposed change on the information system’s security
structure. This individual shall:
a. Conduct a security impact analysis to assess the effects of the system changes prior to
change implementation and, as part of the change approval process;
b. Check the security features to confirm that the features are still functioning properly after
the system is changed (including upgrades and modifications); and
c. Audit activities associated with configuration changes to the information system to
ensure that no security related changes were evaluated or implemented without the
involvement of the technical security lead.
5. Access Restrictions for Change (CM-5) - Common
Only qualified and authorized individuals may obtain access to information system components
for purposes of initiating changes, including upgrades, and modifications. Access restrictions
shall be constructed in accordance with the concept of least privilege and proper segregation of
duties.
6. Configuration Settings (CM-6) - Common
Configuration settings are the configurable parameters of the information technology products
that compose the information system. SBA requires that information systems are configured in
the most restrictive manner possible while still permitting full system functionality. The
requirement of CM-2, if followed, will satisfy the requirements of this control.
7. Least Functionality (CM-7) - Hybrid
All information systems and information system components in use at SBA must be configured
to enforce the principal of least functionality. The concept of “least functionality” is that all
functions, ports, protocols, and/or services are disabled unless their use is explicitly required by
the information system. A corollary of “least functionality” is “least privilege (AC-6), which
applies to the rights of users to initiate action in the information system. Employing least
functionality often involves altering “out of the box” configuration settings, which are frequently
established to allow most functionality.
8. Information System Component Inventory (CM-8) - Hybrid
All SBA information systems in use, either SBA managed or contractor managed, must maintain
a component inventory of all hardware required to operate the information system as determined
by its assessment and authorization boundary. The inventory must consist of all components of
the information system, including hardware and software licenses. The information system
component inventory must include the following:
a. System/component owner
b. Manufacturer
c. Model or version number
d. Serial number
e. Software license information
SOP 90 47 3
Effective Date: August 28, 2012 49
f. Internal inventory labels (if internal labels are used on the hardware)
The information system component inventory must be reviewed at least annually, preferably in
conjunction with contingency plan testing to ensure its accuracy.
9. Configuration Management Plan (CM-9) – Hybrid
The configuration management plan describes how:
a. To move a change through the change management process;
b. To update configuration settings and configuration baselines;
c. To maintain the information system component inventory is maintained; and
d. To control development and test operational environments.
All SBA system owners must develop and implement a configuration management plan for
their systems. These plans must address roles, responsibilities, and configuration management
processes and procedures.
SBA will follow the Federal Risk and Authorization Management Program (FEDRAMP)
guidelines to protect information systems that may be operated by a cloud service provider and
NIST guidelines for managing security and privacy issues in cloud computing, as stated in NIST
Special Publication 800-144. Under this guidance, it is stated that an organization is responsible
for ensuring that its selected cloud computing solution satisfies organizational security and
privacy requirements and should maintain accountability over the privacy and security of data
and applications implemented and deployed in public cloud computing environments.
SOP 90 47 3
Effective Date: August 28, 2012 50
CHAPTER 6 – Contingency Planning
1. Contingency Planning Policies and Procedures (CP-1) - Common
The Office of Management and Budget (OMB) Circular A-130 requires the development and
maintenance of continuity of support plans for general support systems and contingency plans
for major applications. An information technology contingency plan must be developed for each
major application and general support system. An executable Disaster Recovery Plan (DRP),
Information Systems Contingency Plan and Business Recovery Plan (BRP) will be developed for
each system to ensure that core business functions can be restored to full operation with
minimum downtime in the event of a disruption or disaster.
Contingency Planning will be incorporated and integrated in the system development life cycle
process for all IT systems. All SBA Contingency, Disaster Recovery Plans and Information
System Contingency plans will be tested at least annually. Within this control there are several
types of plans that need to be addressed by SBA. These plans include SBA Contingency,
Disaster Recovery Plans and Information System Contingency plans and are described below.
Type of Plans Plan Purpose Scope Plan Relationship
Business Continuity Plan
(BCP)
Provides procedures for
sustaining mission/business
operations while recovering
from a significant
disruption.
Addresses mission/business
processes at a lower or
expanded level from COOP
MEFs.
Mission/business
process focused plan
that may be activated
in coordination with a
COOP plan to sustain
non-MEFs.
Continuity of Operations
(COOP) Plan
Provides procedures and
guidance to sustain an
organization’s MEFs at an
alternate site for up to 30
days; mandated by federal
directives.
Addresses MEFs at a facility;
information systems are
addressed based only on their
support of the mission
essential functions.
MEF focused plan
that may also activate
several business unit-
level BCPs, ISCPs, or
DRPs, as appropriate.
Disaster Recovery Plan
(DRP)
Provides procedures for
relocating information
systems operations to an
alternate location.
Activated after major system
disruptions with long-term
effects.
Information system-
focused plan that
activates one or more
ISCPs for recovery of
individual systems.
Information System
Contingency Plan (ISCP)
Provides procedures and
capabilities for recovering
an information system.
Addresses single information
system recovery at the
current or, if appropriate
alternate location.
Information system-
focused plan that may
be activated
independent from
other plans or as part
of a larger recovery
effort coordinated
with a DRP, COOP,
and/or BCP.
COOP vs. ISCP – The Basic Facts Functions and Scope: COOP plans address national, primary, or mission essential functions; ISCPs address federal information systems. Authorities: COOP is mandated for federal organizations by HSPD-20/NSPD-51, FCDs 1 and 2, and the National Continuity Policy Implementation Plan (NCPIP); ISCPs are mandated for federal organizations by FISMA.
SOP 90 47 3
Effective Date: August 28, 2012 51
2. Contingency Plan (CP-2) - Hybrid
SBA requires the development of contingency plans for all systems, networks, data, business
processes, and facilities. These plans shall be delivered to SBA in both hard and soft copy and
exercised by the owner of the plan at least annually. SBA contingency plans, at a minimum,
must:
a. Identify essential missions and business functions and associated contingency
requirements;
b. Provide recovery objectives, restoration priorities, and metrics;
c. Address contingency roles, responsibilities, assigned individuals with contact
information;
d. Address maintaining essential missions and business functions despite an information
e. system disruption, compromise, or failure;
f. Address eventual, full information system restoration without deterioration of the security
measures originally planned and implemented;
g. Be reviewed annually and approved by designated officials within the organization; and
h. Contain incident response procedures consistent with SBA Incident Response
requirements.
Contingency plans must be maintained by each program area and a copy provided to OIS and
SBA’s COOP Coordinator.
For Moderate and High impact systems, SBA will coordinate contingency plans with related
plans.
For High impact systems, SBA will conduct capacity planning to determine that necessary
support exists for the contingency operations. Additionally, SBA will plan for the resumption of
essential mission and business functions within 12 hours of contingency plan activation.
3. Contingency Training (CP-3) - Common
All personnel involved in disaster recovery or contingency planning efforts shall be identified
and trained in contingency planning procedures annually or as significant changes to the plan are
made. Information system owners shall:
a. Identify key positions related to contingency recovery efforts, and ensure that recovery
team members with sufficient skills are appointed to fill those recovery roles;
b. Ensure that contingency and recovery teams are trained and knowledgeable with respect
to recovery and reconstitution efforts; and
c. Ensure that sufficient employees are trained to provide alternates for key recovery
positions.
Information systems categorized as High must incorporate simulated events into contingency
training to facilitate effective response by personnel in crisis situations.
SOP 90 47 3
Effective Date: August 28, 2012 52
4. Contingency Plan Testing and Exercises (CP-4) - Hybrid
SBA’s information system owners are responsible for ensuring that contingency and continuity
of support plans are developed and tested annually in accordance with OMB Circular No. A-130
and NIST SP 800-34, “Contingency Planning Guide for Information Technology Systems.” NIST
Special Publication 800-84 provides guidance on testing, training, and exercise programs for IT
plans and capabilities.
SBA disaster recovery teams shall test procedures annually and also when significant changes
are made to the location and/or operation of the system. The recovery team lead shall monitor the
system’s needs and ensure that procedures meet evolving demands and emerging threats.
SBA information system owners shall schedule at least annual testing for these plans. Table-top
exercises must precede live testing to ensure the written plan is executable. Any deficiencies
revealed by the tests must be corrected. The type of test and extent of testing will depend upon:
a. Criticality of Agency business functions
b. Cost of executing the test plan
c. Budget availability
d. Complexity of information system and components
Detailed information regarding the tests conducted and the outcomes obtained shall be
documented and provided to system owners and other relevant personnel following the
completion of tests.
A review of the contingency plan, and test/exercise results and corrective actions or “lessons
learned” report shall be reviewed at the completion of testing. Any required changes to the
contingency plan shall be made as a result of problems encountered during recovery efforts.
Tests of the DRP must be documented and retained throughout the authorization lifecycle. Real-
world incidents may be counted as contingency and DRP tests. The CISO must be consulted to
determine if the incident meets contingency and DRP test requirements.
Systems categorized as Moderate or High impact, SBA will coordinate contingency plan testing
with related plans.
High impact systems will be tested and the alternate processing site to familiarize personnel with
the site’s resources and capabilities to support contingency operations. Additionally the plan
must include a full recovery and reconstitution of the information system to a known state as part
of contingency plan testing.
5. Alternate Storage Site (CP-6) - Hybrid
Information system owners must ensure the integrity, security, and availability of information
system data and software. The media containing information system backups will be stored at
offsite locations which are environmentally controlled and secure, and in a state of readiness to
facilitate timely and effective recovery operations. Alternate storage sites shall be sufficiently
removed from the primary data or operations center to ensure they are not susceptible to the
same environmental hazards. The frequency of information system backups and the transfer rate
SOP 90 47 3
Effective Date: August 28, 2012 53
of backup information to the alternate storage site shall be consistent with the organization’s
recovery time objectives and recovery point objectives.
Information system management will regularly inspect system backup documentation and audit
logs to confirm that regular back-ups are being performed, and records are being kept. System
owners must ensure that potential accessibility problems to the alternate storage center are
evaluated and mitigated in the event of an area-wide disruption.
6. Alternate Processing Site (CP-7) - Hybrid
An alternate processing location shall be identified for the critical functions of SBA information
systems. A disaster recovery agreement with other facilities must provide partial or full
capabilities, as required, to run SBA’s systems until damaged systems have been repaired and
restored. This agreement provides for minimal alterations of equipment, software and hardware
required to permit transportability of work between the two facilities.
Agreements with owners of alternate processing locations, hardware and software vendors, and
any support organizations necessary shall be documented and kept on file for reference.
Software media and documentation shall be made accessible to personnel at alternate sites.
Contingency and disaster recovery plans shall be available at alternate processing sites in the
event of the loss or inaccessibility of the primary computer room.
7. Telecommunication Services (CP-8) – Common
Critical mission and business functions within SBA must be identified and documented.
A primary and an alternate telecommunication service for SBA shall be identified to support the
Information Systems and initiate necessary agreements to permit the resumption of system
operations for critical mission/business functions when the primary telecommunications
capabilities are unavailable.
In the event that the primary and/or alternate telecommunications services are provided by a
common carrier, SBA shall request Telecommunications Service Priority (TSP) for all
telecommunications services used for national security emergency preparedness (see
http://tsp.ncs.gov for a full explanation of the TSP program). Alternate or backup
telecommunications providers’ main operations centers shall be sufficiently separated from
primary service providers so as not to be susceptible to the same hazards. Any primary or
alternate telecommunications services agreements shall include:
a. Priority of service provisions in accordance with the information system or Agency’s
availability requirements;
b. Provisions to ensure that a single point of failure will not render telecommunications
inoperable; and
c. Provisions to ensure that agreed upon contingency plans are shared between the entities
and are sufficient to adequately restore telecommunications when required.
8. Information System Backup (CP-9) - Hybrid
SBA management and system owners shall determine the frequency of information system
backups and the transfer rate of backup information to alternate storage sites in a manner
consistent with the organization’s recovery time objectives and recovery point objectives. The
SOP 90 47 3
Effective Date: August 28, 2012 54
organization must protect backup information from unauthorized disclosure, depending on the
type of information residing on the backup media and the FIPS 199 impact level of the
information system using the data. Information system owners shall conduct an assessment of
risk to determine the need of encryption for backup information. Any encryption employed must
be consistent with FIPS 140 guidance, as revised.
All data stored on enterprise servers will be backed up via SBA’s enterprise backup system
according to an established schedule, commensurate with industry best practices and program
requirements. Current SBA requirements for specific data type back-ups are as follows:
Frequency Server Retention*
Daily
(incremental)
Mail 4 weeks
File 4 weeks
Database 4 weeks
Monthly
(full)
Mail 1 year
File 1 year
Database 1 year
In general, all database files must be incrementally backed up on a daily basis. Some individual
databases are backed up less frequently, per program requirements. Data stored on non-enterprise
servers will be backed up via SBA’s Backup System by special request as capacity allows. All
backup media shall be protected from unauthorized modification. Note: E-Discovery backup
information must be retained indefinitely.
Information systems categorized as Moderate or High shall undergo periodic tests of backup
media to ensure that information system data is recoverable and usable. Information systems
categorized as High must store backup information in a separate facility or in a fire-rated
container stored separately than the operational software. High systems must also use actual
backup information in the restoration of information system functions as part of contingency
plan testing.
9. Information System Recovery and Reconstitution (CP-10) - Common
All information system recovery and reconstitution efforts must include mechanisms to ensure
that the information system is restored to a known secure state. This includes:
a. Setting all relevant system parameters to secure values
b. Installing all applicable patches or security hot fixes
c. Setting security configuration settings
All system owners must ensure that appropriate system documentation, including any
instructions on secure operating procedures, is available at the recovery and reconstitution site.
All disaster recovery and contingency plan procedures shall be updated frequently and stored
both locally and at an offsite location.
Moderate and High impact systems that are transaction based, must implement transaction
recovery.
SOP 90 47 3
Effective Date: August 28, 2012 55
Additionally, for High impact systems, SBA must be capable of re-imaging system components
within 12 hours from configuration controlled and integrity protected disk images representing a
secure, operational state for the components.
SOP 90 47 3
Effective Date: August 28, 2012 56
CHAPTER 7 – Identification and Authentication
1. Identification and Authentication Policy and Procedures (IA-1) - Common
Information systems in use at SBA must create a user identification and authentication scheme
used in the system. Identification and authentication schema must adhere to applicable SBA, and
Federal policies and procedures. In some situations, two-factor authentication and identification
are required.
Identification and Authentication (I&A) mechanisms shall include provisions for uniquely
identifying and authenticating entities (i.e., users or information system processes acting on
behalf of users). These processes must:
a. Require that access to an information system be gained through the presentation of an
individual identifier (e.g., a unique token or user login identification [ID]) and
authenticator(s); and
b. Explicitly identify any user actions that can be performed prior to reliable identification
(e.g., reading a publicly available Web site).
All SBA systems must incorporate proper user identification and authentication methodology.
This includes but is not limited to:
a. Designing information systems to require passwords to be changed every 90 days;
b. Employing authentication schemes in lieu of standard passwords, as approved by the
Authorizing Official, (i.e., biometrics, tokens, smart cards, one time passwords);
c. Incorporating identification and authentication mechanisms commensurate with their
security risks and business needs for publicly accessible systems;
d. Changing all default passwords on network devices, databases, operating systems, etc.;
e. Authenticating users before resetting or distributing a password;
f. Requiring user IDs to be unique to each authorized user; and
g. Providing users the capability to change their own passwords (passwords must be set to
automatically expire every 90 days and a history of at least eight passwords must be
maintained before a password can be reused).
Additional password requirements are outlined in Appendix F - “Password Management
Guidance”.
2. I&A (Organizational and Non-Organizational Users) (IA-2/IA-8) - Hybrid
All SBA systems must uniquely identify and authenticate uses before the user can access
systems. Passwords must be used to authenticate the account user. User accounts and passwords
may not be shared between individuals. SBA requires multi-factor authentication for network
access to privileged accounts.
For Moderate and High impact systems SBA requires:
a. Multi-factor authentication for network access to non-privileged accounts
SOP 90 47 3
Effective Date: August 28, 2012 57
b. Multi-factor authentication for local access to privileged accounts
c. Replay resistant authentication mechanisms for network access to privileged accounts
In addition, High impact systems require:
a. Multi-factor authentication for local access to non-privileged accounts
b. Replay resistant authentication mechanisms for network access to non-privileged
accounts
3. Device Identification and Authentication (IA-3) - Common
The purpose of a device identification and authentication is to determine the functions or
privileges a specific device, such as another operating system, any communicating piece of
hardware, etc. can exercise on a system. In some cases, access to the device implies physical
access to the data (all storage media). Information systems in use at SBA must ensure that only
appropriate devices are allowed access to the information system. This can be accomplished by
the use of IP or MAC address identification. Only approved devices may interconnect with
information systems and IS components, and restrictions must be enabled preventing rogue
devices from accessing any portion of the information system.
4. Identifier Management (IA-4) - Common
Identifiers are the components required for identification and authentication, such as user name
and password. Appropriate identifiers must be used in order to access any SBA information
system. Examples of identifiers are outlined in the following table:
Identification Factor Description Example
Secrets: Something you
know.
Secret information known only
the user.
A password or PIN.
Tokens: Something you
have.
A physical device possessed
only by the user.
A token card or smart card.
Biometrics: Something
you are.
A unique, measurable
characteristic of the user.
Voice print verification,
fingerprint or retinal scan.
The following precautions must be taken with respect to managing information system identifiers
such as user names and passwords:
a. Passwords (other than default or one time use passwords) must never be sent via email,
regular mail, or interoffice mail;
b. User IDs and passwords must never be distributed together (i.e., same e-mail, regular
mail, interoffice mail, etc.);
c. Users must follow approved SBA procedures to request or revoke access to the
information system ;
d. Users are responsible for all actions that are taken under their Logon ID and password;
e. Users will not disclose his/her password to other people or knowingly or carelessly make
it possible for other people to access the information system using his/her Logon ID and
Password;
SOP 90 47 3
Effective Date: August 28, 2012 58
f. Users will not write passwords down;
g. Users are aware that their assigned Logon ID and password serve as their electronic
signature for all activity while active in the information system;
h. Users must report any known or suspected breaches of user name and password or token,
using the Incident Response processes in place for the information system; and
i. Passwords must not be stored in forms (i.e., Windows dialog boxes, web forms, etc.).
5. Authenticator Management (IA-5) - Hybrid
Information system authenticators include, for example, tokens, PKI certificates, biometrics,
passwords, and key cards. SBA users issued system authenticators must take security precautions
to prevent the loss or misuse of the authenticators.
The following precautions must be taken with respect to managing information system
authenticators:
a. Users must take safety precautions with all physical tokens issued, for example,
SecurIDs, password dongles, PKI certificates or USB keys. These must be securely
stored and locked when not in use;
b. Tokens may only be used by the authorized personnel to whom they have been issued.
c. In the event that a physical token is lost or stolen, this must be reported immediately
using SBA incident response reporting requirements;
d. Issued authenticators, such as tokens, key cards, or USB keys, must be documented and
tracked;
e. Information system owners must be able to tie an authenticator to a specific user, and
vice versa; and
f. When issued tokens, users must sign “Rules of Behavior” indicating their required
responsibilities with respect to managing and safeguarding the tokens.
Electronic authentication methods to provide services to citizens must comply with OMB
Memorandum 04-04, E-Authentication Guidance, and associated implementation requirements
in NIST Special Publication 800-63, Electronic Authentication Guideline.
6. Authenticator Feedback (IA-6) - Common
SBA information system passwords and other authentication information must be hidden (e.g.,
when a user types in a password, asterisks or some other meaningless symbol is displayed). This
helps prevent bystanders or unauthorized people from observing the passwords.
7. Cryptographic Module Authentication (IA-7) - Common
Any cryptographic modules in place at SBA must be compliant with FIPS 140-2, as amended.
NIST performs testing on a variety of cryptographic systems and methods to assure they meet a
minimum level of effectiveness. NIST maintains a list of cryptographic modules that have been
independently verified and certified as meeting a Federal standard of effectiveness. The
following cryptographic module authentication guidelines must be followed:
a. Ensure the activation data will be a password known only to the user
SOP 90 47 3
Effective Date: August 28, 2012 59
b. Ensure the cryptographic module shall be FIPS validated
c. Ensure the unencrypted copy of the authentication key shall be erased after each
authentication
SOP 90 47 3
Effective Date: August 28, 2012 60
CHAPTER 8 – Incident Response
1. Incident Response Policies and Procedures (IR-1) - Common
The Federal Information Security Management Act (FISMA) of 2002 requires Federal agencies
to establish incident response and handling capabilities. The law also requires incidents to be
reported to the United States Computer Emergency Response Team (US-CERT) (http://www.us-
cert.gov) at the Department of Homeland Security (DHS).
SBA requires that all SBA information systems be covered by an incident response capability.
Also, each SBA program area supported by another contractor hosted system must have a written
agreement for the necessary support to effectively monitor, respond, report, and prevent
incidents within the operating office.
Confirmed and/or suspected incidents involving the potential loss or compromise of PII must be
reported as a CAT-1 incident and reported to US-CERT within one (1) hour. All incidents
involving sensitive data or PII in electronic or physical form must be reported. (See SOP 90 50,
Breach Notification Response Plan.) The table below reiterates the US-CERT incidents,
categories and reporting timeframes that apply to SBA’s environment:
Category Name Description Reporting Timeframe
CAT 0 Exercise/Network Defense Testing
This category is used during state, federal, national,
international exercises and approved activity testing of internal/external network defenses or responses.
Not applicable; this category is for
each agency's internal use during exercises.
CAT 1 Unauthorized Access
In this category, an individual gains logical or
physical access without permission to a federal
agency network, system, application, data, or other
resource
Within one (1) hour of discovery/detection.
CAT 2 Denial of Service (DoS)
An attack that successfully prevents or impairs the
normal authorized functionality of networks, systems
or applications by exhausting resources. This activity
includes being the victim or participating in the DoS.
Within two (2) hours of
discovery/detection if the successful
attack is still ongoing and the
agency is unable to successfully
mitigate activity.
CAT 3 Malicious Code
Successful installation of malicious software (e.g.,
virus, worm, Trojan horse, or other code-based
malicious entity) that infects an operating system or
application. Agencies are NOT required to report
malicious logic that has been successfully quarantined by antivirus (AV) software.
Daily
Note: Within one (1) hour of
discovery/detection if widespread across agency.
CAT 4 Improper Usage A person violates acceptable computing use policies. Weekly
CAT 5 Scans/Probes/ Attempted Access
This category includes any activity that seeks to
access or identify a federal agency computer, open
ports, protocols, service, or any combination for later
exploit. This activity does not directly result in a
compromise or denial of service.
Monthly
Note: If system is classified, report within one (1) hour of discovery.
CAT 6 Investigation Unconfirmed incidents that are potentially malicious
or anomalous activity deemed by the reporting entity to warrant further review.
Not applicable; used to categorize a
potential incident that is currently being investigated.
SOP 90 47 3
Effective Date: August 28, 2012 61
2. Incident Response Training (IR-2) - Common
All SBA incident response training shall include end user training that includes identification and
reporting of suspicious activities. Users will be trained annually as part of the Computer
Security Awareness Training.
In addition, incident response personnel must be designated by program area officials, trained
annually and must understand their responsibilities in the organization’s incident handling
process. Training must include, but is not limited to:
a. US-CERT categorizations and related responses;
b. Monitoring and review activities;
c. Escalation procedures;
d. Prioritization, triage, containment, evidence handling; and
e. Reporting requirements.
Training must be developed and conducted. Training records must be retained in accordance
with AT-3 and AT-4.
For systems designated as High impact, SBA will incorporate simulated events into incident
response training to facilitate effective response by personnel in crisis situations. In addition,
SBA will employ automated mechanisms to provide a more thorough and realistic training
environment.
3. Incident Response Testing and Exercises (IR-3) - Hybrid
Information systems in use at SBA must ensure that the incident response capability is tested at
least annually using defined tests and exercises to determine the effectiveness of the process.
Testing can involve tabletop incident response exercises or simulated and real-life scenarios. If
appropriate, annual incident response testing may be incorporated with annual contingency plan
testing. Incident response test scenarios must include:
a. Assigning the incident the appropriate US-CERT categorization;
b. Determining the involvement of the appropriate staff;
c. Determining the extent of the breach and identifying any corollary vulnerabilities;
d. Determining the appropriate response to the incident;
e. Identifying any policy gaps or corrections needed to existing incident response policies
and procedures;
f. Documenting decisions made and actions taken with response to the incident;
g. Lessons learned;
Incident response testing and exercises must be documented and the documentation must be
retained in accordance with AT-2. This will assist in handling future incidents.
For High impact systems, SBA will employ automated mechanisms to more thoroughly and
effectively test the incident response capability.
SOP 90 47 3
Effective Date: August 28, 2012 62
4. Incident Handling (IR-4) - Common
All SBA personnel must be aware of the proper escalation of potential incidents. All potential
incidents must be reported using the guidelines outlined in IR-6, Incident Reporting. Incident
handling must be coordinated with the SOC and in accordance with SOC Incident Handling
guidelines.
The SOC incorporates lessons learned from ongoing incident handling activities into incident
response procedures, training, and testing/exercises, and implements the resulting changes
accordingly. All incident handling activities shall be conducted in accordance with SOP 90 50
“Breach Notification Response Plan.”
In Moderate and High impact systems, SBA will employ automated mechanisms, such as an
online incident management system, to support the incident handling process.
5. Incident Monitoring (IR-5) - Common
SBA information system owners must develop and implement processes for assessing the current
and potential business impacts of incidents. SBA information system owners must also employ
an effective means of collecting, analyzing, and reporting on irregularities that may signify
incidents.
Consistent reviews and testing of security controls provide valuable information about an IT
resource, and are mandated by SBA and federal policy and guidelines. Monitoring provides
oversight and helps verify the continued effectiveness of the security controls on an on-going
basis. Results from monitoring must be reviewed routinely as part of a documented process, in
accordance with policies set forth in the Auditing and Monitoring section of this SOP. The
results of the review and any remediation or corrective actions must be documented and reported
to the authorizing official. This information can be useful in handling IT security incidents.
SBA incident monitoring shall ensure that the following are taking place:
a. Review and handling of incident reports;
b. Review of records of information system activity;
c. Investigation of security violations, security incidents, and suspicious activities (e.g.,
failed logon attempts, other failed access attempts, questionable activities, etc.) and report
results appropriately; and
d. Definition of appropriate parameters for the response of security incidents.
High impact systems require automated mechanisms to assist in the tracking of security incidents
and in the collection and analysis of incident information.
6. Incident Reporting (IR-6) – Common
All SBA employees will report all suspicious computer related activities on SBA systems
immediately upon detection to the responsible system owner, program ISSO, CISO or helpdesk
personnel. All such reports shall generate investigation and determination of whether an incident
has occurred or is in process.
Moderate and High impact systems require automated mechanisms to assist in the reporting of
security incidents.
SOP 90 47 3
Effective Date: August 28, 2012 63
7. Incident Response Assistance (IR-7) - Common
The SOC is the central point of contact for computer security and PII related incidents. The SOC
may assist SBA personnel with resolving incidents. These actions may include:
a. Securing resources and/or promoting security and privacy data awareness to avoid future
events;
b. Working with IT users, security officers, system administrators, and managers to respond
to computer security events; and
c. Acting as the primary conduit for passing computer security and PII related incidents to
the OIG for law enforcement actions, both within and outside the Agency.
For Moderate and High impact systems, SBA will employ automated mechanisms to increase the
availability of incident response information and support.
8. Incident Response Plan (IR-8) – Common
The CISO will develop an Agency-wide incident response plan that covers the following:
a) A roadmap for implementing its incident response capability;
b) Definition of reportable incidents;
c) Metrics for measuring the incident response capability within the organization;
d) List of the resources and management support needed to effectively maintain and mature
an incident response capability; and
e) Distribution of copies of the incident response plan to system owners and incident
response personnel.
SOP 90 47 3
Effective Date: August 28, 2012 64
CHAPTER 9 - Maintenance
1. System Maintenance Policies and Procedures (MA-1) - Common
SBA is responsible for the maintenance of laptops, desktop printers, network computers, shared
printers, fax machines, and any other information system components residing within SBA’s
infrastructure. Information system owners are responsible for ensuring ongoing maintenance of
operating systems and system components within the assessment and authorization boundary of
the information system. All computer systems and system components within SBA must receive
routine maintenance by qualified personnel to ensure continued operability and security. If
Agency sensitive information and PII are compromised due to a system owner’s failure to ensure
the proper safeguards are in place, disciplinary action will be taken.
In the event that an information system is government owned but contractor operated, SBA must
ensure that appropriate system maintenance is provided for the information system components
managed by the vendor; and the vendor must make the assets available for inspection upon
request. Maintenance obligations on the part of the vendor must be contractually specified.
Contractors found in non-compliance of these policies and procedures will be removed from the
contract. (See document titled “Contract Security Language” for additional information.)
2. Controlled Maintenance (MA-2) - Hybrid
All maintenance activities performed on SBA information system components shall be
conducted in a controlled manner. This includes routine, scheduled maintenance and emergency
repairs; whether performed on site or remotely. If the removal of equipment from the premises is
required, the appropriate approval must be granted and documented. In the event that equipment
removal is required, information system owners must ensure that any and all sensitive data and
PII are purged from the information system in accordance with media protection guidelines.
System owners must provide changes in writing to the appropriate program area.
3. Maintenance Tools (MA-3) - Hybrid
Any and all maintenance tools managed by a third-party vendor or contractor that are brought
into SBA’s environment must be evaluated and approved by appropriate staff personnel prior to
implementation to ensure that they are free from unauthorized modifications (such as
configuration changes, software that implements automatic configuration changes to the
evaluated equipment, etc.) or are prevented from performing any unauthorized activities, such as
data copying or modification. Maintenance tools include, for example, diagnostic and test
equipment used to conduct maintenance on the information system. Any maintenance tool
connected to an information system within SBA must be free of malicious code prior to
connection.
Any maintenance equipment with the ability to store or retain information shall be monitored to
ensure that no information from the information system component is transferred to the media.
Any data transferred for the purposes of diagnosis or evaluation will be purged from the
maintenance equipment prior to the equipment’s removal from SBA’s premises.
4. Non-Local Maintenance (MA-4) - Hybrid
Remote maintenance shall be performed only by authorized individuals using government
furnished equipment. Any connections for the purposes of remote maintenance must follow
SOP 90 47 3
Effective Date: August 28, 2012 65
SBA identification and authentication procedures. All activities performed during remote
maintenance operations must be logged, monitored, and reviewed. Any encryption securing a
remote maintenance connection must be compliant with FIPS 140, as revised.
Information systems providing remote maintenance or diagnostic services must implement a
level of security at least as high as that implemented on the system being serviced, unless the
component being serviced is removed from SBA’s information system and sanitized before the
service is performed and the security of which is ensured before being reconnected to the
information system. Remote personnel will be identified prior to system access.
Remote maintenance service provided by non SBA personnel shall have required security
precautions Documented in contractual agreements. Remote operational maintenance performed
by non-SBA personnel will be actively monitored by system owner or qualified SBA personnel.
5. Maintenance Personnel (MA-5) - Hybrid
Only authorized personnel may perform maintenance on an SBA information system. All
external maintenance personnel must be authenticated through pre-planned appointments and ID
checks. Maintenance personnel must have appropriate access authorizations to the information
system when maintenance activities allow access to organizational information, or could result in
a future compromise of confidentiality, integrity, or availability. Maintenance personnel
requiring access to IT restricted spaces must conform to any applicable visitor and escort
policies. Maintenance personnel without proper identification and authorization will not be
provided access to SBA systems.
When maintenance personnel do not have needed access authorizations, organizational personnel
with appropriate access authorizations must supervise maintenance personnel during the
performance of maintenance activities on the information system.
6. Timely Maintenance (MA-6) - Hybrid
All information system components in use at SBA shall be serviced and maintained according to
the manufacturer’s recommended guidelines. Information systems shall be patched and updated
according to guidelines put forth in the configuration management section and in accordance
with manufacturer’s timeframes. In the event that an information system or information system
component is no longer supported by the manufacturer’s support plans, that system or
component shall be replaced or upgraded to ensure SBA’s continued ability to maintain security.
Systems which cannot be upgraded to current standings due to specialized software constraints
will be managed as a stand-alone system and disconnected from SBA’s enterprise until other
means of safety mechanisms are implemented. These systems will be documented and provided
to the program area.
SOP 90 47 3
Effective Date: August 28, 2012 66
CHAPTER 10 – Media Protection
1. Media Protection Policy and Procedures (MP-1) - common
All media, regardless of format, needs to be protected using measures commensurate with the
sensitivity of the data on the media. Media requiring protection includes diskettes, magnetic
tapes, external/removable hard drives, flash/thumb drives, compact disks, digital video disks,
etc.; and non-digital media (e.g., paper, microfilm, etc.).
This also applies to portable and mobile computing devices with storage capability (e.g.,
notebook computers, tablets, cellular telephones, etc.). SBA personnel should consider
employing a FIPS 140 cryptographic mechanism on personal storage devices.
OIG has overall responsibility for accessing, processing, transmitting, storing, safeguarding and
disposing of all other formats of Agency classified information (including cryptographic).
(Reference SOP 90 22 5b, Chapter 8 “Classified Information and OSO.”)
Applicable privacy requirements, system risk assessments and FIPS 199 system categorizations
shall be considered in determining the sensitivity level of the information stored on media
devices. Appropriate identification and markings will be on the face of each piece of classified
media.
If transporting or receiving data containing sensitive data or PII follow SBA’s encryption policy
located at the following link: http://yes2007.sba.gov/offices/officeofcio/fits/Shared
Documents/SBA Instructions for Encrypting and Emailing Files containing PII.DOCX
2. Media Access (MP-2) - Hybrid
SBA must ensure that only authorized users can access information system media. Protections
can include, but are not limited to, physical protection (e.g., locked cabinets to keep disks and
tapes in, locked computer rooms with controlled access, etc.) and electronic protection (e.g.,
digital encryption). The level of protection needed and rigor of protection will be determined by
the sensitivity of the data. For example, media containing information determined by the
organization to be in the public domain has less need to be protected than sensitive materials
such as PII (i.e., a document that has a print-out of a publicly released report needs less
protection and care than a form with someone’s Social Security Number).
Moderate and High impact systems require restricted access to media storage areas and to audit
attempts to access and access granted.
3. Media Marking (MP-3) - Common
Media marking must be applied to media from all Moderate and High-impact systems. Marks
shall include a notification on media distribution limitations, handling caveats, and applicable
security markings of the information. The labeling of the data should correlate to the sensitivity
of the data (e.g., labeling is not required for media containing information in the public domain
or publicly releasable).
Marking is generally not required for media containing information determined by the
organization to be in the public domain or to be publicly releasable.
SOP 90 47 3
Effective Date: August 28, 2012 67
4. Media Storage (MP-4) - Common
SBA must keep all media related to a moderate or high impact system securely stored. The
media must be stored in an area where the physical and procedural protections provided are
sufficient to protect the information and/or information system. The protection of the data should
correlate to the sensitivity of the data (i.e., FIPS 199 Security Categorization). This control is not
applicable to low impact system.
5. Media Transport (MP-5) - Common
Media transport guidance must be applied to Moderate and High impact systems. This control is
not applicable to low impact systems. SBA media must be protected during transport outside of
protected and secure areas (e.g., backup tapes that leave the facility that are picked up by an
authorized bonded media storage company and transported to an offsite facility in a locked
container). Appropriate encryption (see SC-12 and SC-13 for details) must be used to protect
digital media. The protection of the data should correlate to the sensitivity of the data (i.e., FIPS
199 Security Categorization). SBA must record when media is transported and keep copies of
their information system media transport records for at least three years. SBA must keep records
of media transportation procedures for three years.
SBA processes all types of sensitive information and PII and it is essential that this information
is properly handled and protected. PII is considered sensitive but unclassified (SBU)
Information. Careless handling and transporting PII information puts SBA at risk.
SBA policy prescribes specific procedures for the transport of PII. When Physical Transport is
necessary:
a. Encrypt portable media containing PII;
b. Use NIST approved encryption method;
c. Double wrap portable media;
d. Transport by Postal Service or another authorized delivery service;
e. Transmit decryption key separately via certified mail;
f. Mark physical documents containing PII: “Sensitive But Unclassified / Sensitive Security
Information;
g. Disseminate on a Need-to-Know Basis Only;
h. Double wrap documents; and
i. Transport by Postal Service or another authorized delivery service.
Portable media must be double-wrapped in an opaque package or container that is sealed
sufficiently to prevent inadvertent opening and is able to show signs of tampering. The package
must be sent via a certified carrier with the ability to track pickup, receipt, transfer, and delivery.
Portable media may be transmitted by interoffice mail or briefcase provided it is double-wrapped
to afford sufficient protection against inadvertent or unauthorized access.
6. Media Sanitization and Disposal (MP-6) - Common
Media sanitization is the process for removing sensitive data and PII from storage media (such as
desktops, laptops, external storage devices, mobile devices, etc.), with reasonable assurance that
SOP 90 47 3
Effective Date: August 28, 2012 68
the data cannot be retrieved and reconstructed. Data that has been improperly or unsuccessfully
removed from media could be recreated by attackers or by unauthorized individuals. All of the
residual magnetic, optical, or electrical representation of data that has been deleted from the
media must not be easily recoverable. System owners shall ensure all systems are certified as
sanitized prior to surplus or decommission.
Disposal is the transfer of computer media and equipment to a government agency other than
SBA, donation, destruction, or land fill. A degausser is a commercially available device used to
remove data from magnetic storage mediums by using powerful magnets.
The security concern regarding media sanitization and disposal resides not in the media, but in
the information. If not handled properly, release of these media could lead to an unauthorized
disclosure of information. The minimum protection of the system should correlate to the
sensitivity of the data (i.e., FIPS 199 Security Categorization). Media sanitization is one key
element in assuring confidentiality. The concern with media sanitization includes hard-copy
media (e.g., paper printouts, type ribbons, etc.) and soft-copy media (i.e., electronic versions of
data left on hard drives, USB thumb drives, CDs, etc.).
Regardless of the perceived sensitivity of the data, all SBA magnetic media must be sanitized by
degaussing or destroyed before disposal. Note: Hard disk drives are rendered permanently
unusable by degaussing. Hard disk drives should only be degaussed if they are no longer needed,
are technically obsolete, or are already damaged. Other magnetic media can be reused after
degaussing, but may require reformatting.
Degaussing may be accomplished by the Computer room if it possesses a degausser, or by a
contractor certified to perform media disposal. Media that has been degaussed can be disposed of
by SBA’s Computer Room Computer Room Manager or SBA-designated contractors.
Degaussing is the minimum requirement prior to disposal. Non-magnetic media (i.e., CDs,
DVDs, paper copies of Documents) shall be sanitized by using a shredder; after which they can
be disposed of in regular trash. More information on disposal of controlled information can be
found in NIST SP 800-88, Guidelines for Media Sanitization.
SBA has developed AD Form 112 to track unserviceable, lost, stolen, damage or destroyed
property, including media. SBA Directive 3440.2, Disposal of SBA Computer room Computer
Room Media and Equipment Policy, provides guidance on how computer room equipment must
be disposed of. The guidance states that “All Computer Room media and computer equipment
will be sanitized prior to reuse or disposal.”
The policies for disposal of media used in the computer Room are as follows:
a. All Computer Room media will be sanitized prior to reuse or disposal;
b. Media must be sanitized within 90 days after being removed from service;
c. Hard drives will be overwritten with a commercially available program which writes
random characters over the entire hard drive, making data recovery impossible;
d. Tapes, other cartridges, or removable magnetic media will be degaussed, formatted, or
completely erased prior to reuse within SBA;
e. All data on any storage media must be sanitized prior to disposal;
f. Media shall not be transferred externally until degaussed, overwritten, or destroyed; and
SOP 90 47 3
Effective Date: August 28, 2012 69
g. Media will be considered to contain sensitive data or PII and be handled as such.
The National Security Agency (NSA) also maintains and regularly updates a list of evaluated
products that will sanitize, destroy or dispose of media containing sensitive or classified
information commensurate with the minimum level security required for each. (Please access:
http://www.nsa.gov/ia/government/mdg.cfm?MenuID=10.3.1.) The following is a Media
Sanitization Decision Matrix suggested in NIST SP 800-88, Guidelines for Media Sanitization.
The actual sanitization and disposal decisions must reflect the security categorization of the data.
For a matrix of appropriate disposal methods for the different types of media, see Appendix A,
Mediation Sanitation.
SOP 90 47 3
Effective Date: August 28, 2012 70
CHAPTER 11 – Physical and Environmental Protection
1. Physical and Environmental Policies and Procedures (PE-1) - Common
SBA physical and environmental security controls must be commensurate with the level of risk
and must be sufficient to safeguard IT resources against possible loss, theft, destruction,
accidental damage, hazardous conditions, fire, malicious actions, and natural disasters.
SBA is responsible for coordinating the physical security requirements of their infrastructure
resources, including all IT restricted space that includes computer facilities,
telecommunications/computer rooms to include the Network Operations Center (NOC) sensitive
compartmented information facilities (SCIFs) and isolation zones.
IT restricted space will be controlled directly by SBA personnel who will have the ultimate
responsibility for control of these areas. All IT restricted space will have a facility-based
Occupant Emergency Plan (OEP). New or planned specifications for IT restricted space will
contain a provision that the physical security requirements will be coordinated with the Office of
the Chief Information Officer far enough in advance during the design phase to ensure
compliance with this policy. Physical security requirements must be included in all statements
of work (SOW) and procurement requests for IT restricted space.
Information system owners at SBA must define and record an inventory of the assets to include:
a. Services Assets. For example, computing and communications services and general
utilities (e.g., heating, lighting, power, and air-conditioning)
b. Space Assets. For example, computer rooms, maintenance and workshop areas, power
supply areas and general office areas
All SBA facilities that house computing facilities, telecommunications/computer rooms to
include the security and network operations centers must provide a level of physical security
commensurate with that designation. Devices in these facilities that process or access sensitive
data on a recurring basis will be protected in accordance with minimum security protection
standards.
2. Physical Access Authorizations (PE-2) - Common
Secure management of access to primary computer rooms is vital to protecting SBA computer
systems and information. SBA program managers shall limit access to rooms, work areas/spaces,
and facilities that contain Agency systems, networks, and data to authorized personnel. A list of
current personnel with authorized access shall be maintained and reviewed annually to verify the
need for continued access and authorization credentials. SBA policy and processes for the
implementation of these security controls are as follows:
a. Supervisors must send an email granting approval for an HQ employee to have access to
the computer room to the HQ Helpdesk. District Directors are responsible for granting
access authority to computer rooms at SBA’s field locations and the Local Technical
Representatives (LTR) are responsible for activating/deactivating badge access. The
SOP 90 47 3
Effective Date: August 28, 2012 71
b. Lead IT specialists at SBA’s disaster centers are responsible for activating/deactivating
badge access.
c. All employees must have the appropriate security clearance before access to the computer
room is granted.
d. Computer room Access Reports will be reviewed weekly for inappropriate access.
e. Computer room Approved Personnel Access Lists will be reviewed monthly to ensure
that all persons on the Lists have been properly authorized for access per the terms of this
SOP.
f. Anyone who has not exercised his/her access privileges to one of the Agency’s computer
rooms in 90 days will be removed from the approved personnel access list.
g. Only personnel having an ongoing recurring business need will be given unescorted
access to the IT Restricted Space
h. Personnel who no longer have a business need to enter Restricted Space will immediately
be removed from the access control system
i. Entrance to the computer room will be via electronic access control with the capability of
providing an audit trail
3. Physical Access Control (PE-3) - Common
Physical access controls over SBA restricted areas must ensure the following:
a. Physical access points to sensitive facilities or restricted areas housing information
systems that process or display information during working hours must be controlled, and
must be guarded or locked during non-working hours.
b. Emergency exit and re-entry procedures must ensure that only authorized personnel are
allowed to re-enter sensitive facilities and restricted/controlled areas containing
information systems and system/media libraries after an emergency-related event (e.g.,
fire drills, evacuations, etc.).
c. Combinations or entry codes shall be changed at least annually, or whenever a person
who knows the combination departs or no longer requires access; or when the
combination has been compromised.
d. Appropriate physical protection measures shall be employed for areas that house power
transformers or distribution panels.
e. All un-issued keys or other entry devices shall be safeguarded.
f. Exterior IT Restricted Space doors will have either interior hinges or exterior hinges with
non-removable pins.
4. Access Control for Transmission Medium (PE-4) - Common
SBA information systems must ensure that physical protections applied to information system
distribution and transmission lines help prevent accidental damage, disruption, and physical
tampering. Additionally, physical protections must be designed to prevent eavesdropping or in
transit modification of unencrypted transmissions. Protective measures to control physical access
to information system distribution and transmission lines include:
SOP 90 47 3
Effective Date: August 28, 2012 72
a. Locked wiring closets;
b. Disconnected or locked spare jack; and
c. Protection of cabling by conduit or cable trays.
5. Access Control for Display Medium (PE-5) - Common
Physical access points to sensitive facilities or restricted areas housing information systems that
process or display information during working hours must be controlled, and must be guarded or
locked during non-working hours. SBA computer rooms must employ controls to prevent
physical access to information system devices that display information to prevent unauthorized
individuals from observing the display output.
6. Monitoring Physical Access (PE-6) - Common
All SBA restricted area facilities must be controlled by an intrusion detection system with central
monitoring capability maintained to current life safety standards. Personnel inside a restricted
area facility must display an Agency photo ID at all times. Closed Circuit Television (CCTV)
surveillance cameras with time-lapse video recording may be installed in SBA restricted area
facilities.
a. A physical intrusion detection system with central monitoring capability must be
employed;
b. Security personnel must physically monitor computing systems; and
c. Physical access logs must be maintained, reviewed daily and retained for 1 year.
7. Visitor Control (PE-7) - Common
General guidelines regarding visitors at SBA facilities are as follows:
a. Visitors must be kept to a bare minimum; tours by non-SBA personnel are prohibited;
b. A sign in/sign out log book is required for all escorted visitors; at a minimum the logbook
shall contain the printed identity of each visitor, visitor’s signature, agency/company
represented, purpose of visit, date/time in and date/time out;
c. Cleaning and maintenance personnel accessing restricted spaces shall be escorted at all
times by SBA employees or cleared contractor personnel;
d. Visitors, contractors, and maintenance personnel must be authenticated through the use of
pre-planned appointments and identification checks; and
e. Visitors, contractors, and maintenance personnel must be formally signed in, escorted,
and have their activities monitored when required.
8. Access Records (PE-8) - Common
Visitor access records shall be maintained for facilities containing information systems (except
for those areas within the facility officially designated as publicly accessible). Visitor access
records must include:
a. name and organization of the person visiting;
b. signature of the visitor;
c. form of identification;
SOP 90 47 3
Effective Date: August 28, 2012 73
d. date of access;
e. time of entry and departure;
f. purpose of visit; and
g. name and organization of person visited.
Visitor access records shall be reviewed at least daily. Visitor logs must be closed out at the end
of each month and reviewed by appropriate organization officials.
For High impact systems, SBA will employ automated mechanisms to facilitate the review and
maintenance of access records. Additionally a record of all physical access will be maintained
for both visitor and authorized users.
9. Power Equipment and Power Cabling (PE-9) - Common
SBA computer installation methods must protect all power and telephone cables by segregating
them from communications cables, concealing their locations, not routing them through public
areas, locking inspection points, and having alternative routing routes.
Computer rooms housing SBA equipment must ensure that the following processes are in place:
a. Separate grounding systems to prevent grounding loops; true ground versus green wire
ground;
b. Sealed cable vault entrances to facility must be remotely monitored;
c. Power filtering in UPS system;
d. Fiber enters the computer room through diverse conduits or routes (for example, if a
backhoe cuts though conduit, the network reroutes to minimize loss of;
e. Aggregate bandwidth sufficient to scale the network to meet customer's service demands
f. Uninterruptable power;
g. All cable runs located under raised flooring and be appropriately marked;
h. All cable runs physically protected from damage via tie-downs or where appropriate in
conduit;
i. All cabling designed to industry standards;
j. Communications cabling raceways are separate from electrical, with no intersections;
k. All cabling on raceways is tied down;
l. All SBA IT equipment must be connected to power strips or surge suppressors;
m. Power conditioning components must ensure that fluctuations in a commercial power
quality are isolated from the critical computing loads;
SBA requires that facility electrical systems shall be rated at a minimum of Tier II level, as
defined by the Uptime Institute. Concurrently maintainable computer rooms must have
redundant capacity components and multiple distribution paths serving the site’s computer
equipment. Generally, only one distribution path serves the computer equipment at any time. In
order to establish concurrent maintainability of the critical power distribution system between the
UPS and the computer equipment, Tier III sites require all computer hardware to have dual
power inputs. Devices such as point-of-use switches must be incorporated for computer
equipment that does not meet this specification. The facility electrical system Tier III
SOP 90 47 3
Effective Date: August 28, 2012 74
requirement does not include a requirement for dual utility switching equipment or dual power
feeds for non-mission-critical hosted system components.
SBA computer room requirements are as follows:
a. Electrical systems must incorporate professionally managed power distribution to include
power conditioning, emergency power, and modular distribution.
b. Facility electrical power conditioners shall be employed to protect the computer room
electrical supply from fluctuations in power quality.
c. When used, indoor generators shall be located in an isolated area as to protect the rest of
the computer room facility in the event of a mechanical failure.
d. Each and every capacity component and element of the distribution paths can be removed
from service on a planned basis without causing any of the computer equipment to be
shut down.
e. Planned site infrastructure maintenance can be performed by using the redundant
capacity components and distribution paths to safely work on the remaining equipment
10. Emergency Shutoff (PE-10) - Common
Computer rooms housing SBA information systems must ensure a master power switch or
emergency cutoff switch to sensitive IT equipment is present. The cutoff switch shall be located
near the main entrance of the sensitive area and shall be labeled and protected by a cover to
prevent accidental shutoff. Emergency shutoff capabilities must ensure a controlled shutdown
that minimizes data loss or unexpected connectivity.
11. Emergency Power (PE-11) - Common
Computer rooms housing SBA information systems must ensure an uninterruptible power supply
(UPS) and/or backup generator is provided so that critical operations may continue and to
prevent system crashes as a result of power failure. Any emergency power systems must be able
to provide emergency power to critical systems (alarm systems, radio communications, computer
facilities, etc.). Contracts must be in place for support for UPS, generators, and batteries. UPS
systems must be capable of supporting the designated requirements of the computer room based
on the criticality of the information systems they support. Emergency power implementations
must be planned in accordance with contingency planning measures, and any contingency
planning sites must employ the same level of emergency power coverage as that of the primary
computer room. Any emergency power alternatives must ensure redundancy – for example, may
not share a common point of failure.
12. Emergency Lighting (PE-12) - Common
All computer rooms housing SBA information systems must ensure an automatic emergency
lighting system is installed to cover all areas necessary to maintain mission or business essential
functions, including emergency exits and evacuation routes. Emergency lighting must be
connected to emergency backup power in the event of a power outage.
In general, emergency lighting is required to come on automatically within ten seconds after a
loss of power and must operate for a minimum of 90 minutes. Illumination requirements must be
immediately available to facilitate egress in the event of an emergency.
13. Fire Protection (PE-13) - Common
All SBA IT restricted space must incorporate appropriate fire protection devices. SBA date
center management must install and ensure operability of fire suppression devices, such as fire
extinguishers and sprinkler systems, and detection devices, such as smoke and water detectors, in
SOP 90 47 3
Effective Date: August 28, 2012 75
all areas where agency information systems are maintained (this includes server rooms, tape
libraries, and computer rooms) to meet federal and local building codes. Fire protection devices
must ensure the following:
a. Smoke and thermal detectors are in place, and fire suppression equipment in all data and
operations centers and within close proximity of primary IT systems.
b. A fully automatic fire suppression system shall be used that automatically activates when
it detects heat or smoke particles in order to prevent danger to personnel from toxicity.
c. Fire suppression system shall automatically notify the organization and first responders in
the event of a fire.
d. Fire suppression and prevention devices and systems shall be checked and tested
periodically against such failures as electronic devices or wiring malfunctions, improper
storage of materials.
e. Hazardous or combustible materials must be stored securely at a safe distance from all IT
systems.
f. All fire doors within close proximity of IT systems must be alarmed and must
automatically close after opening.
g. Physical barriers must extend from real floor to real ceiling to prevent environmental
contamination, such as that caused by fire and flooding.
h. All appropriate staff must receive awareness training in fire safety, testing fire alarms,
and evacuation plans for areas containing IT systems under their control.
i. Metal clad doors or solid wood doors with a 2-hour fire rating will be used at all IT
Restricted Space entrances.
j. The computer room will be protected by a fire suppressant system in accordance with
local fire code, preferably dry-pipe.
14. Temperature and Humidity Controls (PE-14) - Common
SBA computer rooms supporting information systems must maintain sufficient measures for
protecting IT systems against environmental factors (e.g., dust, power, excessive heat and
humidity). Specialized equipment and devices to monitor and control the environment should be
installed. These controls must include:
a. Positioning sensitive IT systems and equipment on raised floors.
b. Testing controls protecting the environment (power, temperature, fire protection, lighting,
plumbing) against disruptions and natural disasters at least annually.
c. Monitor environmental conditions for conditions that could adversely affect the operation
of sensitive IT systems and information processing facilities.
d. Automated climate controls and system management in HVAC systems.
e. Installing and ensuring operability of air control devices, such as air-conditioners and
humidity controls, in all areas where agency information systems are maintained (this
includes server rooms, tape libraries, and computer rooms) to meet federal and local
building codes.
SOP 90 47 3
Effective Date: August 28, 2012 76
f. Review utilities, such as air conditioning, regularly to ensure operability.
15. Water Damage Protection (PE-15) - Common
All SBA IT restricted space must have processes in place to ensure that all agency systems and
networks are located in areas not in danger of water damage due to leakage from building
plumbing lines, shut-off valves, and other similar equipment to support meeting federal and local
building codes.
Computer room owners must ensure that building plumbing lines must not endanger the
computer/server room or any room that contains sensitive equipment. Computer room staff
members must ensure that plastic sheets are readily available in the computer/server room or in
any room that contains critical equipment to protect them from accidental water leaks from
building plumbing lines or in the event the sprinkler system malfunctions. The following water
damage precautions must be implemented in all SBA computer rooms:
a. Raised platform floor plenum;
b. Water piping or drains are not installed above computer room space;
c. An alarmed water monitoring system must protect all areas within the computer room;
and
d. Master shutoff valves must accessible, working properly, and have locations that are
known to key personnel.
16. Delivery and Removal (PE-16) - Common
SBA IT restricted space owners must ensure that the delivery of all items to the controlled
facility is monitored and approved, and that appropriate records of these visits is maintained in
accordance with computer room visitor policy. SBA IT restricted space managers shall isolate,
if possible, delivery areas from sensitive computer room areas.
17. Alternate Work Site (PE-17) - Hybrid
Occupant emergency plans shall be developed for all SBA IT restricted space, and contingency
procedures based on threats shall be developed in accordance with contingency planning policies
and procedures. Alternate work sites for SBA IT restricted space shall provide security
considerations commensurate with those in place at the primary computer room.
18. Location of Information System Components (PE-18) - Common
Equipment located within SBA IT restricted space areas shall be positions so as to limit exposure
to damage from physical and environmental hazards. Physical and environmental hazards
include, for example, flooding, fire, tornados, earthquakes, hurricanes, acts of terrorism,
vandalism, electrical interference, and electromagnetic radiation.
Consideration must be given to the physical location of the IT restricted space itself –for
example, it would be unwise to place a computer room in an area that is frequently flooded or is
located on a fault line.
PE-18 is frequently considered to be a “common” control, especially if a limited number of
computer rooms are used. By centrally managing the development, implementation, and
assessment of the common security controls, security costs can be consolidated across multiple
information systems.
SOP 90 47 3
Effective Date: August 28, 2012 77
CHAPTER 12 - Planning 1. Security Planning Policy and Procedures (PL-1) - Common
The goal of security planning is to improve the protection of IT assets and ensure the
confidentiality, integrity, and availability of information. SBA must develop, disseminate, and
periodically review/update formal, documented security planning policies and procedures that
address purpose, scope, roles, responsibilities, management commitment and coordination
among organizational entities, and compliance. Within the SSP, the following subjects must be
covered:
a. Management Controls – Describe the policies and procedures used and specific processes
for planning, organizing, directing and controlling program operations.
b. Operational Controls – Describe the mechanisms that primarily are implemented and
executed by people (as opposed to systems).
c. Technical Controls – Describe the hardware or software used to provide automated
protection to the systems or applications.
2. System Security Plan (SSP) (PL-2) - Common
The purpose of the system SSP is to provide an overview of the security requirements of the
system and describe the controls in place or planned for meeting those requirements. The SSP
also delineates responsibilities and expected behavior of all individuals who access the system.
The SSP must be viewed as documentation of the structured process of planning adequate, cost-
effective security protection for a system. SSPs must be reviewed annually to address changes to
the information system/environment of operation or problems identified during plan
implementation or security control assessments. The SSP is the leading guide for implementing
and maintaining security in the environment.
3. Rules of Behavior (PL-4) – Common
“Rules of Behavior” are required in OMB Circular A-130 and NIST Special Publications 800-18
and 800-53. A set of “Rules of Behavior” in writing must be established for each system. Prior
to gaining access to an SBA information system resource, all users are required to review,
acknowledge and agree to specific “Rules of Behavior” (ROB). The ROB establishes expected
and acceptable computing behaviors and defines inappropriate and forbidden actions. The ROB
includes and describes penalties for non-compliance, and discusses common policies and
procedures that are expected to be followed by all users. Users are required to acknowledge the
“Rules of Behavior”. New users are provided written ROBs and required to sign ROBs prior to
system access.
SBA requires users to ensure they understand their responsibilities and expected behavior by
signing an ROB. The “Rules of Behavior” must clearly delineate responsibilities and expected
behavior of all individuals with access to the system. They must state the consequences of
inconsistent behavior or noncompliance. They must include appropriate limits on
interconnections to other systems. The intent of the “Rules of Behavior” is to make all users
accountable for their actions by acknowledging that they have read, understand, and agree to
abide by the rules. The rules must not be a complete copy of the security policy or procedures
guide; but rather cover, at a high level, what is expected of the user. The document explains clear
usage rules and expected behavior and requires signed acknowledgement from the user (the
signature can be electronic). Copies of the signed document must be retained.
SOP 90 47 3
Effective Date: August 28, 2012 78
4. Privacy Impact Assessment (PL-5) - Common
OMB requires that all FISMA information systems have a Privacy Impact Assessment (PIA)
conducted. SBA must conduct reviews of how information about the public is handled within
SBA when SBA uses IT systems to collect new information, or when agencies develop or buy
new IT systems to handle collections of PII. The PIA identifies privacy information stored and
processed within the environment and discusses the controls in place designed to prevent harm
resulting from the loss, misuse, or unauthorized access to or modification of privacy information.
5. Security-Related Activity Planning (PL-6) - Common
Security related activity planning is not mandatory for a low impact system. Moderate and high
impact systems must plan security related activities affecting the information system before
conducting activities. Planning may include implementing planning security related activities
(e.g., patching, control testing); reviewing actions that could impact operations, assets, or
individuals (e.g., CCB reviews); and planning for conduct in emergency situations (e.g., critical
patch, contingency plan execution) and non-emergency situations (e.g., routine patching, etc.).
SOP 90 47 3
Effective Date: August 28, 2012 79
CHAPTER 13 – Personnel Security 1. Personnel Security Policy and Procedures (PS-1) - Common
Personnel security is a necessary component of safeguarding SBA assets. Personnel security
policies help protect SBA assets from abuse, misuse, or destruction by employees, contractors, or
other authorized personnel. Personnel security involves human users, designers, implementers
and managers and how they interact with computers, access and the authorities they need to do
their job. The greatest harm/disruption to a system comes from the actions of individuals, both
intentional and unintentional. (See SOP 34 00, Separation Clearance.)
Personnel processes in place at SBA must ensure the following:
a. Prevent personnel from misusing SBA facilities and resources;
b. Reduce the risk of theft and fraud;
c. Address information security issues during the recruitment and hiring process;
d. Make sure contracts include security provisions;
e. Make sure all users of SBA IT assets are subjected to a rigorous security screening that is
appropriate for the job;
f. Make sure all users of SBA IT assets understand what is expected (i.e., appropriate
behavior with respect to the system) and the user acknowledgement of their
understanding is captured (e.g., signed “Rules of Behavior” forms);
2. Position Categorization (PS-2) - Common
SBA’s Office of Human Capital Management (OHCM) must assign a risk designation to all
positions and establish screening criteria for individuals filling those positions. Background
investigations must be conducted on employees commensurate with their position risk and/or
sensitivity, level of access, and need to know. Anyone handling sensitive data, PII or Agency
priority applications or systems, must have a background investigation. The requirement for
security clearances for IT employees is based on an assessment of position sensitivity, criticality,
and ability to do grave harm.
3. Personnel Screening (PS-3) - Common
SBA must screen all personnel to ensure the personnel meet the risk designation requirements.
The goal of personnel screening is to:
a) Verify the backgrounds of individuals who apply for permanent employment with SBA;
b) Confirm the personal identity of people who apply for permanent employment;
c) Perform periodic background checks for all personnel who will have access to SBA IT
resources; and
d) Make sure users comply with the legal rules and regulations that govern the collection
and use of personal information.
SBA’s Office of the Inspector General, Office of Security Operations is responsible for ensuring
that updated or upgraded investigations occur in accordance with OPM and personnel security
requirements.
SOP 90 47 3
Effective Date: August 28, 2012 80
4. Personnel Termination (PS-4) - Common
Upon termination of employment, SBA must terminate information system access, conduct exit
interviews, retrieve all organizational FISMA information system related property, and provide
appropriate personnel with access to official records created by the terminated employee that are
stored on SBA information systems. Upon personnel termination (voluntary or involuntary),
SBA terminates system access within 24 hours. (See SOP 34 00, Separation Clearance.)
5. Personnel Transfer (PS-5) - Common
SBA must review information systems/facilities access authorizations when personnel are
reassigned or transferred to other positions within the organization and initiate appropriate
actions. New access must be granted and old access revoked based upon the job requirements.
SBA must ensure that:
a. Old keys, identification cards and building access cards are returned and new ones are
issued, if applicable;
b. Old accounts are closed and new accounts established;
c. System access authorizations are changed and appropriate personnel are provided
d. Access to official records created by the transferred employee that are stored on SBA
information systems; and
e. System access will be terminated within 24 hours upon personnel transfer
6. Access Agreements (PS-6) - Common
SBA must require signed access agreements for individuals requiring access to SBA information
systems before authorizing access. The access agreements can include nondisclosure
agreements, acceptable use agreements, “Rules of Behavior”, and conflict-of-interest
agreements. Users must also sign additional access agreements if their job duties change and
they are granted new access to systems. Access agreements must:
a. Define employee’s information security responsibilities;
b. Specify the actions that SBA will take if employees disregard information security
requirements;
c. Clarify all copyrights and responsibilities;
d. Clarify all data protection rights and responsibilities;
e. Define users’ information management responsibilities; and
f. Inform the users that their information security responsibilities also apply outside of
normal working hours.
7. Third-Party Personnel Security (PS-7) - Common
Third-Party personnel, such as contractors or other organizations providing SBA service, must
possess the same level of security clearance as an SBA employee to access the same system or
information. Contract support staff must adhere to the same clearance levels and re-investigation
requirements as Federal employees. OIG/OSO must review permanent contractor clearances to
ensure the clearance is adequate and current. Contracting officials are responsible for making
sure all current and future contracts include official language addressing security clearances.
(See Appendix H – Contract Security Language.)
SOP 90 47 3
Effective Date: August 28, 2012 81
8. Personnel Sanctions (PS-8) - Common
All violations of SBA’s security rules will be reported to the OGC and OHCM for review and
appropriate action. (See SOP 52 2 - Discipline and Adverse Actions.)
SOP 90 47 3
Effective Date: August 28, 2012 82
CHAPTER 14 – Risk Assessment
1. Risk Assessment Policy and Procedures (RA-1) - Common
Risk is the negative impact of a vulnerability considering both the probability and the impact of
occurrence. Risk assessments are used to give SBA a baseline measurement of their system
security controls. The ability to eliminate all risks in an IT environment is hardly achievable.
Every system or application will have some degree of risk. Therefore, the Agency must
understand and make business decisions concerning what threats are the most critical, somewhat
critical and non-critical; or, risks that are categorized as High, Medium, or Low. Official risk
assessments shall be conducted or updated annually.
According to NIST SP 800-30, Risk Management Guide for Information Technology Systems,
the high-level steps undertaken in a risk assessment are as follows:
2. Security Categorization (RA-2) - Common
SBA must categorize systems and the information processed, stored, or transmitted by the
system according to security categories laid out in the Federal Information Processing Standard
199 (FIPS 199) Standards for Security Categorization of Federal Information and Information
Systems and NIST SP 800-60 Guide for Mapping Types of Information and Information
Systems to Security Categories. FIPS 199 defines the security categories, security objectives, and
impact levels to which NIST SP 800-60 maps information types.
FIPS 199 establishes security categories for both information and information systems. The
security categories are based on the potential adverse effects on an organization must certain
events occur. Adverse effects could jeopardize the information and information systems needed
by the organization to accomplish its assigned mission, protect its assets, fulfill its legal
responsibilities, maintain its day-to-day functions, and protect individuals. Security categories
are to be used in conjunction with vulnerability and threat information in assessing the risk to an
organization.
3. Risk Assessment (RA-3)- Common
The focus of this control is explicitly determining and documenting the risk that SBA is
incurring based on the use of the information system. Risk assessment requires judgment
regarding the perceived, future threats. All information systems within SBA must have a risk
assessment performed. These risks must be documented in the systems security plan and
applicable risk and related assessments. SBA requires that risk assessments are updated
annually or more often if major changes to the system occur.
4. Vulnerability Scanning (RA-5) - Hybrid
SBA will designate authorized personnel to conduct software scans. All authorized users will be
trained in the use of the scanner software prior to conducting any internal or external scans and
will notify the SBA SOC before running scans.
SBA must produce and retain inventory and vulnerability scan reports for all scans conducted in
compliance with Agency record management guidelines.
SOP 90 47 3
Effective Date: August 28, 2012 83
a. The Vulnerability Assessment Team (VAT) scan report will be completed and sent to the
programs.
b. A summary of the vulnerabilities identified will be provided to the CIO for review to
ensure that corrective action plans are developed within 30 days and implemented for
critical vulnerabilities identified.
c. A POA&M will be developed for any unresolved critical vulnerabilities existing for more
than 30 days from the date of the scan.
For systems designated as Moderate and High impact, SBA will employ vulnerability scanning
tools that include the capability to readily update the list of vulnerabilities scanned.
For systems designated as High impact will also utilize the following controls, SBA will:
a. Update the list of vulnerabilities monthly or sooner when new vulnerabilities are
identified;
b. Use vulnerability scanning tools that will employ procedures that can demonstrate the
depth and breadth of coverage;
c. Attempt to discern what information is discoverable by adversaries;
d. Provide privileged access authorization to program security officials for selected
activities to facilitate more thorough scanning; and
e. Employ automated mechanisms to detect the presence of unauthorized software and
notify organizational officials.
SOP 90 47 3
Effective Date: August 28, 2012 84
CHAPTER 15 – System and Services Acquisition
1. System and Services Acquisition Policy and Procedures (SA-1) - Common
System and services acquisition processes at SBA must adhere to the most current version of the
Information Technology Capital Planning and Investment for Information Technology Control
Guide.
All SBA system and services acquisitions must be conducted in accordance Federal Acquisition
Regulations (FAR), the Clinger-Cohen Act, OMB Circular A-11, Section 300 “Planning,
Budgeting, Acquisition and Management of Capital Assets,” and other guidance pertaining to the
Federal government’s procurement process.
2. Allocation of Resources (SA-2) - Common
The Clinger-Cohen Act of 1996 requires federal agencies to use a disciplined capital planning
and investment control (CPIC) process to acquire, use, maintain, and dispose of information
technology. This control seeks to determine using the CPIC process, if there are sufficient
resources to adequately protect the information system. SBA must allocate, as part of its CPIC
process, the resources required to adequately protect the information system by:
a. Defining security requirements for the information system in mission/business planning;
b. Establishing a discrete budget line item for information system security; and
c. Integrating information system security into the CPIC process in accordance with the
guidance in NIST SP 800-65.
3. Life Cycle Support (SA-3) - Common
Security and privacy planning for SBA information systems must proceed in parallel with the
development of the system(s) to ensure IT security and privacy requirements, and costs are
identified and incorporated into the overall lifecycle of the system(s). The system development
life cycle followed must be consistent with NIST SP 800-64.
4. Acquisitions (SA-4) - Common
This control focuses on contract documentation for information systems, ensuring that Federal
and SBA security requirements and/or security specifications; required information system
documentation deliverables; any requirements for use of tested, evaluated and validated
products; and required configuration settings and implementation guidance are noted in the
acquisition documents. SBA’s determination of what security requirements and/or security
specifications requirements for its FISMA information systems must be included in contract
documents explicitly or by reference. The inclusion of security requirements must provide clarity
to contractors regarding SBA’s security requirements and/or specifications and contractual
remedies if requirements are not satisfactorily met. The security requirements in the solicitation
for any acquisitions must include:
a. SBA IT security clauses as provided by the SBA contracting office;
b. Required security capabilities (security needs and, as necessary, specific security controls
and other specific FISMA requirements);
SOP 90 47 3
Effective Date: August 28, 2012 85
c. The implementation of security coding requirements and testing;
d. Required design and development processes;
e. Required test and evaluation procedures; and
f. Required documentation.
5. Information System Documentation (SA-5) - Common
Whenever acquiring software for information systems, SBA must receive documentation from
the manufacturer/contractor that includes administrator and user guides with information on:
a. Configuring, installing, and operating the system; and
b. Effectively using the system’s security features.
When adequate information system documentation is either unavailable or nonexistent (e.g., due
to the age of the system or lack of support from the manufacturer/contractor), SBA must
document attempts to obtain such documentation and provide compensating security controls, if
needed.
Moderate and High systems must also have documentation that describes the functional
properties of the security controls used within the system with sufficient detail to permit analysis
and testing of the controls. If the administrator and/or user guides describe the properties with
enough detail to allow analysis and testing, that is sufficient. The focus of this effort is to
demonstrate that SBA made a “good faith” effort to obtain documentation from the vendor or
manufacturer describing the functional properties of the security controls in the information
system in sufficient detail and comprehensiveness to enable SBA to analyze and test the security
controls.
High systems must also have documentation that describes the design and implementation details
of the security controls used within the system with sufficient detail to permit analysis and
testing of the controls. If the administrator and/or user guides describe the properties with
enough detail to allow analysis and testing, that is sufficient. The focus of this effort is to
demonstrate that SBA made a “good faith” effort to obtain information system documentation
from the vendor or manufacturer describing design and implementation details of the security
controls in the system in sufficient comprehensiveness to enable SBA to analyze and test the
security controls including analysis and testing of functional interfaces among control
components.
6. Software Usage Restrictions (SA-6) - Common
SBA and SBA information systems must be in compliance with software contractual and
copyright usage restrictions, and must ensure that commercial software is properly and legally
acquired, licensed, accounted for, reproduced, distributed, transmitted, disposed of, and
otherwise used only in accordance with licensing agreements. Information systems in use at
SBA must demonstrate that they:
a. Comply with software usage restrictions;
b. Employ tracking systems to control copying and distribution of software and associated
Documentation protected by quantity licenses; and
c. Control and document the use of publicly accessible peer-to-peer file sharing technology
to ensure that this capability is not used for any reason.
SOP 90 47 3
Effective Date: August 28, 2012 86
SBA Directive 3120.3, Software License Compliance Policy, establishes the policy for approval
of software installed on SBA owned computers. The directive states that “All software installed
on SBA computers will be approved software.” The HQ Help Desk can provide guidance on
approved Agency software.
7. User-Installed Software (SA-7) - Common
SBA is responsible for ensuring that users do not install software and use software counter to
licensing agreements or copyright laws. SBA Directive 3120.1 Software License Compliance
Policy, states SBA’s Software License Compliance Policy. It states that SBA employees are
responsible for ensuring that commercial software is properly and legally acquired, licensed,
accounted for, reproduced, distributed, transmitted, disposed of, and otherwise used only in
accordance with licensing agreements. The following list summarizes SBA user responsibilities
described in the directive:
a. Install and maintain only legally procured software on their computer and/or network;
b. Follow all provisions of the license agreements and register organizational ownership;
c. Not make illegal copies of copyrighted software;
d. Maintain written records of software, other than Agency standard software, installed on
each machine and ensure that a license or other proof of ownership is on file for each
piece of software;
e. Retain the current version of other than Agency standard software, software manuals, and
procurement documentation in a secure location (i.e., closed file cabinet, drawer, or shelf,
etc.);
f. Dispose of the old version of software in accordance with the licensing agreement to
avoid a potential violation whenever upgrades to software are purchased;
g. Adhere to the software licensing agreements in conjunction with telecommuting
guidelines when using copies of government owned software for use on their personally
owned computers under specific circumstances (e.g., for government work, but not
personal business); and
h. Adhere to the software licensing agreements when using copies of government owned
software on both their government-owned portable laptop computers and their desktops.
8. Security Engineering Principles (SA-8) - Common
This control is mandatory for moderate and high systems only. SBA information systems must
incorporate security considerations from the initial planning and design phases to disposal of the
system. Applications and systems must be designed and implemented using sound information
system security engineering principles into the system design and implementation wherever a
system is in its system development life cycle (SDLC). This control applies to systems under
development, those undergoing major upgrades, major updates, and/or otherwise being changed.
NIST SP 800-27A is entitled Engineering Principles for Information Technology Security (A
Baseline for Achieving Security) and provides some guidance. The principles that apply depend
on where within the SDLC the development falls (initiation, development/acquisition,
implementation, operation/maintenance, or disposal). A matrix outlining which principals are
applicable to which phase is available in Appendix B, Life Cycle Principles.
SOP 90 47 3
Effective Date: August 28, 2012 87
9. External Information System Services (SA-9) - Common
According to NIST, an external information system service is a service that is implemented
outside of the accreditation boundary of the organizational information system (i.e., a service that
is used by, but not a part of, an SBA information system).
Relationships with external service providers are established in a variety of ways, for example,
through joint ventures, business partnerships, outsourcing arrangements, licensing agreements,
and/or supply chain exchanges. Ultimately, the responsibility for adequately mitigating risks to
the organization arising from the use of external information system services remains with the
authorizing official of the SBA information system with which the external information system
service connects.
Specific security and contractual obligations shall be established for any external information
system service arrangements. Any external information systems services shall be evaluated prior
to implementation or connection to ensure that they meet general security guidelines as
established by SBA, and are commensurate with the FIPS categorization (low, moderate, or
high) of the connecting SBA information system.
Once the association with the external information system has been approved, the SBA
information system owners must perform ongoing monitoring of the security requirements
established to ensure that they are being met and followed according to the agreed upon
specifications. The responsibility of ensuring that the agreed upon security specifications are
being met lies with SBA, not with the owner of the external information system.
Owners of any external information system connecting with an SBA information system must
cooperate with security evaluations, including assessment and authorization testing, security
assessment reports, audits, FISMA and FISCAM reviews, and OIG inquiries. This obligation
must also be contractually specified. NIST Special Publication 800-35 provides additional
guidance on information technology security services.
10. Developer Configuration Management (SA-10) - Common
A system configuration management plan must be developed, implemented, and maintained for
every IT system managed by SBA; including those developed or maintained by vendors or
subcontractors. System developer configuration management plans must include:
a. The latest accepted version of every IT resource and subsystem;
b. Information on the IT resource, including the manufacturer, model type, version, etc., is
recorded and tracked. This ensures that when looking up IT resource information, access
to the most recent information is available;
c. The change history of the IT resource configuration;
d. This process begins at the IT acquisition/development stage and continues until the IT
resource is replaced or has been decommissioned;
e. A complete history of changes for the IT resource;
f. Design requirements satisfied by the IT resource configuration; and
g. Identification documentation includes specification and configuration designs identified
in the system life cycle design stage. The business case for design and the proposed
SOP 90 47 3
Effective Date: August 28, 2012 88
functions are discussed. This helps ensure the CM audit process will verify that the
design configuration objectives have been met.
SBA system owners must implement the following controls:
a. Define security requirements in the system development/acquisition stage for system
confidentiality and availability as well as integrity of data input, transaction processing,
and data output;
b. Test the application in a development environment, or test bed, prior to operation to
ensure the presence and satisfactory operation of controls (this is normally part of the
certification process);
c. Monitor security controls for vulnerabilities throughout the operation and maintenance
stage;
d. Limit access to software programming libraries; and
e. Protect system documentation with the same diligence as the data.
SBA IT security policy must be incorporated into each phase of the lifecycle, (i.e., initiation,
development/acquisition, implementation, operation and disposal, for all SBA information
systems). NIST SP 800-64, Security Considerations in the Information System Development Life
Cycle, must be used as a guide when managing security throughout the system’s lifecycle.
11. Developer Security Testing (SA-11) - Common
Prior to an SBA information system becoming operational, appropriate developer security testing
shall be conducted. The test phase includes all activities during which ultimate acceptance or
rejection of the release or system is determined. The decision to accept or reject the release or
system must be determined based upon demonstrated satisfaction of the baseline requirements.
The primary objectives of the test phase are the planning, preparation, and execution of user
acceptance testing (UAT) and infrastructure testing. These objectives must be outlined in
documented and approved test plans.
SBA information system owners must implement the following controls:
a. Define security requirements in the system development/acquisition stage for system
confidentiality and availability as well as integrity of data input, transaction processing,
and data output;
b. Test the application in a development environment, or test bed, prior to operation to
ensure the presence and satisfactory operation of controls (this is normally part of the
certification process);
c. Monitor security controls for vulnerabilities throughout the operation and maintenance
stage;
d. Limit access to software programming libraries; and
e. Protect system Documentation with the same diligence as the data.
The dates for completion of the selected deliverables must be outlined in the integrated project
schedule. The test phase must be continuously monitored and controlled by the SBA and
SOP 90 47 3
Effective Date: August 28, 2012 89
development project managers, and any work packages created in previous phases must be
assessed for revision and updated accordingly.
In the event that an information system being deployed is a commercial-off-the-shelf product
(COTS), security testing must still be conducted prior to implementation. In these situations, a
security analysis team may be substituted for the developer/maintainer role. Such security testing
must be designed to consider the security considerations provided by the COTS product in
comparison with the security requirements mandated by SBA. Testing must be conducted to the
greatest extent possible, given the closed nature of the software code. Testing phases should
remain the same, and the same documentation must be maintained and reviewed.
12. Supply Chain Protection (SA-12)
As part of a comprehensive, defense in-breadth information security strategy, SBA will protect
against supply chain threats to High impact systems by employing a defense-in-breadth process
intended to protect the information system throughout the system development lifecycle. This
will be accomplished by identifying, managing and eliminating vulnerabilities at each phase of
the lifecycle.
13. Trust Worthiness (SA-13)
SBA requires that High impact systems meet organizational standards for trust worthiness by
using the Risk Management Framework (Steps 1, 2, and 3) to select and implement the necessary
management, operational and technical security controls necessary to mitigate risks.
SOP 90 47 3
Effective Date: August 28, 2012 90
CHAPTER 16 – System and Communications Protection
1. System and Communications Protection Policy and Procedures (SC-1) - Common
All SBA system and communications devices must employ a defense-in-depth security posture.
Defense-in-depth refers to a layered architecture that provides increasing levels of protection for
the SBA infrastructure. There are three layers in which security products can protect servers in
this strategy: the network, the application and the kernel layers. In an ideal environment, there
are one or more security services that protect each of these layers. Network firewalls and
Intrusion Detection Systems (IDS) are the most common types of security products that work at
the network layer. At SBA, the security objective is to ensure that the network perimeters, the
DMZ, and the SBA Intranet are properly protected. Security functionality within the network
perimeter and DMZ will also provide for the screening of all incoming traffic.
Three vital components of this defense strategy are system hardening; employing minimum
system services and configuration management practices sufficient to ensure that systems are
patched as appropriate.
SBA’s goal is to provide information infrastructure protection in the of the following four core
technology layers through defense and support mechanisms:
a. Defend the network and infrastructure;
b. Defend the enclave boundary;
c. Defend the computing environment; and
d. Supporting Infrastructures.
System hardening includes making specific modifications to an operating system before it is put
into use in order to aid in the reduction of operating risks and to increase system availability,
confidentiality and integrity. Securing a system involves implementing a set of procedures,
practices, and technologies to protect the information technology (IT) infrastructure as well as
software and associated data throughout the organization. Minimum system services deployment
is the use of only those TCP/IP services that are necessary to support the business function (for
example, web servers must not also provide DNS services). Securing computer resources,
applications, and related data is an integral part of securing an enterprise and hardening is the
cornerstone of that model. More information on this subject can be obtained from NIST
SP 800-41.
2. Application Partitioning (SC-2) - Common
Information systems in use at SBA shall use physically or logically separated user interfaces to
separate incompatible services or functions. Examples of incompatible services or functions
include separating user interfaces from administrative functionality, or administrative
functionality from security functionality. Means of logical separations may include:
a. Different network addresses;
b. Different operating systems;
c. Logical access profiles or permissions; and
d. Restricting certain types of network traffic to only approved sources.
Means of physical separation include:
a. Requiring the use of separate computers to enact certain functionality;
SOP 90 47 3
Effective Date: August 28, 2012 91
b. Limiting user rights to only certain machines or operating systems;
c. Use of biometrics to access certain functionality; and
d. Hardware separation mechanisms.
Information system owners must consider proper separation of functionality during the initial
development of an information system and must ensure that technical specification incorporate
proper application partitioning.
3. Security Function Isolation (SC-3) - Common
Security functions employed for SBA information systems must ensure that security functions
are isolated, either logically or physically, from non-security functions. The structure of the
information system must ensure that security capabilities have the following characteristics:
a. Cannot be circumvented;
b. Can be evaluated (the security functions small enough and simple enough to be
mathematically verified and evaluated);
c. Are always invoked (the security functions are invoked each and every time); and
d. Are tamper proof (subversive code cannot alter the function of the security functions by
exhausting resources, overrunning buffers, or other forms of making the security software
fail).
Any operating system that supports multiple address spaces supports the concept of partitions,
and can provide some measure of isolation, either between partitions or between any partition
and the OS. Different domains can also be used to separate security functionality from non-
security functionality.
4. Information in Shared Resources (SC-4) - Hybrid
In Moderate and High impact systems, SBA prevents unauthorized and unintended information
transfer via shared system resources.
5. Denial of Service Protection (SC-5) - Common
Denial of Service (DoS) attacks consists of one or more attackers targeting network resources
and servers to deny service to legitimate users. Increasingly, such attacks come from multiple
locations – a variation dubbed distributed DoS attacks or DDoS attacks – making it harder to
locate the attacker or thwart the attacker.
Information systems in use at SBA must ensure that they provide adequate protection against the
following types of denial of service attacks:
Denial of Service Attack
Type
Description
Application-level floods A number of applications or operating systems have denial-of-service attacks that are specific to those applications or operating systems. Examples include IRC floods, fork bombs, SMB attacks, etc.
Distributed A multitude of compromised systems attack a single target, thereby causing denial of service for users of the
targeted system. The flood of incoming messages to the target system essentially forces it to shut down, thereby denying service to the system to legitimate users.
Nuke This attack consists of fragmented or otherwise invalid ICMP packets sent to the target, achieved by using a modified ping utility to repeatedly send this corrupt data, thus slowing down the affected computer until it
comes to a complete stop.
Peer-to-peer attacks The attacker instructs clients of large peer-to-peer file sharing hubs to disconnect from their peer-to-peer
SOP 90 47 3
Effective Date: August 28, 2012 92
Most DoS attacks can be prevented by employing and properly configuring quality firewalls,
intrusion detection and intrusion prevention systems; securely configuring switches and routers,
employing principals of least privilege and least functionality, keeping abreast of patch
management, and ensuring that operating systems and components are hardened according to
SBA specifications. Basic required actions in provisioning for DoS protection include:
a. Configuring firewalls to allow packets to leave a network only if they have the proper IP
addresses of your internal networks;
b. Only allowing incoming packets with the proper internal IP addresses.
c. Enabling TCP-Intercept on Cisco routers (or similar);
d. Use layered authentication schema;
e. Restricting the number of incomplete requests for a connection;
f. Restricting the number of permissible incomplete connections;
g. Setting timeout periods for incomplete connections;
h. Using packet analysis to identify and reject suspicious packets;
i. Filtering subscriber traffic;
j. Installing dynamic traffic filters or traffic anomaly detectors (such as those offered by
firewalls or intrusion detection/prevention devices); and
k. Ensuring that the following services on every interface on every router are disabled:
(1) Disable sending ICMP redirects
(2) Disable ICMP broadcasts
(3) Disable ICMP mask replies
(4) Disable ICMP unreachable
network and to connect to the victim’s website instead. As a result, several thousand computers may aggressively try to connect to a target website. While peer-to-peer attacks are easy to identify with signatures,
the large number of IP addresses that need to be blocked means that this type of attack can overwhelm
mitigation defenses.
Smurf (Ping of Death, Ping
Flood, ICMP attack)
Attacker sends a large number of ICMP echo requests (ping) traffic to IP broadcast addresses. These requests
spoof the address source of the intended victim. If the routing device delivering traffic to those broadcast addresses delivers the IP broadcast to all hosts, most hosts on that IP network will take the ICMP echo request
and reply to it with an echo reply, multiplying the traffic by the number of hosts responding. On a multi-access
broadcast network, hundreds of machines might reply to each packet.
Permanent DoS (Phlashing) A PDoS attack exploits security flaws in the remote management interfaces of the victim's hardware, including
printers, routers, or other networking hardware. These flaws leave the door open for an attacker to remotely
update the device firmware to a modified, corrupt or defective firmware image, rendering the device permanently unusable. This attack that damages a system so badly that it requires replacement or reinstallation
of hardware.
Teardrop A teardrop attack involves sending distorted IP fragments with overlapping, incorrectly-sized payloads to a target machine. A bug in the TCP/IP fragmentation re-assembly code of certain operating systems causes the
fragments to be improperly handled, causing the operating systems to crash. Windows 3.1x, Windows 95 and
Windows NT operating systems, as well as versions of Linux prior to versions 2.0.32 and 2.1.63, are vulnerable to this attack.
TCP-SYN Floods The SYN flood attack sends TCP connections requests faster than a machine can process them.
SOP 90 47 3
Effective Date: August 28, 2012 93
(5) Disable proxy Address Resolution Protocol (ARP)
(6) Protection devices employed must be commensurate with the criticality of the
information system component(s) being protected.
6. Boundary Protection (SC-7) - Common
All SBA networks shall have a firewall installed between their networks and SBA’s backbone
network. SBA will implement secure Internet Protocol (IP) connectivity from the Internet to
SBA’s networks, including all intranets and extranets, and provide minimum technical security
standards for use in the selection and implementation approved firewalls and perimeter
protection. In addition, SBA will use Application Internet Access Nodes.
The term DMZ is defined above and is widely used to describe the perimeter line of defense
provided by firewalls to separate and protect internal networks from networks that may be web
accessible or public facing. DMZ networks will be used where feasible to provide protection of
SBA IT resources and to reduce exposure to outside attacks. Network firewalls are devices or
systems that control the flow of network traffic between networks employing differing security
postures. In most modern applications, firewalls and firewall environments are discussed in the
context of Internet connectivity and the TCP/IP protocol suite.
However, firewalls have applicability in network environments that do not include or require
Internet connectivity. For example, many networks employ “enclave” networks that employ
firewalls to restrict connectivity to and from internal networks servicing more sensitive
functions, such as the accounting or personnel agency. By employing firewalls to control
connectivity to these areas, an organization can prevent unauthorized access to the respective
systems and resources within the more sensitive areas. The inclusion of a proper firewall or
firewall environment can therefore provide an additional layer of security that would not
otherwise be available. The following considerations must be made in implementing and
configuring boundary protection devices:
General Connectivity
a. Firewalls must deny all traffic by default, and only enable those services that are needed.
Only services that are required and approved shall be activated. Any service that is not
needed shall be turned off or deactivated. Any services that are permitted to pass through
an SBA firewall, whether inbound or outbound, shall be documented as to:
(1) service allowed (including TCP or UDP port number);
(2) description of the service;
(3) business case necessitating the service;
(4) internal management and security controls associated with the service; and
(5) system interconnection agreements and service level agreements, as applicable.
Only approved protocols shall be used in SBA firewalls. Protocols must be assigned after
risk-based decisions, and the security provided by the protocol must be commensurate
with the confidentiality and criticality of the resource it is used for. The approved
protocols list is maintained by the OIS. These protocols must be run on well-known
ports. Port reassignments must go through the change management process.
SOP 90 47 3
Effective Date: August 28, 2012 94
b. Ingress filtering will be performed to exclude/reject all data packets that have an internal
host address (i.e., source address is in the local domain). Non-routable IP addresses
specified in RFC 1918 (Private Network Addresses) shall be dropped
c. Egress filtering will be performed to prohibit packets from leaving the SBA network that
have non-SBA addresses as their source address
d. Inbound services are prohibited, unless a valid business case can establish their validity,
in which case proper authorization will be obtained prior to routing said service. For
sensitive but controlled unclassified information, inbound services must provide
authentication using one-time or session passwords, challenge and response protocols,
digital signatures and/or encryption.
e. All Internet and other public access servers will be located in an SBA network DMZ. No
web servers accessible to the public will be placed inside the SBA Intranet. These
servers shall be protected by firewalls on the public side of the SBA network and will
include their own intrusion detection systems.
f. Application gateways will be used as a firewall component to protect client/server
applications where the client or server resides on an external network. The Office of the
Chief Information Officer may waive this provision for non-standard applications where
a proxy application is not available, or if the application provides user-to-user encryption.
g. All exceptions to the traffic flow policy will be documented with a supporting business
need and the duration of that need.
h. All exceptions will be reviewed weekly.
i. Exceptions that are no longer needed will be removed.
Firewall Management
a. All default firewall administrator or root password shall be changed.
b. All changes to approved firewall security configurations will be reviewed by the SBA’s
CISO and approved by the CIO. Approved firewalls will be configured to allow
transmission of only SBA-approved protocols that use Transmission Control
Protocol/Internet Protocol (TCP/IP) stack.
c. The firewall system shall provide for a monitoring capability. This capability can be
provided as an integral part of the firewall by the provider, or by the addition of a third-
party product. The monitoring product must provide remote notification capability.
d. The monitoring capability shall have the ability to substantiate investigations of real or
perceived violations of local security policies.
e. Firewall configuration settings will be documented and maintained for operation and
evaluation purposes.
f. Firewall team leads must be designated.
g. At a minimum, the audit logs will track information on client transactions (i.e. IP address
of source and destination, date and time, port, Uniform Resource Locator, etc.), attempted
access to network services, rejected source routed addresses, Internet Control Message
Protocol (ICMP) redirects, and any system information the local security officer deems
relevant. Archived audit logs will be maintained and kept as a separate backup for easy
retrieval when needed.
SOP 90 47 3
Effective Date: August 28, 2012 95
(1) SBA perimeter protection will have the capacity to identify each IP address to a
workstation. For accountability reasons, adequate logging will be enabled at
DHCP and proxy servers (or anywhere internal and external addressing is used) to
clearly identify the IP address and location of each workstation. In addition, all
agency perimeter protection must be able to provide security alerts in various
levels of severity.
h. For high-security alerts, the perimeter protection (firewall or IDS) must be able to send
an e-mail or pager notification (or other real-time notification) to the System/Network
Administrator (SA/NA) or Information Systems Security Manager (ISSM) for immediate
attention.
i. All firewall consoles will be located in a physically secure area. Only designated
administrator accounts will be installed on a firewall. Management consoles must provide
a secure (encrypted) communications path between the management console and the
firewall being managed.
j. Vulnerability assessments shall be performed on firewalls on an ongoing basis to test for
known software flaws and weaknesses. Tests must be performed on every interface of the
firewall in all directions. Also, tests must be performed with and without the firewall
rules enabled to determine the potential vulnerability level in the event that the firewall is
not functioning properly.
k. Ongoing audits must be performed at least yearly on the firewall to ensure compliance
with appropriate security policies and to ensure adherence to any government regulations
that pertain to the organization.
l. Firewall configuration files must be backed up on a regular basis and must be maintained
offsite.
Routers/Switches
a. Boundary routers and perimeter firewalls are to be used as part of the authorized agency
perimeter protection. Boundary routers will function as the network perimeter interface
and shall accept traffic from the Internet Service Provider.
b. All changes to approved router or switch security configurations and traffic flow will be
reviewed by the SBA Configuration Control Board (CCB) and approved by the Agency
Authorizing Official (AO) or CIO.
c. TACACS+ or a comparable authentication, authorization, and accounting method must
be used.
d. SBA and SBA boundary routers will be used to filter unapproved protocols and pass
traffic to the firewall to supply additional packet filtering processing.
e. All boundary routers will also implement ingress and egress filtering to protect against IP
address spoofing and directed IP broadcasts.
f. Boundary routers will use router access control lists (ACL) in accordance with SBA
Access Control policies.
g. Boundary routers and perimeter firewalls have the capability to filter based on TCP and
UDP ports as well as IP addresses and incoming network interfaces.
h. No routers may use TFTP to automatically load the configuration at reboot.
i. No router must be configured to serve as a TFTP server.
SOP 90 47 3
Effective Date: August 28, 2012 96
j. No modems must be connected to a console port.
k. Reverse telnet to all physical ports shall be disabled.
l. Telnet shall be disabled in favor of SSH on all Virtual TeleType (VTY) lines.
m. The exec-timeout shall be set on all VTYs to five minutes or less.
n. HTTP access to the router shall be disabled.
o. In the event of an operational failure of a boundary protection device, unauthorized
communication or release of information outside the boundary will be prevented.
p. VPN split-tunneling is prohibited
7. Transmission Integrity (SC-8) - Common
Data integrity is the assurance of non-alteration, and good data integrity ensures that the data
(either in transit or in storage) has not been undetectably altered. Some means of data integrity
safeguards include mechanisms such as parity bits and Cyclic Redundancy Codes (CRCs).
However, to protect sensitive data in transmission, cryptographic techniques are required.
Information systems in use at SBA must evaluate all transmissions associated with SBA
applications, and must determine the extent to which transmission integrity must be protected. If
transmission integrity is deemed to be critical, appropriate FIPS 140-2 algorithms and keys must
be employed and commonly understood between the entities providing and receiving the data.
Information systems in place at SBA shall provide protected communications channels for
authorized request and response messages sent outside of the information system boundaries.
Acceptable methods of ensuring transmission integrity include public key infrastructure (PKI),
secure sockets layer (SSL), transport layer security (TLS), IPSEC, etc.
Information systems in use at SBA shall restrict trust relationships among hosts and external
entities to the appropriate minimum level necessary to accomplish mission tasks. Security
protection mechanisms employed must be commensurate to the criticality of the data being
protected.
8. Transmission Confidentiality (SC-9) - Common
Transmission confidentiality is the assurance of data privacy. Transmission confidentiality
ensures that no one may read the data except for the specific entity (or entities) intended.
Confidentiality is a requirement for SBA information systems when:
a. Data is stored on a medium (such as a computer hard drive) that can be read by an
unauthorized individual.
b. Data is backed up onto a device (such as a tape) that can fall into the hands of an
unauthorized individual.
c. Data is transmitted over unprotected networks.
Transmission confidentiality can be achieved through a number of different methods, including
the use of PKI certificates, IPSec technologies, and secure socket layer technologies. Various
block ciphers can be used to ensure transmission functionality. The following are approved
ciphers for transmission confidentiality:
a. 3DES-EDE – The Data Encryption Standard (DES) is the most widely used symmetric
block cipher. It uses 64 bit blocks and a 56-bit key. Triple DES (also known as 3DES)
super-encrypts by running the data through the DES algorithm 3 times with different
keys. The first time it Encrypts with key 1, the second time it Decrypts with key 2 and the
SOP 90 47 3
Effective Date: August 28, 2012 97
third time it encrypts again with key 3; hence the acronym 3DES-EDE. 3DES-EDE is
FIPS approved.
b. AES – The Advanced Encryption Standard is a FIPS-approved symmetric block cipher
encryption algorithm that may be used by U.S. Government organizations (and others) to
protect sensitive but unclassified information. AES uses 128, 192, or 256 bit keys;
however, cipher suites have only been defined for 128 and 256 bit keys to reduce the over
proliferation of cipher suites. The block size in AES is 128 bits. The AES algorithm
[FIPS197] is designed to replace DES and 3DES. AES is FIPS-approved.
Prohibited ciphers (e.g., ciphers not in compliance with FIPS 140-2), include:
a. IDEA13
b. RC4
9. Network Disconnect (SC-10) - Common
Information systems in use at SBA shall be evaluated to determine if a network disconnect is
required for network sessions within the information system. Network disconnects differ from
session locks (AC-11) and remote session termination (AC-12) in that a network disconnect
requires that an internal session is automatically disconnected after a predetermined time frame.
Session locks may be employed in addition to network disconnects. In determining the need and
parameters for a network disconnect, the information system owners shall review the decision
within the context of risk management.
10. Cryptographic Key Establishment and Management (SC-12) - Common
SBA does not have a Public Key Infrastructure (PKI).
11. Use of Cryptography (SC-13) - Hybrid
Cryptographic modules, which contain cryptographic algorithms, are used in products and
systems to provide security services such as confidentiality, integrity, and authentication.
Although cryptography is used to provide security, weaknesses such as poor design or weak
algorithms can render the product insecure and place highly sensitive information at risk.
Adequate testing and validation of the cryptographic module and its underlying cryptographic
algorithms against established standards is essential to provide security assurance.
FIPS 140 (as revised) precludes the use of un-validated cryptography for the cryptographic
protection of sensitive or valuable data within federal systems. Un-validated cryptography is
viewed by NIST as providing no protection to the information or data - in effect the data would
be considered unprotected plaintext. If the information system contains information or data be
cryptographically protected, then FIPS 140 is applicable. In essence, if cryptography is required,
then it must be validated.
Information systems in use at SBA shall use FIPS-approved security functions and NIST FIPS
validated implementations for all cryptographic functions including key management, hashing,
encryption, digital signatures, and random number generation. Additional information on the use
of validated cryptography is available at http://csrc.nist.gov/cryptval.
The following guidance is applicable with respect to the use of cryptography:
a. All sensitive information and PII shall be encrypted prior to transmission over any public
or government owned/furnished network. Applications that use the Internet or other
public networks for the transmission of SBU information will use Virtual Private
SOP 90 47 3
Effective Date: August 28, 2012 98
Network (VPN) circuits, application level encryption, or other approved gateways as a
means to protect data.
b. Information system owners shall ensure that the information system encrypts sensitive
information during receipt, transmission, and storage using a method compliant with
FIPS.
c. Ensure encryption standards use only algorithms that NIST has approved.
For authentication to a cryptographic module, SBA requires that program areas ensure that
information systems employ authentication methods that meet the requirements of FIPS 140.
12. Public Access Protections (SC-14) - Common
Many Federal agencies have begun to design, develop, and implement public access systems for
electronic dissemination of information to the public. Some systems provide electronic
interaction by allowing the public to send information to the government (e.g., electronic tax
filing) as well as to receive it. When systems are made available for access by the public (or a
large or significant subset thereof), additional security issues arise due to: (1) increased threats
against public access systems and (2) the difficulty of security administration.
Security issues must be considered when an organization begins to plan for the deployment of a
public Web server since it is much more difficult to address security once deployment and
implementation have taken place. Sound decisions about the appropriate configuration of
systems are more likely to be made when organizations develop and use a detailed, well designed
deployment plan. The deployment plan will also support the organization’s Web server
administrators when they have to make the necessary trade-off decisions regarding usability,
performance, and risk. New and existing SBA Internet sites must ensure that the following are
considered for public access information systems:
a. Using a secure Internet gateway that can implement network access policies. Errors and
simple mistakes in one system's configuration can cause problems for other
interconnected systems.
b. Creating a TCP/IP service access policy. The following is a partial list of TCP/IP services
that must be restricted or blocked from passing through a site's Internet gateway:
(1) DNS zone transfers
(2) TFTP
(3) RPC (e.g., NIS, NFS)
(4) RLOGIN
(5) RSH
(6) TELNET
(7) FTP
(8) SMTP
a. Using strong authentication. Authentication schema must be consistent with guidance
published in NIST SP 800-63, Electronic Authentication Guidance. E-authentication risk
assessments must be conducted on all public facing information systems supported or
offered by SBA.
SOP 90 47 3
Effective Date: August 28, 2012 99
b. Securing Public Access Systems. Public access systems such as anonymous FTP archives
are often prime targets for abuse. Such systems, if misconfigured to allow writing, can
permit intruders to destroy or alter data or software.
c. System Security Tools. The existence of a secure gateway does not negate the need for
stronger system security. Many tools are available for system administrators to enhance
system security and provide additional audit capability. Such tools can check for strong
passwords, log connection information, detect changes in system files, and provide other
features that will help administrators to detect signs of intruders and break-ins.
d. Ensure that the Web server application is deployed, configured, and managed to meet the
security requirements of the organization.
e. Ensure that Web server operating systems are deployed, configured, and managed to
meet the security requirements of the organization.
f. Take appropriate steps to protect Web content from unauthorized access or modification.
g. Use active content judiciously after balancing the benefits gained against the associated
risks.
13. Collaborative Computing (SC-15) - Common
Collaborative computing mechanisms include devices such as video and audio conferencing
capabilities. Any SBA collaborative computing mechanisms must explicitly indicate that the
collaborative computing system is in use to prevent the system from transmitting confidential or
sensitive information to unintended parties. Explicit indication of use includes, for example,
signals to local users when cameras and/or microphones are activated. SBA collaborative
computing devices shall:
a. Ensure that adequate security controls are implemented to ensure that only authorized
individuals can participate in video teleconferencing.
b. Ensure that transmission protection is commensurate with the highest sensitivity of
information to be discussed over the video teleconference.
c. Ensure that video teleconferencing equipment and software are turned off when not in
use.
14. Public Key Infrastructure Certificates (SC-17) - Common
SBA does not have a PKI infrastructure.
15. Mobile Code (SC-18) - Common
Broadly speaking, mobile code, or active content, refers to electronic Documents that can carry
out or trigger actions automatically without an individual directly or knowingly invoking the
actions. Mobile code technologies include, for example, Portable Document Format (PDF)
Documents, Web pages containing Java applets, JavaScript instructions or ActiveX controls,
word processor files containing macros, Flash and Shockwave media files, spreadsheet formulas,
and other interpretable content. Active content may also be distributed embedded in e-mail or as
executable mail attachments.
SBA information systems shall allow active content only where it specifically benefits the
quality of the services delivered. The following guidance is applicable to SBA mobile code use:
a. When required to conduct official business, all mobile code technologies that are
permitted to be used in SBA information systems shall be allowed to pass through SBA
boundary protection mechanisms. The functionality of a system must be reduced to the
minimum needed to carry out its operation.
SOP 90 47 3
Effective Date: August 28, 2012 100
b. All SBA owned and SBA controlled servers shall be monitored to detect the presence of
prohibited mobile code. Any discovered prohibited mobile code shall be removed.
c. Consideration must be given to using IT products that have undergone a formal security
evaluation.
d. The desktop applications that handle active content documents typically have built-in
controls that can be used to control or prevent access. All desktop applications that could
display or execute mobile code must be configured in accordance with a standard profile
that either allows or denies access to mobile code types in accordance with SBA and
guidelines.
e. On the browser side, unnecessary plug-ins or ActiveX controls must be removed. It is
also recommended to substitute programs with lesser functionality in lieu of fully capable
helper applications or plug-ins.
f. On the server side, any unnecessary software not needed in providing Web services must
be removed as well, particularly any development tools that could be used to further an
attack if an intruder should gain an initial foothold.
g. Users must not peruse active content or run downloaded software from untrusted sources.
Users should enable ActiveX code only from trusted Web sites that require its use.
h. Institutionalize how needed plug-ins and other software code are obtained from software
manufactures, evaluated, and distributed throughout the organization.
16. Voice Over Internet Protocol (SC-19) - Common
Voice over Internet Protocol (VOIP) is a general term for a family of transmission technologies
for delivery of voice communications over the Internet or other packet-switched networks. Other
terms frequently encountered and synonymous with VoIP are IP telephony and Internet
telephony, as well as voice over broadband, broadband telephony, and broadband phone, when
the network connectivity is available over broadband Internet access. While VOIP can offer
significant cost savings for an organization, it also can open unexpected security vulnerabilities.
Any VOIP systems implemented at SBA shall ensure that the following guidelines are
implemented:
a. Server-based Internet Protocol (IP) private branch exchanges (PBX) must be
(1) Securely configured;
(2) Placed behind firewalls;
(3) Patched against vulnerabilities; and
(4) Frequently monitored using intrusion detection systems.
b. IP PBXs must reside in a different domain than its other servers, and there must be
limited administration access to the servers.
c. Strict access-control lists to IP PBXs must be maintained and enforced.
d. The VOIP gateway must be configured in such a fashion that only the people on this list
are permitted to make and receive VOIP calls.
e. Shared media devices (e.g., hubs) must not be installed on VoIP networks.
SOP 90 47 3
Effective Date: August 28, 2012 101
f. All VoIP networks must be configured to function as an alternate telephone service if
major network problems occur.
g. All Agency firewalls must be configured to properly to recognize authorized VOIP
networks and systems.
Any VOIP systems implemented at SBA must be developed and deployed in accordance with
NIST SP 800-58, Security Considerations for Voice over IP Systems.
17. Secure Name /Address Resolution Service (Authoritative Source) (SC-20) - Common
Information systems in use at SBA shall employ secure name/address resolution services. The
information system, when operating as part of a distributed, hierarchical namespace, must
provide the means to indicate the security status of child subspaces and, if the child supports
secure resolution services, to enable verification of a chain of trust among parent and child
domains. The security status of child subspaces may be ensured through the use of delegation
signer resource records. The delegation signer (DS) resource record (RR) is inserted at a zone cut
(i.e., a delegation point) to indicate that the delegated zone is digitally signed, and that the
delegated zone recognizes the indicated key as a valid zone key for the delegated zone.
Any DNS server that contains a complete copy of the domain's zone file is considered to be
authoritative for that domain only. A complete copy of a zone file must have:
a. A valid Start of Authority (SOA) record;
b. Valid Name Server (NS) records for the domain; and
c. The listed NS records must match the servers listed in the SOA record.
There are two types of authoritative name servers: master (or primary) name server and slave (or
secondary) name server. To improve fault tolerance, there could be several slave name servers in
an enterprise. The following security considerations must be employed for authoritative source
name/address resolution servers:
a. An authoritative name server is only intended to provide name resolution for the zones
for which it has authoritative information. The security policy must have recursion turned
off for this type of name server. Disabling recursion prevents an authoritative name
server from sending queries on behalf of other name servers and building up a cache
using responses.
b. The operating system shall be configured securely, according to SBA and OCIO
specifications, and in accordance with NIST and OMB guidance. The most recent version
of the name server software must be employed, and the operating system must be patched
according to SBA and OCIO guidelines.
c. Name server software must run with restricted privileges. If the name server software is
run as a privileged user (e.g., “root” in Unix systems), any break-in into the software can
have disastrous consequences. Name server software must be run as a non-privileged user
with access restricted to specific directories.
d. Hosts that run the name server software must not provide any other services, and must be
configured to respond to DNS traffic only. The only allowed incoming and outgoing
messages to these hosts must be 53/UDP and 53/TCP.
e. Name server software must be isolated to the machines intended to support this
functionality. Name server software must be removed from non-designated hosts.
SOP 90 47 3
Effective Date: August 28, 2012 102
f. A dedicated name server instance must be established for each function.
g. The BIND version query functionality must be disabled.
h. A name server instance must always be configured as either an authoritative name server
or a resolving name server.
18. Secure Name /Address Resolution Service (Recursive or Caching Resolver) (SC-21) -
Common
A resolving or caching domain name system (DNS) server is an example of an information
system that provides name/address resolution service for local clients; and authoritative DNS
servers are examples of authoritative sources.
The underlying feature in the major threat associated with DNS query/response (i.e., forged
response or response failure) is the integrity of DNS data returned in the response. The security
objective is to verify the integrity of each response received. An integral part of integrity
verification is ensuring that valid data has originated from the right source. Establishing trust in
the source is called data origin authentication. The security objective and consequently the
security services that are required for securing the DNS query/response transaction are data
origin authentication and data integrity verification.
SBA information systems categorized as high impact must ensure that data origin authentication
and data integrity verification for secure name/address resolution services occurs for all DNS
resolution responses, even if the client does not request this service. There are two primary ways
to accomplish this:
a. Domain Name System Security Extensions (DNSSEC). In DNSSEC, trust in the public
key (for signature verification) of the source is established by starting from a trusted
name server (such as the root name server) and establishing the chain of trust back to the
current source of response through successive verifications of signature of the public key
of a child by its parent. DNSSEC can guarantee the integrity of name resolution
responses to DNS clients acting on behalf of Internet-based resources, provided the
clients perform the DNSSEC signature verification.
b. Split DNS. Authoritative name servers for an enterprise receive requests from both
external and internal clients. In many instances, external clients need to receive resource
records that pertain only to public services (public Web server, mail server, etc.) Internal
clients need to receive resource records pertaining to public services as well as internal
hosts. Hence, the zone information that serves these resource records can be split into
different physical files for these two types of clients: one for external clients and one for
internal clients. This type of implementation of the zone file is called split DNS.
High impact systems in use at SBA should evaluate both methods and make a risk-based
decision regarding the best course of action to pursue with respect to data origin authentication
and data integrity verification.
19. Architecture/Provisioning for Name/Address Resolution Service (SC-22) - Common
All information systems in use at SBA must use a method of providing name/address resolution,
such as the Domain Name System (DNS). Efficient and effective architecture and provisioning
for any name/address resolution services must be provided.
The following architectural considerations must be made while designing and deploying
address/name resolution services for SBA information systems:
SOP 90 47 3
Effective Date: August 28, 2012 103
a. DNS servers supporting critical applications must have built-in redundancy – for
example, there must be a primary and a secondary DNS server.
b. If DNS provisioning is required for both internal and external resources, two separate
DNS servers shall be established to handle each type of resource. The primary and
secondary DNS servers shall be geographically separated to as to prevent both from
experiencing downtime due to power failures or natural disasters.
c. A limited number of alias records must be added to zones. Canonical Name (CNAME)
resource records (RRs) must not be used where they are not needed to alias a host name
used in a host resource record. Alias names must not be used in other resource records.
d. If Active Directory is used, directory-integrated storage must be implemented for DNS
zones for increased security, fault tolerance, simplified deployment and management.
e. Zone integration is encouraged. For example, Active Directory domain controllers must
correspond in a direct one-to-one mapping to DNS servers. This can simplify planning
and troubleshooting DNS and Active Directory replication problems because the same
server computers are used in both topologies.
f. Employing directory-integrated storage enables administrators to select different
replication scopes that replicate DNS zone data throughout the directory. This will enable
administrators to selectively replicate DNS zone data to domains, forests, or by using
Active Directory.
g. Any DNS server hosting a directory-integrated zone must serve as a primary DNS server
for that zone. This enables multiple DNS servers to update the same zone data,
eliminating a single point of failure associated with a conventional single-master DNS
topology, where updates may only be done to a single DNS server for a given zone.
h. Secondary zones to assist in off-loading DNS query traffic must be employed wherever it
makes sense.
i. Secondary servers can be used as backups for DNS clients. This allows you to use
secondary servers as a means to load balance DNS query traffic on your network and
reserve your DNS-enabled primary servers for use only by those clients that need them to
perform dynamic registration and updates of their A and PTR RRs.
j. DNS software must not be running or present in hosts that are not designated as name
servers. The possibility arises in the case of DNS BIND software because many versions
of Unix (including Solaris and Linux versions) come installed with BIND as default.
20. Session Authenticity (SC-23) - Common
Sessions are vulnerable to being hijacked after the relationship between the two devices has been
established, and proper session authenticity protection is required of SBA communications.
Methods to prevent session hijacking include:
a. Use of a long random number or string as the session key. This reduces the risk that an
attacker could simply guess a valid session key through trial and error or brute force
attacks.
b. Regenerating the session id after a successful login. This prevents session fixation
because the attacker does not know the session id of the user after he has logged in.
SOP 90 47 3
Effective Date: August 28, 2012 104
c. Encryption of the data passed between the parties; in particular the session key. This
technique is widely relied-upon by web-based banks and other e-commerce services,
because it completely prevents sniffing-style attacks.
d. Some services make secondary checks against the identity of the user. For example, a
web server could check with each request made that the IP address of the user matched
the one last used during that session. This does not prevent attacks by somebody who
e. shares the same IP address, however, and could be frustrating for users whose IP address
is liable to change during a browsing session.
f. Alternatively, some services will change the value of the cookie with each and every
request. This dramatically reduces the window in which an attacker can operate and
makes it easy to identify whether an attack has taken place, but can cause other technical
problems (for example, preventing the back button from working properly, on the web).
21. Fail in Known State (SC-24)
For High impact systems, the information system fails to a closed-state preserving system state
information in failure.
22. Protection of Information at Rest (SC-28)
SBA will employ protections to safeguard the confidentiality and integrity of information at rest
in Moderate and High impact systems.
23. Information System Partitioning (SC-32)
SBA will partition Moderate and High impact information systems into components residing in
separate physical domains or environments as deemed necessary.
SOP 90 47 3
Effective Date: August 28, 2012 105
CHAPTER 17 – System and Information Integrity
1. System and Information Integrity Policy and Procedures (SI-1) - Common
System and information integrity (SI) refers to the degree in which a system (or system
component) prevents unauthorized access to, or modification of, computer programs or data.
This concept can be viewed as guarding against improper information modification or
destruction of data, and includes ensuring information non-repudiation and authenticity.
In order to ensure system and information integrity, it is critical that SBA information systems
comply with the guidance and recommendations outlined in the policies and procedures
referenced in the tables above.
2. Flaw Remediation (SI-2) - Hybrid
Flaw remediation requires that discovered security flaws are tracked and corrected by the
developer or system operator/administrators. All information systems in use at SBA must
document and follow processes whereby information system flaws are identified, reported, and
corrected.
Proper flaw remediation includes the ongoing patch and security vulnerability management
processes. Sections CM-2, Configuration Management, IR-4, Incident Monitoring, SI-5, Security
Alerts, and RA-5, Vulnerability Scanning, contain requirements regarding ongoing management
of vulnerabilities identified through either the manufacturer or security alerts, or through internal
and external assessments. All vulnerabilities or exposures identified shall be tracked by an
established flaw remediation process and handled in accordance with the following flaw
remediation principals:
a. Flaws discovered during security assessments, continuous monitoring or incident
response activities must be addressed expeditiously. Expeditious management may
include invoking emergency change procedures (see CM-3).
b. The flaw remediation process shall be centrally managed.
c. Flaw remediation procedures must describe the actions that are taken by the developer or
system administrator from the time each suspected security flaw is reported to the time
that it is resolved.
d. The flaw remediation reporting process must identify the nature and effects of each
security flaw in sufficient detail to be able to reproduce it.
e. After a defect is found, it must be prioritized and scheduled to be fixed. Often this is
subjectively determined by the severity of the problem as seen by the project manager.
f. Flaw remediation must be conducted in accordance with the change control policies and
procedures applicable to SBA. More information on the change control process is
available in the Configuration Management section of this SOP.
g. Flaw remediation action plans must include the names or titles of specific individuals
who must enact the required changes for the identified flaw.
h. SBA employs automated mechanisms monthly to determine the state of system
components with regard to flaw remediation.
SOP 90 47 3
Effective Date: August 28, 2012 106
3. Malicious Code Protection (SI-3) - Common
Information systems in use at SBA must be protected from malicious code, either introduced
from outside or from inside of the assessment and authorization boundary. All malicious code
protection mechanisms employed for SBA information systems must include the capability to
update automatically. Virus protection must be employed at critical information system entry and
exit points (e.g., firewalls, electronic mail servers, remote-access servers) and at workstations,
servers, or mobile computing devices on the network.
Virus or malicious code protections implemented within SBA must include the ability to both
detect and eradicate any malicious code identified.
SBA virus protection mechanisms must update virus protection signatures daily, in accordance
with organizational configuration management policy and procedures.
The following malicious code protections must be employed by SBA information systems:
a. Information systems (including servers, workstations and mobile computing devices)
must implement malicious code protection that includes a capability for automatic
updates.
b. All virus definitions must be up-to-date, in accordance with manufacturer’s and SBA
guidelines.
c. Non-privileged users must be prevented from circumventing malicious code protection
capabilities.
d. Malicious code must be prevented from entering from the e-mail system by:
(1) Filtering potentially dangerous attachment types (e.g., .vbs, .ws, .wsc file
extensions) at the mail server or mail gateway.
(2) Blocking active content (the most popular types of active content are ActiveX,
Java, JavaScript, and Visual Basic Script), which often comes in the form of a
client side scripting language, or control object. (See Mobile Code, SC-18, for
more information.)
4. Information System Monitoring Tools and Techniques (SI-4) - Hybrid
Security of the SBA Information Technology (IT) infrastructure is vital to protecting SBA
computer systems and information. Proactive monitoring to detect attempts at unauthorized
access is an important tool to accomplish this goal. SBA will implement and maintain IDS and
IDP in its computing facilities. Both host-based and network-based intrusion detection systems
must be deployed to protect SBA infrastructure. All inbound and outbound communications
must be monitored for unusual or unauthorized activities or conditions. A three-tiered approach
to providing information system monitoring must be employed.
a. Tier one deployment includes highly critical host devices located in the external-
parameter of the network. These include critical Web, mail and other devices located in
the DMZ or extranet (Internet facing network segments within or outside the DMZ).
b. Tier two consists of other non-critical DMZ devices.
SOP 90 47 3
Effective Date: August 28, 2012 107
c. Tier three would consist of all other devices located within the protected private network
inside the DMZ that are critical or contain confidential data such as client, financial and
databases.
Information system monitoring can be accomplished through the use of two different types of
devices; the network-based IDS and the host-based IDS.
For Moderate and High impact systems, SBA will provide support for:
a. Near real-time analysis of events;
b. Near real-time alerts when a compromise or potential compromise occur; and
c. Prevention of non-privileged users circumventing intrusion detection and prevention
capabilities.
5. Security Alerts and Advisories (SI-5) - Common
To reduce the security risks posed by software vulnerabilities, SBA incident response personnel,
network administrators, security administrators, and intrusion detection staff must stay abreast of
current security alerts and advisories. This may be accomplished through a number of different
means such as:
a. Subscribing to an operating system or hardware device’s manufacturer e-mail alerts. Such
alerts can advise of recommended patches, identified vulnerabilities, expiration of
support coverage, and other security-related events or information.
b. Subscribing to security alerts issued by US-CERT.
c. A designated team may issue advisories that describe new vulnerabilities in operating
systems and applications and provide information on mitigating the vulnerabilities.
6. Security Functionality Verification (SI-6) - Common
SBA information systems categorized as High impact must include functionality that verifies the
correct operation of security functions operating within the information system. Such verification
services must notify system administrators of any failed or inoperable security functionality.
Information system owners and information system security staff must determine, using a risk-
based analysis, the appropriate actions to take in response to information system security
functionality failure. Such reactions can include:
a. Shutting the information system down until the problem is corrected
b. Re-starting the information system
Security functionality verification can occur upon system boot, system shutdown, or on an
active, ongoing basis (security function monitoring). Precautions taken must be commensurate
with the criticality of the data contained within the information system, and must be based upon
the risk-based analysis referenced above.
7. Software and Information Integrity (SI-7) - Common
This control is mandatory for Moderate and High impact systems only. Systems must look for
evidence of information tampering, errors, and omissions. SBA must re-assess the integrity of
software by performing monthly integrity scans of the system.
SOP 90 47 3
Effective Date: August 28, 2012 108
High systems must follow good software engineering practices with regard to commercial off-
the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks, cryptographic
hashes, etc.) and use tools to automatically monitor the integrity of the information system and
the applications it hosts.
8. Spam Protection (SI-8) - Common
This control is mandatory for Moderate and High systems only. There are always entities that
attempt to exploit any means of communication to publicize their ideas or products, including
email. Spam is unsolicited commercial e-mail. Most email users receive spam on a daily basis.
Restricting spam not only reduces the amount of time SBA staff must spend wading through
unwanted email, it will reduce mailbox size by reducing the numbers of email received, which in
turn reduces server storage requirements. To control spam messages, administrators must address
the following three concerns:
a) Ensure that spam cannot be sent from the mail servers they control;
b) Implement spam filtering for inbound messages; and
c) Block messages from known spam-sending servers
High systems shall also use centrally managed spam protection mechanisms.
9. Information Input Restrictions (SI-9) - Hybrid
This control is mandatory for moderate and high systems only. Information input restrictions
requires SBA to assure that only authorized personnel are able to input information to the
system. User authorization is granted based on job requirements and responsibilities.
10. Information Accuracy, Completeness, Validity, and Authenticity (SI-10) - Hybrid
Moderate and high impact systems must have the ability to check inputted information for
accuracy, completeness, validity, and authenticity. SBA must ensure that the system:
a. Checks for accuracy, completeness, validity, and authenticity of information as close to
the point of origin as possible.
b. Employs rules to check the valid syntax of information inputs to verify that inputs match
specified definitions for format and content.
c. Pre-screens information inputs passed to interpreters to prevent the content from being
unintentionally interpreted as commands.
d. Checks the accuracy, completeness, validity, and authenticity of information to the extent
guided by organizational policy and operational requirements.
11. Error Handling (SI-11) - Hybrid
This control is mandatory for moderate and high systems only. The system identifies and handles
error conditions quickly without providing data that could be exploited. Error messages are
revealed only to authorized personnel. Error messages provide timely and useful information
without revealing potentially harmful information that could be used by adversaries. Sensitive
information and PII (e.g., account numbers, social security numbers, and credit card numbers)
are not listed in error logs or associated administrative messages.
SOP 90 47 3
Effective Date: August 28, 2012 109
12. Information Output Handling and Retention (SI-12) - Hybrid
This control is mandatory for moderate and high systems only. The focus of this control is the
handling and retention of output from the information system as required by applicable laws,
Executive Orders, directives, policies, regulations, and standards (as needed) to meet operational
requirements.
This control is concerned with organization information management, such as information
management office, records retention, physical security, document handling, retention, storage,
etc. While this will often be implemented as a common control, it is possible for an information
system to produce output with information-system-specific handling caveats resulting in a hybrid
control.
SOP 90 47 3
Effective Date: August 28, 2012 110
Appendix A – Media Sanitation Media Type Clear Purge Destruction
Hard Copy Storage
Paper and microforms L, N, K
Hand-Held Devices
Cell Phones A I, J, K, L
Personal Digital Assistant (PDA) (i.e., Palm,
PocketPC, etc.)
A I, K, L
Networking Devices
Routers (home, home office, enterprise) A I, J, K, L
Equipment
Copy Machines A I, J, K, L
Fax Machines A I, J, K, L
Magnetic Disks
Floppies B G I, L
ATA Hard Drives B H, G, B I, J, K, L
USB Removable Media (Pen Drives, Thumb Drives,
Flash Drives, Memory Sticks) with Hard Drives
B H, G, B I, J, K, L
Zip Disks B G I, L
SCSI Drives B G I, J, K, L
Optical Disks
CDs O, L, J
DVDs O, L, J
Memory
Compact Flash Drives, SD B I, J, K, L
Dynamic Random Access Memory (DRAM) C I, J, K
Electronically Alterable PROM (EAPROM) D I, J, K
Electronically Erasable PROM (EEPROM) B, E I, J, K, L
Erasable Programmable ROM (EPROM) F,A I, J, K, L
Field Programmable Gate Array (FPGA) Devices
(Non-Volatile)
B I, J, K
Field Programmable Gate Array (FPGA) Devices
(Volatile)
C I, J, K
Flash Cards B I, J, K
Flash EPROM (FEPROM) D B, D I, J, K, L
Magnetic Core Memory A,G B, G, E I, J, K
Non Volatile RAM (NOVRAM) B, C I, J, K
PC Cards or Personal Computer Memory Card
International Association (PCMCIA) Cards
J, L, M
Programmable ROM (PROM) J
RAM C I, J, K
ROM I, J, K
USB Removable Media (Pen Drives, Thumb Drives,
Flash Drives, Memory Sticks) without Hard Drives
B I, J, K
Smart Cards L, N
Magnetic Cards
SOP 90 47 3
Effective Date: August 28, 2012 111
Media Type Clear Purge Destruction
Magnetic Cards B G I, J
SOP 90 47 3
Effective Date: August 28, 2012 112
Media Sanitation Legend A Manually delete all information if possible, then perform a full manufacturer’s reset to reset the equipment
back to its factory default settings. Please contact the manufacturer for proper sanitization procedure.
B Overwrite media by using agency-approved and validated overwriting technologies/methods/tools.
C Purge by powering off and removing the battery (if battery backed).
D Perform a full chip purge as per manufacturer’s data sheets.
E Remove all labels or markings that indicate previous use or confidentiality.
F Clear by performing an ultraviolet purge according to the manufacturer's recommendations, but increase the
time requirement by a factor of 3.
G Degauss in an NSA/CSS-approved degausser. Purge hard disk drives by either purging the hard disk drive in
an NSA/CSS-approved automatic degausser or by disassembling the hard disk drive and purging the
enclosed platters with an NSA/CSS-approved degaussing wand. Degaussing any current generation hard
disk will render the drive permanently unusable. All steel shielding materials (e.g., chassis, case, or
mounting brackets) must be removed before degaussing.
H Purge using Secure Erase. The Secure Erase software can be download from the University of California,
San Diego (UCSD) CMRR site.
I Shred
J Disintegrate. Optical disk media shredders or disintegrator devices must reduce to particles that have
nominal edge dimensions of five millimeters (5 mm) and surface area of twenty-five square millimeters (25
mm). This is a current acceptable particle size. Any future disk media shredders obtained must reduce CD to
surface area of .25mm.
K Pulverize
L Incinerate in a licensed incinerator
M Use a disintegrator to reduce the card's internal circuit board and components to particles that are nominally
two (2) millimeters in size.
N Cut and destroy paper using cross cut shredders which produce particles that are 1 x 5 millimeters in size.
For smart card devices & data storage tokens that are in credit card form, cut or crush the smart card's
internal memory chip using metals snips, a pair of scissors, or a strip cut shredder (nominal 2 mm wide
cuts).
O Removing the Information bearing layers of CD/DVD media using a commercial optical disk grinding
device.
SOP 90 47 3
Effective Date: August 28, 2012 113
Appendix B – Life Cycle Principles Life Cycle Stage
Principle
Init
iati
on
Dev
elo
pm
ent/
Acq
uis
itio
n
Imp
lem
ent
Op
era
tio
n/
Ma
inte
na
nce
Dis
po
sal
Establish a sound security policy as the “foundation” for design ✔ ✔ ✔ ✔
Treat security as an integral part of the overall system design ✔
Clearly delineate the physical and logical security boundaries governed by associated security policies ✔ ✔
Ensure that developers are trained in how to develop secure software ✔
Reduce risk to an acceptable level
Assume that external systems are insecure ✔
Identify potential trade-offs between reducing risk and increased costs and decrease in other aspects of
operational effectiveness
Implement tailored system security measures to meet organizational security goals ✔ ✔ ✔
Protect information while being processed, in transit, and in storage ✔ ✔ ✔
Consider custom products to achieve adequate security ✔ ✔ ✔
Protect against all likely classes of “attacks ✔ ✔ ✔
Where possible, base security on open standards for portability and interoperability ✔ ✔
Use common language in developing security requirements
Design security to allow for regular adoption of new technology, including a secure and logical
technology upgrade process
✔
Strive for operational ease of use ✔ ✔
Implement layered security (Ensure no single point of vulnerability) ✔ ✔ ✔
Design and operate an IT system to limit damage and to be resilient in response ✔
Provide assurance that the system is, and continues to be, resilient in the face of expected threats ✔ ✔ ✔
Limit or contain vulnerabilities ✔ ✔
Isolate public access systems from mission critical resources (e, data, processes, etc.) ✔ ✔ ✔
Use boundary mechanisms to separate computing systems and network infrastructures ✔
Design and implement audit mechanisms to detect unauthorized use and to support incident
investigations ✔ ✔
Develop and exercise contingency or disaster recovery procedures to ensure appropriate availability ✔ ✔ ✔
Strive for simplicity ✔ ✔
Minimize the system elements to be trusted ✔ ✔
Implement least privilege ✔ ✔ ✔
Do not implement unnecessary security mechanisms ✔ ✔ ✔ ✔ ✔
Ensure proper security in the shutdown or disposal of a system ✔ ✔
Identify and prevent common errors and vulnerabilities ✔
SOP 90 47 3
Effective Date: August 28, 2012 114
Life Cycle Stage
Principle
Init
iati
on
Dev
elo
pm
ent/
Acq
uis
itio
n
Imp
lem
ent
Op
era
tio
n/
Ma
inte
na
nce
Dis
po
sal
Implement security through a combination of measures distributed physically and logically ✔ ✔ ✔
Formulate security measures to address multiple overlapping information domains ✔ ✔ ✔
Authenticate users and processes to ensure appropriate access control decisions both within and across
domains ✔ ✔ ✔
Use unique identities to ensure accountability ✔ ✔ ✔
One check “✔” signifies the principle can be used to support the life-cycle phase, and star “”
signifies the principle is key to successful completion of the life-cycle phase.
SOP 90 47 3
Effective Date: August 28, 2012 115
Appendix C – Glossary of Terms
Access Ability to make use of any information system (IS) resource.
Access Control The process of granting or denying specific requests for obtaining and using information
and related information processing services; and, to enter specific physical facilities (e.g.,
Federal buildings, military establishments, and border crossing entrances).
Access Control Lists (ACLs) This is a register of users (including groups, machines, and processes) who have been
given permission to use a particular system resource, and the types of access they have
been permitted.
Accountability The security goal that generates the requirement for actions of an entity to be traced
uniquely to that entity. This supports non-repudiation, deterrence, fault isolation, intrusion
detection and prevention, and after-action recovery and legal action.
Accreditation The official management decision given by a senior agency official to authorize operation
of an information system and to explicitly accept the risk to agency operations (including
mission, functions, image, or reputation), agency assets, or individuals, based on the
implementation of an agreed-upon set of security controls.
Accreditation Boundary All components of an information system to be accredited by an authorizing official and
excludes separately accredited systems, to which the information system is connected.
Accreditation Package The evidence provided to the authorizing official to be used in the security accreditation
decision process.
Evidence includes, but is not limited to the system security plan; the assessment results
from the security certification; and, the plan of action and milestones.
Adequate Security Security commensurate with the risk and the magnitude of harm resulting from the loss,
misuse, or unauthorized access to or modification of information.
Administrative Safeguards Administrative actions, policies, and procedures to manage the selection, development,
implementation, and maintenance of security measures to protect electronic health
information and to manage the conduct of the covered entity's workforce in relation to
protecting that information.
Advanced Encryption
Standard (AES)
The Advanced Encryption Standard specifies a U.S. Government-approved cryptographic
algorithm that can be used to protect electronic data. The AES algorithm is a symmetric
block cipher that can encrypt (encipher) and decrypt (decipher) information.
Agent A program used in distributed denial of service (DDoS) attacks that send malicious traffic
to hosts based on the instructions of a handler.
Application The use of information resources (information and information technology) to satisfy a
specific set of user requirements.
Assurance One of the five “Security Goals.” It involves support for our confidence that the other four
security goals (integrity, availability, confidentiality, and accountability) have been
adequately met by a specific implementation. “Adequately met” includes functionality that
performs correctly; sufficient protection against unintentional errors (by users or software);
and, sufficient resistance to intentional penetration or by-pass.
Audit Independent review and examination of records and activities to assess the adequacy of
system controls, to ensure compliance with established policies and operational
procedures, and to recommend necessary changes in controls, policies, or procedures
Audit Data Chronological record of system activities to enable the reconstruction and examination of
the sequence of events and changes in an event.
Audit Trail A record showing who has accessed an Information Technology (IT) system and what
operations the user has performed during a given period.
Authenticate To confirm the identity of an entity when that identity is presented.
Authentication Verifying the identity of a user, process, or device, often as a prerequisite to allowing
access to resources in an information system.
Authentication Mechanism Hardware or software-based mechanisms that force users to prove their identity before
accessing data on a device.
Authorization The official management decision given by a senior agency official to authorize operation
of an information system and to explicitly accept the risk to agency operations (including
SOP 90 47 3
Effective Date: August 28, 2012 116
mission, functions, image, or reputation), agency assets, or individuals, based on the
implementation of an agreed-upon set of security controls.
Authorizing Official Official with the authority to formally assume responsibility for operating an information
system at an acceptable level of risk to agency operations (including mission, functions,
image, or reputation), agency assets, or individuals. Synonymous with Designated
Approving/Accrediting Authority (DAA).
Availability Ensuring timely and reliable access to and use of information.
Baseline Security The minimum security controls required for safeguarding an IT system based on its
identified needs for confidentiality, integrity and/or availability protection.
Boundary Protection Monitoring and control of communications at the external boundary between information
systems completely under the management and
control of the organization and information systems not completely under the management
and control of the organization, and at key internal boundaries between information
systems completely under the management and control of the organization, to prevent and
detect malicious and other unauthorized communication, employing controlled interfaces
(e.g., proxies, gateways, routers, firewalls, encrypted tunnels).
Boundary Router A boundary router is located at the organizations boundary to an external network.
Business Continuity Plan
(BCP)
The documentation of a predetermined set of instructions or procedures that describe how
an organization’s business functions will be sustained during and after a significant
disruption.
Business Impact Analysis
(BIA)
An analysis of an IT system’s requirements, processes, and interdependencies used to
characterize system contingency requirements and priorities in the event of a significant
disruption.
Business Recovery-
Resumption Plan (BRP)
The documentation of a predetermined set of instructions or procedures that describe how
business processes will be restored after a significant disruption has occurred.
Certificate A set of data that uniquely identifies an entity, contains the entity’s public key and
possibly other information, and is digitally signed by a trusted party, thereby binding the
public key to the entity. Additional information in the certificate could specify how the key
is used and its crypto period.
Certification 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.
Certification Agent The individual, group, or organization responsible for conducting a security certification.
Assessment and
authorization (C&A)
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. Accreditation is the official management decision given by a senior agency
official to authorize operation of an information system and to explicitly accept the risk to
agency operations (including mission, functions, image, or reputation), agency assets, or
individuals, based on the implementation of an agreed-upon set of security controls.
Chief Information Officer
(CIO)
Agency official responsible for providing advice and other assistance to the head of the
executive agency and other senior management personnel of the agency to ensure that
information technology is acquired and information resources are managed in a manner
that is consistent with laws, executive orders, directives, policies, regulations, and
priorities established by the head of the agency; developing, maintaining, and facilitating
the implementation of a sound and integrated information technology architecture for the
agency; and, promoting the effective and efficient design and operation of all major
information resources management processes for the agency, including improvements to
work processes of the agency.
Clinger-Cohen Act of 1996 Also known as Information Technology Management Reform Act. A statute that
substantially revised the way that IT resources are managed and procured, including a
requirement that each agency design and implement a process for maximizing the value
and assessing and managing the risks of IT investments.
SOP 90 47 3
Effective Date: August 28, 2012 117
Common Security Control Security control that can be applied to one or more agency information systems and has
the following properties the development, implementation, and assessment of the control
can be assigned to a responsible official or organizational element (other than the
information system owner); and, the results from the assessment of the control can be used
to support the security assessment and authorization processes of an agency information
system where that control has been applied.
Compensating Security
Controls
The management, operational, and technical controls (i.e., safeguards or countermeasures)
employed by an organization in lieu of the recommended controls in the low, moderate, or
high baselines described in NIST Special Publication 800-53, that provide equivalent or
comparable protection for an information system.
Computer Security Incident A violation or imminent threat of violation of computer security policies, acceptable use
policies, or standard computer security practices.
Computer Security Incident
Response Team (CSIRT)
A capability set up for the purpose of assisting in responding to computer security-related
incidents; also called a Computer Incident Response Team (CIRT) or a CIRC (Computer
Incident Response Center, Computer Incident Response Capability).
Confidentiality Preserving authorized restrictions on information access and disclosure, including means
for protecting personal privacy and proprietary information.
Configuration Control Process for controlling modifications to hardware, firmware, software, and Documentation
to ensure the information system is protected against improper modifications prior to,
during, and after system implementation.
Contingency Plan Management policy and procedures designed to maintain or restore business operations,
including computer operations, possibly at an alternate location, in the event of
emergencies, system failures, or disaster.
Continuity of Operations
Plan (COOP)
A predetermined set of instructions or procedures that describe how an organization’s
essential functions will be sustained for up to 30 days as a result of a disaster event before
returning to normal operations.
Criticality Level Refers to the (consequences of) incorrect behavior of a system. The more serious the
expected direct and indirect effects of incorrect behavior, the higher the criticality level.
Cryptographic Module The set of hardware, software, firmware, or some combination thereof that implements
cryptographic logic or processes, including cryptographic algorithms, and is contained
within the cryptographic boundary of the module.
Cryptography The discipline that embodies principles, means and methods for providing information
security, including confidentiality, data integrity, non-repudiation, and authenticity.
Data Encryption Standard
(DES)
A U.S. Government-approved, symmetric cipher, encryption algorithm used by business
and civilian government agencies. The Advanced Encryption Standard (AES) is designed
to replace DES. The original “single” DES algorithm is no longer secure because it is now
possible to try every possible key with special purpose equipment or a high performance
cluster. Triple DES, however, is still considered to be secure. (See glossary)
Data Integrity The property that data has not been altered in an unauthorized manner. Data integrity
covers data in storage, during processing, and while in transit.
Decryption The process of changing cipher text into plaintext using a cryptographic algorithm and
key.
Demilitarized Zone (DMZ) A network created by connecting two firewalls. Systems that are externally accessible but
need some protections are usually located on DMZ networks.
Denial of Service (DoS) The prevention of authorized access to resources or the delaying of time-critical
operations. (Time-critical may be milliseconds or it may be hours, depending upon the
service provided.)
Digital Signature An asymmetric key operation where the private key is used to digitally sign an electronic
Document and the public key is used to verify the signature. Digital signatures provide
authentication and integrity protection.
Disaster Recovery Plan
(DRP)
A written plan for processing critical applications in the event of a major hardware or
software failure or destruction of facilities.
Electronic Authentication (E-
authentication)
The process of establishing confidence in user identities electronically presented to an
information system.
Encryption Encryption is the conversion of data into a form, called a cipher text, which cannot be
SOP 90 47 3
Effective Date: August 28, 2012 118
easily understood by unauthorized people.
Environment Aggregate of external procedures, conditions, and objects affecting the development,
operation, and maintenance of an information system.
Federal Information
Processing Standard (FIPS)
A standard for adoption and use by Federal agencies that has been developed within the
Information Technology Laboratory and published by the National Institute of Standards
and Technology, a part of the U.S. Department of Commerce. A FIPS covers some topic in
information technology in order to achieve a common level of quality or some level of
interoperability.
FIPS PUB An acronym for Federal Information Processing Standards Publication. FIPS publications
(PUB) are issued by NIST after approval by the Secretary of Commerce.
Firewall A gateway that limits access between networks in accordance with local security policy.
FISMA Federal Information Security Management Act - requires agencies to integrate IT security
into their capital planning and enterprise architecture processes at the agency, conduct
annual IT security reviews of all programs and systems, and report the results of those
reviews to the Office of Management and Budget (OMB).
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.
High Impact System An information system in which at least one security objective (i.e., confidentiality,
integrity, or availability) is assigned a FIPS 199 potential impact value of high.
Identification The process of discovering the true identity (i.e., origin, initial history) of a person or item
from the entire collection of similar persons or items.
Identifier A unique data string used as a key in the biometric system to name a person’s identity and
its associated attributes.
Identity The set of physical and behavioral characteristics by which an individual is uniquely
recognizable.
Identity Verification The process of confirming or denying that a claimed identity is correct by comparing the
credentials (something you know, something you have, something you are) of a person
requesting access with those previously proven and stored in the PIV Card or system and
associated with the identity being claimed.
Impact The magnitude of harm that can be expected to result from the consequences of
unauthorized disclosure of information, unauthorized modification of information,
unauthorized destruction of information, or loss of information or information system
availability.
Incident An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or
availability of an information system or the information the system processes, stores, or
transmits or that constitutes a violation or imminent threat of violation of security policies,
security procedures, or acceptable use policies.
Incident Handling The mitigation of violations of security policies and recommended practices.
Incident Response Plan The documentation of a predetermined set of instructions or procedures to detect, respond
to, and limit consequences of malicious cyber-attacks against an organization’s IT
systems(s).
Information Resources Information and related resources, such as personnel, equipment, funds, and information
technology.
Information System A discrete set of information resources organized for the collection, processing,
maintenance, use, sharing, dissemination, or disposition of information. Within DOI, this
definition is further expounded upon to read: as defined by FISMA, any equipment or
interconnected system or subsystems of equipment that is used in the automatic
acquisition, storage, manipulation, management, movement, control, display, switching,
interchange, transmission, or reception of data or information, and includes computers and
computers networks; ancillary equipment; software, firmware, and related procedures;
services, including supporting services; and related resources.
Information System Owner Official responsible for the overall procurement, development, integration, modification,
or operation and maintenance of an information system.
Information Technology Any equipment or interconnected system or subsystem of equipment that is used in the
automatic acquisition, storage, manipulation, management, movement, control, display,
switching, interchange, transmission, or reception of data or information by the executive
SOP 90 47 3
Effective Date: August 28, 2012 119
agency. For purposes of the preceding sentence, equipment is used by an executive agency
if the equipment is used by the executive agency directly or is used by a contractor under a
contract with the executive agency which— 1) requires the use of such equipment; or 2)
requires the use, to a significant extent, of such equipment in the performance of a service
or the furnishing of a product. The term information technology includes computers,
ancillary equipment, software, firmware and similar procedures, services (including
support services), and related resources.
Information Type A specific category of information (e.g., privacy, medical, proprietary, financial,
investigative, contractor sensitive, security management), defined by an organization or in
some instances, by a specific law, executive order, directive, policy, or regulation.
Integrity Guarding against improper information modification or destruction, and includes ensuring
information non-repudiation and authenticity.
Interconnection Security
Agreement (ISA)
An agreement established between the organizations that own and operate connected IT
systems to Document the technical requirements of the interconnection. The ISA also
supports a Memorandum of Understanding or Agreement (MOU/A) between the
organizations.
Intrusion Detection
System (IDS) Software that looks for suspicious activity and alerts administrators.
IP Address An IP address is a unique number for a computer that is used to determine where messages
transmitted on the Internet must be delivered. The IP address is analogous to a house
number for ordinary postal mail.
IP Security (IPsec) An Institute of Electrical and Electronic Engineers (IEEE) standard, Request For
Comments (RFC) 2411, protocol that provides security capabilities at the Internet Protocol
(IP) layer of communications. IPsec’s key management protocol is used to negotiate the
secret keys that protect Virtual Private Network (VPN) communications, and the level and
type of security protections that will characterize the VPN. The most widely used key
management protocol is the Internet Key Exchange (IKE) protocol.
IT Security Awareness and
Training Program
Explains proper “Rules of Behavior” for the use of agency IT systems and information.
The program communicates IT security policies and procedures that need to be followed.
Least Privilege The security objective of granting users only those accesses they need to perform their
official duties.
Low Impact System An information system in which all three security objectives (i.e., confidentiality, integrity,
and availability) are assigned a FIPS 199 potential impact of low.
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. Note: All federal applications require some level of
protection. Certain applications, because of the information in them, however, require
special management oversight and must be treated as major. Adequate security for other
applications must be provided by security of the systems in which they operate.
Malicious Code Software or firmware intended to perform an unauthorized process that will have adverse
impact on the confidentiality, integrity, or availability of an information system. A virus,
worm, Trojan horse, or other code-based entity that infects a host.
Malware A program that is inserted into a system, usually covertly, with the intent of compromising
the confidentiality, integrity, or availability of the victim’s data, applications, or operating
system or of otherwise annoying or disrupting the victim.
Media Physical devices or writing surfaces including but not limited to magnetic tapes, optical
disks, magnetic disks, LSI memory chips, printouts (but not including display media) onto
which information is recorded, stored, or printed within an information system.
Media Sanitization A general term referring to the actions taken to render data written on media unrecoverable
by both ordinary and extraordinary means.
Memorandum of
Understanding/Agreement
(MOU/A)
A document established between two or more parties to define their respective
responsibilities in accomplishing a particular goal or mission. In this guide, an MOU/A
defines the responsibilities of two or more organizations in establishing, operating, and
securing a system interconnection.
Message Authentication Code
(MAuC)
A cryptographic check sum on data that uses a symmetric key to detect both accidental
and intentional modifications of the data.
Mobile Code Software programs or parts of programs obtained from remote information systems,
SOP 90 47 3
Effective Date: August 28, 2012 120
transmitted across a network, and executed on a local information system without explicit
installation or execution by the recipient.
Mode of Operation An algorithm for the cryptographic transformation of data that features a symmetric key
block cipher algorithm.
Moderate Impact System An information system in which at least one security objective (i.e., confidentiality,
integrity, or availability) is assigned a FIPS 199 potential impact value of moderate and no
security objective is assigned a FIPS 199 potential impact value of high.
Multi-Factor Authentication Authentication controls that generally consist of something a user knows [password], has
[token, PIV, CAC], or is [biometric]; minimally two-factor authentication is a combination
of these elements - e.g. a hard token and complex password – NOT A {USER ID AND
PASSWORD}, OR A {PASSWORD AND ANOTHER PASSWORD}).
Non-repudiation Assurance that the sender of information is provided with proof of delivery and the
recipient is provided with proof of the sender’s identity, so neither can later deny having
processed the information.
Password A string of characters (letters, numbers, and other symbols) used to authenticate an identity
or to verify access authorization.
Password Protected The ability to protect a file using a password access control, protecting the data contents
from being viewed with the appropriate viewer unless the proper password is entered.
Personally Identifiable
Information (PII)
Any information about an individual maintained by an agency, including but not limited
to, education, financial transactions, medical history, and criminal or employment history
and information which can be used to distinguish or trace an individual's identity, such as
their name, social security number, date and place of birth, mother's maiden name,
biometric records, etc., including any other personal information which is linked or
linkable to an individual.
Personal Identity Verification
Card (PIV Card)
Physical artifact (e.g., identity card, “smart” card) issued to an individual that contains
stored identity credentials (e.g., photograph, cryptographic keys, digitized fingerprint
representation etc.) such that a claimed identity of the cardholder may be verified against
the stored credentials by another person (human readable and verifiable) or an automated
process (computer readable and verifiable).
Plan of Action and
Milestones (POA&M)
A Document that identifies tasks needing to be accomplished. It details resources required
to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled
completion dates for the milestones.
Potential Impact The loss of confidentiality, integrity, or availability could be expected to have a limited
adverse effect; a serious adverse effect, or a severe or catastrophic adverse effect on
organizational operations, organizational assets, or individuals.
Privacy Restricting access to subscriber or Relying Party information in accordance with Federal
law and Agency policy.
Privacy Impact Assessment An analysis of how information is handled to ensure handling conforms to applicable
legal, regulatory, and policy requirements regarding privacy; to determine the risks and
effects of collecting, maintaining and disseminating information in identifiable form in an
electronic information system; and to examine and evaluate protections and alternative
processes for handling information to mitigate potential privacy risks.
Public Key Infrastructure
(PKI)
A set of policies, processes, server platforms, software and workstations used for the
purpose of administering certificates and public-private key pairs, including the ability to
issue, maintain, and revoke public key certificates.
Remediation Plan A plan to perform the remediation of one or more threats or vulnerabilities facing an
organization’s systems. The plan typically includes options to remove threats and
vulnerabilities and priorities for performing the remediation.
Remote Access Access by users (or information systems) communicating external to an information
system security perimeter.
Remote Maintenance Maintenance activities conducted by individuals communicating external to an information
system security perimeter.
Residual Risk The remaining, potential risks after all IT security measures are applied. There is a residual
risk associated with each threat.
Risk The level of impact on agency operations (including mission, functions, image, or
reputation), agency assets, or individuals results from the operation of an information
system given the potential impact of a threat and the likelihood of that threat occurring.
SOP 90 47 3
Effective Date: August 28, 2012 121
Risk Analysis The process of identifying the risks to system security and determining the likelihood of
occurrence, the resulting impact, and the additional safeguards that mitigate this impact.
Part of risk management and synonymous with risk assessment.
Risk Assessment The process of identifying risks to agency operations (including mission, functions, image,
or reputation), agency assets, or individuals by determining the probability of occurrence,
the resulting impact, and additional security controls that would mitigate this impact. Part
of risk management, synonymous with risk analysis, and incorporates threat and
vulnerability analyses.
Risk Management The process of managing risks to agency operations (including mission, functions, image,
or reputation), agency assets, or individuals resulting from the operation of an information
system. It includes risk assessment; cost-benefit analysis; the selection, implementation,
and assessment of security controls; and the formal authorization to operate the system.
The process considers effectiveness, efficiency, and constraints due to laws, directives,
policies, or regulations.
Sanitization Process to remove information from media such that information recovery is not possible.
It includes removing all labels, markings, and activity logs.
Scanning Sending packets or requests to another system to gain information to be used in a
subsequent attack.
Secure Communication
Protocol
A communication protocol that provides the appropriate confidentiality, authentication and
content integrity protection.
Security Accreditation The official management decision given by a senior agency official to authorize operation
of an information system and to explicitly accept the risk to agency operations (including
mission, functions, image, or reputation), agency assets, or individuals, based on the
implementation of an agreed-upon set of security controls.
Security Control
Enhancements
Statements of security capability to build in additional, but related, functionality to a basic
control; and/or increase the strength of a basic control.
Security Impact Analysis The analysis conducted by an agency official, often during the continuous monitoring
phase of the security assessment and authorization process, to determine the extent to
which changes to the information system have affected the security posture of the system.
Security Label Explicit or implicit marking of a data structure or output media associated with an
information system representing the FIPS 199 security category, or distribution limitations
or handling caveats of the information contained therein.
Sensitive Information Any information, the loss, misuse, or unauthorized access to or modification of which
could adversely affect the national interest or the conduct of federal programs, or the
privacy to which individuals are entitled under section 552a of Title 5, United States Code
(the Privacy Act), but which has not been specifically authorized under criteria established
by an Executive Order or an Act of Congress to be kept secret in the interest of national
defense or foreign policy.
Sensitivity Used in this guideline to mean a measure of the importance assigned to information by its
owner, for the purpose of denoting its need for protection.
Sensitivity Levels A graduated system of marking (e.g., low, moderate, high) information and information
processing systems based on threats and risks that result if a threat is successfully
conducted.
System A discrete set of information resources organized for the collection, processing,
maintenance, use, sharing, dissemination, or disposition of information.
System Administrator A person who manages the technical aspects of a system.
System Development Life
Cycle (SDLC)
The scope of activities associated with a system, encompassing the system’s initiation,
development and acquisition, implementation, operation and maintenance, and ultimately
its disposal that instigates another system initiation.
System Interconnection The direct connection of two or more IT systems for the purpose of sharing data and other
information resources.
System-specific Security
Control
A security control for an information system that has not been designated as a common
security control.
System Security Plan Formal Document that provides an overview of the security requirements for the
information system and describes the security controls in place or planned for meeting
those requirements.
Technical Controls The security controls (i.e., safeguards or countermeasures) for an information system that
SOP 90 47 3
Effective Date: August 28, 2012 122
are primarily implemented and executed by the information system through mechanisms
contained in the hardware, software, or firmware components of the system.
Threat Any circumstance or event with the potential to adversely impact organizational operations
(including mission, functions, image, or reputation), organizational assets, or individuals
through an information system via unauthorized access, destruction, disclosure,
modification of information, and/or denial of service. Also, the potential for a threat-
source to successfully exploit a particular information system vulnerability.
Total Risk The potential for the occurrence of an adverse event if no mitigating action is taken (i.e.,
the potential for any applicable threat to exploit a system vulnerability).
Triple DES An implementation of the Data Encryption Standard (DES) algorithm that uses three
passes of the DES algorithm instead of one as used in ordinary DES applications. Triple
DES provides much stronger encryption than ordinary DES but it is less secure than AES.
Trustworthy System Computer hardware, software and procedures that are reasonably secure from intrusion
and misuse; provide a reasonable level of availability, reliability, and correct operation; are
reasonably suited to performing their intended functions; and, adhere to generally accepted
security procedures.
Unauthorized Access Occurs when a user, legitimate or unauthorized, accesses a resource that the user is not
permitted to use.
Unauthorized Disclosure An event involving the exposure of information to entities not authorized access to the
information.
Validation The process of demonstrating that the system under consideration meets in all respects the
specification of that system.
Verification The process of affirming that a claimed identity is correct by comparing the offered claims
of identity with previously proven information stored in the identity card or PIV system.
See Identity Verification.
Virtual Private Network
(VPN)
A virtual private network is a logical network that is established, at the application layer of
the Open Systems Interconnection (OSI) model, over an existing physical network and
typically does not include every node present on the physical network.
Vulnerability Weakness in an information system, system security procedures, internal controls, or
implementation that could be exploited or triggered by a threat source.
Wired Equivalent Privacy
(WEP)
Wired Equivalent Privacy, a security protocol for wireless local area networks (WLANs)
defined in the 802.11b standard. WEP was intended to provide the same level of security
as that of a wired LAN.
Wireless Application
Protocol (WAP) A standard for providing cellular telephones, pagers, and other handheld devices with
secure access to e-mail and text-based Web pages
SOP 90 47 3
Effective Date: August 28, 2012 123
Appendix D – Applicable NIST References
This table does not display all of the relevant NIST Documents for each control, but the most
relevant and applicable document in most cases.
Family Group Relevant NIST Document
Access Control AC
Access Control Policy and Procedures AC-1 NIST SP 800-100, Information Security SOP: A Guide
for Managers
Account Management AC-2
Access Enforcement AC-3 FIPS 201-1, Personal Identity Verification (PIV) of
Federal Employees and Contractors
Information Flow Enforcement AC-4 NIST SP 800-41, Guidelines on Firewalls and Firewall
Policy
Separation of Duties AC-5
Least Privilege AC-6 NIST SP 800-68, Guidance for Securing Microsoft
Windows XP Systems for IT Professionals: A NIST
Security Configuration Checklist
Unsuccessful Login Attempts AC-7 NIST SP 800-68, Guidance for Securing Microsoft
Windows XP Systems for IT Professionals: A NIST
Security Configuration Checklist
System Use Notification AC-8
Previous Logon Notification AC-9
Concurrent Session Control AC-10
Session Lock AC-11
Session Termination AC-12
Supervision and Review—Access
Control
AC-13
Permitted Actions without Identification
or Authentication
AC-14
Automated Marking AC-15
Automated Labeling AC-16 FIPS 188, Standard Security Labels for Information
Transfer
Remote Access AC-17 NIST SP 800-44, Guidelines on Securing Public Web
Servers
Wireless Access Restrictions AC-18 NIST SP 800-48, Wireless Network Security: 802.11,
Bluetooth, and Handheld Devices
Access Control for Portable and Mobile
Devices
AC-19
Use of External Information Systems AC-20 NIST SP 800-77, Guide to IPsec VPNs
Awareness and Training AT
Awareness Training Policies and
Procedures
AT-1 NIST SP 800-100, Information Security SOP: A Guide
for Managers
Security Awareness AT-2 NIST SP 800-50, Building an Information Technology
Security Awareness and Training Program
Security Training AT-3 NIST SP 800-16, Information Technology Security
Training Requirements: A Role- and Performance-
Based Model
Security Training Records AT-4 NIST SP 800-50, Building an Information Technology
Security Awareness and Training Program
SOP 90 47 3
Effective Date: August 28, 2012 124
Family Group Relevant NIST Document
Contacts with Security Groups and
Associations
AT-5
Audit and Accountability AU
Audit and Accountability Policy and
Procedures
AU-1 FIPS 200, Minimum Security Requirements for Federal
Information and Information Systems
Auditable Events AU-2 NIST SP 800-94, Guide to Intrusion Detection and
Prevention (IDP) Systems
Content of Audit Records AU-3 NIST SP 800-92, Guide to Computer Security Log
Management, September 2006
Audit Storage Capacity AU-4 NIST SP 800-92, Guide to Computer Security Log
Management, September 2006
Response to Audit Processing Failures AU-5 NIST SP 800-83, Guide to Malware Incident
Prevention and Handling
Audit Monitoring, Analysis, and
Reporting
AU-6 NIST SP 800-42, Guideline on Network Security
Testing
Audit Reduction and Report Generation AU-7 NIST SP 800-92, Guide to Computer Security Log
Management, September 2006
Time Stamps AU-8 NIST SP 800-92, Guide to Computer Security Log
Management, September 2006
Protection of Audit Information AU-9 NIST SP 800-92, Guide to Computer Security Log
Management, September 2006
Non-repudiation AU-10 NIST SP 800-95, Guide to Secure Web Services
Audit Record Retention AU-11 NIST SP 800-92, Guide to Computer Security Log
Management, September 2006
Certification, Accreditation, and
Security Assessments
CA
Certification, Accreditation, and Security
Assessment Policies and Procedures
CA-1 NIST SP 800-37, Guide for the Security Assessment
and authorization of Federal Information Systems
Security Assessments CA-2 NIST SP 800-53A, Guide for Assessing the Security
Controls in Federal Information Systems (Draft)
Information System Connections CA-3 NIST SP 800-47, Security Guide for Interconnecting
Information Technology Systems
Plan of Action and Milestones CA-5 NIST SP 800-30, Risk Management Guide for
Information Technology Systems
Security Accreditation CA-6 NIST SP 800-37, Guide for the Security Assessment
and authorization of Federal Information Systems
Continuous Monitoring CA-7 NIST SP 800-42, Guideline on Network Security
Testing
Configuration Management CM
Configuration Management Policy and
Procedures
CM-1 NIST SP 800-14, Generally Accepted Principles and
Practices for Securing Information Technology
Systems
Baseline Configuration CM-2 NIST SP 800-40, Creating a Patch and Vulnerability
Management Program
Configuration Change Control CM-3
Monitoring Configuration Changes CM-4 NIST SP 800-83, Guide to Malware Incident
Prevention and Handling
Access Restrictions for Change CM-5
SOP 90 47 3
Effective Date: August 28, 2012 125
Family Group Relevant NIST Document
Configuration Settings CM-6 NIST SP 800-70, Security Configuration Checklists
Program for IT Products: Guidance for Checklists
Users and Developers
Least Functionality CM-7
Information System Component
Inventory
CM-8 NIST SP 800-35, Guide to Information Technology
Security Services
Contingency Planning CP
Contingency Planning Policy and
Procedures
CP-1 NIST SP 800-34, Contingency Planning Guide for
Information Technology Systems
Contingency Plan CP-2 NIST SP 800-34, Contingency Planning Guide for
Information Technology Systems
Contingency Training CP-3 NIST SP 800-50, Building an Information Technology
Security Awareness and Training Program
Contingency Plan Testing and Exercises CP-4 NIST SP 800-84, Guide to Test, Training, and Exercise
Programs for IT Plans and Capabilities
Alternate Storage Site CP-6 NIST SP 800-34, Contingency Planning Guide for
Information Technology Systems
Alternate Processing Site CP-7 NIST SP 800-34, Contingency Planning Guide for
Information Technology Systems
Telecommunications Services CP-8 NIST SP 800-13, Telecommunications Security
Guidelines for Telecommunications Management
Network
Information System Backup CP-9
Information System Recovery and
Reconstitution
CP-10 NIST SP 800-83, Guide to Malware Incident
Prevention and Handling
Identification and Authentication IA
Identification and Authentication Policy
and Procedures
IA-1 FIPS 190, Guideline for the Use of Advanced
Authentication Technology Alternatives
User Identification and Authentication IA-2 FIPS 201-1, Personal Identity Verification (PIV) of
Federal Employees and Contractors
Device Identification and Authentication IA-3 NIST SP 800-73, Interfaces for Personal Identity
Verification
Identifier Management IA-4 NIST SP 800-73, Interfaces for Personal Identity
Verification
Authenticator Management IA-5 NIST SP 800-63, Electronic Authentication Guideline:
Recommendations of the National Institute of
Standards and Technology
Authenticator Feedback IA-6
Cryptographic Module Authentication IA-7 FIPS 140-2, Security Requirements for Cryptographic
Modules
Incident Response IR
Incident Response Policy and Procedures IR-1 FIPS 200, Minimum Security Requirements for Federal
Information and Information Systems
Incident Response Training IR-2 NIST SP 800-61, Computer Security Incident Handling
Guide
Incident Response Testing and Exercises IR-3 NIST SP 800-84, Guide to Test, Training, and Exercise
Programs for IT Plans and Capabilities
Incident Handling IR-4 NIST SP 800-61, Computer Security Incident Handling
Guide
SOP 90 47 3
Effective Date: August 28, 2012 126
Family Group Relevant NIST Document
Incident Monitoring IR-5 NIST SP 800-61, Computer Security Incident Handling
Guide
Incident Reporting IR-6 NIST SP 800-61, Computer Security Incident Handling
Guide
Incident Response Assistance IR-7 NIST SP 800-61, Computer Security Incident Handling
Guide
Maintenance MA
System Maintenance Policy and
Procedures
MA-1 NIST SP 800-100, Information Security SOP: A Guide
for Managers
Controlled Maintenance MA-2
Maintenance Tools MA-3
Remote Maintenance MA-4 NIST SP 800-77, Guide to IPsec VPNs
Maintenance Personnel MA-5
Timely Maintenance MA-6
Media Protection MP
Media Protection Policy and Procedures MP-1 NIST SP 800-100, Information Security SOP: A Guide
for Managers
Media Access MP-2
Media Labeling MP-3
Media Storage MP-4
Media Transport MP-5
Media Sanitization and Disposal MP-6 NIST SP 800-88, Guidelines for Media Sanitization
Physical and Environmental Protection PE
Physical and Environmental Protection
Policy and Procedures
PE-1 FIPS 200, Minimum Security Requirements for Federal
Information and Information Systems
Physical Access Authorizations PE-2
Physical Access Control PE-3 NIST SP 800-73, Interfaces for Personal Identity
Verification
Access Control for Transmission Medium PE-4 NIST SP 800-58, Security Considerations for Voice
Over IP Systems
Access Control for Display Medium PE-5
Monitoring Physical Access PE-6
Visitor Control PE-7
Access Records PE-8
Power Equipment and Power Cabling PE-9
Emergency Shutoff PE-10
Emergency Power PE-11 NIST SP 800-58, Security Considerations for Voice
Over IP Systems
Emergency Lighting PE-12
Fire Protection PE-13
Temperature and Humidity Controls PE-14
Water Damage Protection PE-15
Delivery and Removal PE-16
Alternate Work Site PE-17
SOP 90 47 3
Effective Date: August 28, 2012 127
Family Group Relevant NIST Document
Location of Information System
Components
PE-18
Information Leakage PE-19
Planning PL
Security Planning Policy and Procedures PL-1 NIST SP 800-65, Integrating Security into the Capital
Planning and Investment Control Process
System Security Plan PL-2 NIST SP 800-18, Guide for Developing Security Plans
for Federal Information Systems
System Security Plan Update PL-3 NIST SP 800-18, Guide for Developing Security Plans
for Federal Information Systems
Rules of Behavior PL-4
Privacy Impact Assessment PL-5
Security-Related Activity Planning PL-6
Personnel Security PS
Personnel Security Policy and Procedures PS-1 NIST SP 800-100, Information Security SOP: A Guide
for Managers
Position Categorization PS-2
Personnel Screening PS-3
Personnel Termination PS-4 NIST SP 800-14, Generally Accepted Principles and
Practices for Securing Information Technology
Systems
Personnel Transfer PS-5
Access Agreements PS-6
Third-Party Personnel Security PS-7
Personnel Sanctions PS-8
Risk Assessment RA
Risk Assessment Policy and Procedures RA-1 NIST SP 800-30, Risk Management Guide for
Information Technology Systems
Security Categorization RA-2 FIPS 199, Standards for Security Categorization of
Federal Information and Information Systems
NIST SP 800-60, Guide for Mapping Types of
Information and Information Systems to Security
Categories
Risk Assessment RA-3 NIST SP 800-30, Risk Management Guide for
Information Technology Systems
Vulnerability Scanning RA-5 NIST SP 800-40, Creating a Patch and Vulnerability
Management Program
System and Services Acquisition SA
System and Services Acquisition Policy
and Procedures
SA-1 NIST SP 800-65, Integrating Security into the Capital
Planning and Investment Control Process
Allocation of Resources SA-2 NIST SP 800-64, Security Considerations in the
Information System Development Life Cycle
Life Cycle Support SA-3 NIST SP 800-64, Security Considerations in the
Information System Development Life Cycle
Acquisitions SA-4 NIST SP 800-23, Guideline to Federal Organizations
on Security Assurance and Acquisition/Use of
Tested/Evaluated Products
Information System Documentation SA-5
SOP 90 47 3
Effective Date: August 28, 2012 128
Family Group Relevant NIST Document
Software Usage Restrictions SA-6
User Installed Software SA-7 NIST SP 800-83, Guide to Malware Incident
Prevention and Handling
Security Engineering Principles SA-8 NIST SP 800-27, Engineering Principles for
Information Technology Security (A Baseline for
Achieving Security)
External Information System Services SA-9
Developer Configuration Management SA-10
Developer Security Testing SA-11
System and Communications
Protection
SC
System and Communications Protection
Policy and Procedures
SC-1 NIST SP 800-100, Information Security SOP: A Guide
for Managers
Application Partitioning SC-2
Security Function Isolation SC-3
Information Remnants SC-4
Denial of Service Protection SC-5 NIST SP 800-95, Guide to Secure Web Services
Resource Priority SC-6
Boundary Protection SC-7 NIST SP 800-41, Guidelines on Firewalls and Firewall
Policy
Transmission Integrity SC-8 NIST SP 800-54, Border Gateway Protocol Security
Transmission Confidentiality SC-9 NIST SP 800-45, Guidelines on Electronic Mail
Security
Network Disconnect SC-10 NIST SP 800-46, Security for Telecommuting and
Broadband Communications
Trusted Path SC-11
Cryptographic Key Establishment and
Management
SC-12 NIST SP 800-57, Recommendation on Key
Management
Use of Cryptography SC-13 NIST SP 800-21-1, Second Edition, Guideline for
Implementing Cryptography in the Federal
Government
Public Access Protections SC-14
Collaborative Computing SC-15
Transmission of Security Parameters SC-16
Public Key Infrastructure Certificates SC-17 NIST SP 800-25, Federal Agency Use of Public Key
Technology for Digital Signatures and Authentication
Mobile Code SC-18 NIST SP 800-28, Guidelines on Active Content and
Mobile Code
Voice Over Internet Protocol SC-19 NIST SP 800-58, Security Considerations for Voice
Over IP Systems
Secure Name /Address Resolution
Service (Authoritative Source)
SC-20 NIST SP 800-81, Secure Domain Name System (DNS)
Deployment Guide
Secure Name /Address Resolution
Service (Recursive or Caching Resolver)
SC-21 NIST SP 800-81, Secure Domain Name System (DNS)
Deployment Guide
Architecture and Provisioning for
Name/Address Resolution Service
SC-22 NIST SP 800-81, Secure Domain Name System (DNS)
Deployment Guide
Session Authenticity SC-23 NIST SP 800-95, Guide to Secure Web Services
SOP 90 47 3
Effective Date: August 28, 2012 129
Family Group Relevant NIST Document
System and Information Integrity SI
System and Information Integrity Policy
and Procedures
SI-1 FIPS 200, Minimum Security Requirements for Federal
Information and Information Systems
Flaw Remediation SI-2 NIST SP 800-83, Guide to Malware Incident
Prevention and Handling
Malicious Code Protection SI-3 NIST SP 800-94, Guide to Intrusion Detection and
Prevention (IDP) Systems
Information System Monitoring Tools
and Techniques
SI-4 NIST SP 800-40, Creating a Patch and Vulnerability
Management Program
Security Alerts and Advisories SI-5 NIST SP 800-61, Computer Security Incident Handling
Guide
Security Functionality Verification SI-6 NIST SP 800-85A, PIV Card Application and
Middleware Interface Test Guidelines
Software and Information Integrity SI-7 NIST SP 800-94, Guide to Intrusion Detection and
Prevention (IDP) Systems
Spam Protection SI-8 NIST SP 800-45, Guidelines on Electronic Mail
Security
Information Input Restrictions SI-9
Information Accuracy, Completeness,
Validity, and Authenticity
SI-10 NIST SP 800-44, Guidelines on Securing Public Web
Servers
Error Handling SI-11
Information Output Handling and
Retention
SI-12
SOP 90 47 3
Effective Date: August 28, 2012 130
Appendix E – Glossary of Acronyms
3DES Triple Data Encryption Standard
AC Access Control
ACF2 Access Control Facility
ACIO SBA CIO
ACL Access Control List
AES Advanced Encryption Standard
AH Authentication Header
AO Authorizing Official
SBA Small Business Administration
ARP Address Resolution Protocol
AT Awareness Training
ATAC SBA Technical Assistance Center
AU Audit and Accountability
BIA Business Impact Analysis
BIOS Basic Input/Output System
BRP Business Recovery Plan
C&A Assessment and authorization
CA Certification Agent
CA Certification, Accreditation, and Security Assessments
CAP Corrective Action Plan
CCB Configuration Control Board
CCTV Closed Circuit Television
CFO Chief Financial Officer
CISO Chief Information Security Officer
CM Configuration Management
CNSSP-
15
National Policy on the Use of the Advanced Encryption Standard (AES) to Protect
National Security Systems and National Security Information - June 2003
COOP Contingency of Operations Plan
COR Contracting Officer’s Representative
COTS Commercial-Off-The-Shelf
CP Contingency Planning
CPIC Capital Planning and Investment Control
CRC Cyclic Redundancy Code
CS Cyber Security
DAA Designated Approving Authority
DBMS Database Management System
DES Data Encryption Standard
DHS Department of Homeland Security
DMZ Demilitarized Zone (PCs directly connected online)
DNS Domain Name Service
SOP 90 47 3
Effective Date: August 28, 2012 131
DNSSEC Domain Name System Security Extension
DOS Denial of Service
DRP Disaster Recovery Plan
DS Delegation Signer
EAP Extensible Authentication Protocol
EDBC EDBC: Mainframe Data Integration
ESD Employee Services Division
ESP Encapsulating Security Payload
EVM Earned Value Management
FIPS Federal Information Processing Standards
FISMA Federal Information Security Management Act of 2002
FOIA Freedom of Information Act
FOUO For Official Use Only
FTP File Transfer Protocol
GAO Government Accountability Office
GSS General Support System
HIPAA Health Insurance Portability and Accountability Act
HSPD-12 Homeland Security Presidential Directive-12
HSPD-7 Homeland Security Presidential Directive-7
HTTP Hypertext Transfer Protocol (world wide web protocol)
HTTPS Hypertext Transfer Protocol Secure
HVAC Heating, Ventilation, & Air Conditioning
I&A Identification and Authentication
IA Identification and Authentication
ICMP Internet Control Message Protocol
ID Identification
IDP Intrusion Detection and Prevention
IDPS Intrusion Detection and Prevention Systems
IDS Intrusion Detection System
IETF Internet Engineering Task Force
IMAPS Internet Message Access Protocol Secure
IP Internet Protocol
IPSec Internet Protocol Security
IR Incident Response
IRM Incident Response Manager
IRPM Incident Handling Program Manager
IRT Incident Response Team
ISA Interconnection Security Agreement
ISS Internet Security Systems
ISSO Information System Security Officer
ISSP Information System Security Program
ISSPM Information System Security Program Manager
SOP 90 47 3
Effective Date: August 28, 2012 132
IT Information Technology
ITL Information Technology Laboratory
IV Initialization Vector
LAN Local Area Network
LOUO Limited Official Use Only
MA Maintenance
MAC Media Access Control
MD5 Message Digest 5
MOA Memorandum Of Agreement
MOU Memorandum Of Understanding
MP Media Protection
MRPBS Marketing and Regulatory Programs Business Services
NA Network Administrator
NCSD National Cyber Security Division
NIC Network Interface Card
NIST National Institute of Technology and Standards
NISTIR National Institute of Standards and Technology Interagency Report
NS Name Server
NSA National Security Agency
NTP Network Topology Processor
NVD National Vulnerability Database
OCIO Office of the Chief Information Officer
OEP Occupant Emergency Plan
OIG Office of the Inspector General
OMB Office of Management and Budget
OS Operating System
P2P Peer to Peer
PBX Private Branch Exchange
PDF Portable Document Format
PE Physical and Environmental Protection
PIA Privacy Impact Assessment
PIA Privacy Impact Assessment
PII Personally Identifiable Information
PKI Public Key Infrastructure
PL Planning
POA&M Plan of Actions and Milestones
POC Point of Contact
POP3S Post Office Protocol Secure
PS Personnel Security
PVG Patch and Vulnerability Group
RA Risk Assessment
RACF Resource Access Control Facility
SOP 90 47 3
Effective Date: August 28, 2012 133
RC4 RSA Variable-Key-Size Encryption Algorithm by Ron Rivest
ROB Rules of Behavior
RR Resource Record
SA System and Services Acquisition
SA System Administrator
SAR Security Assessment Report
SBU Sensitive But Unclassified
SC System and Communications Protection
SCA Security Controls Assessor
SCIF Sensitive Compartmented Information Facility
SDLC System Development Life Cycle
SFTP Secured File Transfer Protocol
SHA1 Secure Hash Algorithm 1
SI System and Information Integrity
SIP Session Initiation Protocol
SMTP Simple Mail Transfer Protocol (internet email)
SNMP Simple Network Management Protocol
SOA Start of Authority
SOP Standard Operating Procedure
SORN Statement of Record Notice
SOW Statement Of Work
SP Special Publication
SSH Secure Shell
SSID Service Set Identifier (802.11b)
SSL Secure Sockets Layer
SSN Social Security Number
SSP System Security Plan
ST&E Security Test and Evaluation
TACACS+ Terminal Access Controller Access Control System Plus
TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol/Internet Protocol
TFTP Trivial File Transfer Protocol
TIN Tax Identification Number
TLS Transport Layer Security
TSO Telecommunications Service Organization
TSP Telecommunications Service Priority
UAT User Acceptance Testing
USB Universal Serial Bus
US-CERT United States Computer Emergency Response Team
SBA United States Small Business Administration
VLAN Virtual LAN
VOIP Voice over Internet Protocol
SOP 90 47 3
Effective Date: August 28, 2012 134
VPN Virtual Private Network
VTY Virtual TeleType
WAN Wide Area Network
WEP Wired Equivalent Privacy (802.11 encryption protocol)
WLAN Wireless Local Area Network
SOP 90 47 3
Effective Date: August 28, 2012 135
Appendix F – Password Management Guidance
The following instructions are provided to clarify password compliance requirements so that your
access rights are not interrupted. These password management standards are mandatory and apply
to all individuals, organizations, and entities that process, store, or transmit any SBA information.
a. Password management standards apply to all users of SBA’s NETWORK, laptop,
desktop personal computers, and stand-alone workstations (i.e., those SBA systems that
are not connected to SBA’s Network).
b. All user passwords must be complex and in compliance with SBA’s password policy. A
complex password must be a minimum of 8 characters long and contain at least three of
the following four properties:
(1) Upper Case Letters: A, B, C, … Z
(2) Lower Case Letters: a, b, c, ... z
(3) Numerals: 0, 1, 2, … 9
(4) Special Characters: { } [ ] < >;: ' " ? / | \ ` ~ ! @ # $ % ^ & * [ ] _ - + =.
c. One possible method of creating a good password is to create a passphrase that is made
up of parts of multiple words that one can easily remember but would be hard for
someone else to guess. (For example, the phrase “four score and seven years” could be
transformed into the password “4s&7ye@rs”-- a password that would be acceptable in
our current network environment.)
d. The security software has a lockout feature that SBA has set to 3 unsuccessful attempts
for online and for standalone systems. An authorized administrator must remove the
lockout condition from the person’s account and provide the user a new unique password.
e. Local system administrators/security administrators that have direct contact with system
users. Must create and distribute initial passwords.
f. SBA Network users who have reason to believe that their password has been
compromised must immediately contact SBA’s Help Desk and the Agency Computer
Security Program Manager.
g. System Administrators must avoid using easy-to-guess sequential patterns of characters
when more than one system is involved. (For example, administrators must never use
such predictable passwords as ORACLE1, ORACLE2, ORACLE3, etc. for different
servers.)
h. Passwords for networks, systems, or application accounts must be set to expire in 90
days.
i. Users must not share their passwords with anyone and must beware of illicit methods to
obtain password information. For example, social engineering is a common means of
illicitly obtaining a password via the manipulation of people. In the most common form
of social engineering attack, the attacker telephones a help desk, pretends to be an
authorized system user, and requests a new password.
j. Passwords must not be written down or left adjacent to the computer and on computer
printout.
k. Password life must never exceed ninety (90) days, and must be far less for administrator
accounts.
SOP 90 47 3
Effective Date: August 28, 2012 136
Appendix G – Security Measures for SBA’s Open Storage Area and
Homeland Secure Data Network (HSDN)
1. Purpose
This document establishes procedures to ensure the security of SBA’s open storage area which is
sponsored by the Department of Homeland Security. Under National Communications System
Directive 310 (NCS-310), SBA implemented the open storage area to house the Agency’s
Homeland Secure Data Network (HSDN) at SBA Headquarters located at 409 3rd
Street, SW,
Washington, DC 20416, within Suite 4000. This Appendix establishes guidelines for the Office
of the Chief Information Officer (OCIO) to process, safeguard, store, and dispose of classified
national security information/material that is electronically accessed or transmitted. The Office
of the Inspector General (OIG) has overall responsibility for accessing, processing, transmitting,
storing, safeguarding and disposing of all other formats of Agency classified information,
including cryptographic. (Reference SOP 90 22 5b, Chapter 8 “Classified Information and
OSO”)
2. Applicability
This modification applies to all authorized cleared SBA employees and contractors and persons
who are (1) permanently or temporarily assigned, attached or detailed to OCIO who have been
assigned access to the designated open storage area and (2) SBA personnel and DHS visitors
with “a need to know.”
3. Authority
Our Nation's progress depends on the free flow of information. However, throughout our history,
the national interest has required that certain information be maintained in confidence in order to
protect our citizens, our democratic institutions, and our participation within the community of
nations. Protecting information critical to our Nation's security remains a priority and is
paramount.
a. Executive Order (E.O.) 13526, (Classified National Security Information), as amended –
prescribes a uniform system for classifying, safeguarding, and declassifying national
security information
b. Executive Order (E.O.) 13526, (Classified National Security Information), as amended –
prescribes a uniform system for classifying, safeguarding, and declassifying national
security information.
c. Executive Order (EO) 12958 (Classified National Security Information), EO 12968
(Access to Classified Information), and National Security Decision Directive 84
(Safeguarding National Security Information).
d. 32 CFR Parts 2001 and reserved, Classified National Security Information, is the
implementing directive for E.O. 13526.DHS Management Directive (MD) 11046, Open
Storage Area Standards for Collateral Classification Information – provides the “open
storage” policy and the requirements for constructing and operating open storage areas
within DHS.
4. Definitions
a. Access – The ability and opportunity to obtain knowledge of classified information
SOP 90 47 3
Effective Date: August 28, 2012 137
b. Authorized Person – A person who has a favorable determination of eligibility for access
to classified information, has signed an approved nondisclosure agreement and has a
need-to-know.
c. Information System – An assembly of computer hardware, software, or firmware
configured to collect, create, communicate, compute, disseminate, process, store, or
control data or information.
d. Classified National Security Information (or “Classified Information”) - Classified
information is information or material that is owned by, produced for and by, or under the
control of the United States Government and designated as top secret, secret, or
confidential pursuant to EO 12958.
e. Compromise – An unauthorized disclosure of classified information.
f. Communications Security (COMSEC) – The protection resulting from all measures
designed to deny unauthorized persons information of value that might be derived from
the possession and study of telecommunications and to ensure the authenticity of such
communications. COMSEC includes crypto security, emission security, transmission
security, and physical security of COMSEC material and information.
g. Confidential – Level of classification applied to information, the unauthorized disclosure
of which reasonably could be expected to cause damage to the national security that the
original classification authority is able to identify or describe.
h. Document – Any recorded information, regardless of the nature of the medium or the
method or circumstances of recording.
i. Information – Any knowledge that can be communicated or Documentary material,
regardless of its physical form or characteristics, that is owned by, produced by or for, or
is under the control of the United States Government.
j. Information Security – The system of policies, procedures, and requirements established
under the authority of E.O. 13526 to protect information that, if subjected to unauthorized
disclosure, could reasonably be expected to cause damage to the national security
k. Need-to-Know – A determination within the executive branch in accordance with
directives issued pursuant to E.O. 13526 that a prospective recipient requires access to
specific classified information in order to perform or assist in a lawful and authorized
governmental function.
l. Portable Electronic Device (PED) - Any non-stationary electronic apparatus with singular
or multiple capabilities of recording, storing, processing, and/or transmitting data,
video/photo images, and/or voice emanations. This definition generally includes, but is
not limited to, laptops, PDAs, pocket PCs, palmtops, Media Players (MP3s), memory
sticks (thumb drives), cellular telephones, PEDs with cellular phone capability, and
pagers.
m. Safeguarding – Measures and controls that are prescribed to protect classified
information.
n. Secret – Level of classification applied to information, the unauthorized disclosure of
which reasonably could be expected to cause serious damage to national security.
SOP 90 47 3
Effective Date: August 28, 2012 138
o. Security Officer – Authorized position within an organizational element whose primary
duties are to serve as the lead official for developing, implementing, and managing
security programs within the organizational element.
p. Telecommunications – Operating, maintaining, and/or providing access to facilities for
the transmission of voice, data, text, sound, and video based on a single technology or a
combination of technologies.
q. Unauthorized Disclosure – A communication or physical transfer of classified
information to an unauthorized recipient.
5. General
a. All persons authorized unescorted or escorted access to the HSDN open storage will read
and be familiar with the requirements of the Appendix.
b. An open storage area is established when the volume or bulk of classified materials or the
functions (information technology systems connectivity) to be performed in the room
makes the use of security containers impractical. The area designated for open storage
serves as the container for the storage of classified materials and security measures must
be in place and maintained in order to ensure the integrity of the materials stored therein.
Unless otherwise designated, open storage approval is limited to information technology
systems connectivity only. All media, i.e., discs, Documents, etc., that contain classified
information will be secured in an appropriate GSA approved security container whenever
the room is unattended and at the end of each work day. (Reference SOP 90 22 5b)
c. The area designated in paragraph 6 below is granted approval by DHS for open storage to
facilitate connectivity to an accredited classified system such as the HSDN to include
such equipment as computer systems that have been certified and accredited for classified
processing by a Federal Agency. All equipment such as laptops, diskettes, CDs, DVDs,
printers, and other media used for processing classified information will be properly
marked with the highest classification level of media that it has come into contact or
processed on a classified system. This area is also approved for storing classified
information and several of the Agency’s Secure Telephone Equipment (STE) and Iridium
Satellite telephones.
d. The CIO and CISO (see paragraph 9) will be contacted prior to and modifications made to
the structure or security devices that were in place at the time open storage was
approved.
e. Under no circumstances will the level of classified materials stored, discussed,
transmitted or received exceed the level of open storage authorized per paragraph 6
below.
6. Identifying Data
Program area/Activity Responsible for
Area
Office of the Chief Information Officer, Office of
Information Security
Name, Position/Title, Phone Number of
Responsible Officials
Eric K. Won
Chief Information Officer
(202) 205-6708
Ja’Nelle DeVore
Chief Information Security Officer
SOP 90 47 3
Effective Date: August 28, 2012 139
(202) 205-7103
Room Number(s) of Designated Area Suite 4000
Address/Location 409 3rd
Street, SW, Washington, DC 20416
Highest Level of OPEN Storage/Secure
Video Teleconference Center (SVTC)
Operations Authorized
SECRET
7. Responsibilities
The CIO and CISO are the designated responsible officials for SBA’s open storage area. They
will maintain and administer SBA’s HSDN program and all other secure operations within the
open storage area and will serve as the points of contact in matters involving classified
information that is electronically accessed, processed, stored or transmitted. To ensure this kind
of information is properly safeguarded, the CIO and CISO will:
a. Limit access to the “open storage” area housing the HSDN system and other classified
equipment and to “cleared” personnel only.
b. Establish and implement controls for deterring, detecting, restricting, and regulating
access to the “open storage” area to ensure the safeguarding and protection of classified
information and equipment.
c. Require authorized visitors to sign-in upon entering the “open storage” area, be escorted
at all times during their stay, and sign-out upon departing the area. Visitor logs shall be
maintained and available for review for one year.
d. Conduct periodic inspections of the “open storage” area during and after working hours
to ensure classified and other sensitive materials are being adequately safeguarded.
e. Publish internal policies and procedures as necessary to prevent unauthorized access.
f. Establish and maintain relevant security education and training; Training on the security
of the open storage area will be addressed by the new Information Technology Security
Coordinating Committee (ITSCC).
g. Report security infractions and suspected violations to the Agency of Homeland Security
(DHS), Office of Security (OS), Administrative Security Division (ASD), as required by
DHS Management Directive 11046.
h. Report any unauthorized disclosure to the Director, Office of Security (OSO), as soon as
possible. The initial report may be by telephone and must be confirmed by
memorandum. State what information was disclosed, to whom, by whom, when, how,
and any other pertinent information.
8. Procedures
a. Open Storage Security Controls
(1) Key locks, cipher locks and card readers are supplemental access control devices
only and do not provide sufficient security for an unattended open storage area.
The open storage area is considered unattended when it is not occupied or under
direct visual observation by an appropriately cleared person. Therefore, whenever
the designated area is unattended all locking devices (built-in dial type
combination lock and key/cipher lock, electric strike, electric knob, magnetic
SOP 90 47 3
Effective Date: August 28, 2012 140
lock) will be in the locked position. The dial on the combination lock will be
spun at least four times to ensure the combination is cleared. The area will never
be left open or unlocked when unattended.
(2) The combination of the built-in dial type combination lock is classified at the
same level as the highest classification of materials stored therein. It will not be
provided to any person that does not have the appropriate security clearance and
need-to-know. The combination will then be recorded on a Standard Form 700,
Security Container Information, and appropriately stored by the responsible
official listed in paragraph 6.
(3) At a minimum, the combination to the built-in dial type combination lock will be
changed immediately when the lock is first placed in service, when someone
having knowledge of the combination terminates employment or is reassigned to
another SBA program area or no longer requires access, if it is suspected that the
combination was compromised, or if the area is found unattended and unlocked.
Contact the responsible official in paragraph 6 for information on combination
changing.
(4) The supplemental access control device (cipher lock, uncial lock and/or keys)
combination/lock to the open storage area entrance door is classified at the same
level as the open storage area “open storage” certification. The
combination/key(s) will not be provided to anyone who does not have the
appropriate security clearance and need-to-know.
(5) The combination to a cipher lock or the key lock will be changed/rekeyed when
the lock is first placed in service, when someone having knowledge of the
combination terminates employment or is reassigned to another SBA program
area or no longer requires access, if it is suspected that the combination was
compromised, or if the area is found unattended and unlocked.
(6) Where a card reader is used for supplemental access control, the reader will be
programmed with its own distinct access level. Only persons with the appropriate
security clearance and are authorized access to the area, will have their key cards
programmed to access the area.
(7) Only persons who have been granted a security clearance equal to or higher than
the level of classified stored and who have a need-to-know, will be authorized
escorted access to the area. OCIO will provide a list of all SBA staff, which may
have a need to access the open storage area, to OIG, OSO, to verify the required
clearance. OIG/OSO will inform the CIO of any changes in status of anyone on
the list. Replacements designated by OCIO, must also be verified by OIG/OSO.
(8) Persons who do not have a security clearance equal to or higher than the level of
classified stored information and/or do not have a need-to-know will not be
allowed unescorted access to the area. Should the need arise to allow such
visitors access to the area, the area will first be sanitized by a cleared person to
ensure that no classified information is exposed or could otherwise be subjected to
compromise. The visitor will be signed in on the visitor log, and then be escorted
by a cleared person, and remain under visual escort, for the duration of the visit.
SOP 90 47 3
Effective Date: August 28, 2012 141
(9) When un-cleared visitors are escorted into the area, the escort will announce to
any persons working in the area that a visitor is present. In larger areas, if a
strobe light is installed as a means for announcing visitors, it will be activated.
(10) Portable Electronic Devices (PEDs) shall not be introduced into an open storage
without written approval from the designated responsible officials.
(11) Approvals will be considered only when the risks associated with the use of such
equipment are clearly identified and sufficiently mitigated. Restrictions on the
introduction of PEDs into open storage areas shall be prominently posted at the
entrance of the area.
(12) All classified material will be destroyed when no longer required as determined
by the CIO. National Security Agency approved shredders will be used for the
destruction of classified material. Classified material awaiting destruction must be
protected to the level of the material to be destroyed. All classified material must
be destroyed by authorized cleared personnel and recorded in the appropriate log.
The disposition schedule for classified material is as follows:
Security Container Information (Form 700) – destroy when superseded
Activity Security Checklist (Form 701) – destroy every 3 months.
Security Container Check Sheet (Form 702) – destroy every 3 months.
IDS/Alarm Documented Test – destroy after next test is completed.
Standard Operating Procedure for Open Storage Area and HSDN –
destroy when superseded by a new one.
(13) All electronic classified information printed will be secured and safeguarded in
accordance with the following guidelines contained in SOP 90 22 5b:
Store classified material in a container approved in writing by the
Director, OSO.
For top secret material, the container must be a GSA-approved safe or
safe-type file having a three position, dial-type combination lock. Secret
or confidential material may be stored in a container approved for top
secret storage and may also be kept in a steel file cabinet with a steel lock
bar secured by a GSA-approved padlock with a three position, dial-type
combination lock.
Avoid routine reproduction of classified material. For material designated
top secret or secret, employees must check with the Director, OSO, prior
to making any copies.
Keep classified material segregated from non-classified material and do
not summarize classified information in other Documents.
Only disclose classified information to individuals who have the required
security clearance and "need to know" the information.
Do not discuss classified information over the telephone or in a public
place.
Note: All forms involved in an investigation must be retained until completion
of the investigation.
b. End-of-Day Security Checks.
SOP 90 47 3
Effective Date: August 28, 2012 142
(1) At the end of each work day the open storage area will be checked to ensure it is
secure. The Standard Form 701, Activity Security Checklist, will be used to
record the end-of-day check.
(2) The end-of-day check will be conducted by a cleared person designated by the
CIO. The end-of-day check will include (but will not be limited to):
Ensuring that all information system equipment authorized for the
processing of classified information is logged off and the terminal locked.
Ensuring that all Keying Devices are removed from any STEs.
Physically spinning the dial of the built-in combination lock at least four
times. The supplemental access control device, i.e., key lock, cipher lock,
card reader, will then be unlocked and the checker will physically tug on
the door to make sure the dial type combination lock is locked. The
checker will also ensure that the Intrusion Detection System (IDS), if
applicable, is armed. Any discrepancies noted in the end-of-day check will
be reported to the responsible official.
c. Intrusion Detection Systems (IDS).
(1) Upon activation of the IDS, SBA’s building security personnel will respond
within 30 minutes and inspect the exterior of the room for a security breach.
(2) If a breach is apparent and an infiltrator(s) is/are within the area, immediate
summary police action (arrest/detention) will be affected. The room will be
secured, and cleared personnel will be notified to respond and inspect/secure
integrity of materials/systems within. Notification of the intrusion will be reported
to the CIO and CISO.
(3) If a breach is NOT apparent and the area alarm resets, cleared personnel will be
notified to determine additional actions, as necessary. Notification of the IDS
activation will be reported to the DHS OS/ASD representative listed in paragraph
9, below, no later than the next business day.
(4) IDS system will be activated whenever cleared personnel are NOT present in the
facility.
(5) The IDS will be tested monthly and documented.
(6) The IDS will be on supplemental building backup power and not vulnerable to
power outages.
d. Emergency Procedures.
(1) In the event an emergency arises that causes the immediate evacuation of the
area, every reasonable effort will be made to properly secure the area prior to
departure. However, life safety will not be jeopardized in order to secure the area.
(2) Should immediate evacuation prohibit the area from being properly secured, upon
termination of the emergency, a reasonable effort will be made to verify that the
integrity of the materials stored therein has not been compromised. This will
include a visual inspection of the stored materials to determine if any items may
be missing or tampered with. In addition, the combination to the “built-in dial”
type combination lock will be changed.
e. System Security Procedures.
(1) Classified information will only be processed on computer systems that have been
certified and accredited for classified processing by a Federal agency. All
SOP 90 47 3
Effective Date: August 28, 2012 143
equipment, such as laptops, diskettes, CDs, DVDs, printers, and other media used
for processing classified information will be properly marked with the highest
classification of information stored or the highest classification level of media that
it has come into contact with or processed on a classified system. Standard Form
(SF) 700 series labels will be used for this purpose. Desktops and Laptops will be
marked on the exterior of the devices, as well as the interior with the cover open.
f. Classified Information System Processing Policies.
(1) HSDN is designed as a standalone classified network, capable of rapidly
exchanging data that is classified up to the Secret level. The network provides
secure, real-time connectivity in a collaborative environment to collect and
disseminate classified information between appropriately cleared Federal, State,
and local personnel. In a closed storage environment all required system
components that are designated to be locked up must be placed in an approved
security container when not under the direct control of an authorized person.
(2) Because of the sensitive nature of certain types of information, it is essential that
access and dissemination be controlled and restricted in order to prevent
compromise. The unauthorized release or inadvertent disclosure of such
information could adversely affect the ability to detect an adversary’s intentions,
neutralize offensive capabilities in the pursuit of terrorists, compromise the
identity of a confidential human source or operation, or result in physical harm to
our citizens.
(3) Ensure that all unclassified processing equipment (VTC units, workstations,
printer, networking equipment and hard drives) are at a minimum of 1/2 meter
away from the HSDN classified processing.
g. Reporting Requirements.
(1) Any situation or observation that affects the security integrity of the designated
area, security vulnerabilities, or any potential or known compromises of classified
information or materials stored therein, must be reported immediately to the
following personnel:
Chief Information Officer, OCIO (202) 205-6708
Chief Information Security Officer, OCIO (202) 205-7103
(2) If classified meetings/conferences are held in the open storage area or there is a
need in the future to retrofit that area to add acoustics associated with secure
video teleconferencing, the following Documents pertaining to the security
requirements for those options will be on file in that area:
Security Procedures for Classified Meetings and Conferences
Acoustical Security Requirements for Open Storage Areas
SOP 90 47 3
Effective Date: August 28, 2012 144
Appendix H – Contract Security Requirements
Purpose
The purpose of this document is to establish the security requirements, procedures,
responsibilities, and the U.S. Small Business Administration’s framework for ensuring that
security is included in appropriate Agency IT contracts and acquisitions. Each potential
contractor must describe in Section L of the Request for Proposal (RFP) the specific measures
that will be taken to meet the security requirements described herein.
This document applies to all Agency contracts in which SBA sensitive information is stored,
generated, transmitted or exchanged by an SBA contractor, subcontractor or third-party, or on
behalf of any of these entities regardless of format. The regulations in this document also pertain
to information residing on an SBA or a non-SBA system in order for the contractor,
subcontractor or third party to perform their contractual obligations to SBA, standing in lieu of
SBA or acting on SBA’s behalf.
When relying on contractors, subcontractors, or third party service providers or associates, SBA
transfers operational responsibilities for performing one or more business functions (e.g.,
Information Technology (IT) services) to these partners. However, it still remains SBA’s
responsibility to ensure the protection of these assets is addressed via compliance with applicable
security regulations and policy on the part of these partners and contractors. Failure to
adequately address security in appropriate SBA agreements or solicitations can jeopardize
mission success and undermine public confidence.
Background
The Federal Information Security Management Act (FISMA) (116 Stat. 2946, 2950) states that
“each agency shall…provide information security for the information and information systems
that support the operations and assets of the agency, including those provided or managed by
another agency, contractor, or other source.” Information security is an important business
process and must be considered in all phases of an acquisition and contract life cycle to ensure
that SBA’s sensitive information and IT assets are adequately protected.
Data contained within all SBA computer systems are governed by Agency record disclosure and
privacy regulations (13 C.F.R. part 102), IT Security regulations as well as other regulations,
statutes and guidance, including the Privacy Act of 1974, as amended (5 U.S.C. § 552a).
The contractor and its subcontractors will be held accountable for adherence to these statutes,
regulations and guidance, as well as following SBA requirements described in this clause.
Therefore, any time the term contractor is used, it shall be meant to include the contractor and
all of its subcontractors working on this contract that have access to a federally controlled facility
and/or routine access to a federally controlled information system (including, but not limited to,
computer systems, networks, or IT infrastructure).
In addition, various Federal requirements obligate SBA to establish controls to limit access to
Personally Identifiable Information (PII) and sensitive data, as defined below, to authorized
personnel. These include OMB Circular A-130, Appendix III, and OMB Memoranda M-10-15,
M-09-29, M-08-21, M-07-19, M-07-16, M-06-16, and M-06-15.
SOP 90 47 3
Effective Date: August 28, 2012 145
Requirements
a. Personal Identity Verification (PIV)
(1) Pursuant to Federal Acquisition Regulation (FAR) clause 52.204-9, incorporated
into this solicitation and the resulting contract, each contractor and subcontractor
must comply with Agency Personal Identity Verification (PIV) procedures. These
procedures must be followed when the contractor and or subcontractor will have.
Unescorted physical access to a federally-controlled facility; and/or
Access to a federally controlled information system (including, but not
limited to, computer systems, networks, or information technology
infrastructure).
The Contracting Officer’s Representative (COR) will provide guidance on
Agency PIV card procedures.
b. System Security Plan (SSP).
(1) The contractor must develop a final Systems Security Plan (SSP) within 90
business days from the date the system/application is placed in production. The
SSP must be updated at least annually. The SSP will be reviewed by the
Contracting Officer’s Technical Representative (COR) or designated technical
point of contact.
(2) The SSP must document administrative, technical, and physical security measures
at the contractor’s computer facility to protect PII and sensitive data from
unauthorized disclosure, alteration, or misuse; prevent unauthorized access to the
contractor’s computer system; and protect the availability of data and services to
SBA.
(3) Sensitive information includes: Sensitive but Unclassified (SBU) information;
procurement sensitive information; For Official Use Only (FOUO) information;
information generated by or in the possession of SBA that is commercially
valuable, trade secret, market sensitive, proprietary, related to an SBA
enforcement or examination matter, subject to privilege, protected by the Privacy
Act (5 U.S.C. § 552a), or otherwise deemed sensitive, confidential or non-public
by an SBA office head, and is not otherwise available to the public.
(4) This definition applies to sensitive information in any form, including documents,
electronic mail, computer files, conversations, and audio or video recordings.
Examples of sensitive information include corporate financial data provided to
SBA that has not been made public; SBA planned or contemplated courses of
action regarding SBA examinations, investigations, and enforcement actions; and
SBA personnel information covered by the Privacy Act, 5 U.S.C. § 552a.
c. Protecting Personally Identifiable Information (PII) and Sensitive Data.
(1) Physical access to the contractor’s office areas that contain PII and sensitive data
(including SBA loan and any other data subsequently identified by SBA as
sensitive or PII), must be controlled to prevent unauthorized personnel from
acquiring access to this data. Log-on passwords, identifiers, and access
SOP 90 47 3
Effective Date: August 28, 2012 146
procedures must be safeguarded from unauthorized use and disclosure.
Contractor personnel must comply as follows:
The 1228 “Computer Access/Clearance Form” must be completed and
submitted to the COR to begin the mandatory clearance processed.
Passwords must be changed every 90 days;
The contractor shall notify the COR as soon as it is known that a
contractor will no longer be working on the contract. The contractor’s
project manager must ensure that all personnel leaving this contract return
all issued identification and any government property no later than the last
day of their employment on the contract. Such identification and property
must then be provided to the COR within 24 hours;
The contractor must not release SBA data outside of its facility, either
orally or in written form, without the express written consent of the SBA
COR. The contractor must refer all requests for SBA data to the assigned
SBA COR for action;
SBA reserves the right to inspect the contractor’s security measures, data
handling procedures and other security safeguards to determine the
security posture of the contractor facility. The contractor shall provide
SBA access to the contractor’s and subcontractor’s facilities, installations,
operations, documentation, databases, and personnel used in performance
of this contract, with no additional cost to SBA. Authorized SBA
personnel include the Chief Information Security Officer (CISO), the
Contracting Officer (CO), the COR, the Office of Inspector General (OIG)
and other personnel designated by the Chief Information Officer (CIO);
Weaknesses in physical, personnel, or computer security noted by SBA
during the accreditation process must be corrected as specified by the
CISO. Quarterly updates of the status of the corrective actions must be in
writing and forwarded through the COR to the information system owner;
Contingency plans must be implemented and tested annually, at a
minimum, to avoid loss of SBA data and to minimize, within the
provisions of the contract, the impact of contingencies (environmental
failures, fire, severe weather, natural disasters, etc.) on services provided
to SBA. Contractors must develop and provide plans for responding to
security incidents, as that term is used in OMB Circular A-130, Appendix
III, involving sensitive data and PII, and procedures for making any
changes to the data processing environment. Documentation must be
provided to the COR within 30 days from the date of contract award (See
NIST 800 53, as revised);
d. Information Handling and Disposition
(1) PII and sensitive data when distributed electronically must be protected against
unauthorized disclosure and modification. At a minimum, draft and final
documents must be encrypted.
(2) The CO’s approval is required prior to engaging in any contractual relationship
(e.g., sub-contractor) in support of this contract requiring the disclosure of
sensitive information received under, generated under, or relating to this contract.
SOP 90 47 3
Effective Date: August 28, 2012 147
The contractor support team will be required to abide by government and Agency
guidance for protecting PII and sensitive data. Any such information made
available in any format will be used only for the purpose of carrying out the
provisions of this agreement.
(3) Such information will not be divulged or made known in any manner to anyone
outside the Agency or removed from approved work sites without approval from
the COR or other authorized SBA personnel. The contractor support team will
immediately notify the COR upon discovery of any inadvertent disclosures of
information. The contractor will not disclose sensitive or proprietary information
of, or in the possession of, SBA or any of its operating units, contractors, or
business partners to unauthorized persons. The contractor will be subjected to
any and all penalties imposed by law for unlawful disclosure of SBA information
which may include termination of the contract.
(4) Sensitive data and PII, and/or equipment will only be disclosed to authorized
personnel with “a need-to-know” as described in the contract or order. The
contractor shall ensure that the appropriate personnel, administrative, technical,
and physical safeguards are established prior to storing SBA data to ensure the
security and confidentiality of this information. Data containing PII is prohibited
from being used as test data or stored in a non-production processing environment
for development/testing.
(5) All contracts supporting SBA’s Information Systems shall require Internet
Protocol Version 6 (IPv6) compliant products to be included in all new IT
acquisitions using Internet protocol.
e. Contractor Background Investigations.
(1) Office of Management and Budget (OMB) Circular A-130 requires that as a condition
for access to government information systems (including data), SBA must screen
contractor personnel commensurate with the level of risk presented by their access to
sensitive SBA systems. Not all SBA information systems and data are considered
sensitive.
(2) SBA designates all contractor positions requiring access to information systems and
physical access to a federally-controlled facility as Moderate Risk. Therefore, a
minimum background investigation (MBI) or higher level is required for all such
contractor employees. An adjudicated background investigation is required for all
contractor personnel who cannot show positive results of a recent MBI (one that was
successfully adjudicated within the last five years or the contractor has not had a
break as a contractor from the federal government exceeding two years) or higher
level investigation, such as a Limited Background Investigation or other background
investigation. The COR or designated staff may assign each contract labor category a
higher security sensitivity rating, which will determine the type of background
investigation to be performed for that labor position.
(3) To initiate a background investigation, the contractor will be required to complete the
1228 “Computer Access/Clearance Form” and provide additional PII information.
This information will be submitted to OSO.
(4) OSO will coordinate with the OPM to perform all required investigations. Any
background investigation received by a contractor prior to employment on an SBA
SOP 90 47 3
Effective Date: August 28, 2012 148
contract must have been conducted by OPM or contracting firm approved by Defense
Security Service and/or OPM. In order to be accepted by SBA, a contractor’s
background investigation must be reviewed and approved by OSO to determine if it
meets OPM’s standards. Background investigations must also meet the requirements
applicable to all other SBA contractor personnel. The contractor will reimburse SBA
the total cost for each investigation. The cost is subject to increase annually. SBA’s
Procurement Division will update you with the annual increases and provide you with
reimbursement procedures.
(5) Background investigations are not required if the contractor is not working in an
SBA facility and his primary function does not involve access to an SBA information
system or Agency sensitive data and/or PII.
(6) Investigation results will be reviewed by OSO for adjudication. The COR will be
informed of any issues requiring additional action by the contractor
f. Designation of a System Security Officer (SSO).
(1) The contractor shall designate a management official responsible for fulfilling the
responsibilities of an SSO who is knowledgeable in automated data processing
technology and computer security methodology. The SSO shall:
Ensure that an appropriate level of physical, operational, and technical
security is maintained to protect the computing environment(s) and facility
that process SBA information and the information is processed in
accordance with SBA policy.
Implement controls described in an SBA approved SSP.
Ensure vulnerability scanning is routinely conducted for all devices
supporting Agency operations. Scanning should also be conducted by the
contractor’s external auditors as a part of the scope of the SSAE 16
evaluation.
Assist SBA’s CISO with the investigation of information technology
security breaches that affect processing at the contractor’s facility.
Implement, at the direction of SBA’s CISO, information security policies,
procedures, and standards that affect systems that process SBA
information at the contractor’s facility.
Support SBA’s CISO in maintaining the system security plan and in
conducting periodic information security audits and internal control
reviews. Reviews will be scheduled and conducted at least every three
years, and additionally, as required by changes in the system, data, and
operating environment.
Recommend security enhancements and improvements where appropriate.
Ensure the timely correction or remediation of discrepancies found during
the periodic information security audits and internal control reviews.
Ensure that an accurate inventory list of all networking devices and
licensed software products is maintained.
Ensure that security patches and updates are applied to SBA owned,
contractor operated computing devices in a timely fashion.
SOP 90 47 3
Effective Date: August 28, 2012 149
Notify information system owner of all security incidents immediately
after they are discovered. Detailed follow-up reports must be submitted to
the CISO describing the incidents, successful/unsuccessful network
penetrations, root or user account compromises, denial of service attacks,
website defacing attacks, malicious code, viruses, probes and scans, etc.
Ensure that all contractors with access to SBA’s IT systems and/or PII and
sensitive data, complete the annual Computer Security Awareness
Training (CSAT), PII and role based training, if required. New
contractors must complete the CSAT within 10 days from starting to work
as an SBA contractor.
Provide SBA with a copy of the facility’s SSAE 16 in accordance with
Federal guidelines over hosted applications as outlined in NIST 800-53,
Recommended Security Controls for Federal Information Systems and
Organizations, and provisions of OMB Bulletin 07-04, Audit
Requirements for Federal Financial Statements. The SSAE 16 (Reporting
on Controls at a Service Organization) addresses examination
engagements undertaken by a service auditor to report on controls at
organizations that provide services to user entities when those controls are
likely to be relevant to user entities' internal control over financial
reporting. In this instance, the specific organization would be the
outsourcing facility that hosts and/or processes data belonging to SBA.
SBA will verify that the evaluation includes all applicable security
controls.
SBA system owners will ensure that all contractors that have been granted
access to one or more of SBA’s information systems are provided with a
copy of the system’s “Rules of Behavior” which is a group of standards
detailing permissible actions while using the system
g. Service Level for Reporting, Review and Resolution
(1) SBA system owners and contractors hosting SBA systems off-site must ensure the
system is capable of logging and the logging feature is enabled. Logs should
capture account, name, normal and exceptional activities time, data and source of
occurrence. Logs for privileged accounts (e.g., administrator, auditor, database
administrator) must be set up to capture all activities carried out with these
accounts with controls that cannot be altered by an individual. The contractor
shall include in their proposal an established process and designated resources for
the review and monitoring of such logs, to include the following: Audit logs must be reviewed daily and critical and high alerts must be
addressed within one hour.
Security incidents and violations must be reported to SBA within one
hour.
Logs must be retained at least 90 days before deleting. After 90 days, logs
must be archived offline for at least one year.
Reported security problems must be resolved within three business days of
initial report.
SOP 90 47 3
Effective Date: August 28, 2012 150
Security patches, updates and changes need to be applied within one week
from release date. However, quality assurance testing must be done on all
patches, updates and changes before they are applied.
Periodic reports, audit and system reports must be submitted weekly.
SBA Information Technology Security Program Requirements
The following Federal laws, OMB/NIST/SBA Policies and Guidelines (as revised) are applicable
to operating or hosting all SBA systems. See documents and links below:
SBA’s IT Security Policies
(1) SBA Standard Operating Procedure (SOP) 90 47 3, Information Systems Security
Program
(2) SBA Standard Operating Procedure (SOP) 90 49, Appropriate Use of SBA’s Automated
Information Systems
(3) Standard Operating Procedure (SOP) 90 50, Breach Notification Response Plan
Public Law and Statutes
(1) Privacy Act of 1974 (5 U.S.C. § 552a)
(2) Freedom of Information Act (5 U.S.C. § 522b)
(3) Federal Managers Financial Integrity Act of 1982 (31 U.S.C. § 1352)
(4) Paperwork Reduction Act of 1986 (44 U.S.C. 35)
(5) Electronic Communications Privacy Act of 1986 (P.L. 99-508, as amended;
codified in 18 U.S.C. chapters 119, 121 and 206)
(6) Computer Fraud and Abuse Act of 1986 (P.L. 99-474, as amended; codified at 18
U.S.C. § 1030)
(7) Information Technology Management Reform Act of 1996 (Clinger-Cohen Act)
(Division E of P.L. 104-106, as amended; codified in part in 44 U.S.C. chapters
111, 113, 115 and 117)
(8) Title III of the E-Government Act of 2002 (P.L. 107-347) and Federal
Information Security Management Act of 2002 (FISMA) (P.L. 107-296; codified
in part in 44 U.S.C. chapters 35 and 36)
(9) Computer Security Act of 1987 (P.L. 100-235, as amended)
Office of Management and Budget (OMB) Circulars and Bulletins
(1) Office of Management and Budget (OMB) Circular A-123, Management’s
Responsibility for Internal Control, Dec. 21, 2004, OMB Circular A-127,
Financial Management Systems, revised July 23, 1993;
(2) OMB Circular A-130, Management of Federal Information Resources, Appendix
III, Transmittal #4, Security of Federal Automated Information Resources, Nov.
28, 2000;
(3) Executive Order (EO) 12656, Assignment of Emergency Preparedness
Responsibilities (COOP Plans), Nov. 18, 1988, as amended by EO 13074, Feb. 9,
1998;
SOP 90 47 3
Effective Date: August 28, 2012 151
(4) EO 13011, Federal Information Technology, July 16, 1996;
(5) OMB Circular No. A-130, Appendix III establishes a minimum set of controls to
be included in the Federal automated information security programs and links
agency automated information security programs and agency management control
systems established in accordance with OMB Circular No. A-123; OMB Bulletin
90-08,
(6) Guidance for Preparation and Submission of Security Plans for Federal Computer
Systems that Contain Sensitive Information, July 9, 1990;
(7) Homeland Security Presidential Directive (HSPD-7), Critical Infrastructure
Identification, Prioritization and Protection;
(8) HSPD-12, Policy for a Common Identification Standard for Federal Employees
and Contractors;
(9) Presidential Decision Directive (PDD) 67, Continuity of Government (COG) and
Continuity of Operations (COOP) Plans Practices for Securing Critical
Information and Information Systems and Networks, 1988;
(10) M-03-22 – OMB Guidance for Implementing the Privacy Provisions of the
(11) E-Government Act of 2002;
(12) M-05-16 – Regulation on Maintaining Telecommunication Services During a
Crisis or Emergency in Federally-owned Buildings;
(13) M-06-16 – Protection of Sensitive Agency Information;
(14) M-06-20 – FY 2006 Reporting Instructions for the Federal Information Security
Management Act and Agency Privacy Management;
(15) M-06-15 – Safeguarding Personally Identifiable Information;
(16) M-06-19 – Reporting Incidents Involving Personally Identifiable Information and
Incorporating the Cost for Security in Agency Information Technology
Investments;
(17) M-07-11 – Implementation of commonly Accepted Security Configurations for
Windows Operating Systems, March 22, 2007;
Federal Information Processing Standards Publications (FIPS PUBs)
(1) FIPS-201, Personal Identity Verification (PIV) of Federal Employees and
Contractors;
(2) FIPS PUB 199, Standards for Security Categorization of Federal Information and
Information Systems;
(3) FIPS PUB 200, Minimum Security Requirements for Federal Information
Systems;
(4) National Institute of Standards and Technology (NIST) Special Publication (SP)
800-18, Revision 1, Guide for Developing Security Plans for Federal Information
Systems;
(5) NIST SP 800-37, Guide for the Security Certification and Accreditation of
Federal information Systems;
SOP 90 47 3
Effective Date: August 28, 2012 152
(6) NIST SP 800-53, Recommended Security Controls for Federal Information
Systems, and referenced supplemental guidance documents;
(7) NIST SP 800-60, Guide for Mapping Types of Information and Information
Systems to Security Categories;
(See following link: http://www.nist.gov/index.html)
SOP 90 47 3
Effective Date: August 28, 2012 153
Appendix I – Rules of Behavior
Purpose
These “Rules of Behavior” establish expected and acceptable computing behaviors. SBA is
required by law to ensure that anyone who uses SBA’s IT resources is aware of his or her
responsibilities and complies with these “Rules of Behavior”. Public Law 107-347 dated
December 17, 2002; the E-Government Act of 2002; and Office of Management and Budget
(OMB) Circular A-130, Appendix III require protection of information and information systems
from unauthorized access, use, disclosure, disruption, modification or destruction. Because
written guidance cannot cover every contingency, users are also required to use sound judgment
and the highest ethical standards in their decision making.
General
The following apply to all users:
a. Corrective Actions.
(1) SBA will take corrective action and/or enforce the use of penalties against any
user who violates any SBA or Federal system security policy, using any and/or all
of the following:
Written reprimands;
Temporary suspension from duty;
Reassignment or demotion;
Termination of Federal employment;
Suspension of system privileges; and,
Possible criminal prosecution.
b. Prohibited Activities.
(1) The following non-official activities are prohibited on any government owned or
leased computer:
Gambling;
Intentionally visiting and downloading material from pornographic
websites;
Lobbying Congress or any government agency;
Campaigning – political activity;
Any type of continuous audio or video streaming from commercial,
private, news, or financial organizations, except as expressly authorized by
management;
Activities that are connected with any type of outside employment ; and,
Endorsement of any non-government products, services, or organizations.
c. Email.
(1) The following apply regarding email activity:
Automatic filters are in place to help prevent inappropriate and offensive
messages from passing through SBA email gateways.
SOP 90 47 3
Effective Date: August 28, 2012 154
Any email on a government email system is the property of the
government and may become an official record.
The use of IT resources constitutes consent to possible monitoring and
security testing. User’s consent to monitoring and security testing ensures
proper security procedures and appropriate usage are being observed for
SBA’s IT resources
Official SBA email may not be forwarded to private email addresses for
any purpose.
Monitoring of email and other IT resources by management will be done
only in accordance with established SBA policy and guidelines.
Users are prohibited from using SBA IT resources to send, receive, retain,
or proliferate any messages or material that is fraudulent, inappropriate,
offensive, harassing, or is of a sexual nature.
d. Access.
(1) Users shall access and use only information for which they have official
authorization. Users shall:
Follow established procedures for accessing information, including use of
user identification, user authentication, passwords, and other physical and
logical safeguards.
Follow established channels for requesting and disseminating information.
Access only those files, directories, and applications for which access
authorization by the system administrator has been granted.
Use government equipment only for approved purposes.
(2) In addition, users shall NOT:
Give information to other employees or outside individuals who do not
have access authority.
Store sensitive or confidential information on a system unless access
control safeguards (e.g., passwords, locked rooms, and protected local area
network (LAN) storage areas) are used.
Use their trusted position and access rights to exploit system controls or
access data for any reason other than in the performance of official duties.
Browse files (i.e., what can be accessed).
e. Access.
(1) Users are accountable for actions related to information resources entrusted to
them. Users shall:
Behave in an ethically, technically proficient, informed, and trustworthy
manner when using systems.
Be alert to threats and vulnerabilities such as malicious programs and
viruses.
Participate in IT security training and awareness programs.
Not install or use unauthorized software on SBA equipment.
Comply with all software licensing agreements, and not violate Federal
copyright laws.
SOP 90 47 3
Effective Date: August 28, 2012 155
Know that there may be monitoring and that there is no expectation of
privacy on SBA IT resources.
Prevent others from using their accounts by:
1. Logging out or locking the screen when leaving the vicinity of
their terminals or PCs.
2. Setting a password on automatic screen savers.
3. Helping to remedy security breaches, regardless of who is at fault.
4. Immediately notifying the system administrator whenever there is
a change in role, assignment, or employment status and/or when
access to the system is no longer required.
5. Practice good citizenship when accessing external systems by
complying with the system’s “Rules of Behavior.”
6. Read and understand banner pages and end user licensing
agreements.
f. Confidentiality.
(1) Access to confidential or sensitive information must be restricted to authorized
individuals who need it to perform their jobs. This entails refraining from
intentional disclosure and using measures to guard against accidental disclosure.
Users shall:
Protect confidential or sensitive information by using encryption, and
limiting the collection, disclosure, sharing and use of PII data. Never
access or disclose personal information or other sensitive data unless it is
necessary to perform official duties.
Not send highly sensitive information via email, unless it is encrypted.
Ensure that sensitive information sent to a fax or printer is handled in a
secure manner (e.g., use of a cover sheet that contains a statement that the
faxed information is confidential).
Not store or transmit confidential information on public access systems,
such as email or the Internet.
Lock up media, such as paper copies, tapes, and disks containing
confidentially sensitive data. Dispose of media according to approved
procedures.
Never access someone else's account or files without a supervisor's formal
authorization.
To the extent possible, ensure that computer monitors are located in such a
way as to eliminate viewing by unauthorized persons.
Lock workstations when away from the desk as a preventative measure to
ensure that unauthorized individuals cannot read, copy, alter, or steal
printed or electronic information.
When requesting that another individual receive, pick up or deliver
application systems input and output information and media, ensure that
the individual is authorized.
SOP 90 47 3
Effective Date: August 28, 2012 156
Ensure that confidential or sensitive data are properly erased when
disposing of hardware or media.
g. Integrity.
(1) Users must protect the integrity and quality of information. This includes, but is
not limited to:
Reviewing quality of information as it is collected, generated, and used to
ensure that it is accurate, complete, and up to date.
Taking appropriate training before using a system to learn how to
correctly enter and change data.
Protecting information against viruses and similar malicious code by:
1. Using virus detection and correction software.
2. Avoiding unofficial software, such as shareware and public
domain software.
3. Discontinuing use of a system at the first sign of virus infection.
4. Never knowingly entering unauthorized, inaccurate, or false
information into a system.
h. Availability.
(1) Computer systems and media must be protected from environmental hazards such
as fire, water, heat, and food spills. They must also be protected from theft,
unauthorized alteration, and careless handling. Users shall:
Use physical and logical protective measures, such as the following to
prevent loss of availability of information and systems.
1. Ensure that there are backups of information for which they are
responsible.
2. Protect systems and media where information is stored.
3. Store media in protective jackets.
(1) Keep media away from devices that produce magnetic fields (such as phones,
radios, and magnets).
(2) Follow contingency plans.
i. Passwords and User IDs
(1) Users are responsible and accountable for any actions taken under their user ID.
Users shall:
Protect passwords from access by other individuals.
Never give a password to another person, including a supervisor or a
computer support person.
Not ask anyone for their password.
Construct effective passwords by following SBA password policy for
complex passwords.
j. Hardware
(1) Users must protect computer equipment from damage, abuse, theft, and
unauthorized use. Users shall:
SOP 90 47 3
Effective Date: August 28, 2012 157
Protect computer equipment from hazards such as:
1. Extreme temperatures;
2. Electrical storms
3. Water and fire
4. Static electricity
5. Spills from food and drink
6. Dropped objects
7. Excessive dusty environments; and,
8. Combustible materials.
Keep an inventory of all equipment assigned to them.
Only use equipment for which they have been granted authorization.
Do not leave computer equipment in a parked car or in an unsecured
location where it might be stolen.
Follow established procedures when removing equipment from SBA
premises. (This is usually a property pass.)
Do not install or use unauthorized software or hardware on the network,
including personal laptop computers, pocket computers, or personal digital
assistants and network enabled cellular phones, except as expressly
authorized.
Do not alter the configuration, including installing software or peripherals,
on government equipment unless authorized.
Notify management before relocating computing resources.
Use physical locking devices for laptop computers and special care for
other.
k. Software.
(1) Do not install unauthorized, standard, public domain, or shareware software on
your computer without approval from the appropriate management official.
Computer users must protect SBA owned software and equipment from malicious
software. Users shall NOT:
Use SBA purchased software on personally owned or non-SBA computers
unless authorized.
Alter the configuration, including installing software or peripherals, on
government computer equipment unless authorized.
Comply with all software licensing agreements and Federal copyright
laws.
Not download, install, or run security programs or utilities that might
reveal weaknesses in the security measures or access privileges of any
system unless otherwise expressly authorized.”
l. Awareness.
(1) Annual IT Security Awareness and Privacy Training are mandatory for all SBA
employees and contractors. New employees, contractors, partners, and volunteers
SOP 90 47 3
Effective Date: August 28, 2012 158
are required to complete the awareness training prior to gaining access to systems.
All users must stay abreast of security policies, requirements, and issues. Users
must make a conscientious effort to avert security breaches by staying alert to
network vulnerabilities.
m. Incident Reporting.
(1) Each user is responsible for reporting any form of security violation, whether
waste, fraud, or abuse through the SBA incident reporting mechanism. Users
shall:
Report security incidents, or any incidents of suspected fraud, waste, or
misuse of Security Operations Center at (202-205-0101) or to the
appropriate supervisor or IT Security Manager.
Take reasonable action immediately upon discovering a violation to
prevent additional damage, such as logging out a terminal or locking up
property.
Cooperate willingly with official action plans for dealing with security
violations.
Prohibition of the Use of Wireless Networks
(1) All SBA employees, contractors, partners, and volunteers are prohibited from
using any unauthorized 802.11xx network devices within SBA buildings. Users
must ensure that any wireless capable devices in their control, including laptops,
PDAs, and Bluetooth telephones have their wireless networking disabled. The
only acceptable use of wireless communications is through the SBA provided
wireless service.
Prohibition of Peer-to-Peer File Sharing
(1) Users are prohibited from using Peer-to-peer (P2P) file sharing. P2P file sharing
poses a threat to IT security. It allows employees to transfer files between
computers without proper security controls. These programs can be used to
distribute inappropriate materials, violate copyright law and put government
information at risk.
(2) There are no exceptions to the requirement that all employees, contractors,
partners, and volunteers comply with these “Rules of Behavior”. If you are not
sure whether your intended computer use is prohibited, you must NOT do it.
Consult with your supervisor or appropriate management official for clarification.
SBA requires employees, contractors, partners, and volunteers to acknowledge
that they understand their responsibilities and accountability for using SBA
information and resources.
SOP 90 47 3
Effective Date: August 28, 2012 159
Appendix J – SBA’s POA&M Process
Purpose
A plan of action and milestone (POA&M) is a management process that outlines weaknesses and
delineates the tasks necessary to mitigate them. SBA’s POA&M process will be used to facilitate
the remediation of weaknesses, and will provide a means for:
a. Planning and monitoring corrective actions;
b. Defining roles and responsibilities for weakness resolution;
c. Assisting in Identifying the security funding requirements necessary to mitigate
weaknesses;
d. Tracking and prioritizing resources; and
e. Informing decision makers.
SBA’s POA&M policies and procedures provide SBA management and System owners with the
necessary information and instructions for developing, maintaining and reporting their
weaknesses. To ensure a comprehensive POA&M process is in place, individual POA&Ms must
be created for every program and system weakness. Thus, there are two types of weaknesses for
which a POA&M would be created:
a. Program Weakness that impact multiple systems, such as the lack of a security policy.
b. System Weakness that arise from a specific management, operational or Technical
control deficiency within a system. For example, a system did not receive an ATO.
POA&Ms are used to assess the state of SBA’s IT security posture and to aid in oversight of IT
investments. OMB requires associating the POA&M to the budgeting process to evaluate the
soundness of an investment. Systems that do not adequately address a plan for securing funding
for mitigation of IT security weaknesses can be placed ‘at risk’ and lose funding. To function
effectively, POA&Ms must be continually monitored and diligently updated.
SBA’s POA&M policies and procedures comply with the requirements prescribed by the Office
of Management and Budget (OMB). There is an E-Government Scorecard under the President’s
Management Agenda which is scrutinized by the President, OMB and Congress as a
performance management exercise. It measures each agency’s progress and assigns a ranking (of
Green, Yellow or Red) based on progress. To get the highest ranking of Green, an agency must
(i) demonstrate consistent progress in remediating IT security weaknesses through their
POA&Ms, (ii) have IG verify there is an Agency-wide IT security POA&M process and (iii)
have 90% of operational IT systems properly secured (e.g., certified and accredited), including
mission-critical systems.
Introduction
SBA is responsible for implementing and administering an information technology (IT) security
program to protect its information resources, in compliance with applicable laws, regulations,
and Executive Orders.
Per OMB Memorandum 03-19, unless specified as a material weakness, the term weakness
refers to any and all IT security weaknesses. Each weakness requires its own separate plan of
action & milestone (POA&M), which can have corrective action plans defined.
POA&Ms assist decision-makers in identifying, assessing, prioritizing, and monitoring
corrective efforts for these weaknesses across their organization. The POA&M process is a
SOP 90 47 3
Effective Date: August 28, 2012 160
management tool for tracking the mitigation of system weaknesses. The intent of the POA&M is
threefold:
a. To be a management tool to assist agencies in closing their security gaps;
b. Assist Inspectors General in their evaluation work of agency security performance; and
c. Assist OMB with their oversight responsibilities. This Guidance provides a unified and
consistent approach to the POA&M process.
Scope
This document applies to all SBA employees and contractors. Any personnel tasked with
completing POA&M activities must review this document to become familiar with the SBA
POA&M process.
Roles and Responsibilities
POA&Ms are designed to be used predominately by SBA management to track the progress of
IT weakness corrective actions.
SBA CIO and program officials must develop, implement, and manage POA&Ms for every
program and system that they operate and control (e.g., for program officials this includes all
systems that support their operations and assets). Although the overall responsibility for the
POA&Ms rests with the CIO, the OCIO is a partner in the POA&M process because others have
significant roles as well, as defined below.
a. Chief Information Officer (CIO)
(1) Oversees and maintains the SBA-wide IT Security program.
(2) Develops and maintains a comprehensive POA&M program.
(3) Assigns responsibility for oversight and management of the SBAPOA&M effort.
(4) Is responsible for the transmission of Agency progress in
(5) Correcting weaknesses reflected in the POA&M and the results of independent IG
inspections to OMB.
(6) Allocates proper resources to permit identification and remediation of
weaknesses.
a. Chief Information Security Officer (CISO)
(1) Ensures organizational compliance with SBA policy, standards, and procedures.
(2) Has delegated authority from the CIO to accept risks that have low risk level.
(3) Receives formal risk acceptance, reviews and provides decision for justification
for closure of findings that are not feasible to close under normal procedures.
(4) Ensures the POA&M process is used to assess SBA-wide IT weaknesses.
(5) Analyzes and designs POA&M process improvements.
(6) Provides guidance and clarification to Authorizing Officials, System
Owner/Primary POC with regard to their corrective action efforts.
a. System Owner (also known as Primary POC)
(1) Capture all weaknesses from all systems that support their operations and assets
through the POA&M Tracker tool.
(2) Develop, implement, and manage system-level corrective action plans. Ensure
that POA&Ms contain appropriate details as required by OMB.
(3) Requests proper resources to permit identification and remediation of weaknesses.
SOP 90 47 3
Effective Date: August 28, 2012 161
(4) Conducts follow-up to verify a corrective action’s status.
(5) Updates SBA management regularly (at the direction of CIO or the program
area’s management officials) on the progress of weakness remediation efforts
enabling the CIO to monitor Agency-wide remediation efforts and provide the
Agency’s quarterly update to OMB.
(6) Gathers documents in support of closing a POA&M and submit final documents
for closure.
a. OCIO Security
(1) Input weaknesses into the enterprise-wide POA&M tracking tool and identify
primary and secondary POCs responsible for corrective action effort.
(2) Provide guidance and clarification to System owner/Primary POC with their
corrective action efforts.
(3) Review final packages completed by the System owner/Primary POC, submit
packages for review and close POA&Ms once final approval occurs.
b. Office of Inspector General (IG)
(1) Assess whether the agency has a POA&M process and the overall effectiveness of
the process.
(2) Agency IGs are an integral part of the POA&M process and will have read
access to agency POA&Ms
Policy
SBA’s CISO is responsible for developing, documenting and implementing a POA&M
management process for all program areas, programs, and systems. The documentation is to
include processes to review and verify accuracy and comprehensiveness of POA&M reporting
for each program area/program/system to include the following:
a. Reporting of all program and system-level findings identified by, for, or on behalf of the
Agency, including FISMA reports, GAO audits, IG audits, findings from the Financial
Audit, critical infrastructure vulnerability assessments, self-assessments and any open
action items resulting from internal security reviews.
b. Identification of program and system-level security for all weaknesses.
c. Link applicable POA&Ms to budget requests as required in OMB budget guidance
(Circular A-11).
d. Track, maintain, review, and prioritize POA&M activities on at least a quarterly basis.
The procedure must include a regular review of the POA&Ms and verification that all
applicable findings are being tracked. In addition to regularly scheduled reviews, a
POA&M assessment is to be completed when there are changes in roles and
responsibilities, or new executive, legislative, technical or Agency guidance is issued;
changes in vulnerabilities, risks or threats occur; and/or new vulnerability findings are
identified in an audit, review, or self-assessment.
e. Verification, validation, and documentation for closure of each POA&M milestone.
Reported closure of milestones and/or findings must be validated by someone other than
the person(s) directly responsible.
Procedures
POA&M remediation is the process whereby a weakness is identified, corrective actions are
initiated, and the weakness is properly mitigated. All security weaknesses that represent risk to
SOP 90 47 3
Effective Date: August 28, 2012 162
the security of a program or system and that require planned mitigation must be captured in a
POA&M. The POA&M lifecycle is depicted and key steps in the process described in greater
detail below.
a. Identify Weaknesses
(1) Weaknesses can be identified from any of the following activities, but not limited
to:
IG audits
Government Accountability Office (GAO) audits
Chief Financial Officer (CFO) reviews
System self-assessments
C&A (security authorization and assessment)
IS program reviews
IS system reviews
Critical Infrastructure Protection (CIP) vulnerability assessments
Risk Assessments
Penetration Tests
b. Risk Acceptance
(1) In some cases, a weakness may not be documented because a determination was
made that the continued existence of the weakness is an acceptable risk. Such a
determination must be certified by the SBA CISO and documented accordingly.
See Standards below for additional guidance.
c. Identify Corrective Actions
(1) Weaknesses identified from an audit will require IG concurrence of proposed
corrective actions. Those identified internally through self-assessments, program
reviews, system reviews or vulnerability assessments will require concurrence by
the SBA CISO.
d. Determine Funding Availability
(1) The cost of remediation activities must be determined and included in POA&Ms.
Additionally, the availability of funding required to mitigate weaknesses must be
evaluated. Three funding scenarios exist in support of POA&M closure efforts.
Current resources exist that may be allocated to mitigate identified
weaknesses. (This is the scenario most commonly adopted because the
weakness needs to be addressed in the near term.)
Resources exist but must be reallocated to support weakness mitigation.
Additional funding must be requested and allocated.
SOP 90 47 3
Effective Date: August 28, 2012 163
(2) If new funding is required, the existing capital planning process must be relied
upon to request and receive the necessary funds.
e. Prioritize Weakness
(1) FISMA guidance requires SBA to prioritize POA&M weaknesses to ensure the
most critical security weaknesses and/or the weaknesses identified on systems
with the greatest potential impact to the organization’s mission are addressed first.
Resource limitations often prevent the System owner from obtaining the resources
necessary to mitigate every identified weakness within the same time period. The
careful prioritization of weaknesses helps to ensure that critically important
weaknesses are allotted resources within a time period proportionate to the risk
associated with the vulnerability or system.
(2) Documented rank-ordering criteria enable the system owner to prioritize
corrective actions in a standardized fashion against factors that are specific to the
SBA operating environments. Criteria against which weaknesses may be
prioritized include:
SBA security initiatives;
Specific security control implementation;
Cost effectiveness of implementing the corrective action; and
Length of time since the weakness was identified.
(3) Basic weakness prioritization focuses on two criteria: system categorization and
weakness risk level. According to FIPS 199, a system must be categorized as
low, moderate, or high based on the confidentiality, integrity, and availability of
the information it stores, processes, or transmits. System characterization must be
determined in the system’s risk assessment. All SBA FISMA reported systems
have been so classified by information category.
The resulting system categorization, also known as the risk impact level, must
then be used to help identify those weaknesses that require immediate attention.
For example, weaknesses associated with a system classified as having a high risk
impact level may pose a greater risk, if not mitigated in a timely manner, in
comparison to a low risk impact level system possessing the same weakness.
f. Assign Estimated completion Dates
(1) The estimated date of completion for each weakness must be based on realistic
timelines that allow for resources to be obtained and associated steps to be
completed. The completion date must be based on the outcome of prioritization
decisions and resource availability. Per OMB, findings/weaknesses identified by
the GAO and IG are generally expected to be completed within 1 year. Consistent
with this guidance, all other findings/weaknesses identified by other sources are
also expected to be completed within 1 year. Note that this date cannot be
changed once keyed because the field containing this date will be locked after the
initial entry. Should the date need to be revised it can be done so on a separate
field. Therefore, it is important this estimated completion date is based on a
realistic timeline.
g. Document Corrective Action Plan (CAP)
SOP 90 47 3
Effective Date: August 28, 2012 164
(1) OMB mandated a POA&M format to provide a consistent baseline of required
and standardized information. As such, the POA&M tracking tool is configured to
ensure all logged POA&Ms are maintained in compliance with OMB
requirements. This structure improves the ability of IT stakeholders to easily
locate information and review details for analysis. Specific information regarding
each individual component of the required POA&M format is discussed in the
Standards section.
h. Monitor and Report POA&M Activity
(1) The information in the POA&M tracking tool must be maintained continuously.
Per OMB requirements, the SBA is expected to provide a quarterly status report
to OMB to communicate overall progress in identifying and mitigating
weaknesses. Further, the IG has access to view all POA&Ms and may be
monitoring POA&M closure progress.
i. Validate Weakness Completion
(1) OMB’s FISMA reporting guidance recommends that weaknesses must be
considered “Completed” only when they have been fully resolved and their
corrective action have been tested. Testing completed POA&Ms demonstrates
that the weakness has been adequately address and proven effective. Reported
closure of the finding/weakness and/or milestones shall be validated by an
independent party –not the individual(s) directly responsible for the closure. All
completed findings/weaknesses shall remain on POA&M report for a period of 1
year from the date of verification.
j. Retire and Transfer Weaknesses
(1) OMB M-04-25 advises that weaknesses that have been mitigated for over a year
must no longer be reported in the POA&M tool. SBA ages off any weaknesses
that have been “Completed” for at least 12 months.
(2) The transfer of POA&M weaknesses from one FISMA system to another must be
clearly traceable and justified. Upon documentation within the POA&M,
weaknesses may only be removed due to transfer to another program- or system-
level POA&M or retirement by the 12 month rule above.
Standards
The standards presented below reflect requirements defined by the Office of Management and
Budget (OMB) Memorandum (M) 02-01, Guidance for Preparing and Submitting Security Plans
of Action and Milestones; M-08-21, FY 2008 Reporting Instructions for the Federal Information
Security Management Act and Agency Privacy Management, dated July 14, 2008; Federal
Information Security Management Act (FISMA) of 2002; and OMB Circular A-130,
Management of Federal Information Resources.
The following standards must be observed when logging and managing a POA&M in the
tracking tool in order to maintain compliance with mandatory OMB and FISMA requirements
and NIST guidance:
a. All IT security weaknesses which represent risks to the security of SBA system
information in the form of a POA&M. In some cases, a weakness may not be
SOP 90 47 3
Effective Date: August 28, 2012 165
documented in the POA&M because a determination was made that the continued
existence of the weakness is an acceptable risk. Such a determination shall be certified
by the CISO and documented accordingly. Suggested means of documentation include
the system self-assessment, the system security plan, or the system certification letter.
Once the documentation is complete, it is not necessary for the weakness to be included
in a POA&M; however, the weakness shall be reviewed periodically to ensure the
associated risk remains acceptable.
b. Create a separate POA&M for each weakness. Multiple weaknesses cannot be entered
into a single POA&M.
c. POA&Ms shall be entered and managed in the SBA's authoritative POA&M
management tool. These POA&Ms shall be developed within10 business days of the
weakness discovery.
d. POA&M weaknesses shall be prioritized by criticality (i.e., weaknesses with the
greatest potential impact to the organization’s mission are addressed first).
e. A completed weakness shall remain in the POA&M for one year following weakness
remediation, at which time the weakness may be removed from POA&M reporting and
archived.
f. The transfer of a weakness from one program or system-level POA&M to another shall
be clearly traceable and justified.
g. POA&Ms require the following information for every weakness reported in the
POA&M reporting tool:
(1) Weakness Identifier *: An identifier shall be assigned to each weakness. The
naming convention for an IT system weakness identifier shall begin with the
name of the system, fiscal year (FY) during which the weakness was first
recorded on the POA&M and a sequence number (e.g., System Name-2003-01).
The naming convention for a non-system specific weakness identifier shall begin
with the source name, the fiscal year (FY) during which the weakness was first
recorded on the POA&M and a sequence number (e.g., OIG-2010-05). The
weakness identifier must not change once it is recorded in the POA&M reporting
tool. Per OMB Circular A-11, for each POA&M that relates to a project for which
a capital asset plan and justification (exhibit 300) was submitted or was a part of
the exhibit 53, the unique project identifier (UPI) must be reflected on the
POA&M. This identifier will provide the link to agency budget materials.
Note: OMB requires each POA&M weakness to be linked to the capital planning
and investment control (CPIC) process using unique project identifiers (UPI). The
UPI, contained in the Exhibit 300 or 53, is submitted to OMB to request and
justify the funding necessary to develop or maintain the system. The UPI, from
either the Exhibit 300 or 53, must match the UPI provided for the asset (e.g.,
system) and the associated POA&M. The consistent use of the UPI supports the
correlation of the security costs associated with a program or system to its overall
security performance.
(2) Weakness Description *: A description shall be created for each weakness in a
POA&M. The term ‘weakness’ refers to any program- or system-level IS
vulnerability that poses a risk to the confidentiality, integrity, or availability of
SOP 90 47 3
Effective Date: August 28, 2012 166
SBA’ information. Sufficient information is required to enable appropriate
oversight and tracking, demonstrate awareness of the weakness, and facilitate the
creation of specific milestones to address the weakness. The weakness description
must not change once it is recorded in the POA&M reporting tool. Note: Sensitive
information, such as identifying vulnerability’s server name or Internet Protocol
[IP] address, shall not be included in the weakness description. It is acceptable to
substitute specific information with a reference where additional information can
be obtained by individuals with a need to know.
(3) Weakness Source *: Identify sources of all weaknesses. When recording the
weakness source, both the type of review and the date on which this review was
conducted or published shall be provided (e.g., 2009 program review, 2010 IG
Audit, 2011 CFO Audit, etc.)
(4) Point of Contact (POC) *: A POC shall be identified and documented for each
weakness reported. The POC shall refer to the position/role responsible for
resolving the weakness. Also, identify the office or organization that the agency
head will hold responsible. The POC must be an SBA staff person instead of a
contractor.
(5) e. Resources Required *: The resources required to successfully complete the
weakness shall be estimated. The estimate shall be based on the total resources
needed to fulfill all the milestones necessary for weakness correction. When
identifying monetary funding, the amount shall be categorized as New Funding,
Existing Funding, or Reallocated Funding. Staffing requirements shall be
estimated as man-hours or full time equivalents (FTEs) and categorized as New
Staff or Existing Staff. System-level POA&Ms must tie directly to the system
budget request through the IT business case to tie the justification for IT security
funds to the budget process. Funding must be tied to the agency’s budget
submission through the unique weakness identifier. Thus, this column cannot be
left blank or equal 0.
(6) Scheduled Completion Date *: A completion date shall be assigned to every
weakness, to include the month, day, and year. This date must provide adequate
time for verification activities. TBD is not acceptable because the Scheduled
Completion Date shall not change once it is recorded in the POA&M reporting
tool. Note: If the time to correct the weakness extends beyond the original
scheduled date of completion, the status of the weakness shall be changed to
‘delayed,’ and reasons for the delay and revised scheduled date of completion
shall be noted in appropriate fields.
(7) Milestones with Completion Dates *: Each weakness shall have a corrective
action plan Documented that identifies specific actions to correct the weakness.
The number of milestones articulated per weakness must directly correspond to
the number of steps or corrective actions necessary to fully address and resolve
the weakness. Each weakness must have at least one corresponding milestone
with an anticipated completion date. The milestone completion date, which cannot
be TBD, identifies the allotted time reserved to address the individual milestone
and helps place milestones in a logical order. Milestone with Completion Date
SOP 90 47 3
Effective Date: August 28, 2012 167
entries shall not change once recorded in the POA&M reporting tool. Note
revised milestone and/or anticipated date of completion in the ‘Changes to
Milestones’ field.
(8) Changes to Milestones: This column only needs to be completed if the CAP
(corrective action plan) cannot be completed by the Milestones Completion Date
or the Scheduled Completion Date cannot be met. The “Changes to Milestones”
field is designed to accommodate fluctuations in the availability of resources,
periodic reprioritization of activities, and unanticipated delays that organizations
regularly experience. If a situation exists that prevents a milestone and/or the
overall corrective action from being completed as originally estimated, the new or
revised milestone and/or anticipated date of completion must be identified in the
“Changes to Milestones” field. No changes can be made to the original estimate in
the “Scheduled Date of Completion,’ or ‘Description of Milestone,’ fields. As
with all completion dates in the POA&M, the new milestone completion date
must include the month, day, and year of estimated completion and cannot be
TBD. An explanation for the revised milestone and/or milestone completion date
must be entered in the “Comments” field.
(9) Weakness Status: The only entries permitted are “Completed”, “Ongoing” or
“Delayed” to each weakness.
Completed-This status is assigned when all corrective actions have been
applied to a weakness such that the weakness is successfully mitigated.
The Date of Completion shall be recorded for a completed weakness.
Ongoing-This status is assigned only when a weakness continues to be
mitigated and has not yet exceeded the associated Scheduled Completion
Date.
Delayed-This status is assigned only when a weakness continues to be
mitigated after the associated Scheduled Completion Date has passed. An
explanation shall be provided in the Weakness Comments field.
(10) Weakness Severity: Every weakness shall be categorized as a Significant
Deficiency, Reportable Condition, or Weakness based on the risk it poses to
SBA’s overall security.
Significant Deficiency-A weakness is considered a significant deficiency
if it drastically restricts the capability of the SBA or program area to carry
out its mission or if it compromises the security of its information,
information systems, personnel, or other resources, operations, or assets.
In this context, the risk is great enough that the SBA or program area head
and outside agencies must be notified, and immediate or near-immediate
corrective action must be taken.
Reportable Condition-A reportable condition is a weakness that does not
rise to the level of significant deficiency yet is still important enough to be
reported to internal management. A security weakness that affects the
efficiency and effectiveness of SBA or program area operations may be
considered a reportable condition.
SOP 90 47 3
Effective Date: August 28, 2012 168
Due to its lower associated risk, corrective actions for a reportable
condition may be scheduled over a longer period of time.
Weakness-All other weaknesses that do not rise to the level of a
significant deficiency or reportable condition must be categorized as a
weakness and mitigated timely and efficiently, as resources permit.
(11) Risk Level: High, Medium, or Low will be assigned to the finding by the
reviewer and cannot be changed by the System owner or System
Developer/Maintainer. Any findings without a designated Risk Level will be
assigned by OCIO Security. Mandatory fields in the POA&M tracking tool that
require an entry.
(12) To Close a Finding: High and Medium Risk Findings: SBA does not allow
system owners to accept risk for High or Medium Findings. They must be
mitigated. See below for risk acceptance of low risk findings.
The system owners must make every attempt to close all findings. Once the CAP
has been implemented for a finding, System owners shall forward all supporting
documentation to OCIO Security as evidence CAP steps were taken to close the
finding. The System owner must also maintain copies of their documents. In the
event a vulnerability cannot be fully resolved, system owners must ensure that
adequate security controls have been put in place to reduce the risk to low. Once
the security controls have been put in place, the system owners must submit all
supporting documentation to OCIO Security, so it can validate security controls
have been implemented.
Low risk findings may be closed based on an approved risk acceptance, which can
be documented on the Risk Acceptance Memorandum of Understanding form
located on the POA&M tracking tool. The system owner will need to submit this
memo to OCIO Security for approval. In the memo, the System owners will need
to explain the reason for accepting the risk including a description of any
compensating controls used to lower the risk. For all risks that are accepted the
System owner must:
Address them in the system’s SSP and/or IS RA.
Review and re-submit the risk acceptance to OCIO Security if the controls
put in place are still valid and appropriate, e.g., upon re-certification of the
system.
Review the accepted risks when a major change to the system has been
performed; and
Retain copies of the approved justification memo as part of the system
security documentation file. =
(13) Verification of Completed “Closed”: In the POA&M tracking tool, many
findings may be shown “pending verification.” This is done to record completion
of a CAP prior to SBA or independent auditor verification, necessitated by the
fact that many of these items cannot be validated for months after the reported
closure dates (for example during follow-on audits). To do so otherwise would
grossly overstate the number of non-completed or “delayed” findings. Because of
SOP 90 47 3
Effective Date: August 28, 2012 169
timing of the validations, it is not uncommon to have many findings in the
completed “pending verification” status at any given time.
Additional POA&M References: OMB Memo 01-24, OMB Memo 02-01, Memo 02-09, Memo
03-19, E-Government Act, Title III (speaks to FISMA requirements), E-Government
Scorecard under the President’s Management Agenda, NIST 800-53 CA-5, 800-37, Circular
A-11
SOP 90 47 3
Effective Date: August 28, 2012 170
ATTACHMENT A: CLOSURE PACKAGE INSTRUCTIONS
To close a POA&M, the following steps must be taken once all corrective actions have been
completed and supporting evidence is prepared for review by OCIO security:
System POA&Ms
a. The system owner submits a signed closure package form with all supporting physical
and/or electronic documentation to OCIO’s security POC for review.
b. OCIO’s security POC will review the package for completeness and appropriateness. If
the package appears to address the weakness the OCIO Security POC will submit the
package to the CISO for final review and closure. However, if there are missing
documents or items that require further clarification, the OCIO POC may require
additional documentation or further discussion before the package can be sent to the
CISO for final review.
c. The CISO will review and sign the closure package if it is determined all mitigation steps
have been met.
d. OCIO ‘s security POC will upload a signed copy of the closure package in the POA&M
tracking tool. This will trigger an automatic email to the system owner to acknowledge
the POA&M has been successfully closed.
Program POA&Ms
a. The system owner completes the Final Action section of the POA&M, which is located
under the Task Detail link. Once the mandatory fields are completed click the Generate
Form 1824 button at the bottom of the form to automatically generate the
Recommendation Action Sheet (RAS, also known as the 1824 form).
b. The system owner must physically sign the 1824 form in the Originating Official
Signature field and date the form.
c. Compile the signed 1824 form with all supporting physical and/or electronic
documentation, termed the final action package, to OCIO’s security POC for review.
d. OCIO’s security POC will review the final action package for completeness and
appropriateness. If the package appears to address the weakness, OCIO’s security POC
will submit the package to the CISO for review. This final action package will also be
reviewed and approved by the Deputy CIO and/or CIO and OIG. However, if there are
missing documents or items that require further clarification, the OCIO POC may require
additional documentation or further discussion in order to complete the final action
package and submit it up the chain of review. Any of the chain approvers may also
require additional documents or comments.
e. Once a chain reviewer signs the final action package the next chain reviewer will also
review the package for signoff. Once the OIG has signed off on the package, can it be
deemed truly closed.
f. Upon receiving the OIG’s signature on the final action package, OCIO’s Security POC
will upload a signed copy of the closure package in the POA&M tracking tool. This will
trigger an automatic email to the system owner to acknowledge the POA&M has been
successfully closed.
SOP 90 47 3
Effective Date: August 28, 2012 171
Appendix K – Security Assessment and Authorization Process
Purpose
This document pertains to all individuals who play a role in the security assessment and
authorization process at the U.S. Small Business Administration (SBA). The intent is to give an
initial understanding of roles, responsibilities, and individual accountability in the security
assessment and authorization process.
SBA has diverse and complex information technology (IT) resources and uses many different
computer programs in executing its mission. To ensure that adequate security is provided for
Agency sensitive data and personally identifiable information (PII) contained within its
information systems, SBA must assure that all systems adhere to SBA’s security policies and
Federal mandates (laws, regulations, and directives).
One of these mandates, the Federal Information
Security Management Act (FISMA) of 2002, directs
the Secretary of Commerce to prescribe standards and
guidance for Federal information systems to include the
implementation of recommended security controls and
the security assessment and authorization process.
SBA has updated its Agency-wide security assessment
and authorization program to implement these
standards and guidelines. The updated program utilizes
the National Institute of Standards and Technology
(NIST) guidelines for assessing the extent to which
Federal information systems and the operating
environment meet SBA’s security policies and at least
the minimum requirements for Federal systems. It
defines the scope and process for formal management
review, approval, and oversight procedures to ensure
that adequate controls are provided and maintained
over the life cycle of each system that processes
sensitive data.
SBA’s Systems Security Program Protects Information and Information
Systems;
Includes the Security Assessment and
Authorization process as a key component;
Follows IT security policies, guidelines and
mandates to include FISMA and NIST
standards;
Introduction
Objectives of SBA’s Automated Information System Security Program
The objective of SBA’s Automated Information System (AIS) Security Program is to ensure
adequate protection of confidentiality, integrity, and availability SBA’s information and
information systems.
This program adheres to a Risk Management Framework, defined by the guidelines of National
Institute of Standards and Technology (NIST). The assessment of security controls and
authorizing information systems to operate is a critical component of this program. This program
also covers the management practices to meet OMB’s Memorandum M-10-15, for reporting
requirements under the Federal Information Security Management Act of 2002 (FISMA) (Title
III, Pub. L. No. 107-347) and reporting requirements on SBA’s privacy management program.
SOP 90 47 3
Effective Date: August 28, 2012 172
This document describes a standard approach for performing security assessments and
authorizations regardless of acquisition strategy or life cycle status. The document also identifies
Federal security laws and regulations and the roles and responsibilities of the various individuals
and activities that affect the security assessment and authorization process.
a. Definition of Terms: Authorization (to operate): The official management decision
given by a senior agency official to authorize operation of an information system and to
explicitly accept the risk to agency operations (including mission, functions, image, or
reputation), agency assets, individuals, other organizations, and the Nation, based on the
implementation of an agreed-upon set of security controls.
b. Control: In the context of information systems security, this term describes requirements
in the design, development, implementation, operation and management of information
systems.
c. Common Control: A security control that is inherited by one or more agency information
systems from another source.
d. System-Specific Security Control: A security control for an information system that is
implemented by using its own resources.
e. Hybrid Security Control: A security control that is implemented in an information
system in part as a common control and in part as a system-specific control.
f. General Support System: An interconnected set of information resources under the same
direct management control, whose capabilities are shared by many other information
systems.
g. Major Application: An application that requires special attention to security due to the
risk and magnitude of the potential harm resulting from the loss, misuse, or unauthorized
access to or modification of the information in the application. A major application can
be either a major software application or a combination of hardware and software and the
only purpose of the system is to support a specific mission-related function.
h. Minor Application: An application, other than a major application, that requires 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. Minor
applications are typically assessed and authorized as a part of a general support system.
However, some minor applications, such as outsourced systems, are not part of any major
system and must be separately authorized.
i. Management Controls: The security controls (i.e., safeguards or countermeasures) for an
information system that focuses on the management of risk and the management of
information system security.
j. Operational Controls: The security controls (i.e., safeguards or countermeasures) for an
information system that are primarily implemented and executed by people (as opposed
to systems).
SOP 90 47 3
Effective Date: August 28, 2012 173
k. Technical Controls: These are the security controls (i.e., safeguards or countermeasures)
for an information system that are primarily implemented and executed by the
information system through mechanisms contained in the hardware, software, or
firmware components of the system.
l. Risk Assessment: This process identifies risks to agency operations (including mission,
functions, image, or reputation), agency assets, individuals, other organizations, and the
Nation resulting from the operation of an information system. Part of risk management,
incorporates threat and vulnerability analyses, and considers mitigations provided by
security controls planned or in place. This term is also used interchangeably with risk
analysis.
m. Security Control Assessment: This involves testing and/or evaluation 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.
Risk Management in SBA’s IT Security Program
SBA’s IT Security Program follows the Risk Management Framework (RMF) as defined by
NIST. The RMF is a structured approach that integrates information security and risk
management into the system development life cycle. The key steps of the RMF are to:
a. Categorize the information system and the information processed;
b. Select an initial set of baseline security controls for the information system based on the
security categorization, tailoring, and supplementing the security control;
c. Implement the security controls and describe how the controls are employed within the
information system and its environment of operation;
d. Assess the security controls using appropriate assessment procedures 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;
e. Authorize information system operation based on a determination of the risk to
organizational operations and assets, individuals, other organizations, and the Nation
resulting from the operation of the information system and the decision that this risk is
acceptable; and
f. Monitor the security controls in the information system on an ongoing basis including
assessing control effectiveness, documenting changes to the system or its environment of
operation, conducting security impact analyses of the associated changes, and reporting
the security state of the system to designated organizational officials.
The security assessment and authorization procedures cover the first five (5) steps of the RMF.
SBA’s IT Security program monitors security controls through means that are beyond the scope
of this document.
SOP 90 47 3
Effective Date: August 28, 2012 174
Governance
SBA’s Office of Information Security coordinates its activities with the SBA’s committees and
program areas. An important committee with which SBA’ Office of Information Security aligns
its risk-based activities is the Business Technology Investment Council (BTIC) and its
permanent and ad-hoc working groups referred to as the Business Technology Investment
Advisory Council (BTI-AC). The BTIC is the executive oversight body for the SBA’s
Information Technology Investment Management (ITIM) processes and transformational
business processes that constitute the Agency Enterprise Architecture (EA) projects. The CIO
and the Chief Financial Officer (CFO) serve as co-chairpersons of the Council. The goal of the
Council is to ensure that the Agency's major IT and transformational business investments are
driven and grounded by deliberate business needs and is in compliance with the SBA Enterprise
Architecture criteria which reflect the Agency's mission, strategic goals & objectives, current and
target IT and business service delivery, the cost, benefit and risk-adjusted return of those
investments. The Council presents its advice and recommendations to the SBA Administrator.
Overview - Security Assessment and Authorization Process
This security assessment and authorization process is a collaborative process through which a
system is categorized, security controls are selected, security controls are implemented, security
controls are documented, security controls are assessed, risks are identified, and the system is
authorized to operate by designated authorizing officials. In effect, the system is authorized to
operate and the risks are being accepted with a plan to mitigate them. It is essential to emphasize
that OIS maintains sufficient separation of duties and independence while providing guidance to
system development activities while conducting assessments.
The five high-level steps of the security assessment and authorization process (derived directly
from guidelines provided by NIST SP 800-37) are divided into two stages--preparation and
security assessment and authorization. The steps involved in the phases are provided below.
Stage 1: Preparation
Select and Implement
Categorize System
Select Controls
Implement and Document Controls
Stage 2: Assessment and Authorization
Assess and Authorize
Assess Controls
Authorize to Operate
The schematic below presents an overview of the security assessment and authorization
process.
SOP 90 47 3
Effective Date: August 28, 2012 175
FIGURE-1
The rest of this document elaborates further on the security assessment and authorization
process and its details.
Roles and Responsibilities
The security assessment and authorization process involves a coordinated effort of individuals
from different areas of the organization. The security assessment and authorization roles and
responsibilities are presented in the table below:
Table 1: Security Assessment and Authorization Roles and Responsibilities
SBA TITLE ROLES AND RESPONSIBILITIES
SBA Administrator
Designates authorizing officials for SBA’s information systems;
Establishes SBA’s commitment to information security and the actions
required to effectively manage risks and protect the core missions and
business functions carried out by SBA;
Establishes appropriate accountability for information security and
provides active support and oversight of monitoring and improvement for
the information security program;
Establishes senior leadership’s commitment to information security and a
level of due diligence within the Agency that promotes a climate for
mission and business success;
Note:
Authorizing authority for SBA’s general support systems resides with the CIO.
Major applications, and separately authorized minor applications, are jointly
authorized by the senior management official who oversees the business
SOP 90 47 3
Effective Date: August 28, 2012 176
operations and budget for the information system and the CIO;
Chief Information
Officer (CIO)
Designates CISO;
Designates the assessing authority;
Develops and maintains information security policies, procedures, and
control techniques;
Trains and oversees personnel with significant responsibilities for
information security;
Assists senior SBA officials with their security responsibilities;
Reports annually to the Administrator regarding the effectiveness of
SBA’s security program, including the progress on remedial actions;
Serves as the Agency’s privacy officer.
Chief Information
Security Officer (CISO) Develops, implements, and maintains security assessment and
authorization documentation;
Carries out the CIO’s responsibilities under FISMA;
Advises system owners about the security assessment and authorization
process and security requirements;
Monitors the effectiveness of the SBA’s security program
Conducts periodic tests of SBA contingency plans;
Authorizing Official
Coordinates activities with SBA Management Board, CIO, CISO,
common control providers, system owners, ISSOs, Office of Information
Security (OIS), and other interested parties during the security
authorization process;
Approves system security requirements, system security plans,
memoranda of agreement and/or memoranda of understanding, plan of
action and milestone, and interconnection security agreements;
Authorizes information system operation;
Authorizes system interconnections;
Denies or revokes authorization to operate the information system;
Determines and accepts the risk of operating an information system;
Determines whether significant changes in the information system or
environments of operations, require reauthorization; Authorizing Official’s
Designated
Representative
Interacts with the CISO, system owner, ISSO, OIS, and other interested parties
during the security assessment and authorization process;
Carries out the responsibilities of the authorizing authority as assigned, with
authority as delegated ;
The authorizing authority may assign responsibilities and delegate authority, with
the exception of granting final authority to make the authorization decision and
sign the associated authorization statement;
Office of Information
Security
Reviews initial risk assessments, system security plans, security interconnection
agreements, privacy impact assessments, and other documentation to ensure
security requirements for SBA’s IT systems have been adequately addressed;
Conducts a comprehensive assessment of the management, operational, and
technical security controls employed within or inherited by an information system
to determine the overall effectiveness of the controls (i.e., 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);
Provides an assessment of the severity of weaknesses or deficiencies discovered in
the information system and its environment of operation and recommend
corrective actions to address identified vulnerabilities;
Prepares the final security assessment report containing the results and findings
from the assessment;
Develops and compiles security authorization packages for the system owners;
SOP 90 47 3
Effective Date: August 28, 2012 177
Common Control
Provider
Responsible for documenting SBA identified common controls in the system
security plan;
Responsible for ensuring required assessments of common controls are carried out
by qualified assessors with an appropriate level of independence as defined by
SBA;
Responsible for documenting assessment findings in a security assessment report;
Responsible for producing a plan of action and milestones for all controls having
weaknesses or deficiencies;
System Owner Develops the system security plan (SSP) for new systems;
Supports assessment efforts including assuring required documentation and test
resources are available;
Reviews draft security authorization packages and develops and implements risk
mitigation plans for inclusion in the final package;
Ensures security controls for authorized systems are implemented and maintained;
Decides who has access to the system and the appropriate privileges and access
rights;
Notifies the authorizing authority and assessing authority of any changes to the
operating environment that affect authorization status;
Updates the system security plan to reflect system changes and supports re-
assessment and re-authorization efforts;
Appoints the Information System Security Officer and other system owner POCs;
Establishes rules for the appropriate use and protection of the information (i.e.,
“Rules of Behavior”) and retains this responsibility when the information is shared
with other organizations;
The system owner is also the owner of the information;
Information System
Security Officer (ISSO)
Responsible to the system owner for ensuring that the appropriate security posture
is maintained for an information system or program;
Serves as the primary advisor to the system owner for matters involving the
security of the system;
Performs assigned responsibilities for the day-to-day security operation of the
system (e.g., physical and environmental protection, personnel security, incident
handling, security training and awareness, monitoring of security controls);
Employs best practices when implementing security controls within an
information system including software engineering methodologies,
system/security engineering principles, secure design, secure architecture, and
secure coding techniques;
Coordinates security- related activities with the CISO;
Responsible to the system owner for assigned day to day security operations
(e.g., account management, vulnerability scans, intrusion detection analysis, audit
reviews, contingency testing, and other monitoring activities);
SBA Management Board
SBA’s CIO and CISO will work with SBA’s management board to accomplish the
following functions:
Provide a comprehensive, SBA-wide, holistic approach for addressing risk—an
approach that provides a greater understanding of the integrated operations of the
organization;
Develop a risk management strategy for SBA providing a strategic view of
information security-related risks with regard to SBA as a whole;
Facilitate the sharing of risk-related information among authorizing officials and
other senior leaders within SBA;
Provide oversight for all risk management-related activities across SBA (e.g.,
security categorizations) to help ensure consistent and effective risk acceptance
decisions;
Ensure that authorization decisions consider all factors necessary for mission and
business success;
SOP 90 47 3
Effective Date: August 28, 2012 178
Provide SBA-wide forums to consider all sources of risks (including aggregated
risks) to SBA operations and assets, individuals, other organizations, and the
Nation;
Promote cooperation and collaboration among authorizing officials to include
authorization actions requiring shared responsibility;
Ensure the shared responsibility for supporting SBA mission/business functions
using external providers of information and services receives the needed visibility
and is elevated to the appropriate decision-making authorities;
Identify SBA risk posture based on the aggregated risk to information from the
operation, and use of the information systems for which the organization is
responsible.
Security Requirements
Minimum security requirements for Federal information systems are defined by NIST
publication FIPS PUB 200. Agencies must meet these minimum security requirements by
selecting appropriate security controls from NIST publication SP 800-53. The selection of
appropriate minimum controls is based upon how the system has been categorized from a
security perspective. Categorization is based upon NIST publications FIPS PUB 199 and SP 800-
60. In addition to defining the various controls, NIST publication SP 800-53 provides
supplemental guidance to assist in security planning and security assessment. Federal mandates
driving a particular control are identified (public law, directive, or federal regulation). For some
controls, the control identifies parameters that are to be defined by SBA policy or by system
specific requirements. SBA’s primary security policy document is SOP 90 47 2 “Automated
Information Systems Security Program.” Additionally, secure baseline configuration guides
have been established for the commercial products in the Agency’s architecture. Parameters not
specified by Agency policy must be defined in the system’s security plan, which is approved by
the Authorizing Official.
SBA Security Assessment and Authorization and the Security Life Cycle
Systems in SBA’s architecture are inventoried and classified as major applications, general
support systems, minor applications, or other. Any system that meets the definition of a major
application, a general support system, or a minor application must be authorized. A minor
system may be authorized as a part of a major system. Some minor applications, such as
outsourced systems, are not part of any SBA system and are authorized separately.
Implementing and maintaining security in any system can be most efficiently accomplished
when security is an integral part of the system’s life cycle. Changes to a system under
development are easier and less costly to make than the same changes made to the system after it
is already in production. SBA’s System Development Method (SDM) recognizes this fact and
provides guidance to project managers and developers regarding the security tasks to be
performed in each phase of the life cycle. Detailed guidance can be found at the following SBA
intranet location:
(http://www.sba.gov/sites/default/files/SBA%20System%20Development%20Methodology.pdf).
The SDM defines the tasks to be performed and documents to be prepared during the eight life
cycle stages: Initiate Project, Plan System, Define System, Design System, Build and Test
System, Implement System, Operate and Maintain System and Retire System. Security related
considerations are described in this section for each phase.
SOP 90 47 3
Effective Date: August 28, 2012 179
System owners will work with SBA’s Office of Information Security to implement the risk
management framework steps described in section 4.2 to 4.6 as a part of their system
development life cycle, though the security assessment and authorization process covers all tasks
described in 4.7 except RMF STEP 6 – “Monitor Security Controls.”
RMF STEP 1 - Categorize Information System
During RMF STEP 1 – the following tasks are specified for the system during the early stages of
the SBA SDM:
Table 4-2: Categorize Information System
Security Categorization,
Information System Description, and
Information System Registration
The system owner is primarily responsible for:
Categorizing the information system and documenting the results of the security
categorization in the system security plan;
Describing the information system (including system boundary) and document the
description in the system security plan; and
Registering the information system with appropriate SBA program/management offices.
RMF STEP 2 – Select Security Controls
During RMF STEP 2 – the following tasks are specified for the system:
Table 2: Select Security Controls
Common Control Identification
Security Control Selection
Monitoring Strategy
System Security Plan Approval
The first three tasks, common control identification, security control selection and monitoring
strategy are implemented during the early stages of the SBA SDM. The last task, system security
plan approval, is implemented during later stages of the SBA SDM. The CIO, CISO, and
Common Control Provider are primarily responsible for identifying the security controls that are
provided by SBA as common controls for SBA information systems and documenting the
controls in a system security plan.
The system owner is primarily responsible for selecting the security controls for the information
system and documenting the controls in the system security plan.
SOP 90 47 3
Effective Date: August 28, 2012 180
The system owner or common control provider is primarily responsible for developing a strategy
for the continuous monitoring of security control effectiveness and any proposed or actual
changes to the information system and its environment of operation.
The authorizing official or the authorizing official’s designated representative is primarily
responsible for reviewing and approving the system security plan.
RMF STEP 3 – Implement Security Controls
During the RMF STEP 3 – the following tasks are specified for the system during the Build, Test
and Implement stages of the SBA SDM:
Table 3: Implement Security Controls
Security Control Implementation
Security Control Documentation
The system owner or common control provider is primarily responsible for (1) implementing the
security controls specified in the system security plan and (2) documenting the security controls
implementation in the system security plan (as appropriate), providing a functional description of
the control implementation (including planned inputs, executed behavior, and expected outputs).
RMF STEP 4 - Assess Security Controls
During the RMF STEP 4 – the following tasks are specified for the system to assess security
controls, before the system is implemented:
Table 4: Assess Security Controls
Assessment Preparation
Security Control Assessment
Security Assessment Report
Remediation Actions
OIS is primarily responsible for:
Developing, reviewing, and approving security assessment plans for security controls;
Assessing the security controls in accordance with the assessment procedures defined in
the security assessment plan; and
Preparing the security assessment report documenting the issues, findings, and
recommendations from the security controls assessment plan.
The system owner (or common control provider) is primarily responsible for conducting
remediation actions on security controls based on the findings and recommendations of
the security assessment report. The Office of Information Security will reassess
remediation control(s), as appropriate.
RMF STEP 5 – Authorize Information System
During the RMF STEP 5 – the following tasks are specified for the system, before the system is
implemented:
SOP 90 47 3
Effective Date: August 28, 2012 181
Table 4-6: Authorize Information System
Plan of Action and Milestone,
Security Authorization Package,
Risk Determination, and
Risk Acceptance
The system owner or common control provider is primarily responsible for:
Preparing the plan of action and milestones based on the findings and recommendations
of the security assessment report excluding any remediation actions taken; and
Assembling and submitting the security authorization package to the authorizing official
for adjudication.
The authorizing official or AO’s designated representative, is primarily responsible for
determining whether the risk to SBA operations (including mission, functions, image, or
reputation), SBA assets, individuals, other organizations, or the Nation, is acceptable
RMF STEP 6 – Monitor Security Controls
During the RMF STEP 6 – the following tasks are specified for the system during the Operate,
Maintain and Retire stages of the SBA SDM.
Table 5: Monitor Security Controls
Information System and Environment Changes
Ongoing Security Control Assessments
Ongoing Remediation Actions
Key Updates
Security Status Reporting
Ongoing Risk Determination and Acceptance
Information System Removal and Decommissioning
The above step is described through processes beyond the scope of the security assessment and
authorization process.
SECURITY ASSESSMENT AND AUTHORIZATION OF THE SYSTEM
This section discusses in more detail the five RMF steps, divided into two stages:
Preparation
Stage 1: Select and Implement
Categorize System
Select Controls
Implement and Document Controls
Assessment and Authorization
Stage 2: Assess and Authorize
Assess Controls
SOP 90 47 3
Effective Date: August 28, 2012 182
Authorize to Operate
Security Assessment and Reassessment
Per NIST guidelines, an authorization to operate (ATO) is valid for no more than three (3) years.
All information systems are required to repeat the security assessment and authorization every
three years. However, major system changes or other Agency-wide security program changes
could trigger a reassessment before the ATO expires.
For a system undergoing the security assessment and authorization process for the first time, or
for systems that have been assessed before, the process is the same. In cases involving
reassessment, a system may have a set of prior security documentations to reference throughout
the process. Even when such documents are available, system owners are still responsible for
and incorporating numerous changes in system security policies, procedures, and standards that
occur periodically.
Stage 1- Select and Implement
The steps to complete the “Select and Implement” stage are listed below:
Step 1: Initiate – Incorporate information system security requirements as a part of system
development life cycle (SDLC);
Step 2: Categorize the information system;
Step 3: Select security controls;
Step 4: Create system security documents;
Step 5: Review security documents;
Step 6: Finalize and approve system security documents; and
Step 7: Implement security controls.
The tasks, primary responsibility, and output/outcome of the above steps are listed in the
following tables.
Stage: Select and Implement
Step 1: Initiate
Task Primary Responsibility Output/Outcome
Identify names of system owner and
points of contacts
System Owner, ISSO Participants for assessment
established;
Induct system security
requirements/tasks in System
Development life cycle
System Owner, ISSO FISMA requirements explained
System security documents
explained
Assessment process explained
Roles & responsibilities established
Timeline, escalations, next steps
agreed upon
Stage: Select and Implement
Step 2: Categorize Information System
Task Primary Responsibility Output/Outcome
Categorize the information system
answering question in FIPS 199
worksheet
System Owner, ISSO System security categorization (i.e.,
low, moderate, or high) established
using FIPS worksheet; document
SOP 90 47 3
Effective Date: August 28, 2012 183
results in the system security plan
Describe the information system
(including boundary)
System Owner, ISSO Document the description in the
system security plan
Register the information system with
SBA program/management offices
System Owner, ISSO Information system registered with
OCIO
Start developing the system security
plan
System Owner, ISSO Draft SSP
Stage: Select and Implement
Step 3 : Select Security Controls
Task Primary Responsibility Output/Outcome
Identify the security controls that are
provided by SBA as common
controls for SBA information
systems
CIO, CISO, Common Control
Provider
Document common controls in
system security plan
Select the security controls for the
information system
System Owner, ISSO Document the security controls in
system security plan
Develop a strategy for the
continuous monitoring of security
control effectiveness and any
proposed/actual changes to the
information system and its
environment of operation
System Owner, ISSO or Common
Control Provider
An effective monitoring strategy
Stage: Select and Implement
Step 4 : Develop System Security Documentation
Task Primary Responsibility Output/Outcome
Provide a list of required system
security documents
OIS System Owner is informed of the
required system security documents
with relevant document templates
Develop documents System Owner, ISSO System Security Plan
Configuration Management Plan
Risk Assessment
E-Authentication Risk Assessment
FIPS 199 worksheet
BIA
PIA/PTA
Contingency Plan
Incident Response Plan
Monitoring Strategy
Identify Gaps OIS Documents are reviewed for
completeness and gaps are identified
Stage: Select and Implement
Step 5 : Review Security Documents
Task Primary Responsibility Output/Outcome
Provide missing documents, if any System Owner, ISSO System owner is informed of
missing documents to create them
Fill missing sections in current
system security documents
System Owner, ISSO System security documents are
marked with gaps and sent back to
the system owner to update them
Make changes due to updates in
NIST controls & OMB notifications
and SBA directives
System Owner, ISSO System security documents are
‘marked’ with “Instructions for
updates” and sent back to the system
SOP 90 47 3
Effective Date: August 28, 2012 184
owner to update them
Stage: Select and Implement
Step 6: Finalize and Approve System Security Documents
Task Primary Responsibility Output/Outcome
Review and finalize documents System Owner, ISSO Completed system security
documentation
Present documents for review by
CISO
System Owner, ISSO
Approve SSP Authorizing Official Authorizing official indicates
completeness of SSP
Sign-off by CISO’s office CISO All system security documents are
signed off by CISO’s office. This
approval indicates the readiness of
the system security documents for
assessment and triggers the
subsequent assessment stage.
System owner will implement
security controls as per their
documentation.
Stage: Select and Implement
Step 7 : Implement Security Controls
Task Primary Responsibility Output/Outcome
Implement the security controls
specified in the system security plan
System Owner, ISSO or Common
Control Provider
Implementation of system security
plan
Document the security control
implementation, as appropriate, in
the system security plan, providing a
functional description of the control
implementation (including planned
inputs, expected behavior, and
expected outputs)
System Owner, ISSO or Common
Control Provider
Document the security control
implementation, as appropriate, in
the system security plan
Stage 2- Assess and Authorize
The steps to complete the Assessment are listed below:
Step 1: Develop strategy and plan for security control assessment;
Step 2: Execute security control assessment;
Step 3: Determine ‘initial’ vulnerabilities (iteratively);
Step 4: Resolve ‘initial’ vulnerabilities and finalize ‘remaining’ vulnerabilities;
Step 5: Determine residual risks from finalized list of ‘remaining’ vulnerabilities;
Step 6: Create/Update POA&M;
Step 7: Update SSP with planned/compensating controls;
Step 8: Create security assessment report;
SOP 90 47 3
Effective Date: August 28, 2012 185
The steps to complete the Authorization are listed below:
Step 9: Assemble security authorization package;
Step 10: System Owner, ISSO or Common Control Provider Review;
Step 11: CISO Review and evaluate risk;
Step 12: CISO makes authorization recommendation;
Step 13: Authorize Information System;
Step 14: Closure;
The tasks, primary responsibility and output/ outcome of the above steps are listed in the
following tables.
Stage: Assess and Authorize
Step 1: Develop Strategy and Plan for Security Control Assessment
Task Primary Responsibility Output/Outcome
Develop, review, and approve a
plan to assess the security controls
Independent Assessor on a case by
case basis
Supporting staff identified
Test plans created
Site visits are defined
Create a project plan for
assessment tasks with timeline and
resources
Independent Assessor with System
Owner, ISSO
Documented security assessment
project plan with timeline and
resources is sent out to system
owner
Finalize security assessment
project schedule
Independent Assessor with
System Owner, ISSO
Approved security assessment
project plan
A list of supporting
documentation, if any required for
assessment is sent to system owner
Stage: Assess and Authorize
Step 2: Execute Security Control Assessment
Task Primary Responsibility Output/Outcome
Assess management controls in
accordance with the assessment
procedures defined in the security
assessment plan
Independent Assessor Initial vulnerabilities, if any in
management controls identified
Assess operational controls
in accordance with the assessment
procedures defined in the security
assessment plan
Independent Assessor Initial vulnerabilities, if any in
operational controls identified
Assess technical controls in
accordance with the assessment
procedures defined in the security
assessment plan
Independent Assessor Initial vulnerabilities, if any in
technical controls identified
Scan servers Independent Assessor Identify additional vulnerabilities, if
any
Stage: Assess and Authorize
Step 3: Determine Initial Vulnerabilities (Iteratively)
Task Primary Responsibility Output/Outcome
SOP 90 47 3
Effective Date: August 28, 2012 186
Stage: Assess and Authorize
Step 2: Execute Security Control Assessment
Document initial vulnerabilities Independent Assessor Initial vulnerabilities are presented
to the system owner
Stage: Assess and Authorize
Step 4: Resolve Initial Vulnerabilities And Finalize Remaining Vulnerabilities List
Task Primary Responsibility Output/Outcome
Resolve initial vulnerabilities and
finalize remaining vulnerabilities
System Owner, ISSO or Common
Control Provider
The list of initial vulnerabilities is
reduced, if not fully eliminated and
the list of remaining vulnerabilities
is finalized.
Stage: Assess and Authorize
Step 5: Determine Residual Risks From Finalized List Of Remaining Vulnerabilities
Task Primary Responsibility Output/Outcome
Determine residual risk from
finalized list of remaining
vulnerabilities
Independent Assessor A finalized list of residual risk
Risk Assessment Report
Stage: Assess and Authorize
Step 6: Create/Update POA&M
Task Primary Responsibility Output/Outcome
Explain vulnerabilities and risk
levels
Independent Assessor All vulnerabilities leading to
residual risks are clarified in full
Determine mitigation strategies System Owner, ISSO or Common
Control Provider
Documented mitigation strategies
Establish dates for mitigation System Owner, ISSO or Common
Control Provider
Dates are assigned to each
mitigation task
Finalize POA&M System Owner, ISSO or Common
Control Provider
POA&M agreed to by the System
Owner is created
Stage: Assess and Authorize
Step 7 : Update SSP With Planned/Compensating Controls
Task Primary Responsibility Output/Outcome
Identify POA&M mitigation strategy related to security controls
System Owner, ISSO or Common Control Provider
A list of planned new controls, changes to current controls, compensating controls is extracted from POA&M document
Update the SSP with planned controls and compensating controls
System Owner , ISSO or Common Control Provider
Updated SSP that reflects POA&M mitigation tasks is created
Stage: Assess and Authorize
Step 8: Create Security Assessment Report (SAR)
Task Primary Responsibility Output/Outcome
Describe assessment methodology Independent Assessor Security Assessment Report
Add risk assessment results OIS Security Assessment Report
Formulate and include authorization
recommendations
Independent Assessor Security Assessment Report
Review & finalize SAR Independent Assessor Security Assessment Report
Stage: Assess and Authorize
Step 9: Assemble Security Authorization Package
SOP 90 47 3
Effective Date: August 28, 2012 187
Task Primary Responsibility Output/Outcome
Include latest versions of:
System security plan
Privacy impact analysis
Contingency plan
Configuration management plan
Incident response plan
Security control assessment plan
Security assessment report
Risk assessment report
POA&M
Monitoring Strategy
Independent Assessor, System
Owner, ISSO or Common Control
Provider
Security authorization package
Stage: Assess and Authorize
Step 11: CISO Review and Evaluate
Task Primary Responsibility Output/Outcome
Present security authorization
package to CISO
Independent Assessor Security authorization package is
made available for CISO review and
comments
All necessary updates are made
resulting from the review.
Stage: Assess and Authorize
Step 12: CISO Makes Authorization Recommendation
Task Primary Responsibility Output/Outcome
Make authorization recommendation
CISO Determine risk posture and make
recommendation for authorization
Stage: Assess and Authorize
Step 13: Authorizing Official Review
Task Primary Responsibility Output/Outcome
Present authorization package to
Authorizing Official
CISO Summary and details of the residual
risks in operating the system in its
current state and scheduled
mitigation tasks in response to the
identified risks are the key
information presented
Determine the risk SBA operations
(including mission functions, image,
or reputation), SBA assets,
individuals, other organizations, or
the Nation
Authorizing Official or Authorizing
Official’s Designated Representative
Risk determination is made with
acceptable residual risks, subject to
the plan of action to mitigate them
Determine if the risk to SBA
operational assets, individuals, other
organizations, or the Nation is
acceptable
Authorizing Official or Authorizing
Official’s Designated Representative
Authorization to Operate or Denial
of Authorization to Operate
Page: Assess and Authorize
Step 10: System Owner, ISSO, or Common Control Provider Review
Task Primary Responsibility Output/Outcome
Present security authorization
package to the System Owner or
Common Control Provider
OIS Security authorization package is
made available to the System Owner
or Common Control Provider for
review and comments
SOP 90 47 3
Effective Date: August 28, 2012 188
Stage: Assess and Authorize
Step 14: Closure
Task Primary Responsibility Output/Outcome
Bring assessment process to a
closure
Independent Assessor Authorization signature pages are
added to the authorization package
POA&M is added to the audit
tracking tool
All other documents of the
assessment package are added to the
IT security portal
Electronic copy of all documents of
the system assessment package is
provided to the system owner, ISSO.
Communication is sent to all
stakeholders concerning the
authorization decision
![The National Security Council:nsp_intro.golearnportal.org/rawmedia_repository/e8... · Web viewESTABLISHMENT of the NATIONAL SECURITY COUNCIL. ... [Santa Monica, Ca.]: RAND Corporation,](https://img.pdfslide.us/doc/110x75/5b0442357f8b9a41528c3a5f/the-national-security-councilnspintro-viewestablishment-of-the-national-security.jpg)
