Overall Risk
Once the likelihood of occurrence and impact have been determined, you can then determine the
overall risk rating, which is defined as a function of the two ratings. The overall risk can be rated
Low, Medium, or High, which provides guidance to those responsible for securing and maintaining
the systems in question.
• High: There is a strong requirement for additional measures to be implemented to protect
against the vulnerability. In some cases, the system may be allowed to continue operating
but a plan must be designed and implemented as soon as possible.
• Medium: There is a requirement for additional measures to be implemented to protect
against the vulnerability. A plan to implement the required measures must be done in a
timely manner.
291
Chapter 11 — Introduction to Security Assessments
• Low: The owner of the system will determine whether to implement additional measures
to protect against the vulnerability or they can opt to accept the risk instead and leave the
system unchanged.
In Summary
With so many factors making up the true risk of a discovered vulnerability, the pre-defined risk
ratings from tool output should only be used as a starting point to determine the true risk to the
overall organization.
Competently-created reports from a vulnerability assessment, when analyzed by a professional,
can provide an initial foundation for other assessments, such as compliance penetration tests. As
such, it is important to understand how to get the best results possible from this initial assessment.
Kali makes an excellent platform for conducting a vulnerability assessment and does not need
any special configuration. In the Kali Applications menu, you will find numerous tools for vul-
nerability assessments in the Information Gathering, Vulnerability Analysis, and Web Application
Analysis categories. Several sites, including the aforementioned
Kali Linux Tools Listing
13
,
The
Kali Linux Official Documentation
14
site, and the free
Metasploit Unleashed
15
course provide ex-
cellent resources for using Kali Linux during a vulnerability assessment.
11.2.2. Compliance Penetration Test
The next type of assessment in order of complexity is a compliance- based penetration test. These
are the most common penetration tests as they are government- and industry-mandated require-
ments based on a compliance framework the entire organization operates under.
While there are many industry-specific compliance frameworks, the most common would likely
be
Payment Card Industry Data Security Standard
16
(PCI DSS), a framework dictated by payment
card companies that retailers processing card-based payments must comply with. However, a
number of other standards exist such as the
Defense Information Systems Agency Security Techni-
cal Implementation Guides
17
(DISA STIG),
Federal Risk and Authorization Management Program
18
(FedRAMP),
Federal Information Security Management Act
19
(FISMA), and others. In some cases,
a corporate client may request an assessment, or ask to see the results of the most recent assess-
ment for various reasons. Whether ad-hoc or mandated, these sorts of assessments are collectively
13
https://tools.kali.org/tools-listing
14
https://www.kali.org/docs/
15
https://www.offensive-security.com/metasploit-unleashed/
16
https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf
17
https://public.cyber.mil/stigs/
18
https://www.fedramp.gov/about-us/about/
19
https://csrc.nist.gov/projects/risk-management
292
Kali Linux Revealed
called compliance-based penetration tests, or simply “compliance assessments” or “compliance
checks”.
A compliance test often begins with a vulnerability assessment. In the case of
PCI compliance
auditing
20
, a vulnerability assessment, when performed properly, can satisfy several of the base
requirements, including: “2. Do not use vendor-supplied defaults for system passwords and other
security parameters” (for example, with tools from the Password Attacks menu category), “11.
Regularly test security systems and processes” (with tools from the Database Assessment cate-
gory) and others. Some requirements, such as “9. Restrict physical access to cardholder data” and
“12. Maintain a policy that addresses information security for all personnel” don’t seem to lend
themselves to traditional tool-based vulnerability assessment and require additional creativity
and testing.
Despite the fact that it might not seem straight-forward to use Kali Linux for some elements of
a compliance test, the fact is that Kali is a perfect fit in this environment, not just because of
the wide range of security-related tools, but because of the open-source Debian environment it
is built on, allowing for the installation of a wide range of tools. Searching the package manager
with carefully chosen keywords from whichever compliance framework you are using is almost
certain to turn up multiple results. As it stands, many organizations use Kali Linux as the standard
platform for these exact sorts of assessments.
11.2.3. Traditional Penetration Test
A traditional penetration test has become a difficult item to define, with many working from dif-
ferent definitions, depending on the space they operate in. Part of this market confusion is driven
by the fact that the term “Penetration Test” has become more commonly used for the previously
mentioned compliance-based penetration test (or even a vulnerability assessment) where, by de-
sign, you are not delving too deep into the assessment because that would go beyond the minimum
requirements.
For the purposes of this section, we will side-step that debate and use this category to cover as-
sessments that go beyond the minimum requirements; assessments that are designed to actually
improve the overall security of the organization.
As opposed to the previously-discussed assessment types, penetration tests don’t often start with
a scope definition, but instead a goal such as, “simulate what would happen if an internal user is
compromised” or, “identify what would happen if the organization came under focused attack by
an external malicious party.” A key differentiator of these sorts of assessments is that they don’t
just find and validate vulnerabilities, but instead leverage identified issues to uncover the worst-
case scenario. Instead of relying solely on heavy vulnerability scanning toolsets, you must follow
up with validation of the findings through the use of exploits or tests to eliminate false positives
and do your best to detect hidden vulnerabilities or false negatives. This often involves exploiting
20
https://www.pcisecuritystandards.org/documents/PCIDSS_QRGv3_2.pdf
293
Chapter 11 — Introduction to Security Assessments
vulnerabilities discovered initially, exploring the level of access the exploit provides, and using
this increased access as leverage for additional attacks against the target.
This requires critical review of the target environment along with manual searching, creativity,
and outside-the-box thinking to discover other avenues of potential vulnerability and ultimately
using other tools and tests outside those found by the heavier vulnerability scanners. Once this is
completed, it is often necessary to start the whole process over again multiple times to do a full
and complete job.
Even with this approach, you will often find that many assessments are composed of different
phases. Kali makes it easy to find programs for each phase by way of the Kali Menu:
• Information Gathering: In this phase, you focus on learning as much as possible about the
target environment. Typically, this activity is non-invasive and will appear similar to stan-
dard user activity. These actions will make up the foundation of the rest of the assessment
and therefore need to be as complete as possible. Kali’s Information Gathering category has
dozens of tools to uncover as much information as possible about the environment being
assessed.
• Vulnerability Discovery: This will often be called ”active information gathering”, where you
don’t attack but engage in non-standard user behavior in an attempt to identify potential
vulnerabilities in the target environment. This is where the previously-discussed vulnera-
bility scanning will most often take place. The programs listed in the Vulnerability Analysis,
Web Application Analysis, Database Assessment, and Reverse Engineering categories will be
useful for this phase.
• Exploitation: With the potential vulnerabilities discovered, in this phase you try to exploit
them to get a foothold into the target. Tools to assist you in this phase can be found in the
Web Application Analysis, Database Assessment, Password Attacks, and Exploitation Tools
categories.
• Pivoting and Exfiltration: Once the initial foothold is established, further steps have to be
completed. These are often escalating privileges to a level adequate to accomplish your
goals as an attacker, pivoting into other systems that may not have been previously acces-
sible to you, and exfiltrating sensitive information from the targeted systems. Refer to the
Password Attacks, Exploitation Tools, Sniffing & Spoofing, and Post Exploitation categories
to help with this phase.
• Reporting: Once the active portion of the assessment is completed, you then have to docu-
ment and report on the activities that were conducted. This phase is often not as technical
as the previous phases, however it is highly important to ensure your client gets full value
from the work completed. The Reporting Tools category contains a number of tools that
have proven useful in the reporting phase.
In most cases, these assessments will be very unique in their design as every organization will
operate with different threats and assets to protect. Kali Linux makes a very versatile base for
294
Kali Linux Revealed
these sorts of assessments and this is where you can really take advantage of the many Kali Linux
customization features. Many organizations that conduct these sorts of assessments will maintain
highly customized versions of Kali Linux for internal use to speed up deployment of systems before
a new assessment.
Customizations that organizations make to their Kali Linux installations will often include:
• Pre-installation of commercial packages with licensing information. For instance, you may
have a package such as a commercial vulnerability scanner that you would like to use. To
avoid having to install this package with each build, you can do it once and have it show up
in every Kali deployment you do.
• Pre-configured connect-back Virtual Private Networks (VPN). These are very useful in leave-
behind devices that allow you to conduct ”remote internal” assessments. In most cases,
these systems will connect back to an assessor-controlled system, creating a tunnel that
the assessor can use to access internal systems. The
Kali Linux ISO of Doom
21
is an example
of this exact type of customization.
• Pre-installed internally-developed software and tools. Many organizations will have private
toolsets, so setting these up once in a customized Kali install saves time.
• Pre-configured OS configurations such as host mappings, desktop wallpaper, proxy settings,
etc. Many Kali users have
specific settings
22
they like to have tweaked just so. If you are
going to do a re-deployment of Kali on a regular basis, capturing these changes makes a lot
of sense.
11.2.4. Application Assessment
While most assessments have a broad scope, an application assessment is a specialty that is nar-
rowly focused on a single application. These sorts of assessments are becoming more common
due to the complexity of mission-critical applications that organizations use, many of which are
built in-house. An application assessment is usually added on to a broader assessment, as required.
Applications that may be assessed in this manner include, but are not limited to:
• Web applications: The most common externally-facing attack surface, web applications
make great targets simply because they are accessible. Often, standard assessments will
find basic problems in web applications, however a more focused review is often worth the
time to identify issues relating to the workflow of the application. The kali-tools-web meta-
package has a number of tools to help with these assessments.
• Compiled desktop applications: Server software is not the only target; desktop applications
also make up a wonderful attack surface. In years past, many desktop applications such as
PDF readers or web-based video programs were highly targeted, forcing them to mature.
21
https://www.offensive-security.com/kali-linux/kali-rolling-iso-of-doom/
22
https://www.offensive-security.com/kali-linux/kali-linux-recipes/
295
Chapter 11 — Introduction to Security Assessments
However, there are still a wide number of desktop applications that are a wealth of vulner-
abilities when properly reviewed.
• Mobile applications: As mobile devices become more popular, mobile applications will be-
come that much more of a standard attack surface in many assessments. This is a fast mov-
ing target and methodologies are still maturing in this area, leading to new developments
practically every week. Tools related to the analysis of mobile applications can be found in
the Reverse Engineering menu category.
Application assessments can be conducted in a variety of different ways. As a simple example, an
application-specific automated tool can be run against the application in an attempt to identify
potential issues. These tools will use application-specific logic in an attempt to identify unknown
issues rather than just depending on a set of known signatures. These tools must have a built-in
understanding of the application’s behavior. A common example of this would be a web applica-
tion vulnerability scanner such as
Burp Suite
23
, directed against an application that first identifies
various input fields and then sends common SQL injection attacks to these fields while monitoring
the application’s response for indications of a successful attack.
In a more complex scenario, an application assessment can be conducted interactively in either a
|