From Theory to Practice, How the Attack Chain View Helps

As part of practical software engineering practices, we have all learned about threat modeling. From contemplating security boundaries to meticulously creating controlled interfaces operating and offering services across these boundaries. From STRIDE to the latest Cyber Threat Framework, there are various methodologies we go about performing these exercises. With the business growth and pivots we take, our software ecosystem continues to evolve, growing in complexity and making it challenging to reason about design decisions and their implications to the larger threat model(s). Typically this leads to more isolated and localized decisions which could be further exacerbated by the way the team operates (DevOps vs Dev & Ops), where a sound localized decision may not be the best course of action when looking at the larger picture.

It may sound funny, but with all the tools and information floating around, it’s easier to see how a  “Threat and Vulnerability Risk Management” program quickly devolves into “Vulnerability Management” program as given the size of environment, actionable focus moves away from understanding threats and risks and becomes more of a number game of SLA’s (resolve “Critical” in X time frame and “High” in Y time frame). As we embarked on our journey to leverage advances in AI to generate contextualized cyber attack chains in a given target environment, we wanted to bring focus back to the threats and risks and not just focus on the individual vulnerabilities. Here are few ways the attack chain view could help you manage cyber security of your environment more efficiently:

Insights into Network Architecture

When you look at collective attack chains, beside the obvious case of external attack surface reduction, network segmentation becomes a discernable target for mitigation as recognition of various paths to targeted resources become apparent. Always keep in mind that an external entry point is potentially one vulnerability disclosure away from getting access to your internal environment. So knowing and reducing the components that can access/reach critical resources helps in reducing the overall attack chains.

Understanding the Access Impact

Instead of focusing on generic findings like “*” In permissions, knowing how those permissions can be actually abused in your environment leads to relevant architectural discussion/insight and thus allows for more permanent threat reduction. There are obvious cases of over privileged roles which you can easily remediate using tools like access advisor, but more complex access issues – that only can be exploited when chained in multiple steps – or determining the blast radius of a potentially dangerous permission are easy to miss. This architectural insight enables more robust discussion such as splitting the workload into specific functional areas with only required permissions and thus again reducing the threat of end-to-end attack chains in the long run.

As mentioned earlier, not all localized decisions for least privilege are necessarily correct. Attackers are creative and more importantly persistent, and are able to combine two seemingly disconnected paths into larger impact. Attack chain view allows you to view these paths in a more holistic way and thus make the right engineering decisions.

Recognition of Focus Areas

Over the period of time, once you further abstract the attack chains, it becomes easier to recognize problematic areas. A cluster view of attack chains informs where large internal attack surface areas are and how they could be abused:

These areas could be because of use of deprecated libraries, services that may  not have necessarily gone through the engineering rigor you typically want, or areas where ownership has changed too many hands leading to minimal touches. Whatever those reasons are, having the recognition of those areas allows you to marshal your resources better to again reduce the larger risk in a more comprehensive way.

Understanding of Engineering Practices

Interestingly, having a larger view of the various attack chains, reveals interesting engineering aspects of your environment.

A combined graph like above could indicate multiple teams following different practices for deployment or security, which also imply that you will have larger challenges in driving for  mitigation/remediation of these risks. Similarly an attack graph like below could be an indicator of more uniform architecture and engineering practices.

Even if risk is higher, the steps to mitigate/resolve can be applied uniformly thus mitigating the risk quickly.

As we move forward, we would share more case studies on how attack chain based view changes the engineering and security practices for the better!