Tag: Traceable

What Runtime Application Self-Protection (RASP) Doesn’t Solve

RASP, or Runtime Application Self-Protection, is a modern security technology that protects web applications from attacks during runtime. The technology is an important complement to defense systems that focus on the perimeter, but RASPs also have weaknesses that can introduce their own vulnerabilities.

What are RASP’s strengths and weaknesses in protecting against modern security threats? Are there better solutions that offer more in-depth insight into attacks as well as detect suspicious behavior?

A deeper dive into RASP

Gartner defines RASP as “a security technology that is built or linked into an application or application runtime environment and is capable of controlling application execution and detecting and preventing real-time attacks.” Many IT organizations already deploy them, often in conjunction with other security solutions.

An ideal RASP promises:

Deeper-rooted code-level visibility into applications
Passive and active incident response features such as monitoring/alerting and blocking modes
Configurable options to log, alert, challenge, or block malicious behaviors
Support for many languages and execution platforms
Autonomous operation without manual tuning
Coverage for a broad set of vulnerabilities, including OWASP top 10
Integration with secure software development lifecycle (SSDLC) and monitoring tools.

RASP fills the security gaps left by a perimeter defense model like Web Application Firewall (WAF), which protects both legacy and modern applications. Based on these promises, RASP may look like the necessary missing piece of your security stack. In practice, however, it has weaknesses. Let’s dive deep into RASP to understand its advantages and shortcomings.

RASP advantages

Watches rather than predicts

Similar to WAF, Runtime Application Self-Protection works by blocking malicious behavior but does so without extensive need for preset rules and tuning. Rather than building a trained model or predicting behavior, RASP watches the application at runtime to see that those actions are actually performed. For example, a request call to a database occurred, a shell command is executed, or that a file is opened.

DevOps-centric attack visibility with better SSDLC integration

RASP provides visibility into how an application is being attacked, providing better intel and alerting security personnel and developers to the exact vulnerable code. Developers can use this information to modify the codebase and eliminate security vulnerabilities. RASPs may also offer the option to integrate directly with the application development lifecycle to pinpoint vulnerable code based on attacks observed in the production environment.

No training required

An ideal RASP doesn’t need to be taught what bad behavior looks like. That’s because it is tied to the application stack, so knows what the application should and shouldn’t be doing. When the application’s behavior changes, it’s no problem for RASP to adapt because the security is based on the application and not on a set of predefined rules and educated guesses.

Provides time to fix vulnerabilities

Programmers are responsible for developing and releasing new applications and features, and subsequently developing updates and patches as vulnerabilities and bugs are discovered. It can take organizations months to apply patches which creates a window of opportunity for hackers. Because RASP protects against incoming attacks, it provides the engineering team time to fix vulnerabilities free from the pressure of working during a crisis. It is synonymous with WAFs’ virtual patching.

Cloud agnostic

The RASP protection design is rooted in modern software engineering techniques such as instrumentation, dynamic hooks, and secure SDKs. It works by implanting sensors in the existing application code to monitor and control critical execution points in real time. Utilizing these techniques, RASPs become part of the application, allowing them to remain protected independent of their deployment environment. RASPs may not require network calls and work in any deployment architecture, including on-premise, cloud, and containers.

RASP disadvantages

Confined context

Purely from a technical viewpoint, since RASP sits within the application framework, it may look to be a smarter alternative to perimeter defense solutions like WAF. Practically, however, no application is self-contained; they interact with a multitude of other services and components. Consider that each application module can be deployed in different endpoints, further limiting the RASP’s visibility and capabilities.

Use case abuse

We frequently hear about large companies breached with modern application attacks like Broken Object Level Authentication (BOLA). Attackers substitute their resource ID in the API call with a resource’s ID belonging to another user. The lack of proper authorization checks allows attackers to access the specified resource resulting in BOLA. Since the input remains consistent with what the application received before, RASP finds no reason to inspect and will let it pass through. Attackers can abuse similar use cases like Broken Function Level Authorization (BFLA) without RASP suspecting the intrusion. Protection for such attacks requires building broader business context from the application, which RASPs lack.

Normal API request by Robby to fetch his profile

BOLA Attack: Robby changes his user id in the
request and reaches Ava’s profile

