Pentests and the SOC
Penetration testing is a critical part of any robust cybersecurity strategy. However, a successful penetration test relies not only on the skills of the testing team but also on effective collaboration with the security operations team. Providing the right information to your security operations team before a penetration test can prevent false alerts, streamline investigations, and enhance the overall effectiveness of the testing process.
I have led the product for security operations building SOCS which monitor and support multiple cloud banking platforms. A SOC can take all the logs and apply foundation rules to the logs to try and detect activity which needs investigation.
And the same goes for penetration testing, yes we test the application or infrastructure, find the vulnerabilites and put together a plan for remedation. But value can be gained from also engaging the SOC to enabl them to also test they have visibility of the testing taking place. Granted this is not always possible as some tests will be with 3rd parties or offline where logs are not fed directly to the SOC.
Working in partnership, pentest teams and the SOC can have tremendous value in working together during tests, confirming and refining detection rules. But to begin the goal is to first engage the SOC team in any connected test where logs feed to the SOC, here is how I have approached this in the past to create really good collaboration between red and blue teams.
Scope and Objectives: Before conducting a penetration test, it’s crucial to clearly define the scope and objectives. Share this information with your security operations team ahead of any test so they understand what systems, applications, and networks will be tested. This prevents unnecessary investigations into activities that are part of the test.
Testing Schedule: Together with the Scope and Objectices, communicate the timing of the penetration test to your security operations team. Knowing when the test will occur helps them differentiate between actual incidents and scheduled test activities, reducing the risk of false alerts.
IP Addresses and Ranges: Provide a list of IP addresses, domain names and ranges that will be used by the penetration testing team. Importantly you must also provide information on the source of the test, which IP addresses or ranges will thos conducting the pentest originate from. This prevents security operations from mistaking test traffic for a genuine cyberattack. It wouldnt be the first time I have seen a production system being pentested but genuinely also being attacked only for the SOC to disregard all activity as the pentest.
Types of Tests: Inform your security operations team about the specific types of tests that will be conducted during the penetration test. Whether it’s a black-box, white-box, or grey-box test, web application testing only for example, understanding the approach helps them contextualize the findings and alerts they see.
Tools and Techniques: Share details about the tools and techniques that will be employed by the penetration testers. This knowledge allows security operations to recognize patterns associated with test activities such as burp suite. It doesnt mean you have to specify every CLI tool used, but more around how the testing will be conducted, is it a vulnerability scan, or targetted web interface test only.
Testing Team Contact Information: This is cruicial, provide contact information for the members of the penetration testing team. In case there are questions or concerns during the test, security operations can quickly reach out for clarification or to halt activity that is having an impact.
Test Scenario Documentation: Give your security operations team access to the documentation outlining test scenarios and objectives. This enables them to align their monitoring efforts with the specific goals of the penetration test.
Expected Anomalies: Discuss with your security operations team the expected anomalies and activities that might occur during the test. This could include unusual login attempts, port scanning, or testing for specific vulnerabilities. By knowing what to expect, security operations can again avoid unnecessary investigations.
Test Duration: Clearly communicate the expected duration of the penetration test, start and end times, and clear communicate with the test team the actions they need to take if testing continues outside this timeframe. This helps security operations plan their monitoring activities accordingly and prevents alarm fatigue from extended testing periods.
Escalation Procedures: Establish clear escalation procedures in case security operations detect test activities that were not adequately communicated. Having predefined steps for handling such situations ensures a coordinated response.
MITRE ATT&CK Framework Integration: Consider integrating the MITRE ATT&CK framework into your penetration testing process. The MITRE ATT&CK framework provides a comprehensive matrix of tactics, techniques, and procedures (TTPs) that adversaries use during cyberattacks. By mapping your penetration test activities to the MITRE ATT&CK framework, you provide the SOC with a structured way to tune their detection mechanisms.
For example, if your penetration test involves mimicking a phishing campaign to assess employee awareness, the SOC can focus on detecting email-related TTPs within the MITRE ATT&CK framework. By doing so, they can differentiate between your test activities and real phishing attempts. It also helps the SOC to confirm they are successfully detecting the activity.
If a pentest takes place but the SOC have no visibility of what occurred during the test from logs and alerts, this is an area they can focus future alerting rule development.
Customized Detection Rules: As I mentioned, Work closely with your SOC to develop customized detection rules based on the specific TTPs associated with your penetration test. These rules should be finely tuned to recognize test activities while minimizing false positives for genuine threats.
Continuous Monitoring: Encourage your SOC to continuously monitor for the TTPs mapped to the penetration test activities, even after the test has concluded. This helps maintain vigilance and ensures that any residual test-related activity is promptly identified and attributed correctly.
Feedback Loop: Establish a feedback loop between the penetration testing team and the SOC. Encourage the SOC to provide feedback on the effectiveness of the detection rules and whether any refinements are needed, can the pentest team help with running specific attack simulations which were not detected during the test to build new alert rules and refine them. This iterative process enhances the SOC’s capabilities for future tests.
Integrating the MITRE ATT&CK framework into your penetration testing process is a worthwhile process, it not only helps the SOC fine-tune their detection mechanisms but also aligns your testing activities with real-world adversary tactics. This approach enhances the overall effectiveness of penetration tests and ensures that the SOC can differentiate between test activities and actual cyber threats more efficiently.