We had another chance to interview one of our Information Security Auditors, Tim Cunningham, on some frequently asked questions about PCI DSS Requirements 3 and 4.

Here are the highlights from the interview:

Q: When we consider the concept of protecting stored cardholder data, what is the first thing to consider when planning compliance with Requirement 3?

An organization’s approach to PCI Compliance should be a top-down, management driven approach. When considering engaging a company to get a PCI ROC, ask, do we need to have cardholder data in our environment? Do we need to store it?

Do we need to have that 16 digit number in our system if we can truncate or hash it someway and still have it serve a purpose for us that we need. Can we serve our customers without storing this information? Does our process rely on this information? Why? How long?

Q: If I have encrypted backup tapes that have cardholder data that exceeds my retention period, do I have to go through the laborious process of removing that data?

The DSS is pretty specific about testing procedures – any place where it’s stored, it has to go away. This has been unwelcome news, but it is in compliance with DSS. Regardless of where it is “a quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention”.

Q: In regards to Requirement 3.2, but don’t I have to store the security code for recurring payments?

Sensitive authentication data is only used for authorization, and not stored and should be unrecoverable after authorization.

You don’t really need the CVV number to authorize and you cannot store it. However, DSS says we can’t keep that after the authorization process. Find it at POS machine logs, places you don’t anticipate it to be. It doesn’t appear in data flow diagram.

You can store a value or token or authorization code that represents authorization for recurring payments.

Q: Do people struggle with the concept of masking the number or changing processes that have historically required the full number?

I think for the most part, everyone understands the reasons why we should do this. It’s good practice, it’s required in the DSS, and clients typically feel good about adopting and implementing.

Q: Are there any common issues to consider when dealing with encryption methodologies?

If you do have a legitimate business need to store the 16 digit number, you must store it in an unreadable way – wherever it’s stored. There are several allowed methods for rendering PANs unreadable. You can using hashing, truncation, index tokens and pads, or strong cryptography.

Before you ask yourself how you should encrypt a PAN, ask yourself, do you need to store it? Don’t store the full PAN if you don’t have to.

If using strong encryption, reference OWASP cheat sheet

Q: Is Windows Bitlocker considered an OS independent encryption method?

Since the credentials are maintained independent of the OS, and it is authenticated prior to loading the OS, and it is a separate mechanism with separate credentials. I think that it passes 3.4.1 for disc encryption using Bitlocker.

Q: When using encryption you have to use keys to encrypt and keys to decrypt. We have to protect those keys as well by key management. Are there any common gaps that you find with these key management procedures?

This is one I find people wrestling a lot with. I would encourage people to use an integrated solution, a host security method of some sort who already addresses PCI DSS to help ease the load. I think the decision will be based on what’s being encrypted, and where it is. We can help present some solutions.

Q: According to 3.6.4, fully documented policies and procedures are required to demonstrate cryptographic key changes for keys that have reached the end of their cryptoperiod. A cryptoperiod is a defined period of time that has passed and/or after a certain amount of ciphertext has been produced by a given key. What is a reasonable cryptoperiod?

This is another commonly debated requirement. As noted, NIST Special Publication 800-57 is the recognized authority of key management and the idea of a cryptoperiod. I would encourage referencing that for industry best practices and guidelines. Consider volume of information encrypted, security function, strength of cryptographic mechanism, retention period of the data and other variables when analyzing and determining your cryptoperiod.

Q: What is considered early TLS?

It is TLS that relies on the SSL protocol (TLS v1.0). It is no longer recognized as secure due to security vulnerabilities in the protocol.

Q: What are some concerns to point out when it comes to wireless being in scope as part of the CDE?

Good question. For a service provider, if you don’t need wireless to push data across, then segregate that from the CDE to remove that from the scope. If you do need it, the DSS is very specific about what needs to be done to secure wireless at your organization.

If you have any further questions regarding Requirements 3 and 4, contact us today.

More Resources

PCI Requirement 3.7 – Security Policies & Operational Procedures

PCI Requirement 3.6.7 – Prevention of Unauthorized Substitution of Cryptographic Keys

Encryption & Key Management Webinar

Are you in the process of getting your annual audit performed? Are you preparing for your annual audit? We have compiled a list of the Top 10 Risks we most commonly find when auditing information security to help you better strengthen your own environment. Take a look at what our auditors have found to be common shortcomings and make sure you’re not making those same mistakes at your organization.

1. No Formal Policies and Procedures

Formal guidelines of policies and procedures help to provide your employees with clear guidelines of what’s expected of them. They define accountability for each employee and establish the necessary training.

2. Misconfigurations

Standards need to be applied consistently. Organizations should utilize benchmark configuration standards from a recognized entity such as: Center for Internet Security (CIS), International Organization for Standardization (ISO), SysAdmin Audit Network Security (SANS) Institute, and the National Institute of Standards Technology (NIST).

3. No Formal Risk Assessment

