Planning engagement
Scope and boundaries
Okay, let's start with the fact that scope is your everything. At first glance, it seems that in IT Red Team, it's simple - you can attack a server, a network, maybe an end user at the workplace. But it's not that simple. It's not just about access, but about the impact on real processes.
To clearly define the boundaries for testing, it's important not only to agree on what can be attacked, but also to discuss the consequences such attacks may cause. For example, you might want to test a vulnerability in the pump control interface at a hydroelectric power plant. While this may seem like a good idea, it's important to consider the potential consequences of your script causing the pump to malfunction. When working with technical experts, it's crucial to establish clear boundaries between areas where testing is permitted and those where your activities should not interfere with critical systems.
Additionally, it's essential to understand the distinction between hardware and information systems. Not everything that is connected to
Reporting and remediation
So you've already run the tests, found the weak points, and understood what's behind it. But now comes the most interesting part - reporting. No matter what anyone says, these tests are only half the battle. The other half is how you present it. Yes, yes, don't get me wrong: vulnerability testing doesn't save the day if the report isn't properly written. It's not just a formality. This is part of the whole game, and if you lose it, no one will want to work with you next time.
Therefore, the first rule here is that the report should be like a clear line between you and the customer who will work with it. It should be clear and understandable, but not in the style of "everything is bad, and we need to withdraw money and close all the vulnerabilities." No way. Everything should be done carefully, and most importantly, with proper recommendations.
Let's go through the points:
What should be in the report?
Of course, a description of the vulnerability. But here's how to describe it so that the customer doesn't lose heart: write it in a way that makes sense.
Scope and boundaries
Okay, let's start with the fact that scope is your everything. At first glance, it seems that in IT Red Team, it's simple - you can attack a server, a network, maybe an end user at the workplace. But it's not that simple. It's not just about access, but about the impact on real processes.
To clearly define the boundaries for testing, it's important not only to agree on what can be attacked, but also to discuss the consequences such attacks may cause. For example, you might want to test a vulnerability in the pump control interface at a hydroelectric power plant. While this may seem like a good idea, it's important to consider the potential consequences of your script causing the pump to malfunction. When working with technical experts, it's crucial to establish clear boundaries between areas where testing is permitted and those where your activities should not interfere with critical systems.
Additionally, it's essential to understand the distinction between hardware and information systems. Not everything that is connected to
Reporting and remediation
So you've already run the tests, found the weak points, and understood what's behind it. But now comes the most interesting part - reporting. No matter what anyone says, these tests are only half the battle. The other half is how you present it. Yes, yes, don't get me wrong: vulnerability testing doesn't save the day if the report isn't properly written. It's not just a formality. This is part of the whole game, and if you lose it, no one will want to work with you next time.
Therefore, the first rule here is that the report should be like a clear line between you and the customer who will work with it. It should be clear and understandable, but not in the style of "everything is bad, and we need to withdraw money and close all the vulnerabilities." No way. Everything should be done carefully, and most importantly, with proper recommendations.
Let's go through the points:
What should be in the report?
Of course, a description of the vulnerability. But here's how to describe it so that the customer doesn't lose heart: write it in a way that makes sense.
