Threat Landscape for Microservices

As the global reliance on digital architecture keeps growing year by year, so does the need to properly secure it. By transitioning from the big monoliths from the past to a web of microservices, existing threats are expanded onto a larger attack surface, thus requiring to mitigate these threats. For practical purposes, a categorization of the threats can be made in the applications exposed, the networking to, from and in between these services and secrets and access requirements.

Application Level

Microservices provide each their own set of highly specific functionality, often decoupled via a message bus architecture or reachable trough internal API calls. Some services only provide their functionality to other microservices, whilst other endpoints are exposed to administrator or customers. To keep these functionalities secure in all these different use cases and access levels, various principles can be applied.

Isolation

When using microservices the need arises to think about isolation levels. Isolation should be regarded in the most broad definition. For example, client access need to be scoped properly to avoid data leaks. In addition, some service details need to be isolated. For example, you might want to hide some internal endpoints in your API specification for specific clients. Running services in containers is but a small part of isolation.

Isolating data and functionality to the end user is only one part of the equation. To reduce attack vectors, microservices may employ their own storage, databases and virtualized environment to contain breaches.

Authorization

In important aspect of distributed systems is to keep track of access levels each individual has and make sure to keep this up to date. Too much access can result in data leaks in the case of disgruntled (ex) employees or exposed account credentials.

The following common principles should be taken into account with regards to authorization:

• Entity authorization checks – Entity ownership should be verifiable trough the whole chain.
• Principle of least privilege – Users should receive the least access required in order to complete their specific use cases. In addition, this principle also applies to services. A mysql user for example, should not be able to perform unrelated operations on unrelated databases.
• Rate limiting – Prevent brute force attack vectors.
• Tracking and logging through the entire infrastructure – In microservices it is important to be able to track a request through the entire infrastructure. Invoking a service often results in messages traveling trough a message bus or resulting internal API calls on behalf of a user. These messages and their ownership should be tracked throughout the infrastructure (without logging private data).
• Short window of opportunity – In order to limit damage cyber attacks can cause it is good to limit the amount of time an adversary has available to mount these attacks. For example, limiting access tokens to only 5 minutes will cause significant hurdles for adversaries to exploit leaked access tokens.

Networking Level

On the networking level there are various threats which needs to be address and, luckily various ways to do so. The most common threats can be categorized by accidental exposure of admin services and denial of service threats.

Accidental Exposure of Admin Services

Another important threat is the accidental exposure of admin services. All it takes is a simple configuration error in your web service, or failing to set authentication to expose your infrastructure. To mitigate this, there are various solutions. Among those solutions, it is possible to keep administrative services on a separate (disjointed) network or strict firewall policies. It should be noted that this problem can also be solved on the application level by using an edge serve which whitelist publicly exposed endpoint. There will always be a trade-off between accessibility for employees and keeping them secured from the outside.

Denial of Service

Denial of service is an more complex problem in an microservice architecture than when compared in a more traditional monolith.

Denial of service is considered a threat since it disrupts any guaranteed service levels and can quickly bring the core business to a halt. Not only is there the threat of coordinated attacks, the use of microservices brings a new risk, cascading failures.

A cascading failure occurs when downstream service fail, and the queried service depends on those services. A failure in one component can quickly result in other services being down. Due to the distributed nature of microservices the amplification effect is also in scope. Imagine for example a database which services 10 different microservices. These are used by one or more other services which have multiple users. It’s not hard to see how failures can quickly cascade through the entire infrastructure.

Cascading failures can be avoided rather easily by introducing circuit breakers and decoupling where it makes sense. Using the message bus to decouple services provides you with great flexibility to handle these situations. It also allows you to scale up by adding more nodes with consumers. This principle of “low coupling, high cohesion” is the name of the game.

Secrets

A big part of security is the ability to keep secrets. Whether those are trade secrets, passphrases or keys. Secrets need to be known only and only by the applications and persons which should have access to the resources these secrets guard.

Secrets exists in various forms. These can be passwords, certificates, keys and even JWT tokens.

When secrets are improperly managed, it gives an adversary an platform to steal data or use the underlying resource as a way to leverage his hold on a system. In order for secrets to remain truly secret a few requirements must be met. The secret must be updated on various points of time. For example, a disgruntled ex-employee can use his or her
secrets to access systems he is not supposed too, even years later.

To counter this, you can rotate the password in the off-boarding process.

To summarize, if you’d like to keep secrets truly secret, you can use the following guidelines:

1. Rotate or renew secrets any time when a person or system is no longer allowed to access a resource or on a regular schedule;
2. Make sure a secret is not guessable;
3. Make sure a secret is revoke-able manually;
4. Never use the same secret for other resources;
5. Reduce the window of opportunity both in time and access level;
6. Multi factor authentication (something you know, something you possess, something you ‘are’ (bio-metrics));
7. Keeping secrets truly secret when they’re in transit, in memory, in versioning, during deployment.

Governance

Lots of security measures can be taken on a technological however, all systems are ultimately made to enhance human capability. Therefore it is not surprising that the human condition and all of its wonderful flaws, biases and capabilities are often the main cause for security incidents.

These human fallacies can be mitigated and prevent by keeping a good governance structure in place, where possible enforced with technology.

Various frameworks exists for this purpose, the most notable being the ISO/IEC 27001. At Speakup we are proud to be certified against this standard.

1. Organizational Acceptance Security entails putting up barriers for adverse whilst keeping it easy for employees to accomplish their tasks. If this is not balanced property people will come up with ingenious ways to make it easy for themselves at the expense of security.
2. Backups / Ransomware – Backup protocols only work when the restore procedure is known and is working. Due to the rise of ransomware threats, this is critically important. Backup and restore procedures should be part of any set of data and services.
3. Knowledge / Awareness – To react fast to threats, it is required to know what is going on, which services are live and how requests move trough the infrastructure. A compromised account, or suspicious activity should be ceased as soon as possible. In addition, the knowledge of how to use these monitoring systems and protocols should be duplicated
   among more than one employee.

A Few Parting Thoughts

Although the threat landscape is ever-expanding, the principles of securing IT infrastructure in the micoservice age do not change much. The tl;dr version of these principles can be summarized as the ‘cia triad’: Confidentiality, Integrity and Availability.

In this context, the take home bullet points are:

• Keep secrets secure;
• Authorization should be well defined and kept up to date;
• Systems should be isolated;
• Humans are often the weakest link. The most desirable actions should be the easiest to do.