Chapter 7. Compliance Frameworks

This chapter covers the following topics:

Payment Card Industry Data Security Standard (PCI DSS)

Health Insurance Portability and Accountability Act (HIPAA)

Sarbanes-Oxley Act of 2002 (SOX)

Compliance may seem like a tedious effort designed to punish people who are responsible for security. The reality is these requirements are extremely critical to how an organization and its customers are protected against cyber attacks. Think about how often you’ve had to get a new credit card due to unauthorized charges being seen against that account. When I speak to large audiences about security in the United States, I ask the question, “How many people have had to replace a credit card due to unauthorized charges?” I always find more than half of the attendees have had their credit card stolen. Typically in other countries that have adopted smart chip technology, the number is very low. This brings up an interesting question. Are the citizens of the United States all doing something wrong when their credit card data is stolen? I say this because I’ve had my own credit card data stolen numerous times while living in the States. The answer is, probably not. Most likely, a business we spent money with failed at meeting compliance standards to secure our financial transaction, and the cost was our data being stolen. This failure happens all the time with large retailers as well as smaller restaurants. Think about how many privately owned restaurants probably have an old laptop that hasn’t been properly secured, yet it’s designated as the point-of-sale terminal. This is the reality we live in, and failures in compliance impact more than just the organization responsible for being compliant. I pointed out the smart chip enabled countries as the exception to this example since that technology dramatically reduces this attack vector.

The CCNA Cyber Ops SECOPS exam includes a focus on some of the most important compliance frameworks. This does not mean other frameworks do not matter. However, due to the limited scope in this program, the following frameworks are what you should expect to see when attempting the exam. The first framework covered, known as Payment Card Industry Data Security Standard (PCI DSS), focuses on any organization involved with financial transactions. It should be obvious why this framework was selected, as the majority of organizations are responsible for being PCI compliant.

The second framework you should expect on the CCNA Cyber Ops SECOPS exam is known as the Health Insurance Portability and Accountability Act (HIPAA). Simply put, HIPAA focuses on security for health care data. This is extremely important because the loss of this data could lead to identity fraud, leakage of unwanted private health conditions, as well as other negative outcomes. HIPAA targets health care providers. However, anybody with health care data, such as the human resources department of any organization, must comply with securing HIPAA-related data.

The last framework we will cover is known as Sarbanes-Oxley (SOX). SOX compliance states all publicly held companies are required to establish internal controls and procedures for financial reporting. The goal for SOX is to reduce the risk of corporate fraud.

It is important to know that in the real world, an organization hiring for security operation skillsets will most likely not care if you know the details of specific compliance standards—meaning they don’t expect you to quote line by line from a compliance manual. Most managers will train you on what compliance they must adhere to while on the job; however, they probably will expect that you are aware of the importance of compliance as well as have a basic understanding of the main compliance standards that apply to most organizations. For this reason, you should not expect the questions around compliance on the SECOPS exam to go into gory detail.

1. PCI DSS is designed to ensure which of the following?

a. Protect electronic health care information

b. Protect financial data such as the PAN, account data on a magnetic strip, and data on embedded chips

c. Prevent data loss

d. Prevent corporate fraud

2. What is the best answer for defining who must be compliant for PCI DSS?

a. Any financial transactions

b. Any merchant, processor, acquirer, issuer, or service provider that handles payment card processing, outsourced and third parties involved with payment card processing, and the home networks for the contractors responsible for maintaining PCI compliance

c. Any merchant, processor, acquirer, issuer, or service provider that handles payment card processing

d. Any merchant, processor, acquirer, issuer, or service provider that handles payment card processing along with outsourced or third parties involved with payment card processing

3. Which of the following PCI data must be protected?

a. Geographic location of a user

b. The payment amount

c. The full account number

d. A related health condition

4. Which of the following is not a high-level PCI DSS 3.2 requirement?

a. Encryption on all PCI-related servers

b. Implementing strong access control measures

c. Regularly monitoring and testing networks

d. Maintaining a vulnerability management program

