Excerpt from Network Security Auditing

Excerpt from Network Security Auditing. Auditing is one of the most important aspects of maintaining a secure IT system.

E-mail this to a friend

Newsletters: Sign-Up & Save! Receive Special Offers, Free Chapters, Articles Reference Guide Updates, and plug into the pulse of what’s happening in your corner of the industry by subscribing to InformIT newsletters! FREE coupon after sign-up!

Try Safari Books Online NOW! Access the largest fully searchable e-reference library for programmers and IT professionals!

Do you want to know a secret? Security isn’t about hacking, nasty, malicious software or the vulnerability of the day. Security is about maintaining a system and process that provides access to critical data without exposing your company or customers to excessive risk. Auditing is one of the most important aspects of maintaining that system, because it provides the opportunity to test assumptions about the security posture of networked systems and compare that posture with standards and regulations. Auditors ask the questions “How do you know that you are secure?” and “Can you prove that your security technology works?”

The purpose of this chapter is to introduce the key principles of auditing and to describe the auditing process.

Security Fundamentals: The Five Pillars

Auditing the security of a company requires that you have a good general understanding of what security is and what it is not. To understand security, it is critical that you realize that security is a process, not a product. Security is not a race with a finish line at the end, as you can never be 100 percent secure no matter how much money or time you spend on it. It’s just not possible to anticipate every vector of attack; but, with the appropriate planning and protective strategies in place, high levels of security can be achieved. Cisco is, fortunately, in a unique position to help companies achieve their security goals by providing the tools necessary to embed security features into many aspects of the network. This means security can be leveraged as a system to better map to the policies, procedures, and more importantly, the business drivers that cause companies to want to safeguard their assets.

To understand security and to audit it as a system, you need to be able to identify how everything ties together conceptually. Security is a broad topic, and one of the few in information technology that literally touches all aspects of a business. From the data center to the break room, every function of a business has its own list of things that need to be protected from a certain level of risk. Managing risk is one of the most important factors in developing a strategy for protecting people, technology, and data. To focus security efforts and to make them manageable, it helps to break down the various aspects of security into the five pillars of security. Figure 1-1 shows the five pillars.

Figure 1-1

Five Pillars of Security

Assessment

The first step in protecting your company’s assets is to assess the environment. Most people (thrill seekers excluded) wouldn’t try to walk across a busy intersection with a blindfold on because not being able to see if the light is red or green could lead to a bad day. Understanding the business environment and direction helps identify the areas that the business deems most important and subsequently the most sensitive to disruption of services or theft. Much of what an auditor is asked to do in assessing risk requires sufficient knowledge of how the organization operates. Assessments document and identify potential threats, key assets, policies and procedure, and management’s tolerance for risk.

The assessment process involves asking pointed questions. Just as if you were building a house, you would first start by surveying the land (available technology) to determine how suitable it is to build on. You would also need to know if the area is prone to flooding (threats). How often does it flood (threat frequency)? Do you have the appropriate permits (laws and regulations)? What are the job site rules (policy and procedure)? What technology can you use to quickly and effectively build (technological components)? These questions and many more help the business plan a strategy for accomplishing its goals. Asking similar questions of the company’s security enables you to examine various scenarios to identify weaknesses in defenses or procedures. What is the probability that you will be hacked tonight and have a “CNN moment” tomorrow? It’s hard to say without a thorough assessment of the business and technology.

Assessments are not something that are done once and then forgotten. As the business needs change and new services and technologies are introduced, regularly scheduled reassessments should be conducted. Doing this gives you an opportunity to test policies and procedures to ensure that they are still relevant and appropriate.

Prevention

Many engineers focus on technology when they think of prevention. True prevention is more than a firewall or a security appliance: It encompasses administrative, operational, and technical controls. Prevention is not just accomplished through technology, but also policy, procedure, and awareness.

Policy must be documented and enforced with strict rules and consequences for violation. Documented procedures that utilize good security practices can help prevent misconfiguration, which is one of the most common methods that attackers use to compromise a system. Helping users understand what is and is not permissible, in addition to consistent and fair enforcement, goes a long way to lowering the overall risk to a company.

Too often, organizations fixate on trying to prevent bad things from happening when in reality, they simply can’t stop everything. The magic box that Vendor X sells you can never anticipate all vectors of attack. This is where the concept of defense in depth comes into play. Defense in depth assumes that no control is perfect, so it helps to layer defenses so that you can compensate for known or unknown weaknesses in a technology or control. Technical security controls such as a firewall or intrusion prevention systems provide an important role in keeping a network secure, but they are not a silver bullet that you can plug in and expect to solve all of your security problems. Expect individual security controls to fail, but plan for the event by using multiple levels of prevention.

