Endpoint

4/15/2016
02:30 PM
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

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
Comments
Newest First  |  Oldest First  |  Threaded View
PxMx
50%
50%
PxMx,
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
pzivic
50%
50%
pzivic,
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.

Pez

 
5 Reasons the Cybersecurity Labor Shortfall Won't End Soon
Steve Morgan, Founder & CEO, Cybersecurity Ventures,  12/11/2017
Oracle Product Rollout Underscores Need for Trust in the Cloud
Kelly Sheridan, Associate Editor, Dark Reading,  12/11/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Gee, these virtual reality goggles work great!!! 
Current Issue
The Year in Security: 2017
A look at the biggest news stories (so far) of 2017 that shaped the cybersecurity landscape -- from Russian hacking, ransomware's coming-out party, and voting machine vulnerabilities to the massive data breach of credit-monitoring firm Equifax.
Flash Poll
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
Enterprises are spending more of their IT budgets on cybersecurity technology. How do your organization's security plans and strategies compare to what others are doing? Here's an in-depth look.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.