A Service Mesh Helps Simplify PCI DSS Compliance

PCI DSS is an information security standard for organizations that handle credit card data. The requirements are largely around developing and maintaining secure systems and applications and providing appropriate levels of access — things a service mesh can make easier.

However, building a secure, reliable and PCI DSS-compliant microservice architecture at scale is a difficult undertaking, even when using a service mesh.

It requires, for example, 12 separate requirements, each of which has different sub-requirements. Additionally, some of the requirements are vague and are left up to the designated Qualified Security Assessor (QSA) to make their best judgment based on the design in question.

Meeting these requirements involves:

  • Controlling what services can talk to each other;
  • Guaranteeing non-repudiation for actors making requests;
  • Building accurate real-time and historical diagrams of cardholder data flows across systems and networks when services can be added, removed or updated at a team’s discretion.

Achieving PCI DSS compliance at scale can be simplified by implementing a uniform layer of infrastructure between services and the network that provides your operations team with centralized policy management and decouples them from feature development and release processes, regardless of scale and release velocity. This layer of infrastructure is commonly referred to as a service mesh. A service mesh provides many features that simplify compliance management, such as fine-grained control over service communication, traffic encryption, non-repudiation via service to service authentication with strong identity assertions, and rich telemetry and reporting.

Below are some of the key PCI DSS requirements listed in the 3.2.1 version of the requirements document, where a service mesh helps simplify the implementation of both controls and reporting:

  • Requirement 1: Install and maintain a firewall configuration to protect cardholder data
    • The first requirement focuses on firewall and router configurations that ensure cardholder data is only accessed when it should be and only by authorized sources.
  • Requirement 6: Develop and maintain secure systems and applications
    • The applicable portions of this requirement focus on encrypting network traffic using strong cryptography and restricting user access to URLs and functions.
  • Requirement 7: Restrict access to cardholder data by business need to know.
    • Arguably one of the most critical requirements in PCI DSS, since even the most secure system can be easily circumvented by overprivileged employees. This requirement focuses on restricting privileged users to least privileges necessary to perform job responsibilities, ensuring access to systems are set to “deny all” by default, and ensuring proper documentation detailing roles and responsibilities are in place.
  • Requirement 8: Identify and authenticate access to system components
    • Building on the foundation of requirement 7, this requirement focuses on ensuring all users have a unique ID; controlling the creation, deletion and modification of identifier objects; revoking access; utilizing strong cryptography during credential transmission; verifying user identity before modifying authentication credentials.
  • Requirement 10: Track and monitor all access to network resources and cardholder data
    • This requirement puts a heavy emphasis on designing and implementing a secure, reliable and accurate audit trail of all events within the environment. This includes capturing all individual user access to cardholder data, invalid logical access attempts and intersystem communication logs. All audit trail entries should include: user identification, type of event, date and time, success or failure indication, origin of event and the identity of the affected data or resource.

Let’s review how Aspen Mesh, the enterprise-ready service mesh built on Istio, helps simplify both the implementation and reporting of controls for the above requirements.

‘Auditable’ Real-time and Historical Dataflows

Keeping records of how data flows through your system is one of key requirements of PCI DSS compliance (1.1.3), as well as a security best practice. With Aspen Mesh, you can see a live view of your service-to-service communications and retrieve historical configurations detailing what services were communicating, their corresponding security configuration (e.g. whether or not mutual TLS was enabled, certificate thumbprint and validity period, internal IP address and protocol) and what the entire cluster configuration was at that point in time (minus secrets of course).

Encrypting Traffic and Achieving Non-Repudiation for Requests

Defense in depth is an industry best practice when securing sensitive data. Aspen Mesh can automatically encrypt and decrypt service requests and responses without development teams having to write custom logic per service. This helps reduce the amount of non-functional feature development work teams are required to do prior to delivering their services in a secure and compliant environment. The mesh also provides non-repudiation for requests by authenticating clients via mutual TLS and through a key management system that automates key and certificate generation, distribution and rotation, so you can be sure requests are actually coming from who they say they’re coming from. Encrypting traffic and providing non-repudiation is key to implementing controls that ensure sensitive data, such as a Primary Account Number (PAN), are protected from unauthorized actors sniffing traffic, and to providing definitive proof for auditing events as required by PCI DSS requirements 10.3.1, 10.3.5, and 10.3.6.

Strong Access Control and Centralized Policy Management

Aspen Mesh provides flexible and highly performant Role-Based Access Control (RBAC) via centralized policy management. RBAC allows you to easily implement and report on controls for requirements 7 and 8 – Implement Strong Access Control Measures. With policy control, you can easily define what services are allowed to communicate, what methods services can call, rate limit requests, and define and enforce quotas.

Centralized Tracing, Monitoring and Alerting

One of the most difficult non-functional features to implement at scale is consistent and reliable application tracing. With Aspen Mesh, you get reliable and consistent in-depth tracing between all services within the mesh, configurable real-time dashboards, the ability to create criteria driven alerts and the ability to retain your logs for at least one year — which exceeds requirements that dictate a minimum of three months data be immediately available for analysis for PCI DSS requirements 10.1, 10.2-10.2.4, 10.3.1-10.3.6 and 10.7.

