Aspen Mesh proud to sponsor IstioCon 2022

Presentations on Istio Security, Dual Stack Support & TLS Orig. at IstioCon 2022

Virtual IstioCon starts Monday, April 25th. It's the biggest gathering of the Istio community and a great place to learn and share ideas. Aspen Mesh is a longtime Istio open source contributor--we are a top five Istio Contributor of Pull Requests. We are proud to sponsor IstioCon 2022 for the third year.

We're excited three members of the Aspen Mesh team are presenters this year.

Aspen Mesh presentations at IstioCon 2022

Tuesday, April 26, 10:30-10:40 a.m. EST - A Beginner's Guide to Following Istio's Security Best Practices, Jacob Delgado, Senior Software Engineer
Following the Istio Security Best Practices page is a daunting task for newcomers to Istio. Even experienced operators have difficulty discerning where to begin. In this talk I will present an easy way for beginners to adopt Istio and settings/configuration I recommend based on my experience.  

Tuesday, April 26, 11 a.m. EST - Istio Upgrades, Jacob Delgado, Senior Software Engineer & Sam Naser, Software Engineer at Google
Are upgrades getting easier? How easy is easy enough? Are helm and revision based upgrades catching on? What is still painful? How often do you upgrade? How often would you like to? Are patches easier than minor upgrades?

Wednesday, April 27, 10:40-10:50 a.m. EST - TLS Origination Best Practices, Kenan O'Neal, Software Engineer
Quick dive for beginners on TLS origination to improve security. This talk will focus on settings that may not be expected for new users with a focus on validating settings. I will touch on what settings Istio uses by default and how to configure Destination Rules to correctly check certificates.  

Thursday, April 28, 10:50-11:00 a.m. EST - Dual Stack Cluster Setup, Josh Tischer, Lead DevOps Engineer
Dual Stack support is very limited in today’s cloud ecosystem. Learn how to run/test Istio on a Dual Stack cluster in AWS on both OpenShift 4.8+ and KubeAdmin. OpenShift 4.7+ is one of the few options that officially support Dual Stack mode for bare metal clusters and Azure. I am excited to share Aspen Mesh’s experience and empower your team with another option for Dual Stack support. 

You can explore the full list of IstioCon sessions here and be sure to register for IstioCon today

About Aspen Mesh
Enterprise-class Istio service mesh is all we do at Aspen Mesh by F5. We offer Professional Services and 24/7 Support plans to ensure you have OS Istio experts available when you need them. 

Explore our Service Mesh Knowledge Hub for the latest resources on how OS Istio drives performance from your microservices architecture. Deep dive white paper topics include: Multi-cluster deployment to enable hybrid and multi-cloud architectures, security, mTLS, compliance and more.  


mTLS Authentication for Microservices Security is Critical to Digital Transformation

For an enterprise, mentions of “Cloud Native” and “Digital Transformation” are two ways of saying that a service mesh deployment is on the cards. Once deployed, the service mesh forms the backbone of business operations and is usually paramount to business continuity. As an enterprise starts to implement its Digital Transformation plan and migrates from a monolithic application environment to a cloud native application environment, security becomes an immediate concern. From a business operations and revenue generation perspective, it is important to understand the benefits and deployment pitfalls of mTLS to ensure business-as-normal operation. 

Here are some common issues we run into all the time

  • Loss of Regulatory Compliance: Several industries such as healthcare and financial services require compliance with mandated specifications, with many other industries complying with agreed best practices. If compliance is lost, then business operations may be affected if regulatory compliance is lost. A solution to this headache is to enforce mutual TLS STRICT mode as default. This will help to regain regulatory compliance by ensuring end-to-end security for all devices and services
  • Loss of Brand Reputation: Customer or internal proprietary information may be made public via exposure from a security breach. Customers may choose to do business with a more secure supplier consequently. A customer or supplier is unlikely to look favorably upon their chosen supplier or vendor if highlighted on the evening news for example. By enabling mutual TLS GLOBAL setting as default will help to protect your reputation by securing customer and proprietary information. 
  • Loss of Business Agility: With dynamic cloud-based applications, upgrades to business logic, services and offerings can seem endless. Frequent security enhancements are also essential. Upgrades come with their own headaches and can slow a business from rolling out new services due to various glitches. It’s best not to rely solely on perimeter defenses, regain agility by securing critical core applications and services with end-to-end security. 
  • Loss of Business Confidence: The service mesh enables many end-users. If one supplier or service has a loss of confidence in the integrity of the service mesh, this can affect everyone -- and other services. The ability to visualize service communication can help to restore confidence by reducing misconfigurations and simplifying troubleshooting. 

 

