PCI DSS Compliance Masterclass - Foundation to Mastery

By BHARAT NISHAD

Welcome to "Mastering PCI DSS:  Foundation to Mastery," the ultimate Book for anyone seeking to dive deep into the world of payment card industry security. This highly engaging Book is designed to provide you with a thorough understanding of the latest PCI DSS requirements, and equip you with the knowledge and tools necessary to ensure your organization/clients achieves and maintains compliance.

Drawing on the success of other highly-rated Books and programs, I have designed this Book to be both informative and captivating, utilizing real-world examples, expert insights, and interactive exercises to keep you fully immersed in the learning experience.

Whether you are an IT professional, security consultant, or business owner, this Book offers the perfect blend of theoretical and practical knowledge to help you become an expert in PCI DSS compliance. Unlock the secrets of payment card industry security, ensuring the safety and trust of your customers' sensitive data.

• Language: English
• Publisher: BHARAT NISHAD
• Release date: Feb 26, 2024
• ISBN: 9798223385219

Book preview

Copyright

Copyright© 2024 by BHARAT NISHAD.

Published by BHARAT NISHAD

PCI DSS Compliance Masterclass - Foundation to Mastery

Cover Design: BHARAT NISHAD

Cover Photo/illustration: BHARAT NISHAD

Layout & Design: BHARAT NISHAD

Bharat is an active supporter of authors' rights to free speech and artistic expression in their books. The purpose of copyright is to encourage authors to produce exceptional works that enrich our culture and our open society.

Uploading or distributing photos, scans or any content from this book without prior permission is theft of the author's intellectual property. Please honor the author's work as you would your own. Thank you in advance for respecting our author's rights.

The accounts in this book are true and accurate to the best of our knowledge. They may contain some speculation by the author(s) and opinions/analyses from psychology, criminology, and forensics experts. This book is offered without guarantee on the part of the editor, authors, or publisher. The editor, authors, and publisher disclaim all liability in connection with the use of this book.

Table Of Contents

Copyright

Table Of Contents

About

Intro

Acquisition Strategy

Code Analysis

Code Signing

Controls by Data Classification

Criticality Analysis

Cryptographic Protection

Cyber Threat Hunting

Data De-Identification and Anonymisation

Data Governance Structures

Data Purpose and Authority

Data Retention and Disposal

Defense-In-Depth

Information Tainting

Locked Rooms/Devices/Ports

Media Downgrading/Redacting

Physical Media Protection

Provider Assessment and Monitoring

Security/Privacy Architectures

System Safe Modes

Thin/Diskless Devices

Usage Agreements

Visitor Controls

PCI DSS Compliance Masterclass - Foundation to Mastery

Assembling

Assembling: Actions and Implementation

Assembling: Roles and Responsibilities

Assembling: Scope, Framework, Roadmap

Assembling: Governance Structures

Assembling: Trackable Metrics

Presenting: Overview

Presenting: Recency and Primacy

Presenting: Displayed Authority

Presenting: The Hero's Journey

Presenting: Tiredness and Distraction

Dealing with Objections: Introduction

Dealing with Objections: Flipping and Diagnosing

Dealing with Objections: UP Answers

Dealing with Objections: Progress and Loss

Dealing with Objections: Political Capital

Securing Buy-In: Introduction

Securing Buy-In: Implementation and Opinions

Securing Buy-In: Tailored Benefits

Securing Buy-In: Effort Shaping

Securing Buy-In: Future Lock-In

Full Run Throughs: Introduction

Full Run Throughs: Pitching PCI-DSS

Full Run Throughs: Pitching Vendor Assessments

Full Run Throughs: Pitching Data Governance

Full Run Throughs: Pitching Data Management

Conclusion

About

Welcome to Mastering PCI DSS:  Foundation to Mastery, the ultimate Book for anyone seeking to dive deep into the world of payment card industry security. This highly engaging Book is designed to provide you with a thorough understanding of the latest PCI DSS requirements, and equip you with the knowledge and tools necessary to ensure your organization/clients achieves and maintains compliance.

Drawing on the success of other highly-rated Books and programs, I have designed this Book to be both informative and captivating, utilizing real-world examples, expert insights, and interactive exercises to keep you fully immersed in the learning experience.

Whether you are an IT professional, security consultant, or business owner, this Book offers the perfect blend of theoretical and practical knowledge to help you become an expert in PCI DSS compliance. Unlock the secrets of payment card industry security, ensuring the safety and trust of your customers' sensitive data.

Intro

Hello, and welcome to the Security Controls chapter. This is an additional chapter, which is not part of the main Book, but it can be interesting for you to know how to use the different security controls. How to keep visitor logs, how to do code analysis of applications, and others. If you are a cybersecurity professional, it's not going to tell you a lot, but if you're not, then it can be a welcome introduction about how to use different types of security controls. So, let's dive in!

Acquisition Strategy

