This is the third part in our series looking at recent announcements by Amazon, Microsoft and other cloud service providers regarding new encryption and key management services. Let’s talk about log collection and active monitoring as a security best practice, and as a requirement to meet PCI DSS security requirements. Since the PCI DSS guidelines implement common security best practices, they are a good starting point for evaluating the security of any application and platform that processes sensitive data. Following the practice of the first part of this series we will use the PCI document “PCI DSS Cloud Computing Guidelines, Version 2.0” as our reference point, and add in some other sources of security best practices. Even if you don’t have to meet PCI data security requirements, this should be helpful when evaluating your security posture in the cloud.

Collecting system logs and actively monitoring them is a core component of every cyber security recommendation. Cybercriminals often gain access to IT systems and go undetected for weeks or months. This gives them the ability to work on compromising systems and stealing data over time. Active monitoring is important in the attempt to detect and thwart this compromise.

Here is what PCI says about active monitoring in Section 10 of the PCI DSS (emphasis added):

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

Many breaches occur over days or months before being detected. Checking logs daily minimizes the amount of time and exposure of a potential breach. Regular log reviews by personnel or automated means can identify and proactively address unauthorized access to the cardholder data environment. The log review process does not have to be manual. The use of log harvesting, parsing, and alerting tools can help facilitate the process by identifying log events that need to be reviewed.

In recognition of the importance of ongoing, active monitoring the National Institute of Standards and Technology (NIST) provides this guidance in their Special Publication 800-137 “Information Security Continuous Monitoring (ISCM)” guidance:

The Risk Management Framework (RMF) developed by NIST, describes a disciplined and structured process that integrates information security and risk management activities into the system development life cycle. Ongoing monitoring is a critical part of that risk management process. In addition, an organization’s overall security architecture and accompanying security program are monitored to ensure that organization-wide operations remain within an acceptable level of risk, despite any changes that occur. Timely, relevant, and accurate information is vital, particularly when resources are limited and agencies must prioritize their efforts.

And active monitoring is a component of the SANS Top 20 security recommendations:

Collect, manage, and analyze audit logs of events that could help detect, understand, or recover from an attack.

Deficiencies in security logging and analysis allow attackers to hide their location, malicious software, and activities on victim machines. Even if the victims know that their systems have been compromised, without protected and complete logging records they are blind to the details of the attack and to subsequent actions taken by the attackers. Without solid audit logs, an attack may go unnoticed indefinitely and the particular damages done may be irreversible.

Because of poor or nonexistent log analysis processes, attackers sometimes control victim machines for months or years without anyone in the target organization knowing, even though the evidence of the attack has been recorded in unexamined log files.

Deploy a SIEM (Security Incident and Event Management) or log analytic tools for log aggregation and consolidation from multiple machines and for log correlation and analysis.

This is why actively collecting and monitoring system and application logs is critical for your security strategy.

Implementing this critical security control in a cloud environment presents some special challenges. Here is what the PCI cloud guidance says:

Additionally, the ability to maintain an accurate and complete audit trail may require logs from all levels of the infrastructure, requiring involvement from both the CSP and the client. For example, the CSP could manage system-level, operating-system, and hypervisor logs, while the client configures logging for their own VMs and applications. In this scenario, the ability to associate various log files into meaningful events would require correlation of client-controlled logs and those controlled by the CSP.

It is not enough to collect logs from a few selected points in your cloud application environment. You need to collect all of the logs from all of the components that you deploy and use in your cloud application. This is because the effectiveness of active monitoring depends on the correlation of events across your entire application, database, and network and this includes the cloud providers systems and infrastructure. Here is what ISACA says about security event correlation:

Correlation of event data is critical to uncover security breaches because security incidents are made up of a series of events that occur at various touch points throughout a network--a many-to-one process. Unlike network management, which typically is exception-based or a one-to-one process, security management is far more complex. An attack typically touches a network at multiple points and leaves marks or breadcrumbs at each. By finding and following that breadcrumb trail, a security analyst can detect and hopefully prevent the attack.