5. Which is the best answer for addressing what must be PCI compliant?

a. Any device associated with financial transactions must be PCI compliant.

b. Any device and the network it connects to must be PCI compliant.

c. The system, version of software installed, environment, and contracted resources must be PCI approved.

d. The system, version of software installed, and environment of software must be PCI approved.

6. HIPAA is designed to protect which of the following?

a. PHI

b. e-PHI

c. PHI and e-PHI

d. PHI, ePHI, and PCI

7. What does PHI stand for?

a. Personal health information

b. Protected health insurance

c. Personal health insurance

d. Protected health information

8. Which of the following is protected by HIPAA?

a. The full account number in a financial transaction

b. Geolocation of a user

c. Health conditions

d. Full name of the patient

9. SOX does not apply to which of the following?

a. All publicly held American companies

b. Accounting firms involved with financial services

c. International organizations that have registered equity or debt securities within the U.S. Security Exchange Commission

d. Third-party service providers involved with companies responsible for SOX within the U.S.

10. Which of the following is not a security framework based on what PCOAB publishes?

a. COBIT

b. OWASP

c. ITGI

d. COSO

My personal feeling is PCI DSS needs to be better enforced. That way, in the future when I ask an audience about credit card theft, not so many people will raise their hands, showing that more people have avoided becoming victims due to a failure in a payment transaction. It is very possible that either the current standards are not being enforced properly across all organization types or there is a gap between what PCI DSS requires to be secure versus what is actually needed to secure PCI-related data.

Account data defined by PCI DSS 3.2 is shown in the following lists:

Cardholder data includes the following:

Primary account number (PAN)

Cardholder name

Expiration date

Service code

Sensitive authentication data includes the following:

Full track data (magnetic-strip data or equivalent on a chip)

CAV2/CVC2/CVV2/CID

PINs/PIN blocks

PCI DSS is very specific about what type of data is and is not permitted to be stored. This includes data that is encrypted, meaning data encryption doesn’t give you a reason not to follow PCI DSS standards. It is recommended that you contact the individual payment brand directly to fully understand what data is and is not permitted to be stored. Examples of payment brands are Visa, MasterCard, and American Express.

Table 7-2 illustrates examples of data storage regulations. Note that you most likely won’t have to memorize this level of detail for the SECOPS exam. However, that doesn’t mean it isn’t useful to have a decent understanding of PCI DSS.

Note the requirements referenced will be covered later in this chapter, as we review the 12 PCI DSS requirements.

Our focus will be on PCI Data Security Standard 3.2 (PCI DSS 3.2) being that it is the most current release. The major goals and aligned requirements are shown in Table 7-4, which reflects the latest standard. Once again, the SECOPS exam will most likely not dive into this level of detail around PCI DSS 3.2; however, it doesn’t hurt to be aware for your personal studies.

Testing for PCI DSS 3.2 follows 12 requirements and corresponding testing procedures to validate compliance. There may be other legislation and regulatory requirements requiring additional protection of personal information or other data elements based on laws, government regulations, and so on. It is important to be aware that PCI DSS does not supersede any legal requirements. Also be aware there are legal obligations to be PCI compliant.

It is important to be aware that using a Payment Application Data Security Standard (PA DSS) compliant application by itself does not make the entity PCI compliant. PCI DSS requires that the PA-DSS–compliant application be implemented in a PCI DSS environment according to the guide provided by the PA-DSS-application vendor. For example, we have seen security products that require specific features to be enabled or disabled before they are considered PCI compliant. Failing to follow those guidelines stated by the vendor violates the PCI DSS compliancy. The same problem could happen if a PA-DSS-compliant application resides on a network that isn’t following PCI DSS requirements, meaning that data leaving that application could be vulnerable. It is recommended that you validate with every vendor how its solution meets the current PCI DSS standards, including the approved version of software and the required configurations and controls. You can learn more about determining if a PA DSS applies to a payment application by reviewing the PA DSS program guide found at www.pcisecuritystandards.org. Trust us—we have seen the mistake of believing one is compliant with PCI DSS and later failing a PCI audit due to errors in deploying systems with PCI data.