Detection

Your car’s alarm system is one form of detection. Balancing your checkbook at the end of the month is another form of detection. Detection is how you identify whether or not you have a security breach or intrusion. Without adequate detection mechanisms, you run the risk of not knowing whether your network has been compromised. Dr. Eric Cole, author of Network Security Bible, said it best: “Prevention is important, but detection is a must.”¹ If you can’t detect a compromise, then you run the risk of having a false sense of trust in your prevention techniques.

One example of the importance of detection can be seen in the 1996 disclosure by Ohio University of hackers who gained access to systems that resulted in the loss of over 137,000 Social Security numbers. These miscreants had total access and control for over a year! Obviously, detection mechanisms were either nonexistent or were not properly monitored. Of course, the worst example I have heard about that highlights poor detective controls is from the United States Department of Agriculture, who announced in 2007 that it exposed over 150,000 farmers’ Social Security numbers because its database became live in 1981. Because no one can say for sure when it was actually connected to the Internet, over the 26 years it was active, it is estimated that the data was easily accessible for well over 10 years. Not a good thing!

Detective controls help to identify security incidents and provide visibility into activities on the network. It’s important to detect an incident early so that you can formulate an appropriate reaction to recover services as quickly as possible.

Reaction

When prevention and detection are effective, reaction time is greatly reduced. No one wants to find out that they have a breach, but if you do have a compromise you need to do something about it now! Reaction is the aspect of security that is most concerned with time. The goal is to minimize the time from detection to response so that exposure to the incident is minimized. Fast reaction depends on prevention and detection to provide the data and context needed to recognize a security breach. Of course, just knowing about a compromise doesn’t help if you haven’t planned out in advance what to do. This planned and coordinated response is called incident handling. Some companies have a dedicated incident-handling team that can move in at a moments notice to reduce exposure time. Not everyone has the budget for these types of teams. Even if your company doesn’t have a dedicated team, some forethought and planning can mean the difference between everyone falling all over themselves trying to figure out what to do next and restoring key services.

Automated response through technology is an important tool that reduces your reaction time to a security incident. But as good as automated response technologies are, you still need skilled people to handle the incident to ensure that the incident is real and not a hiccup on the wire. How quickly and efficiently incidents are handled is one of the most important tests to the effectiveness of a company’s security program. When the alarms go off, how you react can make all of the difference in the world!

Recovery

When your company has an eCommerce system that simply must be available to your customers or it processes hundreds of thousands of dollars in sales a minute, downtime is relatively easy to quantify. Recovery is where you play detective to determine what went wrong so that you can get the systems back on line without opening up the same vulnerability or condition that caused the problem in the first place. Do you patch the exploited vulnerability and recover the data from backup or do you have a bigger flaw in security controls that allowed the incident to occur? What was the reason that the system was compromised? How did the technical controls fail? Was there a misconfiguration? The recovery phase doesn’t end with bringing the system back online. There is also the post-mortem aspect that determines what changes need to be made to processes, procedures, and technologies to reduce the likelihood of this type of vulnerability in the future. As an auditor, you must ensure that the organizations you audit have a plan for recovery that addresses these issues.

Building a Security Program

Policies, procedures, and standards represent the foundation of a security program. These are the documents that detail the who, what, when, and how of protecting your business assets and resources. Yet, as important as these documents are, many organizations still don’t have a formal policy and procedure set for information security. If you ask the average IT professional about his company’s security policies and procedures, more often than not he will be hard pressed to answer your questions or produce a current copy. With regulatory compliance requirements such as SOX, GLBA, HIPAA, and PCI, this has started to change, but policy and procedure are still put low on the list of priorities. If they don’t help the company sell more widgets, then why would the company do it? The reality is that policies and procedures are how you plan for and hopefully reduce the risk of bad things happening to your data. When you work on a car or an airplane, there is a set of procedures that you should follow to ensure that you are consistently performing the correct operations in the appropriate order. It is essential to have security procedures documented before hand, so that you reduce the risk of having those “extra” parts at the end of the job or worse (in the case of the airplane), a major problem that puts lives at risk.

An essential part of the auditor’s job is to examine an organization’s policies, procedures, and standards to ensure that they are complete, enforceable, and followed.

Policy

Policies are essential for all businesses regardless of size or industry. They act as a social contract between the company and its users that define acceptable behavior with corporate resources. Policies also provide guidance on how a company approaches security by defining why the security measure is in place, what is being protected, and to whom the policy is applicable. An organization should receive its guidance about the technologies and controls that need to be implemented based on the goals defined in the policy. Think of it as the blueprint for building the structure of the security program. Just as you wouldn’t go to a lumberyard and build your house based on the wood and nails available, you should not implement security products and technology without a solid policy. At a minimum, a good security policy includes the following:

