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
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
SOC 2s & Third-Party Assessments: How to Prevent Them from Being Used in a Data Breach Lawsuit
Beth Burgin Waller, Chair, Cybersecurity & Data Privacy Practice , Woods Rogers PLC,  12/5/2019
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-12-10
marc-q libwav through 2017-04-20 has a NULL pointer dereference in wav_content_read() at libwav.c.
PUBLISHED: 2019-12-09
IBM Watson Assistant for IBM Cloud Pak for Data 1.0.0 through 1.3.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session....
PUBLISHED: 2019-12-09
IBM Planning Analytics 2.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 168519.
PUBLISHED: 2019-12-09
IBM Planning Analytics 2.0 is vulnerable to malicious file upload in the My Account Portal. Attackers can make use of this weakness and upload malicious executable files into the system and it can be sent to victim for performing further attacks. IBM X-Force ID: 168523.
PUBLISHED: 2019-12-09
IBM DataPower Gateway throug 6.0.14 and 2018.4.1.0 through 2018.4.1.5 have a default administrator account that is enabled if the IPMI LAN channel is enabled. A remote attacker could use this account to gain unauthorised access to the BMC. IBM X-Force ID: 168883.