In our experience, we find many PCI violations occur when an administrator sets up systems containing PCI data to auto-upgrade that could install a non-PCI-DSS-approved operating system. The downside of having PCI-approved software means there could be times the administrator is sacrificing more secure software due to that software not being “PCI tested and approved.” This is just one of the many situations where being compliant could potentially reduce the quality of security, hence why we continue to recommend that you use security standards that exceed PCI requirements whenever possible.

Let’s summarize the concepts in this section: You can’t just isolate a specific device or application when evaluating its PCI-DSS-compliance status. You must consider everything about it, including what is installed, where it’s installed, and what data it comes in contact with. A failure in any area of that system’s lifecycle or environment is a failure to be PCI DSS compliant.

We recommend that you design your network to have higher security standards than what is required by PCI DSS. This would include proper network segmentation of sensitive systems holding PCI-related data from the rest of the network as well as monitoring sensitive systems using a layered approach of defenses.

Requirement 1: Build and maintain a secure network and systems. The purpose of the following requirements is to enable security to reduce the risk of having a network containing PCI-related data compromised by a virtual attacker. For example, an attacker could breach a company’s network security and remotely take credit card data or other sensitive information. One would hope many of these security practices are enforced in order to avoid a breach.

1.1. Establish and implement firewall and router configuration standards. Document and diagram cardholder data flows across systems and networks.

1.2. Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.

1.3. Prohibit direct public access between the Internet and any system component in the cardholder data environment.

1.4. Install personal firewall software or equivalent functionality on any portable computing devices that connect to the Internet when outside the network.

1.5. Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters. This requirement enforces the general best practice of never leaving the default passwords on systems. This should be common practice and include more advanced authentication programs such as multifactor authentication and the use of passphrases versus passwords. You would be surprised how many times we have found default passwords on core network systems during penetration testing exercises!

2.1. Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.

2.2. Develop configuration standards for all system components. Ensure that these standards address all known security vulnerabilities and are consistent with industry-accepted system-hardening standards.

2.3. Encrypt all non-console administrative access using strong cryptography.

2.4. Maintain an inventory of system components that are in scope for PCI DSS.

2.5. Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.

2.6. Shared hosting providers must protect each entity’s hosted environment and cardholder data.

Requirement 3: Protect stored cardholder data. The focus of this requirement targets protecting the primary account number (PAN). Requirements include how PAN data is stored and practices to keep the area of storage protected from unwanted parties.

3.1. Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures, and processes. Purge unnecessary stored data at least quarterly.

3.2. Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.

3.3. Mask PANs when displayed such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN.

3.4. Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs).

3.5. Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.

3.6. Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data.

3.7. Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.

Requirement 4: Encrypt transmission of cardholder data across open, public networks. This requirement protects card data while it’s being sent over a network. The goal is to prevent man-in-the-middle compromises of the data, meaning attackers trying to capture the PAN data while it’s sent between parties such as a point-of-sale system to the credit card operations center. Requirements also limit the approved methods of communicating with PCI DSS data to tools that include the proper level of security. Tools such as social media and SMS are big no-no’s.

4.1. Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.

4.2. Never send unprotected PANs by end-user messaging technologies (email, instant messaging, SMS, chat, and so on).

4.3. Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties.

Requirement 5: Protect all systems against malware and regularly update antivirus software or programs. This requirement is focused on best practices for defending against malware. The target is host system antivirus and antimalware software, meaning this type of protection must always be updated and running to reduce the risk of this threat vector.

5.1. Deploy antivirus software on all systems commonly affected by malicious software.

5.2. Ensure that all antivirus mechanisms are maintained.

5.3. Ensure that antivirus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period.

5.4. Ensure that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties.