Your encryption key management system is one of those critical system components that must be monitored and whose events should be aggregated into a unified view. Key management logs would include encryption key establishment and configuration, encryption key access and use, and operating system logs of every component of the key management service. You should be able to collect and monitor logs from all parts of your applications and cloud platform.

Unfortunately, current key management services from cloud providers only provide a very limited level of access to critical component logs. You might have access to a limited audit trail of your own access to encryption keys, but no access to the key service system logs, HSM access logs, HSM audit logs, or HSM operating system logs. Without access to the logs in these components it is not possible for you to implement an effective log collection and active monitoring strategy. You are working in the dark, and without full access to all logs on all components of your cloud key management service you can’t comply with security best practices for log collection, correlation, and active monitoring.

Since key management systems are always in scope for PCI audit and are extensions of your application environment it is difficult to see how these new cloud key management services can meet PCI DSS requirements for log collection and monitoring as currently implemented.

Does this mean you can’t implement security best practices for key management in the cloud? I don’t think so. There are multiple vendors, including us (see below), who offer cloud key management solutions that provide full access to key management, configuration, key usage, application, and operating system logs.  You can deploy a key management service that fully supports security best practices for log collection and monitoring.

In part 4 of this series we’ll look at the topic of key custody and multi-tenancy and how it affects the security of your key management solution in the cloud.

Patrick

Resources

Alliance Key Manager for AWS

Alliance Key Manager for Azure

Alliance Key Manager for VMware and vCloud

Alliance Key Manager for Drupal

This is the second part in our series looking at recent announcements by Amazon, Microsoft and others regarding new encryption and key management services. Let’s talk about the concept of segmentation as a security best practice, and as a strong recommendation by PCI DSS security standards. Since the PCI DSS guidelines implement common security best practices they are a good jumping off point for evaluating the security of any application and platform. Following the practice of the first part of this series we will use the PCI document “PCI DSS Cloud Computing Guidelines, Version 2.0” as our reference point. Even if you don’t have to meet PCI data security requirements, this should be helpful when evaluating your security posture in the cloud.

Segmentation as a security concept is very simple and very fundamental. Better security can be achieved by not mixing trusted and untrusted applications, data, and networks. This concept of trusted and untrusted applications extends to the value of the data assets – when applications process highly sensitive and valuable data assets they need to be separated into trusted and secure environments. We expend more effort and resources to protect what is valuable from criminals. Conversely, when there are no valuable data assets in an environment there is no need to take the same level of effort to secure them.

This is the core reason that PCI DSS recommends segmentation of applications that process payments from non-payment applications. Here is what PCI says about non-cloud applications:

Outside of a cloud environment, individual client environments would normally be physically, organizationally, and administratively separate from each other.

So, how do the PCI DSS security requirements relate to cloud platforms? Here is what PCI says (emphasis added):

Segmentation on a cloud-computing infrastructure must provide an equivalent level of isolation as that achievable through physical network separation. Mechanisms to ensure appropriate isolation may be required at the network, operating system, and application layers; and most importantly, there should be guaranteed isolation of data that is stored.

Proper segmentation is difficult to achieve even when you have complete control over all aspects of your environment. When you add the inherently shared and multi-tenant architecture of cloud platforms this becomes a high hurdle to get over. Here is what PCI says about this challenge:

Client environments must be isolated from each other such that they can be considered separately managed entities with no connectivity between them. Any systems or components shared by the client environments, including the hypervisor and underlying systems, must not provide an access path between environments. Any shared infrastructure used to house an in-scope client environment would be in scope for that client’s PCI DSS assessment.

This brings us exactly to the concern about new cloud key management services in Azure and AWS. These new services are inherently multi-tenant in both the key management services down to the hardware security modules (HSMs) that provide the ultimate security for encryption keys. You have no idea who you are sharing the service with.

The PCI guidance tells us what this segmentation looks like in a cloud environment:

A segmented cloud environment exists when the CSP enforces isolation between client environments. Examples of how segmentation may be provided in shared cloud environments include, but are not limited to: 

• Traditional Application Service Provider (ASP) model, where physically separate servers are provided for each client’s cardholder data environment.
• Virtualized servers that are individually dedicated to a particular client, including any virtualized disks such as SAN, NAS or virtual database servers.
• Environments where clients run their applications in separate logical partitions using separate database management system images and do not share disk storage or other resources.

