Assignment 1

CHAPTER

Domain 9: Operations security 10 EXAM OBJECTIVES IN THIS CHAPTER

• Administrative Security

• Sensitive Information/Media Security

• Asset Management

• Continuity of Operations

• Incident Response Management

UNIQUE TERMS AND DEFINITIONS • Collusion—An agreement between two or more individuals to subvert the secu-

rity of a system.

• Remanence—Data that might persist after removal attempts.

• Redundant Array of Inexpensive Disks (RAID)—A method of using multiple

disk drives to achieve greater data reliability, greater speed, or both.

• Mirroring—Complete duplication of data to another disk, used by some levels

of RAID.

• Striping—Spreading data writes across multiple disks to achieve performance

gains, used by some levels of RAID.

INTRODUCTION Operations Security is concerned with threats to a production operating environ-

ment. Threat agents can be internal or external actors, and operations security must

account for both of these threat sources in order to be effective. Ultimately opera-

tions security centers on the fact that people need appropriate access to data. This

data will exist on some particular media, and is accessible by means of a system.

So operations security is about people, data, media, hardware, and the threats asso-

ciated with each of these in a production environment.

CISSP® Study Guide. DOI: 10.1016/B978-1-59749-563-9.00010-X

© 2010 Elsevier, Inc. All rights reserved. 371

ADMINISTRATIVE SECURITY All organizations contain people, data, and means for people to use the data. A fun-

damental aspect of operations security is ensuring that controls are in place to inhibit

people either inadvertently or intentionally compromising the confidentiality, integ-

rity, or availability of data or the systems andmedia holding that data. Administrative

Security provides the means to control people’s operational access to data.

Administrative Personnel Controls Administrative Personnel Controls represent important operations security concepts

that should be mastered by the CISSP� candidate. These are fundamental concepts

within information security that permeate through multiple domains.

Least Privilege or Minimum Necessary Access One of the most important concepts in all of information security is that of the

principle of least privilege. The principle of least privilege dictates that persons

have no more than the access that is strictly required for the performance of their

duties. The principle of least privilege may also be referred to as the principle

of minimum necessary access. Regardless of name, adherence to this principle

is a fundamental tenet of security, and should serve as a starting point for

administrative security controls.

Although the principle of least privilege is applicable to organizations leveraging

Mandatory Access Control (MAC), the principle’s application is most obvious in

Discretionary Access Control (DAC) environments. With DAC, the principle of least

privilege suggests that a user will be given access to data if, and only if, a data owner

determines that a business need exists for the user to have the access. With MAC,

we have a further concept that helps to inform the principle of least privilege:

need to know.

Need to know In organizations with extremely sensitive information that leverage Mandatory

Access Control (MAC), basic determination of access is enforced by the system.

The access determination is based upon clearance levels of subjects and classifica-

tion levels of objects. Though the vetting process for someone accessing highly

sensitive information is stringent, clearance level alone is insufficient when dealing

with the most sensitive of information. An extension to the principle of least privi-

lege in MAC environments is the concept of compartmentalization.

Compartmentalization, a method for enforcing need to know, goes beyond the

mere reliance upon clearance level and necessitates simply that someone requires

access to information. Compartmentalization is best understood by considering a

highly sensitive military operation: while there may be a large number of indivi-

duals (some of high rank), only a subset “need to know” specific information.

The others have no “need to know,” and therefore no access.

372 CHAPTER 10 Domain 9: Operations security

Separation of Duties While the principle of least privilege is necessary for sound operational security, in

many cases it alone is not a sufficient administrative control. As an example, imag-

ine that an employee has been away from the office for training, and has submitted

an expense report indicating $1,000,000 was needed for reimbursement. This indi-

vidual happens to be a person who, as part of her daily duties, had access to print

reimbursement checks, and would therefore meet the principle of least privilege for

printing her own reimbursement check. Should she be able to print herself a nice

big $1,000,000 reimbursement check? While this access may be necessary for

her job function, and thus meet the requirements for the principle of least privilege,

additional controls are required.

The example above serves to illustrate the next administrative security control,

separation of duties. Separation of duties prescribes that multiple people are

required to complete critical or sensitive transactions. The goal of separation of

duties is to ensure that in order for someone to be able to abuse their access to sen-

sitive data or transactions; they must convince another party to act in concert. Col- lusion is the term used for the two parties conspiring to undermine the security of

the transaction. The classic action movie example of separation of duties involves

two keys, a nuclear sub, and a rogue captain.

LEARN BY EXAMPLE: SEPARATION OF DUTIES Separation of duties is a hard lesson to learn for many organizations, but many only needed to learn this lesson once. One such organization had a relatively small and fledgling security department that was created as a result of regulatory compliance mandates. Most of the other departments were fairly antagonistic toward this new department because it simply cobbled together various perceived security functions and was not mindfully built. The original intent was for the department to serve primarily in an advisory capacity regarding all things in security, and for the department not to have operational responsibilities regarding changes. The result meant that security ran a lot of vulnerability scans, and took these to operations for resolution. Often operations staff were busy with more pressing matters than patch installations, the absence of which posed little perceived threat.

Ultimately, because of their incessant nagging, the security department was given the, thankless if ever there was one, task of enterprise patch management for all but the most critical systems. Though this worked fine for a while, eventually, one of the security department staff realized that his performance review depended upon his timely remediation of missing patches, and, in addition to being the person that installed the patches, he was also the person that reported whether patches were missing. Further scrutiny was applied when management thought it odd that he reported significantly less missing patches than all of his security department colleagues. Upon review it was determined that though the employee had indeed acted unethically, it was beneficial in bringing the need for separation of duties to light. Though many departments have not had such an egregious breach of conduct, it is important to be mindful of those with audit capabilities also being operationally responsible for what they are auditing. The moral of the story: Quis custodiet ipsos custodes?1 Who watches the watchers?

373Administrative security

Rotation of Duties/Job Rotation Rotation of Duties, also known as job rotation or rotation of responsibilities, pro-

vides an organization with a means to help mitigate the risk associated with any

one individual having too many privileges. Rotation of duties simply requires that

critical functions or responsibilities are not continuously performed by the same

single person without interruption. There are multiple issues that rotation of duties

can help begin to address. One issue addressed by job rotation is the “hit by a

bus” scenario: imagine, morbid as it is, that any one individual in the organization

is hit by a bus on their way to work. If the operational impact of the loss of an

individual would be too great, then perhaps one way to assuage this impact would

be to ensure that there is additional depth of coverage for this individual’s

responsibilities.

Rotation of duties can also mitigate fraud. Over time some employees can

develop a sense of ownership and entitlement to the systems and applications they

work on. Unfortunately, this sense of ownership can lead to the employee’s finding

and exploiting a means of defrauding the company with little to no chance of

arousing suspicion. One of the best ways to detect this fraudulent behavior is to

require that responsibilities that could lead to fraud be frequently rotated amongst

multiple people. In addition to the increased detection capabilities, the fact that

responsibilities are routinely rotated itself deters fraud.

EXAM WARNING

Though job or responsibility rotation is an important control, this, like many other controls, is often compared against the cost of implementing the control. Many organizations will opt for not implementing rotation of duties because of the cost associated with implementation. For the exam, be certain to appreciate that cost is always a consideration, and can trump the implementation of some controls.

Mandatory Leave/Forced Vacation An additional operational control that is closely related to rotation of duties is that

of mandatory leave, also known as forced vacation. Though there are various jus-

tifications for requiring employees to be away from work, the primary security

considerations are similar to that addressed by rotation of duties; reducing or

detecting personnel single points of failure, and detection and deterrence of fraud.

Discovering a lack of depth in personnel with critical skills can help organizations

understand risks associated with employees unavailable for work due to unforeseen

circumstances. Forcing all employees to take leave can identify areas where depth

of coverage is lacking. Further, requiring employees to be away from work while it

is still operating can also help discover fraudulent or suspicious behavior. As stated

before, the sheer knowledge that mandatory leave is a possibility might deter some

individuals from engaging in the fraudulent behavior in the first place, because of

