Ch 12 kho tài liệu training

CHAPTER

Operations Security
This chapter presents the following:
• Administrative management responsibilities
• Operations department responsibilities
• Configuration management
• Trusted recovery states
• Redundancy and fault-tolerant systems
• E-mail security
• Threats to operations security

Operations security pertains to everything that takes place to keep networks, computer
systems, applications, and environments up and running in a secure and protected
manner. It consists of ensuring that people, applications, and servers have the proper
access privileges to only the resources they are entitled to and that oversight is implemented via monitoring, auditing, and reporting controls. Operations take place after
the network is developed and implemented. This includes the continual maintenance
of an environment and the activities that should take place on a day-to-day or week-toweek basis. These activities are routine in nature and enable the network and individual computer systems to continue running correctly and securely.
Networks and computing environments are evolving entities; just because they are
secure one week does not mean they are still secure three weeks later. Many companies
pay security consultants to come in and advise them on how to improve their infrastructure, policies, and procedures. A company can then spend thousands or even hundreds of thousands of dollars to implement the consultant’s suggestions, install
properly configured firewalls, intrusion detection systems (IDSs), antivirus software,
and patch management systems. However, if the IDS and antivirus software do not
continually have updated signatures, if the systems are not continually patched, if firewalls and devices are not tested for vulnerabilities, or if new software is added to the
network and not added to the operations plan, then the company can easily slip back
into an insecure and dangerous place. This can happen if the company does not keep
its operations security tasks up-to-date.
Most of the necessary operations security issues have been addressed in earlier
chapters. They were integrated with related topics and not necessarily pointed out as
actual operations security issues. So instead of repeating what has already been stated,

1027

12


CISSP All-in-One Exam Guide

1028
this chapter reviews and points out the operations security topics that are important for
organizations and CISSP candidates.

The Role of the Operations Department
I am a very prudent man.
Response: That is debatable.
The continual effort to make sure the correct policies, procedures, standards, and
guidelines are in place and being followed is an important piece of the due care and due
diligence efforts that companies need to perform. Due care and due diligence are comparable to the “prudent person” concept. A prudent person is seen as responsible, careful, cautious, and practical, and a company practicing due care and due diligence is
seen in the same light. The right steps need to be taken to achieve the necessary level of
security, while balancing ease of use, compliance with regulatory requirements, and
cost constraints. It takes continued effort and discipline to retain the proper level of
security. Operations security is all about ensuring that people, applications, equipment,
and the overall environment are properly and adequately secured.
Although operations security is the practice of continual maintenance to keep an
environment running at a necessary security level, liability and legal responsibilities also
exist when performing these tasks. Companies, and senior executives at those companies, often have legal obligations to ensure that resources are protected, safety measures
are in place, and security mechanisms are tested to guarantee they are actually providing
the necessary level of protection. If these operations security responsibilities are not fulfilled, the company may have more than antivirus signatures to be concerned about.
An organization must consider many threats, including disclosure of confidential
data, theft of assets, corruption of data, interruption of services, and destruction of the
physical or logical environment. It is important to identify systems and operations that

are sensitive (meaning they need to be protected from disclosure) and critical (meaning
they must remain available at all times). (Refer to Chapter 10 to learn more about the
legal, regulatory, and ethical responsibilities of companies when it comes to security.)
It is also important to note that while organizations have a significant portion of
their operations activities tied to computing resources, they still also rely on physical
resources to make things work, including paper documents and data stored on microfilm, tapes, and other removable media. A large part of operations security includes
ensuring that the physical and environmental concerns are adequately addressed, such
as temperature and humidity controls, media reuse, disposal, and destruction of media
containing sensitive information.
Overall, operations security is about configuration, performance, fault tolerance,
security, and accounting and verification management to ensure that proper standards
of operations and compliance requirements are met.

Administrative Management
I think our tasks should be separated, because I don’t trust you.
Response: Fine by me.
Administrative management is a very important piece of operations security. One
aspect of administrative management is dealing with personnel issues. This includes


Chapter 12: Operations Security

1029
separation of duties and job rotation. The objective of separation of duties is to ensure
that one person acting alone cannot compromise the company’s security in any way.
High-risk activities should be broken up into different parts and distributed to different
individuals or departments. That way, the company does not need to put a dangerously
high level of trust in certain individuals. For fraud to take place, collusion would need
to be committed, meaning more than one person would have to be involved in the
fraudulent activity. Separation of duties, therefore, is a preventive measure that requires

collusion to occur in order for someone to commit an act that is against policy.
Table 12-1 shows many of the common roles within organizations and their corresponding job definitions. Each role needs to have a completed and well-defined job
description. Security personnel should use these job descriptions when assigning access
rights and permissions in order to ensure that individuals have access only to those
resources needed to carry out their tasks.
Table 12-1 contains just a few roles with a few tasks per role. Organizations should
create a complete list of roles used within their environment, with each role’s associated
tasks and responsibilities. This should then be used by data owners and security personnel when determining who should have access to specific resources and the type of
access.
Separation of duties helps prevent mistakes and minimize conflicts of interest that
can take place if one person is performing a task from beginning to end. For instance,
a programmer should not be the only one to test her own code. Another person with
a different job and agenda should perform functionality and integrity testing on the
Organizational Role

Core Responsibilities

Control Group

Obtains and validates information obtained from analysts,
administrators, and users and passes it on to various user groups.

Systems Analyst

Designs data flow of systems based on operational and user
requirements.

Application Programmer

Develops and maintains production software.

Help Desk/Support

Resolves end-user and system technical or operations problems.

IT Engineer

Performs the day-to-day operational duties on systems and
applications.

Database Administrator

Creates new database tables and manages the database.

Network Administrator

Installs and maintains the LAN/WAN environment.

Security Administrator

Defines, configures, and maintains the security mechanisms
protecting the organization.

Tape Librarian

Receives, records, releases, and protects system and application
files backed up on media such as tapes or disks.

Quality Assurance

Can consist of both Quality Assurance (QA) and Quality Control
(QC). QA ensures that activities meet the prescribed standards
regarding supporting documentation and nomenclature. QC
ensures that the activities, services, equipment, and personnel
operate within the accepted standards.

Table 12-1 Roles and Associated Tasks


CISSP All-in-One Exam Guide