There is no cloud service provider implementation of key management services that meet these basic requirements.

The PCI DSS guidance takes a pretty strong view about inadequate segmentation in cloud environments:

If adequate segmentation is not in place or cannot be verified, the entire cloud environment would be in-scope for any one client’s assessment. Examples of “non-segmented” cloud environments include but are not limited to:

• Environments where organizations use the same application image on the same server and are only separated by the access control system of the operating system or the application.
• Environments where organizations use different images of an application on the same server and are only separated by the access control system of the operating system or the application.
• Environments where organizations’ data is stored in the same instance of the database management system’s data store.

Since key management systems are always in scope for PCI audit and are extensions of your application environment and depend entirely on the access control system of the cloud provider, it is difficult to see how these new cloud key management services can meet PCI DSS requirements as currently implemented.

Here’s the last comment by PCI on segmentation in cloud environments:

Without adequate segmentation, all clients of the shared infrastructure, as well as the CSP, would need to be verified as being PCI DSS compliant in order for any one client to be assured of the compliance of the environment. This will likely make compliance validation unachievable for the CSP or any of their clients.

Does this mean you can’t implement security best practices for key management in the cloud? I don’t think so. There are multiple vendors including us (see below) who offer cloud key management solutions that we believe can be effectively isolated and segmented on cloud platforms, or even hosted outside of the cloud.

In our part 3 of this series we’ll look at the topic of logging and active monitoring and how it affects the security of your key management solution in the cloud.

Patrick

Resources

Alliance Key Manager for AWS

Alliance Key Manager for Azure

Alliance Key Manager for VMware and vCloud

Alliance Key Manager for Drupal

Alliance Key Manager for IBM Power Systems

Alliance Key Manager Cloud HSM

Understanding PCI Merchant Levels and how an assessment can help your business

If your business takes credit cards for payment, then you are subject to the Payment Card Industry – Data Security Standards (PCI-DSS).

Companies of all sizes must comply with PCI DSS to ensure that their customers' data is protected during the processing and transmission of credit or debit card transactions and securely stored within any internal databases. PCI categorizes businesses into different classification levels based on the number of transactions and dollar amounts they processes each year.

Level 1 – All merchants processing more than 6 million card transactions annually

Level 2 – All merchants processing between 1 million and 6 million card transactions annually

Level 3 – All merchants processing between 20,000 and 1 million card-not-present only transactions annually

Level 4 – All other merchants

Level 1 companies are most likely well versed in the annual PCI audit process as they have a certified onsite audit annually with a Qualified Security Assessor (QSA). Level 2, 3, 4 merchants are not required to hire an onsite QSA, but can have a certified Internal Security Assessor (ISA) do the PCI self assessment annually. However, a small business preparing a self-assessment to participate in their first PCI review may find it a little daunting. If you're feeling that the PCI assessment process is overwhelming and complicated, understanding this process may be the first step toward putting your mind at ease. If you are a Level 1 merchant, the PCI assessment is a process carried out by a QSA to establish whether or not a business is compliant with security standards relating to the processing of transactions made via a credit or debit card (payment card). PCI compliance assesses your business point of sale system, payment applications, and all interconnecting systems with these goals in mind: (1) to examine your system, (2) to identify vulnerabilities, and (3) to prevent data from being compromised.

It’s not a matter of “IF”, but “WHEN”

If you have already suffered a data breach, working closely to review your assessment and put data security best practices into place will provide you with a roadmap to help avoid future losses. If you have not yet been breached, undergoing an assessment and reviewing your risk tolerance can still be stressful. Understanding the process may alleviate some of that stress and help you to maximize your use of the information in the PCI DSS assessment report

How can a PCI audit help my business?

PCI compliance auditing helps businesses to ensure they are providing the most secure environment for their customers to process payments and ensures that transactions are less likely to result in a compromise in the customers' data.

Ensuring that you meet PCI compliance and have a solid infrastructure for managing data security will increase customer confidence in your business and ensure that you're not exposed to security breaches that could have been avoided. 

To learn more about meeting PCI compliance requirements, download the whitepaper Meet the Challenges of PCI Compliance and find the answers to the following questions (and more):

