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.


02:30 PM
Connect Directly
E-Mail vvv

Rethinking Application Security With Microservices Architectures

The advantages offered by the container model go against many of the assumptions of traditional security mechanisms. Here are 5 new concepts & 4 best practices you'll need to understand.

Microservices architectures and container-based deployments are all the rage among application developers today. Microservices functionally break down larger applications into smaller, discrete services, and containers are viewed as a natural compute platform for microservices architectures.

Each service can be represented by multiple containers in a microservices cluster. Each service is purpose-built to provide a set of functions, and services interact to make up the entire application. It isn’t unusual for a mid- to large application to have between ten to twenty services. The net effect of all this decomposition is that the physical characteristics of these applications are dramatically different from their multi-tier cousins. Microservices application architectures require a rethinking of security assumptions and practices. Understanding the common attributes of container-based, microservices applications is a necessary step to securing them.

Here are 9 key concepts and best practices you’ll need to understand.

Concept 1: “Endpoint” Proliferation

The functional decomposition of traditional applications results in a significant number of microservices instances. From a networking standpoint, each service instance is still a unique network endpoint. While the attack surface for the application is no longer concentrated in a few isolated servers, it increases simply due to the spread of services. A lot more ports are now open, more APIs are exposed, and authentication just became a distributed issue as well.

Concept 2: Ephemeral IPs and Indefinable Perimeters

Containers can be spun up or down anywhere in matter of seconds and the traditional notion of the perimeter is fading away. Moreover, with dynamic addressing and scaling of services, it is no longer feasible to statically configure IP addresses or steer traffic to traditional perimeter security appliances. Many network constructs to isolate applications, including zoning and VLAN setups, are restrictive or not viable for many implementations.

Concept 3: Entropy and Container Masquerading

The very advantages offered by the container model go against assumptions made by traditional security mechanisms. Containers increase the entropy of the underlying compute infrastructure because they can be dynamically orchestrated across services or even across multiple clouds. Another challenge is that a container’s IP address may be invisible outside the host where it is run. For example, the default mode of a Docker container uses masquerading or natting, making Docker containers on a host invisible to the outside world. In these cases, configuring security in an external appliance becomes impossible since the traffic sources cannot be identified.

Concept 4: Service Discovery and East-West Chattiness

Microservices and container environments have empowered developers with the ease and power to deploy new services as well as service instances dynamically, but it complicates security policy definition since administrators don’t know which services exist or the rules governing their interactions. In addition, the proliferation of services inside the data center or cloud means that more transactions require inter-service interactions to be fulfilled. Depending on the application, a seemingly simple North-South request can translate into hundreds of East-West transactions to fulfill.

Concept 5: CICD Practices

DevOps principles and continuous delivery goals are promising concepts for lines of business but they also mean more frequent builds that production teams have to deploy and each application iteration can mean potential security issues. Organizational processes and tooling for security are still evolving to match development agility.

Gain insight into the latest threats and emerging best practices for managing them. Attend the Security Track at Interop Las Vegas, May 2-6. Register now!


 Security Best Practices for Microservices

Security will clearly play an important part in the decision to adopt and deploy microservices applications for production use. According to the research note, 2016 Software Defined Infrastructure Outlook by 451 Research, nearly 45% of enterprises have either already implemented or plan to roll out container-based applications over the next 12 months. As DevOps practices gain a foothold in enterprises and container applications become more prevalent, security administrators need to arm themselves with the know-how to secure applications. Start with these four best practices for securing microservices applications:

Best Practice 1: Discover and monitor inter-service communications

Security administrators often do not know the permitted interactions between the different services in a microservices application. Yet, when applications need to be secured, administrators need to configure security policies that govern the interactions based on an application deployment guide or other less formal instructions from developers. Rules can also change as applications evolve and new services are brought online.

One way to mitigate this challenge is to observe or visualize inter-service traffic as a way to establish the baseline for policies by understanding application behavior. Service discovery enables automatic identification of new services to others entities in the application. Use these capabilities to arm both developers and administrators with information about real-time service interactions and performance. It will also help security teams notice anomalous communication patterns or even identify potential breaches.

Best Practice 2: Segment and isolate applications and services

