• Penetration testing – test vulnerabilities to determine if they can be exploited
Both vulnerability and penetration testing can be executed in one of three knowledge levels. A black box test provides the testing team with no prior knowledge of the environment – the only knowledge gained is that which the team discovers through public resources (such as search engines or WHOIS services) or by scanning. This best simulates an external attacker, but will prevent complete internal coverage of controls. It may also lead to the team inadvertently attacking a critical system.
A white box test is the opposite – the testing team has complete knowledge of and has complete access to the internal infrastructure. This will result in the most complete assessment, but does not representing very well vulnerabilities and risks from an external or internal attacker.
The final level is a gray box test, and is a hybrid of the black and white approaches. The testing team is allowed access to the internal environment but is not given complete knowledge of the systems or privileged credentials. This does not provide full coverage of all internal controls, but does strike a decent balance in representing both an internal and external attacker.
Vulnerability Testing
Before any type of vulnerability testing is started, an agreement must be created defining how far testing will be taken, listing possible side-effects or fallout. While vulnerability testing is considered to be non- invasive, it can trip IDS/IPS alarms. This agreement must be signed by management as well as the tester – this applies whether the tester is internal or an external party.
Vulnerability testing may use an automated tool as part of the effort, but no tool will be able to
effectively discard false positives and uncover false negatives – only an experienced professional with a deep background in security will be able to accomplish this.
The goal of a vulnerability test is to generate a prioritized list of as many vulnerabilities as possible to reveal the actual security posture of a company, as opposed to the imagined. Management should
understand that this report is a snapshot in time, and should be performed annually for low-risk systems up to continuous scans for high-risk assets.
There are 3 types of assessments. A personnel assessment reviews employee tasks to identify
vulnerabilities in policies and procedures. It should demonstrate how social engineering attack occur and highlight the value of training employees to recognize such activities. It should also ensure policies and procedures that cannot be addressed with physical and technical controls are properly addressed with administrative controls.
A physical assessment tests facility and perimeter protection, such as door locks, badge readers, ensuring doors clos properly, determining if dumpster diving is a risk, checking fire suppression systems, and examining plenum spaces to ensure proper protection.
A system and networking assessment employs an automated scanning tool to search for vulnerabilities, and provides the following:
• Identification of active hosts
• Identification of active and vulnerable services (ports) on hosts • Identification of application and banner grabbing
• Identification of operating systems
• Identification of vulnerabilities for discovered operating systems and applications • Identification of misconfigured settings
• Tests for compliance with host application’s usage and security policies • Provides a foundation for subsequent penetration testing
Banner grabbing examines the content resulting from a specific port scan and attempts to figure out what type or brand of service is running behind that port. Fingerprinting uses a similar tactic to identify specific operating systems or applications.
Some commonly discovered (and exploitable) vulnerabilities include:
• Kernel flaws – if found, this type of vulnerability can give the attacker a great deal of control; the countermeasure is to keep OSs patched and up-to-date
• Buffer overflows – poorly implemented code can allow an attacker to overwrite protected memory, resulting in launching an attacker’s code; countermeasures include developer education, using strongly typed languages, and employing automated source code scanners • Symbolic links – this is a file stub that redirects to another location, allowing a back door path to
access sensitive files; the countermeasure is to ensure that programs and scripts are written to require the full path to the file
• File descriptor attacks – operating systems use numbers to represent open files, and some numbers are always the same, allowing an attacker to control input or output for these files; countermeasures include developer education, performing application security testing, and using automated source code scanners
• Race conditions – a program’s poor design can put it in a temporary vulnerable condition in which an attacker could force the program to execute an operation out of the intended order; countermeasures include developer education, performing application security testing, and using automated source code scanners
• File and directory permissions – inadvertent system or user errors can result in file or directory permissions being lowered, allowing an attacker to access sensitive information; the
countermeasure is to employ file integrity checkers that can alert on these changes before an attacker exploits them
Vulnerability testing should always use multiple automated tools – every tool has its own strengths and weaknesses, and by using multiple tools a tester has a better chance of full coverage. In the same vein, it is better to use multiple testers, as each individual or team will have their own unique experiences – rotating teams allows a company to discover a greater breadth of vulnerabilities.