Table of Contents | Appendix C-9 | Appendix C-11
To carry out its wide ranging responsibilities, the Department of Justice (DOJ), employees and managers have access to diverse and complex information technology (IT) systems which include mainframe central processing facilities, local and wide area networks running various platforms, and telecommunications systems to include communication equipment. The various business and law enforcement functions within the DOJ depend on the confidentiality, integrity, and availability of these systems and their data.
DOJ relies on its IT systems, including the <enter system name here including any acronyms>, to accomplish its mission of providing cost effective services to DOJ organizations. Enter brief description of what the system/application does here and whether or not it processes sensitive information, in accordance with:
• OMB Circular A-130,
Appendix III, Security of Federal Automated Information
Resources;
• Public Law 100-235,
Computer Security Act of 1987;
• Public Law 93-579,
The Privacy Act of 1974; and
• NIST Special Publication
800-18, Guide for Developing Security Plans for Information Technology Systems.
This System Security Plan presents in place and planned controls for ensuring protection of <enter system name here or acronym>.
1.0 SYSTEM IDENTIFICATION
1.1 System Name/Title
Include in this section the system name and any acronyms for the system.
1.2 Responsible Organization
Include the organization name who is responsible for the security of the system. Include any information about other offices or organizations who have management or security control over the system (e.g., IT). Be sure to include the complete address of where the application owner resides and include the phone number.
1.3 Information Contacts
Include the:
Name
Titles
Complete address
Phone number
Roles of individuals responsible for the administration of the system. Briefly describe what their roles and responsibilities are for the system.
1.4 Assignment of Security Responsibility
Include the:
Name
Title
Complete address
Phone number
Role of the individual responsible for the security of the system. Provide a brief description of their security role
1.5 Category
<Enter name or acronym here> meets the criteria for a system.
1.6 System Operational Status
Enter whether the system is:
Operational
Under Development, or
Undergoing a Major Modification
If more than one status is applicable, include which part of the system is covered under each status.
1.7 General Description and Purpose
Enter a brief, 1 to 3 paragraph, description of the function and purpose of the system.
Note: Be sure to discuss:
The function or purpose of the system and the information that is
processed by the system;
List of user organizations and whether they are internal or external to
the system owner's organization; and
The processing flow of the system. Include where data is gathered
and input into the system and where the output goes after
processing. If the system provides data to another system or
system be sure to note that information in this section.
1.8 System Environment and Special Considerations
Enter a brief, 1 to 3 paragraph description of the system environment and any special considerations needed for the system.
Note: This section should contain the following information:
Describe the primary computing platform(s) used (e.g., mainframe, mini
computer, microcomputer(s), local area network (LAN), or wide area
network (WAN)).
Include a general description of the principle components, including
hardware, software, and communications resources.
Discuss the type of communications included (e.g., dedicated circuits, dial
circuits, public data/voice networks).
Include any security software protecting the system and information it
processes.
Include any environmental factors that raise special security concerns, such
as:
The system is connected to the Internet;
It is located in a harsh or overseas environment;
Any configuration management issues;
The software resides on an open network used by the general
public;
The application is processed at a facility outside of the
agency's control; or
The general support mainframe has dial-up lines.
1.9 System Interconnection/Information Sharing
Describe any system interconnection or direct connections to the system.
Note: This section should contain the following information:
List of the connected systems or major application systems
and their identifiers.
Description of interconnections with external systems not
covered by the System Security Plan and any security
concerns.
Description of any written authorizations (i.e., MOUs or
MOAs) that are in place and the rules of behavior that
have been established with the interconnected site.
1.10 Applicable Laws, Directives, and Regulations Affecting the System
The following Federal laws, directives, regulations, and DOJ policy provide guidance pertaining to the security of DOJ automated information systems, including <enter application name or acronym here>:
• Public Law 93-579,
The Privacy Act of 1974.
• Public Law 100-235,
Computer Security Act of 1987.
• Public Law 99-474,
Computer Fraud Act of 1986.
• OMB Circular A-123,
Management Accountability and Control, June 21, 1995.
• OMB Circular A-130,
Appendix III, Security of Federal Automated Information
Resources, February 6,
1996.
• NIST Special Publication
800-18, Guide for Developing Security Plans for Information
Technology Systems, August
14, 1998.
• DOJ Order 2640.2D,
Information Technology Security, July 12, 2001.
2.0 SENSITIVITY OF INFORMATION PROCESSED
2.1 Description of Data Processed
The <enter name or acronym here> processes and transmits unclassified sensitive data which requires protection for confidentiality, availability, and integrity. Sensitive data processed by the <enter name or acronym here> consists of <describe data or include data elements here>.
2.2 Information Sensitivity
<Enter name or acronym here> requires protection of the sensitive information contained within the system.
Note: Provide protection ratings for each of these three categories:
Confidentiality: The system contains information that requires
protection from unauthorized disclosure.
Integrity: The system contains information which must be
protected from unauthorized, unanticipated, or
unintentional modification, including the detection of
such activities.
Availability: The system contains information or provides
services which must be available on a timely basis to
meet mission requirements or to avoid substantial losses.The ratings for the application are:
High - a critical concern of the system;
Medium - an important concern but not necessarily paramount in the
organization's priorities; or
Low - some minimal level of security is required but not to the same
degree as the previous two categories.Enter check marks in the columns of Exhibit 2.3-1 that best describe the
system ratings.
Exhibit 2.3-1, Relative Importance of Protection Needs, presents the protection needs of <enter name or acronym here>.
Exhibit 2.3-1, Relative Importance of Protection Needs
| High (Critical Concern) |
Medium (Important Concern) |
Low (Minimal Concern) |
|
|---|---|---|---|
| Confidentiality | |||
| Integrity | |||
| Availability |
3.0 MANAGEMENT CONTROLS
3.1 Risk Assessment and Management
Threats to the confidentiality, integrity, or availability of <enter name or acronym here> were assessed during the development life cycle. Security controls were considered and included in its design. A risk assessment was performed by <enter organization name here> on <enter date of last risk assessment effort here>. Describe the risk assessment methodology used to identify the threats and vulnerabilities of the system.
Note: If no risk assessment has been done on the system, include a milestone date (month and year) for when the assessment will be completed.
3.2 Review of Security Controls
An independent management review or audit of the security controls was performed on <enter date of independent security review here> by <enter name of corporation or entity that performed the review> for <enter name or acronym here>. The independent security review will be conducted every three years in accordance with OMB A-130 requirements.
Note: An independent security review must be performed at least every three years. This review or audit should be independent of the manager responsible for the application. If your system is perceived as high risk, reviews may need to be conducted more frequently.
Include information about the last independent audit or review of the system, type of review, and who conducted the review. Discuss any findings or recommendations from the review and include information concerning correction of any deficiencies or completion of any recommendations.
3.3 Rules of Behavior
A set of rules of behavior has been established in writing for individual users of <enter system name or acronym here> concerning use of, security in, and the acceptable level of risk for the system.
Note: Requirements for the rules are as follows:
Delineate responsibilities and expected behavior of all individuals withIf the set of rules, for the system, is contained in a separate document, attach the document as an Appendix to the plan and reference the appendix number in this section.
access to the application. Responsibilities and expected
behavior should be based on the needs of the various users of
the application and be only as stringent as necessary to
provide adequate security for the information in the
application;
Reflect the technical controls in the application. For example, rules
regarding password use should be consistent with technical
password features;
Cover work at home, dial-in access, connection to the Internet, use of
copyrighted works, unofficial use of government equipment,
the assignment and limitation of system privileges, and
individual accountability;
State the consequences of behavior not consistent with the rules. For
instance, the rules may be enforced through administrative
sanctions specifically related to the system or through more
general sanctions as are imposed for violating other rules of
conduct;
Form the basis for security awareness and training;
Comply with system-specific policy as described in, An Introduction
to Computer Security: The NIST Handbook (March 16,
1995);
Define appropriate limits on interconnections to other systems;
Define service provision and restoration priorities;
Be in writing;
Be made available to every user prior to receiving authorization for
access to the system;
Include limitations on changing information, searching databases, or
divulging information; and
Specifically address restoration of service as a concern to all users of
the system.
3.4 Planning for Security in the Life Cycle
Determine which phase(s) of the life cycle that the system, or part of the system is in. Describe how security has been implemented during the life cycle.
Note: The life cycle phases, and what should be document is as follows: Initiation PhaseWas security requirements identified and documentedImplementation Phase:
during the system design?
Were security controls and evaluation and test procedures
developed before an RFP was issued?
Did the solicitation documents (RFPs) include security
requirements and evaluation/test procedures that
vendors must comply with when providing the
software/hardware?Were design reviews and system tests run prior to placing
the system into production?
Were the tests documented? Has the system been
certified?
Have additional security controls been added since the
system was developed?
Has the system undergone a technical evaluation to ensure
that it meets applicable DOJ regulations, Federal
laws, regulations, policies, guidelines, and
standards?
Include the date of the certification and accreditation. If
the system has not been authorized yet, include a
date when accreditation request will be made.Operation/Maintenance Phase:
Document the security activities during this phase in theDisposal Phase:
security plan.Describe how the data contained within the system isAuthorize Processing:
moved to another system, archived, discarded, or
destroyed. Controls used to ensure confidentiality
of the data during this phase.
Is the sensitive data encrypted?
How is the information cleared and purged from the
system.
Is information or media purged, overwritten, degaussed, or
destroyed in some manner?Provide the date of authorization, name, and title of
management official authorizing processing of the
system.
3.5 Security Control Measures
Security control measures implemented or planned to meet <enter name or acronym here> security requirements are addressed in the following control categories, in accordance with OMB A-130:
Operational Controls - Controls that include physical and environmental protection, emergency planning, audit and variance detection, maintenance of application software, documentation, and periodic checks for viruses.
Technical Controls - Controls to protect against unauthorized access or misuse and to facilitate detection of security violations.
For each requirement, a status is indicated as to whether the control measure(s) is:
In Place - controls that are operational and judged to be effective.
Planned - controls are specific control measures (e.g., new, enhanced) that will be implemented for the system.
Note: For each security control, check off the appropriate box that pertains to that security control and whether it is in place, planned, in place and planned, or not applicable. Each section has an example of what the security control response should look like. In some instances we responded with a positive response (i.e., security control mechanism is in place). In some instances we showed what the response would look like if the activity was on going (i.e., security control mechanism is planned). These examples are shown to assist the preparer in completing the remainder of the application security plan.
4.0 OPERATIONAL CONTROLS
These are the day-to-day procedures and mechanisms used to protect production applications.
4.1 Personnel Security
Appropriate reference and/or background checks should be conducted for DOJ employees and contractors who have the capability to circumvent controls or who have access to sensitive data.
In Place Controls: All DOJ employees and contractors are subject to background investigations prior to employment. Individuals occupying positions with a higher level of sensitivity designation are subject to more in-depth background investigations.
4.2 Physical and Environment Protection
The physical and environmental protection of the equipment and peripherals supporting <enter system name or acronym here> operations, including all physical protection devices such as fire extinguishers, locks, or video cameras, must be ensured.
In Place Controls: Describe all physical and environmental protection mechanisms in place.
Note:Discuss the physical protection in the area where application processing takes place (e.g., locks on terminals, physical barriers around the building and processing area). Some examples of physical/environmental controls include:
Card keys;
Cipher locks;
Humidifiers;
Fire extinguishers;
Surge suppressors;
Uninterruptable power supply;
Controlled access by security guards; and,
Intrusion, smoke, water, and heat detectors
4.3 Production Input and Output Controls
Formal procedures for handling of input data by properly screened persons and for maintaining an audit trail should be prepared. Printouts and storage media should be identified as to content and sensitivity and sensitive/critical data media should be securely stored. Data media and storage containing sensitive data should be overwritten before it is released outside the original owner's control.
In Place Controls: All users handling input data are properly screened. The audit trail capability provided by the computer and network operations system for <enter name or acronym here> have been implemented to ensure individual accountability.
Planned Controls: Development of procedures for identifying printouts and storage media as to the contents and their sensitivity as well as a policy regarding audit data retention is planned.
Note: Describe the security controls used for marking, handling, processing, storage, and disposal of input and output information. Also describe the labeling and distribution procedures for information media. The following topics should be discussed in this section: User support/help desk capabilities;Procedures to ensure authorized users only have access to data they need and unauthorized users are denied access;Procedures for ensuring that only authorized users pick-up, receive, or
deliver input and output information and media to the major
application system;
Audit trails for receipt of sensitive data for both input and output data.External and internal labeling for sensitivity (i.e., Privacy Act,
or proprietary labeling are examples);
Media storage and environmental protection and controls of
the off-site storage site, if applicable.
Procedures for sanitization of electronic media;
Shredding or other destructive measures for hardcopy media
when no longer needed or which needs protection
because of the sensitivity of the data contained in the
printed material; and
Destruction of softcopy media that is no longer in use or is not
usable.
4.4 Contingency Planning
Contingency plan and disaster recovery procedures should be developed to provide reasonable assurance that critical data processing support can be continued or resumed quickly if normal system operations are interrupted.
Planned Controls: The Contingency Plan is in the process of being completed. The completed Contingency Plan will contain all the following elements:
Any agreements for backup processing;
Documented backup procedures including frequency and scope;
Coverage of backup procedures;
Location of stored backups;
Generations of backups kept;
Contingency plan testing (is testing done and how often); and
Personnel trained on implementation of the plan.
Note: Ensure that the contingency plan contains the information listed above. If not, show a date as to when the changes will be made to the existing contingency plan.
The sample shown for this section shows a planned activity.
4.5 Application Software and Maintenance Controls
Controls are needed to monitor the installation of, and updates to, application software to ensure that the software functions as expected and that a historical record is maintained of application changes.
In Place Controls: Application software and maintenance controls exist for <enter name or acronym here>.
Note: Describe the software configuration policy and products and procedures used in auditing for, or preventing, illegal use of shareware or copyrighted software. Address the following:
Was the application software developed in house or under contract?
Does the Government own the software?
Was the application software received from another Federal agency with the understanding that it is Federal Government property?
Is the application software a copyrighted commercial off-the-shelf product or shareware?
Describe the change control process.
Are all changes to the application software documented?
Are test data "live" or made-up data?
Are test results documented?
How are emergency fixes handled?
Is there an organizational policy in place against illegal use of copyrighted software or shareware?
Are software warranties managed to minimize the cost of upgrades and cost reimbursement or replacement for deficiencies?
4.6 Documentation
Descriptions of the hardware/software policies and procedures related to the security of the application, descriptions of software, hardware, and configuration or cable charts should be available for those who need them.
In Place Controls: Documentation on <enter name or acronym here> application usage and related processing policies and procedures have been developed and are updated periodically.
Planned Controls: Development of documentation on managing and administering the security of <enter name or acronym here> are planned.
Note: The major application system documentation should include the following:
Vendor supplied documentation;
Application requirements;
Application security plan;
General support system security plan;
Application program documentation and specifications;
Testing procedures and results; Standard operating procedures;
Emergency procedures;
Memoranda of Understanding (MOU) with interfacing systems;
User rules/procedures;
User manuals;
Risk Assessment;
Backup procedures;
Certification documents and statements;
Accreditation statements; and
Contingency plans.
4.7 Security Awareness and Training
A security awareness and training program has been established to ensure that employees, contractors, and volunteer personnel are aware of their security responsibility and how to fulfill them. The program should include new employee security briefings, annual refresher training, and training for information technology and security personnel.
In Place Controls: A security awareness and training program has been implemented to ensure that all employees, contractors, and volunteer personnel are aware of their security responsibilities and how to fulfill them. The end-user awareness training is conducted on an on-going basis. Information technology and security personnel attend conferences and specialized training to obtain additional security training.
Note: This section should include the following:
Type of awareness program in place for the system (i.e., posters, booklets,
formal training, etc.)
Type and frequency of the system-specific training to employees and
contractor personnel. This can include seminars, workshops, formal
classroom, focus groups, role-based training, on-the-job training, and
one-on-one training.
Procedures to ensure that employees and contractors have been provided
adequate training on the system.
5.0 TECHNICAL CONTROLS
Controls within the application that enable access control and audit of user activities, and controls provided by the general support system which augment application security.
5.1 User Identification and Authentication
Controls must be in place to verify the identity of a station, originator, or individual before allowing access to the application.
In Place Controls: <Enter name or acronym here> security controls have been configured to require all users to enter a valid ID/password combination for user identification and authentication prior to allowing access. Describe all the identification and authentication mechanisms in place for the system.
Note: In this section describe the system's access controls. Include the
following information:
Describe the method of user authentication (i.e., password, token, or
biometric).
If a password system is used, provide the following specific information:Indicate the frequency of password changes, describe how passwordAllowable character set;
Password length (i.e., minimum and maximum);
Password aging time frames and enforcement approach;
Number of generations of expired passwords disallowed for
use;
Procedures for password changes;
Procedures for handling lost passwords; and,
Procedures for handling password compromise.
changes are enforced, and identify who changes the passwords.
State the number of invalid access attempts that may occur for a given user
identifier or access location and describe the actions taken when that
limit is exceeded.
Describe any policies that provide for bypassing user authentication
requirements, single sign-on technologies and any compensating
controls.
5.2 Logical Access Control
Standards and procedures relating to user ID, password, and access privileges should be developed to maintain and enforce security.
In Place Controls: DOJ has established accounts management procedures applicable to all systems and applications, including <enter name or acronymn here>.
5.3 Public Access Controls
Additional security controls are needed to protect the integrity of the system if the public is allowed access.
In Place Controls: <Enter name or acronym here> does not allow access by the general public.
Note: If this is a public access system, list and discuss the controls that provide protection to the system. Examples of public access controls may include:
Some form of identification and authentication;
Access control to limit what the user can read, write, modify, or delete;
Controls to prevent public users from modifying information on the system;
Prohibit public access to "live" databases;
Verify that programs and information distributed to the public are virus-free;
and,
Audit trails.
5.4 Audit Trail
An automated mechanism should be operational that will create, maintain, and protect an audit trail of the client and administrators actions so that all security relevant events can be traced to a specific client for accountability. The audit trail mechanism should record failed logon attempts.
In Place Controls: <Enter name or acronym here> has an automated audit trail mechanism that records security relevant events. The audit data includes failed and successful user logons, failed and successful access and operations on data (by session), changes to a user's security privileges, changes to the security configuration, and creation and deletion of objects.
Note: In this section describe the measures used to protect system usage and
audit trail logs. Discuss the following:System usage and audit trail logs produced by the general support system on
which the system resides.
Linkages between logs maintained by the system and the supported
application system.
How the actions of individual users of the system may be monitored through
the system logs.
Procedures used for reviewing logs and audit trail reports, and how long
such logs are stored.
5.5 Complementary Controls Provided by Support Systems
Insert any complementary controls that are in place for the network or general support system or where the system is operated outside of your management control.
In Place Controls: <Enter system name or acronym here> is protected from potential abuse or misuse from outside entities by the firewall that is in place on the DOJ WAN connection to the Internet.
Note: In this section discuss the following:
List any controls in place on the general support system that add protection
for the application.
If the application is processed on another system(s), include the name of the
organization, system name, and if one exists, its unique system
identification.
Indicate how the application owner has acknowledged understanding of the
risk to application information that is inherent in processing on the
general support system or in transmitting information over networks.
SYSTEM SECURITY PLAN OUTLINE
1.0 SYSTEM IDENTIFICATION
1.1 System
Name/ Title
1.2 Responsible
Organization
1.3 Information
Contacts
1.4 Assignment
of Security Responsibility
1.5 Category
1.6 System
Operational Status
1.7 General
Description and Purpose
1.8 System
Environment and Special Considerations
1.9 System
Interconnection/Information Sharing
1.10 Applicable
Laws, Directives, and Regulations Affecting the System
2.0 SENSITIVITY OF INFORMATION
PROCESSED
2.1 Description
of Data Processed
2.2 Information
Sensitivity
3.0 MANAGEMENT CONTROLS
3.1 Risk
Assessment and Management
3.2 Review
of Security Controls
3.3 Rules
of Behavior
3.4 Planning
for Security in the Life Cycle
3.5 Security
Control Measures
4.0 OPERATIONAL CONTROLS
4.1 Personnel
Security
4.2 Physical
and Environment Protection
4.3 Production
Input and Output Controls
4.4 Contingency
Planning
4.5 Application
Software and Maintenance Controls
4.6 Documentation
4.7 Security
Awareness and Training
5.0 TECHNICAL CONTROLS
5.1 User
Identification and Authentication
5.2 Logical
Access Control
5.3 Public
Access Controls
5.4 Audit
Trail
5.5 Complementary
Controls Provided by Support Systems