In our experience at Aspen Mesh, deploying mutual TLS has many benefits, but is easy to misconfigure – which can lead to severe disruptions to business continuity when deploying new microservices or upgrading a service mesh. Download our new white paper, Istio mTLS: 8 Ways to Ensure End-to-End Security, to learn about several more mutual TLS concerns that could spell disaster for your business! 

 

- Andy 


Recent security vulnerabilities require Zero-Trust Security tactics for your microservices environment

Despite significant technological advancements, security is still hard. A single phishing email, missed patch, or misconfiguration can let the bad guys in to wreak havoc or steal data. For companies moving to the cloud and the cloud-native architecture of microservices and containerized applications, it’s even harder. Now, in addition to the perimeter and the network itself, the myriad connections between microservice containers must also be protected. 

With microservices, the surface area of your network vulnerable to attack increases exponentially, putting data at greater risk. Moreover, network-related problems like access control, load balancing, and monitoring that had to be solved only once for a monolithic application now must be solved separately for each service within a cluster, as well as between clusters. 

Zero Trust Security Methodology and Networking Principles

Zero-Trust dates to the 1990’s as a method for “Perimeter-less” security. The main concept behind the methodology is “never trust, always verify” even if the network was previously verified.

  • Networks should always be considered hostile 
  • Network locality is not sufficient for deciding trust in a network 
  • Every device, user, and request should be authenticated and authorized 
  • Network policies must be dynamic and calculated from as many sources of data as possible
     

Today, it’s essential to apply a Zero-Trust approach to network security and to service mesh technology. In our white paper just completed, Zero-Trust Security for your Microservices Architecture, we outline what it takes to implement the key tenets of Zero-Trust security using a service mesh to secure a microservices environment. In the paper we provide the steps to mitigate cyberattacks to protect containerized applications. 

What's covered in our white paper, Zero-Trust Security for your Microservices Architecture:
  1. Zero-Trust authentication methodology for a service mesh
  2. mTLS encryption: Achieve non-repudiation for requests without requiring any changes or support from the applications. Identity, certificates, and authorization to ensure “every device, user, and request is authenticated and authorized” -- a Zero Trust principle
  3. Learn the built-in methods Istio uses to combat security vulnerabilities
  4. Ingress and Egress security control within a service mesh


Lastly, in the paper we touch on Aspen Mesh’s approach to Zero-Trust security, including how we configure mTLS, secure ingress, monitor egress, prevent RBAC (Role Based Access Control) misconfigurations and apply policy and configuration best practices.

Aspen Mesh has deep expertise in Istio and understands how to get the most out of it - our Services and 24/7 Service Mesh Support are unmatched in the industry.

- Andy


top 5 istio contributors graphic

Aspen Mesh Leads the Way for a Secure Open Source Istio

Here at Aspen Mesh, we entrenched ourselves in the Istio project not long after its start. Recognizing Istio's potential early on, we committed to building our entire company with Istio at its core. From the early days of the project, Aspen Mesh took an active role in Istio -- we've been part of the community since Fall of 2017. Among our many firsts, Aspen Mesh was the first non-founding company to have someone on the Technical Oversight Committee (TOC) and have a release manager role when we helped manage the release of Istio v1.6 in 2020.

Ensuring open source Istio continues to set the standard as the foundation for a secure enterprise-class service mesh is important to us. In fact, we helped create the PSWG in collaboration with other community leaders to ensure Istio remains a secure project with well-defined practices around responsible early disclosures and incident management.

Jacob Delgado of Aspen Mesh has been a tremendous contributor to Istio's security and he currently leads the Product Security Working Group.

Aspen Mesh leads contribution to Open Source Istio

The efforts of Aspen 'Meshers' can be seen across Istio's architecture today, and we add features to open source Istio regularly. Some of the major features we've added include Elliptic Curve Cryptography (ECC) support, Configuration validation (istio-vet -> Istio analyzers), custom tracing tags, and Help v3 support. Aspen Mesh is a Top 5 Istio Contributor of Pull Requests (PRs). One of our primary areas of focus is helping to shape and harden Istio's security. We have responsibly reported several critical CVEs and addressed them as part of PSWG like the Authentication Policy Bypass CVE. You can read more about how security releases and 0-day critical CVE patches are handled in Istio in this blog authored by Jacob.

Istio Security Assessment Report findings announced in 2021

