Excerpt from Network Security Auditing

• Purpose: Why the policy exists. This section includes the reasoning behind the policy, potential ramifications to the company if the policy is not followed, and how it supports the corporate mission.
• Scope: To whom or what the policy applies. Is this a policy for contractors or full-time employees? The scope should use job titles or functions to identify the employees instead of an individual’s name, so that the policy is unaffected as people change positions or go on vacation. Does the policy apply to development systems or key customer-facing servers? The scope section provides specifics about the assets and employees covered by the policy.
• Policy statement: The policy requirements. This is the meat of the policy document and includes specific details about what is permitted or prohibited. The wording should be clear and concise and not be open to interpretation. A policy should not include specific products or configurations, as these areas are covered in procedures and subject to change.
• Enforcement: Policy provides an enforcement point for discipline or prosecution in the event that an individual chooses not to play by the rules. Policy compliance is mandated through the disciplinary action statement. The enforcement section provides clear indication about the consequences of noncompliance with the policy and may include employment termination or other disciplinary actions.
• Terms and Definitions: Clarification of terminology utilized in the policy statement, such as SPAM or malware.
• Revision History: Summary of changes to the policy, with date of change, person or group that initiated the change, and a summary of what was changed.

The most important aspect of a good security policy is that the policy be clear, concise, and free of ambiguity. Providing examples helps to clarify the intent of the policy, but care must be taken to provide wording to cover areas that are not specifically mentioned. When writing policy, using imperative verbs such as will, shall, and must are essential to providing actionable direction. Trouble can arise when using subjective verbs such as should, may, and recommend because they represent an ideal state and do not imply a mandatory requirement or call to action. Many policies have been rendered ineffective and unenforceable by using subjective speech because the argument can be made that the policy is simply a recommendation and not a requirement. Telling an employee that he should follow the acceptable use policy is not the same as informing him that he must follow it.

Procedures

Procedures are detailed instruction about how a policy is to be implemented. These documents provide an operations manual that an administrator can use to address bringing a new system online, backing up critical data, firewall configuration, and so on. It is difficult to enforce consistency without a procedural checklist to follow. Each policy document should include a companion procedure document. This enables the organization to update technologies and leverage best practices, while writing down the process and techniques used so that they can be replicated and checked. Procedure documents can provide an auditor with insight into how closely the company under audit follows security processes and makes great checklist material for the audit itself. The following is a list of items found in most procedure documents:

• Purpose: Explains why the procedure is in place and what the source policy is.
• Scope: Explains who is responsible for the execution of the procedure and what situation or technology to which it applies.
• Warnings: Includes safety or security warnings that must be followed to maintain integrity.
• Procedure steps: Detailed procedures that must be followed to configure or provision the technology covered by the procedure.
• Revision History: Summary of changes and when the procedure was last updated or reviewed.

Standards

As a kid, you might have gone to an amusement park excited about getting on the latest rollercoaster only to find out you weren’t quite tall enough to ride. This experience was a painful introduction to the definition of a standard. At the time, you might have thought that the cartoon character cutout that you didn’t measure up to was put there to spoil your fun, but it served a purpose. That purpose was to enforce height standards for the safety mechanisms built into the ride.

Security standards serve the same purpose in that they dictate required controls or configurations that are considered best practices. Requiring alphanumeric passwords of 15 characters or more including special characters is an example of a strong password standard. Standards are the source material for the best practices that are used to create procedures. Fortunately, there are many well-documented standards available for use from standards bodies and Cisco. These standards and how to find them are covered in more detail in subsequent chapters. It is important to understand the reasoning behind a technology configuration or product selection choice that is used to address policy requirements. Cross-referencing procedures to standards documents such as the NIST 800 series or ISO27002 are great ways of justifying configuration and design decisions. With regulatory and industry requirements that mandate that companies exercise “due diligence” in securing their computing assets, it helps to be able to back up those claims through reputable third parties.

Security Controls

Security controls are the building blocks of a security program. They are the tools that you implement to protect the confidentiality, integrity, and availability of important assets and data. Much of the assessment work that an auditor conducts is centered on the many controls that a company has (or doesn’t have) to reduce risk. Auditors are concerned with how effectively the controls accomplish the goals set forth by the security policy.

Controls are typically thought of in terms of technology. Firewalls or IPS systems come to mind, but there are many types of controls that can be used to protect your systems. The primary classification of controls can be accomplished by grouping them under three main categories: administrative, technical, and physical.

Administrative Controls

Administrative controls can consist of policies, such as Acceptable Use or security-awareness training. In addition, administrative controls can also consist of processes such as balancing the corporate books and security auditing. This type of control is typically focused on managing people, such as separation of duties, requirements for vacation, or any other rules that provide a deterrent to fraud or improper behavior.

Technical Controls

Technical controls consist of the technology that you implement to prevent or enforce behavior on the network or computing resources. They can include firewalls, Intrusion Prevention Systems (IPS), Host Intrusion Prevention Systems (HIPS), Role-Based Access Control (RBAC), or any other mechanism for enforcing policy.

Physical Controls

If you want to deter people from walking through your yard, put up a fence. Although this won’t keep everyone out, it is an example of a useful physical control. In an office setting, physical controls include locked doors, key card access systems, video surveillance, guards, gates, and so on. This type of control is designed to restrict access to sensitive devices and areas.

