devopsy.kinsta.cloud

Author: John Jeremiah

  • Modern AppSec and Supply Chain Attacks – Three Challenges

    Modern AppSec and Supply Chain Attacks – Three Challenges

    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.

    Supply Chain Attacks and API Security 

    In this specific case, the exploit targeted a traditional, legacy application as part of 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 where IT and security teams need to consider revisiting their application security practices and controls.

    Microservice Proliferation

    Inherent 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 to manage the proliferation of hundreds or thousands of new microservices, each with its unique code base and API calls, between services? On 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. One key question to ask is, will their rule-based approach adequately detect and prevent this kind of threat?

    Continuous Application Change

    Speed and rate of application improvements and enhancements have accelerated 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; organizations have gone from quarterly releases to weekly and even hourly changes – sometimes, even 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 and at too many internal points for a security leader to adequately 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 microservices 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 health and usage data with their vendor? 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 as well as monitoring it as it is running.

    Suggestions to Address API Security

    We’re still early in the cycle of the SolarWinds breach, and the aftermath will be extensive and expensive, as will the lessons learned as the damage is measured. However, one thing remains true. The threats continue to evolve, which means that security professionals (strike that) IT professionals (because 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 (software supply chain and zero-trust architecture) 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 in your software supply chain.
    2. Adopt a zero-trust approach to the 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 between your microservices.
    • Should microservice A be communicating with microservice B?
    • Is the data flow 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 visibility into your modern applications and your overall security posture, the best way to start is to view a quick recorded demo of Traceable.ai.

  • The Evolution to Cloud-Native Applications and APIs

    The Evolution to Cloud-Native Applications and APIs

    If you’ve spent any length of time in application development, you’re familiar with change. It’s the only constant.

    And along with how we build applications come changes in the techniques used to keep them secure.

    Securing modern applications requires more diligence than ever before. A review of how application development has changed over the past decade will explain why more diligence is necessary.

    Traditional Web Applications: Placing an Order From a Menu

    The traditional web application operates like ordering food from a menu at a restaurant. You have a list of dishes available, and you ask for one. The chef decides which ingredients are necessary and how the plate looks when it arrives.

    In a traditional web app, the client fetches a URL. Let’s say you want to see a dashboard of marketing metrics, and thus your browser retrieves example.com/dashboard.jsp. The client doesn’t control what’s on the dashboard; it just knows to ask for it.

    The web server processes the request in three steps:

    1. The web server pulls data from the database.
    2. The server builds an HTML page with the data placed inside.
    3. The server returns the rendered HTML page to the client.

    The web server decides what data goes into the dashboard and where the data goes. The client simply asks for a resource and displays what the server returns.

    In this model, the client typically has very little code. It requests a URL from the server and displays what comes back. All rendering and data processing happens on the server.

    Modern Web Applications: Buffet Style

    Modern web applications put the client in control. It’s more like a buffet than a sit-down restaurant.

    The client is often a Single-Page Application (SPA), or an application that dynamically updates the same page instead of always requesting a new one from the server.

    In a buffet, you take your plate and pick and choose the foods you want. Each dish can have multiple configurations based on your needs at the time.

    SPAs work like those plates. Instead of a single server creating an entire page and returning it to the client, the client knows how to make the page and asks only for the data required to do it.

    Typically, Application Programming Interfaces or APIs provide this data to the client. Business logic is exposed to clients using APIs that return only what the client needs. Maybe the client only wants the last 20 notifications for an account or the ten most recent emails.

    The use of APIs for business logic and data retrieval opens up the world of application development. You no longer need to build a web application. You can use a mobile application instead. You can use any technology or form factor to access the data, from mobile to Internet of Things (IoT) or other developers building applications of their own.

    JSON, a lightweight data format, is one of the most useful enabling technologies for modern applications. It allows all of the APIs, the client, and the database to store and transmit data using the same format. There are no data transformations necessary, which helps keep the application responsive.

    Going back to the above dashboard example, an SPA wouldn’t ask the server for the entire dashboard at once. Instead, it would ask the appropriate APIs for the specific data it needs to build the dashboard itself.

    The desire for APIs and ultimate flexibility and speed of development gave way to the development of microservices. These services are kept small on purpose to be updated independently of each other and more frequently.

    SPAs emphasize the client, leading to more complex code in the clients and the risk of security vulnerabilities in the clients (more on that later). But this change has opened up transformational technologies like IoT devices.

    From Monoliths to Microservices

    A common theme in the evolution of application development has been toward breaking functionality and features into smaller and more granular components.  Just as with the SPA example above, the functionality of the web page is in isolated components, the same trend is true when you look at overall application architecture in general.

    Where a legacy application might have been designed with separate modules and functions, each internally making calls to each other, modern design now breaks out separate functions into discrete services.   Now rather than each development team maintaining similar code/functionality inside their application, many business functions are separated into clearly defined services.  Consider an ‘address verification’ service which can be used by many other applications.  The functionality of validating an address is decoupled from the ‘customers’ that use the service, which introduces value into the delivery lifecycle. This approach enables development teams to focus on smaller, more granular changes and therefore shorten their cycle time and accelerate delivery.

    Microservices – a Response to the Accelerating Pace of Change

    Digital transformation and the rapid acceleration of  the pace of change within the industry dictates a new way of thinking. This thinking is encapsulated in the following quote by Bronwyn Clere, Executive Director for Capital Planning & Delivery, at Telstra Corporation in PMI’s Pulse of the Profession 2017 report:‍

    We are implementing features and products and using technology that were not invented 18 months ago. No longer can we afford these large monolithic programs that go on for two to three years. We know that what we set out to do at the beginning of that time is not what we will finish out doing. So, we are focusing on very rapid delivery cycles, asking ourselves: How do we mobilize a project very quickly? How do we use the right delivery techniques to work through it quickly? How do we get product into market or to customers or into the business?”‍

    Business leaders everywhere are demanding technology teams deliver faster. As a result, teams have adopted new ways of working and new ways of architecting their solutions.  We’ve seen widespread adoption of Agile, CI/CD,  and DevOps tools.  Similarly, application development and architectures have evolved to further enable velocity.

    A Tour of Cloud-native Architecture

    The increasing pace of change would put significant stress on any IT infrastructure. But cloud-native architecture has fundamentally changed how applications can be built and scaled.

    Cloud-native technologies, such as containers, service meshes, microservices, immutable infrastructure, and declarative APIs, empower developers to build and run scalable applications on public, private, and hybrid clouds.

    Cloud-native architecture focuses on creating loosely coupled services with high resiliency. Developers can make changes frequently without negatively impacting the entire system.

    Let’s take a quick tour of cloud-native applications so you can see how they differ from traditional web applications.

    The bulk of cloud-native applications include many microservices deployed in containers. Each service is isolated from the others and can be destroyed and recreated easily without affecting other services.

    Often an orchestration tool like Kubernetes is used to monitor all of the microservices used in an application. Orchestration is necessary when hundreds of services serve a single application. Kubernetes can detect malfunctioning containers or services, destroy them, and recreate new ones to keep the application running smoothly.

    Each service can be created and updated independently from all the others. Each service can use a different programming language altogether. As long as each service exposes a documented API, the language used behind the scenes doesn’t matter.

    Below is a diagram of Microsoft’s eShop on Containers open source application. It demonstrates what a real-world application looks like using cloud-native technologies.

    In this example, the development team building the Marketing microservice can make changes as often as they want without affecting the ordering or cart functionality. Different technologies can be used within each service and each service has a separate datastore. Flexibility and speed are the hallmarks of modern development.

    In the next post, we’ll dive deeper into specific challenges and considerations you need to take when adopting cloud-native applications.

    4 Necessary Mindset Shifts For Cloud-native Success

    The pace of change affects more than technology. Processes, management styles, and even ways of thinking have to adjust to make modern application development successful within your company.

    Delivery: Think Agile and Devops

    Because of the intensive need to shorten delivery cycles and to automate delivery, cloud-native architectures embrace delivery practices that support short and responsive turn around. Developers can deploy new code in seconds, with some companies pushing new code to production hundreds of times a day.

    As a result, your project management processes have to change. Agile practices (Scrum, Sprint, Lean, etc.) along with strong DevOps capabilities (i.e. trunk based development, CI,CD,etc) best support wide scale microservice development. It’s critical to get delivery, cultural, and organizational changes completed before trying to do cloud-native development at scale. The DevOps Handbook is an excellent resource for those new to DevOps development.

    Production: Think Products, not Projects

    The days of ‘throw it over the wall’ and let Operations manage the application are over.  Given the complexity of modern applications with multiple microservices and associated APIs,  development/product teams need to ‘own’ the application in production as much as they do in development.  In order to successfully scale your adoption of cloud-native applications, you need to explore and embrace “Product Management” over “Project Management” as a practice to manage the full lifecycle of your application.

    Think of your application as a long-term product that will change over time. Market insights and customer feedback will continue to improve it. It’s not a one-and-done exercise.

    Security: Think Security Everywhere

    Security is a major concern in this new environment.  The traditional approach of building a fortress of defensive walls and moats around the application and then you ‘trust’ the activity inside the fortress is insufficient in a world where the individual elements of the application are expected to communicate with other components.  On many levels, the new paradigm for security is one where each microservice, each component must have security built in, they need to embrace “zero trust” as a policy for how they operate.

    Trust No One – Zero Trust in Microservices

    Zero trust is a security architecture that lives by the motto: “Never trust, always verify.” It means verifying every request before returning data or performing an action.

    In a traditional network architecture, we protect the perimeters. Firewalls and DMZs only allow certain types of traffic into the network. We use VPNs to enable secure communication between company servers and remote workers.

    However, the biggest flaw with this security method is that traffic within the network is implicitly trusted. It’s similar to a bouncer protecting a nightclub from a long line of wannabe party-goers. It’s tough to get into the club, but once the bouncer lets you in, you can pretty much do whatever you want.

    In a zero-trust network, all traffic is considered suspect. Just because a request comes from within your environment doesn’t mean you can trust it. Check every request first before the service returns data.

    Microservice architecture requires a zero-trust architecture to be secure. It’ll ensure no requests fall through the cracks.

    Diligence, Compliance and Oversight of Cloud-native Applications

    In addition to zero trust as an approach to enabling microservices to operate securely, organizations must rethink how they monitor and manage their security posture.  We’ve covered several significant changes in web applications, especially in the last ten years.

    • Faster change than ever before
    • Small, independent services on different platforms
    • Autonomous teams
    • Cloud-native
    • More moving parts
    • More can fall through the cracks.

    New levels of diligence are required to secure this new breed of application. Cloud-native applications and microservices create new security vulnerabilities companies must account for to keep up with attacks.

    In the next post, we’ll cover what security measures need to be in place to protect cloud-native applications.