Implementing ATT&CK in All Parts of Your SOC

This chapter will outline how to narrow down your environment and prioritize where you need to fix a coverage area. The chapter will then list how you can implement detections and the ATT&CK framework as part of your overall security posture, and how it can be applicable to teams outside of the SOC as well. This chapter will cover the following:

• Examining a risk register at the corporate level
• Applying ATT&CK to NOC environments
• Mapping ATT&CK to compliance frameworks
• Using ATT&CK to create organizational policies and standards

Technical requirements

For this chapter, there are no installations or specific technologies that are required.

Examining a risk register at the corporate level

As discussed in Chapter 2, one way to characterize and prioritize risks is in a risk registry. The issue is that not all risk registries are created the same. That means that some are at a high level, some can be too granular, and some have too many fields, which can be confusing when calculating risk. In my experience, the best corporate risk registers have to find the balance between being technical and accessible to all stakeholders. We typically use the following for the columns in the risk register:

• The business organization or applicable line of business
• A description of the risk
• The score for the impact if exploited
• The score for the likelihood of the risk being implemented
• The risk score (impact x likelihood)
• The identified risk owner (can be a team or a person)
• Current compensating controls
• The date that the risk was first added

This allows you to gather all applicable information for...

Applying ATT&CK to NOC environments

When looking at the ATT&CK framework, you can see that there are Enterprise, Mobile, and Industrial Control System frameworks for different purposes. Under the Enterprise matrices is Network matrix version 12, with the following sub-techniques:

• Initial Access:
  • Exploit Public-Facing Application
  • Valid Accounts
• Execution:
  • Command and Scripting Interpreter:
    • Network Device CLI
• Persistence:
  • Modify Authentication Process:
    • Network Device Authentication
  • Pre-OS Boot:
    • ROMMONkit
    • TFTP Boot
  • Server Software Component:
    • Web Shell
  • Traffic Signaling:
    • Port Knocking
• Privilege Escalation:
  • Valid Accounts
• Defense Evasion:
  • Impair Defenses:
    • Impair Command History Logging
  • Indicator Removal on Host:
    • Clear Command History
    • Clear Network Connection History and Configurations
  • Modify Authentication Process:
    • Network Device Authentication
  • Modify System Image:
    • Patch System Image
    • Downgrade System Image
  • Network Boundary Bridging:
    • Network Address Translation Traversal
  • Pre-OS Boot...

Mapping ATT&CK to compliance frameworks

As previously discussed, there are a large number of compliance frameworks, and it’s growing every year. In my opinion, the most common frameworks are the Payment Card Industry Data Security Standard (PCI-DSS), Health Insurance Portability and Accountability Act (HIPPA), Global Data Protection Regulation (GDPR), National Institute of Standards and Technology (NIST) – NIST-181 and NIST 800-53, for example – International Organization for Standardization (ISO) 2001, and Service Organization Control (SOC2). Of course, as mentioned, there are other types of compliance frameworks that might be more applicable to your environment. With a large number of compliance frameworks, it can be confusing to keep track, so finding common mappings helps simplify it. In this section, we are going to map out a few different techniques for different compliance standards.

The first technique that we’ll create is a mapping to T1556...

Using ATT&CK to create organizational policies and standards

A large part of having a mature security program is the policies and procedures. Unfortunately, that is one of the areas that is typically the weakest. The reason is that when standing up a new security program, there are so many priorities that your team starts focusing on the technical implementations, and before they know it, everyone has a different process for triaging, adding detections, and making security engineering recommendations. Fortunately, when implementing the ATT&CK controls for your SOC and other environments, you naturally have to evaluate and tune settings, and that is a great time to create policies and standards. The difference between the two is that a policy is a set of general guidelines or proposed actions. Policies can be more general and are typically written for compliance regulations; they show the intent for a set of actions that a team or organization should follow. A standard is taking...

Summary

Evaluating a risk register at a corporate level, applying MITRE to other teams, mapping controls, and creating policies and standards are ways to increase the security standpoint of your organization and make them more efficient. As mentioned in the sections, most of these actions will require more manual work upfront but will save time overall. From this chapter, you should now be able to critically look at some of the non-traditional security teams and apply control mapping and MITRE controls to them, to help drive actions.

In the next chapter, we’ll cover areas for improving your SOC environment to help increase its capabilities and make it more scalable.