Security Governance Program

Our previous article, Making sense of PCI DSS for online stores, introduces us to the 12 PCI DSS requirements and aligned them to their respective 6 objectives. While we focused predominantly on online stores, the PCI DSS standards apply to all businesses involved in the collection, storage and processing of credit card information, including the company selling the goods / services.

Whether its your favorite food truck vendor, automotive detailer or favorite online market place. PCI DSS standards do not discriminate, and “I don’t know” will not help post-compromise.

The Payment Processing World

Here is a high-level view of what payment ecosystems look like in the 21st century (source: business insider):

Every business that is part of the payment processing supply chain fits somewhere into the matrix, and must be familiar where their respective scope and responsibility as it pertains to PCI compliance.

The cardholder data environment (CDE) is comprised of people, processes, and technologies that store, process or transmit cardholder data or sensitive authentication data.”

PCI DSS v 3.2.1

Remember, PCI is wholly focused on protecting the entire payment card processing supply chain, and the business providing the service and good is a critical piece of that puzzle.

Your Organization Type Defines Your Responsibility

So you want to accept payment from customers, but what / who is involved in that process? More specifically, who does what?

The following table below provides a simplified explanation of four key organization types every business should be familiar with if they want to accept customer payments:

Category	Description
Merchant	A merchant is any type of business who sells goods or services.  Credit cards are the most common payment method used for these transactions.
Payment Processor	Manages the credit card transaction process. Processors can authorize transaction and works on merchants getting paid on time by facilitate transfer of funds.
Acquirer	This is the financial institution that maintains a merchant’s account in order to accept credit cards. Sometimes the payment processor and the acquirer are the same.
Issuer	This is the cardholder’s bank, responsible for paying the acquirer for approved card transactions and collecting payment from cardholders. he issuer, also known as the account issuer, or issuing bank, is the bank or financial institution who offers the credit or debit card to the consumer.  They underwrite the cardholder, set the credit limit, and issue the card agreements.

It’s important to differentiate between the four key categories of the payment supply chain so that you can understand where you organization fits. Knowing where your organization fits will help reduce the scope of responsibility for your organization.

The key to successfully complying with the PCI standards is to clearly define your scope, failure to do so can leave you extremely exposed. If you are a merchant, this means that as an organization you don’t want to overlap with any of the other key categories. You do this by deferring the risk associated with the collection, storage and processing of any card data.

You reduce scope by identifying where and how data with card holder information flows through your network and systems. In an ideal world you DO NOT want any card holder information to flow through your network and system. This ensures your scope is as minimal as possible. Ways to ensure you do this is by NOT collecting payment information via emails, phones, chats or any other communication medium like tickets and solely using the payment pages and API’s provided by your processors for all payment collections.

Regardless of the type of organization, PCI DSS applies to you if you accept credit card payments.

Tips to Help Consumers and Businesses Reduce Scope and Risk

Trying to make sense of some of this can be tough, to help we share a table of real-world examples that can be treated as triggers for both consumers and businesses alike.

Consumers can use them to asses their own risk (e.g., Do I want to share my data with this merchant?) and businesses can use them to understand how “scope” works with compliance.

Type	Description
Physical Payment Form	If an organization asks you to fill out a PDF with your credit card information, scan and return it, it’s highly unlikely they are not PCI compliant. As a consumer, be very careful using this method. As a business consider updating your processes so that you can use payment collection forms provided by your processor.
No HTTPS	HTTPS is synonymous with online websites these days, while it doesn’t secure the website, it does secure data in transit. If an organization is asking you for payment information via a form that does not have HTTPS they are not PCI compliant. This means they are not taking care of your data as it transfers from your browser to their servers. Businesses that choose to collect this data need to ensure it’s transferred securely, HTTPS facilitates this.
Requesting Card Information via Communication Mediums	In 9 out of 10 instances, an organization that is requesting credit card information via one of many communication mediums (e.g., email, chat, phone, text, slack) are not PCI compliant. Many organizations don’t realize that the minute they do this they immediately expand their scope and now introduce a requirement to document and implement controls to secure those platforms (that rarely happens). As a business, do everything you can to train your team not to leverage any medium outside of the payment pages to collect information. This includes phone calls and virtual terminals, the minute you collect information via a sales call, or support engagement, it immediately broadens the scope to the phone service and the machines collecting the data.

If you have any questions, feel free to let us know at sales@coldpath.net.

A recent Nilson Report shows that payment card fraud losses reached $28.65 billion worldwide in 2019, with the US topping the list of most fraud-prone countries. We’ve also seen explosive growth in card fraud activity throughout the coronavirus pandemic as businesses move toward reducing their physical footprint and ramp up their businesses online.