Requirement 6: Develop and maintain secure systems and applications. Requirement 6 establishes rules around how systems should be continuously evaluated for vulnerabilities as well as the process to reduce the risk of those vulnerabilities when identified. This one is important because everybody has vulnerabilities, so best practice is to continuously audit your network for weaknesses before a malicious party finds it and exploits it. The key is not only continuously enforcing this but how quickly you take action on vulnerabilities found to be potentially devastating to your environment. Hopefully anybody hosting PCI DSS data is following this best practice.

6.1. Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking to newly discovered security vulnerabilities.

6.2. Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

6.3. Develop internal and external software applications (including web-based administrative access to applications) securely.

6.4. Follow change control processes and procedures for all changes to system components.

6.5. Address common coding vulnerabilities in software-development processes.

6.6. For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.

6.7. Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.

Requirement 7: Restrict access to cardholder data by business need to know. This requirement is a summary of the least privilege concept, meaning only providing access to what you need to do your job. This is ideal to reduce the risk of exposing sensitive data to unauthorized parties because access is limited to only those who would actually need access to the data.

7.1. Limit access to system components and cardholder data to only those individuals whose job requires such access.

7.2. Establish an access control system for system components that restricts access based on a user’s need to know and is set to “deny all” unless specifically allowed.

7.3. Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.

Requirement 8: Identify and authenticate access to system components. This requirement complements Requirement 7 by enforcing proper identity and authentication practices to sensitive systems. Combining need to know and access control dramatically reduces the risk of exposing sensitive data.

8.1. Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components.

8.2. In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components.

8.3. Secure all individual non-console administrative access and all remote access to the CDE using multifactor authentication.

8.4. Document and communicate authentication policies and procedures to all users.

8.5. Do not use group, shared, or generic IDs, passwords, or other authentication methods.

8.6. Where other authentication mechanisms are used (physical or logical security tokens, smart cards, certificates, and so on), use of these mechanisms must be assigned.

8.7. All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted.

8.8. Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.

Requirement 9: Restrict physical access to cardholder data. This requirement looks at how physical security measures should be implemented to protect access to systems storing PCI DSS data. This complements the previous requirements that focus on digital access control practices.

9.1. Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment.

9.2. Develop procedures to easily distinguish between onsite personnel and visitors.

9.3. Control physical access for onsite personnel to sensitive areas.

9.4. Implement procedures to identify and authorize visitors.

9.5. Physically secure all media.

9.6. Maintain strict control over the internal or external distribution of any kind of media.

9.7. Maintain strict control over the storage and accessibility of media.

9.8. Destroy media when it is no longer needed for business or legal reasons.

9.9. Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.

9.10. Ensure that security policies and operational procedures for restricting physical access to cardholder data are documented, in use, and known to all affected parties.

Requirement 10: Track and monitor all access to network resources and cardholder data. Requirement 10 focuses on tracking who and what are accessing systems with PCI-DSS-related data. This is important for enforcing Requirement 7, meaning knowing that least privilege access level is being used by all systems.

10.1. Implement audit trails to link all access to system components to each individual user.

10.2. Implement automated audit trails for all system components to reconstruct security events.

10.3. Record audit trail entries for all system components for each event based on PCI DSS best practices.

10.4. Using time-synchronization technology, synchronize all critical system clocks and times and ensure that best practices are implemented for acquiring, distributing, and storing time.

10.5. Secure audit trails so they cannot be altered.

10.6. Review logs and security events for all system components to identify anomalies or suspicious activity.

10.7. Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.

10.8. Additional requirement for service providers only: Implement a process for the timely detection and reporting of failures of critical security control systems.

10.9. Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.

Requirement 11: Regularly test security systems and processes. Requirement 11 speaks to processes for regularly testing the capabilities and effectiveness of existing security systems. This complements Requirement 6 by not only testing security applications but also testing all forms of existing security. This truly is a best practice because attackers will evaluate any path to get to the data, making your weakest area of security the most probable place you will be hit.

11.1. Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis.

11.2. Run internal and external network vulnerability scans at least quarterly and after any significant change in the network.

11.3. Implement a methodology for penetration testing.

11.4. Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.