• 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:

Risk, as it relates to information security, can be defined quite simply as the probability or likelihood that a threat will exploit a vulnerability and cause damages. Although this definition might sound simple, there is some work that needs to be done to figure out the values you need to build your equations. There are two main approaches to risk analysis; one is quantitative and the other is qualitative.

The quantitative approach uses formulas to equate the frequency of a risk to a monetary value. These formulas themselves are not particularly complex, but the data used to feed the variables can be time-consuming and difficult to compile. Most of the data that exists is historical, and the rate of change that is seen in technology makes it difficult to maintain accurate values. In security, you don’t have actuarial tables that give the average number of incidents per type of company or industry—similar to what is seen with insurance claim data—because most organizations simply do not track security incidents accurately or consistently. The most widely used source for this type of data generally comes for the yearly FBI/Computer Security Institute report on cyber crime. This report provides the number of reported incidents in various categories, such as data theft or security breaches; however, you are on your own to figure out what these events cost, as it is different per company and employee. You might have a worm infect a laptop, causing a user to be unable to work for a day. Calculating the technician time in reloading the machine might give you two hours at $60 per hour or $120 for that incident. What is often under reported is the total cost in productivity and lost data. You have the technician’s time accounted for, but what about the individual who can’t do his job because of the downed laptop? What about the lost report that took two weeks to complete and now must be rewritten because key files were corrupted? It’s more difficult to quantify those types of losses. Still many, organizations have standardized on quantitative methods for risk analysis. Auditors must be aware of how these formulas work. Here are a few classic examples:

• Single Loss Expectancy (SLE) = Asset Value x Exposure Factor: SLE is a formula that determines the expected cost of loss to an asset based on the exposure to the event that the asset incurs. The exposure factor represents how much damage there is as a percentage of loss to the asset. The percentage of loss ranges from 0 (no damage) to 100 percent (total loss). Unless there is complete destruction of the asset, the exposure factor is less than 100 percent. If a web server database worth $100,000 is corrupted during an attack, and the backup is able to recover only 70 percent of the data, then the exposure factor would be $30. A $100,000 asset x percent (EF) = $30,000 loss.
• Annual Loss Expectancy (ALE) = Single Loss Expectancy x Annual Rate of Occurrence: The ALE calculation uses the output of the SLE formula and multiplies it by the expected number of occurrences of the event in a single year. If the web server is hit by an attack twice a year, then ARO would be 2. If you have never been hit but estimate that you will experience an attack sometime in 10 years, then ARO would be 0.1. After you determine the ARO, you can then multiple it by the SLE to determine the ALE:

• $30,000(SLE) x 2(ARO) = $60,000(ALE)

• Countermeasure Value = ALE Before – ALE After Annual Countermeasure Cost: To determine how much you should spend on countermeasures to reduce the risk to assets, you can use the data generated by the previous functions to build a cost benefit analysis to help justify the purchase of a new countermeasure. During the post-incident analysis, it was determined that the attack could have been prevented through a combination of an IPS and better backup software for recovery. The total cost of the new countermeasures is $10,000. If you have $60,000 (Before ALE) – $20,000 (after ALE savings from the new countermeasure) – a $10,000 countermeasure cost, then you have added $30,000 of “value” to the organization by purchasing the countermeasure. This enables you to determine that purchasing this countermeasure is a good use of your security investment and saves the company $30,000.
• Return on Security Investment (ROSI) = (ALE x Percent of risk mitigated) – Countermeasure cost) / Countermeasure cost: The ROSI calculation is used to determine a return on investment value for a security countermeasure. You utilize ALE and multiply it by the percentage improvement in effectiveness of the new countermeasure and then subtract it by the cost of the countermeasure. Then you divide the total by the cost of the countermeasure, to determine the rate of return. To arrive at a Risk mitigation percentage, you should test the equipment in a lab or rely on a neutral testing organization to determine an appropriate effectiveness rate. Continuing with the DoS example, your $60,000 (ALE) x 80 percent (increase in risk mitigation based on testing) – $20,000 (cost of the countermeasure) you get $28,000, which would be how much you should save from the increased effectiveness of the countermeasure. If you divide $28,000 by $20,000 (the cost of the countermeasure) you can hope to realize a return on security investment of 140 percent. Not a bad deal!

Although none of the quantification techniques described are 100 percent accurate, there is still value in having a consistent and replicable way to determine how an organization invests in security. These are simple examples that require research and time to increase accuracy. Because a large number of companies don’t have the time or inclination to do this level of number crunching, the qualitative methods for determining risk have become increasingly popular.