<code>
REQUEST
===============
GET /customer/
12548
/profile
Host: shop.store
Cookie: session=
5015ee5d-6133-cab4874b
Accept: application/jsonRESPONSE
===============
HTTP/1.1 200 OKContent-Type: application/json{“id”:
12548

“fName”: “Robby”

“lName”: “Saxton”

“phone”: “202-555-0128”

“ssn”: “987-65-4325”

“address”: “3454 Crummit Lane,

Omaha, NE

68114”
}

</code>

<code>
REQUEST
===============
GET /customer/
12549
/profile
Host: shop.store
Cookie: session=
5015ee5d-6133-cab4874b
Accept: application/jsonRESPONSE
===============
HTTP/1.1 200 OKContent-Type: application/json{“id”:
12549

“fName”: “Ava”

“lName”: “Rose”

“phone”: “340-5556-577”

“ssn”: “449-26-2109”

“address”: “4702 Gordon

Street, Chino, CA

91710”
}

</code>

Missing distributed protection

Since RASP only has visibility for the current application context, additional application-level Distributed Denial of Service and Bot protections cannot be efficiently solved by RASP. A perimeter defense solution can completely isolate that traffic, absorb it, and take defensive action even before the attack hits the application stack.

Intrusive deployment

RASP requires an intrusive deployment model and is highly dependent on the platform and codebase used for the application to be beneficial. It has to be deployed along with the application in the application stack. Some organizations may not feel comfortable deploying RASP for critical services, thus needing to invest more in other security solutions that add cost and maintenance.

Deployment challenges

Conceptually, RASP can do more in-depth protection sitting within the application stack. But there are practical challenges in managing and updating a RASP component deployed at every endpoint. RASP adds additional performance overheads not just on the application execution but also on the dedicated effort required to deploy, tune, and monitor itself and the runtime environment. And to determine proper placement that protects all assets, RASPs may need you to gather internal information about the application and trace data flow.

Unintended consequences

Though RASP’s goals are noble, its deployment can create unintended consequences that produce pain points. For example, situations may require the rewriting of software execution at the last minute, introducing risk from a support/incident response perspective, particularly as applications are modularized and supported by distributed teams.

Performance degradation and impact on service level agreements

In today’s high-performing environments, where availability is expected to be at least four 9s, downtime could severely impact SLA’s, resulting in lost revenue and damage to the company brand. RASPs might impact the application functionality even in monitoring mode as they wrap over existing essential library functions. Since RASP does not learn the business context, it may predict that a perfectly valid use case is malicious. Allowing RASP to stop code running in production amid an attack may pave the way for an effective (and self-imposed) Denial of Service (DoS) engine.

Too much reliance

RASP should be considered as another layer of control, but human behavior can lead to too much reliance on RASP for application protection. This behavior can generate a pile of vulnerabilities that attackers can use in conjunction with other techniques to exploit the application. For in-house-developed proprietary libraries, RASP tools are still not substitutes. The Secure Software Development Lifecycle needs to be followed with other formal methods such as source code reviews and automated tools, like static application security testing and dynamic security application testing, to identify and remediate vulnerabilities in both the source code and the application.

You deserve better

RASP is not a plug-and-play technology; it requires a full cycle of validation with existing applications to ensure functionality and performance are not adversely affected. What RASP makes up for in some areas it lacks in others.

There is a need for a better solution in the application security world that can provide more in-depth insight into attacks as well as detect anomalous behavior. Traceable provides this hybrid approach by combining distributed tracing with intelligent analytics to build a complete picture of your microservices and protect them. Don’t just cover one part of your application; defend it all.
‍

If this sounds like a smart approach to detecting and treating modern security threats, then we should talk. View a demo of Traceable in action.

June 9, 2021

Security Risks With No-Code/Low-Code Tools

As the popularity of no-code and low-code tools grows, so, too, do security concerns

The demand for new applications is growing at a rapid rate. Many individuals and business units will not tolerate delays. As a result, citizen developers are stepping in, some of whom may be sanctioned by the company while essentially operating as shadow IT.

Common to both groups is that they increasingly are aided by the wide availability of no-code/low-code development tools and platforms on the market today. Such solutions abstract away many coding tasks, offering developers a visual studio or palette to create applications by dragging and dropping software components and smaller apps.

No-code/low-code tools offload tedious chores from professional developers, allowing them to work more efficiently. For those without that expertise, these tools enable people who have intimate knowledge of the business create their own applications and automate processes.