Micro-segmentation is policy-governed walling of applications through granular security enforcement. Micro-segmentation can be relatively coarse-grained, for example, to isolate the production environment from the development environment, or more granular, for example, to govern interactions between the catalog service and the order management service in an e-commerce application. For segmentation to work in microservices applications, enforce policies at the cluster level on every host running service instances, since traffic steering to perimeter-based enforcement points is not practical.

Best Practice 3: Encrypt data in transit and at rest

Encrypt traffic between applications or services that make up an application to meet compliance requirements and to improve security especially when the traffic crosses public networks. Keep certificates up-to-date, manage software versions, and fix known SSL issues. Invest in tools that can help manage and distribute keys, and keep them up-to-date while also addressing the issues of resource-scaling so that encryption doesn’t affect performance.

Best Practice 4: Automate policy management and configuration

Complex administrative functions across disparate systems and repetitive tasks can often lead to human error. The single most avoidable, yet common source of security incidents, continues to be human error due to misconfigurations, or missed updates. Automating tasks such as defining policies that can be replicated across applications, separating administrative vs. development roles, and managing SSL certificates and keys, can go a long way towards reduce these errors. Likewise, automating the deployment, management, and maintenance of the entire stack will go a long way towards improving the overall security posture in dynamic environments.

Related Content:

Ranga is CTO and cofounder at Avi Networks and has been an architect and developer of several high-performance distributed operating systems, as well as networking and storage data center products. Before his current role as CTO, he was the Senior Director at Cisco's Data ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
5/4/2016 | 8:47:35 AM
Visibility is key
This is a good overview of AppSec in the microservicse space. The visibility aspect of Best Practice 1 is crticial, you can't discover or monitor without it. The challenge is how do you acheive that visibility? With dynamically changing infrastructure getting the visibility can be an expensive engineering effort. Also, there are real challenges with monitoring from a network perspective since TLS prevents visibility into application traffic. And network based appliance solutions don't scale easily with infrastructure that needs to be able to scale. Finally, security teams don't scale either, the visiblity needs to be put in the hands of DevOps and developers in addition to security teams. I think finding the answers to these challenges will bring about application security success in a microservices world.

There is a good blog post by a colleague of mine on the topic of microservices that you might find interesting here: https://labs.signalsciences.com/why-services-are-eating-the-universe-632101d50a0e
User Rank: Apprentice
4/16/2016 | 10:51:06 AM
Security addition to best practices
These four best practices are good but they are more tuned around application delivery. Se here are my suggestions on adding security to these best practices:

Best Prctice 1. Identify, monitor and protect inter-service communications

Best Practice 2. Segment, isolate and protect applications and services

Best Practice 3. Encrypt data in transit and at rest and decrypt at the point of control to protect against APT

Best Practice 4. Autmate security policy management and security controls configuration

The text can be adjusted accordingly.


Stop Defending Everything
Kevin Kurzawa, Senior Information Security Auditor,  2/12/2020
Small Business Security: 5 Tips on How and Where to Start
Mike Puglia, Chief Strategy Officer at Kaseya,  2/13/2020
Architectural Analysis IDs 78 Specific Risks in Machine-Learning Systems
Jai Vijayan, Contributing Writer,  2/13/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-02-17
Mitsubishi Electric MELSEC C Controller Module and MELIPC Series MI5000 MELSEC-Q Series C Controller Module(Q24DHCCPU-V, Q24DHCCPU-VG User Ethernet port (CH1, CH2): First 5 digits of serial number 21121 or before), MELSEC iQ-R Series C Controller Module / C Intelligent Function Module(R12CCPU-V Ethe...
PUBLISHED: 2020-02-17
Unquoted service executable path in DXL Broker in McAfee Data eXchange Layer (DXL) Framework 6.0.0 and earlier allows local users to cause a denial of service and malicious file execution via carefully crafted and named executable files.
PUBLISHED: 2020-02-17
Iteris Vantage Velocity Field Unit 2.3.1 and 2.4.2 devices have world-writable permissions for the /root/cleardata.pl (executed as root by crond) and /root/loadperl.sh (executed as root at boot time) scripts.
PUBLISHED: 2020-02-17
Iteris Vantage Velocity Field Unit 2.4.2 devices have multiple stored XSS issues in all parameters of the Start Data Viewer feature of the /cgi-bin/loaddata.py script.
PUBLISHED: 2020-02-17
ELTEX NTP-RG-1402G 1v10 devices allow OS command injection via the PING field of the resource ping.cmd. The NTP-2 device is also affected.