The people, process, technology equation

I often tell clients that I have never seen a firewall get angry at the boss and decide to quit coming to work.  I have, however, seen a number of instances were a firewall was misconfigured, or mismanaged by employees.  This truism emphasizes that companies need to ensure they employ a comprehensive approach that includes people, processes, and technology.

People: People are fallible and prone to mistakes.  Ensuring that your team has skilled, well trained, and effectively managed employees is the first key to ensuring that your security strategy can be implemented effectively.  As with all aspects of security, “trust but verify” should be the mantra for managing those responsible for security.

Processes:  When discussing security “consistent and repeatable” should be the goal of all processes.  The foundation of a solid process is the establishment of approved and enforced comprehensive policies and associated procedures.  Enforcement of the policies and procedures ensures that the tasks are being consistently repeated in an approved manner.

Technology: Firewalls, routers, IPS, and anti-virus solutions are little more than tools to support the security strategy.  Proper technology can make management of security more efficient and effective, but it requires skilled, trained, and properly managed people to configure and maintain to the maximum effect.  Ensure that your company is investing in the proper technology to tack the security issues of your organization.

If your organization struggles with security management or simply does not have the resources available to effectively manage an increasingly complex security function, where can you turn?  One of the answers may be a managed security service (MSS) provider.  By leveraging the people, processes, and technologies of a third party, your organization may be able to more effectively manage the particularly complex aspects of security such as firewalls, IDS, and logging.

How are you honing your people, processes, and technology in terms of security?

“If you can’t explain it simply, you don’t understand it well enough”

The PCI DSS is a set of 12 high-level requirements and about 250 (depending upon how you count them) sub-requirements that outline controls all companies which must comply with the standard are required to implement to protect cardholder data. Since first helping to write the PCI DSS’s predecessor (Visa’s CISP) in 2001, I have watched the document grow from 9 pages to 75 pages today.

Many companies struggle to keep up with the changes within the PCI DSS, and those who do often struggle with the nuances and cross references. To see the challenges with keeping abreast of the PCI DSS, just take a look at the “Summary of Changes” document on the PCI SSC’s website.  In that 20-page document there are over 220 documented changes from version 1.2 of the standard to version 2 alone!

Staying on track

I have had opportunity to work with hundreds of companies on PCI DSS assessments, training, and preparation.  I have also trained over 10,000 people worldwide on the PCI DSS while a QSA trainer and official PCI trainer for Visa.  Experience shows that companies that establish a structured, systematic project plan consistently move through PCI DSS compliance more efficiently and more cost effectively.

Unfortunately, the PCI DSS provides many opportunities to get off track.  Simple mistakes in interpretation or understanding can result in the inefficient use of time, energy and resources (money).  This can happen when companies inefficiently pursue controls that are not required.

One example that seems to arise with some frequency is that of encryption.  Recently, I listened to a very well respected QSA from another company state with absolute confidence that: “Encryption of cardholder data at rest is required to comply with the PCI DSS.”  This is a common but incorrect misstatement of the requirement.  PCI DSS requirement 3.4 does not state that encryption is required; it lists encryption as one option, but there are other methods to render data unreadable. This may seem minor, but this particular requirement can have significant implications for companies pursuing PCI DSS compliance.

Get trained on the standard

For those companies pursuing PCI DSS compliance, the best first step is to obtain comprehensive training on the standard. A QSA firm that knows the PCI DSS and implications well enough to provide professional training can guide you through the process.

More importantly, PCI DSS training helps get everyone on the same page, ensuring all team members understand the requirements, their intent, and how to implement controls consistent with the requirements. Finally, training will enable your company to demonstrate ‘buy in’ and commitment from management for the compliance project.  Often this is the difference between employees feeling forced to undertake a difficult project and feeling like they are part of an organizational effort to improve security.
When evaluating training vendors here are a few items you should consider:

1. PCI DSS Expertise – Does the trainer possess real world, hands-on PCI DSS experience and expertise?

2. Training Experience – Many people have knowledge of the PCI DSS.  Does the person conducting the training have experience delivering highly complex training to large groups of people?  How many people have they trained and to what type of personnel (e.g., Management, technical, etc.)?

