How to map security gaps to the Mitre ATT&CK framework

Examples of mappings in real environments

Security vulnerabilities and coverage gaps are a fact of life for anyone who works in infosec. Here are a few different outlined security coverage issues that I've experienced and their applicable mapping and prioritization on a quad chart, as well as a discussion about what work streams I would implement. All of these issues are extremely common and hopefully can provide insight for you as you look at your environment.

Learn more about Aligning
Security Operations with
the MITRE ATT&CK
Framework by clicking here.

The first issue that I've run into multiple times is a lack of logging, or a lack of logging the proper security logs. The reason that this is a problem is that logs are the first place a security responder will look when investigating an alert and attempting to find anything that is suspicious or malicious. If logging is not up to par, there are likely compromised activities occurring that you are not aware of because logs are also typically used to set up detection and alerts. To identify whether this is an issue, you need to determine what logs you need to capture based on the infrastructure and work structure of your organization. You also want to project out the size of the logs that you want to ingest into your log correlation tool. That way, you can assign priority to the missing logs. I assign my logs priority based on the number of potential detection rules and the level of effort needed to ingest them. For example, a list of missing logs might look like this:

As you can see, I've created a table that has the list of data sources that I want added to ingest, the vendor the sources come from (this matters when you have to determine potential integrations), the specific product the logs are coming from, the priority, the size based off of an internal scale, the size in the form of project GB for the next year, and a section for any additional notes. I would then be able to take this list and work with the respective teams to either implement integration or forwarders for ingesting logs. Even then, it's not quite that simple because you have to take into consideration costs and technical constraints. The number one reason I have experienced limited logging is due to cost, as some SIEM tools can be cost-prohibitive as you ingest more data, which isn't reasonable for a smaller organization to pay for. If that's the case, and you have the bandwidth for management, you should look into using an open source solution, such as standing up an Elastic, Logstash, and Kibana (ELK) stack.

Now, how does limited logging map to MITRE? In quite a few areas. Depending on the data, in this case, we'll use some of the examples from the chart of missing zero-trust VPN logs, authentication logs, guard duty logs, and vulnerability scans; they could be mapped to the following tactics:

• T1133: External Remote Services
• T1021: Remote Services
• T1570: Lateral Tool Transfer
• T1078: Valid Accounts
• T1098: Account Manipulation
• T1046: Network Service Discovery

These are just a few that could potentially be mapped to the missing logs. It of course would depend on the level of configuration that you have for the various tools as to other ones that could be mapped. In general, I find it easier to identify all of the tactics that could apply, and that determines which ones have coverage for mitigation and other implementations. That way, I don't accidentally leave one out of the potential list.

Another common security flaw that I have found at smaller companies was a lack of security training or immature security training. In general, I recommend yearly training, on top of exercises such as phishing exercises to test the employee group, so that everyone can become cyber-smart. Some controls that could relate to the lack of training could be as follows:

• T1566: Phishing Spearphishing Link
• T1598: Phishing for Information
• T1550: Use Alternate Authentication Material
• T1098: Account Manipulation

In this case, phishing tactics are obvious to map to security awareness training. However, other tactics were mentioned, which shows that training has a far reach. For example, if there are no procedures and no training on security, then what is keeping an administrator from granting overly permissive permissions or adding different methods of authentication because they might not understand the consequences? This shows that when mapping, you need to keep an open mind and try to understand the blast radius of an attack.

The third security flaw that I have seen is that Access Control Lists (ACLs) might be open to the internet or at least less restrictive than they should be. This is a common area, especially in development teams, where instances are stood up and down. It's easier to leave the instance open to the internet than taking the time to restrict it due to the thought that it'll get torn down quickly, or is just an oversight. I have worked on multiple incidents in my career, even early on, caused by shadow instances that had overly permissive ACLs, and given the move of practically everything to the cloud, this will only continue to occur. Some tactics that could be mapped to this finding are as follows:

• T1069: Permission Groups Discovery
• T1046: Network Service Discovery
• T1557: Adversary in the Middle
• T1563: Remote Service Session Hijacking

Again, these are just a few of the tactics that could apply, and if you have an overly permissive ACL and weak authentication, then you are at a higher risk for an overall compromise, which would be detrimental to your organization.

Taking these three security areas into account and thinking about work streams, I would categorize them on a quad chart as follows:

As you can see on this chart, I placed logging at high-effort/high-impact, placed ACLS as mostly high- effort and mostly high-impact, and placed security training as low- to mid-effort with a moderate impact. I chose these designations because implementing logging will take significant effort via creating integration or setting up forwarders, and that's if you even have the bandwidth on your tool to ingest the additional logs. The logs do provide a significant amount of impact because of the visibility they provide and the detections that can be created based on the logs. The ACLs involve moderate to high effort because they will need monitoring solutions, the likes of Guard Duty, Twistlock, or other tools. Policy creation will be needed to determine the proper ways to stand up instances and training. It is also ranked as having a moderate to high impact because of my experience with how common a security flaw this is, and having worked on multiple incidents in the past that were a result of this. Security training is placed as low to moderate in terms of both effort and impact. For effort, it's because there are a large number of solutions that can be implemented to easily assign and manage security training, and while there is a large amount of effort to set it up, you can coast to an extent (depending on your organization). In terms of impact, I am a big believer in training. However, it alone is not enough, and more needs to be done to protect your workforce. You may agree or disagree with the placements, but any placement is dependent on your organizational priorities.

For work streams, I would start implementing strong ACLs because I believe that will have the greatest impact-to-effort ratio. I think there is also synergy between implementing the ACLs and training, as in, training end users to set up proper ACLs. This shows that even though the logging project has a higher impact, it isn't the first one worked on in the work streams because of the amount of effort it involves, and the amount of discovery that would need to occur. If anything, it would make sense to start with implementing smaller, more accessible sources while scoping out larger sources.