The success of the Istio project and its critical use enforcing key security policies in infrastructure across a wide swath of industries was the impetus for a comprehensive security assessment that began in 2020. In order to determine whether there were any security issues in the Istio code base, a third-party security assessment of the Istio project was conducted last year that enlisted the NCC Group and sought collaboration with subject matter experts across the community.

This in-depth assessment focused on Istio’s architecture as a whole, looking at security related issues with a focus on key components like istiod (Pilot), Ingress/Egress gateways, and Istio’s overall Envoy usage as its data plane proxy for Istio version 1.6.5. Since the report, the Product Security Working Group has issued several security releases as new vulnerabilities were disclosed, along with fixes to address concerns raised in the report. A good outcome of the report is the detailed Security Best Practices Guide developed for Istio users.

At Aspen Mesh, we build upon the security features Istio provides and address enterprise security requirements with a zero-trust based service mesh that provides security within the Kubernetes cluster, provides monitoring and alerts, and ensures highly-regulated industries maintain compliance. You can read about how we think about security in our white paper, Adopting a Zero-Trust Approach to Security for Containerized Applications.

If you'd like to talk to us about what enterprise security in a service mesh looks like, please get in touch!

-Aspen Mesh

 

istio test stats from cncf.io

Aspen Mesh 1.5.10-am1 & 1.6.12-am2 Available for Envoy Security Updates

We recently released Aspen Mesh 1.5.10 as well as 1.6.12-am2, which both address important security updates related to an HTTP header security vulnerability that was recently reported in Envoy. We highly recommend our customers to update to these patched versions by following the instructions here.

At Aspen Mesh, we’re dedicated to helping keep upstream open source and cloud-native applications (including Istio and Envoy) as secure and healthy as possible. When this vulnerability was discovered, we were eager to quickly contribute to a fix in order to keep Istio’s (and Aspen Mesh’s) end-users secure.

Envoy HTTP Header Security Vulnerability

Envoy recently reported an incorrect handling of duplicate HTTP headers (CVE-2020-25017). In this CVE, it was reported that Envoy was only considering the first value when multiple values were presented for a non-inline header. The logic would then ignore all following values for a non-iline header when executing matching logic. An attacker could use this exploit as a request policy bypass by including additional non-inline headers with the same key, but with different values, provided that only the first header value matched the routing rule. As a result, client requests could be routed incorrectly and Envoy would pass different headers to the application workloads than what it has in its own internal representation leading to inconsistency. 

In this blog, we will cover test cases and policy examples which our users can deploy to validate if their current version is affected and how this CVE can be exploited by attackers in their environment. 

Test Cases Based on Istio Policies

In this Envoy CVE, there was a vulnerability allowing attackers to set multiple values of a non-inline HTTP headers, such as x-foo:bar and x-foo:baz whereby the affected Envoy components would only observe the first value, x-foo:bar, in matchers, but both x-foo:bar and x-foo:baz would be forwarded to the application workload. Upstreams may take both values into consideration, resulting in an inconsistency between Envoy’s request matching and the upstream view of the request. You can find the complete list of inline HTTP headers in Envoy here for reference.

The Aspen Mesh team worked to develop a solution to trigger and verify the fix for the security vulnerability by working through several test cases. For these test cases, we developed a VirtualService policy resource that specified incoming requests that matched an x-foo header with only a value baz. This would be routed to the httpbin service in the baz namespace. Any other request that did not match that rule would be routed to the httpbin service in the default namespace.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-headers
spec:
  hosts:
  - httpbin.default.svc.cluster.local
  http:
  - match:
    - headers:
        x-foo:
          exact: baz
    route:
    - destination:
        host: httpbin.baz.svc.cluster.local
  - route:
    - destination:
        host: httpbin.default.svc.cluster.local

 

With this policy deployed, we generated client traffic with different combinations of non-inline headers to trigger this CVE, and the results are summarized in this table below:

Test Case 1.5.7-am5 destination service 1.5.10-am1 destination service
curl httpbin.default:8000/get -H "x-foo: bar" -H "x-foo: baz" httpbin.default.svc.cluster.local httpbin.default.svc.cluster.local
curl httpbin.default:8000/get -H "x-foo: bar" httpbin.default.svc.cluster.local httpbin.default.svc.cluster.local
curl httpbin.default:8000/get -H "x-foo: baz" httpbin.baz.svc.cluster.local httpbin.baz.svc.cluster.local
curl httpbin.default:8000/get  httpbin.default.svc.cluster.local httpbin.default.svc.cluster.local
curl httpbin.default:8000/get -H "x-foo: baz" -H "x-foo: bar" httpbin.baz.svc.cluster.local httpbin.default.svc.cluster.local

 