• What will my auditor look for?

• How can I ensure my customers' data is secure?
• What is the difference between tokenization and encryption?
• What is encryption key management and why are auditors looking at this?

VMware and PCI DSS Compliance: Taking the right steps in a virtualized environment

As of vSphere 6.5, AES encryption has been added to VMware. With VMWare encryption, complying with PCI DSS, requirement 3 is even easier. And executives are taking note as they look to conserve resources by moving their organizations databases and IT environments to virtualized platforms and to the cloud.

Security best practices and compliance regulations call for sensitive data to be protected with encryption and that data-encrypting keys (DEK) be physically or logically separated from the sensitive data and protected with strong key-encrypting keys (KEK). Depending on what type of information is being stored and what industry guidance your project/company falls under, compliance regulations in addition to PCI DSS may apply.

The Payment Card Industry Data Security Standard (PCI DSS) is one of the most rigorous and specific set of standards established to date and is used by many organizations as a standard to secure their systems. PCI DSS applies to all organizations that store, process, or transmit cardholder data, regardless of volume. This includes merchants, service providers, payment gateways, data centers, and outsourced service providers.

Here is a high level look at all twelve items that must be met in order to be compliant, with three new requirements in PCI DSS 3.0 (**) that warrant mentioning as being most relevant to the use of VMware and cloud technologies in a PCI-regulated infrastructure:

Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data


(3.0) **Req. 1.1.3: "[Maintain a] current diagram that shows all cardholder data flows across systems and networks."

Requirement 2: Do Not use vendor-supplied defaults for system passwords and other security parameters

(3.0)** Req. 2.4: "Maintain an inventory of system components that are in scope for PCI DSS."

Protect Cardholder Data

Requirement 3: Protect stored cardholder data*


* Requirement 3 specifically addresses the need for encryption and key management, stating:

“Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.”

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs


Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know


Requirement 8: Identify and authenticate access to system components


Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data


Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that address information security for all personnel

(3.0) ** Req. 12.8.5: "Maintain information about which PCI DSS requirements are managed by each service provider and which are managed by the entity."

It can seem overwhelming at first, but the PCI Security Standards Council (PCI SSC) website contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations. Within the latest documentation by the PCI Security Standards Council (v3.0 released November 2013) specific testing procedures and guidance is given for Requirement 3 on pages 34-43.

Fortunately, there are also standards and published guidance on running payment applications in a virtualized environment:

Payment Card Industry Data Security Standard: Virtualization Guidelines and Cloud Computing Guidelines

NIST SP 800-144: Guidelines on Security and Privacy in Cloud Computing

Cloud Security Alliance: Security Guidance for Critical Areas of Focus in Cloud Computing

While virtual technology is not limited to VMware, it is one of the most commonly used and supported architectures by many cloud service providers. In addition to the PCI compliance and cloud guidelines above, VMware worked with CoalFire, a QSA auditing firm, to create guidance on how to specifically deploy payment applications in a VMware environment. You can access the CoalFire document  here.

As platform virtualization becomes a more popular solution, executives need to remain vigilant with their data security and meeting compliance requirements. We can help make the transition to VMware easy with our Alliance Key Manager for VMware solution, which meets the PCI recommendations when deployed properly in a VMware environment. We are committed to helping businesses protect sensitive data with industry standard NIST compliant AES encryption and FIPS 140-2 compliant encryption key management solutions.

Many compliance regulations and security best practices require the encryption of sensitive data and the protection of encryption keys with proper key management.

Security best practices and PCI DSS compliance regulations call for sensitive data to be protected with encryption and that data-encrypting keys (DEK) be physically or logically separated from the sensitive data and protected with strong key-encrypting keys (KEK). Anyone who needs to protect sensitive data in their database, needs to know that storing the encryption keys within the same location puts data at risk for a breach.  Depending on what type of information is being stored and what industry guidance your project/company falls under, compliance regulations in addition to PCI DSS may apply.

For any company that accepts credit card payments, the Payment Card Industry Data Security Standards (PCI DSS) issues 12 requirements that must be met in order to be compliant. It can seem overwhelming at first, but the PCI council that issues PCI DSS also provides detailed reference guides and instructions on each requirement.

