Over the past few years, I've had the pleasure of welcoming interns on our security research team. One of my goals was to pass on knowledge of security to these folks and pique their interest in (a career in) security. The goal of any teacher is to pass on their knowledge to the younger generation, in essence creating a miniature version of ourselves, which is hopefully somewhat better. Let me take you back in time to 2015 when we had our first round of interns. I had the bright idea to go full-throttle. We loaded up Kali Linux, launched a Damn Vulnerable Web App instance, started scanning with OpenVAS and NMAP and then used Metasploit to attack everything we could. The problem with this was that these young interns had no experience in security. Their eyes were the size of saucers, and they walked around looking confused. The next two years, I reeled it in a bit and started with essentially having them complete a book report on that year's Verizon Data Breach Investigations Report. What I wanted them to understand was some of the key terms in security, how attackers work, what attackers are after and what defenses organizations are using to protect against these attacks. Once this was complete, I kicked them out of the building. I had them run through a scenario of needing to gain access to an encrypted file on their computer back at their desk. Starting from the street corner, I had them provide a report of every security control they encountered on their way to the text in that encrypted file. These could be mitigating controls, such as door locks, security guards or passwords on the computer. They could also be deterring controls, such as video cameras. Nobody ever gets every control, but it provides an excellent way to understand where their minds are at in relation to security. This can be valuable in defining where the rest of the internship may go. To excite these interns about security, I tried using something that they could relate to. These particular interns were from FIRST Robotics, so I acquired a WiFi-controlled toy car. This toy was based on a Raspberry Pi, allowing them to download code off of GitHub. They physically assembled the car and then configured it the way the manufacturer recommended. We then walked through how to find vulnerabilities in this car and how to actually exploit them. With this knowledge, I tasked them with fixing the vulnerabilities and reassessing the security of the toy. On their final day of the internship, we allowed our employees to have a hand at hacking into the car. We did this toy car exercise for a couple of years, but I always thought there could be more to teaching these interns about security. I came across the Bloom’s Taxonomy of Learning in Action and realized that I was skipping the first step of learning, the ability to acquire the knowledge. Once you have the knowledge, you can begin to move on to comprehension, application and beyond. This is the reason why my teachers in school always told me to read the books three times, something I never actually did.
Around the time I came across Bloom’s Taxonomy, I was actively researching the MITRE ATT&CK framework. I thought to myself, “I wonder if the knowledge portrayed in ATT&CK would fill the gap of that first step from Bloom’s Taxonomy.” I began to split the various ATT&CK techniques into categories that could be used for junior-level interns versus those that would be used by folks with more knowledge in security.
Using MITRE ATT&CK and Bloom’s Taxonomy of Learning Together
'Techniques Only' are those which are not really exploits. Rather, they are used by other techniques to achieve their objectives. A good example of these are PowerShell, graphical user interface or any of the techniques in the discovery technique. 'Exploitable to Anyone' are techniques which are easy to exploit. These are the ones which I would be able to hand off to my interns that allow them to exploit and further investigate. Accessibility Features and Registry Run Keys are some of these types of techniques. 'Additional Steps Required' are the techniques that need some sort of tooling to easily test. Using something such as Metasploit or other proof of concept scripts can unlock the potential of these techniques to anyone. A great example of these are exploitation techniques. 'Cost Prohibitive' require some sort of infrastructure to properly test and/or research. Once the infrastructure is set up, these techniques can range from very simple to very complex. I bundled these together, so I can set them aside if I do not have the time prior to teaching security to set up the environment. An example of these techniques are Web Shell or Taint Shared content, which would require a file share or web server to be able to analyze the given technique. The final category is 'Hard.' These require either a custom DLL or EXE file or a very in-depth understanding of the operating system or hardware of a given system. For example, these could be Rootkit, Firmware or Process Injection techniques. When you put all of these together, you can visualize them in the ATT&CK Navigator to create what I call the ATT&CK Rainbow. What I love about this is that for nearly every tactic, with the exception of 'Discovery,' there are techniques that someone from every expertise in the security industry can begin to look at. For example, the 'Persistence' tactic has green, yellow, orange and red categories. If your class, department or you individually are looking at the 'Persistence' tactic, there’s something you can leverage.
When it’s all said and done, I like to have a few learning objectives I like to put forward. The first is “What did you learn?” Was this from the ATT&CK framework itself, one of the linked articles or from some of your original research? I like the last part particularly because I am a fan of feeding information back to the team behind the ATT&CK framework, so it can be improved upon. The next objective is for both mitigation and detection strategies. Did these strategies work? Can they be bypassed? Can anything be added which you think is missing? One example I like to use is for registry run keys in which you can add a registry key to launch a web browser whenever the user logs in. The mitigation strategies call for application whitelisting, which may not work in this case where the browser is allowed to run. The detection strategies call for monitoring the registry run key locations, but ATT&CK doesn’t provide what these keys are. This is a great technique to start with to get people looking into ATT&CK and allowing them to think critically about what it means to leverage it in an enterprise environment. If we have younger kids who are just starting to learn about information security, having quick and easy wins like playing with registry run keys can help peak their interest and make this industry exciting. For those who are in the industry but may not have as much experience, having guidance on various techniques, how to test them, how to mitigate and how to actually detect them is incredibly valuable as a teaching tool. For those that are seasoned veterans, there are still ample opportunities to step outside of your comfort zone and learn more about tactics and techniques with which you are not familiar. If you are interested in learning more, I gave a presentation on this subject at both ATT&CKcon and BSidesPDX earlier this year.
