Solve Istio Security Risks and Get a Handle on Regulatory Compliance

Many verticals, such as Financial services, Healthcare, Insurance, Transportation and Government contracting are highly regulated industries that must adhere to strict Information Technology (IT) compliance requirements. Each industry has unique certification and compliance requirements, for example HIPAA for Healthcare, PCI-DSS for Payment cards, and SOC2 for the Financial services industry.  

Failure to certify against a compliance regulation can mean a Chief Information Security Officer (CISO) or Chief Compliance Officer (CCO) may not be able to authorize a deployment, microservices upgrade or the addition of new services to an existing service mesh deployment. Achieving compliance with industry requirements is rarely trivial, and at the executive level it is a critical business objective. A compliance requirement raises new security concerns and forces security to be looked at from different angles in any Kubernetes based deployment, old or new. 

Our approach to compliance and security

At Aspen Mesh we work with Fortune 2000 companies to help solve their security and compliance concerns. Our certified Istio experts address many inquiries relating to security, some are related to bare-bones security capabilities and management, and the other are related to specific requirements for individual workloads. Most security related inquiries have a compliance requirement at their core. Simply put, compliance drives security requirements, and thus security headaches. We often see the security issues and concerns raised during converting monolithic applications or environments to cloud-native apps running in a Kubernetes environment as part of a digital transformation initiative.  

Security for compliance is best architected up-front during this transformation process to make compliance a central focus for the design and deployment, especially where existing legacy or hybrid transition steps are planned. 

Goal: Design-in regulatory compliance from the start

  • Simplify deployment and save time by short-circuiting compliance issues up front. 
  • Preserve operational capability of legacy IT elements and associated data. 
  • Gain immediate security benefits by securing compliant workloads from the get-go. 
  • Save time on backend deployment headaches through better tools, visibility, dashboards, and auditing capabilities. 

Istio addresses common security problems out of the box

SOC (Security Operation Center) 2 compliance from the American Institute of Certified Public Accountants, are a series of industry-recognized standards for cloud service providers, software providers and developers, web marketing companies and financial services organizations. Section CC6.6 of SOC2 specifies that unauthorized network connections must be detected. A service mesh can be useful here as it restricts interactions between microservices and automatically generates audit logs to allow you to determine who did what and at what time forming the basis of mandated Auditing tools. 

Similarly, the Health Insurance Portability and Accountability Act (HIPAA) modernized the flow of healthcare information and stipulates how personally identifiable information maintained by the healthcare and healthcare insurance industries should be protected from fraud and theft. A service mesh helps to solve the top four most reported HIPAA violations: 

  • Unauthorized access  
  • Lack of cryptography policy  
  • No proper notification of affected parties and public officials following relevant data breaches 
  • Lack of willingness/capability to update, upgrade or address existing compliance gaps. 

Istio based service mesh streamlines the regulatory compliance process in a Kubernetes environment

Istio provides Security by default as no changes are needed to re-code applications and infrastructure. Achieving defense in depth requires integration with existing security systems to provide multiple layers of defense. A Zero-trust network is fostered by building security solutions on distrusted networks to provide each service with strong authentication and authorization to enable interoperability across clusters and clouds. Istio secures service-to-service communication and provides a management system to automate key and certificate generation, distribution, and rotation.  

Traffic encryption and flexible service access control is achieved through mutual TLS (Transport Layer Security) connections and fine-grained system access is facilitated through RBAC (Role Based Access Control). Sidecar and perimeter proxies work as Policy Enforcement Points (PEPs) to secure communication between clients and servers, including a set of Envoy proxy extensions to manage telemetry and auditing. Peer authentication is used for service-to-service authentication to verify the client making the connection. Istio offers mutual TLS as a full stack solution for transport authentication, which can be enabled without requiring service code changes. 

Eight ways Istio helps you achieve regulatory compliance

  1. End-to-end security 
  2. Granularity of security 
  3. Secure integration with legacy components 
  4. Compliant workloads run in compliant environments 
  5. Visibility to configuration changes 
  6. Dashboard reporting 
  7. Audit logs 
  8. Enable Continual Compliance 

Istio is key in your move from monolithic services to a modern microservices environment