Let’s take a brief look at all twelve items:

Build and Maintain a Secure Network and Systems

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Requirement 2: Do Not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data*

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs

Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know

Requirement 8: Identify and authenticate access to system components

Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data

Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that address information security for all personnel

Within the latest documentation by the PCI Security Standards Council (v3.0 released November 2013) specific testing procedures and guidance is given for Requirement 3 on pages 34-43. The PCI Security Standards Council (PCI SSC) website (http://www.pcisecuritystandards.org) contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations.

* Requirement 3 addresses the need for encryption and key management, stating:

“Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.”

The PCI Security Standards Council also issues their Cloud Computing Guidelines (https://www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_Cloud_Guidelines.pdf) and additional information around virtualization of data protection solutions so you can be PCI compliant with a cloud-based solution for encryption and key management.

Other compliance requirements for protecting information go beyond cardholder data (PCI focuses on PAN or the Primary Account Number specifically) and also require that personally identifiable information (PII) such as names, birthdates, email address, zip codes, usernames, or passwords be protected properly with encryption and key management. To meet the growing need for NIST validated and FIPS 140-2 compliant solutions, the data security experts at Townsend Security provide a certified key management system (Alliance Key Manager) which provides secure key storage and retrieval options for a variety of Enterprise and open source platforms.  Now sensitive information can easily be encrypted and the encryption keys properly managed. 

For more information on encryption, download the latest eBook, The Encryption Guide:

Securing data with encryption and protecting the encryption keys with proper key management is addressed in many compliance regulations and security best practices.

For Drupal developers who need to protect sensitive data in their (or their clients) content management system (CMS), storing the encryption keys within the Drupal CMS puts that data at risk for a breach. Security best practices and PCI DSS compliance regulations call for sensitive data to be protected with encryption and that data-encrypting keys (DEK) be physically or logically separated from the sensitive data and protected with strong key-encrypting keys (KEK).  Depending on what type of information is being stored and what industry guidance your project/company falls under, compliance regulations in addition to PCI DSS may apply.

For any company that accepts credit card payments, the Payment Card Industry Data Security Standards (PCI DSS) issues 12 requirements that must be met in order to be compliant. It can seem overwhelming at first, but the PCI council that issues PCI DSS also provides detailed reference guides and instructions on each requirement. Let’s take a high level look at all twelve items:

Build and Maintain a Secure Network and Systems

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do Not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data*
Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Identify and authenticate access to system components
Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that address information security for all personnel

Within the latest documentation by the PCI Security Standards Council (v3.0 released November 2013) specific testing procedures and guidance is given for Requirement 3 on pages 34-43. The PCI Security Standards Council (PCI SSC) website contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations. PCI SSC also issues Cloud Computing Guidelines and additional information around virtualization of data protection solutions so you can be PCI compliant with a cloud-based solution for encryption and key management.

Requirement 3 addresses the need for encryption and key management, stating:

“Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.”

In order to address PCI DSS Requirement 3: Protect stored cardholder data; the security experts at Townsend Security partnered with Chris Teitzel, CEO of Cellar Door Media and Drupal developer to create Key Connection for Drupal in connection with the existing Drupal Encrypt module. In order to provide secure key storage and retrieval options, Key Connection for Drupal provides a secure key management system (Alliance Key Manager) outside of the Drupal installation. Now when cardholder information is collected or stored in a database it can easily be encrypted and the encryption keys properly managed. Key Connection for Drupal allows developers and users to choose whether they need to retrieve a key and encrypt/decrypt locally or to send the data to Alliance Key Manager to perform on board encryption.

Other compliance requirements for protecting information go beyond cardholder data (PCI focuses on PAN or the Primary Account Number specifically) and also require that personally identifiable information (PII) such as names, birthdates, email address, zip codes, usernames, or passwords be protected with encryption and key management. Check back as future blogs will cover additional data privacy compliance regulations and security best practices that impact developers and users of the Drupal CMS open source platform in regards to protected health information (PHI).

For more information on PCI Compliance, download the Whitepaper: "Meet the Challenges of PCI Compliance"