epartment of Commerce's Chapter 10 of the DOC IT Management Handbook, which contains the IT Security policies for the Dept., November 1993
09a6957c1aaabe270c123fc01d768613a5cd5aa9582da2af6f3d72655e493c10
Chapter 10. Information Technology
Security
INTRODUCTION
The "Computer Security Act of 1987," Public Law 100-235 and
Office of Management and Budget (OMB) Circular A-130 require
all federal agencies to plan for the security of all
sensitive IT systems throughout their life cycle. OMB
Circular A-130 also establishes a minimum set of controls to
be included in federal Information Technology (IT) security
programs. The program must include the implementation of
policies, standards, and procedures which are consistent
with government-wide laws and regulations, to assure an
adequate level of protection for IT systems whether
maintained in-house or commercially. The circular directs
agencies to assure:
1. that IT systems operate effectively and
accurately;
2. that there are appropriate technical, personnel,
administrative, physical, environmental, and
telecommunications safeguards in IT systems; and
3. that the continuity of the operations of IT
systems that support critical agency functions is
preserved.
The Department of Commerce (DOC) has established and
implemented an IT security program which will provide
reasonable and acceptable assurance that sensitive and
classified national security IT systems are performing
exactly as specified and doing nothing more; that sensitive
and classified information is provided adequate protection;
that data and software integrity is maintained; and, that
unplanned disruptions of processing will not seriously
impact mission accomplishment.
People, hardware, software, telecommunications, facilities
and data together form an IT system that is highly effective
and productive. However, all IT systems involve certain
risks that must be addressed adequately through proper
controls. The policies contained in this chapter represent
management's commitment to assuring confidentiality,
integrity, availability and control of the Department's IT
resources.
Due to the complexity of the IT Security program
requirements, the policy section of this chapter is divided
into subsections that present policies by specific subjects,
as appropriate.
The "DOC IT Security Manual," Attachment 1 to this chapter,
is being published as a separate document, which combines
all policies, procedures, current detailed guidance and
methodologies for accomplishing the Department's IT security
program. It is intended to provide individuals assigned IT
security responsibilities and individual system owners with
a more detailed single-source reference document, which will
be up-dated as new policies, procedures, techniques,
methodologies or program requirements are developed and
issued.
A. Purpose
The DOC IT Security program complies fully with all federal
laws, regulations and directives and communicates uniform
policies for the protection and control of IT resources
directly or indirectly relating to the activities of the
Department.
The purpose of this chapter is to define all policies and
responsibilities for the establishment, implementation,
maintenance and oversight of the IT security program within
the Department, for the protection and control of vital DOC
IT resources. Basic elements of the Department's IT
security program requirements will be identified in relation
to assigned responsibilities.
B. Overview
Security of IT systems, as described in OMB Circular A-130,
requires the protection of automated systems and information
while associated with any automated processing activity, and
the assurance that the systems do exactly what they are
supposed to do and nothing more. IT security requires
management controls to ensure authorized access to the
information in the systems and proper handling of input,
processing, and output.
The implementation of an effective IT security program
within the Department begins with the establishment of the
organizational IT security structure and the assignment of
broad responsibilities.
Individuals appointed to positions with IT security
responsibilities are accountable for compliance with all DOC
or federal laws, regulations and policies related to the
assigned responsibilities.
C. Background and Authority
The DOC IT Security Program is established in compliance
with the "Computer Security Act of 1987," Public Law 100-
235, OMB Circular A-130, Appendix III, "Security of Federal
Automated Information Systems," National Security Directive
(NSD) 42, "National Policy for the Security of National
Security Telecommunications and Information Systems" and
Departmental Organizational Order DOO 20-14.
D. Scope
The policies contained in this document are applicable to
all DOC IT resources at all levels of sensitivity, whether
maintained in-house or commercially. These policies are
mandatory on all organizational units, employees,
contractors, and others having access to and/or using the IT
resources of the Department.
These policies apply to all automated technology currently
in existence and to any new automated technology acquired
after the effective date of this policy document.
The IT security program focuses on assuring confidentiality,
integrity and availability of all IT resources necessary for
processing or transmitting the information. The IT security
program consists of a number of different elements,
including some that might normally come under other security
programs. Those elements that are required by the "Computer
Security Act of 1987" or OMB Circular A-130 are considered
part of the IT security program and are included in this
document.
E. Policy
10.1 Program Requirements
All DOC organizations will establish, implement and maintain
an IT security program consistent with the Department and
government-wide laws, regulations, policies, procedures and
standards. The program must include as a minimum, adequate
and appropriate levels of protection for all IT resources
within the organization, including hardware, software,
physical and environmental facilities that support IT
systems, telecommunications, administrative, personnel and
data.
All IT systems will be identified and appropriate controls
implemented in the following categories:
1. Management controls;
2. Acquisition/development/installation/implementation
controls;
3. Operational controls;
4. IT security awareness and training; and
5. Technical controls.
Responsibilities for the DOC IT security program starts at
the Department level and flows down through management of
all organizations to the individual users.
1. The DOC Office for Information Resources Management is
responsible for security of DOC IT resources. Non-IT
security programs (e.g., theft of computer resources,
physical security, personnel security, safeguarding
classified material and Inspector General requirements)
are stated in section G. below.
2. The head of each operating unit is responsible for
adequate protection of the operating unit IT resources.
Staff responsibility for IT security shall be monitored
by the operating unit Senior Official for Information
Resources Management.
3. System owners are responsible for providing adequate
and appropriate levels of protection for the IT
resources under their control to prevent unauthorized
disclosure, effective and accurate processing and
continuity of operations for accomplishment of the
organization's mission.
4. Each employee of the Department is responsible for the
adequate protection of IT resources within their
control or possession.
IT security program responsibilities are assigned to the
Department and all operating units in line with the
requirements outlined in section F. below.
10.2 Information Technology System Identification and Planning
The sensitivity level of all IT systems will be determined
based on the sensitivity of the data processed or the
importance of the system to mission accomplishment. All
systems must include security controls that reflect the true
importance of the information processed on the system and/or
the government investment embodied in the components of the
IT system. The sensitivity level of all DOC IT systems will
be identified in one of the following categories:
1. Classified National Security Systems contain
information which requires protection against
unauthorized disclosure in the interest of national
security at either the Top Secret, Secret or
Confidential level. Procedural protection requirements
for classified systems are contained in DAO 207-2, "DOC
National Security Information Manual." Technical
protection requirements are contained in Section 10.18
of the "DOC IT Management Handbook" and Section 18 of
the "DOC IT Security Manual."
2. Unclassified Sensitive Systems include those that
require some degree of protection for confidentiality,
integrity or availability. This includes systems and
data whose improper use or disclosure could adversely
affect the ability of an agency to accomplish its
mission, proprietary data, records about individuals
requiring protection under the Privacy Act, and data
not releasable under the Freedom of Information Act.
If the system is required for accomplishment of an
agency mission it need not contain any sensitive data.
3. Non-Sensitive Systems are considered "trivial" as they
contain only public data, which has no protection
required for confidentiality or integrity, and the
mission of the agency can be accomplished without the
system.
A security plan will be prepared in the format of the "DOC
Guidelines for Developing and Evaluating Security Plans for
Sensitive and Classified Systems," contained in Section 2 of
the "DOC IT Security Manual," and submitted to the
Department for all DOC application and general support
systems that have been identified as sensitive or classified
national security systems. All IT systems will be
identified as either application systems or general support
systems.
1. Application Systems - Systems that perform clearly
defined functions for which there are readily
identifiable security considerations and needs. Such a
system might actually comprise many individual
application programs and hardware, software, and
telecommunications components. They can be either a
major software application or a combination of
hardware/software where the only purpose of the system
is to support a specific mission related function. The
system may process multiple individual applications, if
all are related to a single mission function.
2. General Support Systems - These consist of hardware and
software that provide general automated data processing
or network support for a variety of users and
applications. Individual applications may be less
easily distinguishable than in the previous category.
Single user systems, such as one or more personal
computers may fit into this category if they process
data related to more than one function.
10.3 Certification
Certification is a requirement for all sensitive and
classified DOC general support and application systems. New
IT systems or those not fully operational shall complete all
certification requirements and be accredited prior to full
implementation.
Initial Certification
Prior to accreditation, each IT system is to undergo
appropriate technical certification evaluations to ensure
that it meets all federal and DOC policies, regulations and
standards and that all installed security safeguards appear
to be adequate and appropriate for the protection
requirements of the system. Certification of the system is
based on the documented results of the design reviews,
system tests, and the recommendations of the testing teams.
All systems must include security controls that reflect the
true importance of the information processed on the system
and/or the government investment embodied in the components
of the IT system. Section 3 of the "DOC IT Security
Manual," identifies the required actions in the
certification process.
Recertification
Systems will be recertified when substantial changes are
made to the system, when changes in requirements result in
the need to process data of a higher sensitivity, after the
occurrence of a serious security violation which raises
questions about the validity of an earlier certification,
and in any case no less frequent than three years after the
previous certification. Examples of major changes are
contained in Sections 3 and 4 of the "DOC IT Security
Manual."
10.4 Accreditation
Accreditation is required for all sensitive and classified
DOC general support and application systems. New IT systems
or those not fully operational shall complete all
requirements and be accredited prior to full implementation.
Initial Accreditation
All sensitive and classified DOC IT general support or
application systems will be accredited. The term
accreditation describes the process whereby information
pertaining to the security of a system is developed,
analyzed and submitted for approval to the appropriate
senior management official identified in this document as
the Designated Approving Authority (DAA). Section 4 of the
"DOC IT Security Manual," identifies the required steps in
the accreditation process. The DAA will review the
accreditation support documentation and either concur,
thereby declaring that a satisfactory level of operational
security is present or not concur, indicating that the level
of risk either has not been adequately defined or reduced to
an acceptable level for operational requirements. The DAA
will sign a formal accreditation statement declaring that
the system appears to be operating at an acceptable level of
risk, or defining any conditions or constraints that are
required for appropriate system protection. Sample
accreditation statements are contained in Section 4 of the
"DOC IT Security Manual."
Security of classified IT systems operated by, or in support
of DOC programs is the responsibility of the Department and
these systems must be accredited in accordance with the
requirements defined in this policy. Approvals granted by
external agencies, i.e., Department of State, Department of
Defense, Central Intelligence Agency, etc., are not valid
authority to operate classified IT systems within the
Department. Approvals granted to these systems by DOC,
prior to this policy, are no longer in effect and new
approval to operate must be granted through the DOC
accreditation process.
Interim Accreditation
Interim authority to operate can be granted for a fixed
period of time, not to exceed one year. This authority is
based on an approved security plan and is contingent on
certain conditions being met. The interim authority to
operate, while continuing the accreditation process, permits
the IT system to meet its operational mission requirements
while improving its IT security posture. If the DAA is not
satisfied that the IT system is protected at an acceptable
level of risk, an interim accreditation can be granted to
allow time for implementation of additional controls.
Recommendation or request for an interim accreditation may
be made by the IT system owner, the operating unit IT
Security Officer (ITSO) or the DAA. Interim authority to
operate is not a waiver of the requirement for
accreditation. The IT system must meet all requirements and
be fully accredited by the interim accreditation expiration
date. No extensions of interim accreditation can be granted
except by the DOC Director for Information Resources
Management.
Reaccreditation
Systems will be reaccredited when major changes occur to the
system or every three years, whichever occurs first.
Examples of major changes are contained in Section 4 of the
"DOC IT Security Manual."
Prior to reaccreditation, an on-site IT security
verification review must be conducted by an evaluation team
under the direction of the DOC IT Security Manager, the
operating unit ITSO or the ITSO of a subordinate
organizational unit (i.e., Line Office, Regional Office,
Laboratory, etc.). Procedures for conducting IT security
verification reviews are contained in Section 5 of the "DOC
IT Security Manual."
10.5 Verification Reviews
An IT Security verification review will be conducted on all
DOC sensitive or classified national security IT systems by
an evaluation team under the direction of the DOC IT
Security Manager or the operating unit ITSO every three
years. The purpose of the IT security verification review
is to provide a level of review and evaluation independent
of the system owner, that will verify that adequate and
appropriate levels of protection are being provided for the
individual systems, based on their unique protection
requirements. At the operating unit level, responsibility
for conducting IT security verification reviews may be
delegated to subordinate organizations as long as those
subordinate organizations do not come under the direct
control of the system owner. Detailed guidelines for
conducting IT security verification reviews are contained in
Section 5 of the "DOC IT Security Manual."
10.6 Incidents and Violations
All DOC organizations will establish and implement a process
and procedures to minimize the risk associated with
violations of IT security, to ensure timely detection and
reporting of actual or suspected incidents or violations.
An IT security incident is any event, suspected event, or
vulnerability that could pose a threat to the integrity,
availability, or confidentiality of DOC's systems,
applications or data. Incidents may result in the
possession of unauthorized knowledge, the wrongful
disclosure of information, the unauthorized alteration or
destruction of data or systems and violation of federal or
state laws.
If such violations are detected or suspected, they are to be
reported immediately to the DOC IT Security Manager through
the operating unit ITSO. Section 6 of the "DOC IT Security
Manual contains specific information concerning the
reporting requirements for IT security violations.
10.6.1 Malicious Software
All DOC organizations will establish and implement a process
and procedures to minimize the risk of introducing viruses
and other malicious software, to ensure timely detection of
viral infections, to provide procedures for eliminating
viral infections from the Department's inventory of
microcomputers (PCs), and to provide procedures to minimize
the risk from malicious programs to larger systems, or
systems where virus detection software is not yet available.
If such violations are detected or suspected, they are to be
reported immediately to the DOC IT Security Manager through
the operating unit ITSO. Information concerning the
malicious software protection procedures and reporting
requirements are contained in Section 6.1 of the "DOC IT
Security Manual."
10.7 Risk Management
All DOC organizations will establish and implement a risk
management process for all IT resources, to ensure that the
balance of risks, vulnerabilities, threats and
countermeasures achieves a residual level of risk that is
acceptable based on the sensitivity or criticality of the
individual systems.
System owners shall conduct a periodic risk analysis of each
IT system to insure that appropriate, cost effective
safeguards are incorporated into existing and new systems.
The objective of the risk analysis is to provide a measure
of the relative vulnerabilities and threats to an
installation so that security resources can be effectively
distributed to minimize the potential for future losses.
The risk analysis may vary from an informal, but documented,
review of a microcomputer or terminal installation to a
formal, fully quantified risk analysis for a large mainframe
computer system. A risk analysis will be performed:
1. Prior to the approval of design specifications for new
systems;
2. Whenever a significant change occurs to the system
(examples of major changes are contained in Sections 3
and 4 of the "DOC IT Security Manual";) or
3. At least every three years.
Section 7 of the "DOC IT Security Manual" contains specific
information and guidance concerning the risk management and
risk analysis requirements.
10.8 Contingency and Disaster Recovery Planning
Management officials who are dependent upon IT systems for
the support of essential functions are responsible for the
development and maintenance of contingency plans for these
functions. The contingency planning process will address
the following activities:
1. Backup and retention of data and software;
2. Selection of a backup or alternate operations strategy;
3. Emergency response actions to be taken to protect life
and property and minimize the impact of the emergency;
4. Actions to be accomplished to initiate and effect
backup or alternate site; and
5. Resumption of normal operations in the most efficient
and cost-effective manner.
Each DOC IT system shall develop and maintain in a current
state, a contingency plan for disaster recovery which will
provide reasonable assurance that critical data processing
support can be continued, or resumed quickly, if normal
operations of the system are interrupted. These plans will
include adequate coverage of:
1. Emergency response procedures appropriate to fire,
flood, civil disorder, natural disaster, bomb threat or
any other incident or activity which may endanger
lives, property or the capability to perform essential
functions. These emergency procedures will be
prominently displayed in the areas to which they apply;
2. Arrangements, procedures and responsibilities will be
defined and documented to ensure that essential
(critical) operations can be continued if normal
processing or data communications are interrupted for
any reason for an unacceptable period of time;
3. Recovery procedures and responsibilities to facilitate
the rapid restoration of normal operations at the
primary site, or if necessary, at a new facility,
following the destruction, major damage or other
interruptions at the primary site; and
4. The minimally acceptable level of degraded operation of
the essential (critical) systems or functions will be
identified and prioritized to guide implementation at
the backup operational site. The contingency plan must
accommodate these priorities.
The plan for large systems supporting essential Departmental
or agency functions shall be fully documented. Small
systems, such as those located in office environments, may
develop a more abbreviated and less formal plan. All plans
must be operationally tested at a frequency commensurate
with the risk and magnitude of loss or harm that could
result from disruption of information processing support,
but not to exceed one year.
Section 8 of the "DOC IT Security Manual" contains specific
information and guidance concerning contingency and disaster
recovery planning.
10.9 Personnel Security
All DOC operating units shall comply with personnel security
policies and procedures established by the "DOC Personnel
Security Manual," DAO 207-2 and Section 9 of the "DOC IT
Security Manual." These policies pertain to both federal
and contractor personnel. At a minimum:
1. All IT related positions will be evaluated and assigned
a sensitivity level and appropriate background
investigations will be completed for individuals
filling these positions;
2. Procedures will be established to ensure the screening
of all individuals before they are allowed to
participate in the design, operation or maintenance of
sensitive IT systems, or are granted access to
sensitive data. The level of screening required should
vary from minimal checks to full background
investigations, depending upon the sensitivity of the
information to be handled and/or the risk and magnitude
of loss or harm that could be caused by the individual;
3. Establish a process to grant access privileges based on
a legitimate need to have system access. Individuals
will be granted only the least possible privileges
necessary for job performance. Privileges which have
not been specifically granted will be specifically
denied;
4. Where feasible, sensitive positions will be separated
to preclude any one individual from gaining the
opportunity to adversely affect the system. Procedural
checks and balances must be defined and enforced so
that accountability is established and security
violations are detectable.
5. Establish a process for individual accountability for
the proper use and security of the IT system(s) being
accessed and ensure that all users are provided with
periodic security awareness briefings, copies of system
rules and are trained to fulfil their IT security
responsibilities;
6. Establish a process to revoke access privileges in a
timely manner when the requirement for access ceases
(e.g., transfer, resignation, retirement, change of job
description, etc.); and
7. Establish a process to immediately revoke access
privileges to individuals being separated for adverse
reasons on or just prior to notifying them of the
pending action.
10.10 Hardware Security
DOC operating units shall assure that appropriate technical
security requirements are included in specifications for the
acquisition or operation of new IT equipment intended to
process sensitive information. These specifications shall
be reviewed and approved by the appropriate ITSO or IT
System Security Officer (ITSSO) prior to the acquisition.
It may not be feasible or cost effective to retrofit
existing, older computer hardware. However, the features
below should be considered when acquiring new systems, to
ensure that they are incorporated either within the hardware
or operating system software:
1. User Isolation
a. Users will be allowed to access only the memory
locations, files, and peripheral devices which
have been allocated to the user by the operating
system.
b. Computers, other than stand-alone PCs, should have
the capability to effectively isolate users from
each other and from the operating system.
c. Physical isolation of the hardware is described in
Section 10.11 of this document and Section 11 of
the "DOC IT Security Manual."
2. System Execution
a. Any attempt to execute an illegal instruction
should result in a hardware interrupt permitting
the operating system to interrupt and abort the
program containing the instruction.
b. Error detection and memory boundary checking
should be performed on transfers of data between
memory, peripherals, and external devices.
c. Automatic programmed interrupts must control
system malfunctions and operator errors.
For systems that process very sensitive or national security
information the use of equipment that meets the requirements
of either the "Department of Defense (DOD) Trusted Computer
System Evaluation Criteria," DOD 5200.28-STD ("Orange Book")
or the "Federal Criteria for IT Security," developed jointly
by the National Institute of Standards and Technology and
the National Security Agency is encouraged.
Government owned equipment is for official use only and is
not to be used for personal business or other non-government
activities.
Individual employees should be discouraged from bringing
their personally owned hardware into DOC space for
processing government data. If it is in the best interest
of the DOC organization to allow the use of personally owned
hardware on DOC premises, authorization must be granted in
writing by the immediate supervisor, showing the
justification. The written authorization must show that the
DOC is not responsible for any damage or loss of personally
owned equipment and will not pay for maintenance or repair.
See Section 10.12.1 of this document and Section 12.1 of the
"DOC IT Security Manual" for additional policies and
guidance on copyrighted software.
10.11 IT Facility
Access to IT resources will be based upon demonstrated need
and level of security clearance, if appropriate.
Individuals shall be granted only the access authority
and/or system privileges necessary to accomplish their
assigned duties.
10.11.1 Physical Security
Adequate physical security measures must be provided for the
protection of human resources, physical and logical assets
and sensitive applications and data. Physical security
measures must be selected and implemented in consideration
of the sensitivity of the IT resources and their criticality
to the supported functions. The physical security policies
stated herein are intended to be complementary to the "DOC
Physical Security Manual," DAO 207-1 and apply to the
protection of IT resources.
For the purposes of these policies, controlled areas are
those which encompass or allow access to potentially
sensitive information resources, resources which are
essential for the processing of sensitive data, or resources
essential to accomplishment of organizational missions.
These areas include, but are not limited to: any spaces
housing computer equipment, including terminals, PCs and
file servers; data storage libraries; input/output areas;
data conversion areas; programmer areas and files;
documentation libraries; communication equipment areas;
computer maintenance areas; mechanical equipment areas;
telephone closets; environmental controls and power systems;
and supply storage areas. The physical security
requirements of controlled areas will be determined by the
results of a risk analysis and/or a DOC Office of Security
physical security survey.
When automation or data communications equipment are located
within user areas, the user management officials will assess
the sensitivity of the data, automated resources and
functions performed and, if warranted, designate the area as
a controlled area.
The operational areas of major computer installations,
including local area network file servers, will be
designated restricted areas in which access will not be
permitted unless specifically authorized or required for job
performance.
Controlled and restricted areas will be protected by
physical security and other means which are deemed
appropriate for the sensitivity or criticality of the system
as determined by the results of a risk analysis and as
defined in the Sensitive System Security Plan for the
system. At a minimum, access to controlled areas will be
limited to those individuals having an official need to be
in the area.
IT devices which are easily moved, have non-removable hard
drives and are used for sensitive information will not be
allowed outside of the controlled area. If the sensitive
data remaining on the media has been completely erased or
obliterated, the removal of these devices from the work area
may be approved by the ITSO or ITSSO.
Contract maintenance personnel, and others not authorized
unrestricted access but who are required to be in the
controlled area, will be escorted by an authorized person at
all times that they are within the controlled area.
Media used to record and store sensitive software or data
will be externally identified, protected, controlled and
secured when not in actual use.
10.11.2 Environmental Safeguards
Adequate environmental safeguards must be installed and
implemented to protect IT system resources as deemed
appropriate for the sensitivity or criticality of the system
as determined by the results of a risk analysis and as
defined in the Sensitive System Security Plan for the
system. At a minimum, the following environmental
safeguards must be considered:
1. Fire prevention, detection, suppression and protection
2. Water hazard prevention, detection and correction
3. Electric power supply protection
4. Temperature control
5. Humidity control
6. Natural disaster protection from earthquake, lightning,
windstorm, etc.
7. Magnetism protection
8. Good housekeeping procedures for protection against
dust and dirt
10.12 Software Security
Prior to placing a sensitive application into operation, DOC
operating units will verify that the required user functions
are being performed completely and correctly, and that the
specified administrative, technical and physical safeguards
are operationally adequate and fully satisfy the applicable
federal policies, regulations and standards relating to the
protection of the information.
Application Software - An application which processes
sensitive data, or requires protection because of the risk
and magnitude of loss or harm that could result from
improper operation, manipulation or disclosure must be
provided protection appropriate to its sensitivity. The
following will be considered as the minimum controls to be
applied to sensitive applications, with additional controls
or safeguards to be imposed if appropriate:
1. Security requirements will be defined, and security
specifications approved by the user prior to acquiring
or starting development of applications, or prior to
making a substantial change in existing applications;
2. Design reviews will be conducted at periodic intervals
during the developmental process to assure that the
proposed design will satisfy the functional and
security requirements specified by the user;
3. New or substantially modified sensitive applications
shall be thoroughly tested prior to implementation to
verify that the user functions and the required
administrative, technical and physical safeguards are
present and are operationally adequate. This is
normally accomplished as part of the certification
process described in Section 10.3 of this document and
Section 3 of the "DOC IT Security Manual";
4. Live sensitive data or files will not be used to test
applications software until software integrity has been
reasonably assured by testing with non-sensitive data
or files;
5. Sensitive application software will not be placed in a
production status until the system tests have been
successfully completed and the application has been
properly certified and accredited. Accreditation
requirements are described in Section 10.4 of this
document and Section 4 of the "DOC IT Security Manual";
6. Current copies of critical application software,
documentation, data bases and other resources required
for its operation, will be maintained at a secure off-
site location to be readily available for use following
an emergency;
7. Sensitive applications will be re-tested and
recertified every three years or following major
changes; and
8. Sensitive software documentation should be provided the
same degree of protection as that provided for the
software.
Operating System Software - The operating system software
employed to process data by multiple users, including local
area networks, should control user access to resources and
capabilities which are required and have been authorized.
It should also have the capability to identify, journal,
report and assign accountability for the functions performed
or attempted by a user, and to deny user access to
capabilities or resources which have not been authorized.
Since the operating system has the capability to perform
certain functions which are forbidden to users, it should
allow the user to have access to the authorized resources
only, and nothing more. As a minimum, the operating system:
1. Should control all transfers between memory and on-line
storage devices, between a central computer and remote
devices and between on-line storage devices;
2. Should control all operations associated with
allocating IT system resources (e.g. memory, peripheral
devices, etc.), memory protection, system interrupts
and changes between the privileged and non-privileged
states;
3. Should control programs or utilities which may be used
to maintain and/or modify the operating system, access
control systems, sensitive databases and other software
modules which could effect or compromise the integrity
of the general purpose software or sensitive
applications;
4. Should prevent a user program from executing privileged
instructions;
5. Should isolate the programs and data areas of one user
from those of other users and the operating system
software;
6. Should assure error detection, when accessing memory,
memory bounds, parity, and hardware register checking;
7. Should cause the following screen warning message to be
displayed before the log on message, if the system is
capable of being accessed by communication connection:
**WARNING**WARNING**WARNING**WARNING**WARNING**
YOU HAVE ACCESSED A UNITED STATES GOVERNMENT COMPUTER.
USE OF THIS COMPUTER WITHOUT AUTHORIZATION OR FOR
PURPOSES FOR WHICH AUTHORIZATION HAS NOT BEEN EXTENDED
IS A VIOLATION OF FEDERAL LAW AND CAN BE PUNISHED WITH
FINES OR IMPRISONMENT (PUBLIC LAW 99-474). REPORT
SUSPECTED VIOLATIONS TO THE SYSTEM SECURITY OFFICER.
**WARNING**WARNING**WARNING**WARNING**WARNING**
If equipment or software, capable of monitoring
keystrokes, is used on the system for any reason, the
warning screen must be modified to read as follows:
**WARNING**WARNING**WARNING**WARNING**WARNING**
THIS SYSTEM IS FOR THE USE OF AUTHORIZED USERS ONLY.
INDIVIDUALS USING THIS COMPUTER SYSTEM WITHOUT
AUTHORITY, OR IN EXCESS OF THEIR AUTHORITY, ARE SUBJECT
TO HAVING ALL OF THEIR ACTIVITIES ON THIS SYSTEM
MONITORED AND RECORDED BY SYSTEM PERSONNEL. IN THE
COURSE OF MONITORING INDIVIDUALS IMPROPERLY USING THIS
SYSTEM, OR IN THE COURSE OF SYSTEM MAINTENANCE, THE
ACTIVITIES OF AUTHORIZED USERS MAY ALSO BE MONITORED.
ANYONE USING THIS SYSTEM EXPRESSLY CONSENTS TO SUCH
MONITORING AND IS ADVISED THAT IF SUCH MONITORING
REVEALS POSSIBLE EVIDENCE OF CRIMINAL ACTIVITY, SYSTEM
PERSONNEL MAY PROVIDE THE EVIDENCE OF SUCH MONITORING
TO LAW ENFORCEMENT OFFICIALS. REPORT SUSPECTED
VIOLATIONS TO THE SYSTEM SECURITY OFFICER.
**WARNING**WARNING**WARNING**WARNING**WARNING**
The user should then be prompted for a specific
response to continue or exit the system;
8. Should be maintained by the minimum number of
authorized persons; and
9. Should be copied after each modification with the copy
to be immediately stored at a secure off-site location
for emergency use.
Other General Purpose Software - Other general purpose or
utility software may be executed by both users and the
operating system. Many of these perform routine, but
important functions for the users. Others have the
capability to by-pass controls, access databases without
approval, duplicate files, change or reveal passwords and
similar actions which, if used improperly, can compromise
the protection of system resources. These latter programs
and utilities should be safeguarded by:
1. Password protecting those which are only required by,
or should be reserved for, the exclusive use of system
programmers;
2. Password protecting and restricting access to utilities
required to maintain security files;
3. Limiting the utility instructions to operators and
others not having need for these capabilities;
4. Limiting user privileges for utility and general
purpose programs to "execute only" (except for systems
programmers who need additional privileges);
5. Maintaining a current copy of utilities, general
purpose programs and documentation at a properly
secured off-site location for emergency use; and
6. Protecting proprietary software in accordance with the
terms and conditions of the contract or license.
10.12.1 Copyrighted Software
Title 17, United States Code, Section 106 gives copyright
owners exclusive rights to reproduce and distribute their
material, and Section 504 states that copyright infringers
can be held liable for damages to the copyright owner.
Title 18, United States Code provides felony penalties for
software copyright infringement.
It is the responsibility of each DOC employee and supervisor
to protect the government's interests as they perform their
duties. This includes responsibility for assuring that
commercial software, acquired by the government, is used
only in accordance with licensing agreements. Likewise, it
is also their responsibility to assure that any proprietary
software is properly licensed before being installed on DOC
equipment. This policy does not apply to software developed
by or for a federal agency and no restrictions apply to its
use or distribution within the federal government.
Supervisors will ensure that the following requirements are
made known to all employees and will be held accountable for
conducting periodic audits to ensure that these policies are
being followed:
1. Install only commercial software, including shareware,
that has been purchased through the government
procurement process on DOC systems;
2. Follow all provisions of the license agreements issued
with the software and register organizational
ownership;
3. Do not make any illegal copies of copyrighted software.
Normally the license will allow a single copy to be
made for archival purposes. If the license is for
multiple users, do not exceed the authorized number of
copies;
4. At least annually, an inventory of all software on each
individual PC will be audited against the
organization's license agreement records to ensure that
no illegal copies of commercial software are installed
on any equipment.
5. Maintain written records of software installed on each
machine and ensure that a license or other proof of
ownership is on file for each piece of software;
6. Store licenses, software manuals and procurement
documentation in a secure location (i.e., closed file
cabinet, etc.);
7. When upgrades to software are purchased, the old
version should be disposed of in accordance with the
licensing agreement to avoid a potential violation.
Upgraded software is considered a continuation of the
original license, not an additional license;
8. Some government owned software licenses do allow
employees to take copies home for use on their
personally owned computers under specific circumstances
(e.g., for government work but not personal business).
Unless the license specifically states that employees
may take copies of software home for installation on
home computers, doing so is a violation of the
copyright law and the individual will be liable.
9. All illegal copies of software will be deleted
immediately.
All organizations must acquire special purpose software to
inventory and document all software on all PCs belonging to
the organization. This special purpose software may be a
commercial product or the organization may acquire free
software produced by the Software Publishers Association for
this purpose from their operating unit ITSO.
Individual employees should be discouraged from installing
their personally owned software on government equipment. If
it is in the best interest of the DOC organization to allow
personally owned software, authorization must be granted in
writing by the immediate supervisor, showing the
justification. Prior to authorization, the employee must
provide the software license and give assurance that
copyright infringement will not occur from installation on
government equipment. Employees not following these
procedures shall be held personally liable for any
violations of the copyright laws and subject to the
penalties contained in Title 17 and Title 18 of the United
States Code.
10.13 Production Input/Output Controls
Policies and procedures will be established to protect
sensitive information from either accidental, unauthorized
or intentional modification, destruction or disclosure
during input, processing or output operations.
The handling of sensitive input data will be limited to
properly screened persons, and will be controlled by formal
procedures which will provide an audit trail of the data as
it passes from person to person or point to point in the
process. The audit trail must assure personal
accountability from initial receipt to distribution or
destruction of the final products.
Procedures must be established to ensure that only
authorized users pick up or deliver sensitive input and
output data and media. Procedures for sensitive information
should include such controls as signed receipts, registered
mail and locked or monitored user "boxes".
Printouts, containers, tape reels, disk packs, floppy disks
and similar data storage media should be clearly identified
as to contents and sensitivity. The purpose of this is to
prevent accidental release for reuse, inadvertent disclosure
of sensitive information and to notify the users of the need
for continuous protection. Classified information should be
labeled and protected as specified in the "DOC National
Security Information Manual."
Subject to the capabilities of the system, inadvertent
destruction (e.g., overwriting) should be prevented by the
use of "write protect" rings, internal labels, floppy disk
tabs or similar safeguards. Operator instructions for each
application should clearly specify the actions to be taken
in the event of inadvertent damage or destruction, as well
as incidents which cause physical damages to the media.
All sensitive and/or critical data stored on media such as
magnetic tape, disk, and similar devices, should be stored
and controlled in the media library when not required for
processing. Only authorized and properly screened
individuals will be allowed entry to the library. Controls
should be in place to assure that these individuals can be
held accountable for data resources under their control. In
addition to the library, sensitive data may only be stored
in an authorized, secure off-site location or temporarily in
the computer area during processing. Procedural
instructions, inventories and audit trails will be
implemented to assure that these controls are in place and
are effective. If a media library is not justified, as in
the case of a PC, the sensitive diskettes and tapes should
be stored in a locked safe or cabinet with all other
controls in place.
Section 10.19 of this document and Section 19 of the "DOC IT
Security Manual" describe the approved methods of clearing
and/or declassifying storage media which has been used for
classified national security information. Sensitive, but
unclassified data will be handled as follows:
1. Using "delete" or "erase" features usually do not
remove the data from the media, and does not assure
that the data cannot be retrieved by more sophisticated
devices. This process can be used when the media is to
remain under control of the original data owner, and
will be subsequently used to store or process
information of the same or lower sensitivity. It is
important to note that "delete" routines that only
remove pointers and leave the data intact are not
acceptable methods for clearing sensitive data if the
media is to be released outside of the original data
owner's control.
2. If the media containing sensitive information is to be
released outside the original owner's control or is to
be used for non-sensitive data and will not be in a
controlled environment, it should be cleared by
overwriting each memory location, register and other
circuity used for storing sensitive information before
it is reused. Afterwards, verify that all appropriate
memory locations have been cleared. Section 13 of the
"DOC IT Security Manual" contains specific guidance for
clearing and overwriting sensitive data.
10.14 Acquisition and External Processing Requirements
The federal IT security policies are applicable for IT
systems regardless of whether the services are performed
within DOC, by another Government agency, or by a non-
Government agency. However, in the latter two situations,
the agency would not be under the operational management
control of DOC and must be treated somewhat differently.
Procurement or other documents used to acquire or operate IT
installations, equipment, software, and related resources or
services shall contain specifications to assure that
appropriate technical, administrative, personnel and
physical security requirements are included. The specified
security requirements will be reviewed and approved by the
appropriate ITSSO who must certify that the specified
security requirements are reasonably sufficient for the
intended use, and that they satisfy current federal, DOC
laws, regulations and policies.
Processing by Another Government Agency - All Government
agencies are required to adhere to the IT security policies
contained in the "Computer Security Act," P.L. 100-235 and
OMB Circular A-130, unless more stringent policies or
regulations apply. Other federal agencies may implement
these requirements somewhat differently than Commerce, but
they must adhere to the policy that sensitive applications
will only be processed on IT systems having appropriate
security protection, after the systems have been certified
and accredited by senior officials of the organization.
When DOC processing is done by another agency, the
sensitivity of the data and application will be determined
by a DOC official. The certification of the application is
the responsibility of the agency owning the application. If
the application is not a DOC application, the owning agency
must provide a copy of the certification to the Department.
In such a case, compliance with the federal IT security
policies will be accomplished as follows:
1. The DOC data or application owner is responsible for
determining the sensitivity of the data and/or
application and making this known to the servicing
agency.
2. The servicing agency personnel who will have access to
the sensitive DOC resources must be screened in
accordance with the Federal Personnel Manual and the
servicing agency equivalent to the "DOC Personnel
Security Manual." Servicing agreements will specify
that personnel will be screened and appropriate
clearances granted before allowing access to DOC
sensitive resources.
3. The DOC senior official empowered to certify the
sensitive application, if it belonges to DOC, will
request the servicing agency to provide the
certification and backup documentation. Based on the
information provided, the official may choose to
certify, not certify, or certify for operation under
certain specified conditions.
4. The servicing agreement must state clearly that the
application or system has been certified and that the
servicing organization has achieved, and will maintain,
a level of security commensurate with the sensitivity
of the data being processed for the DOC.
5. The agreement must state that the application or system
must be recertified every three years or earlier if
substantial modifications have been made to the
application or system. A copy of the recertification
will be provided to the DOC data or application owner.
6. The agreement must specify that the servicing
organization will develop and maintain a Disaster
Recovery Plan which includes sensitive DOC applications
and data.
Processing by a Non-Government Agency - When a contractor or
other non-Government organization is processing DOC work,
the contract must specify adherence to DOC IT security
policies and the National Industrial Security Program as
outlined in Executive Order 12829 for classified processing.
In addition:
1. Before entering into an agreement to process sensitive
data or applications at a contractor facility, a risk
analysis must be performed, and approved by DOC
personnel. A new risk analysis must be performed
whenever significant changes to the system occur or
every three years, whichever occurs first.
2. DOC sensitive applications must be certified and
recertified, as specified in Section 3 above, for
operation at the contractor facility. Section 3 of the
"DOC IT Security Manual" identifies the required
actions in the certification process.
3. The servicing contract should specify that DOC reserves
the right to perform unannounced on-site inspections to
insure that an adequate level of security is being
maintained.
4. Monitoring contractor compliance will be the
responsibility of the DOC Contracting Officer's
Technical Representative (COTR), in coordination with
the appropriate procurement and IT security officers,
and the DOC owner of the data or application.
Section 14 of the "DOC IT Security Manual" contains specific
information and guidance concerning IT acquisition security
requirements and external IT processing services.
Section 10.15 Telecommunications Security
(Policy is being developed)
Section 10.16 Technical Controls
(Policy is being developed)
10.17 Security Awareness and Training
Operating units shall establish IT security awareness and
training programs to assure that federal and contractor
personnel involved in the management, operation,
programming, maintenance or use of IT are aware of their
security responsibilities and know how to fulfill them.
All new employees will receive an IT security awareness
briefing as part of their orientation within 60 days of
their appointment and all employees will be provided with
refresher awareness material or briefings at least annually.
IT security training above the awareness level shall be
provided to personnel who design, implement or maintain
systems regarding the types of security and internal control
techniques that should be incorporated into system
development, operations and maintenance.
Individuals assigned responsibilities for IT security shall
be provided with in-depth training regarding security
techniques, methodologies for evaluating threats and
vulnerabilities that affect specific IT systems and
applications and selection and implementation of controls
and safeguards.
10.18 Procedural Security
To reduce the potential for compromise, loss or the
unauthorized modification of critical or sensitive IT
resources or data, procedures should be established to
formalize the work flow process and provide the procedural
protection determined by the data owner to be appropriate.
Such procedures are particularly important for office
environments, since a relatively new and powerful processing
capability has been placed into the hands of persons who
frequently have had little experience or training in IT
security matters.
Standard procedures define the authorized actions to be
performed in different circumstances and are invaluable for
training new employees, to avoid unintentional problems or
to recover from these problems if they should occur. They
also allow the manager to detect procedural deviations which
could signal the need for corrective actions ranging from
additional training to disciplinary action. Formal
procedures should be developed with these objectives in
mind.
Section 10.19 Classified National Security Systems
(Policy is being developed)
F. Responsibilities and Process
Department Level
The Director for Information Resources Management (IRM) is
responsible for information while being processed and/or
transmitted electronically, and for the security of the
resources associated with these functions. The Director for
IRM is the Designated Approving Authority (DAA) for all IT
systems processing classified national security information
within the Department. This authority cannot be delegated.
The Director for IRM will monitor, evaluate and report, as
required, to the Assistant Secretary for Administration on
the status of IT security within the Department and the
adequacy of operating unit IT Security programs. Within
IRM, the authority to perform these responsibilities, except
DAA for classified systems, will be exercised by the
Departmental IT Security Manager.
The DOC IT Security Manager monitors, evaluates and reports,
as required, to the Director for IRM on the status of IT
security within the Department and the adequacy of the
programs administered by the operating units. The DOC IT
Security Manager will:
1. Develop policies, procedures and guidance establishing,
implementing, maintaining and overseeing requirements
for the Department's IT security program to be followed
by all DOC organizations.
2. Provide guidance and technical assistance to operating
units, including analyzing, evaluating and approving
all IT system security plans and requirements for IT
systems security.
3. Assure DOC IT security oversight through compliance
reviews of operating units and organizations and IT
security verification reviews of individual systems and
by participating in Commerce program management
oversight processes.
4. Maintain a tracking system and records concerning
implementation of the required controls and
accreditation status of all DOC IT systems.
5. Establish an IT Security Coordinating Committee and
chair regularly scheduled meetings to discuss and
disseminate information on IT security matters and
concerns.
6. Coordinate the review of all controls for classified IT
systems by the Office of Security and the
Telecommunications Management Division and evaluate the
adequacy of all technical controls for accreditation.
7. Act as the central point of contact for the Department
for IT security related incidents or violations.
Investigate or cause to be investigated any incidents
or violations, maintain records and prepare reports,
disseminate information concerning potential threats
and report to the Office of Security any violations
that come under their area of responsibilities or to
the Assistant Inspector General for Investigations any
activity which may constitute a violation of law or
otherwise is reportable to that office in accordance
with DAO 207-10, "Inspector General Investigations."
8. Coordinate with the Department's Office of Security on
security matters of mutual interest.
Operating Unit Level
Senior IRM Official - Each operating unit Senior IRM
Official shall conduct an IT security program that ensures
appropriate and adequate levels of protection for all IT
systems within the operating unit. The Senior IRM official
shall:
1. Be the DAA for all sensitive systems within their
organization. This approval authority may only be
delegated to a senior management official of a
subordinate organizational unit, if that official does
not have direct control over the IT system being
accredited. Delegation of accreditation authority must
be requested and approved in advance by the DOC
Director for IRM.
2. Assure ownership is assigned for all IT resources
within the operating unit (i.e., hardware, software,
data, telecommunications, etc.).
3. Appoint an ITSO and alternate for the operating unit.
This individual, or alternate, should have the staff
responsibility for the operating unit IT security
program.
Operating Unit ITSO - The operating unit ITSO shall serve as
the central point of contact for the operating unit IT
security program with the Departmental IT Security Manager.
The operating unit ITSO shall perform the following
functions:
1. Represent the operating unit as a voting member of the
DOC IT Security Coordinating Committee, attend
regularly scheduled meetings to obtain current
information on issues relating to federal or DOC IT
security policies, regulations, guidelines, share
information with the committee about issues or concerns
and participate in special subcommittees working to
solve Department-wide issues.
2. Ensure that an ITSO and alternate are appointed for
each major subordinate organizational component within
the operating unit, if appropriate. These individuals
will serve as the point of contact for their
organizational component IT security program with the
operating unit ITSO.
3. Establish and maintain a list of all IT systems within
the operating unit and provide an up-to-date list to
the DOC IT Security Manager annually.
4. Ensure that an ITSSO has been appointed for each IT
system within the operating unit.
5. Ensure IT security plans are prepared in the proper
format for all sensitive and classified IT systems
owned and operated by the operating unit. Review and
comment on individual IT security plans, ensuring that
all corrective actions are completed and submit all
plans to the DOC IT Security Manager. Requirements for
IT security plans are contained in Section 10.2 of this
document and Section 2 of the "DOC IT Security Manual."
6. Ensure that risk analysis is completed for all
sensitive or classified IT systems within the operating
unit. Requirements for risk analysis are contained in
Section 10.7 of this document and Section 7 of the "DOC
IT Security Manual."
7. Ensure that contingency and disaster recovery plans are
developed for all sensitive or classified IT systems
within the operating unit. Requirements for
contingency and disaster recovery planning are
contained in Section 10.8 of this document and Section
8 of the "DOC IT Security Manual."
8. Maintain a tracking system concerning implementation of
the required controls and accreditation status for all
operating unit sensitive and classified IT systems.
9. Act as the central point of contact for accreditation
of all sensitive IT systems within the operating unit.
Ensure that all certification requirements have been
met for each system, prior to accreditation.
Certification requirements are contained in Section
10.3 of this document and Section 3 of the "DOC IT
Security Manual." The ITSO will submit an accreditation
status report quarterly to the DOC IT Security Manager.
Accreditation requirements are contained in Section
10.4 of this document and Section 4 of the "DOC IT
Security Manual."
10. Conduct, or cause to be conducted, IT security
verification reviews of all operating unit sensitive IT
systems every three years. Requirements for IT
security verification reviews are contained in Section
10.5 of this document and Section 5 of the "DOC IT
Security Manual."
11. Ensure that all operating unit personnel are provided
appropriate IT security awareness and training. IT
security awareness and training requirements are
contained in Section 10.17 of this document and Section
17 of the "DOC IT Security Manual."
12. Act as the central point of contact for the operating
unit for any type of IT security related incidents or
violations. Investigate or cause to be investigated
any incidents or violations, maintain records and
ensure reports are submitted to the DOC IT Security
Manager and disseminate information concerning
potential threats to system owners. Requirements for
incident and violation reporting are contained in
Section 10.5 of this document and Section 5 of the "DOC
IT Security Manual."
13. Ensure that the operating unit has a malicious software
policy in place and the required virus detection and
elimination software and procedures are available to
protect against these threats. Malicious software
protection and reporting requirements are contained in
Section 10.6.1 of this document and Section 6.1 of the
"DOC IT Security Manual."
14. Ensure that the operating unit has established a policy
against the illegal duplication of copyrighted
software. Ensure that all systems are audited for
illegal software at least annually and inventories of
all software on each individual system is maintained to
verify that only legal copies of software are being
used. Requirements for software copyright protection,
auditing and reporting are contained in Section 10.12.1
of this document and Section 12.1 of the "DOC IT
Security Manual."
15. Coordinate with the operating unit Security Office on
security matters of mutual interest.
In the absence of the ITSO the alternate shall perform all
functions normally assigned to the ITSO for the operating
unit IT security program.
Subordinate Organization ITSO - Not all operating units
within the Department will require this level position. A
major subordinate organization is defined to mean any large
organizational component that has management responsibility
for a number of individual IT systems performing separate
functions (i.e., Line Office, Laboratory, Regional Office).
The subordinate organization ITSO shall serve as the central
point of contact for the subordinate organization IT
security program with the operating unit ITSO. If this
level of position is determined to be appropriate for the
operating unit, the functions of the ITSO for the
subordinate organization generally parallel those specified
for the ITSO.
System Owner - Responsibility for the protection of IT
resources generally falls into two broad categories:
custodial and owner. The fulfillment of the protection
responsibilities of each is mandatory.
1. All information resources (hardware, software,
facilities, data and telecommunications) will be
assigned to an owner, designated in writing to the
Senior IRM Official of the operating unit. For
example, the "owner" of the resources contained within
a general support system may be the manager of that
facility. Resources located within user areas (i.e.,
offices or laboratories) may be "owned" by the manager
of those areas. To assist with the determination of
ownership, individual system boundaries must be
established. A system is identified by logical
boundaries being drawn around the various processing,
communications, storage and related resources. They
must be under the same direct management control with
essentially the same function, reside in the same
environment and have the same characteristics and
security needs. Each system will be designated either
a general support system or an application system.
Chapter 10.2 of this document and Section 2 of the "DOC
IT Security Manual" contain definitions for general
support and application systems.
2. Ownership of information and/or information processing
resources may be assigned to an organization,
subordinate functional element, a position , or a
specific individual. When ownership is assigned to an
organizational or functional element, the head of the
unit so designated shall be considered the resource
owner. Some, but not necessarily all factors to be
considered in the determination of ownership are:
(a) The originator or creator of data.
(b) The organization or individual with the greatest
functional interest.
(c) Physical possession of the resource.
3. Some general support system owners are suppliers of
data processing services for applications owned by
other organizations. Typically these systems are
custodians of software, data, input and output produced
by the data processing facility to support one or more
application owners. Custodial responsibility includes
the obligation to comply with applicable security
policies and directives, and to administer application
owner specified controls and safeguards for the data
and programs of those owners. Many of the Department's
local area networks will fit into this category.
4. Each system owner shall be responsible to:
(a) Determine the sensitivity of the resources for
which responsible.
(b) Determine the appropriate level of security
required which is consistent with federal and DOC
laws, regulations and directives and the
protection requirements of the system for
confidentiality, integrity or available and ensure
that an adequate level of protection is
maintained.
(c) Be the certifying official and complete all
required certification actions, issue a
certification statement and prepare an
accreditation package which will be forwarded to
the DAA for formal accreditation of the system,
every three years or when major changes occur to
the system, whichever is less. If the certifying
official is at a higher level in the organization,
the system owner will complete all required
certification actions and forward the
accreditation package to the certifying official,
who will issue the certification statement.
Chapter 10.3 of this document and Section 3 of the
"DOC IT Security Manual" contain certification
requirements.
(d) Monitor compliance, and periodically re-evaluate
previously specified levels of sensitivity and
protection.
(e) Ensure that all systems are audited for illegal
software at least annually and inventories of all
software on each individual system is maintained
to verify that only legal copies of software are
being used. Requirements for software copyright
protection, auditing and reporting are contained
in Section 10.12.1 of this document and Section
12.1 of the "DOC IT Security Manual."
(f) Ensure that each automated data processing
position (including contract positions) are
properly designated in accordance with position
sensitivity criteria and receive appropriate
investigative processing. Refer to Section 9 of
the "DOC IT Security Manual" and the "DOC
Personnel Security Manual" for further guidance.
(g) Appoint an individual to serve as the ITSSO with
responsibility to develop, implement and manage
the security of the system.
ITSSO - The ITSSO for each classified or sensitive system
shall perform the following functions:
1. Advise the IT system owner on matters pertaining to IT
systems security.
2. Develop, implement and manage the execution of the IT
system security program.
3. Prepare, or cause to be prepared an IT system security
plan in the proper format for the IT system.
Requirements for IT security plans are contained in
Chapter 10.2 of this document and Section 2 of the "DOC
IT Security Manual."
4. Conduct, or cause to be conducted, a risk analysis on
the system when there are major changes to the system
or every three years, whichever is less. Requirements
for risk analysis are contained in Chapter 10.7 of this
document and Section 7 of the "DOC IT Security Manual."
5. Ensure that contingency and disaster recovery plans are
developed, maintained in an up-to-date condition and
tested at least annually. Requirements for contingency
and disaster recovery plans are contained in Chapter
10.8 of this document and Section 8 of the "DOC IT
Security Manual."
6. Establish and maintain liaison with any remote
facilities or users served by the IT system, the
operating unit ITSO, or if appropriate, the subordinate
organization ITSO.
7. Monitor changes in hardware, software,
telecommunications, facilities and user requirements to
ensure that security is not compromised or degraded.
8. Exercise system responsibility or direct activities for
password management and control.
9. Arrange for IT security awareness training for the
system staff and monitor the user training programs to
ensure that personnel receive security orientation
before being allowed access to sensitive IT resources.
10. Ensure that positions requiring access to classified
information or resources are identified and that
incumbents of these positions receive an appropriate
level of security clearance before access is granted.
11. Investigate or cause to be investigated known or
suspected security incidents or violations and prepare
reports of findings as required in Chapter 10.6 of this
document and Section 6 of the "DOC IT Security Manual.
Verbal and written reports will be made to the
operating unit ITSO through the subordinate ITSO, if
appropriate. Incidents involving a physical security
violation, such as theft or violations of the personnel
security, classified information or industrial security
programs will be referred to the operating unit Office
of Security for investigation.
12. Ensure that the organization abides by the DOC and
operating unit malicious software policies and has the
required virus detection and elimination software and
procedures available to protect against these threats.
Malicious software protection and reporting
requirements are contained in Chapter 10.6.1 of this
document and Section 6.1 of the "DOC IT Security
Manual."
13. Audit all the systems within the organization for
illegal software at least annually and maintain
inventories of all software on each individual system
to verify that only legal copies of software are being
used. Requirements for software Copyright protection,
auditing and reporting are contained in Section 10.12.1
of this document and Section 12.1 of the "DOC IT
Security Manual."
14. Review IT related procurement specifications for
hardware, software or services to ensure that they
include adequate security requirements and/or
specifications which are commensurate with the
sensitivity of the system.
15. Conduct, or cause to be conducted, all activities
required for the certification of the system, including
preparing the certification and accreditation packages
for final approval every three years or when major
changes occur to the system, whichever is less.
16. Coordinate with the operating unit Security Office or
local Security Office on security matters of mutual
interest.
User Level - The primary purpose of IT systems is to support
the missions of using organizations. User management bears
a great deal of responsibility for their systems and data.
In addition to defining the functions to be performed by the
system, and its security requirements, the user is directly
responsible for the system resources, such as terminals and
printers, located within the user areas. In order to assure
adequate security within the user areas where these
resources are located, user managers will appoint a user
ITSSO to be responsible for the IT security within the user
area. This individual is responsible for implementing and
enforcing the security program at the user's location. The
functions of the user ITSSO generally parallel those
specified for the ITSSO.
Each employee of the Department is responsible for the
adequate protection of IT resources within their control or
possession and for abiding by all DOC IT security policies.
G. Relationship with Other Security Programs
The Office of Security is responsible for: (1) physical
security of facilities and equipment external to computers
or telecommunication lines; (2) all procedural matters
relating to national security information; (3) matters
relating to background and security clearance investigations
of personnel; and (4) national emergency planning. For
policies relating to these areas, refer to the appropriate
Departmental directives, i.e., DAO 207- series.
The Office of the Inspector General provides independent
oversight through audit and evaluation of the Department's
IT security program in accordance with the "Inspector
General's Act of 1978." For policies relating to these
areas, refer to the appropriate Departmental directives,
i.e., DAO 207-10.
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed