In this lesson,
we will learn about technical attack surface.
The technical attack surface is the sum
of all potential entry points
within an organization's technology infrastructure
that could be exploited by an attacker.
Technical attack surface concepts include:
Architecture reviews, Data flows,
Trust boundaries, and Code reviews.
Architecture reviews involve evaluating the design
and structure of a system to identify weaknesses
or misconfigurations that could be targeted
by a threat actor.
Data flows are examined to understand
how information moves within and between network systems.
Trust boundaries define the points
where data transitions from one level of trust to another.
And last, code reviews involve the detailed examination
of source code to detect vulnerabilities.
Let's learn more about architecture reviews, data flows,
trust boundaries, and code reviews.
First, we have architecture reviews.
Architecture reviews examine the design
and structure of a system
to identify potential security weaknesses
or misconfigurations that attackers might exploit.
This review is ideally conducted
in the early stages of system design
to ensure that architecture meets security goals
and includes secure configurations, data flows,
and system interactions.
For instance, an architecture review might reveal
that sensitive data is stored centrally
and is accessible from multiple networks.
This could increase risk if an attacker gains access
to any one of those networks,
prompting the team to restructure the design
to segment access.
Additionally, the Microsoft Threat Modeling Tool
and OWASP's Threat Dragon can assist in architecture reviews
by visualizing components and performing threat modeling.
Architecture reviews also help
to identify insecure default configurations
or third-party dependencies within the infrastructure.
For example,
if a system relies on several third-party applications,
each with its own unique protocols, policies,
and security controls,
these differences might lead
to inconsistencies that attackers could exploit.
So if during a review,
the team finds an infrastructure component
with inadequate authentication controls,
they can address the vulnerability quickly
to strengthen the system's security.
Finally, by documenting
and addressing architectural weaknesses,
a security team can ensure all architectural aspects align
with security goals.
This reduces the system's technical attack surface,
ultimately making the overall infrastructure more resilient
to attack.
Second, we have data flows.
Data flow analysis focuses on understanding
how data moves within and across systems,
highlighting areas
where sensitive information might be exposed.
This analysis not only maps out pathways,
but also helps teams understand data types, sensitivity,
and security needs along each segment.
Mapping data flows ensures information follows secure routes
and doesn't inadvertently cross insecure
or untrusted channels.
For example, a team might find
that sensitive customer data
is being transmitted in plain text between internal servers,
exposing it to potential interception.
In response, they could implement encryption
for all sensitive data transfers to secure these exchanges.
Tools like Visio
or Lucidchart are often used to map data flows visually,
aiding in spotting areas needing stronger security measures.
Though, specialized security tools may be used
for more in-depth analysis.
Examining data flows also allows security teams to verify
that access controls are appropriately placed.
For example, let's say a data flow review uncovers
that accounting data is accessible
by employees in unrelated departments.
The team might then set up stricter access controls
to ensure only authorized personnel can view financial data.
So through regular data flow analysis,
organizations can better control how data is accessed
and shared,
reducing opportunities for unauthorized access.
Third, we have trust boundaries.
Trust boundaries are the points within a system
where data moves between zones
with different levels of trust,
such as between an internal network and the internet,
a public-facing web server and an internal database,
or an application interface and a backend system.
Understanding how the data moves across these zones
and boundaries enables managing access
and implementing security controls.
For example, in a standard enterprise network,
a trust boundary exists between the internal network
and the internet.
Without proper controls,
this boundary could allow an external attacker
to access internal resources.
Understanding this, setting up firewalls,
or implementing network segmentation
at these boundaries can help restrict access
and limit the potential for unauthorized access.
So managing trust boundaries ensures
that only trusted entities can access sensitive areas
of the network or application.
If an organization is processing payment information,
for instance,
it needs to ensure
that data remains in a secure zone within the network
and does not cross into areas with lower security levels.
Tools like Azure's Trust Boundary Analysis assist
in defining and controlling these types of boundaries.
So by monitoring trust boundaries
and enforcing security controls,
organizations can prevent data from being exposed
or accessed by unauthorized users.
Fourth and last, we have code reviews.
Code reviews identify vulnerabilities
in source code before deployment.
Code analysis during reviews includes static analysis,
dynamic analysis, side-channel analysis,
reverse engineering, software composition analysis,
and fuzz testing.
Let's talk about each of these in just a little more detail.
Static analysis is used
to inspect code without executing it.
This can be done manually or with tools like SonarQube
or Checkmarx.
If done manually,
a person will examine the code for issues,
such as insecure authentication or vulnerable library use,
while automated tools will scan on their own
for known vulnerabilities, misconfigurations,
or common coding errors.
Using both types of static analysis,
manual review and automated tools, is recommended.
In contrast,
dynamic analysis tests code while it's executing
in a controlled environment, like a sandbox,
to observe interactions with the host system during runtime.
A sandbox is an isolated environment
that can monitor how code interacts with the network
and the host it is installed on
without affecting the actual host machine.
Developers may use dynamic analysis
and sandbox isolation
to monitor malware behavior on a virtual machine,
noting modified files,
new processes,
or registry changes that the malware attempts to make.
Additionally, tools like Burp Suite
can capture network traffic during dynamic analysis,
acting as a proxy to monitor and manipulate data exchanges.
Additionally, side-channel analysis,
a subset of dynamic analysis,
focuses on observing indirect outputs,
like network traffic or system responses,
often through tools like Wireshark
to understand code behavior.
Next, reverse engineering is a process
that helps analysts understand complex or obfuscated code,
and is especially useful for proprietary software
or malware where source code is not fully available.
Tools like IDA Pro, which is a decompiler,
and OllyDbg, which is a debugger,
can help pull apart code into its executable components
for analysis and reverse engineering.
A decompiler like IDA Pro can convert code
into assembly language
for detailed inspection,
while a debugger like OllyDbg
enables step-by-step code execution,
helping to identify specific code steps.
So by examining underlying instructions like this,
analysts can uncover hidden functions
or vulnerabilities that might otherwise be overlooked.
Next, software composition analysis, or SCA,
may be used to identify
and manage third-party components,
such as open source libraries,
to ensure they are secure and compliant.
This is helpful
because attackers frequently target vulnerabilities
in widely used libraries.
So SCA tools like Snyk
and WhiteSource can be used
to help teams identify outdated or insecure dependencies,
recommending updates or mitigations to align the code base
with security standards.
Finally, fuzz testing,
or fuzzing,
injects randomized data into executing code
to find weaknesses in input handling.
Tools like the Peach Fuzzer
and WSFuzzer are used to test how applications respond
to unexpected inputs,
uncovering errors that could be exploited.
So remember, the technical attack surface
includes all potential entry points
in an organization's technology infrastructure
that could be exploited by attackers.
Key components in managing this surface include:
architecture reviews, data flows,
trust boundaries, and code reviews.
Architecture reviews evaluate a systems design
to spot weaknesses,
ensuring configurations are secure
and data storage is protected.
Data flow analysis examines
how information moves across systems,
identifying areas where sensitive data might be exposed.
Trust boundaries define points where data transitions
between different security levels,
such as between internal networks and the internet.
And by managing these boundaries with tools like firewalls
and segmentation,
teams can restrict access to critical areas.
Finally, code reviews detect vulnerabilities
in source code through static and dynamic analysis,
ensuring applications are resilient before deployment.
Together, these practices secure the infrastructure,
reducing the attack surface,
and strengthening system defenses.