Controlling PCI scope

Work in progress

This page is a work in progress. Content may change or be incomplete.

The scenario

Context

The company takes card payments, so it must follow PCI DSS, the security standard for card data. Systems that touch card data form the PCI scope, which is audited and costly to maintain, so it is kept as small as possible. Anything connected to it joins the scope.

What happens

An agent proposes a new spend view architecture for customers. To get the data fast, it consumes the card events.

How ASL helps?

With ASL, the PCI scope is declared in the manifests, and every proposal is checked against it.

Today: Markdown as the harness

network-diagram-v4.pdf · scope reviewed 8 months ago

In PCI scope

payment-servicetokenizer

Outside PCI scope

ledger-servicepayment-eventscard-eventsspend-insights · proposed

Agent proposes

spend-insightsconsumescard-eventsspend-insights consumes card-events

Nothing checks this connection before the merge.

The audit finds spend-insights connected to card data. It, and everything it touches, joins PCI scope: months of rework.

Architecture as Code with ASL

label pci: "true" in the manifests

In PCI scope

payment-servicetokenizercard-events

Outside PCI scope

ledger-servicepayment-eventsspend-insights · proposed

Agent proposes

spend-insightsconsumescard-eventsspend-insights consumes card-events

Application touches PCI data but is not declared in PCI scope; use a tokenized source or ask for a PCI approval

architecture/payments.asl.yaml:51 · acme.pci-scope-is-declared

Agent fixes

spend-insightsconsumespayment-eventsspend-insights consumes payment-events

spend-insights now reads payment-events, which carries tokens only.

$ asl ./architecture --policies-bundle-path ./policies

ok

Scope is declared, and every connection that crosses it is checked before any coding.