11.5. Deploy a change-detection mechanism (for example, file to alert personnel to unauthorized modification of critical system files, configuration files, or content files) and configure the software to perform critical file comparisons at least weekly.

11.6. Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties.

Requirement 12: Maintain a policy that addresses information security for all personnel. This requirement targets properly developing and managing a security policy. This includes training, the mission behind the organization’s security program, and the actual program used to enforce the previous requirements.

12.1. Establish, publish, maintain, and disseminate a security policy.

12.2. Implement a risk-assessment process.

12.3. Develop usage policies for critical technologies and define proper use of these technologies.

12.4. Ensure that the security policy and procedures clearly define information security responsibilities for all personnel.

12.5. Assign to an individual or team the information security management responsibilities.

12.6. Implement a formal security awareness program to make all personnel aware of the cardholder data security policy and procedures.

12.7. Screen potential personnel prior to hire to minimize the risk of attacks from internal sources.

12.8. Maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data.

12.9. Additional requirement for service providers only: Service providers should acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, as well as the extent to which they could impact the security of the customer’s cardholder data environment.

12.10. Implement an incident response plan. Be prepared to respond immediately to a system breach.

12.11. Additional requirement for service providers only: Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures.

The list that follows highlights the key PCI DSS concepts:

PCI DSS protects financial data, meaning the primary account number (PAN), account data on the magnetic strip, and data on the embedded chip. Most PCI SECOPS exam questions will test you on this.

PCI DSS compliance is mandatory for any merchant, processor, acquirer, issuer, or service provider that handles payment card processing as well as any outsourced or third parties involved with payment card processing.

PCI DSS 3.2 is very specific about what it means to be compliant. You must consider the system, version of software installed, and environment it resides in, regardless of how secure the system may appear to be even with data encryption or the latest version of software installed. That software must also be PCI approved.

PCI DSS does not supersede laws; however, there are legal and finical ramifications if compliance is not met.

PCI DSS 3.2 requirements, at a high level, are as follows:

Building and maintaining a secure network and systems

Protecting cardholder data

Maintaining a vulnerability management program

Implementing strong access control measures

Regularly monitoring and testing networks

Maintaining an information security policy

Next, we will review the health-care-focused compliance requirement known as HIPAA.

From a high level, HIPAA is made up of the following goals:

To provide the ability to transfer and continue health insurance coverage for millions of American workers and their families when they change or lose their jobs

To reduce health care fraud and abuse

To mandate industry-wide standards for health care information on electronic billing and other processes

To require the protection and confidential handling of protected health information

HHS developed the HIPAA privacy rule as a standard to protect certain health care information. This is why when you call a hospital and ask for health-care-related information on a person, they may say they can’t provide it due to HIPAA regulations. This privacy rule is also known as the Standards for Privacy of Individually Identifiable Health Information and is designed for protected health information (PHI). The privacy rule is the basis of another HIPAA rule focused on digital data, known as the security rule.

The HIPAA security rule applies to all health plans, health care clearinghouses, and any health care provider involved with transmitting health information in electronic form. Basically anybody who offers any health-related treatment, payment, or operations must be HIPAA compliant. It is probably obvious this impacts hospitals; however, it also impacts other organizations such as a business that does business with a health care provider, meaning I can’t access the health care records of my coworkers at Cisco based on HIPAA compliance.

The HIPAA security rule can be broken down into the following requirements:

1. Ensure the confidentiality, integrity, and availability of all e-PHI the organization creates, receives, maintains, or transmits.

2. Identify and protect against reasonably anticipated threats to the security or integrity of the information.

3. Protect against reasonably anticipated, impermissible uses or disclosures.

4. Ensure compliance by the organization’s workforce.

Rule 1 should be familiar to anybody who has studied for the CISSP exam. Confidentiality means information should not be disclosed to unauthorized people or systems. Integrity means the data should not be altered or destroyed in an unauthorized manner (in other words, the data must stay authentic). Availability means authorized people or systems should have access to the data.