Despite this, only 30%, or less, of organizations are PCI compliant. Why is this? What makes the PCI DSS framework so elusive to online stores?

This article will work to demystify the framework, making it more consumable to a) understand it and b) leverage it as a way to establish an appropriate security program for your online store.

---

With six goals and 12 requirements at the heart of the framework, compliance with PCI DSS ensures protection to payment card data. It does this by establishing technical and operational requirements for all supporting systems, and personnel, responsible for processing, storing or transmitting any element of the cardholders data. Yes, this means all merchants, regardless of size have a compliance obligation.

Failure to align all elements associated with your payment card operations with the applicable PCI DSS controls increases the potential risk for malicious or accidental actions leading to a breach or loss of your customer’s payment card information (this includes sensitive data that is printed on a card, chip data, etc..).

The 6 Goals (Objectives)

We will begin by outlining PCI DSS’s central goals, objectives, before moving into an overview of the different requirements. We always start by looking at the objectives because they provide a blueprint of what the framework is trying achieve, and in the case of PCI DSS it provides an outline from which the requirements will be structured from.

It helps better digest the requirements as it groups them according to the desired end-state. This makes it consumable to organizations, and provides a a sensible framework that can be used to establish an organizational security program that extends well beyond the online store.

6 PCI DSS GOALS

Goal	Description
Build and Maintain a Secure Network	Establish and maintain a secure network and system in order to ensure that payment transactions are processed in a robustly secure network. To achieve this, firewalls must be established to protect cardholder data and these firewalls must be effective without causing inconvenience, such as slow processing times, to cardholders.
Protect Cardholder Data	Protection of stored cardholder data with the needed steps taken to secure against hacking including securely encrypting data that is transmitted through public networks.
Maintain a Vulnerability Management Program	Establishing a vulnerability management program which includes frequently updating anti-virus software, anti-spy software, and other anti-malware solutions in order to protect against malicious hackers.
Implement Strong Access Control Measures	Restrict and control access to system information and operations. Cardholder data should not be provided unless it is required to effectively carry out a transaction and each person who uses a computer in the system must be assigned a unique and confidential identification name or number.  This includes protecting physical cardholder data as well as data submitted electronically.
Regularly Monitor and Test Networks	Constantly and consistently monitor and test to ensure that all security measures are in place and working effectively.
Maintain an Information Security Policy	Maintain a policy that addresses information security for all personnel.

The Requirements

You will notice in the table below that all requirements are aligned appropriately with their corresponding goal. This makes it especially clear to the organization why they are being asked to do something. The PCI SSC goes on to highlight the importance of incorporating these requirements into “business-as-usual” (BAU) activities as part of an organizations security program.

The reality is that for most online stores, this is most probably the only security program that exists within the organization. The good news is the same objectives, and some of the corresponding requirements, can be broaden beyond the scope of your online store and leveraged to build a more comprehensive program (more on this in a different article).

The 12 PCI DSS Requirements and Their Relationship to the Goals

Goal	PCI DSS Requirements
Build and Maintain a Secure Network	1. Install and maintain a firewall configuration to protect cardholder data 2. Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data	3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program	5. Use and regularly update anti-virus software or programs 6. Develop and maintain secure systems and applications
Implement Strong Access Control Measures	7. Restrict access to cardholder data by business need-to-know 8. Assign a unique ID to each person with computer access 9. Restrict physical access to cardholder data
Regularly Monitor and Test Networks	10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes
Maintain an Information Security Policy	12. Maintain a policy that addresses information security for employees and contractors

The thing to remember about these requirements is that they don’t “all” always apply, it’s ok to identify those things that are not-applicable, and it’s also ok to introduce compensating controls where applicable.

We also like to place emphasis on the goal itself, and while we might ensure each requirement is addressed, we always go back to the intent and ask ourselves – “What does this not address as it pertains to my environment?” We find this to be especially helpful, breaks us from the “checklist” mentality and ensures that we’re being honest with ourselves and the environment being secured.

---

In this article we stay broad, intentionally. The topic of PCI DSS is a mile wide and mile deep. But, we did want to take a minute to start with the basics before diving deeper into each area and how they apply to the online commerce world.

We encourage all readers to familiarize themselves with the specific controls that support their particular requirement by visiting the PCI SSC website www.pcisecuritystandards.org/. Although the expected release of PCI-DSS 4.0 is for mid-2021, the core goals and requirements will remain unchanged. 

The advent of e-commerce began mostly in 1995 with Amazon and AuctionNow (eBay). This was the beginning for payment gateways, payment aggregators and other payment support.