3. Card Brand Experience – The PCI DSS is an industry standard, but the card brands (Visa, MasterCard, etc.) enforce compliance.  There are a number of operating regulations with which the companies must comply.  Without relevant card band experience, it will be difficult for a trainer to answer some of the more difficult questions, such as: “Why do we have to comply?”

4. Finally, ask to hear a sample of demonstration of their training.  PCI DSS is a complex and dry topic.  Having a trainer that is dynamic and knowledgeable will ensure that information is retained.

How is your company staying on track with PCI DSS? Have you taken part in training, and if so what advice do you have for others? Share your experiences in comments.

It is not uncommon to hear companies, when first told of their requirement to comply with the PCI DSS to respond with: “I don’t have to comply with the PCI because I am ______ (insert here…”not a merchant,” “too small,”, “don’t support ecommerce,”, we use “EMV,” etc.).  As more than one unlucky company has found, none of these answers are accurate.  Business model alone does not determine whether a company must comply with the PCI DSS.

A quick and easy way to understand whether or not a company must comply with the PCI DS is to use the following as a guide:

Any organization (merchant, service provider, credit reporting company, backup provider, etc.) that stores, transmits, and/or processes Cardholder Data must comply with the PCI DSS. 

It is important to point out that ‘compliance’ with the standard is different from the obligation to validate compliance with the standard.  Whether or not a company is required to validate is dictated by the individual card brands (Visa, MasterCard, Discover, JCB, American Express).  Even if a company is not required to validate, they are still required to comply IF they store, transmit, or process Cardholder Data.

Some of the confusion around compliance derives from the actual PCI DSS requirements document.  On page 7 of the PCI DSS Standard it says:

“PCI DSS applies wherever account data is stored, transmitted, or processed.  Account data consists of Cardholder Data plus Sensitive Authentication Data.”

The standard then further clarifies by stating that:

“…the Primary Account Number is the defining factor in the applicability of the standard. PCI DSS requirements are applicable if a PAN is stored, transmitted, or processed. If a PAN is not stored, transmitted, or processed the requirements do not apply.”  

Finally, on page 8 of the standard, the PCI DSS makes the point once again by stating definitively:

“The PCI DSS only applies of PANS are stored, transmitted and/or processed.” 

Since the term cardholder data is consistently used within the PCI DSS document, it is easier to use this term as the determinant of compliance requirements.  The primary account number (PAN, or the 16-19 digit number printed on the front of the card, among other places) is the defining element that determines whether the data is defined as cardholder data and therefore whether a company must comply with the PCI DSS.

Cardholder data consists of, at a minimum, the primary account number (PAN) and may include cardholder name, service code and expiration date if they are stored in conjunction with the PAN.

Since a PAN alone is considered cardholder data, it is easiest to remember that any organization that stores, transmits, or processes cardholder data (PAN alone or PAN plus any other elements) must comply with the PCI DSS.   Again, the PCI DSS stresses the importance of the PAN:

“The PCI DSS only applies of PANS are stored, transmitted and/or processed.” 

Another way to remember is to remember the following: “If an organization stores, transmits and/or processes the primary account number, then the PCI DSS is applicable and they must comply.”

Is your company required to be PCI DSS compliant? Why or why not? If so, are you ready for the new standards?

First, it is important to understand that a “policy” is NOT simply a document. The policy document is a record of the policy statement that was approved, and the document is a tool for disseminating the policy, as appropriate. The document should be a reflection of the policy that has been approved by management. The possession of a written document that articulates a series of ‘dos’ and ‘don’ts’ does not mean a company has a policy.  To be effective, a policy must be approved by appropriate authority, appropriately documented, disseminated to those to whom it applies, and enforced.

It is important to remember that writing and approving a policy is the easy part.  Ensuring adherence to the policy and enforcing the policy is the difficult part.  Quite simply, a policy that is not enforced will not be followed for very long.  People are inherently efficient, meaning that they (this author included) take  the path of least resistance.  Policies require difficult, often inefficient methods and interject administrative friction and inefficiencies into processes.  Without enforcement, policies will simply not be followed for very long.

Writing and documenting a policy is often much easier than implementing the policy.   Consider the following example: Company X passes a policy that requires all computer and IT users’ access to systems and data to be modeled on “need to know” and “model of least privilege” (standard access control model).  While seemingly simple, this policy statement implies much more.  First, it requires an audit of every user’s existing access privileges, as well as identification and documentation or their roles and responsibilities.  It also requires identification and classification of all types of data.  Using the data classification matrix and each user’s established requirements, each role then needs to have access levels documented and assigned based upon the “need to know” and “model of least privilege.”  As can be seen, a simple one line policy statement may have deep implications and be very difficult to implement.