the increased likelihood of getting caught.

374 CHAPTER 10 Domain 9: Operations security

Non-Disclosure Agreement A non-disclosure agreement (NDA) is a work-related contractual agreement that

ensures that, prior to being given access to sensitive information or data, an indi-

vidual or organization appreciates their legal responsibility to maintain the confi-

dentiality of sensitive information. Non-disclosure agreements are often signed

by job candidates before they are hired, as well as consultants or contractors.

Non-disclosure agreements are largely a directive control.

NOTE

Though non-disclosure agreements are commonly now part of the employee orientation process, it is vitally important that all departments within an organization appreciate the need for non-disclosure agreements. This is especially important for organizations where it is commonplace for individual departments to engage with outside consultants and contractors.

Background Checks Background checks (also known as background investigations or preemployment

screening) are an additional administrative control commonly employed by many

organizations. The majority of background investigations are performed as part

of a preemployment screening process. Some organizations perform cursory back-

ground investigations that include a criminal record check. Others perform more

in-depth checks, such as verifying employment history, obtaining credit reports,

and in some cases requiring the submission of a drug screening.

The sensitivity of the position being filled or data to which the individual will

have access strongly determines the degree to which this information is scrutinized

and the depth to which the investigation will report. The overt purpose of these

preemployment background investigations is to ensure that persons who will be

employed have not exhibited behaviors that might suggest they cannot be trusted

with the responsibilities of the position. Ongoing, or postemployment, investiga-

tions seek to determine whether the individual continues to be worthy of the trust

required of their position. Background checks performed in advance of employ-

ment serve as a preventive control while ongoing repeat background checks consti-

tute a detective control and possibly a deterrent.

Privilege Monitoring The business needs of organizations require that some individuals have privileged

access to critical systems, or systems which contain sensitive data. These indivi-

duals’ heightened privileges require both greater scrutiny and more thoughtful con-

trols in order to ensure that the confidentiality, integrity, and availability remain

intact. Some of the job functions that warrant greater scrutiny include: account cre-

ation/modification/deletion, system reboots, data backup, data restoration, source

code access, audit log access, security configuration capabilities, etc.

375Administrative security

SENSITIVE INFORMATION/MEDIA SECURITY Though security and controls related to the people within an enterprise are vitally

important, so is having a regimented process for handling sensitive information,

including media security. This section discusses concepts that are an important

component of a strong overall information security posture.

Sensitive Information All organizations have sensitive information that requires protection, and that sen-

sitive information physically resides on some form of media. In addition to primary

storage, backup storage must also be considered. It is also likely that sensitive

information is transferred, whether internally or externally, for use. Wherever the

data exists, there must be processes that ensure the data is not destroyed or inacces-

sible (a breach of availability), disclosed, (a breach of confidentiality) or altered

(a breach of integrity).

Labeling/marking Perhaps the most important step in media security is the process of locating sensi-

tive information, and labeling or marking it as sensitive. How the data is labeled

should correspond to the organizational data classification scheme.

Handling People handling sensitive media should be trusted individuals who have been vetted

by the organization. They must understand their role in the organization’s informa-

tion security posture. Sensitive media should have strict policies regarding its

handling. Policies should require the inclusion of written logs detailing the person

responsible for the media. Historically, backup media has posed a significant

problem for organizations.

Storage When storing sensitive information, it is preferable to encrypt the data. Encryption

of data at rest greatly reduces the likelihood of the data being disclosed in an un-

authorized fashion due to media security issues. Physical storage of the media

containing sensitive information should not be performed in a haphazard fashion,

whether the data is encrypted or not. Care should be taken to ensure that there

are strong physical security controls wherever media containing sensitive informa-

tion is accessible.

Retention Media and information have a limited useful life. Retention of sensitive informa-

tion should not persist beyond the period of usefulness or legal requirement

376 CHAPTER 10 Domain 9: Operations security

(whichever is greater), as it needlessly exposes the data to threats of disclosure

when the data is no longer needed by the organization. Keep in mind there may

be regulatory or other legal reasons that may compel the organization to maintain

such data for keeping data beyond its time of utility.

Media Sanitization or Destruction of Data It is time to destroy data or the associated media once an organization has identi-

fied that it no longer requires retention from an operations or legal perspective.

While some data might not be sensitive and not warrant thorough data destruction

measures, an organization will have data that must be verifiably destroyed, or

otherwise rendered nonusable in case the media on which it was housed is recov-

ered by a third party. The process for sanitization of media or destruction of data

varies directly with the type of media and sensitivity of data.

NOTE

The concepts of data destruction and data remanence are also referenced as part of Chapter 5, Domain 4: Physical (Environmental) Security. As is often the case with the CISSP�, some content easily falls within multiple domains, and might deserve coverage in both sections, as is the case here.

Data Remanence The term data remanence is important to understand when discussing media sani-

tization and data destruction. Data remanence is data that persists beyond noninva-

sive means to delete it. Though data remanence is sometimes used specifically to

refer to residual data that persists on magnetic storage, remanence concerns go

beyond just that of magnetic storage media. Security professionals must understand

and appreciate the steps to make data unrecoverable.

Wiping, overwriting, or shredding File deletion is an important concept for security professionals to understand. In

most file systems, if a user deletes a file, the file system merely removes metadata

pointers or references to the file. The file allocation table references are removed,

but the file data itself remains. Significant amounts of “deleted data” may be

recovered (“undeleted”); forensic tools are readily available to do so. Reformatting

a file system may also leave data intact.

Though simple deletion of files or reformatting of hard disks is not sufficient to

render data unrecoverable, files may be securely wiped or overwritten. Wiping, also called overwriting or shredding, writes new data over each bit or block of file

data. One of the shortcomings of wiping is when hard disks become physically

damaged, preventing the successful overwriting of all data. An attacker with means

and motive could attempt advanced recovery of the hard disks if there was signifi-

cant perceived value associated with the media.

377Sensitive information/media security

NOTE

For many years security professionals and other technologists accepted that data could theoretically be recovered even after having been overwritten. Though the suggested means of recovery involved both a clean room and an electron microscope, which is likely beyond the means of most would be attackers, organizations typically employed either what has been referred to as the DoD (Department of Defense) short method, DoD standard method or Gutmann approach2 to wiping, which involved either 3, 7, or 35 successive passes, respectively. Now it is commonly considered acceptable in industry to have simply a single successful pass to render data unrecoverable. This has saved organizations many hours that were wasted on unnecessary repeat wipes.

Degaussing By introducing an external magnetic field through use of a degausser, the data on

magnetic storage media can be made unrecoverable. Magnetic storage media

depends upon the magnetization of the media being static unless intentionally

changed by the storage media device. A degausser destroys the integrity of the

magnetization of the storage media, making the data unrecoverable.

Physical Destruction Physical destruction, when carried out properly, is considered the most secure

means of media sanitization. One of the reasons for the higher degree of assurance

is because of the greater likelihood of errors resulting in data remanence with wip-

ing or degaussing. Physical destruction is certainly warranted for the most sensitive

of data. Common means of destruction include incineration and pulverization.

Shredding A simple form of media sanitization is shredding, a type of physical destruction.

Though this term is sometimes used in relation to overwriting of data, here shred-

ding refers to the process of making data printed on hard copy, or on smaller

objects such as floppy or optical disks, unrecoverable. Sensitive information such

as printed information needs to be shredded prior to disposal in order to thwart a

dumpster diving attack. Dumpster diving is a physical attack in which a person

recovers trash in hopes of finding sensitive information that has been merely dis-

carded in whole rather than being run through a shredder, incinerated, or otherwise

destroyed. Figure 10.1 shows locked shred bins that contain material that is

intended for shredding. The locks are intended to ensure that dumpster diving is

not possible during the period prior to shredding.

ASSET MANAGEMENT A holistic approach to operational information security requires organizations to

focus on systems as well as the people, data, and media. Systems security is

another vital component to operational security, and there are specific controls that

can greatly help system security throughout the system’s lifecycle.

378 CHAPTER 10 Domain 9: Operations security

