TESTING IS A CRUCIAL ACTIVITY for any IT department because it provides assurances that access controls and other security systems are working as designed. It also illuminates gaps in security that may not be obvious to the casual observer. By testing IT architecture thoroughly and regularly, an organization will know how secure their systems really are, and what needs to be done to make those systems support the organization's security goals.
Access control systems, like any other technology, should work as designed. Unfortunately, like other security systems, access control systems are constantly under surveillance and attack. It is rare for an attacker to hone in on a word processing suite, but an identity verification system is a tempting target. Frequent testing of access control systems ensures that weaknesses are found and can be dealt with before they are exploited.
There is no one correct way to test an access control system. Instead, a solid test should incorporate testing methodologies at different stages of development, for example:
Each of these areas has a place in the design of a good access control system, and should be used in the testing of access control systems. Most access control systems have some software component, which must be tested as rigorously as any other critical piece of software. You will read more about software testing in the next section.
Every access control system has a hardware component. Username and password combinations for a secured Web site depend on access control servers and the underlying networks. Biometric access controls, which you read about in Chapters 9 and 10, require scanners or other input devices. A simple locked door is a strictly hardware-based solution. Even human security guards use surveillance cameras to keep an eye on things. Because hardware is such an integral part of access controls, it makes sense to test it thoroughly.
Any good hardware test should pay attention to both normal conditions and boundary conditions. Boundary conditions are the outermost extremes of test environments. For example, you might test a surveillance camera under normal conditions—a clear, sunny day—but you would also test it at night, during an electrical storm, and during a power outage. The first test will assure you that the equipment is not defective, whereas the boundary tests will let you know how it will perform during extreme situations. An attacker is not likely to strike on a sunny afternoon. Instead, he or she will choose circumstances that provide cover, such as darkness or stormy weather, or will attempt to create cover by cutting off power to surveillance cameras.
Penetration testing is the act of simulating an attack on an organization's resources. Penetration testers use a variety of methods including social engineering, software hacking, and physical intrusion. You will read more about penetration testing later in this chapter.
When designing an application with an access control component, or software to configure and run an access control device such as a programmable lock or biometric device, it is not enough to simply test the finished product. Testing should be built into the entire software development life cycle. Why put such an emphasis on testing, rather than features or bugs? Tests are the only way for software developers to really know how their software will perform under various circumstances, such as a range of good and bad inputs, or normal and high numbers of users connected concurrently.
Writing test cases also forces the developer to think like an attacker and anticipate all the possible data an attacker could put into the software in an attempt to break through the access control system. By thinking like an attacker, the developer can build checks into the codebase to handle bad data correctly instead of crashing or responding unpredictably. Not every system crash is the result of a malicious attack. Sometimes bad data is the result of a legitimate user who simply mistypes his or her password. Regardless of the reason behind bad data, access control software should handle it gracefully. Writing test cases early and often during the entire development life cycle helps ensure that the software is robust enough to handle a wide variety of normal and abnormal situations.
There are seven distinct phases in the software development life cycle:
Planning
Requirements analysis
Software design
Development or coding
Testing and integration
Release and training
Support
Agile software development methods make extensive use of automated testing throughout the development life cycle. When developing in an agile method, you write the test suite for your software first, during the early stages. During the planning, requirements analysis, and software design phases, tests are a tool for accurately defining requirements. During the development phase, tests are used as a coding tool—when the tests pass, you know you're finished. Tests are also run frequently during development to ensure that new code does not break existing parts of the application. Because functional tests have been run continuously throughout the cycle, the testing and integration phase is reserved for user acceptance training, although the automated test suite is usually still run periodically, just to be safe. Finally, during the release and training and the support phases, automated tests that run hourly in the background help pinpoint problems with the software, and will often alert developers of issues before the users encounter them.
The software development life cycle is shown in Figure 14-1. The figure depicts the cycle as a continuous, looping process. Once software is developed and released, future refinements and upgrades require the cycle to start again.
Security features should be an integral part of each phase in the cycle, as you will see in the following sections.
The planning stage is where the stakeholders in any given software project meet to brainstorm what the software should do. It is important that the stakeholders have an awareness of security issues and access controls so that the project does not begin with an inherently insecure concept.
During the planning stage, high-level requirements are defined, and an initial project plan is worked out. At this stage the project plan will not be very fleshed out, except for the requirements analysis stage.
Once the high-level goals for a software project are defined, those goals need to be translated into formal requirements. Formal requirements list each of the major functions of the software product as well as its inputs and outputs.
The deliverables for this stage will be a formal requirements document and an updated project plan. At this stage, areas that should be considered from a security point of view, such as user authentication and authorization, should be noted.
Once formal requirements have been laid out, system architects and software engineers can begin to design the low-level functions that will make up the final product. At this stage, specific access control measures should be designed into the software.
At the end of the software design phase, all the major questions surrounding the implementation of the product should be answered, including screen layouts, detailed implementation of business rules, pseudocode, and a data dictionary.
During the development phase, programmers write and test the actual code that makes up a piece of software. This is the stage where security features are implemented and sometimes flaws or weaknesses make their way into the final product. To prevent unintended security flaws, unit testing should be done continuously throughout the development stage.
In the testing and integration phase, the finished software should undergo full system integration testing to ensure that each piece of the software works properly together. The software must also be tested to ensure that it works well with the rest of the system—the operating system, other applications, and back-end database. The primary goal during this phase is to make sure the new software doesn't break any existing system.
During this phase, the system should also undergo load testing, which measures how the software will perform with an average number of users, as well as how it will perform under extreme load conditions. For example, if the organization estimates that 50 users will use the access control system concurrently, it should be load tested with 50 users, 100, or even 190 users. This proves that the system can handle both an average load and double or triple that load.
During the release and training phase, the software is deployed to production servers, and employees are trained to use it. This is an important opportunity to educate them on the importance of security and access controls in their workday.
The support phase of any software project is where most security flaws come out. When the software is in production and being used every day, weaknesses and flaws will begin to surface. During the support phase, you will begin the cycle again as you plan for upgrades and security patches. Although upgrades and patches will not have the same scope as the initial development, they still follow the same basic software life cycle.
Testing is not limited to software-based access controls. Every security system should be rigorously tested at each point in the development life cycle. Testing security systems requires management and the security team for an organization to anticipate possible scenarios that could circumvent the new security system, and build features into the system to respond to those scenarios. For example, an organization is planning to install a new closed-circuit video surveillance system. During the planning phase, members of the security team should walk through the facility imagining how an intruder might try to sneak in. During this walkthrough, they should note where the cameras could be placed to catch this imaginary intruder.
The life cycle of security systems is similar to that of software, as shown in Figure 14-2. The security system life cycle includes five phases:
The security system life cycle is simpler than the software development life cycle, but just as important.
During the initiation phase, the existing architecture and security systems are documented, and a preliminary risk assessment is conducted. Applicable laws and regulations are identified. The documentation and analysis done during this phase is a crucial step in identifying what type of security system is needed and how it will work with existing systems.
During the acquisition and development phase a more complete risk assessment is completed, and a baseline security level is established. Once this is done, the security team establishes security goals and meets with vendors to choose specific solutions to meet those goals.
Once a new system has been purchased, it must be installed. This occurs during the implementation and testing phase. Unit and integration tests ensure that the product performs as expected and works with existing systems. User training is a significant part of this phase.
Operations and maintenance is the longest of the five phases. During this phase, the system is continuously monitored, incidents are dealt with, and the security team creates or modifies an existing business continuity plan.
Eventually, every security system becomes either unnecessary or outdated and can no longer be upgraded. At that point, a new security system must be purchased and the old one removed. This happens during the sunset phase. The key to this phase is that the old system must be removed without exposing the organization to additional risk during the migration to a new system.
After a new security system has been installed, the old one must be disposed of securely because it could retain information that an attacker could use to gain entry to the organization's facilities. Physical components must be disposed of or destroyed, electronic media wiped clean, and paper documentation shredded or securely archived.
There are two primary activities for any information security team—monitoring/incident handling and testing. Monitoring and incident handling are the day-to-day activities every team does. They run automated scanners, review audit logs, and generally keep an eye on the security status of the IT infrastructure. When an anomalous situation is found, the security team responds by investigating the situation and shutting down the avenue of attack. After a security incident, the security team will investigate the affected systems and perform a damage assessment. They will meet with management to discuss how and why the attack occurred, and formulate plans to repair the damage and harden the infrastructure against future attacks.
Testing and upgrading the system usually occurs annually, depending on the organization and its security goals. The rest of this chapter outlines how most organizations handle testing and upgrades of their security systems. This process varies by organization but most follow this basic procedure.
Before an information security team can purchase and implement a new security system, they perform a basic risk assessment to test the functionality of the old system. This tells the team what major weaknesses exist and need to be strengthened in the new system. It also informs the requirements gathering process. The result of this phase is a requirements document that must be approved by senior management.
Once a requirements document has been written and approved, the next step is to develop a plan for testing including the scope of the test phase. There are several factors to consider when developing a test plan:
Impact—What impact will the testing have on operations? Is some disruption acceptable? If not, testing will need to occur during off hours or be restricted to nonintrusive methods.
Vulnerability—Are there known vulnerabilities to consider during testing? The test plan should exercise known vulnerabilities, but should not be limited to them.
Breach planning—What should happen as the result of a security breach? The test plan should include scenarios that test reactions to a breach.
Gap analysis—Security is a concern across the entire infrastructure. The scope of the test plan should reflect this.
The next sections examine each of these factors in depth.
If it is important for operations to continue without interruption by the security testing team, the test plan must focus on nonintrusive testing methods such as host discovery or port scanning. Host discovery is the process of scanning the network to find out which Internet Protocol (IP) addresses are attached to potentially vulnerable resources such as a Web server or database server. Depending on the purpose of the scan, an interesting discovery may be defined as anything with open ports, or anything running a certain service, or even any box with a connection to the outside world.
Port scanning is a technique designed to probe a network's open ports and look for weaknesses. Ports that are not being used should be closed, but often they will be unintentionally left open by systems administrators who do not think to change default settings. For example, if a machine is intended to be a file server, there should be no reason for port 80—the port most Web servers use—to be open.
Nonintrusive testing methods can uncover valuable information about potential vulnerabilities, and in most cases this information is enough for an organization to justify modifying, upgrading, or replacing its existing security systems. In some cases, positive proof of a given vulnerability's existence and potential damage is necessary. In those cases, intrusive testing is called for.
Some security vulnerabilities cannot be reliably tested in a nonintrusive way. Weaknesses to social engineering attacks are a good example of this because it is impossible to predict how employees will behave in a social engineering situation until they are actually confronted with it. Other vulnerabilities, such as weaknesses to insecure code, are sometimes easy to test in a nonintrusive way. If a security scanner detects that insecure libraries or applications are installed in the environment, they can infer that the environment is vulnerable to buffer overflows, code injection, and the like.
One distinct advantage to nonintrusive testing is the fact that it is often automated. This allows a reliable scan to be performed by IT staff that may not have extensive security training or experience. However, just as you'd secure an IT infrastructure with more than just a firewall, testing the security of an IT infrastructure should not rely on a single method either. If possible, nonintrusive and intrusive testing methods should be used in cooperation to produce a comprehensive view of the status of IT security.
IT crimes are generally crimes of opportunity. Attackers look for weak networks and bypass strong ones unless the resources on the strengthened network are highly tempting. Most of the time, if a network has been hardened, attackers will quickly move on to softer targets. Vulnerability assessment is the first step in hardening a network, and is generally performed using an automated scanning tool.
There are three basic types of vulnerability assessment scanners:
Network scanners—A general-purpose scanner that probes a network for a variety of widely-known vulnerabilities
Port scanners—A specialized tool that probes open ports on a system. An attacker could use these open ports to gain entry to a network
Web application scanners—Scans hosted Web applications for known vulnerabilities. Because Web applications are public-facing, they cannot be locked down as easily as an internal network
All of these scanners are automated software packages that run periodically and produce a report of their findings. When choosing a vulnerability assessment scanner, look for one that updates frequently. Like a virus scanner, it is only as good as its vulnerability definitions. It cannot find vulnerabilities that have only been recently discovered and for which new tests have not been written.
Because of this limitation, it is important to use these automated tools as part of an overall security assessment. IT security teams should keep up to date on new vulnerabilities as they are discovered and reported, and manually check the network for them rather than waiting for the vulnerability scanner to update its tests.
You have many options when choosing a vulnerability assessment scanner. The best choice depends on your organization's needs.
Nmap, or Network Mapper, was originally intended as a network mapping utility. Its port scanning and host detection features can be useful in identifying access points to your network and holes in access controls. The basic version of Nmap is a command-line utility, whereas the Zenmap graphical user interface (GUI) front end adds ease of use, as shown in Figure 14-3. Nmap is an open source utility and is highly configurable.
After Nmap runs, it outputs a report for the user. This report contains a rundown of which hosts are on a network and which ports are open on those hosts. It also contains the common usage of those ports. An example Nmap report is shown in Figure 14-4 in the Zenmap GUI.
Nmap is available at http://nmap.org/.
Nessus is a proprietary security scanner developed by Tenable Network Security. It is network-centric with Web-based consoles and a central server. It is a useful tool for larger security teams handling larger networks. The configuration screen for Nessus is shown in Figure 14-5.
Nessus reports give a good breakdown of which ports are open on which hosts, and any security threats to those ports. A sample Nessus report is shown in Figure 14-6.
You can download a free home version of Nessus at http://www.nessus.org.
Retina is another proprietary vulnerability scanner. It can deep-scan a network, looking for known issues that have not been patched in existing applications. It also scans for open ports. The configuration screen for Retina is shown in Figure 14-7.
Retina's output report gives a good breakdown of network vulnerabilities and the state of the environment in a format that even entry-level security professionals can understand. Retina reports are graphically intensive, which makes security presentations easier to follow. A sample Retina report is shown in Figure 14-8.
You can download a demo version of Retina at http://www.eeye.com.
Security breaches are inevitable. They can occur despite your best efforts to prevent them. Knowing this, incident response and remediation must be a part of any security testing effort. It is simply not enough to scan for known vulnerabilities, patch them, and assume your IT infrastructure is safe. When unauthorized access does occur, there are two stages to a good IT response:
Incident response—The initial response to a security breach. The goal of this stage is to contain or shut down the attack before further damage is done.
Cleanup—The process of examining a system or network to assess how much damage was done, removing any software that was installed during the attack, and looking for new vulnerabilities such as backdoors that the attacker may have created.
Both of these are crucial, and should be tested as part of an overall security assessment. The middle of a crisis is not when you want to discover that your network security expert hasn't read a Bugtraq alert in five years. Incident response testing usually involves bringing in or creating a penetration team, which will be discussed later in this chapter.
To subscribe to the Bugtraq mailing list, go to http://www.securityfocus.com.
Security breach drills are one way to test the ability of IT staff to respond to an incident. These drills can be open, blind, or double-blind.
In an open drill, everyone knows that the incident is a drill and that no real attack is taking place. This is the least intrusive type of security breach response test. In a blind drill, IT staff is not notified that a drill is taking place, but the testing team has full knowledge of the infrastructure. In a double-blind test, the IT staff is not given prior warning of the test. In addition, the testing team is not given information about the infrastructure—they must start from scratch just as an attacker would. This is the most accurate way to test breach response, because it most closely imitates a real attack.
Any security breach drill should end with an incident recap meeting involving management, systems administrators, and testers. At the incident recap, the group should discuss what they learned from the tests, prioritize their findings, and begin the process of remediation.
Gap analysis is the process of identifying the difference between reality—the current state of an organization's IT infrastructure—and the organization's security goals. Every organization has a different ideal security level. Some organizations need the best, most secure infrastructure available. Others can forsake some level of security to gain cost savings and ease of use. Whatever that ideal level is, a gap analysis will inform IT of what improvements need to be made in order to achieve it.
The seven domains of a typical IT infrastructure were described in Chapter 2. A thorough gap analysis covers all seven domains and examines security in each of them.
Gap analysis in the User Domain focuses on user training and day-today practices, and how the practices affect IT security. If users are required to attend an annual security workshop on secure password creation, for example, but then use the same insecure passwords they used before the training, this represents a gap in security that should be addressed through better training and technical enforcement methods.
Most users do not willfully follow insecure practices. In most cases, they simply do not understand the purpose behind security procedures, or they do not know how to follow them successfully. Most users' highest priorities are convenience and task efficiency. They simply want to do their jobs as easily and quickly as possible. Users often perceive security measures as an obstacle to those goals. Creating, memorizing, and typing a complex password with eight or more characters, upper- and lower-case letters, and numeric and special characters, is more difficult and time consuming than a simple four-character password or no password at all. Similarly, it is intuitive for many users to prop open a security door, especially if they are moving equipment in and out of a server room.
It is inconvenient, from the user's perspective, to keep entering a password every time they go in and out of the server room, especially if they are carrying heavy equipment.
An effective training program that generates user buy-in to security practices bridges the gap between users' legitimate need for convenience and efficiency with the demands of a secure infrastructure.
Because the number of workstations in an organization can be very large, automated vulnerability scanners are often the most efficient way to perform a gap analysis in the Workstation Domain. The data derived from a vulnerability scan is only useful when it is compared to the organization's stated security goals. Many vulnerability scanners find vulnerabilities that can only be exploited from within the local network, because the workstations are protected by the network firewall. The gap analysis in this domain should focus on vulnerabilities on workstations that could spread to the local network. They should be run on a regular basis because the state of any given workstation can change at any time.
For example, users—despite thorough training—will occasionally open an e-mail attachment or load a Web page that contains a virus. Many viruses are designed to hide on a system and spread themselves across a local network until a trigger event causes them to deploy their malicious payload. The original user may not even be aware that he or she clicked on a malicious attachment or Web page. Ideally, every data packet downloaded to a workstation should be passed through a virus scanner, but the reality is that many organizations do not have updated virus scanners or users have disabled them to save time. Running a periodic vulnerability scan on the Workstation Domain is a second layer of defense in case a malicious program slips through automated virus scanning.
Gap analysis in the LAN Domain focuses on the network itself. How are resources on the network secured, and could those security measures be bypassed by someone who has access to the network, either internally or remotely?
For example, many networks are set up with a firewall to keep unauthorized users outside the local area network (LAN) from accessing resources on the network. Once inside the firewall, however, there can be a false sense of security that leads to insecurely protected resources. Consider a file server located behind the firewall. Because it is not exposed to outside attack, systems administrators consider it relatively safe and focus their attention on other vulnerabilities. Unfortunately, if strict access controls are not implemented on the file server itself, as well as individual folders and files on the server, a low-level user could easily stumble upon sensitive information such as product designs or financial reports, which they could then disclose intentionally or unintentionally outside the organization.
The LAN-to-WAN Domain is where tools such as a port scanner come into play. This is where you will test an attacker's ability to gain privileged access to the organization's private network through openings between the LAN and the wide area network (WAN).
Many servers come with a default configuration that leaves various ports open, such as those used by Web or File Transfer Protocol (FTP) server software. If those services are not used on a machine, the ports should be closed before the machine goes into production. Unfortunately, many systems administrators forget to do this, leaving an open door for an attacker to gain access from the WAN—usually the Internet—to the LAN. A port scanner will alert systems administrators to ports that have been left open unnecessarily.
Resources on the WAN include cloud computing and Web applications. These must be analyzed separately from locally hosted applications because they generally exist on the public Internet, which exposes applications to a host of new threats and vulnerabilities. Some of the most prominent vulnerabilities are code injection and buffer overflow errors. Code injection is an attack where the hacker inserts malicious code into an input field, usually on a Web application. If the application is not coded securely, the server will execute the malicious code.
Consider a contact form on an organization's Web site. It is a simple application that allows Web site visitors to send a message to various departments within the organization. The user selects a department, and types in his or her name and a message into a Web form. The information is stored in a database table. Every 10 minutes, a script runs on the Web server that pulls new comments from the database, reformats them, and e-mails them to the correct department.
As long as users do the expected, and enter a name and message into the form, the system works well. Unfortunately, if a malicious user finds this form, he or she could enter the following line of text in the message field:
This is a message for IT security"; drop table comments;
The Web server would interpret the input as a database command:
Insert into comments "This is a message for IT security"; drop table comments;"
The Web server will send that line of code to the database, which would interpret it as three lines of code:
Insert into comments "This is a message for IT security"; drop table comments; "
The trailing end quote would throw a syntax error, but not until after the crucial command, drop table comments, was executed. This command would delete the entire comments table from the database. This type of attack is common on Web applications. It is possible because of lax input validation, which is something that a good Web application security scanner will look for.
Allowing remote access to internal resources adds a level of complication to any IT infrastructure, and can lead to gaps in an otherwise secure system. Gap analysis in the Remote Access Domain focuses on the access controls that authorize remote users on the internal network and the encryption methods and IP tunneling that allow data to be sent securely over the public Internet to a remote worker.
There are many areas that a gap analysis could uncover vulnerabilities in the Remote Access Domain. Lost or stolen challenge-response tokens are a common problem for remote access. If a lost or stolen token cannot be disabled promptly, that represents a significant vulnerability in the Remote Access Domain. A gap analysis in this domain should examine the average time lapse between the point a device is missed and the point at which it is disabled.
Gap analysis on systems and applications focuses on insecure code in the application, the operating system, or the libraries and programming languages that connect the two. In the System/Application Domain, you will be looking for vulnerabilities that can lead to buffer overflows, SQL injections, and other common application-level attacks.
Unfortunately, many application-level vulnerabilities are not the fault of insecure code written in-house. The vulnerabilities exist in the programming languages and libraries that developers rely on. Libraries and functions within programming languages exist so that developers can concentrate on the high-level functionality of their applications, and not get bogged down by the low-level details of file management or database communication. Unfortunately, when a vulnerability exists in low-level libraries, that vulnerability filters up into the application where it can be exploited by malicious users.
New vulnerabilities are constantly surfacing, so it is important for developers and systems administrators to know exactly which libraries are in use, and to keep up to date on new vulnerability announcements.
Penetration testing is the most accurate way to assess an infrastructure's true vulnerability, because it simulates the actual attack. It can also be the most dangerous to both the targeted organization and the penetration team itself.
Penetration testing is an intrusive testing method. Because penetration testers use the same tools and methods actual attackers use, systems and networks can be taken down during a test. Because one of the greatest advantages to penetration testing is that it tests both the security of the infrastructure and the readiness of the incident response team, it is usually necessary to conduct the test during normal work hours when an outage could impact productivity. Even if the attack is carried out after hours, which tests the incident response team's ability to deal with an attack at those times, it could take some time to bring the network back online. Management should be aware of these possibilities and sign off on them before a penetration test begins.
Note
A penetration team's authorization memo is often called the get out of jail free card. This memo, and the authorization it describes, is the only real difference between legal penetration testing and illegal hacking or computer crimes.
Penetration testing is risky for the attacking team as well. If the incident response team—or even ordinary employees if the testing involves social engineering—is well prepared, they may call in security or law enforcement authorities. This would be a normal and approved response, especially to an intruder in the building. Penetration testers should be prepared to step out of their role as attacker and prove their identity and authorization at a moment's notice. Every member of a penetration team should carry a copy of the authorization memo, signed by a member of upper management, which states that a penetration test has been authorized and exactly which methods the test will include.
Consider the case of a penetration testing team in Britain. They were hired by a media organization doing a story on how easy it is to steal automated teller machine (ATM) card numbers and personal identification numbers (PINs). The team was led to believe the bank that owned the specific ATMs they tested against had sanctioned their activities. Unfortunately, this belief was incorrect. The team installed surveillance cameras near an ATM and a fake card reader on top of the legitimate one. The media organization filmed all of their activities and released that footage as part of an investigative report. After the report was aired, the members of the penetration team were arrested on charges of identity theft and credit card fraud, and the footage taken by the media was used as evidence against them.
The penetration team was very good at their job. Their only failure was in trusting the organization that employed them and not having a legal waiver indemnifying them against all liability and legal action as a result of their activities.
The term "red team" originated in military war-gaming parlance. In this context, the red team is the attacker in a war game. Both the attacker and the defender know that the war game is taking place. The red team knows that the defenders expect them, but do not know how they've prepared. In penetration testing, the red team may be made up of systems administrators from other departments within the organization, or of external penetration testers.
The "blue team" in a war game is the defending team. They may not know how the red team will attack, but they know to expect some sort of attack. In penetration testing, the systems administrators and general IT staff are considered the blue team.
A tiger team is the most common type of penetration tester. Tiger teams are almost always external testers who operate in a double-blind penetration test. The target, with the exception of upper management who authorized the test, is unaware that the test is taking place, and the testing team is given no information about the infrastructure.
The tiger team is left to discover whatever they can about the infrastructure prior to launching the actual attack, and the IT staff must detect and respond to the attack.
A penetration test is any simulated attack scenario. It could be purely technological, or it could focus on uncovering weaknesses to social engineering tactics, or it could take a holistic approach and use any and all tactics and tools available to penetrate the organization's defenses. Because this type of testing is inherently invasive, and simulates as close as possible the methods of an actual attack, it is important that all parties have a clear outline of what will be done, what restrictions (if any) must be followed, and what the tests are designed to uncover. If there is any miscommunication between the testers and the organization's management team, a useful penetration test could easily become a crisis situation.
For example, an organization hired a security consulting firm to conduct a penetration test against its IT infrastructure. During the planning stage, management neglected to mention that they would be launching a new customer-facing Web site during the window allowed for the penetration test. The penetration test proceeded, and the test attack interrupted service during the Web site launch. Management was understandably upset that a test scenario disrupted a major Web site launch. The penetration testers had no idea that this particular Web site was any more important than any other hosted on the organization's servers. All this would have been avoided had the penetration test team known that the new Web site was off-limits, and if management had known exactly what the penetration test team planned to do.
Any penetration test should follow a well-planned methodology that has been approved by upper management. The basic stages of a penetration test are:
Planning and preparation—This is the most crucial stage in any penetration test. In the planning stage, penetration testers and organization management should meet to determine the goals, scope, and methodology of the penetration test. Without a clear indication of what the penetration test should accomplish, it is likely to produce nothing but a list of exploitable vulnerabilities without any prioritization or guidelines for the organization.
During this stage, appropriate legal documents must be created to protect the penetration testers. As part of the testing, penetration testers engage in activities that would otherwise be considered illegal, and it is possible that confidential information can be compromised. The testing contract should elaborate on how such confidential information will be handled and either returned or disposed of after the test. It should also contain a liability waiver to protect the testers from legal ramifications in the case of accidental or intentional damage to systems or data during the test.
Tip
Always consult legal counsel before conducting any penetration test, even on your own organization.
Information gathering—During the information gathering stage, the penetration testing team uses nonintrusive methods to discover as much as they can about the target network. In this stage, port scanners and online tools such as Netcraft (
www.netcraft.com) are invaluable. They give the penetration team a good sense of which parts of the network are potential targets, and which systems are detectable. They will use this information later during the actual penetration attempt.Vulnerability detection—Once the penetration team knows something about the target network they can begin to probe for vulnerabilities using nonintrusive vulnerability scanners. The information gathered in this stage helps the team choose specific attack vectors and target systems during the penetration attempt.
Penetration attempt—During the penetration attempt, testers may use a variety of methods and tools to gain unauthorized access to systems and networks. Social engineering may be a key method, if it is allowed under the terms of the contract with the organization. The penetration team may also attempt to defeat physical security to gain access to facilities such as data centers. The testing team must keep detailed records of every action they take as a guide for the clean-up process.
Analysis and reporting—Once the penetration test is complete, the testing team analyzes the gathered data and writes a report for the organization. The final report should contain a summary of the testing methods used and their success or failure on various targets, a detailed listing of all information gathered during the testing, a list that describes all vulnerabilities found, and recommendations for remediation.
Clean-up—During penetration testing, the team may create new user accounts, modify configuration or data files, and make other changes to the environment. Once the test is complete, the testing team has the responsibility to undo any changes they made to the environment.
These basic steps will help ensure an accurate, safe penetration test that produces actionable results for the organization. The basic goals of any penetration test are to assess three areas: whether policies and standards are followed, whether an appropriate baseline is achieved throughout the infrastructure, and whether countermeasures and access control systems are implemented properly. The next three sections discuss these goals in detail.
Every organization should have policies and standards for access controls. Simply having standards is not enough to secure an infrastructure—those standards must be implemented and followed consistently. A good penetration test attempts to uncover inconsistencies and exploits them to demonstrate this weakness in the organization's infrastructure.
Social engineering methods are often used to find weaknesses in policy and standards implementation. Often a lax attitude toward security and a lack of understanding of how policies and standards contribute to an organization's overall security posture lead to employees who take shortcuts and circumvent access controls. They may hold or prop open the doors to sensitive areas, reuse passwords, or share privileged accounts. A good penetration testing team will use social engineering and other methods to discover these weak areas.
During the planning phase, a security baseline is defined. The baseline is the minimum level of security that is acceptable to the organization. Whether that baseline is achieved throughout the organization is a question answerable by a good penetration test.
For example, if the organization has determined that no outside access should be permitted to the intranet as one baseline for access control systems, penetration tests may scan for open ports on the intranet server and attempt to gain remote access.
Access control systems are often complex and sophisticated systems. Unfortunately, vulnerabilities often hide in those complexities. Security countermeasures are not always well understood by IT staff, and access control systems can be misconfigured is such a way as to allow false positives. Penetration tests probe access control systems and attempt to force a false positive. If they are successful, penetration tests will also exercise security countermeasures and ensure that they are effective.
The major deliverable from any penetration test is the analysis and report delivered to the organization. This report—and prior authorization—is all that really separates penetration tests from hacking. The first section of the final test report must include a detailed description of the penetration test team's activities including which methods were used and what areas of the infrastructure were targeted. The next section should contain details of the vulnerabilities they found, and what areas were adequately hardened and resisted their attacks. The final section of the report should contain the test team's final analysis, prioritization of risk, and recommendations for hardening.
The organization uses this report to guide security activities so that the vulnerabilities that represent the most significant risks are addressed. The report is also used to determine budgets for future infrastructure upgrades.
In the first section, the penetration testers describe each of their activities and elaborate on any gaps and vulnerabilities they were able to exploit. They combine this information with knowledge of the organization's security goals to assess the impact of the gaps and vulnerabilities found during testing.
Once those gaps have been identified, they must be prioritized by risk exposure. It is important to keep in mind that the organization has limited resources—time, money, and personnel—available to close security holes, so the testing team's findings must be presented in a way that makes it easy to decide where to spend those resources.
Once the gaps in an organization's infrastructure are identified, the next step is to develop remediation plans for closing the most important gaps. These plans will vary depending on the gaps identified, and should always involve re-testing to ensure that the gaps have been adequately closed. Remediation plans should be listed in order of risk exposure.
Remediation of security gaps can be costly in terms of time, effort, and monetary costs. The final section of a penetration test report should include a breakdown of the costs of remediation, in order of risk exposure. Once the costs have been broken down, an executive summary is a useful tool to include. This summary will give a quick overview of the bottom line: what will it cost the organization in terms of time, effort, and monetary costs to close the most important security gaps in its infrastructure?
Testing in various forms is an important tool for identifying vulnerabilities and security gaps in an organization's IT infrastructure. Ideally a testing plan should include both intrusive and nonintrusive testing methods, as each will provide a different view on the infrastructure. For the protection of the testers, intrusive tests should only be conducted with the full approval of upper management as well as legal documentation of that support.
Once security testing is complete a detailed report of the testers' findings as well as recommendations for remediation will be an invaluable guide for improving the overall security of an organization's IT infrastructure.
Automated testing
Backdoor
Blue team
Boundary conditions
Bugtraq
Code injection
Data dictionary
Gap analysis
Get out of jail free card
Hardening
Host discovery
Integration testing
Intrusive testing methods
Load testing
Nessus
Nmap
Nonintrusive testing methods
Penetration testing
Port scanning
Pseudocode
Red team
Retina
Tiger team
Unit testing
It is necessary to consider security issues during every phase of the software development life cycle.
True
False
What occurs during the sunset phase of a security system's life cycle?
Electronic media is wiped clean.
Paper documentation is shredded or archived.
Old equipment is destroyed or disposed of in a secure manner.
All of the above
Which of the following are primary activities for an information security team? (Select two.)
Researching new exploits
Monitoring/incident handling
Testing
Upgrading security systems
Port scanning is an example of ________ testing.
Penetration testing is an example of ________ testing.
Which of the following tests is the most accurate way to test security incident response?
Open
Blind
Double-blind
Automated
Gap analysis in which domain focuses primarily on the effectiveness of an organization's training program?
User
Workstation
LAN
LAN-to-WAN
WAN
System/Application
Remote Access
A Web application security scanner is a good tool to use when testing which domain?
User
Workstation
LAN
LAN-to-WAN
WAN
Remote Access
Penetration testing is a risky operation for both the organization and the testers.
True
False
Which penetration testing team may be comprised of systems administrators in other departments of within an organization?
Red
Blue
Tiger
Orange
Which penetration testing team is comprised of systems administrators who defend the network and respond to the activities of the penetration testers?
Red
Blue
Tiger
Orange
Which penetration testing team is given no prior knowledge of the IT infrastructure and uses the same tools and strategies that an actual attacker would use?
Red
Blue
Tiger
Orange
The clean-up phase of a penetration test is the responsibility of which individual or group?
Systems administrator
Upper management
Penetration testing team
Help desk
A penetration test report should include which of the following? (Select three.)
Description of gaps and risk exposures found during the test
List of passwords uncovered by the penetration testing team
Remediation plans for closing security gaps
Cost analysis and solution prioritization based on risk exposure