After documenting the policies, it is important to ensure that your company adheres to the documented policies on a consistent, and repeatable basis.  This is a three-step process that can be described simply as SDC or:  “Show, Demonstrate, & Convince.”

1) Show that your company has a documented security policy that is up to date, approved by management, and appropriately disseminated.

2) Demonstrate to the auditor that your company is currently in compliance with the policy.  This is typically accomplished through showing existing processes.

3) Convince the auditor that your company has a history of following the policy by producing relevant documentation/evidence (ie…change control documentation) to show compliance over time. (last 3 months, last 6 months).

By using the Show, Demonstrate & Convince model with policies and departments, you can have confidence that your company’s policies are being enforced and followed.

How does your company enforce its security policy? What have you learned from the experience? We’d like to know.

Some of the more interesting (and heated) discussions arise when companies are asked to define data breach or data compromise as would merit disclosure.  More interesting is when companies are asked to define a suspected data breach.  For the purposes of PCI DSS, a suspected data breach is the key that requires notification.

Visa’s rules state that “suspected” breaches must be immediately reported or there could be potential penalties.  As stated in the Visa “What to do if Compromised” document: “Immediately report to Visa the suspected or confirmed loss or theft of Visa.” (emphasis added)

The suspected part is where companies are exposed to significant risk.   Many state breach notification laws also require notification if there is high likelihood of fraud or exposure of consumer data.

Consider the following example.  Suppose you, as CSO, are informed of a malicious software outbreak in the customer service department.  Does this alone require notification under the state breach notification laws, or relevant regulatory regimes such as Visa’s CISP?  Maybe and maybe not.  It depends upon a number of factors including access to data, data protections (i.e., encryption, tokenization), network segmentation, various laws etc.  In short, it is not easy to decipher, yet it is critical to be as accurate as possible.

Understanding what is, and what is NOT, a data breach or data compromise is the first step in defining your company’s data breach notification plan.  The reason it is so critical is in the title of this article.  Once you notify that your company has been breached, you cannot unring the proverbial bell.  Certainly, any company would absolutely hate to make an announcement that protected data was exposed only to find that, while they may have experienced a security incident, it did not impact sensitive data (PII, CHD, NPI, PHI, etc.).

Taking broader regulations into account

When evaluating your company’s notification requirements under the various card brand data protection programs (CISP, SDP, DSOP, etc.), it is critical that you not forget to consider the broader privacy regulations that may impact your organization. It is equally important that you work with your compliance group, legal team (don’t forget legal!), and the infosec & risk department to ensure you have a solid understanding of when, and under what conditions your company is required to notify of a breach or suspected breach.  Here are some basic definitions to use as a starting point. (Please validate these definitions with your own legal and risk departments):

Security incident/event: Any event that compromises the availability, accessibility, or integrity of any asset.  This includes systems, personnel, applications, services, etc.

Data breach: Any exposure of, or unauthorized access of sensitive and/or protected data to include PHI, PII, CHD, and NPI.

Suspected data breach: In the absence of direct evidence (identified fraud, or misuse of data, for example), any Security Incident in which it can be reasonable assumed that sensitive and/or protected data was exposed or accessed without authorization.

Remember, some state breach notification laws do not consider a breach of encrypted data as a trigger for notification while others do.  Simply encrypting data may not provide absolute protection against notification of a data breach event.

You can find a list of state breach notification laws at www.NCLS.org

In addition, AT&T’s PCI Practice and GRC Practice can help your organization unravel the complexities of compliance.

If you found this article helpful, please share it using the social links below.

Consider a typical company with a large IT infrastructure.  On one end of the spectrum is the IT department. They are constantly being told that the goal is “five nines” (99.999%) uptime, faster systems, and greater access to data.  For this reason, the IT group is focused on uptime, efficiency, and convenience.

On the other end of the spectrum is the security group.  They demand that networks use multi-tiered architecture, two-factor authentication, and that data is tightly restricted based upon a model of least privilege and a need to know. These controls invariably interject administrative complexities and inefficiencies into the network and process for accessing data, thereby hindering the objectives of the IT department.