1030
programmer’s code, because the programmer may have a focused view of what
the program is supposed to accomplish and thus may test only certain functions and
input values, and only in certain environments.
Another example of separation of duties is the difference between the functions of a
computer user and the functions of a security administrator. There must be clear-cut
lines drawn between system administrator duties and computer user duties. These will
vary from environment to environment and will depend on the level of security required
within the environment. System and security administrators usually have the responsibility of performing backups and recovery procedures, setting permissions, adding and
removing users, and developing user profiles. The computer user, on the other hand,
may be allowed to install software, set an initial password, alter desktop configurations,
and modify certain system parameters. The user should not be able to modify her own
security profile, add and remove users globally, or make critical access decisions pertaining to network resources. This would breach the concept of separation of duties.
Job rotation means that, over time, more than one person fulfills the tasks of one
position within the company. This enables the company to have more than one person
who understands the tasks and responsibilities of a specific job title, which provides
backup and redundancy if a person leaves the company or is absent. Job rotation also
helps identify fraudulent activities, and therefore can be considered a detective type of
control. If Keith has performed David’s position, Keith knows the regular tasks and

routines that must be completed to fulfill the responsibilities of that job. Thus, Keith is
better able to identify whether David does something out of the ordinary and suspicious. (Refer to Chapter 4 for further examples pertaining to job rotation.)
Least privilege and need to know are also administrative-type controls that should
be implemented in an operations environment. Least privilege means an individual
should have just enough permissions and rights to fulfill his role in the company and
no more. If an individual has excessive permissions and rights, it could open the door
to abuse of access and put the company at more risk than is necessary. For example, if
Dusty is a technical writer for a company, he does not necessarily need to have access to
the company’s source code. So, the mechanisms that control Dusty’s access to resources
should not let him access source code. This would properly fulfill operations security
controls that are in place to protect resources.
Least privilege and need to know have a symbiotic relationship. Each user should
have a need to know about the resources that he is allowed to access. If Mike does not
have a need to know how much the company paid last year in taxes, then his system
rights should not include access to these files, which would be an example of exercising
least privilege. The use of new identity management software that combines traditional
directories, access control systems, and user provisioning within servers, applications,
and systems is becoming the norm within organizations. This software provides the
capabilities to ensure that only specific access privileges are granted to specific users
and it often includes advanced audit functions that can be used to verify compliance to
legal and regulatory directives.
A user’s access rights may be a combination of the least-privilege attribute, the user’s
security clearance, the user’s need to know, the sensitivity level of the resource, and the
mode in which the computer operates. A system can operate in different modes depending on the sensitivity of the data being processed, the clearance level of the users, and


Chapter 12: Operations Security

1031
what those users are authorized to do. The mode of operation describes the conditions

under which the system actually functions. These are clearly defined in Chapter 5.
Mandatory vacations are another type of administrative control, though the name
may sound a bit odd at first. Chapter 3 touches on reasons to make sure employees take
their vacations. Reasons include being able to identify fraudulent activities and enabling job rotation to take place. If an accounting employee has been performing a salami attack by shaving off pennies from multiple accounts and putting the money into
his own account, a company would have a better chance of figuring this out if that employee is required to take a vacation for a week or longer. When the employee is on
vacation, another employee has to fill in. She might uncover questionable documents
and clues of previous activities, or the company may see a change in certain patterns
once the employee who is committing fraud is gone for a week or two.
It is best for auditing purposes if the employee takes two contiguous weeks off from
work to allow more time for fraudulent evidence to appear. Again, the idea behind
mandatory vacations is that, traditionally, those employees who have committed fraud
are usually the ones who have resisted going on vacation because of their fear of being
found out while away.

Security and Network Personnel
The security administrator should not report to the network administrator, because
their responsibilities have different focuses. The network administrator is under pressure to ensure high availability and performance of the network and resources and to
provide the users with the functionality they request. But many times this focus on
performance and user functionality is at the cost of security. Security mechanisms commonly decrease performance in either processing or network transmission because
there is more involved: content filtering, virus scanning, intrusion detection prevention, anomaly detection, and so on. Since these are not the areas of focus and responsibility of many network administrators, a conflict of interest could arise. The security
administrator should be within a different chain of command from that of the network
personnel, to ensure that security is not ignored or assigned a lower priority.
The following list lays out tasks that should be carried out by the security administrator, not the network administrator:
• Implements and maintains security devices and software Despite some
security vendors’ claims that their products will provide effective security
with “set it and forget it” deployments, security products require monitoring
and maintenance in order to provide their full value. Version updates and
upgrades may be required when new capabilities become available to combat
new threats, and when vulnerabilities are discovered in the security products
themselves.

• Carries out security assessments As a service to the business that the
security administrator is working to secure, a security assessment leverages
the knowledge and experience of the security administrator to identify
vulnerabilities in the systems, networks, software, and in-house developed
products used by a business. These security assessments enable the business
to understand the risks it faces, and make sensible business decisions about


CISSP All-in-One Exam Guide

1032
products and services it considers purchasing, and risk mitigation strategies
it chooses to fund versus risks it chooses to accept, transfer (by buying
insurance), or avoid (by not doing something it had earlier considered doing,
but isn’t worth the risk or risk mitigation cost).
• Creates and maintains user profiles and implements and maintains access
control mechanisms The security administrator puts into practice the security
policies of least privilege, and oversees accounts that exist, along with the
permissions and rights they are assigned.
• Configures and maintains security labels in mandatory access control (MAC)
environments MAC environments, mostly found in government and military
agencies, have security labels set on data objects and subjects. Access decisions
are based on comparing the object’s classification and the subject’s clearance,
as covered extensively in Chapter 4. It is the responsibility of the security
administrator to oversee the implementation and maintenance of these
access controls.
• Sets initial passwords for users New accounts must be protected from
attackers who might know patterns used for passwords, or might find
accounts that have been newly created without any passwords and take over
those accounts before the authorized user accesses the account and changes

the password. The security administrator operates automated new password
generators, or manually sets new passwords, and then distributes them to the
authorized user so attackers cannot guess the initial or default passwords on
new accounts, and so new accounts are never left unprotected.
• Reviews audit logs While some of the strongest security protections come
from preventive controls (such as firewalls that block unauthorized network
activity), detective controls such as reviewing audit logs are also required. The
firewall blocked 60,000 unauthorized access attempts yesterday. The only
way to know if that’s a good thing or an indication of a bad thing is for the
security administrator (or automated technology under his control) to review
those firewall logs to look for patterns. If those 60,000 blocked attempts were
the usual low-level random noise of the Internet, then things are (probably)
normal, but if those attempts were advanced and came from a concentrated
selection of addresses on the Internet, a more deliberate (and more possibly
successful) attack may be underway. The security administrator’s review of
audit logs detects bad things as they occur and, hopefully, before they cause
real damage.

Accountability
You can’t prove that I did it.
Response: Ummm, yes we can.
Users’ access to resources must be limited and properly controlled to ensure that
excessive privileges do not provide the opportunity to cause damage to a company and
its resources. Users’ access attempts and activities while using a resource need to be
properly monitored, audited, and logged. The individual user ID needs to be included


Chapter 12: Operations Security

1033

