Of the vulnerability scanning, penetration testing, and IT security audits, IT security audits generally require the least amount of in-depth technical knowledge but the most organizational agility and negotiation skills. The heart of any organization’s information security is its security policy. All information security is built on security policy; consequently, routinely assessing the policy’s effectiveness is critical to an organization’s ability to protect its information assets. Quite frequently, a poor performance during a penetration test is an indicator of greater problems with security, right down to the underlying policy. You might be asked to conduct an IT security audit as part of regulatory compliance, and this chapter will help you plan for it.
Although on the surface, the goal of a security audit might appear to be ensuring that security policy is followed, with the notable exception of regulatory compliance, this is a cursory viewpoint. Except in cases of regulatory compliance assessment, the primary goal of an IT security audit is to assess the effectiveness of the organization’s ability to protect its information assets.
For assessment purposes, overall IT security can be divided into three primary components:
Policy
Processes and procedures
Operations
Security policy can be defined as the bylaws of information security for the organization, but in reality it addresses more than that. Security policy also captures the security posture of an organization, which is illustrated in how the policies are written, the ways in which they are viewed by the organization, and the extent to which the IT staff is versed in them. When you are assessing IT security policy, it is important to not only assess the policy for completeness (all relevant areas are addressed) and comprehensiveness (each individual area is covered completely), but also to assess how the security policy influences the security posture of an organization.
There are three general types of security policies. Each is based on its primary method of enforcement:
Administrative policies
Technical policies
Physical policies
Administrative policies are enforced by management or by user compliance. Generally, operating systems, applications, and physical controls provide little to no enforcement of administrative policies. For example, your organization might protect plans for a new product currently under development by requiring employees and business partners to read and sign a nondisclosure agreement (NDA). The mode of enforcement of an NDA is the compliance of those who have signed it. Of course, the threat of lawsuits or being fired certainly helps with compliance, but no control based on physical security measures or technology can really prevent employees or business partners from disclosing information.
In contrast to the way administrative policies are enforced, compliance with technical policies is enforced by the operating system, applications, or other technical controls. Technical policies should have corresponding administrative policies.
For example, your organization might have a password policy that requires users to use complex passwords. Your organization defines a complex password as containing at least 10 characters; these characters are uppercase and lowercase letters, numbers, and at least one non-alphanumeric symbol. It is unlikely that all users will willingly comply with this policy. Furthermore, because passwords are often the only line of defense protecting the network from attackers, the risk of leaving compliance up to the users (and administrators) is too great. Therefore, you should have a technical policy that systematically enforces the use of passwords that meet the complexity requirement in the operating system.
Just because you have the technical policy for passwords in place does not mean users will create strong passwords. For example, a user could create the password Password1!. Although this password meets the technical policy, it is not really strong. (See Chapter 15, for more information about weak and strong passwords.) Thus, your organization also needs to have an administrative policy that addresses the difference between a technically complex password and one that is strong.
You enforce physical policies by implementing physical controls to prevent tampering or theft. Because physical security is the cornerstone of any information security measures protecting data on a computer or other device, in some instances your organization will require more than administrative and technical policies. For example, to control which employees enter the data center to gain physical access to a server, you could post a sign prohibiting access to anyone other than authorized employees. You could also install conventional locks or even electronic locks that record entry to and exit from the room when an employee scans his badge. In this scenario, the data center’s security is governed by all three types of policies:
Administrative. The sign that advises that only authorized employees are allowed in the data center
Technical. The electronic locks that systematically enforce which employees can enter the data center
Physical. The construction of the data center that prevents unauthorized people from entering
Note
It is quite common for highly valued assets to be governed by all three types of policies and to have multiple levels of protection through policy. This is an application of the defense-in-depth principle to security policy, which is described later in this chapter in the "Operations" section.
Processes and procedures describe and prescribe how administrators and users comply with security policy. Although the words "process" and "procedure" are used interchangeably, there is a discrete difference in their meanings. A process is a set of actions or functions that bring about a desired result, whereas a procedure is a series of steps that someone follows to accomplish a goal. The key difference is that processes are inactive, whereas procedures are active. For example, your organization likely has both a process and a procedure to create a user account for a newly hired employee. The process might read something like this:
The human resources department creates a new employee request form with the new employee’s personnel information.
The IT security department receives the new employee request, creates the account, and sends the hiring manager an encrypted e-mail message with the new employee’s account information.
The hiring manager provides the account information for the new employee.
In contrast, the procedure for creating the new account might read like this:
Open the Active Directory Users and Computers MMC.
In the New Employees OU, right-click Employee Template, and select Copy.
Enter the new employee’s information provided in the new employee request.
Create an initial password by using the first three letters of the employee’s last name, the first three letters of the hiring manager’s last name, with case preserved, and a random 16-bit number. For example: SmiBoa55487
Complete the account creation e-mail and send it to the hiring manager.
Note
Both processes and procedures are necessary to ensure compliance with security policy. A process without a corresponding procedure or set of procedures can introduce security vulnerabilities.
In the new account creation example, if no procedure existed for creating the password for a new account, an administrator could use a blank password or create a weak password, such as password. If no process was in place for creating new accounts, an administrator could create the account with a reasonably strong password but distribute it in a non-secure manner. Processes and procedures are different but both are important.
Whereas policies provide the bylaws for information security, and processes and procedures provide the methods of compliance, operations largely determines the actual level of security that an organization possesses. Policies, processes, and procedures are all well and fine but when they are not followed, they are entirely useless. Operations ensures that they are followed.
Analyzing the degree to which policies, processes, and procedures are operationalized is ostensibly what is primarily measured in an IT security audit; however, on another level, you also need to assess each for its own effectiveness in isolation. For each component, you should ensure that these four basic principles are embraced:
Defense-in-depth. Combining people, operations, and security technologies to provide multiple layers of protection to a network by defending against threats at multiple points within the network. A single layer is often ineffective against multiple attacks. By using defense-in-depth, if an attack breaks through one point of defense, other defenses provide additional protection to the asset.
Least privilege. Consistently granting a user, resource, or application the least amount of privilege or permissions necessary to perform the required task. Practices such as using default or full control permissions on resources, or giving user accounts administrator rights, simplify administration to a dangerous degree. Granting excessive permissions can introduce numerous vulnerabilities that attackers can easily exploit.
Minimized attack surface. Limiting the number of access points to your network. The concept of an attack surface describes points of entry that an attacker can exploit to penetrate the network. A network with few exposed areas or vulnerable points has a minimized attack surface. A network that has several unprotected connections to the Internet has a larger attack surface than a small, isolated network with a single, secured connection to a branch office.
Avoidance of assumptions. Reducing the chances of unanticipated failure of policies, processes, and procedures by avoiding assumptions. For example, your organization might have a policy that requires administrators to "securely dispose" of hardware that is no longer used. If administrators are assumed to understand how to comply with this policy, and processes or procedures are not provided, ambiguity about requirements will almost certainly result. Very likely, this would lead administrators to follow the path of least resistance when interpreting the policy.
You must allocate time to plan your audit. During the planning stage, before you create the project scope and timeline (discussed later in this chapter), you should consider several areas that might determine how you conduct the audit or report the results:
Legal
Regulatory
Operational
Organizational
Increasing attention is paid to how organizations, both public and private, are protecting their data and any private information they collect; this private information is known legally as personally identifiable information (PII). With this concern over PII, disclosure of potential lapses in security could have negative ramifications for an organization, ranging from bad public relations to lawsuits. Consequently, if your security audit turns up areas where security is not up to par, you will face two situations. First, you will need to articulate your findings carefully and only to the appropriate audience. Pay careful attention to how you phrase your findings to avoid the impression of impropriety or making potentially damaging statements, especially ones that call out negligence. Second, you might be obligated to immediately fix the issues that you find. In some cases, you might be required by law to report certain findings to your customers or business partners. Taking effect July 1, 2003, California’s Information Practices Act (IPA) mandates:
...a state agency, or a person or business that conducts business in California, that owns or licenses computerized data that includes personal information, as defined, to disclose in specified ways, any breach of the security of the data, as defined, to any resident of California whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person.—California SB 1386
The law is quite specific. If you find out that your organization has reason to believe it was compromised, your organization would be faced with making a disclosure that is potentially embarrassing and financially damaging. The chance of this occurring is remote, but if you ask the questions, you need to be prepared to accept the answers. Before conducting an IT security audit, you should discuss the following with your organization’s legal team:
The scope of the audit
How the findings will be reported
How issues will be escalated
The confidentiality of the findings
Many organizations are now subject to security and/or privacy regulations, and many others might soon face similar regulations. For example, banking and most financial services entities are subject to the Gramm-Leach-Bliley (GLB) regulations, which include both security and privacy elements. Hospitals, doctors, and health care organizations are subject to the security and privacy regulations in the Health Insurance Portability and Accountability Act (HIPAA) of 1996.
More Info
You can find more information about GLB on the Federal Trade Commission’s website at http://www.ftc.gov/privacy/glbact/glbfaq.htm, and more information about HIPAA on the United States Department of Health and Human Services’ website at http://www.dhhs.gov/ocr/hipaa.
If your organization is covered by these or other regulations, be sure to incorporate the regulations into your audit. By incorporating them, you can help your organization locate and fix potential violations, or provide assurance that your organization is in compliance.
In a perfect world, you could conduct your security audit without interrupting your organization’s business activities; however, we do not live in such a world. For example, during holidays, which might at first appear to be a good time to conduct a security audit, your organization could be completing end-of-the-year transactions as well as end-of-the-month transactions. Holidays can thus be the busiest time of the year and the least tolerant of distractions and disruptions. A security audit will not only require the attention of the auditors but also of the administrators and IT managers of the business unit. You should plan your security audit well in advance to ensure you minimize disruption.
You often hear politics referred to as the eighth and all-trumping layer of the OSI model. Though this is usually said in jest, it is perhaps no more real than when the word "audit" is mentioned. For IT managers, few things evoke more bitter feelings than the thought of the internal auditor digging around their network, nitpicking at the tiniest issues. Unfair or not, these are the images that audits inspire. As you plan your IT security audit, be sensitive to this: although your goal is not to find fault, an audit inherently measures success or failure. Unfortunately, completing a security audit without the cooperation of IT management is impossible. That said, you must minimize the impact of the negative emotions connected with audits:
Clarify goals. Always remember that the goal of the IT security audit is not to find fault or place blame, but rather to serve as an essential step in improving security. By stating this clearly at the beginning of the audit, you can avoid starting off on the wrong foot. For a well-performing IT department, the audit can be a welcome opportunity to quantify its ability to secure information or can provide a launching point for improvement.
Be specific about audit criteria. No one likes to be judged against unknown standards. Being specific about the audit criteria makes IT managers and administrators feel more comfortable because they know what the outcome of the audit will be.
Notify IT managers well ahead of time. The goal of the security audit is to improve security, not to place blame, so notify the IT manager whose department will be audited well ahead of time. Doing so enables the IT staff to self-assess and make appropriate changes before the audit begins, and they will be better prepared to work with you to complete the audit.
Be positive. Avoid verbalizing shock or dismay if you find security problems, even if they are indeed shocking. Your strong reaction will create an adversarial or threatening environment, which will not be conducive to your overall goals. Rather, document what you find, make positive suggestions about how to improve the situation, and listen for mitigating factors. Perfectly legitimate reasons might explain your findings, but these could easily be lost if you foster the wrong relationship with the IT staff. For example, an IT staff member might have been told to lower the priority of securing an internal Web server to dedicate more time to an Internet-facing Web server farm.
Undertaking a security audit without advanced planning is a recipe for disaster. In fact, an incomplete or poorly executed audit might be worse than having no audit at all. Here is a basic process that you can follow to organize a security audit in your organization. You might need to add steps to meet your organization’s specific needs.
Build your audit model or framework.
Set the scope and timeline for the audit.
Obtain appropriate legal and management approval.
Complete the audit.
Analyze and report the audit results.
A good audit assesses the organization’s ability to secure information at the policy, processes and procedures, and operations levels. These three components, as discussed earlier in this chapter, are central to your organization’s security; therefore, build your audit framework around them. Here’s another way to think of these three components:
Policy | "What you must do" |
Processes and procedures | "What you say you do and how you do it" |
Operations | "What you really do" |
A very simple yet very effective framework for auditing security is to simply compare the items in the preceding list. By using this model, you can ensure that senior management, who usually owns the policy; IT management, who usually owns the processes and procedures; and IT staff, who operates the network, are in alignment regarding their security posture. Ideally, what you must do is also what you say you do and what you really do, meaning that the security policy has corresponding processes and procedures that are documented and followed by administrators and users on a daily basis.
Note
There will likely be discrepancies, but that does not necessarily mean there are security problems: the policy might be out-of-date, or administrators could have invented a more efficient process for carrying out their tasks while maintaining the appropriate level of security.
This framework will also locate omissions, that is, places without a defined process for carrying out a security policy. Two other major benefits of this model are ease of documentation and the criteria specificity.
With this model, your documentation template is practically created for you. You can parse your organization’s security policy into a database or spreadsheet and add columns for processes and procedures as well as operations. This format could be simply a binary field or a rating system. For example, you could use a four-point system for each area, as described in Table 5-1—the lower the score, the better the department is fairing. This type of a scoring system tends to be effective when you are tracking improvement over time. In fact, if you use this type of scoring system, you can create measurable criteria that can be used to calculate security bonuses for the IT staff. For example, IT administrators could receive a bonus for improvement by a certain percentage from year to year or for achieving a score lower than the number of policy elements in your database (meaning that the department is net-exceeding compliance).
Table 5-1. Scoring Compliance
Score | Definition |
|---|---|
0 | Exceeds compliance |
1 | Meets compliance |
2 | Needs improvement |
3 | Nonexistent |
When you use this model, the audit criteria will not be a surprise to anyone and will encourage IT administrators to spend time examining and thinking about your organization’s security policy. Because the audit is based entirely on your organization’s security policy, it will be difficult for IT managers or administrators to use ignorance as a defense of poor audit results.
Figure 5-1 illustrates this framework for auditing IT security. Whether or not you choose to use this model, having a framework for objectively evaluating and tracking improvement is essential to conducting good security audits.
By setting a clear scope and a realistic timeline for accomplishing your audit goals, you can avoid scope creep—the ever-widening expansion of projects that eventually results in late deliveries and going over budget. When you define your scope, including what is not covered is often as important if not more so than including what is covered. For example, if you set out to conduct a security audit of your organization’s customer database management but will not be auditing the Web server farm that provides front-end Web services to the data, clearly state in the scope definition that this component will not be included. Two goals are served by doing this. First, you will be able to preemptively clear up any potential confusion over what parts of the customer database system will be audited. (In your organization, people might hear "customer database" and automatically assume that both the front- and back-end systems are included.) Second, each member of your project team will be on the same page.
Tip
Failure to define what is not included in the scope could result in a misunderstanding about the actual scope of the audit.
Creating a timeline for conducting the audit that includes milestones will help you track progress and calculate costs and also help you and your project team drive the project to completion.
After you have a framework for the security audit, a proposed scope, and a timeline set, consult your organization’s legal department about any potential issues. For example, suppose that as part of your security audit you want to assess whether users and administrators are following your organization’s password policy. To accomplish this, you plan to extract the password hashes from the account database and use a password-cracking tool to reveal the passwords. Although you have a secure process and trusted personnel to carry out this assessment, privacy laws in the countries where some of your users live restrict the cracking of passwords. After working with the legal department, you learn that you can still carry out the assessment legally by comparing the password hashes to a database of known weak passwords by using a function that returns only a binary value, regardless of whether it is known as weak.
Before starting your audit, your last task is to get management "buy-in" and approval. Be sure to inform the business owners and managers who are included in the scope of the audit. Not only is this the proper and courteous thing to do, but as mentioned earlier, you will need their cooperation during your audit. When gaining buy-in and approval from management, be clear about the goals for the audit, what you will need from them, and what they will be responsible for at the conclusion of the audit.
Easier said than done, right? Once you have approval from management, you can begin the audit. If you are using the framework recommended in this chapter or a similar statistical framework for the audit, you will look at a lot of data that you do not note in the official documentation. Consequently, you should have a system for documenting what data you have seen to prevent looking for the same document more than once. As you complete the assessment, you will probably be working closely with the IT administrators that you are auditing. Because you need their cooperation and they might feel threatened or intimidated by the specter of the audit, spend time building a good working relationship with them.
After the investigative portion of the audit is complete, you can analyze the results and report your findings to management. During this phase, you have your greatest opportunity to add value to the audit, and you have choices about how to phrase your results. For example, you could point out this in your audit:
The customer database security is poor. In many ways, it is wide open to an attacker because of known security issues with SQL servers and no patch management process.
By using a more positive and proactive tone, you might produce this:
The security on the database could be greatly improved by checking the server for known issues with this configuration and creating a patch management process. This would also bring the database into compliance with company policy.
You could improve this statement even more by specifying the issues discovered and including details for future reference.
The final step in a security audit is to create a schedule for remediating the issues turned up in the audit.
More Info
See Chapter 6, for more detailed information about reporting your results.
Q. | Do you need to hire an auditor to do a security audit? |
A. | No, although most auditing companies now offer IT security auditing. Before you hire security auditors, find out what methodology they would use and whether the auditors actually have any experience with security. |
Q. | Are there any audit standards for security like the generally accepted accounting principles for accounting? |
A. | Although several efforts to create a standard have been made, the closest thing existing at the time of this writing is ISO 17799. You can purchase a copy from your nation’s official standards body. |
Q. | Are other audit methodologies freely available? |
A. | Yes. The United States National Institute of Standards and Technology (NIST) has developed a framework and methodology called ASSET. You can download the ASSET guidebook from the NIST Computer Security Resource Center at http://csrc.nist.gov. |