Each of the primary control groups can be further broken out into specific types of actions the control can take. Although there are others, the standard set includes preventative, detective, corrective, and recovery.

Preventative Controls

Preventative controls enforce the confidentiality, integrity, and availability of data and assets. If the primary control is technical, then preventive controls are firewall rules, access control lists (ACL), or another technology used to block unauthorized access. Administrative preventative controls can include things like policies and warning banners. The primary category of controls (administrative, technical, and physical) gives context to how to implement the secondary controls.

Detective Controls

Detective controls are the alarm systems built into various parts of the business to detect if bad things are happening. These can be video surveillance, firewall logs, an IPS, or Security Incident Event Management (SIEM) system. This type of control also includes financial and security audits.

Corrective Controls

Corrective controls are reactionary in nature. An IPS blocking an attacking IP address is an automated corrective control that responds to the detection of malicious activity. A simpler example is a security guard double-checking that a door is locked when performing his nightly facilities check. A corrective control is a mechanism used to mitigate a security incident and is likely implemented after a detective control has discovered the problem.

Recovery Controls

Recovery controls are like parachutes on a plane. Hopefully, you won’t need them, but they are there in case you do. Backup systems, redundant power supplies, and spare parts are all examples of recovery controls. Restoring services is the goal of these controls.

An auditor is responsible for determining whether or not the controls implemented are sufficient to protect the assets or meet the business requirements outlined in the policy documents. Do the controls adhere to best practice and are they in compliance with regulations and law? An auditor might also be asked to provide recommendations about how to improve the controls to better address current risks.

The interaction between the various controls discussed provides a nice view into whether or not a company under audit has addressed its controls in a thorough manner. Table 1-1 provides an example of how an auditor can logically group controls for a remote access (Virtual Private Network (VPN) solution to ensure it has been addressed.

Table 1-1  Remote Access VPN Control Groupings

Managing Risk

You manage risk every day of your life. When you get into a car, the real risk of getting into an accident on the way to your destination exists. This is a risk that everyone who drives realizes, so in order to mitigate the risk of something bad happening, you follow posted road signs, stop at stoplights, and signal before you change lanes. This can help to reduce the chances of something unpleasant happening, but it can’t completely eliminate risk. There is always a person who drives aggressively or runs the red light. To reduce the impact of the event (pun intended)—in this case, a car wreck—you purchase vehicles with airbags, crumple zones, and antilock brakes. These technologies can help minimize potential damages (physical well being is the asset in this case) and hopefully give you enough time to react to the event so you can avoid it or walk away without any major harm.

Technology can help dramatically reduce risk, but only if applied in a manner that puts investments where they can do the most good. Airbags that go off 10 minutes after a wreck (or not at all) don’t provide very much protection. An improperly installed IPS will not provide any meaningful data and can potentially degrade your ability to detect a real attack by generating unnecessary log data. Finding a real attack in this situation is like finding the proverbial needle in a haystack.

How much security is enough security? This is a question that plagues IT managers because there are no easy answers. Most organizations answer this question by implementing a risk-management program. SOX, GLBA, HIPAA, and PCI require a risk-management program because there is no one-size-fits-all approach to securing corporate assets and data. Organizations must understand the risks they face, and the only way to do that is through assessing risk.

Risk Assessment

There are many techniques used to assess risk. Some measure risk through numerical models, and others use experience and professional opinion to measure risk. No matter how good your models are or how extensive your research is, a portion of the equation always has a level of uncertainty. Risk by its very nature does not lend itself to a numeric value that is 100 percent accurate. Of course, if you can unerringly determine whether or not something is going to happen, I am sure you would move to Las Vegas and hang out at the casinos instead! To better understand the various models, it is necessary to define a few important terms:

• Asset: If you took an accounting class, you probably had the whole debits and credits thing drilled into your head. Putting a numeric value to an asset is easy for tangible items such as how much your routers cost or employee payroll, but the real challenge is in putting a value on the intangibles such as goodwill, opportunity cost, or loss of reputation. In summary, an asset is anything of value to your organization.
• Threat: A threat is any type of event that can cause loss and is usually measured in terms of probability or likelihood of occurrence. In the case of viruses, companies can see hundreds of infection attempts a month, so the threat of being exposed (though not necessarily infected) to a virus is close to 100 percent.
• Vulnerability: A vulnerability is a weakness that can result in a threat being able to compromise an asset. Hardware and software vulnerabilities are discovered on a daily basis, but the greatest number of vulnerabilities still comes from default configurations. One other thing to note is that just because a system is “vulnerable” does not mean that the vulnerability can be exploited. Hardening systems by removing unneeded services can help to reduce the potential vectors of attack by preventing access to vulnerable services.
• Cost of Exposure: Cost of exposure refers to the total tangible and intangible cost associated with an asset being compromised. Many times the actual monetary value of an asset is a small portion of its total value to the organization. A $10,000 database server might have 1 million dollars worth of data on it. You have to understand the business processes and interconnections to assess the true cost of exposure. Interdependent systems can grind to a halt if a 25-cent part breaks.

The risk assessment process defined by NIST 800-30 provides an excellent guide to identifying risk to systems and processes. NIST 800-30 utilizes the following steps: