At the present time, there is a remarkable trend for application modularization that splits the large hard-to-change monolith into a focused microservices cloud-native architecture. The monolith keeps much of the state in memory and replicates between the instances, which makes them hard to split and scale. Scaling up can be expensive and scaling out requires replicating the state and the entire application, rather than the parts that need to be replicated.

In comparison to microservices, which provide separation of the logic from the state, the separation enables the application to be broken apart into a number of smaller more manageable units, making them easier to scale. Therefore, a microservices environment consists of multiple services communicating with each other. All the communication between services is initiated and carried out with network calls, and services exposed via application programming interfaces (APIs). Each service comes with its own purpose that serves a unique business value.

Within a microservices deployment, one must assume that the perimeter is breachable.  Traditional security mechanisms only provide a layer of security for a limited number of threats. Such old-fashioned mechanisms are unable to capture the internal bad actors where most compromises occur. Therefore, it is recommended to deploy multiple security layers and employ zero trust as the framework. This way, the new perimeter and decision point will be at the microservice.

In this day and age, we must somehow enforce separation along with consistent policy between the services, while avoiding the perils of traditional tight coupling, and not jeopardize security. We need to find a solution so that the policy is managed centrally. However, at the same time, the policy should be enforced in a distributed fashion to ensure the workloads perform as designed and do not get compromised.

The cost of agility

The two main drivers for change are agility and scale. Within a microservices environment, each unit can scale independently, driving massively scalable application architectures. Yet, this type of scale was impossible when it was necessary to couple heavy data services along with the application.

The ability to scale and react rapidly increases business velocity, which allows organizations to reap the benefit in terms of cost and resilience and also improved ways of managing and building the application. However, the decentralized nature of agile deployments introduces challenges in terms of governance.

We should keep in mind that we now have a distributed organization with sub-teams responsible for individual microservices, In addition, the patching and updates are carried out in real time. Eventually, this creates a gap that needs to be filled. The gap consists of visibility and the ability to scale policy in a distributed fashion.

Complexity is the enemy of security

The cloud-native approach introduces considerable complexity. Besides complexity, the end user is responsible for securing their own environment. With microservices, there are many more moving pieces and paths of communication, introducing complexity that must be managed. We need to manage this complexity while keeping the holistic view of the application and visibility as to how each component is operating.

The attempt to secure a complex deployment using existing tools does not work and leads to a complicated security solution with complex policies. Complexity is the enemy of security. As security solutions become more complex, they become unmanageable and less secure. There is a requirement for a new unified security framework that can adapt to the different microservice environments while still providing full visibility along with simplified policy management.

You really need to know who is talking at any given point, authenticate the source, and authorize the type of transaction the API communication is trying to do. You should be aware of the specific communication, which is going on within these channels and what should be authenticated and authorized to communicate.

This is impossible to do efficiently unless changes are introduced to the microservices architecture. Microservice deployments are susceptible to an array of security threats. API vulnerabilities, logic attacks, lateral movements, and the inadequacy of traditional security tools bring the systems to a halt like a house of cards tumbling down.

Diverse traffic patterns

Today’s traffic patterns are different from those of the past. Nowadays, there are a lot of APIs connecting inbound and outbound along with internal communication. The APIs are all public, open and customer facing. The administrators are permitting this type of communication in and out of the public and private data center.

There is typically considerable asymmetry between the front-end ingress API and the backend APIs. Considering the customer environment, there is an initial consumer API call, but that propagates numerous other backend API calls to carry out, for example, user and route lookups.

As the microservice environment develops more components, it is difficult to monitor and make sure everything is secure. The deployment of web application firewalls (WAFs) to secure the public APIs and the use of next-gen firewalls filtering at strategic network points cover only a part of the attack surface. We must still assume that the perimeter is breachable along with the high potential for internal bad actors.

Traditional security mechanisms fall short

The network perimeter was born in a different time and traditional security mechanisms based on Internet Protocol (IP) and 5-tuple no longer suffice. The traditional perimeter consists of the virtual or physical appliance such as a firewall, IPS/IDS or API gateway located at strategic network points. Actually, the traditional perimeter with its traditional security mechanisms only provides the first layer of security. Even though it is labeled as defense in depth, still it is far from reaching that status in a microservices environment.

For example, API gateways are meant to manage the inbound calls. APIs are registered with the API gateway, which changes the workflow. They don’t scale in a microservices environment where there could be hundreds of services, each one exposing a number of API’s and each service containing multiple instances.

The API gateway needs to scale not just with the external traffic, but also with east to west internal traffic. This is the order of magnitude that holds the significant share of total traffic. Web application firewalls (WAFs) do not change the workflow but they share some of the challenges of API gateways. It is impossible to create and manage security when policies are not distributed to the workloads. There is a lot of work to be done for just a limited number of APIs that exponentially grow with internal communications. This is clearly not practical in case of microservices deployments.

Next-gen firewalls are typically the central security resource. They are more suitable for north to south traffic flows but not for internal east to west. In this world where everything is HTTP, firewalls do not offer the best visibility and access control. A firewall typically forces security on the source and destination IP and protocols, but in a microservices environment, the regular communication port is 80/443. It is very common for all to use the same port and protocol for communication.

For this to work, the firewall would need to follow the identity of the source and destination IP address along with the source and destination port numbers. It should have the ability to deal with an orchestration system, changing the identity all the time.

Enforcement should be done in a distributed fashion, right down at the workload level. If what you are monitoring and protecting is accessible to the application and application behavior, it matters less where the attacks come from. However, security frameworks based on traditional mechanisms can leave many avenues for bad actors to camouflage their attacks.

The larger attack surface requires a new perimeter

If the security cannot follow the microservices, you need to bring the security to the microservice and embed the security with the microservice. An effective perimeter is the decision point at the microservice that is not set at the strategic points located within the network. The new perimeter is at the microservice layer and everywhere that has an API. This is the only way to protect, especially when it comes to logic attacks.

Logic attacks become more prevalent in a microservices environment. This type of threat is carried out by a sophisticated attacker, not a script kiddy using a readily accessible tool. They take their time to penetrate into the perimeter to silently explore the internal environment and to go unnoticed while accessing valuable assets.

Cloud native applications expose their logic in multiple layers, not just one. Each microservice exposes some application logic through an API and these APIs if not efficiently secured, can be manipulated by a bad actor. A practical example would be an API that is meant to give you information about a single entry in a database. If the bad actor is able to modify the query slightly, they can pull multiple entries in the database that they do not have authority to access. Now, this can be exploited in every single API, which presents a much larger attack surface than before. This can bring about the opportunity for advanced persistent threat (APT).

As stated earlier, the distributed architectures give a much larger surface area. Each one of these small components is exposed to threats. The surface area is the sum of all APIs and the interactions both internal and external of the application. If you examine an API that is exposed to the outside, you would see hundreds of API calls. This offers numerous ways to exploit the vulnerabilities of an externally facing API. Within a kill-chain, the API is not just used to gain access but also as a way to perform lateral movements.

We also have challenges with traffic encryption. A large part of security in the new age of east to west traffic is the ability to have everything encrypted. It is the role of the application to perform the encryption.

In a microservices environment, key management is a difficult task. Besides, IPsec has a very coarse granularity. If you are looking for encryption with finer granularity in this environment then you need a new type of solution.

Solution components: identity

Workloads can be encapsulated in a number of ways such as a virtual machine (VM), bare metal or container. As a result, what’s required is a mechanism to provide a provable and secure identity to the application, not just to the server or container but also to the actual workload that is running. Ideally, identity can be a list of attributes. Think of them as the key-value pairs that describe an object to the level of detail that you want. Indeed, the more detail you have, the better.

The process of providing identity to a service is called identity bootstrapping. You have to trust something in order to provide application identity i.e. there needs to be an external source of truth. Companies such as AWS, VMware, and Octarine provide this by integrating with the orchestration system.

The orchestration system could be anything from vCenter to AWS ECS to Kubernetes. The system monitors events of new workloads being spawned. After validating the newly spawned workload, the workload is provided with the credentials it needs to prove its identity. After validating that it is legitimate, the newly spawned workload is provided with the credentials it needs to prove its identity. This way, the secrets are never kept in the code, container image, or in kubernetes.

Solution components: visibility

Once the identity is taken care of, we must create security based on the secured identity. How do you enforce policy and how does it get represented when you communicate it to something else?

Firstly, you need to rely on the application identity and monitoring traffic at layer 7. This is because on every API call the caller identifies oneself. You can add the identity on the client side and server side, validate the identity and log the API call to a central system.

The central system aggregates all API calls in all deployments for the customer’s environment and provides extensive visibility. This visibility extends over time to include the history of any changes. Such visibility is useful in agile environments.

Solution components: anomaly detection

You must try as much as possible to enforce the policy at the endpoint. However, sometimes in order to detect sophisticated attacks, you have to correlate multiple sequences, such as time of the day, payloads, and geographic access patterns.

Anomaly detection is needed that comprises a component responsible for looking at all the signals at a given time. Further, it should recognize small deviations from the baseline that could not be detected if you are looking at a single endpoint.

Solution components: policy

In the past, policy presented two prevailing themes – ACL distributed policy solutions and segmentation based on VLANs. You really need to start to think about policy being centrally administered but highly scalable and distributed by way of enforcement.

The policy should be based on workload identity and not network identity. With cloud-native, there is no alignment between the identity of a workload and its network identity. You cannot enable security enforcement through pre-defined network policies laid on traditional means.

The policy should also be driven by visibility, enabling feedback about policy and information about violations. This would allow the administrators to update the policy as required.

The promise of cloud-native applications and agile environments has many benefits for business. Cloud-native deployments left to the default lacks proper security tools and methodologies. However, with a guarded approach, you can reach a secure cloud-native agile environment.

The post Securing microservice environments in a hostile world appeared first on Artificial Intelligence.

Chaos engineering helps enterprises expect the unexpected and reasonably predict how microservices will perform in production. One education SaaS provider embraced the chaos for its microservices deployment, but it didn’t jump in blindly.

San Francisco-based Remind, which makes a communication tool for educators, school administrators, parents and students, faced a predictability problem with its SaaS offering built on microservices. While traffic is steady during most of the year, back-to-school season is extraordinarily busy, said Peter Hamilton, software engineer at Remind.

“We [were] the No. 1 app in the Apple App Store for two weeks,” he said.

Unforeseen microservices dependencies caused performance degradations and volatile traffic patterns in production. Remind determined that a microservices architecture on cloud resources was not enough alone to scale and maintain availability.

The post How a SaaS provider made microservices deployment safely chaotic appeared first on Artificial Intelligence.