Tokenization and SAQ D vs C comparison

Tokenization is the process of substituting a sensitive data element with a non-sensitive equivalent. In context of PCI DSS it means replacing credit card details with tokens. Using external service for payment processing, service provider would accept credit card details, process payment (pre-authorization or charge) and provide hotel with a reference number called token.

Tokenization will help property to reduce scope of PCI DSS, or at least help with non-compliant processes. Using system which supports tokenization mechanisms might even bring PCI DSS SAQ type from “D” to “C”, making PCI DSS much easier to achieve and comply with.

In comparison to SAQ D, SAQ C would be easier to comply with. SAQ C has less requirements:

  • Less formalities in network configuration changes such as documented approvals
  • No data retention policies (provided that everything will be stored using tokenization even when need to charge booking 1 day prior arrival if that is possible, not sure here)
  • No encryption key management and custodians
  • Less official policies to document
  • Less documented roles and approvals to access different functions, privileges and components
  • No restriction to use shared logins and no facility entry controls requirements, users can have shared logins
  • … or name badges
  • Req. 11.4 IPS/IDS not strictly required
  • Whole Req. 10.5 would not apply which means no need of centralized log server (SIEM) but FIM or change detection system needed, however still a good practice

But the following would still apply:

  • Penetration testing and vulnerability scanning
  • Antivirus and firewall
  • Monitoring logs would be a good practice
  • Destruction of hard copies containing credit card details
  • Security awareness program for staff
  • Response plan in case of security breach

SIEM solution and PCI scope. Why scoping environment is important

SIEM stands for Security Information and Event Management. Log management and notifications is a part of PCI DSS requirements and not optional in case of SAQ D. SIEM would gather user (staff) activity from computers, servers and network. Logs can be used in event of breach to rebuild a picture what was happening on the network.

An example: someone can install a virus on your network on purpose to steal data. With SIEM it is possible to narrow down who has done it or more like whose credentials were used for that.

SIEM integration is quite sophisticated and requires a lot of time at the beginning. It is not type of “setup and forget”, a continuous maintenance and daily monitoring+review would be needed.

Different vendors have various licensing models: either per number of computers or amount of activity on the network. There are also subscription model or perpetual licence.

The more computers you have on your network the more activity will be logged. However it is possible to minimize this: computers having access to your CDE can be moved into a separate network which would be called “PCI environment” (or CDE). Computers (or staff) who do not need to have access to the system which holds card data, they can be considered outside of scope. The process is called: segmentation.

Reducing the scope, or if put this different way — having less computers with access to your business system, would mean:

  • Lower SIEM solution cost
  • Less activity logged which means less to review daily, less alerts and easier management
  • Lower risk of breach

Proper scoping of environment would not only cost cheaper, but would also involve less maintenance and reduce the risk for your business.

Three components to secure web connection 101

This article is 101 into HTTPS.

Took me whole Sunday to understand how HTTPS, SSL/TLS, Certs and encryption works. At first, after ssllabs and ssldecoder tests, I thought that issuing correct cert will enable correct SSL/TLS protocol and cipher suite. WRONG.

Even after reading how D-H can be cracked (another explanation of you are up to reading a lot), I though I need to have knowledge of cryptography to be able to configure secure connection. No, not needed at all either. Without going deep into cryptography either or having maths knowledge, you just need to know which algorithms are insecure to use. Anyway there are plenty examples to learn from or just copy into your config, as long as you know what you are doing. Anyhow, after you set up your website, you can do various tests as mentioned above and even this one too — From

Three components. Theory to Practice

This blog is proof of this article.

1. Secure protocol

Your web server is responsible for connection protocol between server and client. I would suggest to make this a first step to enable your server accept https connection over 443 port. I have done it on my Apache through ssl.conf by enabling SSLEngine and configuring vhost to listen on port 443. My CentOS server came with root certificate available out of box, so all worked — I was able to browse my page over https. Obviously, certificate is untrusted, as self-signed, hence tests failed (no A grade achieved and lots of errors) plus no system hardening done.

Done: traffic going through secure link

Flaws: weak cypher suites enabled which means information can be decoded, and untrusted certificate used which means MITM attack is potentially possible.

2. Configure cipher settings

In the same file, and same — server’s responsibility to use strong cipher suites, we configure server to use your preferred algorithms and not to use known weak ones. Web and news are full of information about, but you can also refer to tests. At the very least I disabled RC4, SHA1 and some others algorithms. You may enlist cipher suites in your config file or can go easy and quick way by mentioning to use only “high” and “medium” algorithms and disabling weak ones.

This is one of the shared examples you may use to accomplish first two steps, it is also good example showing you how to use it with Letsencrypt certs. Apache Configuration Example

Done: only strong cypher suites used, plus information going through secure link (as from above).

Flaws: MITM attack still potentially possible, error due to not trusted certificate.

3. Certificate

When we finally completed server side configuration, it is time to obtain trusted CA-signed certificate.

Short theory: certificate is file placed on your web server and required for client (browser or human) to “trust” that the webpage is genuine and safe to go into, send your password through. Of course you can use root or self-signed certificate which you can create yourself on the same server you are hosting your webpage, as long as you have SSH access to it; or any other server/PC where the required tool is installed. There is one more important thing to mention that issued certificate should be strong as well, make sure you avoid using SHA1 when creating your own certificate, use at least SHA256 instead. If you use your own self-signed certificate file, test will not be successful but connection and information exchange can be still secure.

As per community, Namecheap is one of good choices to go buy cert from. Normally you probably would buy certificate for your domain or subdomain, that would cost in range of £10 per year. You can only use it for your domain or subdomain. Or you could buy so called “wildcard” certificate for your whole domain, and it would work for any subdomains too, although if you are not business, the price is quite high enough.

Another way. There is new service called Let’s Encrypt with help of which you can quickly obtain 3-months certificate for free. On their webpage you can find easy and brief explanation how their technology works. Great technology and modern approach.

As this article is to clarify and explain on high level how this all works, I would give a good advice for organizing or designing configuration: what is in any way related to virtual host, move it into virtual host configuration. The configuration which will be used globally, only that configuration can remain outside vhost configuration. Please see good config examples.


Now you know simple theory and three major things-to-do behind setting up secure connection for your server. One moment I cannot stop recommending enough is: follow best practices when configuring systems and always look into system hardening. Use ssllabs and ssldecoder tests while in process of configuring your server to find what have you missed or what else can you improve. It will tell you any weak configuration related to any of three settings explained above.