Attack Simulations and Penetration Tests always pose a risk to the systems under review. The risk may be very low for non-production systems, but attacking a production system always pose a risk as it could impact a legitimate user who needs to access the system.
In this post we describe the basics of our approach to risk management, which is included in every of our Attack Simulation exercises. It is deployed in Penetration Tests too, even though most of the time a more stripped down version is used.
What is Risk Management in a project with Y-Sec?
Risk management is the process of identifying, evaluating and controlling identified cyber security risks during an offensive security assessment. This a continuous process during every Attack Simulation we perform and is also done during a Penetration Tests of e.g., a Web Application. During our assessments we bring potential risks to the attention of our clients to counteract against unforeseen consequences of an attack. The risk itself is usually discussed with our client to:
- Identify the What-If scenario and consequences of the risk
- Identify if a Plan B or playbook exists to restore the system or function in case it behaves abnormal
- An alternative approach to review the function is possible (this is usually not done in Attack Simulations)
When should I do Risk Management?
The short answer is always. Risk Management is one of the key values to success in Attack Simulations as full transparency is required throughout the assessment to avoid any disruption of services. Even in Penetration Tests we perform continuous Risk Management. This includes assessments targeting:
- Critical Infrastructure (e.g. KRITIS)
- Production Systems (e.g. a company domain network) for which no test environment exists
- Test Systems with attached production systems, e.g. mail server , Active Directory Login, SAP Systems
How we are performing our Risk Management
Risk Management is performed continuously in a Better Safe Than Sorry approach. This approach needs dedication and honesty of both sites which also includes full transparency. The process can usually be divided into three stages:
Pre-Assessment
The Risk Management already starts at the earliest possible stage which is the Scoping process. This is used to understand the design of the in scope systems (such as external back-end systems) discuss critical parts of the systems and functions (such as sending e-mails). Additionally, the project team agrees on the frequency of Meetings to discuss the progress of the assessment.
Assessment
We constantly Evaluate risks associated with an action (attack) and discuss possible consequences with stakeholders before conducting them. Risk evaluation is performed using the CIA triad and transparently documented as part of the Risk Management.
After
During the assessment we keep detailed notes as part of our Log Management. This includes information about performed actions, which can be used to trace actions back to the time it was performed.
The detailed log management does not only include active attacks, but also detailed information about performed Authentications (e.g. with compromised user credentials) or Observations.
The Confidentiality, Integrity, and Availability (CIA) triad is used to evaluate an identified risk. Depending upon the environment and usage of the system, a vector may be more important than the others. For example, Availability may be a more important than the Confidentiality of a globally used system if a downtime would impact those working with the system or disrupt a company’s core service.
The risk associated with each vector can be defined as Low, Medium or High and is chosen in collaboration with the client’s project member.
Active Risk Management
Each risk is evaluated individually and includes measures on the client’s side and Y-Sec’s side to lower the calculated risk. If appropriate measures are in place to lower the risk, then the project team can decide if the associated risk can be accepted. Documenting a risk also includes having contact details ready if the worst case scenario happens.
Let’s have a look at the exemplary risk of a SQL-Injection which may be found in an Attack Simulation Exercise or Penetration Test:
|
SQL
Injection in License Manager
|
|||
|
Confidentiality
|
Integrity
|
Availability
|
|
|
Moderate
|
Low
|
Low
|
|
|
Risk |
The login area of the application was found to be vulnerable against SQL-Injection. The SQL-Injection is likely within a SELECT statement which can only be used to read and not write data.
|
||
|
Mitigation
YSec |
Access will be limited to user having a @y-example.com e-mail address. Only one user at a time will be read from the database. Requests to the application will be limited to 5 per minute.
|
||
|
Mitigation
Ex |
Usage of SELECT statement was confirmed. Daily system backups exist and can be recovered within minuted. Application is only used by 3 users a day.
|
||
|
Contact
Person |
Van Houten +49 157 XX XXXXXXXXXXXXX Simpson +49 157 XX XXXXXXXXXXXXXX
|
||
|
Status |
Approved
|
||
In the above risk the Confidentiality was set to Moderate as production data is impacted and legitimate user of the application. The Integrity has been rated with a Low impact as the SQL query can not be used to change data in the database. Additionally, any downtime of the application, shown via the Availability vector, has been rated with Low impact.
Y-Sec Risk Mitigation
To lower the Confidentiality risk, Y-Sec ensures that data is only read of administrative users that have an email address set that matches the client’s domain. Additionally, only a limited number of user will be read per SQL Injection which also limits the risk of affecting the Availability.
Client Risk Mitigation
The client verified that the SQL-Injection is indeed within a SELECT statement which removes any risk on the system’s Integrity as data within the database cannot be changed. Additionally, the client confirmed that daily backups of the system exist and the application is only used by a few user per day. A risk regarding the Availability can be neglected.
Implicit Risk Management
During a Penetration Test of an application, it is often the case that e-mails are automatically send to a user, e.g. upon a Password Reset or Registration. The e-mail server used may be non-productive, but it may still be that a Denial of Service condition is created if the function is flooded with requests. This is a classic example of implicit risk management that is continuously performed in Penetration Tests.
Whenever a critical function is identified then the tester will determine if this may disrupt the system under review. If the tester decides that the function may not cause a direct impact on the system, then the function will be tested using a manual approach first, before using tools to automate sending requests (which will then be reviewed manually). This gentle approach includes continuously reviewing possible side effects of the performed tests.
In some cases, it may be that a function cannot be reviewed as it will disrupt the system. In an Attack Simulation we usually move forward to identify another entry point to reach the goal of the simulation, but in a Penetration Test this wouldn’t work. If this is the case, then alternative approaches can be used to still review the function, such as a manual Code Review of that specific part.
Not a universal approach
Risk Management is not a universal approach and the required depth differs across the services we offer. Our team has performed assessments in highly sensible environments, such as KRITIS environments, global banking systems including mainframes and SWIFT networks and many other. This experience helps us to create tailored risk management plans during our assessments. If you are interested in further information, then give us a Ping via request@y-security.de.
Author
Christian Becker
christian@y-security.de
Y-Security GmbH
06. December 2022