Establishing a Comprehensive Network Security Policy

A comprehensive network security policy is a contract amongst all the stakeholders in an organization. It spells out clear rules for how to protect an organization’s people, information systems, and network devices both from external and internal threats. According to Request for Comment (RFC) 2196, “The Site Security Handbook,” a security policy is: “… a formal statement of the rules by which people who are given access to an organization’s technology and information assets must abide.
” Also, according to the same RFC:
“The main purpose of a security policy is to inform users, staff, and managers of their obligatory requirements for protecting technology and information assets. The policy should specify the mechanisms through which these requirements can be met. Another purpose is to provide a baseline from which to acquire, configure, and audit computer systems and networks for compliance with the policy. Therefore, an attempt to use a set of security tools in the absence of at least an implied security policy is meaningless.”

According to Cisco’s Security SDLC, we must first determine whether we have anything of value to protect. Whether our assets are intellectual property, an inventory of items, people, or precious commodities, the assets must be defined and valuated at the outset of the Initiation phase. This demonstrates the need for a network security policy, risk assessment, and the ongoing maintenance of the secure network. These are detailed in this section. Understanding these principles teach you valuable context in which to remember the details. This is important for the exam and also for that real world that we work in!

NOTE
RFC 2196, “The Site Security Handbook,” is referenced in Appendix B, “Need to Know More?” It is an excellent, plainly written, and common-sense approach that can be used as a template to network security policy planning and implementation.

Defining Assets

We’ve seen the attackers in Chapter 1, “Network Insecurity.” We know their motivations. We can infer from this that whatever the type of organization, there is something there that an attacker wants. It might not have any monetary value to the attacker, but an organization always has assets that it needs to protect from access and DoS attacks. Figure out what you are protecting. The first step in developing a comprehensive security policy is to define an organization’s assets. What constitutes an asset?

Anything that others might want.
Processes, systems, and data that is critical to an organization’s operations.
Anything that, if compromised, would stop an organization from conducting its affairs.

Placing value on these assets is a separate exercise, as we see in the “Risk Management” subsection later.

The Need for a Security Policy

Remember the axiom, “Security is a process, not a product”? No surprise then, that a security policy, which defines the objectives and rules for that process, is never finished. It is a living document, a contract between all the stakeholders in
an organization to constantly revisit and evolve an organization’s security posture in the face of new threats and technology.

Three Reasons for Having a Security Policy

Why do we need a security policy? Here are three reasons. Security policies serve to do the following:

Inform stakeholders (users, staff, and managers) of their respective responsibilities.
Specify security controls/mechanisms (administrative, technical, and physical).
Create a baseline from which to improve security.

EXAM ALERT
Know these three reasons for security policies. They’re sure to be on the exam!

Three Things That Security Policies Do
What do security policies do? Comprehensive security policies contain highlevel statements that set out and outline management’s position with respect to protecting an organization’s people and data and how these goals might be accomplished. Specifically, the security policy defines rules for the following:

Protection. Provides confidentiality, integrity, and availability protection for people and information.
Expected Behavior. Defines the rules for expected behavior (see the Exam Alert).
Consequences. Specifies the consequence of security violations.
Investigation. Authorizes staff to investigate security violations.
Monitoring. Authorizes and designates staff to monitor and log system activity.

EXAM ALERT
The Acceptable Use Policy (AUP) is the component of the security policy most visible to users and the most common. The AUP sets out very specific rules as to what constitutes allowed versus not allowed behavior to prevent misinterpretation. For example, an AUP might list the specific websites and types of websites that users are prohibited from visiting. Not coincidentally, an effective AUP can help promote productive Internet use.

Policies

Groan … not policies, standards, guidelines, and procedures! This sounds like a lot of writing, meetings with people who love legalese, and people with big sticks making sure that the policies are enforced. Many texts do not do a good job on differentiating this important terminology. Essentially, there is a hierarchy here:

Policies do specify overall statements of direction, management position on security issues, organization goals in the context of security, definitions of roles, and so on.
Policies do not stipulate the details of day-to-day implementation.

Standards, guidelines, and procedures are derived from policies. These stipulate the details of day-to-day implementation per the last bulleted point. Policies do not answer “how,” but they do variously answer “who, what, when, where, and why.” See if you can determine in the following list which of “who, what, when, where, and why” the policy type answers.

There are three types of policies, as follows:

Governing policy
Technical policies
End-user policies

Figure 2.4 shows how these policies relate, and the following section describes them in more detail.

Governing Policy

Note that there is only one governing policy because it is the over-arching, high-level policy that describes security concepts that are important to the organization as a whole. The audience is management and technical custodians.

Technical Policies

These policies are more detailed than the governing policy. The audience is technical custodians. They detail the security responsibilities required to address specific systems or issues. For example, a technical policy might specify the policies for site-to-site confidentiality of data and physical access controls, but not how it might be accomplished. Examples of technical policies include the following:

