Security Assessment Techniques
A number of tools and techniques are available to help organizations conduct security assessments. In this sample chapter from CompTIA Security+ SY0-601 Exam Cram, you will learn how a security information and event management (SIEM) system can help identify internal and external threats, monitor activity, conduct compliance reporting, and more.
This chapter is from the book
This chapter is from the book
This chapter is from the book
A number of tools and techniques are available to help organizations conduct security assessment. Identifying vulnerabilities and threats is key to maintaining organizational security. In addition to identifying vulnerabilities, organizations need an approach to assess threats against their systems. A myriad of solutions are available. In the past, an organization first needed to move beyond simple log management and find a method to efficiently store and analyze log data across all of its networks, devices, and applications. Security information management (SIM) was the solution. Then, in addition, the data needed to be analyzed in real time to provide correlation across events and enable alerts and reporting. Security event management (SEM) was the solution in this case. SIM and SEM were eventually combined into what’s known today as security information and event management (SIEM). This chapter looks at security assessment techniques, including how they are combined and continue to evolve.
Vulnerability Scans
Many network scanners are designed to be passive and non-intrusive to the target systems. Passive scanning poses minimal risk to the assessed environment because it is designed to avoid interfering with normal activity or degrading performance. However, tests against the system can affect network and system performance. A comprehensive vulnerability scan helps an organization identify vulnerabilities, uncover common misconfigurations, and understand where further security controls are required. The following points briefly summarize these three goals:
▸ Identify vulnerability: Vulnerabilities include outdated software versions that contain flaws or are missing patches.
▸ Identify common misconfigurations: Vulnerability scanners can identify many common misconfigurations. Some scanners are even capable of remediation. Checking for misconfigurations is most beneficial when deployed configurations are compared against an organization’s security policies and standards.
▸ Identify lack of security controls: Identifying vulnerabilities provides an opportunity to remediate weaknesses. In some cases, organizations may find that they need to implement more security controls to mitigate the risk.
Vulnerability scanners fall into three broad categories, based on the devices they evaluate:
▸ Network scanners: This type of scanner probes hosts for open ports, enumerates information about users and groups, and proactively looks for known vulnerabilities.
▸ Application scanners: This type of scanner requires access to application source code or binaries but does not need to actually execute the application. Thus, this type of scanner tests an application from the inside. Application scanning supports all types of applications and is also known as static application security testing (SAST).
▸ Web application scanners: This type of scanner applies specifically to web applications and identifies vulnerabilities such as cross-site scripting, SQL injection, and path traversal. This type of scan executes an application and tests from the outside in. This type of scanning is known as dynamic application security testing (DAST).
A network vulnerability scanner, for example, is a software utility that scans a range of IP addresses, testing for the presence of known vulnerabilities in software configuration and accessible services. A traditional vulnerability scanner relies on a database of known vulnerabilities. It is an automated tool that can be directed at a targeted system or systems. Unlike systems that test for open ports, which test only for the availability of services, vulnerability scanners can check for the version or patch level of a service to determine its level of vulnerability.
Keep in mind that a vulnerability does not necessarily indicate an issue that needs to be immediately remediated—or even remediated at all. Using an analogy, consider a home as a subject for a vulnerability assessment. A broken deadbolt lock certainly seems like a vulnerability. Ideally, the homeowner would replace it; however, in some parts of the world, residents do not lock their doors anyway. A smashed window is a vulnerability as well. In some cases, it might make sense to mitigate a broken window simply by covering it with plastic to protect against the elements. Even a perfectly functioning window is a vulnerability, however. The benefit a window offers typically outweighs the benefits gained by living without windows. What is counted as a vulnerability typically depends on what you are trying to protect.
Upon completion of a vulnerability scan, an organization can generally choose to take one of three approaches:
▸ Remediation: The organization can patch the vulnerability.
▸ Mitigation: The organization can introduce a control to reduce the likelihood of the vulnerability being exploited or the impact if it is exploited.
▸ Acceptance: The organization can take no action if the risk is low, especially compared with the cost or operational impact of addressing the vulnerability.
There isn’t necessarily a quick method for determining risk based on the output of a vulnerability scanner. Relevancy to the business, trade-offs, and identified threats and likelihoods need to be considered to accurately interpret the results.
Vulnerability scanners rely heavily on catalogs of known vulnerabilities. Two standards are commonly used, both of which are open industry standards:
▸ Common Vulnerability Scoring System (CVSS)
CVE is a standard for identifying vulnerabilities. It is designed to allow vulnerability databases to be linked together and does not contain attributes such as risk, impact, remediation steps, or detailed technical information. It primarily includes a description and a unique identifier assigned by the vendor where a patch has been provided to fix the vulnerability. CVE also includes related references, such as vulnerability reports and advisories.
On the other hand, CVSS is a framework for communicating the characteristics and severity scores of vulnerabilities. A CVSS score is a rating from 0 to 10. Calculation of the score is complex and takes various components into consideration, such as how easy it would be to exploit the vulnerability. CVSS scoring seeks to address the following questions:
▸ What is the attack vector? Does it require physical access, or can it be exploited over the network?
▸ What is the attack complexity?
▸ Are elevated privileges required?
▸ Is user interaction required?
Intrusive vs. Non-Intrusive
Vulnerability tests seldom disrupt systems. However, an initial port scan can cause a system to fail, particularly if the implementation of a particular service does not follow proper standards. Intrusive scans aim to verify vulnerabilities by trying to exploit them. Organizations should take care before initiating such intrusive tests.
Credentialed vs. Non-Credentialed
Credentials such as usernames and passwords enable authorized access to a system. Scanners can be configured to run in either credentialed or non-credentialed mode. Non-credentialed scans are less invasive and provide an outsider’s point of view. With credentialed scans, however, the system can ascertain more information, which results in a more complete vulnerability status with greater certainty. Both credentialed and non-credentialed scans can mistakenly identify a vulnerability when none exists; this is known as a false positive. Confirming a large number of false positives can be time-consuming and places a burden on IT resources. Credentialed scans tend to reduce false positives and can also reduce the opposite effect: false negatives. False negatives are more difficult to see than false positives. A false negative is a lack of result when there should be one. A false negative may occur, for example, when a vulnerability is new, and a check has not been developed yet to look for the vulnerability.