We can see in Aspen Mesh version 1.5.7-am5 that the request is routed incorrectly to the httpbin in the baz namespace thereby bypassing configured policy, but in 1.5.10-am1, the same request is routed to thehttpbin service in the default namespace, as we expected. This behavior change, along with the verification of the upstream commits that fixed this issue from upstream Envoy, leads us to believe that our 1.5.10-am1 release contains the required CVE fix. We ran a similar experiment on the affected Aspen Mesh version 1.6.5-am1 and the patched version 1.6.12-am2 to validate that CVE is addressed correctly.

The official remediation fixes these inconsistencies, providing a more secure Aspen Mesh installation with uniform policy enforcement. The newest Aspen Mesh binaries are available for download here.  


How Delphi Simplifies Kubernetes Security with Aspen Mesh

Customer Story: How Delphi Simplifies Kubernetes Security with Aspen Mesh

Delphi and Zero-Trust Security

Delphi delivers software solutions that help professional liability insurers streamline their operations and optimize their business processes. Operating in the highly regulated healthcare industry, privacy and compliance concerns such as HIPAA and APRA mandate a highly secure environment. As such, a Zero-trust environment is of utmost importance for Delphi and their customers. 

The infrastructure team at Delphi has fully embraced a cloud-native stack to deliver the Delphi Digital Platform to its customers. The team leverages Kubernetes to effectively manage builds and deploys. Delphi planned to use Kubernetes from the start, but was looking for a simpler security solution for their infrastructure that could be managed without implementations in each service. 

While Delphi was getting tremendous value from Kubernetes, they needed to find an easier way to bake security into the infrastructure. Taking advantage of a service mesh was the obvious solution to address this challenge, as it provides cluster-wide mTLS encryption. 

The team chose Istio to confront this problem, and while the initial solution included setting up a certificate at the load balancer, this had open http between the load balancer and service. Unfortunately, this was not acceptable in a highly regulated healthcare industry with strict requirements to keep personal data secure. 

Achieving Security with a Service Mesh

To solve these challenges, Delphi engaged with Aspen Mesh in order to implement an end-to-end encrypted solution, from Client to back end SaaS applications. This was achieved by enabling mTLS mesh-wide from service to service and creating custom Istio policy manifests to integrate cert-manager and Let's Encrypt for client-side encryption. As a result, Delphi is able to provide secure ingress integration for a multitenant B2C environment, allowing Delphi to deploy a fully scalable solution. 

[Read the Full Case Study Here]

This Aspen Mesh solution lets Delphi use Let’s Encrypt seamlessly with Istio, removing the need to consider building security into application development and placing it into an infrastructure solution that is highly scalable. Leveraging the power of Kubernetes, Istio and Aspen Mesh, the Delphi team is delivering a highly secure platform to their customers without the need to implement encryption in each service. 

“At this point, I look at Aspen Mesh as an extension of my team” 

- Bill Reeder, Delphi Technology Lead Architect


photo of vault door

How to Approach Zero-Trust Security with a Service Mesh

Last year was challenging for data security. In the first nine months alone, there were 5,183 breaches reported with 7.9 billion records exposed. Compared to mid-year 2018, the total number of breaches was up 33.3 percent and the total number of records exposed more than doubled, up 112 percent.

Zero Trust Security 2019

What does this tell us? That, despite significant technology investments and advancements, security is still hard. A single phishing email, missed patch, or misconfiguration can let the bad guys in to wreak havoc or steal data. For companies moving to the cloud and the cloud-native architecture of microservices and containerized applications, it’s even harder. Now, in addition to the perimeter and the network itself, there’s a new network infrastructure to protect: the myriad connections between microservice containers.

With microservices, the surface area available for attack has increased exponentially, putting data at greater risk. Moreover, network-related problems like access control, load balancing, and monitoring that had to be solved once for a monolith application now must be handled separately for each service within a cluster.

Zero-Trust Security and Service Mesh

Security is the most critical part of your application to implement correctly. A service mesh allows you to handle security in a more efficient way by combining security and operations capabilities into a transparent infrastructure layer that sits between the containerized application and the network. Emerging today to address security in this environment is the convergence of the Zero-Trust approach to network security and service mesh technology.

Here are some examples of attacks that a service mesh can help mitigate:

  • Service impersonation
    • A bad actor gains access to the private network for your applications, pretends to be an authorized service, and starts making requests for sensitive data.
  • Unauthorized access
    • A legitimate service makes requests for sensitive data that it is not authorized to obtain.
  • Packet sniffing
    • A bad actor gains access to your applications private network and captures sensitive data from legitimate requests going over the network.
  • Data exfiltration
    • A bad actor sends sensitive data out of the protected network to a destination of their choosing.