Development is not only faster but less structured. As such, these technologies in the hands of those not trained in security can introduce risk.

There are many ways citizen developers can expose a business to cyber risks. One common issue in many companies is that citizen developers (like their professional counterparts) do not want to reinvent the wheel. If they can find an existing or open source component to an application, they might freely use it when developing an application. For example, rather than hard coding a front-end mobile user interface for different platforms, they may just take existing ones and use them for their new applications. Similarly, if they want their application to perform real-time analytics, they could use an open source events stream engine. And if they want to create an interactive chatbot, they might use open source cognitive apps. The problem is that they select these no-code/low-code apps with very little vetting of the code components they’re using.

Another common issue is that a citizen developer might ignore built-in security features in a component that makes up their composite application. For example, they may choose not to password-protect a database to simplify its use. Or they may decide to forgo best practices and send data across public networks unencrypted.

There are many choices like these where attention to security is needed. Yet, most citizen developers do not even know to be on the lookout for potential security weaknesses.

Layering in Security Before, During and After Apps Are Created

Obviously, citizen developer applications must be tracked, vetted and fixed before potential vulnerabilities are exploited by attackers.

To do that, security needs to be integrated throughout an application’s life cycle. It is no longer enough to only test for vulnerabilities after an application is developed and let it operate unchecked forever. Additionally, security must be real-time instead of reactive. It must constantly examine the elements of an application as they operate and are modified.

Cobbling together components using no-code/low-code techniques introduces additional issues. While the individual components may be trusted, the use of several components together might expose data or provide a weakness that can be exploited. Additionally, a composite application that is secure today may no longer be so if a new vulnerability emerges for one of the software elements within the application.

What many organizations are finding is that they need to marry DevOps and security. Hence, the growing focus on DevSecOps in the industry. DevSecOps is increasingly necessary to find weaknesses and vulnerabilities in modern applications composed of loosely coupled components.

The constant refreshing, updating and replacement of applications dictate that security must be an integral part of the entire life cycle of an application. Again, another reason to bring security into the application life cycle, just as DevOps does for development and deployment.

And the complexity of applications built, even when using low-code/no-code methods, means security needs to be more sophisticated to understand hidden dependencies in today’s loosely coupled applications. Any security solution cannot be passive. Simple scanning for known vulnerabilities is not enough. A solution must understand the way components of a citizen developer application change over time and interact with one another.

The bottom line is that cybercrime protection must be implanted at the code level, and secure coding practices must be instituted, especially when citizen developers are driving application development.

June 7, 2021
Use the OWASP API Top 10 to Secure Your APIs
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:
1. Broken Object Level Authorization (BOLA)
2. Broken User Authentication
3. Excessive Data Exposure
4. Lack of Resources and Rate Limiting
5. Broken Function Level Authorization
6. Mass Assignment
7. Security Misconfiguration
8. Injection
9. Improper Assets Management
10. 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.

Let’s take a look at the differences between traditional web development and API development.

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.
June 2, 2021
Security Observability: Why Tracing?
Detecting a cyberattack can take more than 200 days. During this time, attackers might be exploiting your system while you are completely unaware. Cyberattacks can cost affected organizations as much as $13 million per year.

What if we could reduce the time to detect a cyberattack all the way down to zero? How much money could you save by detecting and stopping an attack while it is still happening?

And what if we could do even better than that? What if we could detect security vulnerabilities before an attack even occurred?

Security observability is critical to achieving these goals. Let’s take a look at what security observability means and how distributed tracing, which is one part of observability, can help to defend your business from cyber security threats.

What Is Security Observability?

Knowing what is happening inside software is the best way to learn how to defend it. Observability refers to the ability to see the state of a system at any time. It’s like opening up a watch and watching the gears turn.

Applications and services constructed using APIs and microservices have an advantage over other systems because you can more easily observe what’s happening inside of them. You add hooks to the APIs and microservices and use additional tools to collect the details.

This presents us with an opportunity to better secure applications and services against cyberattacks by allowing us to see exactly what is happening inside the system.

The Three Pillars of Observability

Three types of data are needed to make a system observable. These are commonly referred to as the “Three Pillars of Observability:

Logs: Raw data, recording every activity that happens in the system

Metrics: Aggregated performance metrics, such as CPU load and memory usage, collected as min, max, average, number of counts, and so on

Distributed traces: The complete path a request follows as it flows through the microservices