Let's talk about your acquisition strategy. This security control is about having a strategy, in terms of how you purchase systems and parts. For example, demanding a certain type of packaging, so that systems are not tampered with during transport. Or, making sure that you qualify your suppliers, so that not just anybody can supply parts or systems to you - they have to comply with certain requirements. And there are other techniques, but, at the end of the day, it's about making your purchasing - or your process for purchasing - systems or parts more secure, so that you have less vulnerabilities in your supply chain. Let's take a look. Let's talk about acquisition strategies, in terms of your supply chain.

Having an acquisition strategy relates to using certain processes and certain tools for protection, during the acquisition of systems themselves - or services, for that matter. That is, you want to prevent tampering with materials, replacement of materials, or other types of attacks, to purchased systems or components in your company. There are many different techniques that we can use, as part of our acquisition strategy, to actually protect ourselves. Some of the most common ones include, for example: First, using tamper-proof packaging, to ensure that nobody intercepts the package or tampers with it. Or, tracking and documenting all distribution lineages.

That is, where did this product come from? What are all the places that it has been to? Who has handled it? And what happened at each stage? Then, using blind buys, filtered buys, or supplier qualification. That is, blind buys are buying products or services without identifying the organization (or the purpose). Or, for example, in filtered buys, only opening up the purchase to quality suppliers, or having specific criteria for those suppliers - which is supplier qualification itself. Or a related one, which is just obscuring the end use of a system or component. That is, if a supplier knows, for example, that you are buying a router to install in a crucial network, with credit card data, attackers can target that delivery to compromise your credit card data.

But, by not telling them what it's for, any attackers who compromise the supplier still don't know the purpose, and they will have a very hard time prioritizing their attacks. And the goal of all of these techniques is to both not let the attackers know how important acquisitions are made - they literally don't know whether you are buying a hard drive to store credit card data, or public social media data, for example - but also to actually prevent them from attacking. The reasons for leveraging several different acquisition processes and tools - in short, the reasons for protecting your actual supply chain - are that many types of attacks can occur during the acquisition process itself.

And these attacks can include but they're not limited to, for example: The production of counterfeit or unauthorized products. That is, if you can't properly identify the products that you buy, or perform quality control, then the supplier can just send fake products - or somebody else. Or a related one, which is producing low-quality or unverified products. Again, if you have no quality control, then the supplier can send products that do seem like they do the job, but they're a little bit worse than usual. Or, they fail a little bit faster than they should. And you won't even realize it. Or, for example, theft or replacement of the products in transport, or tampering with the actual products during transportation.

For example, taking a hard drive on their way to a buyer, and installing a microphone, or a camera on it, for example. Or, for example, inserting malicious code, viruses, back doors, or others in products which are in transport. Same example. You take a hard drive during transport, you inject a rootkit in it, and you let it continue to the destination. As with other types of supply chain activities, there are two main risks here: The risk of disruption, and the risk of exploits. The risk of disruption is materials not actually reaching us, or not reaching us in time, and the risk of exploits is the materials being purchased being used as a gateway for actual attacks. And both can be very serious.

It's important to notice here that acquisition processes and tools are an important topic, both internally and externally. Both sides can do things to better protect the supply chain, and there are measures, which can be taken, for both cases. So, internally, you want to have extensive acquisition training and education. What I mean is: Do employees that receive materials test them? Ideally, in air-gapped machines, or controlled locations? Do they verify the packaging? Do they track the transportation documents? Do they even look at them? And, externally, this usually boils down to 2 things, which are: The acceptance criteria - that is, conditions that must be fulfilled for a purchase - and the incentives - that is, changing the price if the supplier complies with specific criteria.

Acceptance criteria - as the name says - are about actually accepting a supplier. For example, you can say, Our suppliers must document all transportation from the origin point to be our supplier. If you miss any stop along the way, you don't qualify. It's that simple. In terms of incentives, it's about changing the compensation structure. Saying something like, Suppliers will obtain a 10% bonus if all transportation is tracked, and all packaging is tamper-proof. They're both faces of the same principle. They have to get this done, one way or another. What are some examples here? The first are incentives. As mentioned. One of the most effective ways to make a non-compliant supplier start complying is to pay them more to do it.

For example, We will pay you 20% more if you use tamper-proof packaging, and you track all transportation, because the supplier now has something to gain by doing it. Then, remember that attackers can be very creative. Security throughout the distribution process is crucial, because attackers can be very creative at different stages. For example, posing as couriers, distribution workers, and others, to replace materials in transit - and, finally, remember that low-value materials can also be attacked. And they usually are a blind spot for many organizations. What I mean is the following: Some organizations ignore the low-value purchases - for example, $2 USB sticks - and they place lower security controls at entry for these, because they consider that they're less important.

So, if you buy $50,000 in hard drives, you'll have strict security controls, but if you buy maybe $100 in USB sticks, you will have fewer controls. But here is the key: Both enter your organization, and attackers know this. So they leverage precisely these low-value products, because they know that the purchases are less scrutinized. What are our key takeaways this time? The first is that an acquisition strategy is about processes and tools. That is, an acquisition strategy is about ensuring quality suppliers, and quality purchases, by using certain methods, and certain tools, reducing the vulnerabilities present in the purchase process. Then, there are many possible attacks that can be performed. That's the major reason for actual protection during the acquisition process.