Configuration Management One of the most important components of any systems security work is the develop-

ment of a consistent system security configuration that can be leveraged throughout

the organization. The goal is to move beyond the default system configuration to

one that is both hardened and meets the operational requirements of the organization.

One of the best ways to protect an environment against future zero-day attacks

(attacks against vulnerabilities with no patch or fix) is to have a hardened system that

only provides the functionality strictly required by the organization.

Development of a security-oriented baseline configuration is a time consuming

process due to the significant amount of research and testing involved. However,

once an organizational security baseline is adopted, then the benefits of having a

known, hardened, consistent configuration will greatly increase system security

for an extended period of time. Further, organizations do not need to start from

scratch with their security baseline development, as different entities provide guid-

ance on baseline security. These predefined baseline security configurations might

come from the vendor who created the device or software, government agencies, or

also the nonprofit Center for Internet Security (see: http://www.cisecurity.org/).

Basic configuration management practices associated with system security will

involve tasks such as: disabling unnecessary services, removing extraneous pro-

grams, enabling security capabilities such as firewalls, antivirus, and intrusion

detection or prevention systems, and the configuration of security and audit logs.

FIGURE 10.1

Locked shred bins.

Source: http://commons.wikimedia.org/wiki/File:Confidential_shred_bins.JPG. Photograph by:

# BrokenSphere/Wikimedia Commons. Image under permission of Creative Commons Attribution ShareAlike 3.0

379Asset management

Baselining Standardizing on a security configuration is certainly important, but there is an

additional consideration with respect to security baselines. Security baselining is

the process of capturing a point in time understanding of the current system secu-

rity configuration. Establishing an easy means for capturing the current system

security configuration, can be extremely helpful in responding to a potential secu-

rity incident. Assuming that the system or device in question was built from a stan-

dardized security baseline, and also that strong change control measures (see

Change Management section below) are adhered to, then there would be little need

to capture the current security configuration. However, in the real world, unautho-

rized changes can and will occur in even the most strictly controlled environment,

which necessitates the monitoring of a system’s security configuration over time.

Further, even authorized system modifications that adhere to the change manage-

ment procedures need to be understood and easily captured. Another reason to

emphasize continual baselining is because there may be systems that were not orig-

inally built to an initial security baseline. A common mistake that organizations

make regarding system security is focusing on establishing a strong system secu-

rity configuration, but failing to quickly and easily appreciate the changes to a sys-

tem’s security configuration over time.

Patch Management One of the most basic, yet still rather difficult, tasks associated with maintaining

strong system security configuration is patch management, the process of manag-

ing software updates. All softwares have flaws or shortcomings that are not fully

addressed in advance of being released. The common approach to fixing software

is by applying patches to address known issues. Not all patches are concerned with

security; many are associated with simple nonsecurity related bug fixes. However,

security patches do represent a significant piece of the overall patch pie. Software

vendors announce patches both publicly and directly to their customers. Once noti-

fied of a patch, organizations need to evaluate the patch from a risk management per-

spective to determine how aggressively the patch will need to be deployed. Testing

is typically required to determine whether any adverse outcomes are likely to

result from the patch installation. From a timeline standpoint, testing often occurs

concomitantly with the risk evaluation. Installation is the final phase of the patch

management process, assuming adverse effects do not require remediation.

While the process of installing a single patch from a single vendor on a single

system might not seem that onerous, managing the identification, testing, and instal-

lation of security patches from dozens of vendors across thousands of systems can

become extremely cumbersome. Also, the degree to which patch installations can

be centrally deployed or automated varies quite a bit amongst vendors. A relatively

recent change in the threat landscape has made patch management even more diffi-

cult; attackers increasingly are focused on targeting clients rather than server based

systems. With attackers emphasizing client side applications such as browsers, and

their associated plugins, extensions, and frameworks, office suites, and PDF readers,

the patch management landscape is rapidly growing in complexity.

380 CHAPTER 10 Domain 9: Operations security

Vulnerability Management Security patches are typically intended to eliminate a known vulnerability. Organi-

zations are constantly patching desktops, servers, network devices, telephony

devices and other information systems. The likelihood of an organization having

fully patched every system is low. While un-patched systems may be known, it

is also common to have systems which were thought to have been patched which

were not. It is even more common an occurrence to find systems in need of an

unknown patch. Vulnerability scanning is a way to discover poor configurations

and missing patches in an environment. While it might seem obvious, it bears men-

tioning that vulnerability scanning devices are only capable of discovering the exis-

tence of known vulnerabilities. Though discovering missing patches is the most

significant feature provided by vulnerability scanning devices or software, some

are also capable of discovering vulnerabilities associated with poor configurations.

The term vulnerability management is used rather than just vulnerability scan-

ning to emphasize the need for management of the vulnerability information. Many

organizations are initially a bit overzealous with their vulnerability scanning and

want to continuously enumerate all vulnerabilities within the enterprise. There is

limited value in simply listing thousands of vulnerabilities unless there is also a

process that attends to the prioritization and remediation of these vulnerabilities.

The remediation or mitigation of vulnerabilities should be prioritized based on both

risk to the organization and ease of remediation procedures.

Zero-Day Vulnerabilities and Zero-Day Exploits Organizations intend to patch vulnerabilities before they are exploited by an

attacker. As patches are released, attackers begin trying to reverse engineer

exploits for the now-known patched vulnerability. This process of developing an

exploit to fit a patched vulnerability has been occurring for quite some time, but

what is changing is the typical time-to-development of an exploit. The average

window of time between a patch being released and an associated exploit being

made public is decreasing. Recent research even suggests that for some vulnerabil-

ities, an exploit can be created within minutes based simply on the availability of

the unpatched and patched program3.

In addition to attackers reverse engineering security patches to develop exploits, it

is also possible for an attacker to discover a vulnerability before the vendor has devel-

oped a patch, or has been made aware of the vulnerability either by internal or external

security researchers. The term for a vulnerability being known before the existence of

a patch is zero day vulnerability. Zero-day vulnerabilities, also commonly written 0-

day, are becoming increasingly important as attackers are becoming more skilled in

discovery, and, more importantly, the discovery and disclosure of zero day vulnerabil-

ities is being monetized. A zero-day exploit, rather than vulnerability, refers to the

existence of exploit code for a vulnerability which has yet to be patched.

Change Management As stated above, system, network, and application changes are required. A system

that does not change will become less secure over time, as security updates and

381Asset management

patches are not applied. In order to maintain consistent and known operational

security, a regimented change management or change control process needs to

be followed. The purpose of the change control process is to understand, commu-

nicate, and document any changes with the primary goal of being able to under-

stand, control, and avoid direct or indirect negative impact that the change might

impose. The overall change management process has phases, the implementation

of which will vary to some degree within each organization. Typically there is a

change control board that oversees and coordinates the change control process.

In smaller organizations, the change control board might be a much less formal

group than is found in larger organizations, sometimes even consisting of just

one or two individuals.

The intended change must first be introduced or proposed to the change control

board. The change control board then gathers and documents sufficient details

about the change to attempt to understand the implications. The person or group

proposing the change should attempt to supply information about any potential

negative impacts that might result from the change, as well as any negative impacts

that could result from not implementing the change. Ultimately, the decision to

implement the change, and the timeliness of this implementation, will be driven

by principles of risk and cost management. Therefore, details related to the organi-

zational risk associated with both enacting or delaying the change must be brought

to the attention of the change control board. Another risk-based consideration is

whether or not the change can be easily reversed should unforeseen impacts be

greater than anticipated. Many organizations will require a rollback plan, which

is sometimes also known as a backout plan. This plan will attempt to detail the pro-

cedures for reversing the change should that be deemed necessary.

If the change control board finds that the change is warranted, then a schedule

for testing and implementing the change will be agreed upon. The schedule should

take into account other changes and projects impacting the organization and its

resources. Associated with the scheduling of the change implementation is the

notification process that informs all departments impacted by the change. The next

phase of the change management process will involve the testing and subsequent

implementation of the change. Once implemented, a report should be provided

back to the change control board detailing the implementation, and whether or

not the change was successfully implemented according to plan.

Change management is not an exact science, nor is the prescribed approach a

perfect fit for either all organizations or all changes. In addition to each organiza-

tion having a slightly different take on the change management process, there will

also likely be particular changes that warrant deviation from the organizational

norm either because the change is more or less significant than typical changes.

For instance, managing the change associated with a small patch could well be

handled differently than a major service pack installation. Because of the variabil-

ity of the change management process, specific named phases have not been

offered in this section. However, the general flow of the change management

process includes:

382 CHAPTER 10 Domain 9: Operations security

• Identifying a change

• Proposing a change

• Assessing the risk associated with the change

• Testing the change

• Scheduling the change

• Notifying impacted parties of the change

• Implementing the change

• Reporting results of the change implementation

All changes must be closely tracked and auditable. A detailed change record

should be kept. Some changes can destabilize systems or cause other problems;

change management auditing allows operations staff to investigate recent changes

in the event of an outage or problem. Audit records also allow auditors to verify

that change management policies and procedures have been followed.

CONTINUITY OF OPERATIONS Although some continuity concepts have already been covered in Chapter 7:

Domain 6: Business Continuity and Disaster Recovery Planning, this section will

focus on more overtly operational concerns related to continuity. Needless to

say, continuity of operations is principally concerned with the availability portion

of the confidentiality, integrity, availability triad.

Service Level Agreements (SLA) As organizations leverage service providers and hosted solutions to a greater extent,

the continuity of operations consideration become critical in contract negotiation such

as service level agreements. Service level agreements have been important for some

time, but they are becoming increasingly critical as organizations are increasingly

choosing to have external entities perform critical services or host significant assets

and applications. The goal of the service level agreement is to stipulate all expecta-

tions regarding the behavior of the department or organization that is responsible for

providing services and the quality of the services provided. Often service level agree-

ments will dictate what is considered acceptable regarding things such as bandwidth,

time to delivery, response times, etc.

Though availability is usually the most critical security consideration of a service

level agreement, the consideration of other security aspects will increase as they become

easier to quantify through better metrics. Further, as organizations increasingly leverage

hosting service providers for more than just commoditized connectivity, the degree to

which security is emphasized will increase. One important point to realize about service

level agreements is that it is paramount that organizations negotiate all security terms of

a service level agreement with their service prior to engaging with the company. Typi-

cally, if an organization wants a service provider to agree after the fact to specific terms

of a service level agreement, then the organization will be required to pay an additional

premium for the service.

383Continuity of operations

NOTE

The most obvious example of a trend toward increasingly critical information and services being hosted by a service provider is that of the growing popularity of cloud computing. Cloud computing allows for organizations to effectively rent computing speed, storage, and bandwidth from a service provider for the hosting of some of their infrastructure. Security and quality of service of these solutions constitutes an extremely important point of distinction between the service offerings and their associated costs. Though not overtly testable for the CISSP�, cloud computing is becoming an important concept for security professionals to appreciate.

Fault Tolerance In order for systems and solutions within an organization to be able to continually

provide operational availability they must be implemented with fault tolerance in

mind. Availability is not solely focused on system uptime requirements, but also

requires that data be accessible in a timely fashion as well. Both system and data

fault tolerance will be attended to within this section.

Backup The most basic and obvious measure to increase system or data fault tolerance is to

provide for recoverability in the event of a failure. Given a long enough timeframe

accidents, such as that in Figure 10.2, will happen. In order for data to be able to be

recovered in case of a fault some form of backup or redundancy must be provided.

Though magnetic tape media is quite an old technology, it is still the most common

FIGURE 10.2

Why are backups necessary?

Source: http://commons.wikimedia.org/wiki/File:Backup_Backup_Backup_-_And_Test_Restores.jpg.

Photograph by: John Boston. Image used under Creative Commons Attribution 2.0 License.

384 CHAPTER 10 Domain 9: Operations security

repository of backup data. Three basic types of backups exist: full backup; the incremental backup; and the differential backup.

Full The full backup is the easiest to understand of the types of backup; it simply is a

replica of all allocated data on a hard disk. Full backups contain all of the allocated

data on the hard disk, which makes them simple from a recovery standpoint in the

event of a failure. Though the time and media necessary to recover are less for full

backups than those approaches that employ other methods, the amount of media

required to hold full backups is greater. Another downside of using only full back-

ups is the time it takes to perform the backup itself. The time required to complete

a backup must be within the backup window, which is the planned period of time

in which backups are considered operationally acceptable. Because of the larger

amount of media, and therefore cost of media, and the longer backup window

requirements, full backups are often coupled with either incremental or differential

backups to balance the time and media considerations.

Incremental One alternative to exclusively relying upon full backups is to leverage incremental

backups. Incremental backups only archive files that have changed since the last

backup of any kind was performed. Since fewer files are backed up, the time to

perform the incremental backup is greatly reduced. To understand the tape require-

ments for recovery, consider an example backup schedule using tapes, with weekly

full backups on Sunday night and daily incremental backups.

Each Sunday, a full backup is performed. For Monday’s incremental backup,

only those files which have been changed since Sunday’s backup will be marked

for backup. On Tuesday, those files which have been changed since Monday’s

incremental backup will be marked for backup. Wednesday, Thursday, Friday,

and Saturday would all simply perform a backup of those files that had changed

since the previous incremental backup.

Given this schedule, if a data or disk failure occurs and there is a need for

recovery, then the most recent full backup and each and every incremental backup

since the full backup is required to initiate a recovery. Though the time to perform

each incremental backup is extremely short, the downside is that a full restore can

require quite a few tapes, especially if full backups are performed less frequently.

Also, the odds of a failed restoration due to a tape integrity issue (such as broken

tape) rise with each additional tape required.

Differential Another approach to data backup is the differential backup method. While the

incremental backup only archived those files that had changed since any backup,

the differential method will back up any files that have been changed since the last

full backup. The following is an example of a backup schedule using tapes, with

weekly full backups on Sunday night and daily differential backups.

385Continuity of operations

Each Sunday, a full backup is performed. For Monday’s differential backup,

only those files which have been changed since Sunday’s backup will be archived.

On Tuesday, again those files which have been changed since Sunday’s full

backup, including those backed up with Monday’s differential, will be archived.

Wednesday, Thursday, Friday, and Saturday would all simply archive all files that

had changed since the previous full backup.

Given this schedule, if a data or disk failure occurs and there is a need for

recovery, then only the most recent full backup and most recent differential backup

are required to initiate a full recovery. Though the time to perform each differential

backup is shorter than a full backup, as more time passes since the last full backup

the length of time to perform a differential backup will also increase. If much of

the data being backed up regularly changes or the time between full backups is

long, then the length of time for a backup might approach that of the full backup.

Redundant Array of Inexpensive Disks (RAID) Even if only one full backup tape is needed for recovery of a system due to a hard

disk failure, the time to recover a large amount of data can easily exceed the recov-

ery time dictated by the organization. The goal of a Redundant Array Inexpensive Disks (RAID) is to help mitigate the risk associated with hard disk failures. There

are various RAID levels that consist of different approaches to disk array config-

urations. These differences in configuration have varying cost, in terms of number

of disks lost to achieve the configuration’s goals, and capabilities in terms of reli-

ability and performance advantages. Table 10.1 provides a brief description of the

various RAID levels that are most commonly used.

Three terms that are important to understand with respect to RAID are: mirror-

ing; striping; and parity.

• Mirroring is the most obvious and basic of the fundamental RAID concepts,

and is simply used to achieve full data redundancy by writing the same data

to multiple hard disks. Since mirrored data must be written to multiple disks

the write times are slower. However, there can be performance gains when

reading mirrored data by simultaneously pulling data from multiple hard disks.

Other than read and write performance considerations, a major cost associated

Table 10.1 RAID Levels

RAID Level Description

RAID 0 Striped set

RAID 1 Mirrored set

RAID 3 Byte level striping with dedicated parity

RAID 4 Block level striping with dedicated parity

RAID 5 Block level striping with distributed parity

RAID 6 Block level striping with double distributed parity

386 CHAPTER 10 Domain 9: Operations security

with mirroring is disk usage; at least half of the drives are used for redundancy

when mirroring is used.

• Striping is a RAID concept that is focused on increasing the read and write per-

formance by spreading data across multiple hard disks. With data being spread

amongst multiple disk drives, reads and writes can be performed in parallel

across multiple disks rather than serially on one disk. This parallelization pro-

vides a performance increase, and does not aid in data redundancy. The final

concept is parity.

• Parity is a means to achieve data redundancy without incurring the same degree

of cost as that of mirroring in terms of disk usage and write performance.

EXAM WARNING

While the ability to quickly recover from a disk failure is the goal of RAID there are configurations that do not have reliability as a capability. For the exam, be sure to understand that not all RAID configurations provide additional reliability.

RAID 0: Striped Set As is suggested by the title, RAID 0 employs striping to increase the performance

of read and writes. By itself, striping offers no data redundancy so RAID 0 is a

poor choice if recovery of data is the reason for leveraging RAID. Figure 10.3

shows visually what RAID 0 entails.

RAID 1: Mirrored Set This level of RAID is perhaps the simplest of all RAID levels to understand. RAID 1 creates/writes an exact duplicate of all data to an additional disk. The write per-

formance is decreased, though the read performance can see an increase. Disk cost

is one of the most troubling aspects of this level of RAID, as at least half of all

disks are dedicated to redundancy. Figure 10.4 shows RAID 1 visually.

A

C

E

G

B

D

F

H

RAID 0

FIGURE 10.3

RAID 0—Striped Set.

387Continuity of operations

RAID 2: Hamming Code RAID 2 is not considered commercially viable for hard disks and is not used. This

level of RAID would require either 14 or 39 hard disks and a specially designed

hardware controller, which makes RAID 2 incredibly cost prohibitive. RAID 2 is

not likely to be tested.

RAID 3: Striped Set with Dedicated Parity (byte level) Striping is desirable due to the performance gains associated with spreading data

across multiple disks. However, striping alone is not as desirable due to the lack

of redundancy. With RAID 3 data, at the byte level, is striped across multiple disks,

but an additional disk is leveraged for storage of parity information, which is used

for recovery in the event of a failure.

RAID 4: Striped Set with Dedicated Parity (block level) RAID 4 provides the exact same configuration and functionality as that of RAID 3,

but stripes data at the block, rather than byte, level. Like RAID 3, RAID 4 employs

a dedicated parity drive rather than having parity data distributed amongst all disks,

as in RAID 5.

RAID 5: Striped Set with Distributed Parity One of the most popular RAID configurations is that of RAID 5, Striped Set with

Distributed Parity. Again with RAID 5 there is a focus on striping for the performance

increase it offers, and RAID 5 leverages a block level striping. Like RAIDs 3 and 4,

RAID 5writes parity information that is used for recovery purposes. However, unlike

RAIDs 3 and 4, which require a dedicated disk for parity information, RAID 5 distri-

butes the parity information across multiple disks. One of the reasons for RAID 5’s

popularity is that the disk cost for redundancy is lower than that of a Mirrored set.

Another important reason for this level’s popularity is the support for both hardware

and software based implementations, which significantly reduces the barrier to entry

A

B

C

D

A

B

C

D

RAID 1

FIGURE 10.4

RAID 1—Mirrored Set.

388 CHAPTER 10 Domain 9: Operations security

for RAID configurations. RAID 5 allows for data recovery in the event that any one

disk fails. Figure 10.5 provides a visual representation of RAID 5.

RAID 6: Striped Set with Dual Distributed Parity While RAID 5 accommodates the loss of any one drive in the array, RAID 6 can

allow for the failure of two drives and still function. This redundancy is achieved

by writing the same parity information to two different disks.

NOTE

There are many and varied RAID configurations which are simply combinations of the standard RAID levels. Nested RAID solutions are becoming increasingly common with larger arrays of disks that require a high degree of both reliability and speed. Some common nested RAID levels include RAID 0þ1, 1þ0, 5þ0, 6þ0, and (1þ0)þ0, which are also commonly written as RAID 01, 10, 50, 60, and 100, respectively.

RAID 1þ0 or RAID 10 RAID 1þ0 or RAID 10 is an example of what is known as nested RAID or multi-

RAID, which simply means that one standard RAID level is encapsulated within

another. With RAID 10, which is also commonly written as RAID 1þ0 to explic-

itly indicate the nesting, the configuration is that of a striped set of mirrors.

System Redundancy Though redundancy and resiliency of data, provided by RAID and backup solu-

tions, is important, further consideration needs to be given to the systems them-

selves that provide access to this redundant data.

Redundant Hardware Many systems can provide internal hardware redundancy of components that are

extremely prone to failure. The most common example of this in-built redundancy

A1

A2

1 Parity

C2

C3

RAID 5

3 Parity

B1

2 Parity

B3

FIGURE 10.5

RAID 5—Striped Set with Distributed Parity.

389Continuity of operations

is systems or devices which have redundant onboard power in the event of a power

supply failure. In addition to redundant power, it is also common to find redundant

network interface cards (NICs), as well as redundant disk controllers. Sometimes

systems simply have field replaceable modular versions of commonly failing com-

ponents. Though physically replacing a power supply might increase downtime,

having an inventory of spare modules to service the entire datacenter’s servers

would be less expensive than having all servers configured with an installed redun-

dant power supply.

Redundant Systems Though quite a few fault-prone internal components can be configured to have

redundancy built into systems, there is a limit to the internal redundancy. If system

availability is extremely important, then it might be prudent to have entire systems

available in the inventory to serve as a means to recover. While the time to recover

might be greater, it is fairly common for organizations to have an SLA with their

hardware manufacturers to be able to quickly procure replacement equipment in a

timely fashion. If the recovery times are acceptable, then quick procurement

options are likely to be far cheaper than having spare equipment on-hand for ad

hoc system recovery.

High-Availability Clusters Some applications and systems are so critical that they have more stringent uptime

requirements than can be met by standby redundant systems, or spare hardware.

These systems and applications typically require what is commonly referred to

as a high-availability (HA) or failover cluster. A high-availability cluster employs

multiple systems that are already installed, configured, and plugged in, such that if

a failure causes one of the systems to fail then the other can be seamlessly lever-

aged to maintain the availability of the service or application being provided.

The actual implementation details of a high-availability cluster can vary quite a

lot, but there are a few basic considerations that need to be understood. The primary

implementation consideration for high-availability clusters is whether each node of

a HA cluster is actively processing data in advance of a failure. This is known as an

active-active configuration, and is commonly referred to as load balancing. Having

systems in an active-active, or load balancing, configuration is typically more costly

than having the systems in an active-passive, or hot standby, configuration in which the backup systems only begin processing when a failure state is detected.

INCIDENT RESPONSE MANAGEMENT Although this chapter has provided many operational security measures that would

aid in the prevention of a security incident, these measures will only serve to

decrease the likelihood and frequency with which security incidents are experi-

enced. All organizations will experience security incidents, about this fact there

is little doubt. Because of the certainty of security incidents eventually impacting

390 CHAPTER 10 Domain 9: Operations security

organizations, there is a great need to be equipped with a regimented and tested

methodology for identifying and responding to these incidents.

We will first define some basic terms associated with incident response. To be

able to determine whether an incident has occurred or is occurring, security events

are reviewed. Events are any observable data associated with systems or networks.

A security incident exists if the events suggest that violation of an organization’s

security posture has or is likely to occur. Security incidents can run the gamut from

a basic policy violation to an insider exfiltrating millions of credit card numbers.

Incident handling or incident response are the terms most commonly associated

with how an organization proceeds to identify, react, and recover from security

incidents. Finally, a Computer Security Incident Response Team (CSIRT) is a term used for the group that is tasked with monitoring, identifying, and responding to

security incidents. The overall goal of the incident response plan is to allow the

organization to control the cost and damage associated with incidents, and to make

the recovery of impacted systems quicker.

Methodology Different books and organizations may use different terms and phases associated

with incident response; this section will mirror the terms associated with the exam-

ination. Though each organization will indeed have a slightly different understand-

ing of the phases of incident response, the general tasks performed will likely be

quite similar among most organizations.

Detection One of the most important steps in the incident response process is the detection phase. Detection is the phase in which events are analyzed in order to determine

whether these events might comprise a security incident. Without strong detective

capabilities built into the information systems, the organization has little hope of

being able to effectively respond to information security incidents in a timely fashion.

Organizations should have a regimented and, preferably, automated fashion for pull-

ing events from systems and bringing those events into the wider organizational con-

text. Often when events on a particular system are analyzed independently and out of

context, then an actual incident might easily be overlooked. However, with the

benefit of seeing those same system logs in the context of the larger organization pat-

terns indicative of an incident might be noticed. An important aspect of this phase of

incident response is that during the detection phase it is determined made as to

whether an incident is actually occurring or has occurred. It is a rather common

occurrence for potential incidents to be deemed strange, but innocuous after further

review.

Containment The containment phase of incident response is the point at which the incident

response team attempts to keep further damage from occurring as a result of the

incident. Containment might include taking a system off the network, isolating

391Incident response management

traffic, powering off the system, or other items to control both the scope and sever-

ity of the incident. This phase is also typically where a binary (bit by bit) forensic

backup is made of systems involved in the incident. An important trend to under-

stand is that most organizations will now capture volatile data before pulling the

power plug on a system.

Eradication The eradication phase involves the process of understanding the cause of the inci-

dent so that the system can be reliably cleaned and ultimately restored to opera-

tional status later in the recovery phase. In order for an organization to be able

to reliably recover from an incident, the cause of the incident must be determined.

The cause must be known so that the systems in question can be returned to a

known good state without significant risk of compromise persisting or reoccurring.

A common occurrence is for organizations to remove the most obvious piece

of malware affecting a system and think that is sufficient. In reality, the obvious

malware may only be a symptom, with the cause still undiscovered.

Once the cause and symptoms are determined then the system is restored to a

good state and should not be vulnerable to further impact. This will typically

involve either rebuilding the system from scratch or restoring from a known good

backup. A key question is whether the known good backup can really be trusted.

Root cause analysis is key here: it can help develop a timeline of events that lends

credence to the suggestion of a backup or image known to be good. Another aspect

of eradication that helps with the prevention of future impact is bolstering defenses

of the system. If the incident was caused by exploitation of a known vulnerability,

then a patch would be prudent. However, improving the system’s firewall config-

uration might also be a means to help defend against the same or similar attacks.

Once eradication has been completed, then the recovery phase begins.

Recovery The recovery phase involves cautiously restoring the system or systems to opera-

tional status. Typically, the business unit responsible for the system will dictate

when the system will go back online. Remember to be cognizant of the possibility

that the infection, attacker, or other threat agent might have persisted through the

eradication phase. For this reason, close monitoring of the system after it is

returned to production is necessary. Further, to make the security monitoring of

this system easier, strong preference is given to the restoration of operations occur-

ring during off or nonpeak production hours.

Reporting Unfortunately, the reporting phase is the one most likely to be neglected in immature

incident response programs. This fact is unfortunate because the reporting phase, if

done right, is the phase that has the greatest potential to effect a positive change in secu-

rity posture. The goal of the reporting phase is to provide a final report on the incident,

which will be delivered to management. Important considerations for this phase are

detailing ways in which the identification could have occurred sooner, the response

392 CHAPTER 10 Domain 9: Operations security

could have been quicker ormore effective, and organizational shortcomings that might

have contributed to the incident, and potential areas for improvement. Though after

significant security incidents security personnel might have greater attention of the

management, now is not the time to exploit this focus unduly. If a basic operational

change would have significantly increased the organization’s ability to detect, contain,

eradicate, or recover from the incident, then the final report should detail this fact

whether it is a technical or administrative measure.

Types of attacks Now that the phases of incident response are understood, types of attacks that fre-

quently require incident response will be described. Though this section will by no

means present an exhaustive list of attack types, it will provide basic information

on the types of attacks more commonly experienced and responded to in organiza-

tions. Before attending specifically to the common attacks, a brief discussion on

threats will aid in bringing the common attacks into the organizational risk assess-

ment model. Attention should be paid to ways in which the attacks can be classi-

fied and organized, which is summarized in Table 10.2.

Threat Agents Threat agents are the actors causing the threats that might exploit a vulnerability.

While the easiest threat agent to understand is the single dedicated attacker, per-

haps working from his mother’s basement, it would be foolish to think this is the

only manifestation of threat agents. One of the most alarming recent trends is the

increasing organization of the threat agents. Organized crime, terrorists, political dis-

sidents, and even nation states are now common threat agents that can easily target

any organization. Though the untrained or careless worker is likely the most common

threat agent, this section’s preference for attacks will tend towards the intentional

attackers. Malware, or malicious code, can also be considered a threat agent, even

though it is automated and lacks creativity. One of the primary reasons to consider

the various threat agents is to appreciate the fact that all organizations can be targets

when the number, types, and motivations of threat agents are so broad.

Threat Vectors What medium allows the threat agent potentially exploit the vulnerability?

The answer to this question describes the threat vectors that must be considered.

Historically, one of the most common threat vectors that persist even today is that

of email attachments. Attackers have been using email attachments as a means to

exploit vulnerabilities for a long time, and the practice continues going strong,

though the types of attachments that are effective has changed. Other common vec-

tors include: external attacker targeting public-facing systems via open ports, web

applications, and clients; using phone lines to target internal servers and already

compromised internal clients to target internal servers; and internal attackers tar-

geting internal systems. Table 10.2 provides additional details regarding these

common attack vectors.

393Incident response management

Password Guessing and Password Cracking Though some fail to distinguish between the two, it is prudent to differentiate

between password guessing and cracking as the techniques differ. Password gues- sing is the simpler of the two techniques from both the attacker’s and defender’s

vantage point. Password guessing is an online technique that involves attempting

Table 10.2 Threat Vectors

Attacker’s Origin

Attacker’s Target Medium or Vector

External Public facing servers

Network Attack—direct attacks against ports open through network and system firewalls. This is the conventional attack vector that is most commonly defended against.

External Web Application components

Web Applications—though some organizations view this as a subset of the above, the attacks and associated defenses are drastically different. The attacker targets the web application, associated servers, and content, rather than merely the web server. Traditional perimeter security defenses fall short when protecting web applications.

External SMTP Gateways, Antimalware systems, Internal Clients

Attack using malicious email attachments. Used to be straightforward virus attachments, but now commonly uses malicious files that exploit client-side application vulnerabilities (.doc, .xls, .ppt, .pdf, .jpg). Note: these seemingly innocuous file types are also being hosted on malicious websites (see below).

External Internal Servers

Phone lines—attacks leveraging phone systems are some of the oldest by nature of the technology involved. Many organizations still leverage these systems, especially for critical legacy components, yet often this medium is now overlooked during security assessments.

External Internal Clients Browser attacks—attacker hosts a malicious web site or leverages a compromised trusted site to exploit internal clients.

External Internal Servers

Pivot attack—leverage an internal client (compromised via another vector) to attack internal servers. Increasingly common as organizations are making better use of perimeter security.

Internal Internal Clients, Internal Servers, Infrastructure

Insider threat—attacker is an insider (employee, contractor, consultant, transient worker, someone with VPN access, etc.) which typically translates to greater access just by virtue of where they are situated with respect to perimeter defenses. Most organizations have limited internal security when compared to their external facing security.

394 CHAPTER 10 Domain 9: Operations security

to authenticate a particular user to the system. Password cracking refers to an off-

line technique in which the attacker has gained access to the password hashes or

database. Note that most web-based attacks on passwords are of the password

guessing variety, so web applications should be designed with this in mind from

a detective and preventive standpoint.

Password guessing may be detected by monitoring the failed login system logs.

In order to differentiate between the normal user accidentally mistyping their pass-

words and the attacker, clipping levels are useful. Clipping levels define a mini-

mum reporting threshold level. Using the password guessing example, a clipping

level might be established such that the audit system only alerts if failed authenti-

cation occurs more frequently than five times in an hour for a particular user. Clip-

ping levels can help to differentiate the attacks from noise, however they can also

cause false negatives if the attackers can glean the threshold beneath which they

must operate.

Preventing successful password guessing attacks is typically done with account lockouts. Account lockouts are used to prevent an attacker from being able to sim-

ply guess the correct password by attempting a large number of potential pass-

words. Some organizations require manual remediation of locked accounts,

usually in the form of intervention by the help desk. However, some organizations

configure account lockouts to simply have an automatic reset time, which would

not necessarily require manual intervention. Care should be taken in the account

lockout configuration as an attacker, though unsuccessful at retrieving a correct

password, might be able to cause significant administrative burden by intentionally

locking out a large volume of accounts.

Password cracking is considered an offline attack because the attacker has

gained access to a password hash for a particular account or the entire password

database. Most password databases store the passwords as hashes rather than clear

text. These one way cryptographic hashes are created by running the plaintext

password through a hashing algorithm such as MD5, LM, NT Hash (MD4), etc.

The attacker will attempt to crack the password with a dictionary, hybrid, and then

finally a brute force method if suitably motivated to achieve the plaintext pass-

word. The dictionary method simply directs the password cracking tool to use a

supplied list of words as potential passwords. The tool will encrypt the supplied

word using the matching password algorithm, and compare the resulting hash with

the hash in the database. If the two hashes match then the plaintext password is

now known. If the dictionary method is unsuccessful then the hybrid approach will

likely be attempted. The hybrid approach to password cracking still leverages a

word list (dictionary), but makes alterations to the word before putting the guess

through the hashing algorithm. Common alterations made by hybrid crackers

include prepending or appending numbers or symbols to the password, changing

the case of the letters in the word, making common symbol or number substitutions

for letters (e.g., replacing an “o” with a “0”). Finally, password brute forcing

involves simply attempting every possible password until the correct match is

395Incident response management

found. Brute forcing will eventually yield the password, but the question is whether

it will return the plaintext password quickly enough (days, months, or years) for it

to still be of value. A variation on typical password brute forcing that can greatly

increase the speed with which the correct password can be retrieved is a precom-

putation brute force attack. This technique employs rainbow tables which are

tables of precomputed password-hash combinations, sometimes within specific

confines such as an upper limit on password length or only including the more

common symbols, collection of all password hashes that are applicable for a given

algorithm. While rainbow tables can reduce the password cracking to a mere table

lookup to find the password hash in question, the creation of these rainbow tables

is an extremely time consuming process.

NOTE

The efficacy of precomputation brute force attacks leveraging rainbow tables is dependent upon the password hashing algorithm’s implementation. The main feature that determines whether rainbow tables will greatly increase the speed of password recovery is whether the implementation of the algorithm involves salts, which is simply a way of introducing randomness into the resultant hashes. In the absence of salts, the same password will yield the exact same hash every single time. Notably, Windows’ LM and NT hashes do not include salts, which makes them particularly vulnerable to this type of brute forcing. Linux and UNIX systems have employed salts for decades. A 16 bit salt would effectively require an attacker to create 65,536 separate sets of rainbow tables, one set for each possible salt.

Prevention of successful password cracking attempts can be achieved by strong

password policies that prescribe appropriate length, complexity, expiration, and

rotation of passwords. Further, strong system security that precludes that attacker

ever gaining access to the password database in the first place is another preventive

measure.

Session Hijacking and MITM Another attack technique that needs to be understood is session hijacking, which

compromises an existing network session, sometimes seizing control of it. Older

protocols such as Telnet may be vulnerable to session hijacking.

A Man In The Middle (MITM, also called Monkey In the Middle) attack places

the attacker between the victim and another system: the attacker’s goal is to be able

to serve as an undiscovered proxy for either or both of two endpoints engaging in

communication. Effectively, an attacker suitably positioned through a combination

of spoofing, masquerading as another endpoint, and sniffing traffic is potentially

able to insert herself in the middle of a connection. The capabilities of session

hijacking include: changing content as it is delivered to one of the endpoints, initi-

ating transactions as one side of the connection, distribution of malware to either

end of the connection, and other attacks. Prevention of session hijacking is best

done by leveraging encrypted communications which provide mutual endpoint

authentication.

396 CHAPTER 10 Domain 9: Operations security

Malware Malware, or malicious code/software, represents one of the best known types of

threats to information systems. There are numerous types of malware, some

detailed in Table 10.3, that have evolved over the years to continually cause stress

to operations. This section will provide a brief description of the major classes of

malware. One important note is that distinguishing between the classes of malware

is growing more difficult as one piece of malware code is being used as the deliv-

ery mechanism to distribute other malware. Antivirus, or antimalware, suites are a

basic protection mechanism for malicious code. However, most antivirus systems

are heavily reliant upon signature based detection which is often considered a reac-

tive approach. Many antivirus tools have evolved into larger suites that include

functionality beyond just basic signature based virus detection (e.g., host based

firewalls, intrusion prevention systems, antispyware functionality, etc.). Two of

the most important considerations for preventing malware infection beyond anti-

virus suites are system hardening and user awareness training.

Table 10.3 Types of Malware

Malicious Code Description

Virus Virus is the term that most lay persons use for all bad things that can happen on a computer. Information security professionals require a bit more specificity of the term, and reserve the word virus to indicate malicious code that hooks onto executable code, and requires user interaction to spread. In addition to spreading, the actual payload of the virus, that is, what it is intended to do, could be anything.

Macro Virus The termmacro virus refers to malicious code that infects Microsoft Office documents by means of embedding malicious macros within them. Many organizations were wholly unaware of the macro functionality provided by Microsoft Office until they were hit with macro viruses.

Worm The distinguishing feature of worms is their ability to self-propagate, or, spread without user interaction. This has made worms exceedingly good at spreading very rapidly throughout the internet. Some of the most well known names of malware fall under the worm category: Code Red, Nimda, SQL Slammer, Blaster, MyDoom, Witty.

Trojan Horse Trojans, which get their name from the famous Trojan Horse from Greek mythology, are defined by how they are concealed, and are most often associated with providing an attacker with persistent backdoor access. Trojans provide ostensibly desirable functionality that the user is seeking, but also comewith malicious functionality that the user does not anticipate.

Rooktkit The term rootkit is used for malware that is focused on hiding its own existence from a savvy administrator trying to detect the malware. Typical capabilities include file, folder, process, and network connection hiding. The techniques developed with rootkits are now commonly included in other types of malware.

397Incident response management

Denial of Service (DoS) and Distributed Denial of Service (DDoS) Denial of Service (DoS) is a one-to-one availability attack; Distributed Denial Of Service (DDoS) is a many-to-one availability attack. They are among the easiest

attack techniques to understand as they are simply availability attacks against a

site, system, or network. Though there are many local denial of service techniques,

this section focuses on remote denial of service techniques. DoS attacks come in

all shapes and sizes, ranging from those involving one specially crafted packet

and a vulnerable system to see that packet, to DDoS attacks that leverage tens of

thousands (or more) bots to target an online service provider with a flood of seem-

ingly legitimate traffic attempting to overwhelm their capacity. Historically there

have been well known named tools for instigating denial of service attacks, how-

ever, these seem to have to become less popular with the rise of botnets that pro-

vide denial of service techniques as part of their generic feature set. It is unlikely

that the CISSP� will require knowledge of more recent specific variations of bots

used for distributed denial of service, so Table 10.4 below will include some his-

torical examples of malicious packet attacks as well as some general resource

exhaustion, or flooding, techniques.

SUMMARY OF EXAM OBJECTIVES In this chapter we have discussed operational security. Operations security con-

cerns the security of systems and data while being actively used in a production

Table 10.4 Denial of Service Examples

DoS Name Type Description

Land Malformed packet

The land attack uses a spoofed SYN packet that includes the victim’s IP address and TCP port as both source and destination. This attack targets the TCP/IP stack of older unpatched Windows systems.

Smurf Resource Exhaustion

A smurf attack involves ICMP flooding. The attacker sends ICMP Echo Request messages with spoofed source addresses of the victim to the directed broadcast address of a network known to be a Smurf amplifier. A smurf amplifier is a public facing network that is misconfigured such that it will forward packets sent to the network broadcast address to each host in the network. Assuming a /24 Smurf amplifier, this means that for every single spoofed ICMP Echo Request sent the victim could receive up to 254 ICMP Echo Responses. As with most of resource exhaustion denial of service attacks, prevention involves having infrastructure that can filter the DoS traffic and/or an ISP that can provide assistance in filtering the traffic.

Continued

398 CHAPTER 10 Domain 9: Operations security

environment. Ultimately operations security is about people, data, media, and hard-

ware; all of which are elements that need to be considered from a security perspec-

tive. The best technical security infrastructure in the world will be rendered moot if

an individual with privileged access decides to turn against the organization and

there are no preventive or detective controls in place within the organization.

Table 10.4 Denial of Service Examples—cont’d

DoS Name Type Description

SYN Flood

Resource Exhaustion

SYN Floods are themost basic type of resource exhaustion attacks, and involve an attacker, or attacker controlled machines, initiating many connections to the victim, but not responding to the victim’s SYN/ACK packets. The victim’s connection queue will eventually be unable to process any more new connections. Configuring a system to more quickly recycle half-open connections can help with this technique. As with most of resource exhaustion denial of service attacks, prevention involves having infrastructure that can filter the DoS traffic and/or an ISP that can provide assistance in filtering the traffic.

Teardrop Malformed packet

The teardrop attack is a malformed packet attack that targets issues with systems’ fragmentation reassembly. The attack involves sending packets with overlapping fragment offsets, which can cause a system attempting to reassemble the fragments issues.

Ping of Death

Malformed packet

The Ping of Death denial of service involved sending a malformed ICMP Echo Request (Ping) that was larger than the maximum size of an IP packet. Historically, sending the Ping of Death would crash systems. Patching the TCP/IP stacks of systems removed the vulnerability to this DoS attack.

Fraggle Resource Exhaustion

The fraggle attack is a variation of the smurf attack. Themain difference between smurf and fraggle being that fraggle leverages UDP for the request portion, and stimulates, most likely, an ICMP Port Unreachablemessage being sent to the victim rather than an ICMP Echo Response.

DNS Reflection

A more recent denial of service technique that, like the smurf attack, leverages a third party is the DNS reflection attack. The attacker who has poorly configured third- party DNS servers query an attacker-controlled DNS server and cache the response (a maximum-size DNS record). Once the large record is cached by many third party DNS servers, the attacker sends DNS requests for those records with a spoofed source of the victim. This causes these extremely large DNS records to be sent to the victim in response. As with most of resource exhaustion denial of service attacks, prevention involves having infrastructure that can filter the DoS traffic and/or an ISP that can provide assistance in filtering the traffic.

399Summary of exam objectives

There must be controls associated with even the most trusted individuals. This

chapter discussed items such as the principle of least privilege, separation and rota-

tion of duties, and mandatory vacations which can all help provide needed security

controls for our operational personnel. In addition to personnel related security,

this section dealt with media, where the data physically resides. Even though an

organization’s access control methodology might be superlative, if they allow for

sensitive information to be written to backup tapes in plaintext and then hand that

tape to a courier, bad things will almost certainly follow. Further, media security

also dealt with retention and destruction of data, both of which need to be strictly

controlled from an operational security perspective.

Another aspect of operational security is maintaining the availability of systems

and data. To this end, data backup methodologies, RAID, and hardware availability

were all attended to. Data backups are one of the most common data and system

reliability measures that can be undertaken by an organization. RAID, in most con-

figurations, can provide for increased data availability by making systems more

resilient to disk failures. In addition to disk and data reliability though, system

hardware must also be continually available in order to access those disks and

the data they contain. Hardware availability via redundancy and clustering should

also be considered if the systems or data has strict availability requirements.

The final aspect of this chapter on operations security dealt with how to respond to

incidents and some common attack techniques. An incident response methodology was

put forth, because incidents will inevitably occur in organizations; it is just a matter of

time. Having a regimented process for detecting, containing, eradicating, recovering,

and reporting security incidents is paramount in every organization that is concerned

with information security, or, more simply, the confidentiality, integrity, and availabil-

ity of their information systems and the data contained therein. Finally, some common

attack techniqueswere discussed including password cracking, denial of service techni-

ques, session hijacking, and malicious software. Though this is by no means a compre-

hensive list, it does provide some basic information about some of the more common

attack techniques that are likely to be seen from an operational security vantage point.

SELF TEST 1. Which type of control requires multiple parties in order for a critical transac-

tion to be performed?

A. Separation of duties

B. Rotation of duties

C. Principle of least privilege

D. Need to know

2. Which concept only allows for individuals to be granted the minimum access

necessary to carry out their job function?

A. Rotation of duties

B. Principle of least privilege

400 CHAPTER 10 Domain 9: Operations security

C. Separation of duties

D. Mandatory leave

3. Which level of RAID does NOT provide additionally reliability?

A. RAID 1

B. RAID 5

C. RAID 0

D. RAID 3

4. Which type of RAID uses block level striping with parity information

distributed across multiple disks?

A. RAID 1

B. RAID 3

C. RAID 4

D. RAID 5

5. Which type of backup will include only those files that have changed since the

most recent Full backup?

A. Full

B. Differential

C. Incremental

D. Binary

6. Which security principle might disallow access to sensitive data even if an

individual had the necessary security clearance?

A. Principle of least privilege

B. Separation of duties

C. Need to know

D. Nash analytics

7. Which type of malware is able to propagate itself without user interaction?

A. Rootkit

B. Trojan

C. Virus

D. Worm

8. Separation of Duties requires that two parties act in concert in order to carry

out a critical transaction. What is the term associated with two individuals

working together to perpetrate a fraud?

A. Hijacking

B. Espionage

C. Terrorism

D. Collusion

9. Which type of malware is commonly associated with office productivity

documents?

A. Macro

B. Worm

401Self test

C. Spyware

D. Rootkit

10. What type of backup is obtained during the Containment phase of Incident

Response?

A. Incremental

B. Full

C. Differential

D. Binary

11. Which type of attack will make use of misconfigured third party systems to

perpetrate a DoS?

A. Smurf

B. Session hijacking

C. Teardrop

D. Land

12. Which attack technique might involve a seemingly trusted endpoint resolving

as a website hosting malware?

A. Password cracking

B. Trojan horse

C. Session hijacking

D. UI redressing

13. Which principle involves defining a trusted security baseline image of critical

systems?

A. Configuration management

B. Change management

C. Patch management

D. Vulnerability management

14. Which type of attack leverages overlapping fragments to cause a denial of

service?

A. Smurf

B. Teardrop

C. Fraggle

D. Session hijacking

15. What security principle can be used to help detect fraud coming from users

becoming comfortable in their position?

A. Separation of duties

B. Principle of least privilege

C. Rotation of duties

D. Collusion

402 CHAPTER 10 Domain 9: Operations security

SELF TEST QUICK ANSWER KEY 1. A 2. B 3. C 4. D 5. B 6. C 7. D 8. D 9. A

10. D 11. A 12. C 13. A 14. B 15. C

References 1. Juvenal Satires Book II: Satire 6, 346-348. 1st-2nd Century CE.

2. Gutmann P. Secure Deletion of Data from Magnetic and Solid-State Memory. 1996. http://www.cs.auckland.ac.nz/�pgut001/pubs/secure_del.html [accessed February 17,

2010].

3. Brumley D, Poosankam P, Song D, Zheng J. Automatic Patch-Based Exploit Generation

is Possible: Techniques and Implications. In: Proceedings of the 2008 IEEE Symposium on Security and Privacy, April; 2008.

403Self test quick answer key