So how can the tenets of Zero-Trust security and how a service mesh enable Zero Trust in the microservices environment? And how can Zero-Trust capabilities help organizations address and demonstrate compliance with stringent industry regulations?

Threats and Securing Microservices

Moat and Castle ApproachTraditionally, network security has been based on having a strong perimeter to help thwart attackers, commonly known as the moat-and-castle approach. With a secure perimeter constructed of firewalls, you trust the internal network by default, and by extension, anyone who’s there already. Unfortunately, this was never a reliably effective strategy. But more importantly, this approach is becoming even less effective in a world where employees expect access to applications and data from anywhere in the world, on any device. In fact, other types of threats -- such as insider threats -- have generally been considered by most security professionals to be among the highest threats to data protected by companies, leading to more development around new ways to address these challenges.

In 2010, Forrester Research coined the term “Zero Trust” and overturned the perimeter-based security model with a new principle: “never trust, always verify.” That means no individual or machine is trusted by default from inside or outside the network. Another Zero-Trust precept: “assume you’ve been compromised but may not yet be aware of it.” With the time to identify and contain a breach running at 279 days in 2019, that’s not an unsafe assumption.

Starting in 2013, Google began its transition to implementing Zero Trust into its networking infrastructure with much success and has made the results of their efforts open to the public in BeyondCorp. Fast forward to 2019 and the plans to adopt this new paradigm have spread across industries like wildfire, largely in response to massive data breaches and stricter regulatory requirements.

While there are myriad Zero-Trust networking solutions available for protecting the perimeter and the operation of corporate networks, there are many new miles of connections within the microservices environment that also need protection. A service mesh provides critical security capabilities such as observability to aid in optimizing MTTD and MTTR, as well as ways to implement and manage encryption, authentication, authorization, policy control and configuration in Kubernetes clusters.

Security Within the Kubernetes Cluster

While there are myriad Zero-Trust networking solutions available for protecting
the perimeter and the operation of corporate networks, there are many new miles of connections within the microservices environment that also need protection. A service mesh provides critical security capabilities such as observability to aid in optimizing MTTD and MTTR, as well as ways to implement and manage encryption, authentication, authorization, policy control and configuration in Kubernetes clusters.

Here are a few ways to approach enhancing your security with a service mesh:

  • Simplify microservices security with incremental mTLS
  • Manage identity, certificates and authorization
  • Access control and enforcing the level of least privilege
  • Monitoring, alerting and observability

A service mesh also adds controls over traffic ingress and egress at the perimeter. Allowed user behavior is addressed with with role-based access control (RBAC). With these controls, the Zero-Trust philosophy of “trust no one, authenticate everyone” stays in force by providing enforceable least privilege access to services in the mesh.

Aspen Mesh can help you to achieve a Zero-Trust security posture by applying these concepts and features. As an enterprise- and production-ready service mesh that extends the capabilities of Istio to address enterprise security and compliance needs, we also provide an intuitive hosted user interface and dashboard that make it easier to deploy, monitor, and configure these features.

Learn More About Zero-Trust Security and Service Mesh

Interested in learning more about how service mesh can help you achieve Zero-Trust security? Get the free white paper by completing the form below.




Secure Ingress + TLS Termination - Aspen Mesh

Secure Ingress + TLS Termination: The Match You Didn't Know You Needed

Keeping Data Secure

Secure Ingress + TLS TerminationWorking in an increasingly connected world, maintaining the security of users and their data is a challenging problem to solve. As we move into a state where service meshes are becoming a better way to provide availability of services to your users, it’s also more important to ensure that the data is secured from the moment it leaves the user’s device until it is ingressed into your service mesh. In an interconnected world increasingly focused on the security of both users and their data, secure ingress is a fundamentally complex but necessary part of the service mesh architecture.

Today, I’d like to talk about secure ingress, TLS termination and how this all affects users and maintainers of an Istio service mesh. We’ll also touch on some of the pitfalls of setting up TLS termination as well as how Aspen Mesh attempts to simplify the entire process, so your teams are free to focus on providing value to your customers.

 

Security and You: What is Secure Ingress?

So you’ve got your services up and running, sidecars injected, Prometheus churning out stats and Istio working properly in your cluster; you’re ready to start processing user data and adding value. But your security team is leery about that TCP ingress you’ve been using for testing. Gateways and Virtual Services are great, and while passing TLS requirements down to the service has been working, they want a stronger assertion. How can you make sure that all datawhether or not it is secured within the service meshis encrypted with no setup from the services themselves?