An assessment of risk should cover assets that are critical to your enterprise to continue business operations. This includes hardware, software, human resources, and processes (automated or manual). Some important things to consider when thinking about risk are the threats to your assets as well as the likelihood of a particular vulnerability being compromised. Threats can be both internal (employees or third-party contractors or partners) as well as external (natural events or social engineering). Developing a formally written strategic risk assessment can help to mitigate potential risks you may face.

4. Undefined Incident Response Plan

It is always important to have clear instructions on reporting procedures when determining incident response. Best practice says building a culture within your work environment that encourages the reporting of all incidents the moment they present themselves can help minimize damage.

5. Lack of Disaster Planning

We’ve stressed before the importance of planning for the inevitable disaster (whether it be natural or human). Planning for disaster is important in situations where written plans are available for others to follow in the event that key personnel are unavailable. Proactive arrangements should be made to care for the staff and to communicate with third parties. Walkthroughs and training scenarios can benefit organizations by ensuring that employees are properly trained in the event of a disaster.

6. Lack of Testing

The concept of testing applies to all areas of your security. If your security is not tested, there is no way to determine whether or not vulnerabilities are present. Conducting a third-party audit is not a replacement for internal testing, merely a great way to validate it.

7. Insecure Code

Developing secure coding is something we find a lot of companies struggling with. To develop secure coding, training must be implemented as well as specific development standards and quality assurance.

8. Lack of Monitoring/Audit Trails

Log Harvesting, parsing, and alerting methods must be determined to efficiently deal with massive event logs. The responsibility for review must be formally assigned as part of daily operations. Audit trails should be stored in such a way that system administrators cannot modify without alerting someone with an oversight role.

9. Data Leakage

We often forget all the places our data is located. How long should it be retained? How do we implement and verify encryption? How is access to data granted? How is it audited? These are all important components of your security environment, and if not done correctly, can keep you from complying with federal and industry standards and regulations.

10. Lack of Training

A lack of training can prove to be a striking blow to the security of your organization. Employers should recognize the importance of properly training all employees on safety and security best practices. Policies and procedures should be clearly determined and disseminated in every organization. KirkpatrickPrice offers several training opportunities to help train you and your company on the basics of security awareness, awareness for managers, awareness for IT professionals, and awareness for credit card handling.

It all begins with a Risk Assessment. Determining what your individual risks are is the first step towards mitigating those risks. KirkpatrickPrice is dedicated to helping you reach maximum security. Contact us today to find out how we can help.

SOC 1 (formerly SSAE 16) is the most commonly used means of third-party attestation. Have you been asked about a SOC 1 audit? Are you interested in learning more about how you can ensure SOC 1 compliance? The following webinar provides an informative overview of the SOC 1 framework along with SOC 2, HIPAA, PCI, and FISMA.

What Does a SOC 1 Audit Include?

SOC 1 is an audit and report on audit controls. It is performed by a certified CPA and is customized based on the services provided by an entity. Because a SOC 1 audit is based on risk, any objective and control that is relevant to an entity’s risk would be included in the audit report. For example:

  • Controls impacting your client’s financial security
  • Information security
  • Regulatory compliance
  • Contractual requirements

During a SOC 1 audit, an auditor’s job is to determine whether you do what you say you do. The SOC 1 audit will examine the controls that you have in place and if your organization is following through with them. The auditor will also determine if what you say you do is reasonable or not: does the auditor agree that the controls are good controls and are effectively designed to accomplish what you said your organization is accomplishing?

What is the Difference Between SOC 1 Type I and Type II Audits?

The primary difference between SOC 1 Type I and Type II audits is the audit period. A SOC 1 Type I and a SOC 1 Type II both report on the controls and processes at a service organization that may impact their user entities’ internal control over financial reporting. The main difference is that a SOC 1 Type I report is an attestation of controls at a service organization at a specific point in time, whereas a SOC 1 Type II report is an attestation of controls at a service organization over a minimum six-month period. The SOC 1 Type I reports on the description of controls provided by management of the service organization and attests that the controls are suitably designed and implemented. The SOC 1 Type II reports on the description of controls provided by management of the service organization, attests that the controls are suitably designed and implemented, and attests to the operating effectiveness of the controls.

To learn more about SOC 1 audits and other audit frameworks, download the full webinar. For more information about SOC 1 assessments and how KirkpatrickPrice can help you meet your compliance objectives, contact us today.

business people walking

Why is an internal audit program important?

The CFPB Examination Manual has become the ruling guidance for those in the collections space, and internal audit is a topic that can’t be taken too lightly. According to the manual, an effective compliance management system should have four interdependent control components:

  • Board and management oversight
  • Compliance program
  • Response to consumer complaints
  • Compliance Audit

When these four control components are strong and well-coordinated, a supervised entity should be successful at managing its compliance responsibilities and risks.

Let’s discuss the “compliance audit” component. Where exactly do you start with this?

We recommend you start with the following six core components of an internal audit program:

Step 1: Established Authority

The person in charge of performing the internal audit at your organization must have the established authority to do so. Without the necessary buy-in and support from the highest level of authority, you won’t have the authority or access to the information you need to get the work done.

Step 2: Operational Independence

