Advanced hacking groups are targeting applications, and they have a good reason
Attackers are constantly trying to gain access to private resources. Today, more than ever, the focus for attacks is the Application, and this is no random act. The shift of organizations to agile cloud-based environments, along with microservices and API-first architecture, makes for a complex application stack with many dependencies. All of this while the application is being automatically built and run by Continuous Integration and Continuous Delivery pipelines, and auto-scaling capabilities.
This shift is great for agile applications development, enabling amazing capabilities for an organization. However, it adds to the application stack and pipeline chaos, creating an enormous challenge for modern application security teams. Agility makes management of the application security posture much harder for security teams. The struggle of application security teams to keep up with the ever-growing gap is discussed among the security community. Advanced attackers and hacking groups know this all too well.
Let’s take a look at one of the biggest and most elaborate hacks of recent times — The SolarWinds’ Orion attack, attributed to highly advanced state actors. The fascinating and important part of this attack is the way the attackers used the application’s own CI pipeline to introduce their manipulated malicious application, as well as utilizing SolarWinds’ updates distribution system to distribute the malicious signed application automatically to unsuspecting SolarWinds clients.
“It’s one of the most effective cyber-espionage campaigns of all time,”
said Alex Stamos, director of the Internet Observatory at Stanford University and the former head of security at Facebook in an interview with NPR.
“In doing so, they demonstrated not just technical acumen, but the way they did this demonstrated that they understand how tech companies operate, how software companies operate.”
What is alarming to application security teams is the understanding that such an attack, compromising the application stack or CI/CD pipelines would be very hard to mitigate by modern organizations. The agility of application development creates vast areas that are either not covered by security as they are constantly changing, at scale — by the minute, or they are “covered” by yet another reporting system that is just too disruptive for application security teams to maintain in a relevant way.
“This was an intelligence collection operation meant to steal information, and it’s not the last time that’s going to happen, This is going to happen every day.
…And I think there’s a lot that we all need to do to work together to stop this from happening.“
Warned Adam Meyers of CrowdStrike’s who led the forensics investigation.
Another relevant recently published attack vector was dubbed dependency confusion. This vulnerability allows an attacker, in a fairly easy manner, to run arbitrary code as part of a local developer environment, CI build scripts, or in production environments. That is if an attacker knows (or guesses) the name of an internal private dependency package. We can tell it is an attack vector potentially affecting almost every modern R&D organization. This is due to the vast usage of dependencies in modern applications.
How did we get here?
The “dependency confusion” attack is also a great proof of concept for just how much modern application security teams struggle to assess their security posture, and how a specific vulnerability affects their security posture. As it turns out application security teams found it hard to list their organization’s private dependencies. Teams who were able to comprise such a list found it hard to determine which internal package was recently built, which package was being used by which service, and which package was developed by which developer, etc… This chaos made it hard for security teams to assess the organization’s application security posture, or in other words, application security teams struggled to do their job and safeguard the application.
When you think of it, in both attacks, unlike in attacks targeting data or user’s privileges, these attacks compromised the application stack — its source code, developers’ privileges, or the application CI/CD and production environments. Attacks targeting applications are gaining popularity, and they are expected to gain even more popularity in the future.
In the not-so-far past, the majority of the information security of applications relied mostly on infrastructure hardening, followed by monitoring of those policies and investigation of any violation. In such a mindset, you could manage your security posture as long as you maintained a secured network policy, separating the well-defined internal private resources from external public resources (e.g. via a network firewall policy), and keep the server’s infrastructure up-to-date, patched, and properly configured.
The application security part was confined to the development lifecycle mostly by threat modeling, penetration testing, and developers training.
These were never easy tasks but the growing maturity of infrastructure security products allowed a reasonable balance between the efforts of maintaining the security posture while enabling infrastructure growth. While the infrastructure assets management security tools have matured into the age of posture management platforms, in the application security this shift is just beginning, as more and more organizations adopt agile security posture that does not hold the development back while allowing clear ongoing posture management of the organization application security.
What’s next for application security?
The current goal for application security experts of all levels is clear: eliminate chaos. Easier said than done — The application stack is as complex as can be with multiple distinct efforts and multiple security reports and sources: compliance, bot detection, application PII handling, Penetration Tests, threat-modeling, code review, SCA, SAST, DAST, developers training, security policies, bug bounty programs, and more.
We see more and more application security teams trying to “close” the AppSec gap but with little way of knowing what should be prioritized to gain the most value. To efficiently prioritize, they must determine and measure the application security posture, define KPIs across the board, and have the ability to view the organization trends over time. In other words, at present, teams struggle to achieve application security posture management capabilities and maturity.
The shift of the organizations’ information security teams from the infrastructure posture to the application posture is well felt everywhere. The application environment is rapidly changing and lacks the proper tools, making it impossible to manage. AppSec teams need clarity as to what the application assets are, and where the full and updated posture can be obtained.
Maturity and adaptation of the posture management approach, enabling AppSec agility, is critical for any organization maintaining a modern application. Application security posture management mindset will undoubtedly be at the center of cybersecurity as an industry in the coming years. Without such change in AppSec management mindset the chaos can only grow, eventually resulting in a security incident. More and more security products with the same mindset will not prevail. We must map the correlations and gaps across the entire application — from controls and policies coverage to the secure development lifecycle, and bug bounty reports into a single unified posture.
Application security teams struggling to maintain their current gapped security posture, now have a unique chance of gaining ownership of the application security posture in their organization. Organizations are putting more effort into application security, but only if AppSec will be quick to adopt the posture management approach can they be sure they are moving in the right direction.