Enter secure ingress. By configuring TLS requirements on your Istio Gateway, you can make sure that all information is encrypted, even without TLS on your services. Istio supports TLS certificates in both traditional file mount setups as well as in Kubernetes secrets

 

Configuration Issues (Otherwise Known As: ANOTHER 503 UF UR?!)

You’ve decided that TLS termination is the way to go, sounds amazing! No more needing to worry about services handling TLS requirements, and we can even JWT secure our endpoints! You deploy the gateway, virtual service and authorization policy and once you’ve got your TLS certs deployed, you hit that endpoint and get… A 503 status? Looking at the Istio ingress gateway logs only tells you that there was an upstream connection failure (UF) and the upstream connection reset (UR). What’s going on?

Welcome to layer seven TCP routing and mTLS requirements. By deploying an authorization policy to JWT to secure your ingress endpoints, you may have inadvertently disabled mTLS, causing your sidecars to balk at communicating. Maybe you haven’t even been fully using sidecars for some of the services up until this point! Each of these errors show up as an obtuse 503 status code and require digging into the istioctl proxy config just to get an understanding on what’s going on in the backend. 

Even more frustrating, the configuration of your service may have been fine without TLS termination. Ingressing through a TCP port to a TCP port on your service for HTTP traffic is fine. But now that you’re using HTTPS, Istio wants to know about what type of traffic you’ll actually be sending. You’ll have to prefix your port names on your service with “http-” in order to tell Istio what you actually are sending over to that service. But Istio’s errors aren’t going to tell you about that.

 

Certificates? DNS?

Let’s say you’ve addressed the issues above. You’ve finally gotten your services to connect from the outside world, your cluster is up and running, and everything finally seems to be working as you expected. But hold on, your ELB just restarted, and now it has a new domain name and a new IP address. Suddenly, traffic is no longer ingressing. Your old DNS records aren’t pointing to the correct host name, and since you’re using TLS now, you can’t just point your customers at your new host name and call it good. 

External DNS management will need to be configured for your cluster to make sure this does not happen, updating the records as your DNS and IP addresses shift. And if your certificates are not renewed, will you be ready with CertManager set up properly in your cluster?

 

Secure Ingress with Aspen Mesh

As described above, setting up secure ingress into an Istio cluster is not as simple as it looks. From configuration issues ranging from mTLS configuration and service port naming, to ever changing environments with DNS and certificate renewals, managing a TLS ingress into your cluster can be a daunting process, especially for new Istio users. The good news? Aspen Mesh can help simplify your secure ingress needs. By simply specifying applications and ports that you’d like to open to the world, and the ports you’d like to ingress on, Aspen Mesh’s Secure Ingress will take care of the configuration for you by: 

  • Setting up and maintaining gateways, virtual services, and authorization policies
  • Providing you with detailed information about possible misconfigurations in your secure ingress

Now doesn’t that seem like a lot of work you’d rather have your system do for you? Reach out to our team of experts if you’d like to learn more about how we can help.


Microservice Security and Compliance in Highly Regulated Industries: Threat Modeling

The year is 2019, and the number of reported data breaches is up 54% compared to midyear 2018 and is set to be the “worst year on record,’ according to RiskBased Security research. Nearly 31 million records have been exposed in the 13 most significant data breaches of the first half of this year. Exposed documents included personal health information (PHI), personally identifiable information (PII) and financial data. Most of these data breaches were caused by one common flaw: poor technical and human controls that could have easily been mitigated if an essential security process were followed. This simple and essential security process is known as threat modeling.

What is threat modeling?

Threat modeling is the process of identifying and communicating potential risks and threats, then creating countermeasures to respond to those threats. Threat modeling can be applied to multiple areas such as software, systems, networks, and business processes. When threat modeling, you must ask and answer questions about the systems you are working to protect. 

Per OWASP, threat model methodologies answer one or more of the following questions: 

  • What are we building?
    • Outputs:
      • Architecture diagrams
      • Dataflow transitions
      • Data classifications
  • What can go wrong?
    • To best answer this question, organizations typically brainstorm or use structures such as STRIDE, CAPEC or Kill Chains to help determine primary threats that apply to your systems and organization. 
    • Outputs:
      • A list of the main threats that apply to your system.
  • What are we going to do about that?
    • Output
      • Actionable tasks to address your findings.
  • Did we do an acceptable job?
    • Review the quality, feasibility, process, and planning of the work you have done.

These questions require that you step out of your day-to-day responsibilities and holistically consider systems and processes surrounding them. When done right, threat modeling provides a clear view of the project requirements and helps justify security efforts in language everyone in the organization can understand.

