Reverse Kill Chain Automation — Next Level of Incident Response Service.
Living through a cybersecurity breach is far more educational than education itself.
CEO: “Please, we are down again! Let me guess the hacker from some village in the Congo?”
CIO: “We are currently researching a root-cause analysis. All hands on deck!”
CISO:” Our security operations processes and procedures worked as expected.”
Dir of IT: “Are we sure it is not the same person that hit our attack surface?”
Yes, if you have lived through a critical “all stop” cybersecurity breach, confusion, after-the-fact processes, and running in circles used to be the way things unfolded.
Most cyber-attacks, including propagation of ransomware, unknown threats, denial-of-service attacks, and password spraying, happen daily. Some of these vectors happen so often. We tend to write them off as noise because of the sheer frequency and estimated impact on the user.
Even with the well-thought-out plans, incident response SOPs executed by the security operations center, and state-of-the-art containment from the NetOps, having an open mind when dealing with the attack helps the crisis much faster with fewer resources and resources time.
The theory of “deny any any” in the firewall.
During a security conference I attended, someone years ago spent 20 minutes of his presentation discussing the theory of inserting a “deny any any” into the firewall to stop all zero-day attacks. On the surface, this kind of thinking had read common sense. Drop all packets if the application or user port connectivity is not defined.
NetOps, SecOps, and Appdev communicate regularly, and everyone is on the page. Everyone knows what ports and protocols every application and user connection rules. The firewall changes happen dynamically based on a minor control rule, and in time, the security appliance is manageable even one year after deployment.
However, placing a catch me all rule within the security frameworks would make sense. However, many attack vectors happen over known ports and protocols. Email phishing is an excellent example of hackers bypassing all the legacy controls and placing the attack vector squarely on the shoulders of the end-user and security email gateway.
Outgrowing Legacy Security Automation Solutions
The new world is more about the security orchestration compartmentalization of an attack and response, not wholly taking everyone off the network. Hackers are smart enough to focus on multiple entry points within the client’s security infrastructure, using ransom times to hit their targets. One hacker attack vector could be a distraction with low-level malware while others focus on the actual attack. We can only figure out what has happened through trial and error, reviewing legacy baselines, and Wireshark packet captures. This method of cybersecurity troubleshooting does not scale to meet today’s multi-level attacks.
Reversing the Kill Chain
Developed by Lockheed Martin, the kill chain helped define the attack and possible response capabilities modeling. Like threat modeling, the client leverages various kill chain scenarios during a pen testing engagement. From the test results, the organization could create a new level of incident response service or “reverse kill chains” as the response scenario. Leveraging next-generation automation like MSOAR 0r email-focused security automation and response would be an ideal reverse kill chain function.
Organizations should continue to execute pen-testing randomly with every critical component of the environment. Taking the results of the “kill chain” pen testing, the blue team should own the “reverse” response process. Once the reverse kill chain automation response is active, the red team assessment team should target the same part of the network, validating the reverse kill chain capability. The reverse kill chain automation should have multi-threaded response scripts, commands, remediation, and notifications.
Once successful reverse kill organizations develop reverse kill chain contextual incident response playbooks, they should place the highest security protection on these capabilities. In time, as hackers attempt to break into the environment, most will be discouraged and move on. Some, of course, will let their ego get the better of them and try multiple times. The good news is organizations will be recording this hacking attempt, and I am sure they will hand over the records to their favorite FBI agent at the next InfraGard meeting :)
Let’s review our CEO meeting and see how the reverse kill chain changes the dialog.
CEO: “People are down again.”
CIO: “Yes, we quickly compartmentalized the attack to a small subsection. We have restored all users to ready state.”
CISO: “Our reverse counter-measures stopped the attack in several areas. We did suffer a breach within a small section of our cloud instance. We will adjust our counter-measures against future attacks.”
Dir of IT: “The network never went down, nor do we lose access to our username and passwords. Great work, guys.”
Automation is not new to SecOps. Leveraging the Kill Chain process and MITRE ATT&CK frameworks for threat hunting is not new either. Creating reverse kill chain automation will positively impact even during a zero-day attack.
Investing in automation isn’t about one component like XDR, email security, or dynamic ACLs. More about taking the knowledge gained by the Kill Chain attacks and creating several multi-tier reverse chains working together based on investment in pen testing, red team assessments, and continuous scanning in one collective good, not siloed by a single technical function.
Until next week,
John