Qualitative risk analysis is less concerned with the numbers, and more interested in finding which assets are exposed to the greatest level of risk. The power of the qualitative approach is that it can provide a measurement tool that anyone can understand without majoring in statistical analysis. The results are actionable, and the rating system can be anything that the organization is comfortable with, such as high, medium, and low. The variables threat, vulnerability, and exposure are similar to the quantitative approach, but the ways in which we arrive at the values are quite different. The qualitative approach uses the following simple formula:

Risk = Threat x Vulnerability x Impact of Exposure

Assets are what you must try to protect, and those assets can be a database, business process, network access, or anything else that is an important part of how you do business. The easiest way to identify threats is to use the CIA triad of Confidentiality, Integrity, and Availability. These three areas represent the primary aspects that businesses attempt to protect, so if you measure your assets against CIA, you can determine potential threats to that asset. Confidentiality is keeping data private and out of unauthorized hands. Integrity is about ensuring that unauthorized parties do not tamper with data. Availability is concerned with keeping the service or system up and running.

After you determine your potential threats, you need to classify them based on the likelihood of an event happening. There are always potential threats out there, but some of them are just not practical. That’s where the vulnerability aspect of the formula comes into play. A threat with no vulnerability is still a threat, but there is no risk to the asset because if any one of the variables is zero, then risk is zero. Risk depends on the presence of a threat and a vulnerability. Take, for example, the threat of a teardrop attack. The teardrop attack took advantage of a vulnerability in the IP stack where a maliciously crafted fragmented packet with overlapping offsets could cause a kernel panic or blue screen of death. In 1997 this was a real risk because the vulnerability was present in a large majority of Windows and Unix-derived IP stacks, and the threat of someone using this attack was great due to easily accessible exploit code. Unless you are running very old or devices that aren’t patched, this is not something you would be concerned with today. The risk of this attack to modern operating systems is virtually nonexistent.

The last variable in the simplified risk equation looks at the impact to the organization if the threat is successful. If the threat is stealing customer credit card information, you can feel confident that the threat level is high because there is significant evidence that there are plenty of individuals with the skills, resources, and inclination to engage in this type of crime. If a company houses its customers’ credit card information in a database that is connected to an Internet-accessible web server, then the potential for a vulnerability that could be exploited is also high. The impact of this event could be high, too, because customers do not forgive a company that experiences a breach like this. Based on this simple scenario, you can determine that the risk is high to this asset and it would be wise to focus your efforts on protecting the asset by providing controls and countermeasures that can reduce the risk of a compromise happening.

The point of all of this is to make sure that the organization that is being audited has addressed these issues in a manner that reduces the total risk to the organization. Auditors need to understand how to perform risk analysis to determine whether or not the controls are in place and appropriately address the level of risk to the asset. The auditor’s role is also to provide recommendations for reducing risk, and that takes us to the next area of risk management: risk mitigation.

Risk Mitigation

After you have determined that there are legitimate risks to the company’s assets, the next step is to figure out how to address those risks. The goal of most risk-management programs is to prove that the organization has preformed “due diligence” or “due care”. Due diligence and due care are legal terms that seek to determine whether a company or individual has been negligent in their duties. In the case of information, security organizations need to act (and document those actions) in a manner that secures business assets to a level that is prudent and reasonable given their value and risk. This prudent man rule is another aspect of law that comes up often when discussing risk mitigation. Directors and managers might be held personally liable for negligence of duty, if it is proven that they did not provide the necessary environment to protect the assets they have been charged with securing.

  It is important to involve legal council to ensure compliance with local and federal law. I am not a lawyer (I don’t even know any good lawyer jokes), and this book isn’t a substitute for good legal advice.

Mitigating risk is not simply about buying a product or writing a policy. Purchasing technology can be a component of addressing risk, but there are a number of options available. The following list details the choices a company must make when managing risk.