Attacks can include tampering with products, replacing them, injecting malware, or just disrupting the supply chain - and many other variations. And, finally, there are both internal and external measures that can be taken. Ensuring safe acquisitions is both an internal and an external job. In internal terms, it's about training and education. And in external terms, it's about having acceptance criteria to work with a supplier, and incentives for them to improve. So, as we see, an acquisition strategy is a set of both internal and external techniques that helps prevent attackers from disrupting your supply chain, or even actually compromising your supplied materials!

Code Analysis

Let's cover code analysis. This security control consists of analyzing the code of your application, or a third-party application, to find security vulnerabilities. And you can do it both in the actual source code of an application, before it's compiled, or the binary code, while it's running. Let's take a look at both cases. Code analysis is a type of security control that analyzes an application, in order to find possible vulnerabilities within it - either by analyzing the source code, or the running application itself. This control is frequently used both for internally developed applications, to ensure that your developers are developing securely, but it's also used for external applications - for example, for the ones purchased from vendors, and that may not be secure. We can identify 2 main types of code analysis: static and dynamic.

So, static code analysis - or, formally, Static Application Security Testing, or SAST - analyzes vulnerabilities which are present in the source code. It actually reads the text and looks for patterns, in the code itself, that lead to vulnerabilities. On the other hand, dynamic code analysis, also known as binary code analysis, or, formally, Dynamic Application Security Testing, or DAST, analyzes the running program itself, to identify vulnerabilities in the actual binary. This is useful for when the source code is not available - for example, if you purchase an application that does not include the source code - and is also useful to test for environmental variables, such as startup arguments, which are not available in the source code itself.

So, as mentioned, static analysis works by identifying vulnerabilities which are present in the source code of an application itself. That is, we actually scan the source code, and we look for lines of code which may be problematic, and may generate vulnerabilities. This is very useful, because the application does not need to be compiled for vulnerabilities to be identified - we're just reading the source code. In other words, it allows us to detect a security problem at an earlier stage of the software development lifecycle - and due to this, this is especially used for in-house applications, because it allows us to identify vulnerabilities, and recommend improvements, before we even roll out an application.

We don't waste time compiling something which may be unsecured. This security control scans for specific patterns in the source code. That is, we look for specific lines, which are vulnerable to attacks. Then, it flags those lines and it recommends improvements. It identifies specific code patterns which may be vulnerable to SQL injections, to buffer overflows, cross-site scripting (XSS), and others. It identifies, for example, that a certain line of code may obtain an input, but that it does not validate that input. And, therefore, a vulnerability is present, because code can be injected in that input. And it has hundreds of specific patterns memorized, for hundreds of specific types of vulnerabilities.

Then, dynamic code analysis is the other face of the same control. It works by taking a running application and testing how it reacts to attacks in real time. This type of analysis is especially useful when we want to test applications for which we don't have the source code. For example, we purchase an application, and we just have the binary, and not the source code, but we still want to test it. It really is the opposite of static analysis. In static analysis, we have the source code, but we don't have the binary - because we don't want to compile yet - in this case, we have the binary, but probably not the source code. Dynamic analysis is also useful to test the security level of specific libraries which are involved in the compilation process.

You can analyze individual libraries in execution, and you can gauge whether they are secure. And, consequently, whether they can introduce vulnerabilities to other applications, which will include them - and which would, otherwise, be secure. So, this type of analysis works by taking a running application, or a binary, and running a predetermined set of attacks technically known as a dictionary of attacks, and it tests for all major types of vulnerabilities. For example, testing for buffer overflows - by inputting very long strings, or very big numbers - or, for example, testing for SQL injection - by using specific queries.

So, if static analysis looks at the source code to say You don't validate this input, then dynamic analysis actually tries to break that input, when the application is running, to verify that you don't really validate it. It tests the execution of the code. What are some examples here? The first is that most solutions are single, integrated ones. That is, although developers should be aware of security requirements, when developing, many commercial solutions do this testing all-in-one, generating feedback and recommendations integrated with the development environment, and having continuous integration, so this can be included into your DevOps pipeline. Then, there are usually different patterns for different types of applications - and most solutions take care of all of them.

So, sophisticated tools know what are the biggest vulnerabilities of mobile applications, of web applications, and many other profiles. And, finally, dynamic code analysis is the only way to test for certain elements that static analysis doesn't allow - such as runtime variables, or even runtime configurations. These are impossible to test in the source code, and can only be tested in a running application - because they're only present at runtime. What are our key takeaways here? The first is code analysis. Code analysis tools work by analyzing either the source code of an application - which is static analysis - or the running binary of that application - which is dynamic analysis. In both cases, to find vulnerabilities. Then, code analysis can be done with or without the source.

Static code analysis is great for when you have the source code, but no compiled application - such as, when you're developing, and you want to check for security requirements before you compile - while dynamic code analysis is perfect for the opposite situation, where you may have a compiled application, but no source code.

For example, if you've purchased it from a vendor. And, finally, both types usually have specific test batteries. Although their internal workings are different - so one tests the code, and the other tests the binary - in essence, both static and dynamic code analysis solutions