Since, there has been a continuous increase in demand for online purchases. It has created a substantial online payment space.

These days, online stores not only use the traditional payment gateways, but they’re also equipping themselves for future technologies. Introducing innovative payment methods, such as developing technology to embed payment-card information into the SIM card of cell phones, hardware device-based payment methods, contactless RFI based secure payment method, chip and PIN-based embedded smart cards shortly; there’s a lot to keep abreast of in the payment processing space.

Technologies Demand Improved Security

While businesses have adapted to new technological advances, they have not always applied the same level of energy into the security of those same technologies. Modern criminals recognize that an organizations desire to streamline a customers experience often dwarfs their desire to ensure it is secure. This translates into vulnerabilities being introduced, often unbeknownst to the business owner. That’s where things like PCI DSS can help.

About PCI DSS

In 2004, the payment card industry (PCI) recognized the importance of secure payment card operations and introduced global data security standards. This is referred to as the Payment Card Industry Data Security Standard, or PCI DSS, and applies to organizations that handle payment card data.

PCI provides a baseline against the Cyber Security, Information Sec, and Physical Security domains. The PCI DSS’s focus is to ensure that the Confidentiality and Integrity of the payment card data and supporting Information Systems are protected.

Why Online Stores Should Consider PCI DSS Compliance

Although PCI DSS is not law, it is a standard for all organizations handling credit card information and is mandated by the major credit card brands (i.e., Discover, Visa, MasterCard, AMEX).

Several countries and US states are starting to implement “PCI-like” laws to help protect consumers. In 2007 Minnesota enacted the “The Minnesota Plastic Card Security Act” and in 2009 Nevada enacted law that requires all businesses in its state to be compliant with PCI DSS in any instance where card information is collected.

With that in mind, there are several benefits online stores should be aware of to being PCI DSS compliant:

1. Improved Loss Prevention Foundation:

At the core of a businesses responsibility is to prevent the loss of money and company resources (e.g., customer data, proprietary information, etc..). A business, regardless of size, has a responsibility to reduce the potential security exposure and work to minimize the affects of a compromise if it does occur. Not doing so, can be costly to an organization.

For example, a compromise that includes a customer sensitive card information can lead to significant regulatory fines. These fines currently vary between $5000 to $100,000 per month until the merchants become PCI DSS compliant. It can also include being banned by various card providers.

Failure to prioritize things like a data protection program increases the risk of a compromise of personal data processing operations.

Some other potential business costs may include the following:

• Forensic Investigation Costs;
• Non-level one merchant gets defaulted to a level one merchant (ie.., it results in yearly onsite audits);
• Merchant may be charged for card reissue;
• Loss of ability to accept payment cards;
• Increase transaction costs;
• Removed from listing by payment brands;

Depending on how you look at your business, the cost savings could be interpreted as a return on security investments (ROSI) but in the world of security we prefer to think of it more as minimizing and improving loss prevention strategy.

2. Reducing Reputational Damage Control:

Many businesses have fallen victim to data breaches. A few high dollar value data breach cases were reported for Canva, Target, eBay, Equifax, LinkedIn, MySpace, Yahoo.

