Working with your SOC/MDR during a security assessment

aligning your security assessments to organizational goals


Red teams, penetration tests, vulnerability scans: there are different kinds of security assessments, and what you perform should be aligned to your organization’s goals.

Hopefully your organization recently conducted a year-end security assessment. If not, or if you’re new to cybersecurity, these assessments test security controls (operational, technical, even managerial) through a variety of techniques and tactics, ensuring the controls are implemented correctly and any gaps or issues are identified.

The two primary ways of performing security assessments are through penetration tests and red teams. (Vulnerability scans deserve an honorable mention, but should generally be ongoing and addressed differently.) There are many reasons to perform a security assessment, including compliance, security hygiene, and stress testing your security operations center (SOC) or incident response (IR) plan.

Pen tests and red team exercises are more than demonstrations of our services in the event of a real compromise—they’re also an opportunity to work together and improve. This is the ultimate goal of an assessment, and to that end we provide resilience recommendations to protect our customers’ environment. Additionally, we’re reviewing these exercises to identify opportunities for new detections. With better visibility, we’ll respond faster, helping the organization remediate more efficiently, especially with open communication.

We may focus on some more than others, depending on the goal of the security assessment and its results.

Before going further, here’s a quick overview of both red teaming and penetration tests. They’re similar engagements that test the security posture of your environment, and although they may seem interchangeable, they typically differ in the tactics, scope, and objective. As a result, what you focus on during and after either one will also be different.

Penetration tests typically focus on finding vulnerabilities or weaknesses on a broad scale and exploiting them in a controlled way, generally without a specific objective or target after exploitation. As a result, they’re usually “noisier,” less expensive, and are likely coordinated with specific teams. Since pen tests aim to identify weaknesses to exploit, your focus should be on detecting those actions, in addition to fixing them.

Red teams also seek weaknesses to exploit, but are much more targeted so as to avoid detection. Red teams emulate real threat actors, using tools and tactics that are generally less common and harder to detect. The result is a stealthier operation focused on exploitation after the attack lifecycle. In addition to detecting the red team, the SOC’s focus should include the security team’s ability to respond and remediate.

Venn diagram - compare penetration testing vs red/purple team assessments

The type of engagement (automated vulnerability scan, penetration test, red team) you’re running should align with your overall goal, which will fall into one or more of these categories:

  • Defending: can your security measures prevent an incoming attack?
  • Detecting: can your organization identify a threat and surface related evidence?
  • Responding: can your team stop and remediate the threat?

Each category builds onto the next one:

  • If you’re well defended, you’re more likely to be able to detect
  • If you can detect more, you can respond faster
  • If you can respond faster, you can limit impact and resume operations

Understand what your organization is trying to accomplish with the engagement and prepare accordingly—especially for red teams, as their simulation of a real attacker signals a greater risk to business. With this in mind, as well as key questions to help accomplish your goal, it’s time to talk with your SOC or MDR.

No matter which type of engagement you’re running, a core goal of all of these is to test your organization’s ability to defend itself. Vulnerability scanning is generally limited to this category and should be done regularly. While you want to be notified of discovered vulnerabilities, you should separate internal vulnerability scanners from your detection strategy to limit noise and focus on external threats. Key questions to ask for defending include:

  • Did the technology do its job?
  • If not, why? Are there missing configurations, or disabled features?
  • Is additional technology needed to stop what was missed?
  • Is the environment up to date and configured to best practices?

Fixing the issues found is a constant uphill challenge. The changes and updates take time to implement (and you need to ensure they don’t break more than they fix). In the meantime, you can take action to make sure you have visibility to alert on the activity by reviewing your detections.

Penetration tests should not only help uncover an organization’s weaknesses, but also highlight its detection strategy to identify when those weaknesses are abused. Ideally you detect all the actions taken by the penetration testers. That may not be realistic, but it doesn’t mean you shouldn’t try. Key questions to ask for detecting include:

  • What was detected and what wasn’t?
  • For things not detected, what detections can be added or created?
  • Are there enough detections in case something gets turned off?
  • At what phase of the attack lifecycle was the detection?
  • Could it have been detected earlier?

Better detections provide strong leads for faster response. With detections at each stage of the attack lifecycle, your SOC or MDR can trace the red team’s path to identify new indicators and remediate efficiently. An organization’s ability to respond and remediate is critical to limit risk and restore normal business operations. Red teams help train and measure this by emulating a real threat actor. Key questions to ask for responding include:

  • How long did it take to respond?
  • How long did it take to remediate?
  • Were there any challenges with remediations?
  • How many of the actions performed by the testers (if not all) were identified while investigating?

We see security assessments as a way for our customers to improve, but we’re also looking to improve. Most importantly, we want to strengthen the way we work together as a team. We use penetration tests and red teams to test detection strategies and exercise our analysts’ investigative muscle. Knowing the goals an engagement serves and communicating openly about them helps us tailor our focus to provide the most value.

For example, when running a penetration test with the aim to improve detections, alerts related to the engagement are tracked in a single investigation, with a timeline section listing all surfaced detection, along with a high-level summary of detected activity. During a red team engagement, in addition to the above, we’ll actively investigate to identify additional hosts, users, and indicators of compromise (IOCs), summarizing key findings and tactics in a report, providing a deeper dive. In both cases we assign mock remediation actions to contain assets.

Open communication about the engagement (or access to the assessment report) lets us compare the detections and indicators identified during response versus what was done during the engagement to identify detection opportunities and ways to improve.

There are a variety of reasons and ways to run a security assessment. Depending on how the assessment went, the road to improvement may be shorter or longer, and it’s always ongoing. It can be complicated to know where to start first.

Understanding your organization’s goals, running the engagement type that aligns best with them, and asking the right follow-up questions to cover with your SOC or MDR, these are the most important steps towards getting better. By tracking progress over time you can measure and quantify your improvements, comparing them with past or future engagements.

If you have questions about security assessments or what it’s like collaborating with a managed detection and response provider, we’re happy to talk.