This piece fits hand-in-hand with having established authority. You simply can’t audit your own work without a definite conflict of interest. The auditing party must not have any operational responsibility for this to be achieved. This may be seemingly difficult for smaller companies to accomplish, however, cross-training employees in different departments (such as accounting or HR) to audit another department is completely acceptable.

Step 3: Policies and Procedures

No audit can be successful without set policies and procedures dictating what and how to audit. Established policies and procedures need to outline the entire process. Fortunately, the policies and procedures you already have in place can serve as a type of QA that you can use as the basis for your audit. Are you doing what your policies and procedures say you’re doing? Are these processes adequate in mitigating risks?

Step 4: Framework of Controls

This piece is important for understanding what exactly you are looking for. What exactly should you be auditing? How often should you be auditing? Using a risk-based approach is key here to understanding where your risks are and making sure you have the right controls in place working to properly mitigate those risks. The audit process looks for ways to constantly improve upon the controls you already have in place. Understanding where and how your business deals with consumers, what consumers complain about, and all applicable laws are all key components to establishing a framework.

Step 5: Reporting Structure

Who does the internal audit department or staff report to? Communicating effectively the results of the audit is just as key as the actual audit itself. The distribution of the audit report should initially be disseminated to Executive Management as well as the Chief Compliance Officer.

Reporting to the appropriate personnel within the organization is important to ensuring that proper remediation steps are taken. The format of the report itself should take a couple of different forms:

  • A high level executive summary version of the report should be available for those on the outside of the organization, such as clients and potential clients.
  • A full-detailed version of the report should be available for distribution to all internally.

Step 6: Remediation Process

This final step is a review of the testing and the gaps that were found during the audit process. Steps taken to remediate any gaps should be tracked and documented to demonstrate what has been done to ensure the mitigation of any found risks.

Still have questions about developing your own internal audit program? Contact us today and let’s start building your internal audit program.

More Internal Audit Resources

5 Reasons Why Internal Audit is Important

Chief Compliance Officer Series: Constructing an Internal Audit Framework

CFPB Readiness Series: Developing an Internal Audit Process

Last week, we explored the process of writing effective policies. This week we will take a look at what goes in to writing effective procedures; the policy counterpart. Procedures are the process or task instructions on how, exactly, a policy is followed. They communicate the responsibility for a task or a process. Where a policy defines the rule as a guide to employees making decisions and mandatory rules that require enforcement, the procedure says “This is who is expected to do it, and this is how they are expected to do it.”

Components of Procedures

When you look at a procedure, what are some good components you would have within the procedure? Some of the required document components are:

  • The name of the procedure
  • The procedure reference
  • Records of audit, change, and review
  • The effective date
  • Who approved the procedure

When is the last time this procedure was reviewed? When is the last time it was changed? There needs to be an effective date saying this is when we, as an organization, instituted this procedure, and from this point forward we expect it to be followed. Is this procedure just a piece of paper or this this something that is really and truly followed by an organization? Who approved it? Do they have the appropriate authority to approve this procedure? Has it been clearly communicated to all employees? Is it being enforced? These are the components we, as auditors, look for when reviewing an organization’s procedures.

What to Include in Your Procedures Documentation

Looking more at the document itself, what are some things that should be inside the procedure document? A good general overview and summary of a procedure is helpful in defining the procedure before getting into the nuts and bolts of the actual procedure itself. A purpose statement helps keep you focused on what you’re trying to accomplish. What is the scope? Does it apply to all offices, an office, a division, or a special case? It’s also important to identify who the responsible parties are to help determine the people that need to be educated and involved. Some procedures don’t need to be sent to all employees if they don’t affect them. Be thoughtful and specific about who is responsible for this procedure, and that this procedure is sent to them.

Another important thing that should be included in a procedure are any forms and related references. If there are websites or databases that need to be visited, or forms that need to be filled out, they must be referenced in the procedure. You should always ask yourself, if you weren’t there, would you be able to hand the procedure to someone else and they be able to figure out what needs to be done?A good way to begin the procedure writing process would be to go to each department head and have them prioritize the functions they are responsible for every day, week, month. Then have them write out what that looks like to them on a daily basis. Once you have those lists, it’s time to add some flesh to it by defining the purpose, scope, responsible parties, etc.

Policies and Procedures Maturation

Maturing your procedures will take time. A lot of companies discover that it may take up to three years to fully mature your policies and procedures. Getting the initial procedures written down, getting the other components into place, and ensuring you have a procedure that someone can actually test and follow can be time consuming and may seem overwhelming. Here are some last minute tips to help the process along:

  1. Start at a high level and drill down layer by layer.
  2. Establish a defined scope that includes a starting and ending point of what the procedure covers.
  3. Consider all of the possibilities and decision points.
  4. Interview all of the responsible parties.
  5. Utilize flow charts and checklists.

KirkpatrickPrice helps organizations develop and implement policies and procedures. We offer general templates as well as guided development. For more information on developing your policies and procedures, contact us today.

More Resources

15 Must-Have Information Security Policies

Quickstart to Information Security Policies for Startups

SOC 2 Academy: Expectations of Policies and Procedures