Data analysis/visualization tools (sometimes referred to as the “fourth” pillar).

Yes, that makes four, but this item isn’t data. The above data is too complex to digest directly, making these tools paramount to achieving observability.

Figure 1. Sending observability data from the microservices to their respective collectors.

The three pillars are shown in the diagram in Figure 1. Each microservice in the diagram contains additional code that sends logs, metrics, and traces to their respective collectors. These collectors gather the data, store it, filter it, and pass it forward to analysis and visualization tools that make the data usable by humans.

Traditional security tools, such as SIEMs, make use of logs and metrics to secure a company’s assets. However, these tools fall far short of protecting applications.

Limitations of Logs and Metrics for Protecting Apps

Logs and metrics begin to paint a picture of what is happening inside your APIs/microservices. But the picture is incomplete. Logs and metrics can help developers ensure that the system is working properly and they can help with solving problems during debugging. But they do not provide enough information to protect the system from cyber attacks.

Logs: Just the Facts

Every time a microservice is called or a request is generated, a message describing that activity is sent to the log collector.

Code Snippet 2. Example of a log message, indicating that Service A has received a GET request.

This message contains information about what has happened, but it is in a very raw form. You can think of a log as a fact. It doesn’t provide any real understanding of what happened in the system.

If this GET request was the first step in an attack, we can’t tell that from looking at the logs alone.

Metrics: Adding Insights – What Happened

Metrics are aggregated data collected from microservice activity. Metrics may include things like CPU usage, memory usage, execution time, number of calls or requests per unit of time, and so on. Each metric is associated with the microservice that recorded it.

Figure 2. Metrics example, showing the number of calls received for the Login service. What do the spikes reveal? Are they attacks, or are they normal user behavior?

Figure 2. shows activity over time for a login service. The login activity is usually uniform and consistent, but there are very large spikes that occur occasionally.

The spikes show that there are bursts of login attempts that are occurring occasionally on a system. They could indicate that a hacker is sending a brute force attack, attempting to guess usernames and passwords for administrators in the system. Or they could indicate a hacker is trying to overload the server with a Denial of Service (DoS) attack.

But these spikes might indicate normal user activity. Perhaps many users are running an app simultaneously because they just saw a compelling television commercial that was aired during the Super Bowl halftime. Or maybe everybody is contacting Uber to request a ride at the same time because a Rolling Stones concert just ended.

Another possibility is that these bursts of activity indicate a bug in the system. Maybe there is some sort of unforeseen infinite loop that is causing an unexpected burst of activity.

We just don’t know what is causing these bursts. To gain the insight we need to secure APIs, we need to know what happened before this metric was generated. We need the ability to work backward.

Distributed Tracing: Context and Causality – Why Things Happen

Distributed tracing can help us understand the reason things happen. When we know why things happen, we can determine if an attack is underway.

Figure3. A “span”, or trace, showing the path a request follows through the API/microservices system.

Distributed tracing is a form of tracing that is specially adapted to microservice architectures. It allows us to observe each request traveling through the system from its beginning to its end. We can use traces to improve performance and understand what typical behavior looks like.

But traces also give us the power to identify attacks on our microservices and stop them.

Traces show the entire path a request followed through the edge API and microservices. They can tell us:

If the request went through all of the required services, including authentication and authorization checks

If the request called any unexpected services or granted access to unauthorized data

Where the request entered the system. (If a request entered without going through an edge API, also known as an API gateway, there may be a problem)

The IP address that originated the request

And if they are working especially well, traces might even help identify an attacker.

Data Analysis and Visualization Tools: Seeing What Humans Can’t

In a real system, there may be hundreds of different paths requests can take, just like the one shown in figure 3. And each request could touch tens or even hundreds of services. While distributed tracing gives us the ability to observe all of these, the complexity makes it impossible for humans to gain much insight.

Machine learning and data visualization tools can identify patterns in the data, in order to identify normal behavior and abnormal behavior, and can even create alerts when abnormal behavior is detected.

These patterns of normal and abnormal behavior help us to identify security vulnerabilities and attacks within APIs and microservices.

Tracing to Reveal Vulnerabilities

The diagram in Figure 4 shows the combination of traces through a system. We can use this diagram to identify possible security vulnerabilities.

Figure 4. Possible security vulnerability, indicated by the red-colored trace. The diagram shows that this group of requests may inadvertently grant unauthorized access to the user’s account-info.