Istio can form a central part of your move from a monolithic services system to a modern Kubernetes based microservices architecture, preserving the ability to use legacy elements. Istio provides all the hooks and handles needed to overcome security issues that cause compliance headaches, to help you achieve compliance faster – which means a quicker deployment with fewer problems and getting a step closer to continual compliance operations. 

  • Compliance requirements drive the need behind most security issues 
  • Istio provides the basis for compliance in a Kubernetes environment 

Checklist for Compliance in a Microservices World

3 Steps to help you put your compliance house in order

1. Architectural review 

  • Have compliant and noncompliant workloads been separated? 
  • Are your compliant workloads running in compliant environments? 

2. Prepare legacy elements for connection to the service mesh 

  • Are the connections to the legacy elements secure? 
  • Are microservices restricted to specific legacy elements?

3. Configure Istio for compliant operation 

  • Are the built-in security features enabled? 
  • Are the mTLS settings correct for your environment? 

About Aspen Mesh

Our experts understand what is necessary to achieve regulatory compliance. We have a team of seasoned Istio experts, and there is no one better at solving Istio security issues and relieving compliance headaches. 

  • Aspen Mesh is a top 5 contributor to the Open Source Istio project – we help shape OS Istio. 
  • Aspen Mesh has deployed service mesh projects in the world’s largest and most complex organizations. 
  • Aspen Mesh visibility tools and dashboards will help you to achieve Continual Compliance. 
  • Reach out to an Aspen Mesh expert for an architectural review and security audit 

Get in touch and we can talk about the compliance issues you are facing. We will share what we’ve done at Fortune 2000 companies to help them achieve their regulatory compliance goals. 


Istio mTLS: 8 Ways to Ensure End-to-End Security

Every time an mTLS problem arises, it has the potential to cause a deployment or service outage. 

Mutual TLS (mTLS) is a method of ensuring traffic is authenticated and encrypted between Kubernetes services. In a highly distributed cloud-native system, using mTLS can drastically increase your security posture by eliminating impersonators, bad actors, and traffic snooping. However, this comes with additional complexity, and troubleshooting issues can be challenging.   

Implementing mTLS is often done with a sidecar service mesh like Istio. Istio supports mTLS out of the box, but in our experience the default configuration is not enough. 

Simple configuration changes are often all that is needed to solve the most taxing of issues.  

The Aspen Mesh team has experience helping our customers deploy mutual Transport Layer Security (TLS) across a wide range of industry verticals and situations. 

8 ways to mitigate risk when deploying mutual TLS:

1. Enforce STRICT mode as a default

Why it’s important: Ensures end-to-end security for all devices and services. 

PERMISSIVE mode allows a service to accept both plain text traffic and mutual TLS traffic at the same time. This feature greatly improves the mutual TLS onboarding experience; however, this mode is not as secure as STRICT mode. When STRICT is set, the service only accepts mutual TLS traffic. For services with transport authentication enabled by an authentication policy, the peers section has an additional key (mode), which you can use to define which traffic a service can accept from its peers. This mode key can take two values: PERMISSIVE or STRICT. If PERMISSIVE is set, the service can accept both plain-text traffic as well as encrypted. If STRICT is set, the service only accepts mutual TLS traffic. 

In Istio, sidecar proxies for each service are needed to establish mutual TLS communication. However, during a service onboarding process there may be cases where the operator cannot install sidecar proxies for all clients and services at the same time. In these situations, it is ideal to enable communication between non-Istio client services and Istio target services. By enabling the PERMISSIVE mode in the authentication policy for a target service, non-Istio client services can continue to send plain-text traffic to the target service until the onboarding process is complete, when STRICT can be enabled. 

 

2. Enable mutual TLS global by default

Why it’s important: Defines scope of mutual TLS settings. 

There are three levels of granularity through which mutual TLS settings can be defined. For each service, Istio applies the narrowest matching policy. The order is: service-specific, namespace-wide, mesh-wide. It is best to enforce mTLS globally, and then change to PERMISSIVE at the service level only when necessary.   


3. Don’t rely on Perimeter defenses to secure core applications and services

Why it’s important: Greater security and compliance with industry regulations. Perimeter defenses are insufficient; secure critical core services and traffic with end-to-end security. 