Who should be included in threat modeling?

The short answer is, everyone. Threat modeling should not be conducted in a silo by just the security team but should be worked on by a diverse group made up of representatives across the organization. Representatives should include application owners, administrators, architects, developers, product team members, security engineers, data engineers, and even users. Everyone should come together to ask questions, flag concerns and discuss solutions.

A security checklist is essential

In addition to asking and answering general system and process questions, a security checklist should be used for facilitating these discussions. Without a defined and agreed-upon list, your team may overlook critical security controls and won’t be able to evaluate and continually improve standards.

Here’s a simple example of a security checklist:

Authentication and Authorization

☐ Are actors required to authenticate so that there is a guarantee of non-repudiation?

☐ Do all operations in the system require authorization?

Access Control

☐ Is access granted in a role-based fashion?

☐ Are all access decisions relevant at the time the request is performed?

Trust Boundaries

☐ Can you clearly identify where the levels of trust change in your model?

☐ Can you map those to authentication, authorization and access control?

Accounting and Auditing

☐ Are all operations being logged?

☐ Can you guarantee there is no PII, ePHI or secrets being logged?

☐ Are all audit logs adequately tagged?  

When should I start threat modeling? 

“The sooner the better, but never too late.” - OWASP

How often should threat modeling occur?

Threat modeling should occur during system design, and anytime systems or processes change. Ideally, threat modeling is tightly integrated into your development methodology and is performed for all new features and modifications prior to those changes being implemented. By tightly integrating with your development process, you can catch and address issues early in the development lifecycle before they’re expensive and time-consuming to resolve.

Threat modeling: critical for a secure and compliant microservice environment

Securing distributed microservice systems is difficult. The attack surface is substantially larger than an equivalent single system architecture and is often much more difficult to fully comprehend all of the ways data flows through the system. Given that microservices can be short-lived and replaced on a moment's notice, the complexity can quickly compound. This is why it is critical that threat modeling is tightly integrated into your development process as early as possible.     

Aspen Mesh makes it easier to implement security controls determined during threat modeling

Threat modeling is only one step in a series of steps required to secure your systems. Thankfully, Aspen Mesh makes it trivial to implement security and compliance controls with little to no custom development required, thus allowing you to achieve your security and compliance goals with ease. If you would like to discuss the most effective way for your organization to secure their microservice environments, grab some time to talk through your use case and how Aspen Mesh can help solve your security concerns.

Learn more about security and service mesh

Interested in learning more about how service mesh can help you achieve security? Get the free white paper on achieving Zero-trust for containerized applications by completing the form below.


Microservice Security and Compliance in Highly Regulated Industries: Zero Trust Security

Zero Trust Security

Security is the most critical part of your application to implement correctly. Failing to secure your users’ data can be very expensive and can make customers lose their faith in your ability to protect their sensitive data. A recent IBM-sponsored study showed that the average cost of a data breach is $3.92 million, with healthcare being the most expensive industry with an average of $6.45 million per breach. What else might be surprising is that the average time to identify and contain a breach is 279 days, while the average lifecycle of a malicious attack from breach to containment is 314 days. 

Traditionally network security has been based on having a strong perimeter to help thwart attackers, commonly known as the moat-and-castle approach. This approach is no longer effective in a world where employees expect access to applications and data from anywhere in the world, on any device. This shift is forcing organizations to evolve at a rapid rate to stay competitive in the market, and has left many engineering teams scrambling to keep up with employee expectations. Often this means rearchitecting systems and services to meet these expectations, which is often difficult, time consuming, and error prone.   

In 2010 Forester coined the term ‘Zero Trust’ where they flipped the current security models on their heads by changing how we think about cyberthreats. The new model is to assume you’ve been compromised, but may not yet be aware of it. A couple years later, Google announced they had implemented Zero Trust into their networking infrastructure with much success. Fast forward to 2019 and the plans to adopt this new paradigm have spread across industries like wildfire, mostly due to the massive data breaches and stricter regulatory requirements.

Here are the key Zero Trust Networking Principles:

  • Networks should always be considered hostile. 
    • Just because you’re inside the “castle” does not make you safe.
  • Network locality is not sufficient for deciding trust in a network.
    • Just because you know someone next to you in the “castle”, doesn’t mean you should trust them.
  • Every device, user, and request is authenticated and authorized.
    • Ensure that every person entering the “castle” has been properly identified and is allowed to enter.
  • Network policies must be dynamic and calculated from as many sources of data as possible. 
    • Ask as many people as possible when validating if someone is allowed to enter the “castle”.