General policies
Email policies
Remote-access policies
Telephony policies
Application policies
Network policies
Wireless communication policies

End-User Policies
These documents specify the details of all security topics that are important to an end user. An example of an end-user policy is the AUP.

Standards, Guidelines, and Procedures

Now that the policies are in place, let’s develop a plan for their actual implementation and enforcement. Policies are too general. Standards, guidelines, and procedures detail the specific “how” the policies are implemented. While agreeing that they are related, what is the difference between standards, guidelines, and procedures? Here are some definitions.

A security policy is compared against standards. Standards can be differentiated from other security policy elements in these ways:

They define the measuring stick against which the efficacy of security controls is judged.
.Standards result in consistent, uniform application of specific technologies.
Standards are usually mandatory.

Security policies also include a number of guidelines. Guidelines can be differentiated from other security policy elements in these ways:

Guidelines are similar to standards but not usually mandatory.
Guidelines create a general envelope of rule application that remains more flexible than standards.
Guidelines can aid in standards development. Guidelines can be tightened up to standards if they prove effective.
Guidelines are used to ensure adherence to more general security policies.
Some widely-accepted guidelines include the following:
- NIST Computer Security Resource Center
- NSA Security Configuration Guides
- The Common Criteria “standard”
- Rainbow Series

The arms and legs of a security policy are found in its procedures, as follows:

Procedures are usually required.
Procedures are the most granular—the lowest level of all.
Procedures contain detailed steps to accomplish certain tasks.
Procedures contain step-by-step tasks to implement policies, standards, and guidelines.
Procedures are sometimes known as practices.

Who Is Responsible for the Security Policy?

Generally speaking, there are three main groups of stakeholders responsible for the security policy: senior management (or owners), security staff, and users.

Senior Management. Ultimately responsible for the whole security policy, its operation, and implementation.
Security Staff:
- Senior Security/IT management (CSO, CIO, CISO).
  Responsible for the security policy.
- Senior Security/IT Staff. Have input on the security policy, possibly drafting parts of it.
- Security / IT Staff. Responsible for implementing the security policy. These are the “foot soldiers.”
End Users. Responsible for complying to the security policy.

Risk Management

As was seen in the section “Defining Operations Security Needs,” the first part of the “Cisco System Development Life Cycle for Secure Networks” was the Initiation Phase, where security categorization and a preliminary risk assessment occurred. Refer to Figure 2.1.
Risk management has two components, as follows:

Threat Identification. This is the process of identifying the threats faced by a system or network. This is sometimes called threat modeling.
Risk Analysis. This is the process of estimating the probability and threats that a system faces. Two principles are adhered to:
An estimate of potential loss can be calculated for each risk.
Strive for worst- and best-case estimates.

Risk Analysis

The main purpose of risk analysis is to try to quantify the possible impact or loss of a threat. There are two categories of risk analysis:

Quantitative. Using asset value as a starting point, develop a mathematical model to come up with a monetary figure of expected losses.
Qualitative. This is a scenario-based model. This is particularly useful for countries, large cities, and states where it is impractical to list all assets (the starting point for quantitative risk analysis).

Because quantitative risk analysis assumes that risk can be determined mathematically, it stands to reason that there should be a Quantitative Risk Analysis Formula. Figure 2.5 illustrates the formula and the variables that can be plugged into the formula.

EXAM ALERT
Memorize the formula in Figure 2.5 and the meanings of the variables.

It’s fun to plug numbers into the formula and see what pops out, but in the end, it’s only a bit better than guessing. In most organizations, the risk assessment teams use a combination of quantitative and qualitative methods to determine the risk factor of a specific threat. For example, who determines whether the exposure factor (EF) of a tornado is 75% destruction of a place of business for any single occurrence? It might be easier to estimate the annualized rate of occurrence (ARO) based on weather data, but what value is an annualized loss expectancy (ALE), which is itself a product (literally) of three estimates? The best that can be hoped for is to provide some measure of the relative risks of specific threats.

The numbers generated also help justify the expense of implementing a comprehensive security policy and focusing costs where they can be of the most benefit. Here is an example of applying the Quantitative Risk Analysis Formula. What is the Annualized Loss Expectancy (ALE) of a knowledge worker carrying a new laptop through airports in a given year?
AV of a laptop = $1,500

EF of carrying the laptop through airports is estimated at .25% based on industry data. ARO of carrying the laptop is estimated at 48 occurrences because the knowledge worker will take 24 trips abroad in a year, and each visit will require the worker to go through an airport twice. Answer: ALE = $1,500 * .25 * 48 = 18,000 This number means nothing by itself, but when comparing relative risks of other threats, it can help an organization prioritize risks and develop a more effective implementation strategy for its security policy.