• Accept the risk: A company can choose to accept a risk for many reasons. If the probability of a threat successfully exploiting a system is unlikely or the cost to protect the system is so high that it would be cheaper to recover the system in house, then an organization might choose to accept this risk as part of doing business. The danger here is in underestimating the total cost of an exploit and not fully realizing the impact of the event to the business or customers.
• Avoid the risk: Sometimes in business, the reward is just not worth the risk. Companies might choose to not conduct business in a way that opens them up to risk. If you have a retail establishment and store credit card information on your Point of Sale (POS) systems as part of your processing of daily transactions, you run the risk of credit card information being stolen because you have this data scattered across all of your POS systems in all of your stores. You can avoid this risk by not storing the data on the POS system and simply running your credit card transaction through a headquarters-based clearinghouse with much higher levels of security.
• Transfer or share the risk: The simplest mechanism for transferring risk is to purchase an insurance policy. Other ways include outsourcing the risky service to a third party and building in strict service-level agreements (SLA) and contracts so that they are responsible for securing the data. Of course, regardless of who is “responsible” for an incident, there is still the damage to reputation that can occur with a data breach.
• Reduce or mitigate the risk: Implementing controls and countermeasures are how you can reduce or mitigate risk. You can avoid the risks on the Internet by simply unplugging external connections, but you lose all of the benefits that a global marketplace gives you. Purchasing countermeasures and implementing controls is a much less drastic response to protecting your systems.
• Ignore the risk: This is the most dangerous of all options, because it can have dire consequences to shareholders and the organization as a whole. Ignoring risks does not make them go away and could cost your company everything in the end.

Risk in the Fourth Dimension

No, this isn’t the section about Euclidean geometry or a discussion about Einstein’s theory of relativity (I know you are disappointed!). Instead, the Fourth dimension as it applies to information security is about time. Time is important in security because it enables us to measure the effectiveness of countermeasures based on how long they are exposed to a particular event. When you think about the security of your data, how well do your countermeasures stand up to a sustained attack? When you want to purchase a safe, time is one of the most important factors in picking the correct one to do the job. If you go out and purchase a safe for your valuables, you have to decide what level of protection you need because no safe is impenetrable. Given enough time and the right resources someone can get into it. Safe manufacturers know this, so they rank their safes based on how long it takes an expert to break in. This is called Net Working Time and is displayed on a sticker or other label to indicate how well the safe did. If it is rated as a TL30, it should take an expert with grinding wheels, high-speed drills, saws, and hammers 30 minutes to get in. Of course, the time could be significantly less if you have a little C4, but you run the risk of an accident and destroying the items inside. A safe with TRL30 should withstand all of the hand tools and a gas-cutting and welding torch. The safe isn’t designed to prevent someone from getting in forever, just long enough for you to detect that he is there and hopefully catch him before he makes off with your valuables.

The concept of using time as a measurement tool for security is not new. Many people have contributed to this concept, but Winn Schwartau was the first to write a book applying these techniques to information security. Schwartau’s book, Time Based Security, details how to use time as a mechanism to determine whether or not the countermeasures are sufficient. This methodology—although not the only one to consider in risk assessment—gives us another tool that puts risk-management strategy into fairly simple terms that can help identify the areas that need the most attention. The following formula can be used to determine exposure time:

Exposure = Detection + Reaction

This technique uses detection and reaction as variables to measure potential exposure time to an incident. If you have a fire, the quicker you can detect it and react to it (put it out), the less damage you will have. Let’s work through a quick example.

Let’s say there is an organization selling vitamins on the Internet through an online shopping cart. The company operates its own web server and database and processes credit cards through its website. A new vulnerability in the web server is discovered and an exploit code is released that can enable an attacker to gain control of the server. On average the security analysts review vulnerability reports every 24 hours. After a vulnerability is detected, it takes about two hours to update the server and bring it back into operation. The formula to represent this scenario would look like this: Detection (24 hours) + Reaction (2 hours) = 26 hours. This means that there is an exposure time of roughly 26 hours. For those 26 hours, any customer placing an order can have his credit card information stolen, or the database itself can be siphoned off by the attacker. Many organizations do not have people dedicated to monitoring these types of events 24/7, so the detection time is drastically different. You can, however, easily see that you have a major problem that requires you to do something to tilt the equation back to the correct direction.

Prevention technologies can be used to decrease detection and reaction time, reducing exposure. An IPS appliance can decrease detection and also reaction time based on new signatures being deployed. If an IPS receives a new signature every 4 hours, then your exposure in the previous example would be cut by 22 hours. Using a web application firewall might completely prevent a successful attack of this nature in the first place, changing the organizations exposure time to zero.

Utilizing time-based security measurement provides a relatively simple method of determining how effective countermeasures are in real-world scenarios.

How, What, and Why You Audit

So far this chapter has spent a lot of time talking about the fundamentals of security, covering many areas that are essential knowledge for someone performing an audit. Auditing is most concerned with risk and how that risk is addressed. Are the controls put in place effective at protecting the assets? The only way to know is to test them. That is why the role of the auditor is so essential to good security. This section discusses the details of the audit process and provides an overview of the types of audits and key aspects that help make an audit successful.

Audit Charter