Rule 2 and Rule 3 speak about due diligence, meaning being responsible to provide the proper security in order to protect health care data. This means if you know you have HIPAA-related data, you must provide the right level of effort in hardware and manpower to secure that data. For example, if you are breached and are found to only have a basic firewall as your security strategy, you most likely will be in violation of Rule 2 and Rule 3, meaning you should have invested more money and manpower into securing HIPAA-related data.

Rule 4 makes it mandatory for the entire workforce to be HIPAA compliant. For example, I do not work for human resources; however, I have the same responsibility as any employee within Cisco to protect HIPAA-related data. In summary, security is everybody’s responsibly. This is a very good rule.

The security rule requires an organization with HIPAA-related data to provide a risk analysis. The goal of this exercise is to do the following:

1. Evaluate the likelihood and impact of potential risks to e-PHI.

2. Implement appropriate security measures to address the risks identified in the risk analysis.

3. Document the chosen security measures and, where required, the rationale for adopting those measures.

4. Maintain continuous, reasonable, and appropriate security protections.

The HIPAA security rule has specific safeguards that are used to evaluate whether an entity is compliant. Entities must maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting e-PHI.

Let’s review each of the HIPAA security rule safeguards.

Security management process: How to identify and analyze potential risks to PHI and e-PHI as well as what security measures are used to reduce risks and vulnerabilities.

Security personnel: There must be a designated security official responsible for developing and implementing security policies and procedures.

Information access management: The idea of least privilege must be enforced, which means limiting users and disclosures of PHI and e-PHI to the “minimum necessary” based on what is required for the user or recipient’s role.

Workforce training and management: There must be the appropriate authorization and supervision of anybody in contact with e-PHI. The entire workforce must be trained in security policies and procedures. If a violation occurs, the appropriate sanctions must be implemented.

Evaluation: Periodic assessments must be performed to evaluate how the entity is meeting the HIPAA security rule requirements.

Facility access control: Ensuring only authorized access to the physical environment is permitted.

Workstation and device security: Implementing policies and procedures to enforce proper use of and access to workstations and electronic media with e-PHI data. This covers how e-PHI and the related system are transferred, removed, disposed of, and reused.

Device and media controls: Hardware and electronic media need to be tracked in and out of a facility and inventoried while within the facility.

Access control: Technical policies and procedures to only permit authorized persons to have access to e-PHI.

Audit controls: Hardware, software, and procedural mechanisms that can record and evaluate access and other activity within systems that contain e-PHI.

Integrity: Policies must be enforced to ensure e-PHI isn’t improperly altered or destroyed. Electronic measures must also confirm the integrity of the e-PHI.

Transmission security: Security measures to protect e-PHI in transit over an electronic network.

Person or entity authentication: Authentication ensures the person or entity is in fact who they claim to be.

Cisco has many resources and technical documents dedicated to helping organizations meet HIPAA requirements. You can learn more about how to meet HIPAA safeguards from Cisco by visiting the following website:

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Compliance/HIPAA/default.html

The list that follows highlights the key HIPAA concepts:

HIPAA is designed to protect protected health information (PHI) and electronic PHI (e-PHI). For the SECOPS exam, make sure you know what PHI stands for.

HIPAA applies to all health plans, health care clearinghouses and any health care provider involved with transmitting health information in electronic form.

The security rule focuses on e-PHI and is made up of safeguards.

There are administrative, physical, and technical safeguards under the security rule.

Key safeguard areas to consider are proper management and security personnel and policies, access controls, audit controls, integrity controls, transmission security, facility controls, and system controls.

The last compliance requirement we will review, known as Sarbanes-Oxley (SOX), is related to corporate fraud.

SOX applies to all publicly held American companies as well as any international organizations that have registered equity or debt securities within the U.S. Securities Exchange Commission. SOX also applies to any accounting firm or third-party service provider involved with financial services to the previously stated companies responsible for SOX.

