A Service Mesh Helps Simplify PCI DSS Compliance
Aspen Mesh sponsored this post.
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.
Feature image via Pixabay.
