Security Operations Concepts

The topic of security operations covers a wide variety of concepts, which we describe in the following sections. The common theme among these concepts is protecting the confidentiality, integrity, and availability of information assets. Information is protected through controls and the reduction of threats and vulnerabilities.

Avoiding single points of failure

A single point of failure is any part of a system, process, or network whose failure can cause the whole system to become unavailable. The technical lexicon is full of strategies and solutions that attempt to address single points of failure: reliable systems design, high-availability (HA), clustering, mirroring, virtualization, and more.

In reality, any system, process, or network has numerous single points of failure. To the extent possible, effective security planning attempts to identify and eliminate these single points of failure and thereby avoid a self-inflicted denial of service because of a weak architecture.

When conducting security planning for any new or existing system, process, or network, try brainstorming to identify as many possible single points of failure as you can. Consider the following examples:

Systems: Does the system have redundant power supplies and cooling fans? What about separate power sources? Are hard drives configured for RAID? Are components hot-swappable? Can (and should) the system be clustered or virtualized? Can data be replicated to another system/location in real time?

Networks: Do your routers and firewalls fail over automatically? Do they fail back? Do your routers have multiple paths available to your network destinations? Do you have multiple service providers? Do they share the same network POPs (points-of-presence)? What happens if the connection to your telecommunication provider’s central office is cut? Do your multiple telecommunication providers’ networks go through the same telecommunications hotel?

A telecommunications (or telecom) hotel is a facility that houses equipment belonging to many different telecommunications companies.

Processes: Do your personnel security policies and practices create single points of failure? Perhaps you’ve instituted a separation of duties and responsibilities, but you haven’t established a corresponding rotation of duties and responsibilities. If this situation sounds familiar, you may actually be causing a process to rely on a single person — that’s a single point of failure! Do you have contingency processes in place in case a primary system, process, or person isn’t available?

“Failure is not an option” was the famous resolution that set NASA engineers to solving the dire system troubles aboard the Apollo XIII moon flight. In a typical network, failure is always a possibility that must be addressed. The accompanying sidebar lays out some of the essential concepts for doing so.

Handling sensitive information

Sensitive information such as financial records, employee data, and information about customers must be clearly marked, properly handled and stored, and appropriately destroyed in accordance with established organizational policies, standards, and procedures:

Marking: How an organization identifies sensitive information, whether electronic or hard copy. For example, a marking might read PRIVILEGED AND CONFIDENTIAL. See Chapter 6 for a more detailed discussion of data classification.

Handling: The organization should have established procedures for handling sensitive information. These procedures detail how employees can transport, transmit, and use such information, as well as any applicable restrictions.

Storage and Backup: Similar to handling, the organization must have procedures and requirements specifying how sensitive information must be stored and backed up.

Destruction: Sooner or later, an organization must destroy a document that contains sensitive information. The organization must have procedures detailing how to destroy sensitive information that has been previously retained, regardless of whether the data is in hard copy or saved as an electronic file.

Records retention

Most organizations are bound by various laws to collect and store certain information, as well as to keep it for specified periods of time. An organization must be aware of legal requirements and ensure that it’s in compliance with all applicable regulations.

Records retention policies should cover any electronic records that may be located on file servers, document management systems, databases, e-mail systems, archives, and records management systems, as well as paper copies and backup media stored at off-site facilities.

Organizations that want to retain information longer than required by law should firmly establish why such information should be kept longer. Nowadays, just having information can be a liability, so this should be the exception rather than the norm.

At the opposite end of the records retention spectrum, many organizations now destroy records (including backup media) as soon as legally permissible in order to limit the scope (and cost) of any future discovery requests or litigation. Before implementing any such draconian retention policies that severely restrict your organization’s retention periods, you should fully understand the negative implications such a policy has for your disaster recovery capabilities. Also, consult with your organization’s legal counsel to ensure that you’re in full compliance with all applicable laws and regulations.

Although extremely short retention policies and practices may be prudent for limiting future discovery requests or litigation, they’re illegal for limiting pending discovery requests or litigation (or even records that you have a reasonable expectation may become the subject of future litigation). In such cases, don’t destroy pertinent records — otherwise you go to jail. You go directly to jail! You don’t pass Go, you don’t collect $200, and (oh, yeah) you don’t pass the CISSP exam, either — or even remain eligible for CISSP certification!