This opposition is both critical and necessary.  Unfortunately, if the company does not have a mechanism to enforce the required security controls, then the company will default to the path of least resistance, and security will be left by the wayside in exchange for greater efficiency and convenience.  Security is critical, but it is important to remember the following point:

Security introduces administrative and operational friction and decreases efficiency and convenience. This results in greater costs and less efficient operations. 

Consider a simple example of a firewall rule change.  The IT department (or whomever is responsible) decides that they need another port opened on the Internet-facing firewall for a new whiz-bang application that is being deployed.  They ask the firewall administrator to open the port, understanding that it takes less than five minutes to open a port on a firewall.

The firewall administrator informs them that, as per company policy, the requester will need to follow the following steps. First, the proposed change needs to be documented, evaluated and submitted for consideration by a change control committee.  A risk analysis is conducted and, if the change is approved, the change will be scheduled in the change control process which includes an implementation window as well as fall back procedures.

What could have been a five-minute change has now required multiple hours and involvement of several departments. It is likely that the change will not be made for well over a week, if not longer.  This process, however, is critical to minimize the impact of the change.

The “all” or “nothing” approach to security

Companies are faced with a delicate balancing act.  From a security perspective, the absolute best form of information security is to simply NOT be connected to the Internet, not use email, and implement NSA type controls.  The result would be that the company would likely go out of business rather quickly as it could not function effectively.

On the other end of the spectrum is complete access to all data and systems without any controls.  This is certainly an efficient model, but one that often results in a company being highlighted in the media after the inevitable data breach.

The challenge lies in balancing security and business needs in a manner that allows business to be conducted while minimizing the risk to the organization.  Regardless of how little or how much security is deemed necessary, to appropriately manage the risk it is critical to remember the following:

Without a documented, approved and enforced security policy, security will eventually erode and become subordinate to business needs (efficiencies).

Consistent, enforceable policies are key

Security requires consistent, repeatable controls.  It is not possible to ensure consistency or repeatability without documented processes.  More important than the policies is the enforcement of the policies.  If people do not feel there is a penalty for not following the rules, then the rules will slowly begin to fall by the wayside.  There must be buy-in from management and enforcement must be consistent and appropriate.  Finally, while we all like and trust each other, never forget the rule of security: trust but verify.

How do you navigate the balancing act between security and flexibility?

But Chris sees his job as more than just validating compliance. His team manages every audit with an eye toward larger payment security issues and how risk can be further mitigated, always offering further recommendations for improvement.

He came to data security via the military, serving first as an enlisted Marine and then as a Navy officer. With military specialties Marine Scout/Sniper and Reconnaissance Marine, and having seen combat in Somalia, Chris has been involved in numerous aspects of security, from data security, to physical security, and force protection. In data security, he continues to draw on those experiences, knowing that technology, standards and protocols are only part of the picture and that people represent the core problems and solutions of security. On one end of the technology is someone who’s trying cause harm, and on the other is an organization with limited resources trying to protect their assets. The challenge of security is to allocate resources the most efficient way possible to prevent a malicious person from doing damage.

He’s been on the frontlines of a variety of security battles, most recently on a ship in the Gulf of Aden, supporting anti-piracy operations for the maritime industry. Prior to that, he founded a qualified security assessor (QSA) firm,  conducting or managing over 100 assessments, and trainingover 2,800 QSAs worldwide. As the Visa Inc. CISP trainer, he was responsible for training another several thousand people on PCI-DSS and related topics.

Chris’s specialties include cyber espionage and risk management. He speaks, writes and blogs on these topics prolifically, and has been published in Transaction World, Secure Payments, The Counter Terrorist and PenTest magazines and on PYMNTS.com.

A huge fan of Teddy Roosevelt, Chris is inspired by Roosevelt’s Sorbonne speech from 1910, the source of the famous “Man in the Arena” quote (“It is not the critic who counts… The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood…”). He enjoys reading – his and his wife’s library includes 1500 volumes – and two of his favorite books are Richard Clarke’s Cyber War: The Next Threat to National Security and What to Do About It, and Empire of the Blue Waters about Captain Morgan’s pirate army.

He lives with his wife and their 3-year-old son in Park City, Utah.