Transitioning to Zero Trust Networking can dramatically increase your security posture, but until recent years, it has been a time consuming and difficult task that required extensive security knowledge within engineering teams, sophisticated internal tooling that could manage workload certificates, and service level authentication and authorization. Thankfully service mesh technologies, such as Istio, allow us to easily implement Zero Trust Networking across our microservices and clusters with little effort, minimal service disruption, and does not require your team to be security experts. 

Zero Trust Networking With Istio

Istio provides the following features that help us implement Zero Trust Networking in our infrastructure:

  • Service Identities
  • Mutual Transport Layer Security (mTLS)
  • Role Based Access Control (RBAC) 
  • Network Policy

Service Identities

One of the key Zero Trust Networking principles requires that “every device, user, and request is authenticated and authorized”. Istio implements this key foundational principle by issuing secure identities to services, much like how application users are issued an identity. This is often referred to as the SVID (Secure and Verifiable Identification) and is used to identify the services across the mesh, so they can be authenticated and authorized to perform actions. Service identities can take different forms based on the platform Istio is deployed on, for example:

  • When deployed on:
    • Kubernetes: Istio can use Kubernetes service accounts.
    • Amazon Web Services (AWS): Istio can use AWS IAM user and role accounts.
    • Google Kubernetes Engine (GKE): Istio can use Google Cloud Platform (GCP) service accounts.

Mutual Transport Layer Security (mTLS)

To support secure Service Identities and to secure data in transit, Istio provides mTLS for encrypting service-to-service communication and achieving non-repudiation for requests. This layer of security reduces the likelihood of a successful Man-in-The-Middle attack (MiTM) by requiring all parties in a request to have valid certificates that trust each other. The process for certificate generation, distribution, and rotation is automatically handled by a secure Istio service called Citadel.  

Role Based Access Control (RBAC)

Authorization is a critical part of any secure system and is required for a successful Zero Trust Networking implementation. Istio provides flexible and highly performant RBAC via centralized policy management, so you can easily define what services are allowed to communicate and what endpoints services and users are allowed to communicate with. This makes the implementation of the principle of least privilege (PoLP) simple and reduces the development teams’ burden of creating and maintaining authorization specific code.

Network Policy

With Istio’s centralized policy management, you can enforce networking rules at runtime. Common examples include, but are not limited to the following:

  • Allowlisting and denylisting access to services, so that access is only granted to certain actors.
  • Rate limiting traffic, to ensure a bad actor does not cause a Denial of Service attack.
  • Redirecting requests, to enforce that certain actors go through proper channels when making their requests.

Cyber Attacks Mitigated by Zero Trust Networking With Istio

The following are example attacks that can be mitigated:

  1. Service Impersonation - A bad actor is able to gain access to the private network for your applications, pretends to be an authorized service, and starts making requests for sensitive data.
  2. Unauthorized Access - A legitimate service makes requests for sensitive data that it is not authorized to obtain. 
  3. Packet Sniffing - A bad actor gains access to your applications private network and captures sensitive data from legitimate requests going over the network.
  4. Data Exfiltration - A bad actor sends sensitive data out of the protected network to a destination of their choosing.

Applying Zero Trust Networking in Highly Regulated Industries

To combat increased high profile cyber attacks, regulations and standards are evolving to include stricter controls to enforce that organizations follow best practices when processing and storing sensitive data. 

The most common technical requirements across regulations and standards are:

  • Authentication - verify the identity of the actor seeking access to protected data.
  • Authorization - verify the actor is allowed to access the requested protected data.
  • Accounting - mechanisms for recording and examining activities within the system.
  • Data Integrity - protecting data from being altered or destroyed in an unauthorized manner.

As you may have noticed, applying Zero Trust Networking within your application infrastructure does not only increase your security posture and help mitigate cyber attacks, it also addresses control requirements set forth in regulations and standards, such as HIPAA, PCI-DSS, GDPR, and FISMA.

Use Istio to Achieve Zero Trust the Easy Way

High profile data breaches are at an all time high, cost an average of $3.92 million, and they take upwards of 314 days from breach to containment. Implementing Zero Trust Networking with Istio to secure your microservice architecture at scale is simple, requires little effort, and can be completed with minimal service disruption. If you would like to discuss the most effective way for your organization to achieve zero trust, grab some time to talk through your use case and how Aspen Mesh can help solve your security concerns.

Learn More About Security and Service Mesh

Interested in learning more about how service mesh can help you achieve Zero Trust security? Get the free white paper by completing the form below.