Application lateral movement defines the attacker’s ability to leverage a breach of a single resource to then successfully move across resources from different organizational applications.
All applications are not created equal within modern organizational architecture - they carry different levels of risk, and their access to internal resources and assets should be considered with that in mind. Much like company employees are only granted access to sets of data as they relate to their specific position, and should not be able to access others, so should organizational applications be segregated from one another in order to significantly reduce an attacker's ability to exploit one application’s vulnerability to target others.
How does application lateral movement occur?
There are various ways in which access to one application can be used to breach others, by leveraging one or more of the following in order to allow for application lateral movement:
Why is application lateral movement popular with attackers?
In most cases, developers are the organizational owners of all development processes and, along with the core R&D teams, are in charge of the overall R&D velocity - creating developers' self-serving tools, libraries, and frameworks while being measured by their ability to deliver features and increase this velocity. In a sense, this may be the equivalent of the fox guarding the henhouse, as their goals and responsibilities - with little security oversight - are prime positions for attackers to find a way into the organization and maximize their attack efforts. This risk grows exponentially without proper mitigation and governance - as a single vulnerability caused by a single commit of code in any application may be chained by lateral movement to compromise critical organizational assets. We are witnessing a growing volume of high-impact attacks originating from a low-risk asset or from the compromise of a single developer workstation or credentials.
What can I do in my organization?
Once you map out the gaps, you should consider mitigation strategies in full collaboration with R&D teams so as to find the optimal middle ground between security and efficiency, without impacting their velocity.
For example, if developers are used to working with self-service provisioning of new applications, you might want to change that flow and require the approval of an additional developer for any provisioning of new applications, rather than have a security review for every new application request. In such a case, a malicious request for provisioning a new application is much less likely to be successful for the attacker, and in fact, acts as another control where an ongoing attack could be detected and mitigated.
Once all known gaps are mapped out, we encourage you to challenge yourself with a dedicated PT scoped for application lateral movement. Such a scope could begin with granting access to a low-risk application, with the goal of reaching critical assets via application lateral movement. This kind of drill will provide you with important information that should be used to both reassess existing AppSec methodologies, and also accurately reflect your organizational security posture internally, to ensure that the risks of application lateral movement are known and dealt with.