in the audit logs to enforce individual responsibility. Each user should understand his
responsibility when using company resources and be accountable for his actions.
Capturing and monitoring audit logs helps determine if a violation has actually occurred or if system and software reconfiguration is needed to better capture only the
activities that fall outside of established boundaries. If user activities were not captured
and reviewed, it would be very hard to determine if users have excessive privileges or if
there has been unauthorized access.
Auditing needs to take place in a routine manner. Also, someone needs to review
audit and log events. If no one routinely looks at the output, there really is no reason to
create logs. Audit and function logs often contain too much cryptic or mundane information to be interpreted manually. This is why products and services are available that parse
logs for companies and report important findings. Logs should be monitored and reviewed, through either manual or automatic methods, to uncover suspicious activity and
to identify an environment that is shifting away from its original baselines. This is how
administrators can be warned of many problems before they become too big and out of
control. (See Chapters 3, 6, and 10 for auditing, logging, and monitoring issues.)
When monitoring, administrators need to ask certain questions that pertain to the
users, their actions, and the current level of security and access:
• Are users accessing information and performing tasks that are not necessary for
their job description? The answer would indicate whether users’ rights and
permissions need to be reevaluated and possibly modified.
• Are repetitive mistakes being made? The answer would indicate whether users
need to have further training.
• Do too many users have rights and privileges to sensitive or restricted data or
resources? The answer would indicate whether access rights to the data and
resources need to be reevaluated, whether the number of individuals accessing
them needs to be reduced, and/or whether the extent of their access rights
should be modified.

Clipping Levels
I am going to keep track of how many mistakes you make.
Companies can set predefined thresholds for the number of certain types of errors
that will be allowed before the activity is considered suspicious. The threshold is a baseline for violation activities that may be normal for a user to commit before alarms are

raised. This baseline is referred to as a clipping level. Once this clipping level has been
exceeded, further violations are recorded for review. Most of the time, IDS software is
used to track these activities and behavior patterns, because it would be too overwhelming for an individual to continually monitor stacks of audit logs and properly identify
certain activity patterns. Once the clipping level is exceeded, the IDS can e-mail a message to the network administrator, send a message to his pager, or just add this information to the logs, depending on how the IDS software is configured.
The goal of using clipping levels, auditing, and monitoring is to discover problems
before major damage occurs and, at times, to be alerted if a possible attack is underway
within the network.


CISSP All-in-One Exam Guide

1034
NOTE The security controls and mechanisms that are in place must have
a degree of transparency. This enables the user to perform tasks and duties
without having to go through extra steps because of the presence of the
security controls. Transparency also does not let the user know too much
about the controls, which helps prevent him from figuring out how to
circumvent them. If the controls are too obvious, an attacker can figure
out how to compromise them more easily.

Assurance Levels
When products are evaluated for the level of trust and assurance they provide, many
times operational assurance and life-cycle assurance are part of the evaluation process.
Operational assurance concentrates on the product’s architecture, embedded features,
and functionality that enable a customer to continually obtain the necessary level of
protection when using the product. Examples of operational assurances examined in
the evaluation process are access control mechanisms, the separation of privileged and
user program code, auditing and monitoring capabilities, covert channel analysis, and
trusted recovery when the product experiences unexpected circumstances.
Life-cycle assurance pertains to how the product was developed and maintained.

Each stage of the product’s life cycle has standards and expectations it must fulfill before it can be deemed a highly trusted product. Examples of life-cycle assurance standards are design specifications, clipping-level configurations, unit and integration
testing, configuration management, and trusted distribution. Vendors looking to
achieve one of the higher security ratings for their products will have each of these issues evaluated and tested.
The following sections address several of these types of operational assurance and
life-cycle assurance issues not only as they pertain to evaluation, but also as they pertain to a company’s responsibilities once the product is implemented. A product is just
a tool for a company to use for functionality and security. It is up to the company to
ensure that this functionality and security are continually available through responsible
and proactive steps.

References
• NIST Security Configuration Checklists Program for IT Products http://
csrc.nist.gov/checklists/
• An Introduction to Computer Security: The NIST Handbook />publications/nistpubs/800-12/
• “The Operations Security Connection,” by Arion N. Pattakos, PM (Jan.–Feb.
1999) www.au.af.mil/au/awc/awcgate/dau/pattakjf.pdf

Operational Responsibilities
Operations security encompasses safeguards and countermeasures to protect resources,
information, and the hardware on which the resources and information reside. The
goal of operations security is to reduce the possibility of damage that could result from
unauthorized access or disclosure by limiting the opportunities of misuse.


Chapter 12: Operations Security

1035
Some organizations may have an actual operations department that is responsible
for activities and procedures required to keep the network running smoothly and to
keep productivity at a certain level. Other organizations may have a few individuals
who are responsible for these things, but no structured department dedicated just to

operations. Either way, the people who hold these responsibilities are accountable for
certain activities and procedures and must monitor and control specific issues.
Operations within a computing environment may pertain to software, personnel,
and hardware, but an operations department often focuses on the hardware and software aspects. Management is responsible for employees’ behavior and responsibilities.
The people within the operations department are responsible for ensuring that systems
are protected and continue to run in a predictable manner.
The operations department usually has the objectives of preventing recurring problems, reducing hardware and software failures to an acceptable level, and reducing the
impact of incidents or disruption. This group should investigate any unusual or unexplained occurrences, unscheduled initial program loads, deviations from standards, or
other odd or abnormal conditions that take place on the network.

Unusual or Unexplained Occurrences
Networks, and the hardware and software within them, can be complex and dynamic.
At times, conditions occur that are at first confusing and possibly unexplainable. It is up
to the operations department to investigate these issues, diagnose the problem, and
come up with a logical solution.
One example could be a network that has hosts that are continually kicked off the
network for no apparent reason. The operations team should conduct controlled troubleshooting to make sure it does not overlook any possible source for the disruption
and that it investigates different types of problems. The team may look at connectivity
issues between the hosts and the wiring closet, the hubs and switches that control their
connectivity, and any possible cabling defects. The team should work methodically
until it finds a specific problem. Central monitoring systems and event management
solutions can help pinpoint the root cause of problems and save much time and effort
in diagnosing problems.
NOTE Event management means that a product is being used to collect
various logs throughout the network. The product identifies patterns and
potentially malicious activities that a human would most likely miss because
of the amount of data in the various logs.

Deviations from Standards
In this instance, “standards” pertains to computing service levels and how they are measured. Each device can have certain standards applied to it: the hours of time to be online, the number of requests that can be processed within a defined period of time,

bandwidth usage, performance counters, and more. These standards provide a baseline
that is used to determine whether there is a problem with the device. For example, if a
device usually accepts approximately 300 requests per minute, but suddenly it is only
able to accept three per minute, the operations team would need to investigate the