Figure 4 shows a pattern that contains an “Excessive Data Exposure” vulnerability, which is vulnerability #3 in the OWASP API Security Top 10. The pattern shows that when a user views a shopping cart, the API will also return the user’s account information. This unnecessary information may include personal information, account information, or financial information a hacker can exploit.

These insights help developers recognize potential security vulnerabilities and correct the code to eliminate them.

Tracing to Detect Attacks in Real-Time

Tracing can monitor each request and compare it to established norms. The system can generate an alert if a trace deviates from this expected behavior.

Figure 5. Possible attack in progress. The diagram shows that a possible attacker may have found a way to bypass a required authentication or authorization step.

Figure 5 illustrates a pattern that could indicate either a “Broken Object Level Authorization” attack or a “Broken User Authentication” attack, which are #1 and #2 in the OWASP API Security Top 10 vulnerabilities.

This figure indicates that an attacker has found a way to enter another user’s shopping cart and possibly obtain information for that user, by bypassing either an authorization or an authentication check.

Typically, tracing allows us to go back in time to find attacks such as the one above. Can tracing help to stop attacks in real-time?

Yes, tracing provides the information we need to detect and stop attacks in real-time. However, more is needed. A sophisticated AI on top of a tracing mechanism would be able to notice abnormalities humans may miss and can stop abnormal behavior before any damage is done.

Tracing plus AI gives us real-time security observability. In a future blog post, we’ll discuss how AI takes what tracing gives us and uses it to create real-time protection against attacks.

Use Distributed Tracing to Defend Your APIs

Cybercrime is expensive, and it can take a long time to detect an attack. Attackers are creative, and older techniques using logging and monitoring do not give enough insight to recognize an attack when it happens.

Security observability uses internal states to thoroughly comprehend what is happening inside your API/microservices system with the goal of protecting them from attack.

Observing your software, using logs, metrics, and most importantly, distributed traces gives you the opportunity to identify attack patterns, eliminate security vulnerabilities, and block attacks before they can cause serious damage. View a recorded Traceable demo to see for yourself.
May 11, 2021
Secure Kubernetes Architecture: Six Factors Essential to Success
Kubernetes has become the go-to container orchestration tool for businesses.

Check out these telling stats [source: Enterpriser’s Project]:

84% of companies are using containers in production.

Of those, 78% are using Kubernetes to manage their containers.

69% of companies have found security holes due to misconfiguration of their Kubernetes environment.

Your Kubernetes architecture is like a large house with container “tenants” living inside it. You’ll need to build it with care to make sure it’s a safe and happy place to live.

Here are six essential factors to get right when planning (or auditing) your Kubernetes architecture.

Setting the Foundation: Underlying Platform and Control Plane Configuration

The foundation of a house is a critical first step. A weak foundation leads to cracks over time.

Similarly, where you install Kubernetes is your first choice. There are several options available, each with pros and cons.

Kubernetes is a cloud-native tool. Therefore, it makes sense to install it on the cloud. There are two cloud deployment options: Infrastructure as a Service (IAAS) or Platform as a Service (PAAS).

An IAAS installation involves creating a series of virtual machines in the cloud (for instance, using Amazon EC2) and installing Kubernetes on those machines. You’ll be responsible for updates and configuration of the Kubernetes installation.

On the other hand, all major cloud providers offer managed Kubernetes services. This deployment model allows you to use Kubernetes without having to handle the infrastructure.

Even though Kubernetes was made for the cloud, you don’t have to install it in the cloud. An on-prem installation is an option, with many companies choosing to use their virtualization infrastructure to host Kubernetes.

You’ll find a quick summary of the pros and cons of each choice below.
‍

Your decision depends on three factors:

The skillset of your team

Your need for control and flexibility

Your company’s goals

Control Plane Configuration

The Kubernetes Control Plane consists of the services run on the Master node. The cluster store, scheduler, controller manager, and API server combine to create the control plane.

Plan your control plane security well. If an attacker gains access to your control plane, they’ll be able to control your entire Kubernetes cluster. Use SSH or a VPN / VPC to connect to and use the control plane.

If you’re using a managed service from a cloud provider, protect your API keys and credentials. Don’t ever store them in a source control system. Losing your API keys would lead to a complete takeover of your cloud infrastructure, not only your Kubernetes installation.

