11: SAFEGUARD ANALYSIS
INTRODUCTION
In the McCumber Cube, safeguards are categorized into three primary groups—technical, procedural, or human factors. Sometimes these safeguard categories are glibly defined as the Three Ps—products, procedures, and people.
Safeguards are most commonly defined as a concept synonymous with security controls and countermeasures. Technically, security controls are defined as the management, operational, and technical controls (safeguards or countermeasures) prescribed for an information system that, taken together, satisfy the specified security requirements and adequately protect the confidentiality, integrity, and availability of the system and its information. The problem with this definition is simply that the characteristics of confidentiality, integrity, and availability always apply strictly to the information, not to the underlying technology that effects the transmission, storage, and processing of the information. Additionally, that definition is far too broad to effectively manage a technical security program.
Security practitioners need to understand safeguards as any technical, procedural, or human factors control or countermeasure that can be employed to mitigate or eliminate risk in IT systems. Additionally, a safeguard may only address a portion of a vulnerability, a single vulnerability, or an entire class of vulnerabilities. The appropriate mix of safeguards is the cornerstone of an effective and cost-efficient security program for IT systems. Before we develop the safeguard analysis component of the model, it is important to review the categories of safeguards and more accurately define each one.
TECHNOLOGY SAFEGUARDS
Technology safeguards are those security controls and countermeasures that exist as IT components to enforce one or more security policy requirement. Technology safeguards can be hardware components, software, or any other type of direct, physical enforcement mechanism. In the realm of physical security, safeguards such as locks, doors, and fences are elements of physical (or by extension, technical) safeguards.
Technology safeguards for IT systems comprise a broad spectrum of physical products and software tools that mitigate risk by either eliminating vulnerabilities or enforcing a confidentiality, integrity, or availability requirement. Not all safeguards actually target specific technical vulnerabilities.
Many technology safeguards are designed and built to enforce one or more of the security attributes. For example, much of the functionality in modern firewalls is there to eliminate certain exposures, as defined by MITRE’s CVE outlined in Appendix A. An exposure is different from a vulnerability by definition. An exposure refers to securityrelated facts that may not be considered to be vulnerabilities by everyone.
In the case of firewalls, the capability to proxy data transfer and to prevent unmonitored access to various ports on a server is not employed simply to eliminate what is commonly known as a vulnerability. Most of the blocked ports on a firewall-protected server are operating exactly as they were designed to. However, the firewall blocks access to defined ports by certain parties to prevent them from being probed and possibly used as a pathway for unauthorized access to information resources. This technology safeguard then mitigates the risk from numerous potential threats. Once this type of technology safeguard is implemented, it is then important to discern what related threats, vulnerabilities, and exposures remain.
Technology safeguards can also include physical safeguards used to support, enhance, supplement, or replace IT safeguards. For example, physical separation of IT systems and components is often used to enforce certain confidentiality controls. Defined physical spaces controlled by such safeguards as doors and locks are often to prevent the ability of information to either be viewed or moved outside a defined controlled area. The doors and locks are used to enforce some or all of the requirements for confidentiality.
These physical safeguards are sometimes referred to as air gaps, and they have been used effectively to either support or replace software or electronic controls that are often easier to subvert. When information resources need to be transferred to another system either within the controlled area or outside the area completely, a copy of the selected data are transferred to a portable medium such as a memory stick and physically brought to an appropriate device on the target information system.
Another example of physical safeguards supporting or enforcing IT security is the integration of access control badges or other physical security tools into the IT systems environment. The same access badges that can be used to unlock doors and raise the gate at the corporate garage can be used as a token at end points in a computer systems network as a form of authentication for access to information resources. Additionally, other identification and authentication devices used for control of physical access can often be adapted to complement IT access controls.
Technology safeguards are best considered in their broadest sense. They represent the most tangible and often the most effective security controls and countermeasures in the security practitioner’s arsenal of tools. Ensuring that physical and other non-IT safeguards are considered as complementary to and supportive of an information security program ensures that the best possible mix of controls can be considered.
PROCEDURAL SAFEGUARDS
Procedural safeguards are critical countermeasure components and encompass a wide array of capabilities. Like technology safeguards, procedural safeguards also mitigate risk by either eliminating vulnerabilities or enforcing a confidentiality, integrity, or availability requirement. However, they do not take the form of a physical or technological product or component. They are normally best understood as denoting the way something is accomplished that meets the requirements of a security control or countermeasure.
Procedural safeguards are identified and implemented by their ability to mitigate risk through the enforcement of a way of effecting a desired security-relevant outcome. Many stand-alone procedural safeguards are used in the management of security requirements. For example, a procedural safeguard may dictate that only personnel obtaining an authorization form signed by a certain manager will be allowed access to information resources. This procedure in and of itself may not completely enforce the letter and intent of the confidentiality requirement, but it is a key part of the specific confidentiality controls.
Broadly speaking, procedural safeguards include almost any codified requirement designating a method or process for performing any action that enforces or supports the security policy. The easiest way to identify and assess procedural safeguards is to review all security policies and regulations that affect the organization’s information resources. The difficulty of a comprehensive assessment of these controls is the fact these safeguards are usually codified in a variety of formats in a wide variety of corporate and even technical publications. Procedural safeguards for the enforcement of confidentiality, integrity, and availability requirements can run the gamut from simple user checklists to comprehensive manuals.
Physical security procedures are often procedural safeguards either used independently or in conjunction with other IT safeguards. For example, a procedural safeguard may be to ensure that all visitors in rooms containing network access points must be escorted to ensure that they are not allowed the opportunity to access IT resources and presumably gain access to sensitive information assets. This safeguard would also logically be invoked to provide security for all company assets, including office items or paperwork that could be pilfered by unaccompanied visitors. This type of common procedural safeguard, however, is a critical IT safeguard that supports the technical and human factors safeguards in a comprehensive program.
HUMAN FACTORS SAFEGUARDS
Human factors safeguards are often the most difficult to identify and the most difficult to quantify. As with both technical and procedural safeguards, human factors safeguards mitigate risk by either eliminating vulnerabilities or enforcing a confidentiality, integrity, or availability requirement. Human factors are often defined as the study of how humans behave physically and psychologically in relation to particular environments, products, or services. In our case, it would be the information security program. Often the terrn is used as a synonym for ergonomics, but in the case of a safeguard category, this is not accurate. A more refined and focused definition is required.
Human factors study primarily focuses on general human behavior in relation to technology (such as studies of how people react to various form factors of technology), on a generic type of product, on specific environment or product designs as a whole, or on some specific design aspects of a particular environment or product. Using this more traditional definition of human factors engineering, the result of human factors study can include suggestions on how to redesign an object of study or a general guideline for designing such an object or technology. In addition to relatively formal human factors study, human factors can be said to be underway any time a designer thinks about the effects of the design on the end user.
In understanding and implementing human factors safeguards, it is important to recognize that many of these controls may not directly appear to be safeguards or they may appear as a separate component of a technical or procedural safeguard. Technology safeguards are things and procedural safeguards are plans, processes, and policies. Human factors safeguards are tied directly to people and their performance in enforcing or supporting security requirements. Rarely is it easy to quickly identify human factor safeguards.
Human factors safeguards can be used to mitigate risk through the influence of organizational members such as system users, security analysts, system administrators, company partners, visitors, and auditors. An example of a human factor safeguard is the keen eye of an auditor searching records and logs for malicious activities and anomalies. This uniquely human activity relies on the ability of the auditor to filter this information through his or her personal knowledge and training to recognize potential breaches and other security violations.
Human factors safeguards can also be employed to influence the security relevant activities of outsiders and even potential attackers. In cases such as this, human factors safeguards are used as psychological enforcement mechanisms. Take the case of a security warning banner on a government owned and operated Web site. It may serve primarily a legal purpose in providing the required warnings and disclaimers so that people who violate the system rules cannot claim they were unaware of their responsibilities if they are prosecuted for their actions. However, it can also serve a key purpose as a warning that the site owner treats potential threats seriously and is willing and able to take legal steps to protect its sensitive information resources. This warning, then, works just like a sticker in the front window of a home or a placard on a residential lawn proclaiming the fact that the house has a monitored alarm system. The sign not only provides inexpensive advertising for the alarm company, but also provides the homeowner a means to encourage potential burglars to seek out a less well protected home.
Human factors safeguards are often the least costly and most effective components of a sound security program. In many ways, the overall security program itself is a form of macro-safeguard. The fact that a structured methodology is being used to build and manage the security program ensures that the appropriate people and tools are integrated to create a comprehensive security framework. This is turn involves technologists, administrators, executives, and security personnel who contribute and share in supporting the security objectives. This broad involvement in turn provides a scaffold of support structures to ensure the continued effectiveness of the overall protection program.
VULNERABILITY-SAFEGUARD PAIRING
An important aspect for understanding safeguards is the ability to map your proposed or existing safeguards against potential threats. Safeguard analysis for IT systems is a critical aspect of providing both enforcement and management of security policy. Safeguards are employed to either completely or partially mitigate risks from vulnerabilities. When applying the McCumber Cube methodology, it is important to map the safeguards against their corresponding vulnerabilities. By compiling a complete list of potential system vulnerabilities, you can more easily determine the safeguard suites necessary to cost-effectively implement your security requirements.
We have already outlined the effectiveness mapping threat-vulnerability pairs. At this point, it is also beneficial to map the vulnerabilities to safeguards. These security safeguards should be considered in the broadest sense of the term. Even physical security safeguards and organizational procedures are effective aspects of your security program and should not be overlooked in favor of purely technical safeguards. Each safeguard contributes to the greater program and many safeguards can mitigate risks across a broad spectrum of vulnerabilities.
Just as threat-vulnerability pairs are used to comprehensively identify vulnerabilities, there is great value in performing a similar analysis by developing a comprehensive vulnerability-safeguard pairing. This pairing is performed in the same manner of the threat-vulnerability pairing exercise. Identified vulnerabilities (either using the CVE or other methodology) are placed down the left-hand side of a chart and appropriate safeguards for these relevant vulnerabilities are then paired by cross-reference. As in threat-vulnerability pairs, there are often one-to-many and many-to-one relationships. This type of analysis is portrayed in Table 11.1.
Although such an exercise may be impractical for a large IT system, this type of analysis can be used effectively in smaller subsets and with discreet technology elements to foster critical thinking and a perspective on the comprehensive set of potential safeguards. As with any safeguard analysis, it is appropriate to consider safeguards that span all three categories. Your analysis will be easier and more effective if you ensure that these safeguards are also categorized as technological, procedural, or human factors.
HIERARCHICAL DEPENDENCIES OF SAFEGUARDS
One of the most important attributes of safeguards is their hierarchical dependency. The McCumber Cube categorizes safeguards into technical, procedural, and human factors. These categories are identified separately and can be conveniently placed in one category or another. However, there is an important feature of the model that recognizes this hierarchical dependency. These dependencies are depicted in Table 11.2.
The dependency attribute shows that for each technical safeguard, there are supporting procedural and human factors safeguards. If the safeguard is purely a procedural one, there is at least one supporting human factors safeguard associated with it. Human factors safeguards often stand alone as singular entities.
Table 11.1 Vulnerability-Safeguard Pairing
Table 11.2 Hierarchical Dependencies of Safeguards
To clarify this concept, let us begin with a fairly common technical safeguard—a firewall. The firewall is logically a technical safeguard; it exists (minimally) as software. The firewall can perform several security-relevant functions. An Internet firewall examines all traffic routed between an organizational network and the open Internet to determine if it conforms to certain criteria. If it does, the data is passed from outside (the Internet) to inside the corporate network. Traffic that does not meet the explicit criteria is stopped. A network firewall filters both inbound and outbound traffic. The firewall can be employed to log all attempts to enter the private network and be set up to trigger alarms when unauthorized or potentially hostile entry is attempted. Firewalls can perform this security function by filtering packets based on their source, destination addresses, and port numbers. This aspect of firewall management is known as address filtering. Firewalls can also be configured to filter specific types of network traffic. This capability is known as protocol filtering because the decision to forward or reject traffic depends on the protocol used, for example, HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), or Telnet. Firewalls can also filter traffic by packet attribute or state.
The firewall’s ability to perform these important network security functions is obviously supported by an established set of procedures that identify the types of security functions it must perform. Out-of-the-box configurations are almost universally inadequate. The firewall must be manually configured to perform the required security functions such as filtering and logging that support the security requirements of the organization that acquires and implements the firewall technology. The technical safeguard implements these procedural safeguards.
To develop, implement, and monitor these firewall procedures and requirements, human factors safeguards are necessarily employed. Ultimately, a human must make an initial risk management determination about what security functions the firewall must perform and determine which firewall best meets the organization’s requirements. Also, a firewall produces logs and other output that often require human oversight to review, and possibly human intercession to enforce, a security policy with the firewall technology. In the case of the firewall, it quickly becomes obvious that the technology safeguard itself must be supported by at least one (and often many) procedural safeguards. The sarne is true for human factors safeguards.
When assessing procedural safeguards, it is critical to remember that at least one and possibly several human factors safeguards in turn support them. We can again look to the example of the physical security procedure that requires an escort for visitors in rooms containing IT and network access points. The human factors safeguards supporting the actual procedure are actually fundamental to the efficacy of the procedure itself. As always, this safeguard was developed and enforced as the result of a corporate risk management decision—whether it was off-the-cuff, copied from another company’s policies, or the result of an in-depth, tailored risk analysis.
There are also several other explicit or implicit human factors safeguards directly supporting this procedural safeguard. The fact that visitors are required to obtain an escort actively discourages visitors from innumerable suspicious or malicious activities. It also dramatically displays to visitors that the organization has valuable assets that it is willing to protect even if it requires pulling someone from their normal duties to act as an escort. Conversely, the procedure affects the employees by making the escorts personally responsible for protecting assets even though their primary duty may not be security. This relatively simple and inexpensive procedural safeguard then is not only the product of human factors safeguard analysis, but is supported by human factors safeguards that impact the security-relevant activities of employees and visitors alike.
Although a human factors safeguard may support one or many procedural or technical safeguards, they are often defined and analyzed in their own context. Many human factors safeguards are employed by themselves to influence human behavior. Human factors safeguards always support procedural safeguards, including procedural safeguards that support technical safeguards. In this context, it is easy to see that each and every safeguard—technical, procedural, or human factors—has at least one human factors component.
The hierarchical nature of IT safeguards is a critical aspect of the McCumber Cube. It recognizes and highlights the important aspect of supporting and interrelated safeguards. Procedural and human factors safeguards support all technical safeguards. Human factors safeguards support all procedural safeguards. And human factors safeguards can stand independently or can support the other safeguards as noted above.
This hierarchical dependency applies to all types of safeguards, not just those associated with IT security. For example, physical security practitioners may define the need for a fence to control access to a certain area. The fence itself represents the purely technical solution. However, there will be a procedural need to monitor, lock, and unlock doors or gates. There will also be procedural components to the upkeep and maintenance of the fence. The fence also provides a human factors safeguard by physically partitioning the enclosed area and serving notice to potential human threats that the area is protected propeity.
Every type of safeguard, irrespective of its application, has the hierarchical dependency trait that is highlighted by the McCumber Cube. In the case of physical security safeguards, the elements of confidentiality, integrity, and availability do not apply directly to physical assets, but the three-tier structure of the safeguard component directly applies to any type of safeguard. Applying this reasoning to any safeguard or countermeasure application provides practitioners with a categorization capability to fully assess the secuiity impact to their safeguard deployment and management.
SECURITY POLICIES AND PROCEDURAL SAFEGUARDS
There is an important distinction to make at this point: Security policies are not the same as procedural safeguards. A security policy is a document that defines in writing how a company plans to protect its physical, personnel, and information assets. A security policy is often classified as a living document, meaning that the document is never finished, but is continuously updated as technology and employee requirements change. A company’s security policy should include a description of how the company plans to educate its employees regarding protecting the company’s assets, an explanation of how security measurements will be carried out and enforced, and a procedure for evaluating the effectiveness of the security policy to ensure that necessary safeguards are implemented, enforced, and managed.
A security policy must also define the consequences for knowing violations of organizational security policy. Many policies are drafted and promulgated without any consequences outlined. When consequences are outlined, often they state simply that any violation could result in penalties up to and including termination of the employee. To effectively provide a human factors safeguard element to the policy, detailed consequences should be included.
Policies need not overlap procedural safeguards. Policies define the assets, the associated security requirements, and the consequences and remedial actions necessary to return to an acceptable level of risk. They are the genesis for a risk analysis, whereas procedural safeguards are tools chosen as a result of that same analysis.
Defining the difference between the two concepts is relatively easy. Procedural safeguards are tied to specific vulnerabilities as described in the section on vulnerabilitysafeguard pairing. These codified policies are not the same as a procedural safeguard. Procedural safeguards implement policies, but are not, of themselves, policies. This distinction is important when creating both policies and procedural safeguards. By identifying the appropriate characteristics of both, the security practitioner can be assured of a more effective policy as well as appropriately targeted safeguards.
DEVELOPING COMPREHENSIVE SAFEGUARDS: THE LESSONS OF THE SHOGUN
In 1975, author James Clavell wrote a momentous piece of historical fiction called Shogun. The book can teach us some important lessons about the use of safeguards and their application to IT security as well. At the dawn of the Information Age, simple computer access controls were coupled with physical security measures to ensure adequate control over digital assets. The thought and execution was simple. If people could not gain access to the information, they could not exploit it. This was the primary rule of the Shogun: If possible enemies could not even approach your assets, they could not kill them or steal them.
Another clever security tactic employed in the novel was the law of centralization. For example, all the national treasure of Japan at that period was gathered and then stored in a single fortress location. The logic behind that activity was simple, yet elegant. If you had to protect a significant quantity of valuable assets, you could gain a significant economic advantage by keeping your security forces focused on a single collection point. This was more effective than trying to distribute your security forces across a broad geographic area where travel was difficult. Anyone who would deign to steal the treasure was faced with an extensive and interwoven security system composed of numerous armed guards, secret passageways, alarms, and an impregnable vault. This analogy has also not been lost in the Information Age.
Historically, information and computer security was much more effective when the information could be gathered and stored in a single location. All the security technology needed to control and protect the data could be centrally purchased, configured, and managed by a tight group of specialists at a single location. An added value was a fact that the security tools could work in concert to interoperate to create a seamless secure boundary with interlocking layers of protection.
As the Internet revolution swept the IT industry along in its wake, people began to realize that, unlike gold and jewels, most information actually increased in value as it was shared and used across distributed systems. A good example would be your credit card. You can better protect your financial information from misuse if you refuse to share the number with anyone over the telephone, Internet, or even in person. However, you cannot gain the full advantage of catalog sales and Internet shopping unless you share it with vendors and service providers through these media. What you need, therefore, is an ability to share your credit card information with a degree of confidence that you can limit or eliminate risks to your personal assets.
Although you want the ability to share your information, you know you cannot relinquish your right to control it. The requirement for distributed security emerged directly from this basic characteristic of information asset management. Unfortunately, many safeguard technologies are simply the software equivalent of the samurai warrior.
My favorite example of samurai software includes most popular versions of antiviral programs. Every month or so, they recommend you upload something known as the virus definition files. These updates are nothing more than software signatures of possible viruses and malicious code. For each and every possible new virus, a new samurai has to be dispatched that can kill the offending program. As the number of viruses and variants grows, the size of the signature file grows in direct proportion. Because this dated security technology cannot prevent the undesirable actions of viruses, it is forced to identify and eliminate any code that could be a virus.
Because distributed security often means little or no security, another common practice in the security industry is based on the law of centralization. Internet portals and large databases are often used to put data in one place so it can be effectively controlled with an interoperating security system. To create a portal that stores and manages the data, all the data has to be converted to a format consistent with the portal technology. Usually this would be in the form of a large database or HTML (Hypertext Markup Language) files. This cumbersome task is exacerbated by the fact that this data now needs centralized mediation to ensure that the information’s asset value is controlled. Managing this problem can limit the value your data can realize because it must be centrally retained and managed. This central storage system may ultimately be several steps removed from where the information is originally created and updated.
The lessons of the Shogun that were effective at the dawn of the 17th century may not be easy to apply at the dawn of the Information Age. New ways to share information while controlling its use need to be developed. This is important in the planning and application of safeguards and controls. One of the most telling examples involves the problems associated with peer-to-peer software technology.
The peer-to-peer concept of sharing information resources among users is straightforward. It takes advantage of all the interconnected computers to freely share and distribute files among users. Sometimes a common location or portal is used to act as a mediator by identifying the location of information resources and facilitating its transfer. By facilitating the unlimited flow of digitized assets, however, the peer-to-peer solution denies data owners a way to control their information or realize revenue from its use.
However, it makes little sense to refrain from making the best use of information through a medium such as peer-to-peer technology. An acceptable answer to this dilemma lies with the appropriate use of safeguards. When control and use policies can be applied directly to data assets, such as music recordings and other digitized content, it becomes possible to use portal systems and databases to mediate and enforce the policies established by the owners and users of the information resources. Such an arrangement would benefit both the producers of digital content and the consumers thereof. Content could be made available in a variety of digital formats and the owners and information producers could be assured of fair compensation for their investments.
The characters represented in the Shogun saga understood the value of their assets and protected them accordingly. As the threats increased, they had only a limited number of options to exercise. They could call for more samurai guards and they could also shift their assets to locations that increased the likelihood of better security. With data, intellectual property, and other information and other digital assets, we have to harness the power of new technology safeguards to mediate, monitor, and control to ensure that we realize their true value. Simply acquiring and deploying more samurai is no longer sufficient. And keeping your assets locked in the dungeon prevents your organization from getting the best ROI.
IDENTIFYING AND APPLYING APPROPRIATE SAFEGUARDS
Determining which safeguards to employ is a critical task. That is the reason a sound approach is to carefully juxtapose your safeguards against a comprehensive list of technical vulnerabilities. Acquiring, developing, and implementing a collection of safeguards based on their marketing description (e.g., firewall, intrusion detection system, honeypot, authentication, etc.) is an inadequate process. Safeguards need to be assessed and implemented as a means to cost-effectively reduce risk exposure to information assets. As an example, we will examine a specific technical class of safeguard—authentication tools.
Authentication tools consist of tokens and biometric devices that allow administrators to definitively determine someone’s unique identity. They go far beyond the more common identification and passwords that account for most authentication schemes. Although rapid advances in this area are necessary, the specific security functions authentication products provide are actually quite limited. Once you determine who someone is, the next big issue is figuring out what they have permission to do with your data.
Most IT authentication safeguards have the ability to enforce a limited number of permissions. Permissions are simply binary decisions about what is and is not allowed. In the case of a safeguard such as a firewall, there is an assortment of permissions that define what connections and processes are allowed to pass through from the Internet to the company’s internal network. Once a program, a piece of data, or a request is allowed pass through to the internal network, the firewall no longer exercises any control over the activities of a user or remote process. For that job, you need to be able to intercept any call for data and evaluate it against a policy that states what that person or program can do and under what conditions.
With an authentication technology, you first require a policy to determine what a person or process can do with specific pieces of information and under what conditions. Although the authentication safeguard may provide sound access control, it often cannot enforce the actual authorization requirements of the policy. Unfortunately, data security authorization technologies have received significantly less attention than the more basic authentication process. Biometric devices like thumbprint readers and retina scanners have an ability to uniquely identify an individual and ensure that person alone is accessing the resources protected by the authentication safeguard. The more granular (and often more critical) aspect of authorization goes beyond simple access control.
Authorization is the process of enforcing the policy of what information a person can access, modify, or create along with a set of conditions that constrains their activities based on a nearly unlimited number of potential factors such as time of day, location, and primary job function, among others. These attributes should be captured in the security policy and need to be enforced by the appropriate safeguards.
This can present a serious problem to identifying and implementing safeguards as security products companies are often tied to a product roadmap that focuses almost entirely on network security. Network security is important, but relying solely on network security technologies has meant that data protection can only be enforced at the network boundaries and normally only with network (not information) resources. Insiders on the local network can still easily misuse company information and data that must travel outside the local network is usually left without any protection whatsoever.
Expensive and complex technologies like public key infrastructure and host-based intrusion detection can provide your organization with today’s most advanced network security products. However, it is important to determine precisely what protection you expect from your investment in these large-scale network security tools. The security practitioner must define specifically which vulnerabilities are either fully or partially mitigated with the safeguards under review. This brings us back to the simple basics of security policy and risk assessment.
The best way to determine if you are using the right tools is to start by reevaluating your most recent corporate security policies and your risk assessment documents. The safeguards you select and employ to protect your company’s data should directly provide the control and audit functions that support fundamental security policy. If you find it difficult to connect the policy with the tool, you should carefully analyze the functionality of the product you are planning to acquire and employ.
If your organization is one of many that have emerging requirements for sharing information and allowing corporate data to be selectively distributed, you will need to find the right tools for the job. Although network security technology continues to be an important component of the corporate IT landscape, security authentication and authorization solutions are rapidly becoming critical to meet evolving business needs. It is no longer sufficient to provide for security enforcement solely at the network boundaries. For organizations to find and exploit new revenue channels and to seek out new customers, they will need to share their information in a controlled manner. Make sure you are using the right tools for the job.
COMPREHENSIVE SAFEGUARD MANAGEMENT: APPLYING THE McCUMBER CUBE
Ultimately, all your safeguards—technical, procedural, and human factors—must interoperate as a whole to provide the required amount of protection. Once the risk assessment process is complete, you have a roadmap for determining how much protection is required and an in-depth analysis of the key assets you are trying to protect and manage. Now you can again go back to the McCumber Cube methodology and apply the Cube to map the safeguards against vulnerabilities as they apply specifically to information resources.
As with any adaptation and use of the McCumber Cube methodology, the focus is on the information states—attributes of data and information. In other words, it is not effective to try to apply the safeguards to a specific technical specification; instead you need to target the safeguards as they support the appropriate information attributes of confidentiality, integrity, and availability. Any safeguard should be tied directly to these factors to assess efficacy and cost-effectiveness.
After evaluating safeguards in this manner, it is necessary to also ensure you have considered the hierarchical properties of the safeguards. Procedural and human factors safeguards support all technical safeguards. Human factors safeguards support all procedural safeguards. Only human factors safeguards can operate as stand-alone countermeasures.
The McCumber Cube methodology is based on information attributes and not technical criteria. However, safeguard assessments should ultimately move from their application to information resources to the risks from the specific vulnerabilities they mitigate. This process may at first appear cumbersome and difficult; however, it can reap significant benefits to the security practitioner.
The most obvious and perhaps the most significant value to be realized from following the structured process of tying safeguards to their specific vulnerabilities (as defined in the CVE or through penetration testing and other means) is the ability to accurately justify and defend the investment in appropriate safeguards. This is sometimes referred to as the ROI or security.
THE ROI OF SAFEGUARDS: DO SECURITY SAFEGUARDS HAVE A PAYOFF?
Sound security has always made common sense. Cars have seatbelts, buildings have fire sprinklers, and access badges are commonplace. No one seems to question these fundamental technical security safeguards. However, the value of security safeguards for information is, for better or worse, somewhat less obvious. Decision makers and resource planners often demand to know what they can expect in return from an investment in information security safeguards.
One of the most elusive goals of all security practitioners is the security ROI calculator. Often, security experts are called on to justify security expenses. And many decision makers like to look at every corporate investment in light of how soon the investment will pay for itself. Calculating ROI is the most widely accepted way to measure anticipated savings or increased revenue generated from expenditures. There are a variety of metrics used to assess the value received from the investment. For security, the ROI is normally built around the consequences of the risks that are averted.
Most numbers currently in use by proponents of ROI calculations for security fall in the FUD category—fear, uncertainty, and doubt. This approach is aimed at trying to scare the decision maker into making the necessary investment. The approach seeks to instill fear by showing the potential security losses as astronomical and highly likely. Inexperienced or newly minted security practitioners seek to create an aura of immediacy with these inflated numbers, yet they most often tend to alienate the people they are meant to impress.
For many years, an industry trade association has published the numbers used by so many security practitioners hoping to make a point. These numbers are purposely so large as to be almost meaningless. By describing something on so vast a scale, you are basically trying the end the point in your favor simply by using the biggest number you have in your list of supposed facts. However, little or no academic rigor was actually applied. The numbers are an amalgam of estimates compiled from estimates made by other people. On top of that, many if not most of the respondents who provided these numbers in the survey had a vested interested in seeing the possible or projected loss from threats to be as large as possible. Basically, the numbers have absolutely no statistical validity.
There are still numerous ongoing efforts aimed at developing a ROI model for information security safeguards. However, ensure that you have evaluated the statistical underpinnings and various assumptions and estimates that may be included. Often security practitioners hurt their case by inappropriate use of inaccurate numbers.
Another problem exists when it assumed that all vulnerabilities are holes or software bugs. Such is not the case. This concept was developed and presented in the chapter on vulnerabilities and would be valuable to review in light of understanding ROI for safeguards. Fixing software errors and other problems can certainly have a positive impact on security, but does not provide the security practitioner with all the safeguards required.
One significant area of safeguard ROI that has been proven is the value of incorporating security safeguards into the systems design process. Estimates range from improvement in the low double digits to orders of magnitude depending on the study in question and the type of system under study. The lower estimates are usually derived from the analysis of software development efforts that place an emphasis on safeguards and the larger for complex, large-scale systems that ultimately require a comprehensive risk assessment and safeguard upgrade to maintain confidentiality, integrity, and availability attributes of the information to transmit, store, and process.
There has even been one ROI study that established a baseline by leaving a system without safeguards and running a series of attacks replicating an external, hostile, structured threat. Then they added safeguards to the system and ran the same series of attacks. After several iterations of the test, they arrived at a security ROI represented by a curve. The curve supposedly represented the trade-off between what an organization would spend on security and an estimate of the amount of security provided for the information resources.
Assessing these types of parameters will produce data that are more defensible than speculation; however, a quick comparison to a broader risk assessment will show that this approach is also fundamentally flawed. The attacks are simulating only one type of attack. The external, hostile, structured threat (or hacker) is not representative of the full spectrum of human threat. Insider threats as well as nonmalicious threats are completely ignored or are assumed to represent no risk.
Another fundamental flaw of this approach is an overreliance on technical safeguards. Without explicitly citing procedural and human factors safeguards, it can be easy to assume that these add little or no risk mitigation value. The procedural and human factors safeguards associated with the technical safeguards that are priced for this study are either included as a cost factor or simply assumed to exist with the associated technical safeguard. Because the hierarchical dependencies of the safeguards are not explicitly included in the analysis, a comprehensive safeguard implementation cannot be specified.
One affiliated aspect of this approach is that the term survivability is used in place of the word security. Although this may seem a minor semantic difference, it actually represents a significant departure from the more classical understanding of security. As we have already defined security, a recap is unnecessary here. The term survivability implies an overreliance on the security component of availability at the expense of confidentiality. It also patently ignores the vital attribute of information integrity.
Another fuzzy metric used as an alternative to the security ROI calculation is the subjective comparison to similar industry or organization. This can also be referred to as industry best practices. Many decision makers prefer to conservatively follow the trails blazed by their industry leaders. These people rely on replicating those programs with a proven track record for success.
When searching for appropriate industry best practices with regard to safeguard implementation, it is critical to assure the organization behind the information. Many best practices guides are vendor-produced road-maps that, not surprisingly, feature the vendor’s products as the centerpiece of the standard. Organizations that have highly effective programs, especially security programs, are usually unwilling to share that information, because they can no longer control its distribution and use. The most problematic aspect of industry best practices for information security is that often, simple knowledge of the safeguards employed can encourage attackers.
Fundamentally, information security safeguards lend themselves more easily to analogies to insurance policies. If you have paid for life insurance the past 20 years and you have not yet died, does that mean the monies you used to pay for that insurance were a wasted investment? Security safeguards are analogous to exercising, eating right, and taking out a good family insurance policy. You buy it, use it, and manage it to prevent and deal with undesirable consequences. Sometimes the threat never materializes and sometimes you are rewarded for your investment.
Ultimately, it will be the insurance industry that finally drives more effective metrics for IT safeguards. Insurance companies seeking customers will be able to sell risksharing products that will cover their customers in the event of information compromise. Recently, this has come to be known as hacker insurance. However, actuarially driven insurance companies will be able to define metrics that capture a comprehensive view of threats as well as the complete understanding of the value of information.
As organizations with valuable information assets see the value in these insurance products, insurance companies will competitively strive to provide the best product for the best price. To do so, they will need to accurately assess the amount of risk mitigation provided by various safeguards and combinations of safeguards. Discounts will be provided to customers who follow certain standards or use certain products. Only then will the true science of risk management metrics be achieved and be able to accurately define an effective ROI for security safeguards.