CISSP All-in-One Exam Guide

1036
deviation from the standard that is usually provided by this device. The device may be
failing or under a DoS attack, or be subject to legitimate business use cases which had
not been foreseen when the device was first implemented.
Sometimes the standard needs to be recalibrated so it portrays a realistic view of the
service level it can provide. If a server was upgraded from a Pentium II to a Pentium III,
the memory was quadrupled, the swap file was increased, and three extra hard drives
were added, the service level of this server should be reevaluated.

Unscheduled Initial Program Loads (a.k.a. Rebooting)
Initial program load (IPL) is a mainframe term for loading the operating system’s kernel
into the computer’s main memory. On a personal computer, booting into the operating
system is the equivalent to IPLing. This activity takes place to prepare the computer for
user operation.
The operations team should investigate computers that reboot for no reason—a
trait that could indicate the operating system is experiencing major problems, or is possessed by the devil.

Asset Identification and Management
Asset management is easily understood as “knowing what the company owns.” In a
retail store, this may be called inventory management, and is part of routine operations
to ensure that sales records and accounting systems are accurate, and that theft is discovered. While these same principles may apply to an IT environment, there’s much
more to it than just the physical and financial aspect.

A prerequisite for knowing if hardware (including systems and networks) and software are in a secure configuration is knowing what hardware and software are present
in the environment. Asset management includes knowing and keeping up-to-date this
complete inventory of hardware (systems and networks) and software.
At a high level, asset management may seem to mean knowing that the company
owns 600 desktop PCs of one manufacturer, 400 desktop PCs of another manufacturer,
and 200 laptops of a third manufacturer. Is that sufficient to manage the configuration
and security of these 1200 systems? No.
Taking it a level deeper, would it be enough to know that those 600 desktop PCs
from manufacturer A are model 123, the 400 desktop PCs from manufacturer B are
model 456, and the 200 laptops are model C? Still no.
To be fully aware of all of the “moving parts” that can be subject to security risks, it
is necessary to know the complete manifest of components within each hardware system, operating system, hardware network device, network device operating system, and
software application in the environment. The firmware within a network card inside a
computer may be subject to a security vulnerability; certainly the device driver within
the operating system which operates that network card may present a risk. Operating
systems are a relatively well-known and fairly well manageable aspect of security risk.
Less known and increasingly more important are the applications (software): Did an
application include a now out-of-date and insecure version of a Java Runtime Environ-


Chapter 12: Operations Security

1037
ment? Did an application drop another copy of an operating system library into a
nonstandard (and unmanaged) place, just waiting to be found by an old exploit which
you were sure you had already patched (and did, but only in the usual place where that
library exists in the operating system)?
Asset management means knowing everything—hardware, firmware, operating system, language runtime environments, applications, and individual libraries—in the
overall environment. Clearly, only an automated solution can fully accomplish this.
Having a complete inventory of everything that exists in the overall environment is

necessary, but is not sufficient. One security principle is simplicity: If a component is
not needed, it is best for the component to not be present. A component which is not
present in the environment cannot cause a security risk to the environment. Sometimes
components are bundled and are impractical to remove. In such cases, they simply
must be managed along with everything else to ensure they remain in a secure state.
Configuration standards are the expected configuration against which the actual
state may be checked. Any change from the expected configuration should be investigated, because it means either the expected configuration is not being accurately kept
up-to-date, or that control over the environment is not adequately preventing unauthorized (or simply unplanned) changes from happening in the environment. Automated asset management tools may be able to compare the expected configuration
against the actual state of the environment.
Returning to the principle of simplicity, it is best to keep the quantity of configuration standards to the reasonable minimum which supports the business needs. Change
Management, or Configuration Management, must be involved in all changes to the
environment so configuration standards may be accurately maintained. Keeping the
quantity of configuration standards to a reasonable minimum will reduce the total cost
of Change Management.

System Controls
System controls are also part of operations security. Within the operating system itself,
certain controls must be in place to ensure that instructions are being executed in the
correct security context. The system has mechanisms that restrict the execution of certain types of instructions so they can take place only when the operating system is in a
privileged or supervisor state. This protects the overall security and state of the system
and helps ensure it runs in a stable and predictable manner.
Operational procedures need to be developed that indicate what constitutes the
proper operation of a system or resource. This would include a system startup and shutdown sequence, error handling, and restoration from a known good source.
An operating system does not provide direct access to hardware by processes of
lower privilege, which are usually processes used by user applications. If a program
needs to send instructions to hardware devices, the request is passed off to a process of
higher privilege. To execute privileged hardware instructions, a process must be running
in a restrictive and protective state. This is an integral part of the operating system’s architecture, and the determination of what processes can submit what type of instructions is made based on the operating system’s control tables.

CISSP All-in-One Exam Guide

1038
Many input/output (I/O) instructions are defined as privileged and can be executed
only by the operating system kernel processes. When a user program needs to interact
with any I/O activities, it must notify the system’s core privileged processes that work at
the inner rings of the system. These processes (called system services) authorize either
the user program processes to perform these actions and temporarily increase their
privileged state or the system’s processes are used to complete the request on behalf of
the user program. (Review Chapter 5 for a more in-depth understanding of these types
of system controls.)

Trusted Recovery
What if my application or system blows up?
Response: It should do so securely.
When an operating system or application crashes or freezes, it should not put the
system in any type of insecure state. The usual reason for a system crash in the first place
is that it encountered something it perceived as insecure or did not understand and decided it was safer to freeze, shut down, or reboot than to perform the current activity.
An operating system’s response to a type of failure can be classified as one of the
following:
• System reboot
• Emergency system restart
• System cold start
A system reboot takes place after the system shuts itself down in a controlled manner
in response to a kernel (trusted computing base) failure. If the system finds inconsistent
object data structures or if there is not enough space in some critical tables, a system
reboot may take place. This releases resources and returns the system to a more stable
and safer state.
An emergency system restart takes place after a system failure happens in an uncontrolled manner. This could be a kernel or media failure caused by lower-privileged user
processes attempting to access memory segments that are restricted. The system sees

this as an insecure activity that it cannot properly recover from without rebooting. The
kernel and user objects could be in an inconsistent state, and data could be lost or corrupted. The system thus goes into a maintenance mode and recovers from the actions
taken. Then it is brought back up in a consistent and stable state.
A system cold start takes place when an unexpected kernel or media failure happens
and the regular recovery procedure cannot recover the system to a more consistent state.
The system, kernel, and user objects may remain in an inconsistent state while the system attempts to recover itself, and intervention may be required by the user or administrator to restore the system.
It is important to ensure that the system does not enter an insecure state when it is
affected by any of these types of problems, and that it shuts down and recovers properly to a secure and stable state. (Refer to Chapter 5 for more information on TCB and
kernel components and activities.)