Administrators responsible for SOX in information technology typically focus on a few sections of SOX-compliance regulations. The sections of interest are Section 302, Section 404, and Section 409. Let’s review each of these sections in more detail.

Section 302 requires the following to be in an annual report:

That signing officers have reviewed the report

That reports don’t contain untrue material or omissions in material

That financial statements and related information are current

That signing officers are responsible and have evaluated controls within the previous 90 days of the report’s findings

That any deficiencies in the controls as well as information on fraud are disclosed

That any significant changes in controls that could have negative impact on internal controls are listed

In regard of SOX audits, a SOX auditor will review the organization’s controls, policies, and procedures during a Section 404 audit. Typically an audit leverages a control framework such as COBIT. Organizations must be prepared to share collected logs to establish a proven audit trail that all access and activity to sensitive business material are accounted for. It is important to understand how critical logging and preparation are to meet Sections 404 and 409 for SOX. Many organizations invest a ton of resources dedicated to providing this type of data.

Here are a few terms you should be aware of in regard to understanding SOX compliance:

The Public Company Accounting Oversight Board (PCAOB) develops auditing standards and trains auditors on best practices for assessing a company’s internal controls. PCAOB publishes periodic recommendations and changes to the recommended audit process.

The Committee of Sponsoring Organizations (COSO) is an auditing framework. COSO publishes periodic updates to its internal control framework and serves as the basis for the auditing standards developed by PCAOB.

COBIT stands for Control Objectives for Information and Related Technology and is a framework published by ISACA. ISACA is responsible for guidelines for developing and accessing internal controls related to corporate information technology, which should make sense why it is used for SOX. Typically COBIT is used because it is seen as a more specific version of the COSO framework. COBIT outlines practices for 34 IT processes, which is far more detail than you will need for the Cyber Ops SECOPS exam.

The Information Technology Governance Institute (ITGI) is another framework that publishes its own SOX compliance recommendations based on both COBIT and COSO guidelines. The key thing about ITGI is that this framework focuses only on security issues.

Now let’s review some controls you should be familiar with in regard to a SOX audit.

Access: Access covers physical and electronic controls ensuring only authorized users can access sensitive information. Technology and concepts covered include secure physical locations of equipment, effective password policies, and network access control. Policies should follow the principle of least privilege, meaning only provide the minimal required access to perform a job.

IT security: IT security covers various security technologies that prevent breaches and loss of sensitive data. Technology and concepts include firewalls, IPS/IDS, antivirus, honey pots, and content filters. The best way to meet this area is to spread the investment for layered protection and include both quality monitoring and reporting to prove the effectiveness of the IT security controls.

Change management: Change management covers how an organization adds and removes users or workstations, software installation and maintenance, user database administration, and so on. When preparing for a SOX audit, you will need to show a record of changes, including who made the changes, when they were made, and how the integrity of such records is protected.

Backup: This covers how sensitive data is protected while backed up in the event of a need for data recovery. SOX compliance includes data stored offsite or by a third-party data storage provider.

This should give you a general understanding of SOX requirements. Most likely the SECOPS exam will ask very basic questions about SOX; however, we included more details here for those looking to improve their understanding of SOX compliance.

The list that follows highlights the key SOX concepts:

SOX applies to all publicly held American companies as well as any international organizations that have registered equity or debt securities within the U.S. Securities Exchange Commission.

SOX also applies to any accounting firm or third-party service provider that is involved with financial services to all publicly held American companies and any international organizations responsible for SOX.

SOX Section 302 requires the organization’s C-level members to be responsible for enforcement.

SOX Section 404 requires an annual audit of security controls by an outside auditor.

SOX Section 409 requires disclosing changes on an urgent basis.

Key security controls to be aware of in regard to a SOX audit are access, IT security, change management, and backups.

First we covered PCI DSS, which focused on the payment card industry. Next, we looked at HIPAA, targeting health care data. We concluded the chapter with a brief overview of SOX, which was designed to deal with financial fraud. Make sure you verify what version of PCI DSS, HIPAA, and SOX is referenced in the Cyber Ops SECOPS exam, even though it is very likely the questions you will see are very high level and don’t require memorizing the specifics of each compliance standard.