Don’t rely on Perimeter defenses to secure your core applications and services. While defense-in-depth has been a valid approach to security, it does not stop an attacker from viewing unencrypted data after the security bubble has been pierced. Only services that are encrypted end-to-end can provide the level of security needed to protect confidential information such as financial transactions or medical records. 

 

4. Visibility for service communication

Why it’s important: Eases misconfigurations and aids in troubleshooting. 

A visibility tool is paramount to get a picture of what’s happening at the service level. For example, if one service has no sidecar installed, or a service with a sidecar has a service-specific policy set and there is something wrong with communication between services, the cause may be one service has mutual TLS enabled where another service may not support mutual TLS. A visibility tool that runs in real time can help to find problems quickly as they arise, dynamically visualizing services and their communications to ease misconfigurations and aid in troubleshooting. 


5. Enable an external Certificate Authority

 Why it’s important: More easily integrate with external systems.

Although the Istio Certificate Authority (CA) generates a self-signed root certificate/key, and uses them to sign all workload certificates, external parties normally will not trust a digital certificate signed by an Internal CA. Also, the certificate management overhead of an Internal CA is higher than that of external CA. External parties normally trust a digital certificate signed by a trusted External CA easing the ability to work with external services over using an Internal CA. 

 

6. Optimize System Design – Design for mTLS and service mesh from the start

Why it’s important: Retrofitting system-wide mTLS after deployment of the platform and services is difficult and error prone. Designing for mTLS from the beginning will increase your success rate and ensure that all communication channels are secured properly.  Attempting to implement mTLS after deploying the platform and applications will require reconfiguration of the service mesh, installing and configuring a root CA, redeploying all applications, and regression testing of the applications and external integrations. 

 

7. Mitigate the mutual TLS performance hit

Why it’s important: Mitigate to restore ideal system performance to prevent services operating at less than optimum levels 

After enabling mutual TLS, depending on the service or workload, a performance hit may be experienced which can affect services. A performance hit up to 10% is possible, but largely depends on the services and workload of the deployment. To mitigate any resultant performance hit, Envoy can be tuned, and the underlying deployment hardware re-sized to restore system performance. 

 

8. Decrease certificate rotation time

Why it’s important: Enhances security which helps to defeat hackers. 

Istio has a default Certificate rotation time that rotates new Certificates, and encryption keys are issued. However, the longer this rotation interval, the more opportunity an attacker has to defeat the encryption. Set the Certificate rotation time to the minimum rotation time needed for your deployment / services. This helps defeat hackers by shortening the window of time they have to execute “brute force” attacks. 

 

How can Aspen Mesh help you on your Istio journey?

Aspen Mesh provides the knowledge, leadership & expertise needed to successfully help you deploy mTLS. We have helped customers deploy in the Enterprise, Telco, Financial services, and Healthcare verticals. We have deployed mTLS in complex High Availability and Disaster Recovery environments and provided upfront training before the deployment starts, and expert support after the deployment is complete. We can: 

  • Advocate for your needs within the open-source community 
  • Provide training and expert support 
  • Mitigate your deployment risk with our service offerings, which include: 
  • A 360° quantitative and qualitative evaluation of your Istio environment to identify problems. 
  • Expertise in the design of a scalable service mesh environment. 
  • Comprehensive security review and detailed recommendations. 
  • Upgrade Istio in your environment, then ensure it’s running smoothly. 
  • Existing Istio environment benchmarking and tuning for maximum performance. 

 

Deployment success means picking the right partner

mTLS can be challenging, integration with external workloads is problematic, and debugging information can be a blackhole. Visibility is essential when something goes wrong in any deployment, but more so in a mTLS deployment. We provide 24/7 and international support delivered by our expert Istio engineers from F5, a trusted enterprise vendor you can rely on. You can be assured our engineers are with you every step of the way, no matter the problem – big or small.  

Aspen Mesh can help fully manage and monitor your mTLS deployment, setting you up for success in the long term. Our team of experts have the knowledge and expertise to guide you every step of the way. See our Professional Services including in-depth Istio Health Assessment, Architecture Design and Security Essentials and Custom Projects. Get in touch to start the conversation.