Aspen Mesh Makes it Easier to Implement and Scale a Secure and PCI DSS Compliant Microservice Environment

Managing a microservice architecture at scale is a serious challenge without the right tools. Having to ensure each service follows the proper organizational secure communication, authentication, authorization and monitoring policies needed to comply with PCI DSS is not easy to achieve.

Achieving PCI DSS compliance involves addressing a number of different things around firewall configuration, developing applications securely and fine-grained RBAC. These are all distinct development efforts that can be hard to achieve individually, but even harder to achieve as a coordinated team. The good news is, with the help of Aspen Mesh, your engineering team can spend less time building and maintaining non-functional yet essential features, and more time building features that provide direct value to your customers.

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 security for containerized applications.

Originally posted on The New Stack

The New Aspen Mesh UI Makes Service Mesh Easy

The New Aspen Mesh UI Makes Service Mesh Easy

The service mesh space is quickly maturing. The service mesh toolbox provides a bevy of different features that can address different microservices challenges, and service meshes are ready to be used in production deployments. But what about the enterprise? They need additional features that address policy, configuration and a uniform view across distributed teams. With this in mind, we built a new user interface that will make it easier for you run a service mesh in your enterprise. A redesigned UI brings the most important information to the forefront so you can easily understand the real-time status of your mesh. Here's a quick look at some of the features to give you an idea what to expect with the new Aspen Mesh UI.  

  • See security and performance posture at a glance – service graph surfaces real time mTLS status and health scores provide visibility into performance
  • Go from macro to micro view – zoom from service graph view into namespace and workload details
  • View service details to quickly identify failures or bottlenecks – view and sort services by latency, error rate and health scores
  • Understand the health of your mesh and be alerted to any mesh configuration errors by our Istio Vet tool
  • Use Aspen Mesh Experiments to securely test and qualify new versions of microservices in your production environment without affecting users

Click play on the video to see it in action


Get your free Aspen Mesh account to take advantage of the new UI and a host of other features. 

DevOps and service mesh

How Service Mesh Enables DevOps

I spend most of my day talking to large companies about how they are transforming their businesses to compete in an increasingly disruptive environment. This isn’t anything new, anyone who has read Clayton Christensen’s Innovator’s Dilemma understands this. What’s most interesting to me is how companies are addressing disruption. Of course, they are creating new products to remain competitive with the disruptors, but they are also taking a page out of their smaller, more nimble competitors’ playbook and focusing on being more efficient.

Companies are transforming internal organizations and product architectures along a new axis of performance. They are finding more value in iterations, efficiency and incremental scaling which is forcing them to adopt DevOps methodologies. This focus on time-to-market is driving some of the most cutting-edge infrastructure technology that we have ever seen. Technologies like containers and Kubernetes; and a focus on stable, consistent and open APIs allow small teams to make amazing progress and move at the speeds they require. These technologies have reduced the friction and time to market and the result is the quickest adoption of a new technology that anyone has ever seen.

The adoption of these technologies isn’t perfect, and as companies deploy them at scale they realize that they have inadvertently increased complexity and de-centralized ownership and control. In many cases, it can be impossible to understand the entire system and everyone needs to be an expert in compliance and business needs. Ultimately this means that when everyone is responsible, no-one is accountable.

A service mesh enables DevOps by helping you to manage this complexity. It provides autonomy and freedom for development teams while simultaneously providing a place for teams of experts to enforce company standards for policy and security. It does this by providing a layer between your teams’ applications and the platform they are running on that allows platform operators a place to insert network services, enforce policy and collect telemetry and tracing data.

This empowers your development teams to make choices based on the problem they are solving rather than being concerned with the underlying infrastructure. Dev teams now have the freedom to deploy code without the fear of violating compliance or regulatory guidelines. Secure communication is handled outside of the application reducing complexity and risk. A service mesh also provides tools that developers can use to deploy new code and debug or troubleshoot problems when they come up.

For the platform operator, whose primary objective is to provide a stable, secure and scalable service to run applications, a service mesh provides uniformity through a standardization of visibility and tracing. Policy and authentication between services can be introduced outside of the application at runtime ensuring that applications are adhering to any regulatory requirements the business may have. Deploying Aspen Mesh provides a robust experiments workflow to enable development teams to test new services using real production traffic. Our platform also provides tools that reduce mean-time-to-detection (MTTD) and mean-time-to-resolution (MTTR) with advanced analytics that are part of our SaaS portal.

DevOps represents two teams, Development and Operations, coming together to deliver better products more rapidly. Service mesh is a glue that helps unite these teams and provides one place in the stack that you can manage microservices at runtime without changes to the application or cluster.

The result is a platform that empowers application developers to focus on their code, and allows operators to more easily provide developers with a resilient, scalable and secure environment.