Finding Good Tenants: Container Security and Composition Analysis

The wrong tenants can destroy your house. Similarly, dangerous containers can bring down your Kubernetes environment.

Make sure any containers you bring in from the outside are vetted and configured correctly. Only use trusted registries, such as Docker Hub or Quay.io.

Finally, scan your containers before using them. You can use open-source container scanners to find vulnerabilities and malware. You can integrate most scanners into your CI/CD pipeline.

Plan Your Rooms Wisely: Kubernetes Cluster Partitioning

The rooms in your house each have a different name and purpose. You don’t keep a stove inside your bedroom or a bed in the kitchen. You give tenants private rooms while allowing them to share common areas, such as the kitchen.

In Kubernetes, namespaces allow you to separate various applications within the same cluster logically. If the cluster is your house, each namespace is a separate room within it.

Give namespaces to each application within your cluster. This practice produces three benefits:

Logically separates applications and environments (Development, Staging, Production)

Allows for robust Role-Based Access Control (RBAC)

Allows for network partitioning for added security within the cluster

Kubernetes RBAC Primer

You can check out the Kubernetes docs for comprehensive explanations of RBAC within Kubernetes. But here’s a quick primer for those who don’t have the time to read it now.

Kubernetes has Roles and ClusterRoles. They contain rules that represent a set of permissions. There are no “deny” rules, so you have to know what access is necessary.

Each Role is scoped to a specific namespace. ClusterRoles, on the other hand, have no namespace. In Kubernetes, an object can only be namespaced or not; it can’t be both. Therefore it’s necessary to have two resources, one for each scenario.

Use Roles to create permissions tied to a specific application. Use ClusterRoles for access to cluster-scoped resources or resources used by multiple namespaces.

RoleBinding and ClusterRoleBinding is the act of assigning permissions to a specific user. A RoleBinding grants permissions within a single namespace while a ClusterRoleBinding grants access cluster-wide.

For example, assigning the “pod-reader” Role to the user “jane” in the “default” namespace allows “jane” to read pods in the “default” namespace.

Roles define a set of permissions. Then users, groups, or service accounts (collectively called “subjects”) are assigned roles to grant access to specific resources within the cluster.

Define network partitioning and access control appropriate for the business’s needs before deploying any application into your cluster.

Watch Your Wiring: Inter-Pod Communications

Shoddy wiring is more than an inconvenience. It can lead to damaging fires or even destroy the entire house.

Similarly, poor inter-pod communications can bring your Kubernetes cluster grinding to a halt.

A Kubernetes environment is a small network ecosystem. The same network topologies, protocols, and policies govern pod-to-pod communication as those you’d find in any corporate network.

A full discussion of Kubernetes networking is beyond the scope of this article. You can read up on it using the Kubernetes networking documentation. But here are some quick pointers.

You can use Service Topology to define how traffic flows to and from a particular service. For example, a service can specify that traffic should be routed to endpoints on the same node as the client.

Service Topology is useful in the public cloud. You can use it to keep a service’s traffic in a particular availability zone or region to reduce latency.

Another useful networking tool is NetworkPolicies. These application-level constructs specify how a pod is allowed to communicate with other entities. This feature is especially useful when you want to control network traffic using IP addresses or ports.

Finally, you need to have a robust authentication and authorization strategy. We recommend using a service mesh to simplify load balancing, service discovery, encryption, and authentication. For example, service meshes include support for OAuth, which makes service authorization much easier to manage.

Secure the Front Door: Ingress Architecture

There’s no point in building a secure home and then leaving the front door unlocked. You don’t want to do that with your Kubernetes cluster either.

In Kubernetes, Ingress exposes HTTP and HTTPS routes from outside the cluster to your services within it. Ingress is your environment’s “front door.”

[source: Kubernetes docs]

Carefully consider which server to use in your Ingress architecture. NGINX is a tried and true web server with all of the security features necessary to protect your services. NGINX now offers an Ingress Controller for cloud-native Kubernetes environments.

However, you may want to give Envoy a look. It’s an open-source edge and service proxy built by Lyft specifically for cloud-native applications. It tackles the common observability and network debugging issues common in a microservice architecture. Envoy can also serve as a service mesh.

As the “front door” to your cluster, the choice of an Ingress server also impacts security. You can use it to terminate TLS connections from clients before they access your services. Be sure to include a key management strategy, including a Key Management Service or another secure vault.