Risk Management Versus Risk Avoidance

Why do we have to manage risk in the first place? Can’t we eliminate it entirely? There are two, complimentary schools of thought about risk. These are outlined below. You can either manage risk or run away from it:

Risk Management. Reduces risks to levels deemed acceptable by the system’s stakeholders.
Risk Avoidance. Eliminates risk by avoiding threats entirely. This is not a practical option in the business world where some risk = profits. Even in the public sector this makes no sense. For example, cutting access to an important website such as a weather information portal may in itself increase the risk to the very stakeholders the site is meant to serve.

Risk Management Countermeasures

What are some ways to reduce risk to acceptable levels? Table 2.3 covers some sample threats and possible procedures (remember them?) to counter their risk.

Principles of Secure Network Design

The first principle of secure network design is to understand that the finished product, a secure system, is never truly finished.

The traditional approach is to develop a security policy, taking into account business needs and risk analysis, as well as industry best practices, as depicted in Figure 2.6. This security policy is implemented, leading to a secure system. Ongoing security operations are carried out by security staff (see “Who is Responsible for the Security Policy?” in an earlier section). Then we stop, right? Of course not! Unless we are lazy or lax, we use what we learn during the operation of the secure system to improve the secure system (arrow “A” in Figure 2.6), as well as the overarching security policy. Similarly, organizations should constantly educate themselves using industry best practices to improve the secure system in real-time, as well as to incorporate this knowledge in the security policy (arrow “B” in Figure 2.6). This requires some flexibility in the security guidelines. As long as the standards dictated by the security policy are met or exceeded, this shouldn’t present a problem.

NOTE
Referring to Figure 2.6, Security Ops include incident response, monitoring, maintenance, and auditing the system for compliance on an ongoing basis.

Realistic Assumptions

History has proved that many security controls are breached simply because the secure network design was based on incorrect assumptions about the vulnerabilities, risks, and threats that might target the system. Unfortunately, one key wrong assumption may have a ripple effect in impacting other related systems. A good secure system design will have built-in resilience against its own design flaws and will be modular enough in design that when flaws are discovered, they can be corrected without rethinking the whole architecture. Designing a system without single points of failure would be one principle to achieve this goal. You have heard Murphy’s Law before: “Anything that can go wrong, will.” A good network design assumes that it is impossible to anticipate everything that can go wrong, but nevertheless we should be prepared for everything that can go wrong to key systems. Here is a summary of design factors that follow the realistic assumptions principle:

Failure Scenarios. What if an element fails? Is the security impact isolated? Does it affect other systems?
When an Element Fails. Adopt a fail-open or fail-closed approach for the failure of key components of your network, subject to the security policy.
Attack Possibility. Identify vulnerabilities and try to identify possible attacks that can be leveraged against them.
Attack Probability. Evaluate a realistic probability that the system might be compromised. Don’t assume that because a technology is new and that an attack has not yet been invented to compromise it, that it won’t happen.
Evolving Technology. Keep up to date on the latest technological advances and factor them both into your security policy, the secure network, and operations.
Human Element. Assume people will make mistakes leading to an unintentional system compromise.
Review. Subject your assumptions to peer review.

Concept of Least Privilege

The concept of least privilege is no element (users, programs, hosts, and so on) should have more than the minimum privileges necessary to perform a task. Because not every repercussion of a compromise can be planned for or even seen, following the concept of least privilege minimizes the possibility that an unanticipated compromise may have system-wide consequences. This might be the single most important principle of secure network design. Here are two examples of the concept of least privilege:

Example 1. If a user has no system administrative level of authority, it is much less likely that a compromise of this account will lead to a privilege escalation.
Example 2. A compromised web server in a DMZ is less likely to be used to attack an internal network if the router that establishes the DMZ is configured to allow only Network Time Protocol (NTP) to be initiated to an inside network from the DMZ.

Design and Implementation Simplicity

It has often been said that, “Complexity is the worst enemy of security.” A military corollary is, “No plan survives first contact with the enemy.” So, these sayings mean that designing a network security architecture is doomed to failure?
Not at all! Simply put, complexity can lead to unintended interactions with other systems when a network is under attack. The simpler a design and implementation is, the easier it will be to 1) anticipate; and 2) deal with feature interaction. The not-inconsequential side benefit to a simple system is that it is more likely to be embraced by the users as it is likely also simple to understand. Users not only need to be educated in the system; they have to believe in the system as well. How can they embrace the security goals of a security policy and its procedures if they don’t understand the system that implements them?

Security Awareness

All the stakeholders (senior management, security staff, and users) require awareness, education, and training. Keeping up on industry best practices, technological innovations, and the operation of your own secure network are essential to maintaining the living security policy and the resultant secure system.

CCNA Security Study Notes