Chapter 12: Operations Security

1039
References
• Configuration Management Plans: The Beginning to Your CM Solution,
by Nadine M. Bounds and Susan Dart, Software Engineering Institute,
Carnegie Mellon University www.sei.cmu.edu/legacy/scm/papers/CM_Plans/
CMPlans.MasterToC.html
• Configuration Management Resources from the Georgia Institute of
Technology www.cc.gatech.edu/computing/classes/cs3302_98_spring/
handouts/cm-info.html

After a System Crash
When a system goes down, and they will, it is important that the operations personnel
know how to troubleshoot and fix the problem. The following are the proper steps that
should be taken:
1. Enter into single mode When a system cold start takes place, due to
the system’s inability to automatically recover itself to a secure state, the
administrator must be involved. The system will either automatically boot

up only so far as a “single user mode” or must be manually booted to a
“Recovery Console.” These are modes where the systems do not start services
for users or the network, file systems typically remain unmounted, and only
the local console is accessible. As a result, the administrator must either
physically be at the console, or have deployed external technology such as
secured dial-in/dial-back modems attached to serial console ports, or remote
Keyboard Video Mouse (KVM) switches attached to graphic consoles.
2. Fix issue and recover files In single user mode, the administrator salvages
file systems from damage which may have occurred as a result of the unclean
sudden shutdown of the system, and then attempts to identify the cause of the
shutdown to prevent it from recurring. Sometimes the administrator will also
have to roll back or roll forward databases or other applications in single user
mode. Other times, these will occur automatically when the administrator
brings the system out of single user mode, or will be performed manually
by the system administrator before applications and services return to their
normal state.
3. Validate critical files and operations If the investigation into the cause
of the sudden shutdown suggests corruption has occurred (for example,
through software or hardware failure, or user/administrator reconfiguration,
or some kind of attack), then the administrator must validate the contents
of configuration files and ensure system files (operating system program
files, shared library files, possibly application program files, and so on) are
consistent with their expected state. Cryptographic checksums of these files,
verified by programs such as Tripwire, can perform validations of system
files. The administrator must verify the contents of system configuration files
against the system documentation.


CISSP All-in-One Exam Guide

1040
Security Concerns
• Bootup sequence (C:, A:, D:) should not be available to reconfigure To
assure that systems recover to a secure state, the design of the system must
prevent an attacker from changing the bootup sequence of the system. For
example, on a Windows workstation or server, only authorized users should
have access to BIOS settings to allow the user to change the order in which
bootable devices are checked by the hardware. If the approved boot order is
C: (the main hard drive) only, with no other hard drives and no removable
(for example, floppy, CD/DVD, USB) devices allowed, then the hardware
settings must prohibit the user (and the attacker) from changing those device
selections and the order in which they are used. If the user or attacker can
change the bootable devices selections or order, and can cause the system to
reboot (which is always possible with physical access to a system), they can
boot their own media and attack the software and/or data on the system.
• Writing actions to system logs should not be able to be bypassed Through
separation of duties and access controls, system logs and system state files must
be preserved against attempts by users/attackers to hide their actions or change
the state to which the system will next restart. If any system configuration file can
be changed by an unauthorized user, and then the user can find a way to cause
the system to restart, the new—possibly insecure—configuration will take effect.
• System forced shutdown should not be allowed To reduce the possibility
of an unauthorized configuration change taking effect, and to reduce the
possibility of denial of service through an inappropriate shutdown, only
administrators should have the ability to instruct critical systems to shut down.
• Output should not be able to be rerouted Diagnostic output from a system
can contain sensitive information. The diagnostic log files, including console
output, must be protected by access controls from being read by anyone other
than authorized administrators. Unauthorized users must not be able to
redirect the destination of diagnostic logs and console output.

Input and Output Controls
Garbage in, garbage out.
What is input into an application has a direct correlation to what that application
outputs. Thus, input needs to be monitored for errors and suspicious activity. If a checker at a grocery store continually puts in the amount of $1.20 for each prime rib steak
customers buy, the store could eventually lose a good amount of money. This activity
could be done either by accident, which would require proper retraining, or on purpose, which would require disciplinary actions.
Because so many companies are extremely dependent upon computers and applications to process their data, input and output controls are very important. Chapter 10
addresses illegal activities that take place when users alter the data going into a program
or the output generated by a program, usually for financial gain.
The applications themselves also need to be programmed to only accept certain
types of values input into them and to do some type of logic checking about the re-


Chapter 12: Operations Security

1041
ceived input values. If an application requests the user input a mortgage value of a
property and the user enters 25 cents, the application should ask the user for the value
again so that wasted time and processing is not done on an erroneous input value. Also,
if an application has a field that holds only monetary values, a user should not be able
to enter “bob” in the field without the application barking. These and many more input
and output controls are discussed in Chapter 11.
All the controls mentioned in the previous sections must be in place and must continue to function in a predictable and secure fashion to ensure that the systems, applications, and the environment as a whole continue to be operational. Let’s look at a few
more issues that can cause problems if not dealt with properly.
• Online transactions must be recorded and timestamped.
• Data entered into a system should be in the correct format and validated to
ensure such data are not malicious.
• Ensure output reaches the proper destinations securely.
• A signed receipt should always be required before releasing sensitive output.

• A heading and trailing banner should indicate who the intended receiver is.
• Once output is created, it must have the proper access controls
implemented, no matter what its format (paper, digital, tape).
• If a report has no information (nothing to report), it should contain “no
output.”
Some people get confused by the last bullet item. The logical question would be, “If
there is nothing to report, why generate a report with no information.” Let’s say each
Friday you send me a report outlining that week’s security incidents and mitigation
steps. One Friday I receive no report. Instead of me having to go and chase you down
trying to figure out why you have not fulfilled that task, if I received a report that states
“no output,” I will be assured the task was indeed carried out and I don’t have to come
hit you with a stick.
Another type of input to a system could be ActiveX components, plug-ins, updated
configuration files, or device drivers. It is best if these are cryptographically signed by
the trusted authority before distribution. This allows the administrator manually, and/
or the system automatically, to validate that the files are from the trusted authority
(manufacturer, vendor, supplier) before the files are put into production on a system.
Microsoft Windows XP and Windows 2000 introduced Driver Signing, whereby the
operating system warns the user if a device driver that has not been signed by an entity
with a certificate from a trusted Certificate Authority is attempting to install. Windows
Mobile devices and newer Windows desktop operating systems, by default, will warn
when unsigned application software attempts to install. Note that the fact that an application installer or device driver is signed does not mean it is safe or reliable—it only
means the user has a high degree of assurance of the origin of the software or driver. If
the user does not trust the origin (the company or developer) that signed the software
or driver, or the software or driver is not signed at all, this should be a red flag that stops
the user from using the software or driver until its security and reliability can be confirmed by some other channel.


