Some Important Industry Standards

Payment Card Industry Data Security Standard (PCI DSS)

The Payment Card Industry Data Security Standard (PCI DSS) is a worldwide information security standard that describes how to protect credit card information. If you accept Visa, MasterCard, or American Express, you are required to follow PCI DSS. These card companies formed the Payment Card Industry Security Standards Council to create the standard. The PCI DSS standard was released in 2004. The current version of PCI DSS is 3.0, released in 2013. There was a revision to 3.2.1 in 2018. The standard applies to every organization that stores, processes, or exchanges cardholder information.

NOTE

In February 2014, PCI DSS 3.0 was released in nine languages. PCI is considered a global standard.

The standard requires an organization to have specific PCI DSS security policies and controls in place. The organization must also have these controls validated. If you are a small merchant, you can perform a self-assessment questionnaire (SAQ). Large-volume merchants must obtain their validation through a qualified security assessor (QSA). Failing to validate, or failing the validation, can result in fines from the credit card companies. In extreme cases of noncompliance, you may be prevented from handling credit cards. Taking credit cards away could put you out of business.

The PCI DSS is an information security framework, so it contains a lot of technical requirements. Two have been a challenge for organizations to implement: network segmentation and encryption. PCI DSS strongly encourages isolating credit card systems at a network layer. For many open network designs and shared systems, this is a challenge. If you cannot segment the systems that contain cardholder data, PCI DSS requires that all systems on that segment must comply with PCI DSS. This means if you have 20 systems on a segment and one processes credit card information, all 20 systems should comply with PCI DSS standards. This could be expensive. The second major challenge is encrypting data at rest. Encrypting data in transit is common over the Internet and public networks. Encrypting data at rest, however, can be technically challenging and at times not feasible.

There are six control objectives within the PCI DSS standard. To be compliant, you need to include these control objectives in your security policies and controls. These control objectives are:

TIP

The PCI DSS materials are free and publicly available through the PCI Security Standard Council website at https://www.pcisecuritystandards.org.

  • Build and maintain a secure network—Refers to having specific firewall, system password, and other security network layer controls.
  • Protect cardholder data—Specifies how cardholder data is stored and protected. Also sets rules on the encryption of the data.
  • Maintain a vulnerability management program—Specifies how to maintain secure systems and applications, including the required use of antivirus software.
  • Implement strong access control measures—Refers to restricting access to cardholder data on a need-to-know basis. It requires physical controls in place and individual unique IDs when accessing cardholder data.
  • Regularly monitor and test networks—Requires monitoring access to the cardholder. Also requires periodic penetration testing of the network.
  • Maintain an information security policy—Requires that security policies reflect the PCI DSS requirements. Also requires these policies are kept current and an awareness program is implemented.

Clarified Statement on Standards for Attestation Engagements No. 18 (SSAE18)

The American Institute of Certified Public Accountants (AICPA) created the Statement on Standards for Attestation Engagements No. 18 (SSAE18). It was issued in April 2010, replacing the widely accepted auditing standard referred to as SAS 70. An SSAE16 audit examines an organization’s control environment. This usually includes an audit of the information security controls. An SSAE16 allows an independent auditor (called a service auditor) to review an organization’s control environment. The service auditor then issues an independent opinion in a cover letter. The actual audit report and opinion is provided to the organization being examined. Then SSAE 18 was released to further clarify and update the standard.

The popularity of an independent audit comes from the use of the opinion letters. Anyone trying to buy services from a vendor should ensure the data is protected. Organizations often request an opinion letter from a vendor to help build that confidence. Vendors often promote how well they passed an SSAE16 audit as a way of selling their services.

NOTE

The AICPA has free publications available at http://www.aicpa.org/Research/Standards/AuditAttest/Pages/SSAE.aspx.

There is a mutual benefit in having an independent audit performed. To the customer, it provides some assurance that their vendor’s control environment has been audited. And the vendor can say there’s been independent opinion that the customer’s data is protected. A key area of examination is security policies. Having well-defined policies and evidence of their effectiveness is required as part of an SSAE16 review.

Technical TIP

The opinion of the auditor depends in part on the scope of the SSAE16 review. When requesting the opinion, be sure to ask for the scope of the examination. This helps you understand the context of the opinion. For example, if you are concerned with whether a vendor can recover the system in case of an outage, be sure to ask whether backup and recovery controls were in the scope of the SSAE16 review. Simply obtaining an opinion that controls are working is not enough. You need to know which controls were tested.

Does an SSAE16 truly test if controls provide adequate safeguards to protect data? That depends in part on the type of SSAE16 audit performed. There are two types of SSAE16 audits:

  • Type I—This is basically a design review of the controls. The auditor’s opinion would note if the controls are designed well. The audit also looks at documented policies and procedures. The opinion states if the policies, controls, and procedures could meet the control objective stated. This doesn’t mean the controls are working. It simply says that if the controls are executed, then they should work.
  • Type II—Includes everything in Type I. In addition, the controls are tested to see if those controls are properly installed and working effectively.

Information Technology Infrastructure Library (ITIL)

The Information Technology Infrastructure Library (ITIL) is a series of books that describe IT practices and procedures. The collection of books originally came from a British government initiative. The first version was published in 1989 as ITIL v1.0. The current version as of this writing is ITIL v4.

ITIL has evolved over time from over 30 booklets on different topics to a unified IT service management (ITSM) approach. ITIL focuses on the entire service life cycle. It outlines goals, activities, tasks, inputs, and outputs. It is seen as outlining the best management practices for IT.

The ITIL official website states “ITIL provides a cohesive set of best practices, drawn from the public and private sectors internationally.”10 The concept behind ITSM is to use ITIL to optimize the IT infrastructure, lower costs, and improve quality.

FYI

ITIL is not free, and it can be expensive to buy the entire library. You can purchase just the ITIL books of specific interest. The official website has some free material at https://www.axelos.com/best-practice-solutions/itil.

ITIL has five core books called volumes. The following outlines each of the five volumes:

  • Service Strategy—Relates to how to define the governance and portfolio of services. This includes aligning to the business and IT finance requirements.
  • Service Design—Relates to the actual design of the service and controls. Here is where you take into account all the business and technology concerns. For example, risk management, capacity management, availability, information security, and compliance are among the elements considered.
  • Service Transition—Relates to the transition of services into production. For example, validation testing, release management, and change management are among the elements considered.
  • Service Operation—Relates to ongoing support of the service. For example, incident and problem management, and access management, are among the elements considered.
  • Continual Service Improvement—Relates to continuous improvement of the service. For example, measuring, reporting, and managing service level agreements (SLAs) are among the elements considered.