The use of composable methodologies for application development is growing rapidly. The reason: It offers many benefits that speed the development process and opens up application creation to developers of all skill levels. However, the speed and ease-of-use benefits, via the reuse of pre-built components, can introduce new security risks that traditional security management solutions might not be able to handle.
The rising interest and adoption of composable architecture seems to be a matter of the right approach at the right time. Businesses today are under great pressure to innovate, transform, and offer new products and services. The pressure is coming from both inside organizations and from customers. Those within need applications, tools, and services to increase productivity, boost efficiencies, and cut costs. Customers want fast service, improved engagement, and quick responses to any queries and questions.
A composable approach to application development helps businesses deliver the needed solutions at the pace of modern business change. It accomplishes this by using composable entities that offer self-contained business capabilities. These elements make use of APIs and can be assembled and combined into larger applications.
Bolstered by other industry trends
Another reason for the popularity of composable application development is that it is a good match and complements other application development trends.
For example, its usefulness is enhanced by low-code/no-code development methods. Low-code/no-code saw great adoption during the pandemic. Businesses realized they needed to be more responsive to fast marketing changes, and their at-home workforce needed easy-to-use solutions.
The surge in their use continues this year. The low code development technologies market is projected to grow by 23% this year over last.
Many of the reasons companies cite for moving to low code are similar to why they use composable application architectures.
Namely, professional developers work faster, and they can spend more time on higher-level development problems. And both low code and composable methodologies let individuals and business groups with limited or no development expertise create their own powerful applications.
So, in many ways, the two technologies go hand-in-hand in many organizations.
Similarly, many of the underlying rationale and principles for using composability align with the other cloud-native methodologies. Specifically, with a cloud-native approach, applications are broken into loosely coupled microservices and container elements that are then assembled into a larger application. Specific elements in a cloud-native application, such as a front-end application or a business process, can be standardized and made available as a composable component in a cloud-native application.
What’s needed for security?
Enabling development using composable elements centers on APIs. Specifically, with respect to composability, Gartner notes that businesses “seeking to kick-start efforts to turn an organization into a composable business” should:
Enforce composable application design by ensuring application development teams use available external and internal API products
Educate teams about how to exploit existing applications and platforms for composability by using application APIs and low-code development and integration platforms.
Hence, security efforts must change from traditional approaches to ones that are more API-centric. Solutions must observe all user activity and API interactions, then act on unexpected user and API behaviors.
Solutions that address composable application security must offer infrastructure, services, and code-level threat analysis in a single platform to facilitate collaboration and expedite threat resolution to meet the needs of modern DevSecOps approaches to application development and security.
Such capabilities are critical given the complexity of modern cloud-native applications. In many cases, when creating applications with composable elements, hidden inter-dependencies can arise. Traditional security solutions often will not be able to detect such issues or trace the source of problems down to the composable element level.
Furthermore, while each element of an application may be secure, the interplay between the composable elements and the data exchanged between them can introduce risks that need a more API-centric solution which understands the greater application context.
The tools, languages, platforms, and methods used to build applications have changed drastically over the past decade. Application security practices have to change with them; otherwise, security professionals will be playing constant catch-up with attackers and cybercriminals.
What Is the OWASP API Top 10?
The increase of microservices and application programming interfaces (APIs) has given rise to a new set of threats against applications. The OWASP API Top 10 documents the risks associated with API development.
Here are the vulnerabilities highlighted in the most recent OWASP API Top 10:
Broken Object Level Authorization (BOLA)
Broken User Authentication
Excessive Data Exposure
Lack of Resources and Rate Limiting
Broken Function Level Authorization
Mass Assignment
Security Misconfiguration
Injection
Improper Assets Management
Insufficient Logging and Monitoring
Why Is the OWASP API Top 10 Necessary?
Large monoliths are giving way to small, nimble microservices. Kubernetes, containers, cloud-native architectures, and API gateways are the new hotness. This shift has also led to new threats.
Authentication and Authorization Look Completely Different
Three out of ten risks in the API Top 10, including the first two, deal with authentication and authorization issues. These critical security functions look differently with APIs than they do with more traditional web applications.
In a typical web app, the user logs in and the server grants a session cookie. The browser stores the cookie and passes it to the server with every request, removing the need to re-authenticate. All of the user’s permissions are tied to the session ID.
APIs are made of several mini web apps all deployed on separate servers, each with its own data store. Creating a session in one server doesn’t matter much. The server receiving the next request won’t know anything about the session stored at the first server.
This complexity gave rise to the OAuth and OpenID Connect specifications. These specs outline authentication (Open ID) and authorization (OAuth) for distributed systems. Using these techniques correctly helps to keep microservices and APIs safe.
But even though authentication and authorization have changed for APIs, another aspect of them introduces a new big player in API risks: business logic errors.
APIs Talk Too Much
Traditional web applications expose one endpoint, and one executable running on the server contains all business logic. An attacker will have a difficult time mapping out all of the internal business logic of an application. With so much trial and error, it’s easier to go after vulnerabilities based on inputs, such as XSS or SQL Injection.
On the other hand, breaking an application into microservices, each with its own API endpoint, by default exposes much of the business logic to the outside world. You can watch your browser’s connections to see the individual pieces of the application as a whole. And most of the time, the public interface reveals the essential parameters and unique identifiers of sensitive data objects.
BOLA is an excellent example of this phenomenon. BOLA occurs when an attacker changes the resource ID passed into an API to retrieve someone else’s records.
Imagine a medical application that holds sensitive documents. You can view your documents in PDF form. Since APIs are used to serve up your data, the client app passes an ID through the URL. You accidentally (because we know you’d never do this on purpose) transpose the numbers in the URL. All of a sudden, another person’s medical information stares back at you. You’ve discovered a BOLA vulnerability.
Another example of APIs talking too much is with claims-based authentication. Typically, JSON web tokens (JWT, pronounced “jawt”) are used to send the current user’s permissions, referred to as “claims.” These tokens are easily decoded and updated.
Imagine receiving a JWT using OAuth and decoding it. You notice that one of the attributes on the token is “admin: false.” Now you know how the application determines your permissions. You change the attribute to “admin: true” and send it back to the application with the next request. If the API doesn’t follow the correct token signing and verification procedures, you’ve now become an administrator and can gain access to all sorts of goodies.
Make sure your APIs aren’t leaking too much information. Be aware of what your API’s clients see and determine the risks and mitigation of each piece of data.
“Loose lips sink ships” was a famous security warning during World War II. In today’s world, loose data sinks APIs.
Microservices and APIs Are (Too) Easy to Create and Deploy
New development methodologies come with cultural changes within organizations. Developer autonomy and delivery speed are emphasized, leading to many development teams deciding how to implement APIs and when and where to deploy them.
These methods lead to greater flexibility, agility, and scalability but could also create API proliferation and increased risk. Number nine on the API Top 10 is Improper Assets Management. Not knowing where all of your APIs are and what they do can lead to serious application vulnerabilities.
For example, in creating and deploying a new version of an API, an endpoint running the old version could still exist. Should the old version contain a security vulnerability, attackers could exploit it without your knowledge. Building an inventory using API discovery techniques allows organizations to find these endpoints and shut them down properly.
Businesses need to be agile and responsive. But they must also be aware of the side effects these strategies create and design processes to keep things under control.
If You’re Building APIs, Don’t Forget the API Top 10
Building microservices and APIs is distinct from building traditional web applications. Differences in environments, frameworks, and development techniques solve some problems while introducing new ones.
Get familiar with the OWASP API Top 10 and use it to check your applications. Add it to the regular security checkpoints you already have. Then you’ll be confident your APIs are safe and secure.
Traceable Defense AI helps protect against the OWASP API Top 10. View a recorded demo to see it in action.
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:
The web server pulls data from the database.
The server builds an HTML page with the data placed inside.
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.