So what’s the difference between a hacker and an auditor? Permission. The auditing, by nature, includes having access to sensitive data and systems. This function is defined by an audit charter, which is a document that defines the purpose, responsibility, authority, and accountability of the auditing program. This document helps to clearly define the requirement for performing audits and provides justification as to why the auditor should be given access to critical systems. An audit charter usually applies to an internal corporate auditing organization and will include the following:

• Purpose of the auditing function
  • Create a mission statement.
  • Set goal objectives.
  • Define the scope.
• Authority
  • Access rights to audited systems.
  • Obtain support of personnel to accomplish audit goals.
  • Use technology to test auditing controls.
  • Perform risk assessment.
• Responsibility
  • Develop audit plan.
  • Maintain professional expertise.
  • Issue reports on results of audits.
  • Make recommendations for reducing risk.
  • Maintain integrity and professional standards.
• Accountability
  • Report deficiencies about control effectiveness to executives.
  • Provide reports about the current risk.
  • Ensure the organization complies with standards and legal requirements

Engagement Letter

When an outside party performs an audit, an engagement letter must be obtained. This document functions in a similar manner to the audit charter, but is usually written per project. It includes many of the same items as the audit charter but is more specific about the deliverables of the current engagement. The engagement letter includes:

• Authority
  • Who contracted for the audit
  • Rights of access to systems
  • The signature of the company executive
• Responsibility
  • Scope of the audit
  • Specific deliverables
• Accountability
  • Who is to receive the final report
  • Agreed upon completion dates

Types of Audits

Audits can be broken down into a number of types, from the simple analysis of security architecture based on opinion, to a full-blown, end-to-end audit against a security framework such as ISO27001. The difference between types of audits is in what the auditor based the findings on and how detailed the audit’s scope is.

Security Review

A security review is when you examine the security posture of an organization based on professional experience and opinion. Think of a security review as a site survey. In this type of examination, you look for issues that stand out as a way to help define the starting point for further activities. Running a vulnerability scanner such as Nessus would fall under this category. The tool generates a list of potential security issues, but the data must be analyzed further to determine on what needs to be acted on. This is the most basic form of security analysis and the primary output is in the form of an opinion. Examples include:

• Penetration test
• Vulnerability scan
• Architecture review
• Policy review
• Compliance review
• Risk analysis

Security Assessment

Security assessments utilize professional opinion and expertise, but they also analyze the output for relevancy and criticality to the organization. The analysis aspect of an assessment attempts to quantify the risk associated with the items discovered to determine the extent of the problem. If you have two servers with the same vulnerability, but one is your financial server, and the other operates as a print server a security assessment would rank the financial server as a high risk and the print server as a lower risk based on the severity and damage potential. The biggest differentiator between an assessment and a review is the depth to which the auditor examines the system and analyzes the results. Examples include:

• Vulnerability assessment
• Risk assessment
• Architecture assessment
• Policy assessment

Security Audit

A security Audit examines the organization’s security posture against an industry standard (ISO27001 or COBIT) and/or regulatory compliance such as HIPAA or PCI. An audit includes review and assessment; it also conducts a gap analysis against standards to measure how well the organization complies. Audits take into account people, processes, and technologies, and it compares them to a benchmark in a standardized and repeatable way. Examples include:

• Compliance audit
• Policy audit
• Procedure audit
• Risk audit

The Role of the Auditor

The role of the auditor is to identify, measure, and report on risk. The auditor is not tasked to fix the problem, but to give a snapshot in time of the effectiveness of the security program. An auditor might be asked to make recommendations about what needs to be done to fix a deficiency in a control, but the objective of the auditor is to report on security weakness. Auditors ask the questions, test the controls, and determine if the security policies are followed in a manner that protects the assets the controls are intended to secure by measuring the organization’s activities versus its security best practices.

The auditor functions as an independent advisor and inspector. The auditor is responsible for planning and conducting audits in a manner that is fair and consistent to the people and processes that are examined. Auditors must have appropriate access and cooperation or the audit runs a risk of not being successful or worse, not identifying critical items that could jeopardize key systems. The auditing charter or engagement letter defines the conduct and responsibilities of an auditor.

Depending on how a company’s auditing program is structured, ultimate accountability for the auditor is usually to senior management or the Board of Directors. The auditor must be independent of the business entity being audited or the impartiality of the audit can be called into question. Auditors are usually required to present a report to management about the findings of the audit and also make recommendations about how to reduce the risk identified.

Conflicts of interest can preclude an auditor from conducting an assessment of a particular system or organization. If you were the one that installed the firewall, it doesn’t make sense for you to also be the one to audit it. Auditors are expected to excuse themselves from an audit if they feel that there is a potential for a conflict to exist.

Places Where Audits Occur

