52 - Auditing methods
Auditing types
External security testing is conducted from outside the organization’s security perimeter. This offers the ability to view the environment’s security posture as it appears outside the security perimeter usually as seen on the Internet with the goal of revealing vulnerabilities that could be exploited by an external attacker. External testing often begins with reconnaissance techniques that search public registration data, Domain Name System (DNS) server information, newsgroup postings, and other publicly available information to collect information (e.g. system names, Internet Protocol [IP] addresses, operating systems, technical points of contact) that may help the assessor to identify vulnerabilities.
For internal security testing, assessors work from the internal network and assume the identity of a trusted insider or an attacker who has penetrated the perimeter defenses. This kind of testing can reveal vulnerabilities that could be exploited and demonstrates the potential damage this type of attacker could cause. Internal security testing also focuses on system-level security and configuration—including application and service configuration, authentication, access control, and system hardening.
| 1st party audit | 2nd party audit | 3rd party audit |
|---|---|---|
| Internal audit | External provider audit | Certification and/or accreditation audit |
| Other external interested party audit | Statutory, regulatory and similar audit |
Overt and Covert
Overt Testing: Security testing performed with the knowledge and consent of the organization’s IT staff.
Covert Testing: Testing performed using covert methods and without the knowledge of the organization’s IT staff but with full knowledge and permission of upper management.
Collecting documents
Usually every tool has some method how to collect results, for example a separate file. This helps an auditor to collect all results for later analysis. Example NMAP command: nmap -T4 -A -v -oX document.xml 192.168.1.1/24 will scan the whole network and saves the results in one document.xlm file.
Example
With vulnerability scanners, it is possible to scan an environment with known vulnerabilities. These tools do not recognize new vulnerabilities that these tools do not know. Below is an example of scan results against Windows XP SP3. This is just an example and has nothing to do with this exercise.
Examination overview & techniques
NIST SP 800-115 Technical Guide to Information Security Testing and Assessment processes different examination techniques and is also recommendable reading. Review techniques passively examine systems, applications, networks, policies, and procedures to discover security vulnerabilities. They also gather information to facilitate and optimize other assessment techniques. Because review techniques are passive, they pose a minimal risk to systems and networks. This section covers several common review techniques—documentation, log, ruleset, and system configuration review; network sniffing; and file integrity checking.
These Techniques are:
-
Documentation review
- Documentation review determines if the technical aspects of policies and procedures are current and comprehensive. These documents provide the foundation for an organization’s security posture but are often overlooked during technical assessments. Security groups within the organization should provide assessors with appropriate documentation to ensure a comprehensive review. Documents to review for technical accuracy and completeness include security policies, architectures, and requirements; standard operating procedures; system security plans and authorization agreements; memoranda of understanding and agreement for system interconnections; and incident response plans.
-
Log review
- Log review determines if security controls are logging the proper information, and if the organization is adhering to its log management policies. As a source of historical information, audit logs can be used to help validate that the system is operating in accordance with established policies. For example, if the logging policy states that all authentication attempts to critical servers must be logged, the log review will determine if this information is being collected and shows the appropriate level of detail. Log review may also reveal problems such as misconfigured services and security controls, unauthorized accesses, and attempted intrusions. For example, if an intrusion detection system (IDS) sensor is placed behind a firewall, its logs can be used to examine communication that the firewall allows into the network. If the sensor registers activities that should be blocked, it indicates that the firewall is not configured securely.
-
Ruleset review
- A ruleset is a collection of rules or signatures that network traffic or system activity is compared against to determine what action to take—for example, forwarding or rejecting a packet, creating an alert, or allowing a system event. These rulesets are reviewed to ensure comprehensiveness and identify gaps and weaknesses on security devices and throughout layered defenses such as network vulnerabilities, policy violations, and unintended or vulnerable communication paths. A review can also uncover inefficiencies that negatively impact a ruleset’s performance.
-
System Configuration review
- System configuration review is the process of identifying weaknesses in security configuration controls, such as systems not being hardened or configured according to security policies. For example, this type of review will reveal unnecessary services and applications, improper user account and password settings, and improper logging and backup settings. Examples of security configuration files that may be reviewed are Windows security policy settings and Unix security configuration files such as those in /etc.
-
Network Sniffing
- Network sniffing is a passive technique that monitors network communication, decodes protocols, and examines headers and payloads to flag information of interest. This can be for example capturing and replaying network traffic.
-
File Integrity Checking
- File integrity checkers provide a way to identify that system files have been changed computing and storing a checksum for every guarded file and establishing a file checksum database. Stored checksums are later recomputed to compare their current value with the stored value, which identifies file modifications. A file integrity checker capability is usually included with any commercial host-based IDS and is also available as a standalone utility.
After examination, the next step would be Target identification, analysis and vulnerability validation techniques. These are not relevant with this course, so these has been added only on title level. Further information can be found on NIST SP 800-115 Technical Guide to Information Security Testing and Assessment
-
Target Identification and Analysis Techniques
- Network Discovery
- Network Port and Service Identification
- Vulnerability Scanning
- Wireless Scanning
- Passive Wireless Scanning
- Active Wireless Scanning
- Wireless Device Location Tracking
- Bluetooth Scanning
-
Target Vulnerability Validation Techniques
- Password Cracking
- Penetration Testing
- Social Engineering
Mitigation and Remediation
Vulnerability management programs look different depending on the available resources and specific risks your organization faces. While both identifying and evaluating possible threats are important steps, the most time-consuming step is actually treating the vulnerability. It is here where remediation and mitigation come into play. Both are different approaches to dealing with a vulnerability, and each has its own merits depending on the specific vulnerability you are dealing with.
Once a vulnerability has been discovered, the ideal solution is to remediate it—to fix or patch the vulnerability before it can become a security threat. Usually, it is the organization’s security team, system owners, and system administrators who come together to determine which actions are appropriate.
Remediation can be as simple as applying a readily available software patch or as complex as replacing a fleet of physical servers across an organization’s network. When remediation activities are completed, it is best to always run another vulnerability scan to confirm that the vulnerability has been fully resolved.
However, sometimes remediation is not possible, for several reasons. First, not all vulnerabilities need to be fixed. For example, if the vulnerability is identified in Adobe Flash Player but the use of Flash Player is already disabled in all web browsers and applications company-wide, there is no need for action or sometimes you might be prevented from taking remediation action by a technology challenge, where a patch is not yet available for the vulnerability in question.
Other times, you may experience pushback from your own organization. This often happens when a vulnerability is on some type of customer-facing system, and your company wants to avoid the downtime required to patch a vulnerability.
In those cases, the concept of mitigation comes into play. That is a process that essentially reduces the likelihood of a vulnerability being exploited. For example, distributed denial-of-service (DDoS) mitigation can route suspicious traffic to a centralized location where it is filtered.
Usually, mitigation is not the final step in dealing with a vulnerability. It is more of a way to buy time for the organization to either wait for the technology to be released or find a more appropriate time to schedule downtime in the system. Ultimately, fixing a network security issue is better than blocking the port that could expose it.