Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


10:00 AM
Connect Directly
E-Mail vvv

Microservices Flip App Security on Its Head

With faster application deployment comes increased security considerations.

Containers, microservices, and APIs work together as the pillar for modern application development. While the shift to microservices provides unparalleled adaptability, adopting the new framework comes at a cost: keeping each piece of the puzzle secure.

With DevOps, constant change is the reality. Because all services and APIs talk to one another over HTTP and new applications are cropping up online constantly, web application security must adapt.

The new microservices framework — the process of breaking down an application into a set of services — is a hot topic, with over half of the respondents in a December 2018 O'Reilly report saying that more than 50% of new development in their organization uses microservices. As a result, developers can create and deliver applications at a much faster rate, offering reduced business cycles from original idea to production. With a microservice approach, the need to more easily orchestrate microservice communication arose, so service mesh — a new infrastructure — was created.

The results are clear. The same O'Reilly report states that microservices have evolved from a fad to a trend, with the architecture being used in over half of software projects across North America, Europe, and Asia. More than 15% of respondents stated that they have seen "massive success" as a result of the framework. 

But with faster application deployment comes increased security considerations. Teams that deploy microservice architectures are already spread thin, and due to the framework's complex distributed design, teams now must defend against a larger volume of attacks because of the increased number of entry points. As organizations shift to microservices, their legacy web application firewalls (WAFs) can't keep up with the rise in microservices. However, new security tools are built to handle the evolving IT infrastructure.

For example, OFX, an international financial transfer platform based in Sydney, Australia, processes over $22 billion in transactions each year through its web application. (Note: OFX uses Signal Sciences to implement a WAF, a service also offered by other companies.) After migrating to a cloud-first microservices infrastructure, OFX sought to increase its visibility and protection against attacks documented by the Open Web Application Security Project (OWASP) and authentication abuse.

To maintain this workflow, OFX's partners need to seamlessly interact with the platform. They use APIs that connect to microservices within the OFX network; however, when interfacing with legacy WAF solutions, this can be a major challenge. OFX leveraged new technology and web application security solutions to provide transparency into authentication requests, therefore allowing a greater level of authentication defense and visibility for penetration testing.

Not all companies are keeping pace with microservices, though. Application security is one of the biggest gaps in microservice architecture overall. Because most microservices run over HTTP, security concerns include data injection attacks, cross-site scripting, and privilege escalation to command execution. These systems become vulnerable to business logic attacks, which, without effective monitoring practices, might not be detected.

Below are five things to consider when securing a microservice architecture:

· Ensure full coverage across the infrastructure: Breadth in coverage is essential in order to make sure web application defense can keep up with the changes that organizations face. Because applications on a microservice architecture have been decomposed into smaller services and components, the defense needs to be spread to those same delivery stacks. When you evaluate defensive tools, look for use in major cloud providers, container platforms, hardware and web servers, and platform services.

· Prevent account takeovers (ATOs): ATOs continue to be a major concern for organizations. A WAF with ATO capabilities to protect your microservices can protect against unauthorized account access.

· Gain insight into attacks: Microservices are often composed of dozens or even hundreds of individual services that can be running in different languages and in many containers. Granular attacks can be discovered at the microservices level, including where and how your microservices are being attacked.

· Choose a WAF that requires little tuning: A WAF can take a lot of time to get configured, set up, and running properly for each microservice. Choosing a WAF that blocks malicious attacks by default without interrupting your microservices or lengthy tuning periods will provide immediate coverage. Although you want a WAF to work right away, it should be flexible enough to customize to the specific needs of microservices.

· Think cross-deployment: There are several ways to install a WAF: on-premises, a module, a content delivery network, or as a Runtime Application Self Protection (RASP). The best protection is one that can be easily integrated into your DevOps workflow. This can be accomplished by either using a library integrated into your application, a module on the web server, or as a reverse proxy. This allows for the greatest adaptability to your microservices needs. With microservices, service meshes, API gateways, and more, it's best to use a firewall that offers the same protection, rules, and no-tuning required across all deployment models.

Knowing that dynamism is a fixture in DevOps, it's important to not fall behind. Microservices are not just a fad, so if you're not eyeing a change, it's time to get moving. To keep pace with business growth and increased workflow in an increasingly fast-moving space, businesses have to adapt. For now, adapting to a microservice architecture — and keeping it secure — is the way forward.

Related Content:

Jonathan DiVincenzo, Head of Product at Signal Sciences, the fastest growing web application security company in the world, brings his engineering background together with a passion for taking mere ideas and turning them into products. He has experience working in both large ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
4 Security Tips as the July 15 Tax-Day Extension Draws Near
Shane Buckley, President & Chief Operating Officer, Gigamon,  7/10/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...