Depending on the scope of the audit, an auditor can be asked to examine many different systems and processes. When defining the scope, the specific items to be audited fall under the category of policy, procedure, or control. Some audits are concerned only with policy review and nothing else, whereas other audits might assess all aspects of security by looking at all three areas. Regardless of how detailed the audit becomes, the three categories are not islands unto themselves. They represent interlocking components of the overall security strategy.

Policy Level

Auditing policy entails examining current policy to ascertain whether or not the policy meets the objectives of the business. It should be specific enough while not being so specific that you can’t change your firewall rules without changing the policy. The policy itself should stay consistent regardless of how you accomplish executing the objectives of the policy. Of course an auditor might also find that the organization does not have a policy for a potentially risky business system, which would mean that the auditor would recommend the creation of a policy and give examples based on industry standards. Policy is the cornerstone of security, so care and attention need to be paid in the creation of these documents. Techniques for auditing policy include:

• Categorize policies into Administrative, Operational, and Technical.
• Ensure that the policy meets business objectives.
• Check for compliance to ensure the policy is being followed and enforced.
• Compare it against best practices (SANS, ISO, and COBIT).
• Identify gaps.

Procedure Level

Procedures represent how a company implements policy. Here is where all of the detail resides on how the company will go about protecting its assets. From an auditor’s perspective, procedures provide a lot of information in creating checklists to measure how the business applies policy and controls. If a company has a policy that requires all systems to have a personal firewall installed, configured, and active at all times—but does not have a consistent procedure documenting how the firewall is to be configured—then the company will more than likely have a hard time enforcing this policy. These are the kinds of areas that auditors can help with by recognizing deficiencies in policy implementation and recommending solutions to improve security. Techniques for auditing procedures include:

• Compare procedures to policies to ensure that the procedures follow the spirit of the policies.
• Check for configuration compliance.
• Compare procedures with industry standard practices.

Control Level

Many audits and assessments are focused on the control level. Controls can be technical, administrative, or physical, and they can represent a key component in reducing risk. The auditor is concerned with whether or not the control provides a level of protection greater than the level of risk. Techniques for auditing controls include:

• Test control functionality.
• Inspect configuration.
• Inspect logs.

The Auditing Process

The auditing process can be easily broken down into a number of phases. Each phase builds on the last with the ultimate product being a report that documents the findings of the audit. Having a good framework to conduct an audit makes the process run smoothly and helps to eliminate opportunities for mistakes and inconsistencies that reduce the accuracy of the audit. The phases of an audit are:

• Planning phase: Audit the subject, objective, and scope.
• Research phase: Plan, audit procedures, and evaluate criteria.
• Data gathering phase: Gather checklists, tools, and evidence.
• Data analysis phase: Analyze, map, and recommend.
• Audit report phase: Write, present, and file the audit report.
• Follow up phase: Follow up, follow up, and follow up!

Planning Phase: Audit Subject, Objective, and Scope

The first and most important phase of auditing is in determining the overall strategy of the audit. What is the purpose of the audit? If the audit is in response to regulatory compliance requirements, the auditor must compare processes and procedures with those mandated by law. Alternatively, an audit of a newly installed firewall would have a different objective and be specific to one particular control. To figure out the degree and depth of the audit, there is a bit of work that needs to be done before sending the first test packet or stepping foot on site:

Research Phase: Planning, Audit Procedures, and Evaluation Criteria

Once you determine what the goal of the audit is, the next step is to formulate a plan for accomplishing the objectives of the audit. This phase will include:

• Identify the resources needed: skills and technologies.
• Identify the organizational structure, process, and data flow.
• Determine who in the organization under audit should be interviewed or involved.
• Identify logistics information, such as which facilities or locations need to be reviewed.
• The procedures used to test controls must also be identified, including what types of tools will be used.
• Measurement and evaluation criteria should be selected (for example, COBIT, ISO27001, or PCI Technology Standards).
• Review corporate policies and procedures.
• Build auditing checklists.

Data Gathering Phase: Checklists, Tools, and Evidence

Data gathering is the phase in which the auditor conducts the actual audit itself. The checklist that was created in the research phase is used to measure compliance with the standards and practices that were selected as benchmarks. The checklist acts as a guide that directs the auditor on where to look and what to expect. Many tools might be used to test the various controls to determine functionality and to generate the evidence that is used later in the analysis phase. The auditor looks to find “proof” or evidence of compliance with policy and standards. The auditor does the following:

• Examine system documentation.
• Conduct surveys on the effectiveness of policies and procedures.
• Conduct interviews of key personnel.
• Observation of systems and process in action.
• Review previous audits to look for trends.
• Review logs and reports.
• Inspect technical control configuration.
• Statistical sampling of data transaction.
• Run security analysis tools to verify technical control effectiveness.