In early October of 2013, Brian Krebs, a security blogger, reported (https://krebsonsecurity.com/2013/10/adobe-breach-impacted-at-least-38-million-users/) that the data breach at Adobe “appears to include more than 150 million username and hashed password pairs taken from Adobe.” This had also exposed customer names, IDs, passwords and payment information.

Within a couple of years, Adobe had to agree to pay millions in legal fees and settlement claims of violating the Customer Records Act and unfair business practices. 

It was a breach of customers’ trust, which resulted in significant brand damage, directly impacting their share price and brand.

Given that payment card data is deemed personal data, and most data privacy legislation requires that businesses notify the affected people and the regulators, a public notice had to be sent out in this case.

Setting a “company-level tone” of security by default/security by design is an attempt toward protection against such data breaches.

3. Avoid a High-Risk Label

Post-breach, a business is required to carry out a forensic investigation to identify the root cause and is needed to invest heavily in the enhancement of their security defenses. The Card Brands escalate the businesses’ status to a high-risk (level 1) entity and subject them to a minimum of a 3-year onsite report on compliance (RoC) assessments.

The Regulators investigate the cause of the data breach and levy a fine. As seen in breaches like at Equifax, Morrisons Supermarket, Marriott, a business may also be subjected to private litigation.

4. An Organizational Security Framework

PCI DSS Controls Framework layers create an integrated approach for the protection of card payment channels. Fortunately, the PCI DSS heritage has a precise alignment with other cybersecurity controls frameworks.

Lessons learned from the PCI DSS integrated controls provide global data security standards defense of the business environment. For small online businesses especially, PCI DSS provides a basic framework from which an organization is able to build their security program.

5. Preparation for the Future

The PCI DSS is ever-evolving in accordance with new technologies and threats, with updates in security standards and practices; by being compliant, the merchants can enforce the most up-to-date processing practices for sensitive data processing business operations. This further enhances the Brand and protects the Reputation of a business while reducing risks of a breach of sensitive data assets or sensitive data processing systems.

---

The most historical data-breaches could have been avoided by adopting the “security by default” model.

The Use of Payment Card Industry Data Security Standards (PCI DSS) should be regarded as enhancing one’s business and not an annual “checkbox” audit. Handling highly sensitive client information is a huge responsibility and should be taken seriously.

All businesses, regardless of size, handling credit card information have a compliance obligation. While not all do, we hope this article helps highlight some of the other business specific benefits that help organizations of all sizes mature their security program.

Over the past decade we have helped countless organizations respond to security incidents around the world. There is a common theme each time, with exception to large enterprises with an established security team, most small businesses have no idea where to start.

The following article will help expand on some of the lessons we’ve learned over the years. It will help provide the practical recommendations that we have used to help guide companies through their most vulnerable period.

---

This guidance will be most valuable to organizations that fit this criteria, but there is a lot of value that micro-businesses can also take from this.

Total Revenue	$1M – $20M
Total Employees	< 500
CISO / Security Leader	No
Security Team	No, or < 5
Security Governance	No

---

Incident Response Foundation

The key to responding to an incident is having a basic foundation from which you’ll operate. For a small business that has never experienced a compromise before, you’ve likely never felt more vulnerable. A foundation will remove the emotion from the equation, and help you function rationally.

The minute you realize you have been compromised there are a series of questions you should immediately ask yourself, your team:

What is the scope of the compromise?	Understanding the scope of the compromise will help you figure out your response, and who needs to be involved. You won’t always know the answer up front, but it’s a question you’ll want to continuously ask. Note that scope will change through the entire process. You might realize the scope was not as bad as you initial though, but it might also be a lot worse. The big question that should be at top of mind: 1. Have customers been affected? 2. Has PII been affected? These two questions will have implications both for privacy and data breach laws across multiple jurisdictions and regulatory bodies (depending on industry).
Who is taking ownership?	If everyone is leading, then no one is leading. You need to assign roles and responsibilities during any compromise. Who is the one making the decisions? Who do I go to for information? One of the biggest mistakes executives make is assume they are in control, and they have the need to work directly with the operators. They MUST know what is happening every minute! This can’t be further from the truth, as a leader you are definitely a stakeholder but you’re not necessarily the operator in charge.
What is the communication cadence and medium?	Identify how information will be communicated to all the stakeholders. Will you use an asynchronous form of communication via a medium like Slack, Teams? Will you use email? What will the communication frequency be? Will you do updates every 30 minutes? every 60 minutes? When must information be shared?

Incident Response Work Streams

The minute you become aware of an incident, it should be all-hands on deck for those teams that have the ability to make a difference. If your team can’t make a difference, then your responsibility is to get out of the way.

Clearly assigning ownership will help with this process. This person should function as the buffer between the stakeholders and operators. They will also be responsible for managing the various streams of work that must kick-off the minute a compromise is identified.  

The table is not designed be exhaustive, but it is meant to provide a foundation from which any organization can start regardless of industry.

Ok to Run Parallel Work Streams

Most of these jobs can be performed in parallel.

For example, one step that a lot of businesses often forget during the initial phases is to enlist the help of law enforcement and their insurance provider (assuming you have Cyber Insurance). In the US for example, you can engage your local FBI office depending on the scale of the impact.

Another great example is communication. Communication itself can have a series of other streams and can be divided between internal and external communications. While the technical teams begin their investigative process you can have a separate team start preparing artifacts for best and worst case scenarios so that they are ready once the information is available.

Security Breach Notifications Laws / Rules

One of the biggest things you want to be cognizant of are the various laws that exist across different jurisdictions around data breaches and your responsibility to notify partners, and customers. It’s why understanding the scope of the compromise is critical.

In the United States, all 50 states have their own legislation that you have an obligation to confirm with. The best resource we have found to stay up to date with the changes is the National Conference of State Legislatures.

Additionally, organizations need to be considerate of their industry and their obligations under whatever regulatory body they have to conform too (e.g., PCI DSS, HIPAA, ISO 27001, FISMA, etc…).

Handling the Incident

The steps involved in handling an incident requires its own article, but in the interim I would refer you to a great guide by the National Institute of Standards and Technology (NIST) on Computer Security Incident Handling.

In this guide they outline four very distinct phases of the incident response life cycle:

I like this guide because it is simple, and practical. Something, any organization can easily follow, but still highly effective. It also highlights one very critical principle – security is a continuous process. Most importantly, it highlights the importance of post-incident activity in which you learn from what has happened and improve your security program.

The Chaos of Incidents

We can say without a doubt that in every incident we have handled over the past decade, there is always this feeling of dismay amongst the companies we work with. It doesn’t help that they always happen in the middle of the night or right as you’re going on holiday. You will also find yourself frustrated with mistakes you made, or information you don’t have (secret: you will never have enough information).

Know that this is all normal, and expected behavior.

This article will help you orient yourself. It should provide your organization a basic foundation from which you can lead your team through whatever incident you’re facing.

A framework should provide the underlying structure from which we built our security governance program.

Consider a home. Regardless of the type of home, they all have a similar framework. The framework keeps the house together and defines the basic structure, it starts with the foundation on which the house will sit. From there, the developers and architects build and expand it into something that fits their specific requirements. Without a basic framework, the house will collapse, the same applies to your organizations security program.

The security problems we face today are more often than not attributed to human behavioral problems, more so than technical ones. We invest a tremendous amount of energy into the latest technologies, deploying controls designed to mitigate risk, and yet we all continue to suffer from compromises. It’s not that the technologies don’t work, but rather that our approach is flawed; it lacks the structure required to adequately account for the emerging threats.

Attackers are successful not because we’re technically incapable, but because we are behaviorally weak.

Tony Perez | @perezbox

Something I learned at GoDaddy / Sucuri was that the tools we built (e.g., CDN/WAF/Backups/Remediation) were one piece of a larger puzzle. It’s not that our product wasn’t effective, but that the businesses leveraging the products lacked a basic understanding and appreciation for basic security principles. Tools would be employed with no structure in place to define why they are being deployed.

Take into consideration the organization that deploys a Web Application Firewall (WAF) to mitigate external threats by virtually hardening and patching at the edge. Sounds fancy, right? And technically works great! Until you learn that the same organization doesn’t block direct access to the server. In other words, an attacker can access the site directly, bypassing the defensive control.

We have to do a better job of bridging the divide between the knowledge that today’s webmasters have, and those that they require to effectively manage their websites security. We do this by starting with the basics – let’s create a basic Website Security Framework that any organization, regardless of size, can employ.

A Basic Website Security Framework

The basis of this framework is not new. It’s borrowed from the Framework for Improving Critical Infrastructure Cybersecurity, developed by the US National Institute of Standards and Technology (NIST). The idea is to educate users on a framework that already exists and can be easily leveraged for your organizations website security needs.

It is built on 5 core elements: Functions, Categories, Subcategories, and Informative References. Their relationship is as follows:

The functions are designed to organize the key security domains you should be considering. Keep the functions to these core five domains, do not over complicate.

As the illustration shows, the categories are subdivisions of the functions, and the subcategories subdivisions of categories. There is a one to many relationship between Functions and Categories, and Categories and Subcategories. The informative references have a one to one relationship with the subcategories, they are important to ensure that everyone is aligned with the exact steps being leveraged for each control and action.

Improving An Organizations Security Posture

Before deploying security solutions into your stack ask yourself what your general disposition is towards security. The framework above is designed to help you in this process.

As you consider the framework, think of security as a continuous process. The threat landscape is constantly evolving, your security posture should also evolve. Revisit the process at some interval (e.g., weekly, monthly, quarterly). It’s not about the frequency as much as the simple act of actually revisiting the process.

It can feel over-whelming when you first start thinking about a framework for your organization, which is why we recommend breaking it down into bite-size chunks. The easiest, and most difficult, is always the identification step.

In my experience, rarely does an organization have a good handle on what they really own. You can’t protect what you don’t know exists.

Things to consider through the process:

1. When was the last time you created an inventory of?
2. What is your technical stack?
3. Who knows what your technical stack is?
4. How many domains are part of your brands portfolio?
5. What does supply chain look like for your various digital assets?
6. What systems / services are you dependent on?
7. Where are they hosted?
8. Who has access these environments?

We do not get hacked because cyber criminals have an advantage over us, or because of the platforms we use. We get hacked because we lack basic knowledge, and in some instance complacent. We fail to take the basic precautions required when introducing a new property to the greater internet ecosystem.

ColdPath is here to partner with your organization and help navigate the process.