CISSP All-in-One Exam Guide

1042
System Hardening
I threw the server down a flight of steps. I think it is pretty hardened.
Response: Well, that should be good enough then.
A recurring theme in security is that controls may be generally described as being
physical, administrative, or technical. It has been said that if unauthorized physical access can be gained to a security-sensitive item, then the security of the item is virtually
impossible to assure. (This is why all data on portable devices should be encrypted.) In
other words, “If I can get to the console of the computer, I can own it.” It is likely obvious that the data center itself must be physically secured. We see guards, gates, fences,
barbed wire, lights, locked doors, and so on. This creates a strong physical security perimeter around the facilities where valuable information is stored.
Across the street from that data center is an office building in which hundreds or
thousands of employees sit day after day, accessing the valuable information from their
desktop PCs, laptops, and handheld devices over a variety of networks. Convergence of
data and voice may also have previously unlikely devices such as telephones plugged
into this same network infrastructure. In an ideal world, the applications and methods
by which the information is accessed would secure the information against any network attack; however, the world is not ideal, and it is the security professional’s responsibility to secure valuable information in the real world. Therefore, the physical
components which make up those networks through which the valuable information
flows also must be secured.
• Wiring closets should be locked.
• Network switches and hubs, when it is not practical to place them in locked
wiring closets, should be inside locked cabinets.
• Network ports in public places (for example, kiosk computers and even
telephones) should be made physically inaccessible.
Laptops, “thumb drives” (USB removable storage devices), portable hard drives,
mobile phones / PDAs, even MP3 players all can contain large amounts of information,
some of it sensitive and valuable. Users must know where these devices are at all times,
and store them securely when not actively in use. Laptops disappear from airport security checkpoints; thumb drives are tiny and get left behind and forgotten; and mobile
phones, PDAs, and MP3 players are stolen every day. So if physical security is in place,
do we really still need technical security? Yep.
An application that is not installed, or a system service that is not enabled, cannot
be attacked. Even a disabled system service may include vulnerable components which

an advanced attack could leverage, so it is better for unnecessary components to not
exist at all in the environment. Those components that cannot be left off of a system at
installation time, and cannot be practically removed due to the degree of integration
into a system, should be disabled so as to make them impractical for anyone except an
authorized system administrator to re-enable. Every installed application, and especially every operating service, must be part of the overall Configuration Management
database so vulnerabilities in these components may be tracked.
Components that can be neither left off nor disabled must be configured to the
most conservative practical setting that still allows the system to operate efficiently for


Chapter 12: Operations Security

1043
those business purposes which require the system’s presence in the environment. Database engines, for example, should run as a nonprivileged user, rather than as root or
SYSTEM. If a system will run multiple application services, each one should run under
its own user ID so a compromise to one service on the system does not grant access to
the other services on the system. Just as totally unnecessary services should be left off of
a system, unnecessary parts of a single service should be left uninstalled if possible, and
disabled otherwise. And for extra protection, wrap everything up with tin foil and duct
tape. Although aliens can travel thousands of light years in sophisticated space ships,
they can never get through tin foil.

Licensing Issues
Companies have the ethical obligation to use only legitimately purchased software applications. Software makers and their industry representation groups such
as the Business Software Alliance (BSA) use aggressive tactics to target companies
that use pirated (illegal) copies of software.
Companies are responsible for ensuring that software in the corporate environment is not pirated, and that the licenses (that is, license counts) are being abided
by. An operations or configuration management department is often where this capability is located in a company. Automated asset management systems, or more
general system management systems, may be able to report on the software installed
throughout an environment, including a count of installations of each. These counts

should be compared regularly (perhaps quarterly) against the inventory of licensed
applications and counts of licenses purchased for each application. Applications
that are found in the environment and for which no license is known to have been
purchased by the company, or applications found in excess of the number of licenses known to have been purchased, should be investigated. When applications
are found in the environment for which the authorized change control and supply
chain processes were not followed, they need to be brought under control, and the
business area that acquired the application outside of the approved processes must
be educated as to the legal and information security risks their actions may pose to
the company. Many times, the business unit manager would need to sign a document indicating he understands this risk and is personally accepting it. So if and
when things do blow up, we know exactly who to hit with a stick.
Applications for which no valid business need can be found should be removed, and the person who installed them should be educated and warned that
future such actions may result in more severe consequences—like a spanking.
Companies should have an acceptable use policy, which indicates what software users can install, and informs users that the environment will be surveyed
from time to time to verify compliance. Technical controls should be emplaced to
prevent unauthorized users from being able to install unauthorized software in
the environment.
Organizations that are using unlicensed products are often turned in by disgruntled employees as an act of revenge.


CISSP All-in-One Exam Guide

1044
NOTE

Locked down systems are referred to as bastion hosts.

Remote Access Security
I have my can that is connected to another can with a string. Can you put the other can up to
my computer monitor? I have work to do.
Remote access is a major component of normal operations, and a great enabler of

organizational resilience in the face of certain types of disasters. If a regional disaster
makes it impractical for large numbers of employees to commute to their usual work
site, but the data center—or a remote backup data center—remains operational, remote
access to computer resources can allow many functions of a company to continue almost as usual. Remote access can also be a way to reduce normal operational costs, by
reducing the amount of office space that must be owned or rented, furnished, cleaned,
cooled and heated, and provided with parking since employees will instead be working
from home. Remote access may also be the only way to enable a mobile workforce,
such as traveling salespeople, who need access to company information while in several different cities each week to meet with current and potential customers.
As with all things that enable business and bring value, remote access also brings
risks. Is the person logging in remotely who he claims to be? Is someone physically or
electronically looking over his shoulder, or tapping the communication line? Is the client device from which he is performing the remote access in a secure configuration, or
has it been compromised by spyware, Trojan horses, and other malicious code?
This has been a thorn in the side of security groups and operation departments for
basically every company. It is dangerous to allow computers to be able to directly connect
to the corporate network without knowing if they are properly patched, if the virus signatures are updated, if they are infected with malware, and so on. This has been a direct
channel used by many attackers to get to the heart of an organization’s environment. Because of this needed protection, vendors have been developing technology to quarantine
systems and ensure they are properly secured before access to corporate assets is allowed.

Remote Administration
To gain the benefits of remote access without taking on unacceptable risks, remote administration needs to take place securely. The following are just a few of
the guidelines to use.
• Commands and data should not take place in cleartext (that is, should
be encrypted). For example, SSH should be used, not Telnet.
• Truly critical systems should be administered locally instead of remotely.
• Only a small number of administrators should be able to carry out this
remote functionality.
• Strong authentication should be in place for any administration activities.
• Anyone who wears green shoes really should not be able to access these
systems. They are weird.