Remember to follow the same security practices for your Kubernetes cluster as you do for any other part of your network infrastructure. Watch for OWASP Top 10 and OWASP API Top 10 vulnerabilities as well as logic-based threats.

(Hint: Traceable watches for common and logic-based vulnerabilities by learning the business logic of your microservice applications. Check it out for yourself here).

Finally, make sure your ingress plays nicely with mobile and IoT devices if you serve those clients.

Install Security Cameras: Secure and Monitor Microservice Communications

Video doorbells and security cameras are becoming commonplace. Homeowners want to know what is happening in and around their house.

Securing and monitoring within your Kubernetes cluster is equally critical. Make sure that microservice communications are protected, and you know what requests are being sent between services.

Consider point-to-point encryption between all microservices. And ensure real-time API monitoring for both REST and gRPC protocols.

Zero Trust principles not are becoming more popular as new technologies are appearing that support it. Zero Trust is an operating model where no traffic is trusted by default, inside or outside your network.

Within Kubernetes, implementing this model means verifying every request, client, or object trying to connect to your services. Nothing happens within your cluster unless the user or service account has proven that they have permission to act.

Zero Trust is essential to cloud-native security. At any moment, dozens or hundreds of services are trying to perform actions and share information. Zero Trust ensures that every request is validated and there are no holes due to the assumption that internal traffic is automatically safe.

Protect Your House

The world of microservices and cloud-native architecture unlock countless opportunities for businesses today. But new technologies also come with new dangers; new opportunities for malicious actors to steal sensitive information.

We’ve discussed six essential factors for securing your Kubernetes architecture:

1. Choosing the underlying platform and control plan configuration
2. Vetting and securing the containers running in your environment
3. Implementing cluster partitioning and access control
4. Defining inter-pod communications
5. Choosing your Ingress architecture (protecting your “front door”)
6. Securing and monitoring your microservice communications

With these factors in mind, what should your next steps be?

If you have an existing Kubernetes installation, use these factors as a mini-audit. Review your current policies and see how well they match up in these six areas.

If you’re planning your first Kubernetes installation, use these factors as a guide to making sure you cover all of your bases. Meet with implementers and make sure you have a plan for all of these factors.

Then your Kubernetes environment will be a happy home for your microservices.
May 11, 2021
Web Application Security is not API Security

Do you follow the same procedures to secure a web application as you do an API? Is there a difference between the two?

We’ve spoken about API security quite a bit in the past few months because we believe that there are critical differences between API security and traditional web application security. A lack of understanding of those differences is dangerous.

Let’s look at the differences between the two and why you should treat API security differently from application security in general.

What is API security?

API security is the practice of defending web APIs against attacks. Building APIs, typically with microservices as the foundation, has become a growing trend. Many mobile applications and websites send and retrieve data using APIs, even if the end user is unaware of this fact.

APIs are different from traditional web applications, and those differences can lead to critical security issues.

What Makes APIs Different From Traditional Web Applications?

I’ll answer that question with a picture, then proceed to “drop the mic.”

Here’s the entire Netflix architecture, comprised of about 700+ microservices. (Source)

(Picking the mic back up.)

The above picture illustrates why APIs are fundamentally different from traditional web applications. What was once one request to one server has become dozens or hundreds of requests to dozens or hundreds of microservices.

Previously, the work was relatively easy; defend one large application. Now, you have to protect hundreds of small web applications and the data they access. Authentication and authorization don’t look the same. The built-in session management of your favorite framework has gone out the window. Each microservice is its own little kingdom.

In addition, you now have to know where all of these API endpoints reside, what version they’re running, and how to scale them when demand increases.

Finally, changes to the development and deployment environment cause changes in how malicious actors attack applications. Are you familiar with the new ways attackers target APIs?

What Are the Most Significant Threats Against APIs?

The OWASP API Top 10 project outlines 10 dangerous risks with APIs. (See this post for the breakdown.)

Instead, let’s look at the big themes the API Top 10 brings to the forefront. Then we’ll discuss some specific breaches that illustrate what happens when APIs are vulnerable.

Authentication and Authorization Win Top Prize

Okay, maybe “Most Likely To Get You Hacked” isn’t much of an award, but authentication and authorization are the most prolific and dangerous API security flaws.