In the next chapter, we will look at network and host profiles.

http://www.hhs.gov/hipaa

http://www.dhcs.ca.gov/formsandpubs/laws/hipaa/Pages/1.00WhatisHIPAA.aspx

https://www.pcisecuritystandards.org/pci_security/

http://www.sarbanes-oxley-101.com/

http://www.hipaajournal.com/no-insurance-cover-for-cottage-health-hipaa-breach-6778/

http://www.thesecurityblogger.com/insurer-tells-hospitals-you-let-hackers-in-we-are-not-bailing-you-out/

Payment Card Industry Data Security Standard (PCI DSS)

cardholder data environment (CDE)

Health Insurance Portability and Accountability ACT (HIPAA)

electronic protected health information (e-PHI)

Sarbanes-Oxley Act of 2002 (SOX)

Public Company Accounting Oversight Board (PCAOB)

Committee of Sponsoring Organizations (COSO)

1. According to PCI DSS, cardholder data includes everything but which of following?

a. Primary account number (PAN)

b. Expiration date

c. Image on the card

d. Service code

2. Which of the following is not a HIPAA administrative safeguard?

a. A company’s CEO and CFO are required personally to certify that all financial reporting records are complete and accurate.

b. There must be the appropriate supervision of anybody in contact with e-PHI.

c. There must be a designated security officer responsible for developing and implementing security policies and procedures.

d. Periodic assessments must be performed to evaluate HIPAA security rule requirements.

3. Cardholder data environment (CDE) can best be defined as which of the following?

a. The people, processes, and technologies that store, process, or transmit cardholder data or authentication data

b. The people, processes, and technologies that store, process, or transmit cardholder data

c. The processes that store, process, or transmit cardholder data or authentication data

d. The technologies that store, process, or transmit cardholder data or authentication data

4. Which of the following is not a requirement of the HIPAA security rule?

a. Ensure the confidentiality, integrity, and availability of all e-PHI created, received, maintained, or transmitted.

b. Protect against reasonably anticipated, impermissible uses or disclosures.

c. Enforce automated access control using 802.1x-based technologies.

d. Identify and protect against reasonably anticipated threats to the security or integrity of the information.

5. Which of the following is not part of the PCI Data Security Standard?

a. Encrypt transmission of cardholder data across open, public networks.

b. Restrict access to cardholder data by business need to know.

c. Ensure that any deficiencies in the controls as well as information on fraud are disclosed.

d. Track and monitor all access to network resources and cardholder data.

6. Which of the following is not part of SOX technology and policy monitoring?

a. Access to physical and electronic controls, ensuring only authorized users have access to sensitive information

b. Employing, hiring, and auditing for criminal history

c. Change management for how an organization adds and removes users or workstations, software installation and maintenance, and user database administration

d. How sensitive data is protected while backed up in the event of a need for data recovery

7. Which of the following is not a violation of PCI DSS?

a. Sending e-PHI in an unencrypted method due to local law

b. Installing the most secure software versus older PCI-approved software

c. Hardening a PCI system due to being installed on a non-PCI approved network

d. Running a PCI-approved application on a non-PCI-approved server

8. In regard to PCI DSS, sensitive authentication data does not include which of the following?

a. PINs/PIN blocks

b. Fingerprint scanning

c. CAV2/CVC2/CVV2/CID

d. Full track data, which can be magnetic strip or equivalent chip

9. Which of the following is not required for the PCI DSS requirement “Implement strong access control measures”?

a. Restrict physical access to cardholder data.

b. Identify and authenticate access to system components.

c. Audit firewall configurations annually.

d. Restrict access to cardholder data by business need to know.

10. The HIPAA security rule ensures the CIA of e-PHI. What does CIA stand for?

a. Confidentiality, integrity, and access

b. Confidentiality, integrity, and availability

c. Confidentiality, indisputability, and access

d. Control, integrity, and access