Modern Application Security and Supply Chain Attacks - 3 challenges

Supply Chain Attacks and API Security 

The recent news about the SolarWinds breach has focused on the difficulty and challenges a supply chain attack presents.   In the case of what Microsoft is calling “solorigate,” the attackers modified a dll deep inside a trusted application, which was then deployed into over 18,000 enterprises and government organizations, where it would then create a live back door for the attacker to exploit. The Microsoft Threat Intelligence Center (MSTIC) recently published details about how the SolarWinds attack worked and attempted to avoid detection.

In this specific case, the exploit targeted a traditional, legacy application as part of the SolarWinds Orion, an IT inventory management and monitoring application.  The attack was the result of extensive planning and resources, which appear to be the work of a state actor.  The immediate focus must be on mitigation of the current attack. Still, it is also essential to understand that supply chain attacks like this should be considered in the future as modern cloud-native applications become the norm. 

The evolution of cloud-native and modern applications where the functionality is decomposed into microservices, each running independently of each other, presents several new challenges for security and IT professionals to address. Specifically, the underlying application programming interfaces (APIs) introduce new attack surfaces where API security is paramount.  The OWASP API project has enumerated 10 critical API level threats that are substantially more important in the era of modern, cloud-native applications.     

These three trends, microservice proliferation, application change, and porous perimeters, create an environment where attacks can flourish and that IT and Security teams need to consider revisiting their application security practices and controls.

Microservice proliferation

Inherently in adopting a cloud-native architecture, one characteristic is the decomposition of the monolithic architecture into atomic services. Microservices enable business application teams to operate more efficiently and innovate. This approach also results in a compounding of the number of independent services, where each microservice is a potential source for the injection of a supply chain attack. In the case of microservices, rather than compromising an entire system, an attacker has more opportunities.

The challenge facing defenders is how do you manage the proliferation of hundreds or thousands of new microservices, each with its unique code base and API calls between services. On the one hand, traditional Web Application Firewalls (WAFs) can play a role, attempting to protect the edge, but on the other hand (WAFs) do not account for the underlying complexity of the web application and microservices. A question to ask is, will their rule-based approach adequately detect and prevent this kind of threat?

Continuous application change

Speed and rate of improvements and enhancements of applications as teams adopt DevOps practices of Continuous Delivery and Continuous Deployment.  Business expectations of faster delivery and reduced cycle time have naturally led IT teams to embrace and adopt DevOps practices of CI/CD, which when adopted, lead to significantly shorter cycle times between changes. The industry has seen remarkable improvements in delivery speed, where organizations have gone from quarterly releases to weekly and even hourly changes or faster. For example, A team at Goldman Sachs (releases every few minutes) and Netflix (releases thousands of times per day)
‍
In a traditional application, where new code is delivered lethargically, it might have been possible to keep up with the pace of change and mitigate security threats. However, in the age of microservices and cloud-native applications, it is unrealistic to maintain full awareness of the application’s state and associated microservices.  Change is happening too fast at too many internal points for a security leader to manage their risk profile. 

‍

Relatively porous perimeter

Because applications are no longer monolithic installations that reside behind a defense in depth fortress, they are much harder to protect. Indeed, the principles of zero trust are essential when designing and managing modern applications. The reality is that for every microservice (both internal and external), there is a library of interfaces that enable the microservice to communicate with each other (internally), with third-party service providers (externally), and with end-users through an established UI.  

Additionally, how many of your applications have a “call home” feature where they communicate with their vendor with health and usage data. While many vendors use this information to improve the quality of their service, it is also another potential threat vector to consider.

The Web Application Firewall and traditional approach to security provide only a degree of protection, as the nature of modern applications encourages the use of SaaS services, third-party services, and other resources in the interest of faster delivery. This complicates the challenge of delivering a secure application and also monitoring it as it is running.  

‍

Suggestions to address API Security

We’re still early in the Solarwinds breach, and the aftermath will be extensive and expensive, as will the lessons learned and the damage is measured. However, one thing remains true.  The threats continue to evolve, which means that security professionals (strike that) IT Professionals (security is everyone’s responsibility) need to renew our focus and commitment to delivering secure, reliable, and trustworthy applications. 

There is no perfect protection or 100% secure approach; instead, it is a question of how to establish layers of defense where each layer of security reduces the overall risk exposure. Ultimately, you want to have the ability to 

• Prevent the risks in the first place (SW Supply Chain and Zero Trust Architecture) and

And

• Detect and react to adversaries who may be attempting to exploit your systems
  

Specifically, here are several recommendations to improve your security posture and lower your exposure:

1. Invest in processes and tools to help validate your supply chain. A Trust but Verify approach is critical in the development stages. You should look at tools like Sonatype and others that can help reduce the risks of your software supply chain.
2. Adopt a zero-trust approach to your design and implementation of microservices. 
3. Maintain awareness and insight into the current state of your APIs and your present risks (too many organizations cannot keep up with the pace of DevOps change)
4. Augment your perimeter with processes and practices to have “Zero Trust but Verify” in production. You need to observe the behavior of EACH of your microservices AND detect anomalous behavior and between your microservices.

• Should Microservice A be communicating with Microservice B?   
• Is the data flowing between Microservice A and Microservice B typical?
• Are there suspicious behaviors or patterns that indicate anomalous behavior?

Traceable.ai helps you detect and react to threats to your cloud-native and modern applications where API security is now mission-critical. If you’re interested in learning more about how you can improve your visibility into your modern applications and your security overall posture, the best way to start is to view a quick recorded demo of Traceable.ai.