Authentication and authorization in APIs feel like a new world for many developers. A development framework doesn’t manage a session, but instead, applications pass JSON Web Tokens (JWT) around with claims attached. In a nutshell, every microservice must verify the caller’s identity and permissions before performing any work on their behalf.

As the number of APIs grows, it’s more likely that developers will miss some authorization checks, and a data breach is waiting to leap out and strike when you least expect it.

API Endpoints Are Everywhere

I remember taking my two-year-old daughter to Disney’s Magic Kingdom during spring break. I had to slip a kiddie leash on her to make sure she didn’t disappear in the crowd. It was challenging to keep track of only one child in that vast mass of people.

An explosion of microservices fills your infrastructure with a crowd of endpoints, and kid leashes don’t seem to fit Docker containers very well. It’s easy for APIs to disappear.

Unfortunately, these “shadow APIs,” whether spun up by a developer for testing purposes or just an old version left out in the wild, can become a point of attack. They may not be secure, and if you don’t know they’re still publicly exposed, someone could be attacking it without your knowledge.

Examples of Real API Vulnerabilities

Let’s illustrate the differences between API and web app security by looking at real vulnerabilities.

Shopify “Collaborator” Vulnerability

Security researcher Uzsunny found a critical flaw in the Shopify “collaborator” functionality that allowed an attacker to assign themselves the “collaborator” role on any store. This feature unlocks all sorts of administrative functionality.

It turns out that the API endpoint that handles this collaborator business logic didn’t verify that the request to add a collaborator to a store came from the store manager. Therefore, anyone could call that endpoint with the right arguments and get admin rights to any store on the Shopify platform.

Check out our detailed post on how this vulnerability works and why it’d be hard to detect.

Facebook Authentication Bypass Using Shadow APIs

Obscurity isn’t security, and determined attackers will find forgotten API hosts. The AppSecure cybersecurity research team found a way to gain access to any Facebook account via a couple of API endpoints Facebook forgot existed. The AppSecure team received a $15,000 bug bounty.

Although found in 2016, this bug illustrates a kind of vulnerability prevalent in API architectures. This bug was subtle but demonstrated how the smallest crack could let an attacker run amok.

The bug existed in Facebook’s password recovery logic. When a user requested to recover their account because of a forgotten password, they received a random six-digit code via text message. They enter the code in the browser, which sends an API call with the code.

Facebook placed rate-limiting on the endpoint to protect against brute-force attacks. The API blocked client requests after 10 failed attempts. However, API endpoints existed on other hosts, and Facebook’s engineers didn’t realize it. An attacker could send payloads to “beta.facebook.com” and “mbasic.beta.facebook.com” and brute force the recovery code. These endpoints didn’t have the ten try limit.

Check out our detailed post on this vulnerability for more on how modern app sec tools probably would’ve missed this vulnerability.

Uber API BOLA Vulnerability

Broken Object Level Authorization (BOLA) is number one on the API Top 10 list. Uber’s API had this vulnerability. Thankfully, it was discovered by security researchers before malicious actors did damage (as far as we know). But it illustrates well how dangerous BOLA can be.

The vulnerability leaked sensitive information, including an authentication token that could be used to perform a full account takeover.

The vulnerability appears when a new driver joins the Uber platform. The browser sends the “userUuid” to the API endpoint, and the API returns data about the driver used to populate the client.

Unfortunately, the API endpoint didn’t check if the calling client had the authorization to view its returned details. An attacker could add another “userUuid” and get a sizable JSON object with the other user’s account details, including first and last name, email address, and user identifiers.

This vulnerability illustrates that revealing too much information is dangerous for any API (Excessive Data Exposure is number three on the Top 10). Also, inadequate authorization checks can lead to account takeover with minimal effort.

Check out our detailed post to learn more about this vulnerability.

The Future of API Security

Application security technologies such as Web Application Firewall, Next Generation Web Application Firewall, and Runtime Application Self-Protection don’t typically find the kinds of vulnerabilities we’ve discussed. These attacks present as ordinary traffic, so many defenses let them through.

The future of API security lies with business logic. Application security tools have to understand the application’s context and business logic to know that non-managers shouldn’t be adding collaborators to a store or that a client shouldn’t access that user ID’s information.

Traceable AI uses machine learning to learn the application’s business logic, so these types of attacks are found and stopped. See Traceable AI in action and see what the future of API security looks like.

May 11, 2021
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.
May 11, 2021
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.
May 11, 2021