In this lesson,
we will learn about post-deployment testing.
Post-deployment testing is used to evaluate software
after it has been released into a live environment
to identify and address any security vulnerabilities
and performance issues.
Post-deployment testing concepts include
software vulnerability analysis
and Runtime Application Self-Protection, or RASP.
Let's learn more about software vulnerability analysis
and Runtime Application Self-Protection.
First, we have software vulnerability analysis.
Software vulnerability analysis identifies
security weaknesses that exist within a live environment.
The primary objective of vulnerability analysis is
to find and address vulnerabilities
that attackers could exploit before any exploitation occurs.
This analysis process involves
scanning a deployed application
and its surrounding infrastructure
for known vulnerabilities,
such as unpatched software, misconfigurations,
or insecure code.
By performing vulnerability analysis after deployment,
security teams can continuously monitor
and protect the application
as new threats and vulnerabilities emerge.
A variety of tools can be used
for software vulnerability analysis.
For example, OpenVAS is
an open-source vulnerability scanner
used to identify software vulnerabilities
across various systems, networks, and applications.
OpenVAS can detect weaknesses such as outdated software,
insecure configurations, and missing patches.
OpenVAS also provides detailed reports
to help prioritize remediation.
It is highly effective for continuous monitoring of systems
by regularly scanning
for new vulnerabilities as they emerge.
This is important because vulnerabilities can be identified
after a system has been deployed.
New threats can be discovered
or changes in configurations may create vulnerabilities.
So regular scans are essential for maintaining security.
Regularly scheduling scans with tools like OpenVAS helps
organizations catch and address evolving risks
before they are exploited.
For instance, OpenVAS can be configured automatically
to run vulnerability scans on a recurring basis,
ensuring that any new vulnerabilities
or vulnerabilities above a severity threshold are flagged.
Without recurring scans,
even previously secure environments become
vulnerable over time,
particularly when new software updates
or third-party components introduce new risks.
But vulnerability analysis has its weaknesses.
One of the main challenges is
that many tools rely on databases of known vulnerabilities,
meaning they may not detect zero-day vulnerabilities.
A zero-day vulnerability is a new and unknown threat.
Because they are unknown threats,
documentation and patches don't exist.
Additionally, vulnerability scanners can generate
false positives, which are flagged issues
that do not actually pose a threat.
These false alarms can slow down the remediation process
as security teams investigate known issues.
Now, let's take a quick pause
to see how OpenVAS can be configured
to conduct recurring scans.
I am using a Kali Linux virtual machine
with OpenVAS installed.
First, let's create a new target.
In the Configuration menu, I'll select Targets.
Then I'm going to select New Target.
Creating a target tells OpenVAS what to scan.
This ensures we define which servers, networks,
or applications will be checked for vulnerabilities.
In this example,
we're going to scan the entire 192.168.0.0/24 network,
and we'll call this target list myTargets.
And I'll save it.
Next, we need to create a new scan task.
A scan task defines
when and how the scan will be conducted.
I'll start a new task and here we go.
In this example,
we're going to call our scan Weekly Vulnerability Scan.
And we'll load up the target list
we just created, myTargets.
And we'll check that our configuration is set
for a full and fast scan configuration.
Then we need to schedule our weekly scan
by creating a new schedule.
Scheduling our scan helps automate the scanning process,
so OpenVAS will scan our targets
without requiring a manual start.
In this example,
we will schedule our scan
to occur weekly on Saturdays at 1:00 AM UTC.
So I'll select the next Saturday
and set it for 1:00 AM.
And I want it to recur weekly.
And I need to give this a name.
So I'll call it mySchedule.
I'll go ahead and save it.
Next, we could set up alerts for high-level vulnerabilities
by selecting Create a new alert.
In a vulnerability scanner,
setting up email alerts for high-severity vulnerabilities
ensures we are notified immediately
if critical security issues are detected.
In this case,
we'll manually review our results without email alerts.
All right, once everything is configured,
we just need to sit back
and wait for our automatic weekly scans to occur,
and then respond to any vulnerabilities that are detected.
You can see that my scan is created,
it's listed as a new scan.
And over here,
you can see that my scan will next run
on Saturday, November 9th, 2024 at 1:00 AM UTC.
Second, we will talk
about Runtime Application Self-Protection, or RASP.
RASP monitors and protects applications
while they are running in a live environment.
The main objective of RASP is
to provide real-time protection
by analyzing the behavior of the application
and blocking any detected threats or suspicious activity.
Unlike traditional security methods
that focus on perimeter defense
or scanning for vulnerabilities,
RASP operates within the application itself,
allowing it to detect and stop attacks
from inside the runtime environment.
RASP tools, such as Contrast Security or Imperva RASP,
integrate directly into an application
monitoring it for abnormal behavior,
such as unexpected input patterns
or attempts to exploit known vulnerabilities.
In practice, if a Runtime Application Self-Protection,
or RASP tool detects an attempt to execute an SQL injection,
it can immediately block the malicious action
and prevent it from affecting the application.
This makes RASP particularly useful
for addressing new vulnerabilities
or attacks that bypass external security measures
as it provides a layer of protection
based on how the application is actually behaving
in real time.
However, RASP does have some weaknesses.
One potential issue is performance impact.
Performance impact occurs
because RASP operates within the application.
So it can slow down the application's overall performance,
especially in highly complex
or resource-intensive environments.
Additionally, while RASP is excellent
for detecting runtime threats,
it's not a replacement for other forms of security testing,
such as vulnerability scanning or code reviews,
which are needed to address underlying security flaws
before deployment.
So remember, post-deployment testing is essential
for ensuring software security and performance
after the software has been released to a live environment.
Post-deployment testing focuses
on identifying vulnerabilities and protecting applications
in real time.
As an example, software vulnerability analysis helps detect
and address weaknesses
by continuously scanning for security risks
in the deployed application.
Next, Runtime Application Self-Protection, or RASP,
adds another layer of security
by monitoring the application during operation
and blocking threats as they arise.