Data Analysis Phase: Analyze, Map, and Recommend

After the auditor has gathered all of the evidence, the next phase involves analyzing what is discovered. This analysis requires an auditor’s experience and professional knowledge to determine how to prioritize any deficiencies identified. If the audit is done in response to regulatory compliance requirements or industry standards, then the auditor should also map the observed controls to the applicable standard or law to identify if anything is missing or incomplete. Finally, most audits also have an opinion component where the auditor must state his professional opinion regarding the effectiveness of the organization’s controls, and recommend solutions about how to improve the quality of the control to reduce risk. The actions in this phase are:

• Categorize and identify evidence gathered during the audit.
• Analyze policies and procedures for effectiveness.
• Prioritize risks and rank according to severity.
• Map identified controls to industry standards or regulatory compliance requirements.
• If required, make recommendations on policy, procedure, and technology improvements.

Audit Report Phase: Write, Present, and File the Audit Report

Authoring the audit report and presenting it to management is one of the most critical phases of the audit. Articulating the deficiencies found and recommendations about how to reduce risk are the primary reasons why the auditor is engaged in the first place. The report should include an executive summary and detailed findings about how the deficiencies discovered apply to the business. The report should not just be the output from a Nessus scan, but actually clarify why a particular vulnerability is determined to be critical or low risk. Recommendations about how to address each audit exception should also be included. The auditor shouldn’t just drop off a stack of papers but also present the findings in a meeting between management, the auditor, and key stakeholders. This gives the auditor a chance to clarify findings and answer questions that might arise as the organization digests the audit report. After the report has been presented, the final work papers should be filed as proof of the audit. Auditing is not just about showing that you understand what needs to be done; it’s also about proving it! This phase includes:

• Create a clear and concise report detailing risk.
• Write an executive summary that highlights critical items.
• Present the audit findings to management and key stakeholders.
• Develop solutions to address audit exceptions.
• Provide all documentation and evidence to be filed by the organization.

Follow-Up Phase: Follow-up, Follow-up, Follow-up!

After the report is filed, that’s it, right? Not quite. It is important to understand that an audit is a snapshot in time. The deficiencies found need to be addressed and should be remedied as soon as possible after the audit occurs. An auditor might be called back after the organization has had a chance to remediate the deficiencies so that the auditor can re-examine the new controls or process. This gives the auditor a chance to get feedback on the solutions chosen. To prevent a conflict of interest, auditors are not generally involved in fixing the deficiencies. This helps to keep the auditor neutral to the situation so that he can be objective and unbiased.

Summary

This chapter covered some of the fundamental aspects of auditing. Providing a risk-based auditing approach that leverages industry standards and best practices is an integral part of a company’s IT Governance strategy. You can’t protect what you don’t know about. Auditing gives an organization the opportunity to test assumptions about how secure its assets and data are. In summary:

• The five pillars of security—assessment, prevention, detection, reaction, and recovery—define the process of security.
• The building blocks of a security strategy are policy, procedures, and standards. Policy is where security strategy is set, while procedures and standards provide guidance about how to accomplish the policies’ objectives.
• Security controls are how an organization prevents, detects, corrects, and recovers from an incident. Many types of controls work together to build a defensive strategy. Building a control table can identify weaknesses in security posture.
• Risk management isn’t just a recommended practice; SOX, HIPAA, and GLBA require it. Assessing risk provides the justification and prioritization necessary to invest time, money, and resources for the areas of security that are critical to the success of the business.
• Auditing is a process and has different degrees and depth. The scope of an audit defines whether or not you conduct a review, assessment, or full audit. The role of the auditor is to report on control deficiencies and risk.

References in This Chapter

Cole, Eric. Network Security Bible, First Edition. John Wiley & Sons, 2006.

Schneier, Bruce. Secrets & Lies: Digital Security in a Networked World. John Wiley & Sons, 2004.

Bejtlich, Richard. The Tao of Network Security Monitoring Beyond Intrusion Detection. Addion Wesley, 2004.

Landoll, Douglas J. The Security Risk Assessment handbook: A Guide for Performing Security Risk Assessments. Auerbach Publications, 2006.

Peltier, Thomas R/Peltier, Justin. Complete Guide to CISM Certification. Auerbach Publications, 2007.

Slade, Robert M. Information Security Management Handbook, Fifth Edition, Vol 3. Auerbach Publications, 2006.

Schwartau, Winn. Time-Based Security. Interactive Press, 1999.

SANS Institute, The SANS Security Policy Project, https://www.sans.org/resources/policies/#question

© Copyright Pearson Education. All rights reserved.