Chapter 12: Operations Security

1045

Configuration Management
The only thing that is constant is change.
Every company should have a policy indicating how changes take place within a
facility, who can make the changes, how the changes are approved, and how the
changes are documented and communicated to other employees. Without these policies in place, people can make changes that others do not know about and that have
not been approved, which can result in a confusing mess at the lowest end of the impact scale, and a complete breakdown of operations at the high end. Heavily regulated
industries such as finance, pharmaceuticals, and energy have very strict guidelines regarding what specifically can be done and at exactly what time and under which conditions. These guidelines are intended to avoid problems that could impact large
segments of the population or downstream partners. Without strict controls and
guidelines, vulnerabilities can be introduced into an environment. Tracking down and
reversing the changes after everything is done can be a very complicated and nearly
impossible task.
The changes can happen to network configurations, system parameters, applications, and settings when adding new technologies, application configurations, or devices, or when modifying the facility’s environmental systems. Change control is
important not only for an environment, but also for a product during its development
and life cycle. Changes must be effective and orderly, because time and money can be
wasted by continually making changes that do not meet an ultimate goal.
Some changes can cause a serious network disruption and affect systems’ availability. This means changes must be thought through, approved, and carried out in a
structured fashion. Backup plans may be necessary in case the change causes unforeseen negative effects. For example, if a facility is changing its power source, there
should be backup generators on hand in case the transition does not take place as
smoothly as planned. Or if a server is going to be replaced with a different server type,
interoperability issues could prevent users from accessing specific resources, so a
backup or redundant server should be in place to ensure availability and continued
productivity.

Change Control Process
A well-structured change management process should be put into place to aid staff

members through many different types of changes to the environment. This process
should be laid out in the change control policy. Although the types of changes vary, a
standard list of procedures can help keep the process under control and ensure it is carried out in a predictable manner. The following steps are examples of the types of procedures that should be part of any change control policy:
1. Request for a change to take place Requests should be presented to an
individual or group that is responsible for approving changes and overseeing
the activities of changes that take place within an environment.


CISSP All-in-One Exam Guide

1046
2. Approval of the change The individual requesting the change must justify
the reasons and clearly show the benefits and possible pitfalls of the change.
Sometimes the requester is asked to conduct more research and provide more
information before the change is approved.
3. Documentation of the change Once the change is approved, it should be
entered into a change log. The log should be updated as the process continues
toward completion.
4. Tested and presented The change must be fully tested to uncover any
unforeseen results. Depending on the severity of the change and the
company’s organization, the change and implementation may need to be
presented to a change control committee. This helps show different sides
to the purpose and outcome of the change and the possible ramifications.
5. Implementation Once the change is fully tested and approved, a schedule
should be developed that outlines the projected phases of the change being
implemented and the necessary milestones. These steps should be fully
documented and progress should be monitored.
6. Report change to management A full report summarizing the change
should be submitted to management. This report can be submitted on
a periodic basis to keep management up-to-date and ensure continual

support.
These steps, of course, usually apply to large changes that take place within a facility. These types of changes are typically expensive and can have lasting effects on a
company. However, smaller changes should also go through some type of change control process. If a server needs to have a patch applied, it is not good practice to have an
engineer just apply it without properly testing it on a nonproduction server, without
having the approval of the IT department manager or network administrator, and
without having backup and backout plans in place in case the patch causes some
negative effect on the production server. Of course, these changes need to be documented.
As stated previously, it is critical that the operations department create approved
backout plans before implementing changes to systems or the network. It is very common for changes to cause problems that were not properly identified before the implementation process began. Many network engineers have experienced the headaches of
applying poorly developed “fixes” or patches that end up breaking something else in
the system. To ensure productivity is not negatively affected by these issues, a backout
plan should be developed. This plan describes how the team will restore the system to
its original state before the change was implemented.


Chapter 12: Operations Security

1047

Change Control Documentation
Failing to document changes to systems and networks is only asking for trouble, because no one will remember, for example, what was done to that one server in the DMZ
six months ago or how the main router was fixed when it was acting up last year.
Changes to software configurations and network devices take place pretty often in most
environments, and keeping all of these details properly organized is impossible, unless
someone maintains a log of this type of activity.
Numerous changes can take place in a company, some of which are listed next:
• New computers installed
• New applications installed
• Different configurations implemented
• Patches and updates installed

• New technologies integrated
• Policies, procedures, and standards updated
• New regulations and requirements implemented
• Network or system problems identified and fixes implemented


CISSP All-in-One Exam Guide

1048
• Different network configuration implemented
• New networking devices integrated into the network
• Company acquired by, or merged with, another company
The list could go on and on and could be general or detailed. Many companies have
experienced some major problem that affects the network and employee productivity.
The IT department may run around trying to figure out the issue and go through hours
or days of trial-and-error exercises to find and apply the necessary fix. If no one properly documents the incident and what was done to fix the issue, the company may be
doomed to repeat the same scramble six months to a year down the road.

Media Controls
Media and devices that can be found in an operations environment require a variety of
controls to ensure they are properly preserved and that the integrity, confidentiality, and
availability of the data held on them are not compromised. For the purposes of this discussion, “media” may include both electronic (disk, CD/DVD, tape, Flash devices such as
USB “thumb drives,” and so on) and nonelectronic (paper) forms of information; and
media libraries may come into custody of media before, during, and/or after the information content of the media is entered into, processed on, and/or removed from systems.
The operational controls that pertain to these issues come in many flavors. The first
are controls that prevent unauthorized access (protect confidentiality), which as usual
can be physical, administrative, and technical. If the company’s backup tapes are to be
properly protected from unauthorized access, they must be stored in a place where only
authorized people have access to them, which could be in a locked server room or an
offsite facility. If media needs to be protected from environmental issues such as humidity, heat, cold, fire, and natural disasters (to maintain availability), the media

should be kept in a fireproof safe in a regulated environment or in an offsite facility
that controls the environment so it is hospitable to data processing components. These
issues are covered in detail in Chapter 6.
Companies may have a media library with a librarian in charge of protecting its resources. If so, most or all of the responsibilities described in this chapter for the protection of the confidentiality, integrity, and availability of media fall to the librarian. Users
may be required to check out specific types of media and resources from the library, instead of having the resources readily available for anyone to access them. This is common when the media library includes the distribution media for licensed software. It
provides an accounting (audit log) of uses of media, which can help in demonstrating
due diligence in complying with license agreements, and in protecting confidential information (such as personally identifiable information, financial/credit card information, protected health information) in media libraries containing those types of data.
Media should be clearly marked and logged, its integrity should be verified, and it
should be properly erased of data when no longer needed. After large investment is made
to secure a network and its components, a common mistake is for old computers along
with their hard drives and other magnetic storage media to be replaced, and the obsolete
equipment shipped out the back door along with all the data the company just spent so
much time and money securing. This puts the information on the obsolete equipment


Chapter 12: Operations Security

1049
and media at risk of disclosure, and violates legal, regulatory, and ethical obligations of
the company. Thus, the requirement of erasure is the end of the media life cycle.
When media is erased (cleared of its contents), it is said to be sanitized. In military /
government classified systems terms, this means erasing information so it is not readily
retrieved using routine operating system commands or commercially available forensic /
data recovery software. Clearing is acceptable when media will be reused in the same
physical environment for the same purposes (in the same compartment of compartmentalized information security) by people with the same access levels for that compartment.
“Purging” means making information unrecoverable even with extraordinary effort
such as physical forensics in a laboratory. Purging is required when media will be removed from the physical confines where the information on the media was allowed to
be accessed, or will be repurposed to a different compartment. Media can be sanitized
in several ways: zeroization (overwriting with a pattern designed to ensure that the data
formerly on the media are not practically recoverable), degaussing (magnetic scrambling of the patterns on a tape or disk that represent the information stored there), and

destruction (shredding, crushing, burning). Deleting files on a piece of media does not
actually make the data disappear; it only deletes the pointers to where the data in those
files still live on the media. This is how companies that specialize in restoration can
recover the deleted files intact after they have been apparently/accidentally destroyed.
Even simply overwriting media with new information may not eliminate the possibility of recovering the previously written information. This is why zeroization (see Figure
12-1) and secure overwriting algorithms are required. And, if any part of a piece of media containing highly sensitive information cannot be cleared or purged, then physical
destruction must take place.
Not all clearing/purging methods are applicable to all media—for example, optical
media is not susceptible to degaussing, and overwriting may not be effective against
Flash devices. The degree to which information may be recoverable by a sufficiently
motivated and capable adversary must not be underestimated or guessed at in ignoFigure 12-1
Zeroization
overwrites media
to protect sensitive
data.


CISSP All-in-One Exam Guide

1050
Atoms and Data
A device that performs degaussing generates a coercive magnetic force that reduces the magnetic flux density of the storage media to zero. This magnetic force
is what properly erases data from media. Data are stored on magnetic media by
the representation of the polarization of the atoms. Degaussing changes this polarization (magnetic alignment) by using a type of large magnet to bring it back
to its original flux (magnetic alignment).
rance. For the highest value commercial data, and for all data regulated by government
or military classification rules, read and follow the rules and standards.
Data remanence is the residual physical representation of information that was
saved and then erased in some fashion. This remanence may be enough to enable the
data to be reconstructed and restored to a readable form. This can pose a security threat

to a company that thinks it has properly erased confidential data from its media. If the
media is reassigned (object reuse), then an unauthorized individual could gain access to
your sensitive data.
If the media does not hold confidential or sensitive information, overwriting or
deleting the files may be the appropriate step to take. (Refer to Chapter 4 for further
discussion on these issues.)
The guiding principle for deciding what is the necessary method (and cost) of data
erasure is to ensure that the enemies’ cost of recovering the data exceeds the value of the
data. “Sink the company” (or “sink the country”) information has value so high that
the destruction of the media, which involves both the cost of the destruction and the
total loss of any potential reusable value of the media, is justified. For most other categories of information, multiple or simple overwriting is sufficient. Each company
must evaluate the value of its data and then choose the appropriate erasure/disposal
method.
Methods were discussed earlier for secure clearing, purging, and destruction of electronic media. Other forms of information, such as paper, microfilm, and microfiche,
also require secure disposal. “Dumpster diving” is the practice of searching through
trash at homes and businesses to find valuable information which was simply thrown
away, without being first securely destroyed through shredding or burning.
Media management, whether in a library or managed by other systems or individuals, has the following attributes and tasks:
• Tracking (audit logging) who has custody of each piece of media at any
given moment. This creates the same kind of audit trail as any audit logging
activity—to allow an investigation to determine where information was at any
given time, who had it, and, for particularly sensitive information, why they
accessed it. This enables an investigator to focus efforts on particular people,
places, and time, if a breach is suspected or known to have happened.
• Effectively implementing access controls to restrict who can access each
piece of media to only those people defined by the owner of the media /
information on the media, and to enforce the appropriate security measures
based on the classification of the media / information on the media.

Chapter 12: Operations Security

1051
Certain media, due to the physical type of the media, and/or the nature of the
information on the media, may require “special handling.” All personnel who
are authorized to access media must have training to ensure they understand
what is required of such media. An example of special handling for, say,
classified information may be that the media may only be removed from
the library or its usual storage place under physical guard, and even then
may not be removed from the building. Access controls will include physical
(locked doors, drawers, cabinets, or safes), technical (access and authorization
control of any automated system for retrieving contents of information in the
library), and administrative (the actual rules for who is supposed to do what
to each piece of information). Finally, the data may need to change format,
as in printing electronic data to paper. The data still needs to be protected at
the necessary level, no matter what format it is in. Procedures must include
how to continue to provide the appropriate protection. For example, sensitive
material that is to be mailed should be sent in a sealable inner envelope and
use only courier service.
• Tracking the number and location of backup versions (both onsite and
offsite). This is necessary to ensure proper disposal of information when
the information reaches the end of its lifespan; to account for the location
and accessibility of information during audits; and to find a backup copy
of information if the primary source of the information is lost or damaged.
• Documenting the history of changes to media. For example, when a particular
version of a software application kept in the library has been deemed obsolete,
this fact must be recorded so the obsolete version of the application is not
used unless that particular obsolete version is required. Even once no possible
need for the actual media or its content remains, retaining a log of the former
existence and the time and method of its deletion may be useful to demonstrate

due diligence.
• Ensuring environmental conditions do not endanger media. Each media type
may be susceptible to damage from one or more environmental influences.
For example, all media formats are susceptible to fire, and most are susceptible
to liquids, smoke, and dust. Magnetic media formats are susceptible to
strong magnetic fields. Magnetic and optical media formats are susceptible to
variations in temperature and humidity. A media library and any other space
where reference copies of information are stored must be physically built so
all types of media will be kept within their environmental parameters, and the
environment must be monitored to ensure conditions do not range outside of
those parameters. Media libraries are particularly useful when large amounts
of information must be stored and physically / environmentally protected, so
that the high cost of environmental control and media management may be
centralized in a small number of physical locations, and so that cost is spread
out over the large number of items stored in the library.
• Ensuring media integrity, by verifying on a media-type and environmentappropriate basis that each piece of media remains usable, and transferring