Showing posts with label Cloud. Show all posts
Showing posts with label Cloud. Show all posts
Wednesday, August 12, 2009
Amazon EC2 and PCI Compliance
I saw a very informative forum post regarding Amazon's position on EC2 and S3 PCI compliance via a twitter update from @beaker (http://twitter.com/Beaker/statuses/3277444460). The post states merchants can not achieve level 1 PCI compliance within Amazon's cloud infrastructure, because Amazon will not allow customers to perform on-site assessments. Amazon recommends using their Flixible Payments Service to successfully handle credit card data within their cloud. Mosso, now "Rackspace Cloud", took a similar approach as discussed in my March 2009 blog post.
Tuesday, March 24, 2009
Cloud Computing Data Security
Disclaimer: I am not a QSA and am in no way certified to determine whether a network, system, or application is PCI compliant. The information in this article is my opinion only.
A lot of people have voiced concerns about the security and control of data within the cloud. Obviously organizations have significantly more control over data stored within their own infrastructure, but what about data hosted by a third party financial services organization that offers SaaS mobile banking or loan management services versus an implementation within a cloud computing provider's infrastructure? This article analyzes security concerns and the ability to control data in both of the service provider situations. This article will ONLY focus on the data storage aspect of this situation and will ignore things like vulnerabilities in developed applications. In future posts, I may expand the scope.
To set up the context in which these situations will be analyzed, we must first place each provider on equal footing. In this example, both service providers place cardholder data within storage over an encrypted connection (SSL/TLS). In addition, cardholder data is encrypted by the application before being placed within storage. It is assumed that the secret key for the encrypted data is stored on the application server using an appropriate framework such as Microsoft's DPAPI. This means that users with appropriate domain credentials and permissions for the application server may be able to access the secret key.
Threats
I have chosen to analyze data security issues based on potential threats to data within a provider's infrastructure. The following sections dig into each of these threats.
Data Loss or Destruction: Infrastructure Admin Deletes Data
A user with administrative privileges to the data storage infrastructure may maliciously or accidentally destroy the encrypted cardholder data.
Amazon S3 and Third Party Financial Services Provider: Viable Threat
This is a viable threat in both scenarios. A data administrator could delete data in each of these situations.
Data Loss or Destruction: One Data Center is Temporarily or Permanently Unavailable
A natural disaster, power failure, or other situation could render one data center unavailable.
Third Party Financial Services Provider:
My experience indicates that most of these providers utilize multiple data centers located in separate geographic locations within the United States. Depending on whether the additional data center is regarded as a cold, warm, or hot site, data may or may not be immediately available.
Amazon S3:
Data stored within Amazon S3 is stored and immediately available in at least two data centers [1] [2]. If one data center becomes unavailable, data will still be accessible to applications in the other data center.
All US Data Centers are Temporarily or Permanently Unavailable
If some kind of significant event affects the US's Internet infrastructure, multiple data centers could become unavailable.
Third Party Financial Services Provider:
Third party providers may or may not have data centers in locations outside of the US.
Amazon S3:
Data in Amazon S3 is not automatically backed up to data centers outside of the US; however as a mitigating control, organizations can choose to periodically backup data to Amazon S3 buckets within the UK [5].
Data Loss or Destruction: "Hacker" Destroys Data
A hacker could exploit a vulnerability within a system or network device that allows access to or control of data (remember, we are intentionally ignoring application level issues in this particular article). The attacker may choose to delete, destroy, or render that data inaccessible.
Third Party Financial Services Provider:
Customers rely on the third party providers to place appropriate access controls around data and to apply security patches to network and system devices in a timely manner.
Amazon S3:
Customers can place bucket or object-level access controls around data within Amazon S3. Customers directly control the application of security patches to virtual images. Customers rely upon Amazon to apply patches to flaws identified within S3 or Amazon's API.
Unauthorized Data Access: Infrastructure Admin Accesses Data
A user with administrative privileges to the data storage infrastructure may attempt to access cardholder data for the purpose of financial gain.
Third Party Financial Services Provider:
Since the third party provider maintains the secret key for the encrypted data, it may be possible that an unauthorized individual may have domain privileges to access the secret key and the encrypted cardholder data. This would directly result in a compromise of customers' credit cards.
Amazon S3:
An administrator for Amazon S3 may be able to access the cipher-text for cardholder data; however the administrator would not have access to the secret key used to encrypt the data. It would be very difficult for that administrator to discover or brute force the secret key associated with that data.
Unauthorized Data Access: "Hacker" Accesses Data
A hacker could exploit a vulnerability within a system or network device that allows access to data (remember, we are intentionally ignoring application level issues in this particular article). The attacker may choose to read or steal that data for financial gain.
Third Party Financial Services Provider:
Customers rely on the third party providers to place appropriate controls around data, to apply security patches in a timely manner, and to encrypt data at rest and while in transit.
Amazon S3:
Customers can place bucket or object-level access controls around data within Amazon S3. Customers directly control the application of security patches to virtual images. Data can be encrypted prior to being placed within cloud storage, rendering stolen data useless for an attacker. Customers rely upon Amazon to apply patches to flaws identified within S3 or Amazon's API.
Unauthorized Data Modification: Infrastructure Admin Modifies Data
A user with administrative privileges to the data storage infrastructure may attempt to modify cardholder data for the purpose of financial gain.
Third Party Financial Services Provider:
Since the third party provider maintains the secret key for the encrypted data, it may be possible that an unauthorized individual may have domain privileges to access the secret key and the encrypted cardholder data. This would allow an attacker to modify cardholder data or other assets within the data store.
Amazon S3:
An administrator for Amazon S3 may be able to access and modify the cipher-text for cardholder data, however the administrator would not have access to the secret key used to encrypt the data. It would be very difficult for that administrator to discover or brute force the secret key associated with that data.
Unauthorized Data Modification: "Hacker" Modifies Data
A hacker could exploit a vulnerability within a system or network device that allows access to data (remember, we are intentionally ignoring application level issues in this particular article). The attacker may choose to modify that data for financial gain.
Third Party Financial Services Provider:
Customers rely on the third party providers to place appropriate controls around data, to apply security patches in a timely manner, and to encrypt data at rest and while in transit.
Amazon S3:
Customers can place bucket or object-level access controls around data within Amazon S3. Customers directly control the application of security patches to virtual images. Data can be encrypted prior to being placed within cloud storage. Customers rely upon Amazon to apply patches to flaws identified within S3 or Amazon's API.
Miscellaneous: Data Stored in Hostile Country
It is important for customers to ensure sensitive data or intellectual property is properly protected. Some countries do not have adequate laws or security standards in place to protect sensitive data or to restrict seizure of data by the government.
Third Party Financial Services Provider:
Third party providers typically are aware of these concerns and likely will not host data within a hostile country.
Amazon S3:
Customers of Amazon's S3 service may choose the country in which data is stored. Customers can choose to create a bucket in the US or in the UK [5].
Miscellaneous: Availability Issues
When data or services are unavailable, companies may lose revenue during the down time and may loose customers concerned with reliability of data or applications.
Third Party Financial Services Provider:
Availability and SLAs vary for each third party financial services providers.
Amazon S3:
The S3 storage system is highly available and stores data redundantly in multiple geographic locations. Amazon provides a SLA of 99.9% up time per month [4]; however they have had an issue or two in the past with availability [3].
Conclusions
To summarize the findings above, I created a table listing threats, mitigating factors, and risk levels.
(Click the image to enlarge)
One major concern voiced regarding cloud computing is the control of data. Organizations do not want sensitive data accessed by service providers or disclosed/stolen due to security issues related to the provider's infrastructure. Surprisingly, the findings above show customers have a greater level of control over data stored within Amazon's S3 cloud storage service as compared to utilizing a third party financial services provider.
When analyzing threats to data security, findings show customers have the potential to implement stronger security controls around sensitive data stored in the cloud as compared to third party service providers. These finding my be misleading; however as many financial service providers invest heavily into developing strong information security programs, typically have a range of security experts in house, and engage in independent assessments to verify the security of networks, systems, and applications.
After considering all the data, I think the most important point to take away from this is actually not whether one solution is more secure than the other, but instead that data can be stored within the cloud in a secure and robust manner. Organizations should evaluate the choice to adopt cloud storage on the basis of whether it improves the business or generates additional revenue and should not make the decision based on fear of customer data being compromised or stolen.
References
A lot of people have voiced concerns about the security and control of data within the cloud. Obviously organizations have significantly more control over data stored within their own infrastructure, but what about data hosted by a third party financial services organization that offers SaaS mobile banking or loan management services versus an implementation within a cloud computing provider's infrastructure? This article analyzes security concerns and the ability to control data in both of the service provider situations. This article will ONLY focus on the data storage aspect of this situation and will ignore things like vulnerabilities in developed applications. In future posts, I may expand the scope.
To set up the context in which these situations will be analyzed, we must first place each provider on equal footing. In this example, both service providers place cardholder data within storage over an encrypted connection (SSL/TLS). In addition, cardholder data is encrypted by the application before being placed within storage. It is assumed that the secret key for the encrypted data is stored on the application server using an appropriate framework such as Microsoft's DPAPI. This means that users with appropriate domain credentials and permissions for the application server may be able to access the secret key.
Threats
I have chosen to analyze data security issues based on potential threats to data within a provider's infrastructure. The following sections dig into each of these threats.
Data Loss or Destruction: Infrastructure Admin Deletes Data
A user with administrative privileges to the data storage infrastructure may maliciously or accidentally destroy the encrypted cardholder data.
Amazon S3 and Third Party Financial Services Provider: Viable Threat
This is a viable threat in both scenarios. A data administrator could delete data in each of these situations.
Data Loss or Destruction: One Data Center is Temporarily or Permanently Unavailable
A natural disaster, power failure, or other situation could render one data center unavailable.
Third Party Financial Services Provider:
My experience indicates that most of these providers utilize multiple data centers located in separate geographic locations within the United States. Depending on whether the additional data center is regarded as a cold, warm, or hot site, data may or may not be immediately available.
Amazon S3:
Data stored within Amazon S3 is stored and immediately available in at least two data centers [1] [2]. If one data center becomes unavailable, data will still be accessible to applications in the other data center.
All US Data Centers are Temporarily or Permanently Unavailable
If some kind of significant event affects the US's Internet infrastructure, multiple data centers could become unavailable.
Third Party Financial Services Provider:
Third party providers may or may not have data centers in locations outside of the US.
Amazon S3:
Data in Amazon S3 is not automatically backed up to data centers outside of the US; however as a mitigating control, organizations can choose to periodically backup data to Amazon S3 buckets within the UK [5].
Data Loss or Destruction: "Hacker" Destroys Data
A hacker could exploit a vulnerability within a system or network device that allows access to or control of data (remember, we are intentionally ignoring application level issues in this particular article). The attacker may choose to delete, destroy, or render that data inaccessible.
Third Party Financial Services Provider:
Customers rely on the third party providers to place appropriate access controls around data and to apply security patches to network and system devices in a timely manner.
Amazon S3:
Customers can place bucket or object-level access controls around data within Amazon S3. Customers directly control the application of security patches to virtual images. Customers rely upon Amazon to apply patches to flaws identified within S3 or Amazon's API.
Unauthorized Data Access: Infrastructure Admin Accesses Data
A user with administrative privileges to the data storage infrastructure may attempt to access cardholder data for the purpose of financial gain.
Third Party Financial Services Provider:
Since the third party provider maintains the secret key for the encrypted data, it may be possible that an unauthorized individual may have domain privileges to access the secret key and the encrypted cardholder data. This would directly result in a compromise of customers' credit cards.
Amazon S3:
An administrator for Amazon S3 may be able to access the cipher-text for cardholder data; however the administrator would not have access to the secret key used to encrypt the data. It would be very difficult for that administrator to discover or brute force the secret key associated with that data.
Unauthorized Data Access: "Hacker" Accesses Data
A hacker could exploit a vulnerability within a system or network device that allows access to data (remember, we are intentionally ignoring application level issues in this particular article). The attacker may choose to read or steal that data for financial gain.
Third Party Financial Services Provider:
Customers rely on the third party providers to place appropriate controls around data, to apply security patches in a timely manner, and to encrypt data at rest and while in transit.
Amazon S3:
Customers can place bucket or object-level access controls around data within Amazon S3. Customers directly control the application of security patches to virtual images. Data can be encrypted prior to being placed within cloud storage, rendering stolen data useless for an attacker. Customers rely upon Amazon to apply patches to flaws identified within S3 or Amazon's API.
Unauthorized Data Modification: Infrastructure Admin Modifies Data
A user with administrative privileges to the data storage infrastructure may attempt to modify cardholder data for the purpose of financial gain.
Third Party Financial Services Provider:
Since the third party provider maintains the secret key for the encrypted data, it may be possible that an unauthorized individual may have domain privileges to access the secret key and the encrypted cardholder data. This would allow an attacker to modify cardholder data or other assets within the data store.
Amazon S3:
An administrator for Amazon S3 may be able to access and modify the cipher-text for cardholder data, however the administrator would not have access to the secret key used to encrypt the data. It would be very difficult for that administrator to discover or brute force the secret key associated with that data.
Unauthorized Data Modification: "Hacker" Modifies Data
A hacker could exploit a vulnerability within a system or network device that allows access to data (remember, we are intentionally ignoring application level issues in this particular article). The attacker may choose to modify that data for financial gain.
Third Party Financial Services Provider:
Customers rely on the third party providers to place appropriate controls around data, to apply security patches in a timely manner, and to encrypt data at rest and while in transit.
Amazon S3:
Customers can place bucket or object-level access controls around data within Amazon S3. Customers directly control the application of security patches to virtual images. Data can be encrypted prior to being placed within cloud storage. Customers rely upon Amazon to apply patches to flaws identified within S3 or Amazon's API.
Miscellaneous: Data Stored in Hostile Country
It is important for customers to ensure sensitive data or intellectual property is properly protected. Some countries do not have adequate laws or security standards in place to protect sensitive data or to restrict seizure of data by the government.
Third Party Financial Services Provider:
Third party providers typically are aware of these concerns and likely will not host data within a hostile country.
Amazon S3:
Customers of Amazon's S3 service may choose the country in which data is stored. Customers can choose to create a bucket in the US or in the UK [5].
Miscellaneous: Availability Issues
When data or services are unavailable, companies may lose revenue during the down time and may loose customers concerned with reliability of data or applications.
Third Party Financial Services Provider:
Availability and SLAs vary for each third party financial services providers.
Amazon S3:
The S3 storage system is highly available and stores data redundantly in multiple geographic locations. Amazon provides a SLA of 99.9% up time per month [4]; however they have had an issue or two in the past with availability [3].
Conclusions
To summarize the findings above, I created a table listing threats, mitigating factors, and risk levels.
(Click the image to enlarge)One major concern voiced regarding cloud computing is the control of data. Organizations do not want sensitive data accessed by service providers or disclosed/stolen due to security issues related to the provider's infrastructure. Surprisingly, the findings above show customers have a greater level of control over data stored within Amazon's S3 cloud storage service as compared to utilizing a third party financial services provider.
When analyzing threats to data security, findings show customers have the potential to implement stronger security controls around sensitive data stored in the cloud as compared to third party service providers. These finding my be misleading; however as many financial service providers invest heavily into developing strong information security programs, typically have a range of security experts in house, and engage in independent assessments to verify the security of networks, systems, and applications.
After considering all the data, I think the most important point to take away from this is actually not whether one solution is more secure than the other, but instead that data can be stored within the cloud in a secure and robust manner. Organizations should evaluate the choice to adopt cloud storage on the basis of whether it improves the business or generates additional revenue and should not make the decision based on fear of customer data being compromised or stolen.
References
- http://s3.amazonaws.com/aws_blog/AWS_Security_Whitepaper_2008_09.pdf
"Data stored in Amazon S3, Amazon SimpleDB, or Amazon Elastic Block Store is redundantly stored in multiple physical locations as a normal part of those services and at no additional charge."
- http://developer.amazonwebservices.com/connect/thread.jspa?threadID=11831&start=15&tstart=0
"I guess in my last message I neglected to clearly reiterate what we've said before, which is consistent with what Jeff said in his talk - we store multiple copies in multiple data centers. Yes, that means at least two. We don't ack a PUT until those multiple copies in multiple datacenters have been stored. The only exception to this is if a datacenter receiving your PUT is totally isolated from other datacenters due to a network issue. In that case, the multiple copies are stored in the single active datacenter, and then one or more of the copies are migrated to separate datacenters when connectivity is attained. This is a very rare occurance though."
- http://status.aws.amazon.com/s3-20080720.html
- http://aws.amazon.com/s3-sla/
- http://aws.amazon.com/s3/
"A bucket can be located in the United States or in Europe. All objects within the bucket will be stored in the bucket’s location, but the objects can be accessed from anywhere."
Thursday, March 5, 2009
Mosso - First PCI Compliant Customer Through Self Evaluation and Scanning
Mosso, a PaaS cloud provider, claims to be the first in enabling a customer to be PCI compliant within the cloud. Naturally, this really excited me as I have spent a lot of time lately trying to figure out how to acomplish PCI compliance in the cloud. I was somewhat disapointed, however, once I read the details.
In this case, the application within the cloud does not actually store any credit card data. The customer leverages a third party payment gateway to handle collection and storage of all cardholder data.
Additionally, the customer did not gain PCI certification through an evaulation by a Qualified Security Assessor (QSA), but instead only needed to complete a "Self Assessment Questionaire" and pass a scan from an approved scanning vendor (ASV).
Since the application used a third party payment gateway to handle collection and storage of cardholder data, only a subset of the PCI DSS controls applied to this application. According to Mosso's article, only requirement 9 (Restrict physical access to cardholder data) and 12 (Maintain a policy that addresses information security) applied.
It's wonderful that some level of PCI compliance has been achieved for applications within the cloud, but I feel like this isn't much different than Amazon EC2 + Amazon Flexible Payments Service, or even simpler any cloud provider + Paypal. Hopefully in the future, we will have a case study in which an application that handles cardholder data will become PCI certified within a cloud computing provider's infrastructure.
Resources:
http://blog.mosso.com/2009/03/cloud-hosting-is-secure-for-take-off-mosso-enables-the-spreadsheet-store-an-online-merchant-to-become-pci-compliant/
http://www.mosso.com/docs/PCI_HowTo.pdf
http://aws.amazon.com/fps/
In this case, the application within the cloud does not actually store any credit card data. The customer leverages a third party payment gateway to handle collection and storage of all cardholder data.
Additionally, the customer did not gain PCI certification through an evaulation by a Qualified Security Assessor (QSA), but instead only needed to complete a "Self Assessment Questionaire" and pass a scan from an approved scanning vendor (ASV).
Since the application used a third party payment gateway to handle collection and storage of cardholder data, only a subset of the PCI DSS controls applied to this application. According to Mosso's article, only requirement 9 (Restrict physical access to cardholder data) and 12 (Maintain a policy that addresses information security) applied.
It's wonderful that some level of PCI compliance has been achieved for applications within the cloud, but I feel like this isn't much different than Amazon EC2 + Amazon Flexible Payments Service, or even simpler any cloud provider + Paypal. Hopefully in the future, we will have a case study in which an application that handles cardholder data will become PCI certified within a cloud computing provider's infrastructure.
Resources:
http://blog.mosso.com/2009/03/cloud-hosting-is-secure-for-take-off-mosso-enables-the-spreadsheet-store-an-online-merchant-to-become-pci-compliant/
http://www.mosso.com/docs/PCI_HowTo.pdf
http://aws.amazon.com/fps/
Thursday, February 26, 2009
PCI Compliance and Cloud Computing
Disclaimer: I am not a QSA and am in no way certified to determine whether a network, system, or application is PCI compliant. The information in this article is my opinion only and is intended create an open discussion about how companies subject to PCI can leverage cloud computing in their overall business strategy. If you disagree with any of my observations or conclusions, please add a comment and explain your argument, it's very likely that you are right ;-)
References:
PCI DSS version 1.2
Amazon's AWS Security Whitepaper
As I began researching cloud computing, one question I continually asked others is how payment card applications or data could be placed in a cloud computing provider's infrastructure in a PCI-compliant manner. So far, I have not received a definitive answer to this question.
In order to understand the implications of this question, I decided to read through the PCI standard and try to determine what controls would need to be in place for an example company and implementation. In this example, a fictitious financial services company wishes to leverage Amazon's EC2, EBS and S3 offerings to host a loan payoff application and its data. This application allows customers to view current loan information and pay balances using a credit or debit card.
The network and server architecture for this system will be identical to the "Basic Failover Architecture" presented in RightScale's wiki. The application will be written in Java and the database will be SQL Server 2005. Database backups will be encrypted and archived using Amazon's S3 cloud storage. Communication between the client and the web server, the web server and the database server, the master database server and the slave database server, and the database servers and Amazon's S3 service will be encrypted using SSL.
PCI DSS Scope
The PCI DSS document, page 5, states network segmentation of credit card data or activities may limit the scope of a PCI assessment. The PCI assessor must evaluate the effectiveness of network segmentation controls and then make a decision based on these results.
In a cloud computing environment, there are both physical and virtual infrastructure devices that provide segmentation. Amazon's Security Whitepaper discusses the following components that provide segmentation:
Takeaway: "segmentation" needs to be evaluated as it applies to virtual infrastructure and Amazon's physical infrastructure.
PCI DSS and Third Party Service Providers
Page 6 of the PCI standard discusses situations in which a company uses a third party service provider to provide cardholder data services. This section states that an assessor must clearly state which third party components should be included within a PCI assessment. The third party must have a PCI assessment conducted; however this assessment can be conducted at the time of the assessment of the original company. This means that cooperation from cloud computing service providers may be required to gain PCI-compliance for components within the cloud.
Takeaway: Companies will need to establish compliance of at least some of the cloud provider's components AND companies will likely need cooperation from cloud providers in obtaining PCI compliance.
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
There are a number of items within this requirement that refer to creating network diagrams, implementing firewalls, and other similar network controls. Organizations can easily fulfill these requirement as they apply to the virtual infrastructure within the cloud using the provided "security groups", Hypervisor firewall, and other similar features.
The unanswered question is to what extent the requirement applies to Amazon's physical infrastructure. This is particularly a problem if servers are constantly being spun up or down to automatically adjust based on needs/requirements. In addition, Amazon's S3 storage mirrors data across a number of geographically diverse locations. Documenting and assessing Amazon's the physical network for PCI is very tough. On the other hand, it may be sufficient to assess a sample of Amazon's data centers or physical network devices where data or servers could potentially be located.
Takeaway: It is unclear to what degree the cloud provider's physical architecture will need to be assessed in addition to the organization's virtual infrastructure.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
This section concerns default passwords, disabling unnecessary services, secure configuration of components, and the use of SSL. Most of this information applies to the virtual infrastructure.
However, item 2.4 and Appendix A list requirements that apply to shared hosting providers. These rules are concerned with segmentation of cardholder data, logging and forensics. Based on the controls implemented by the Hypervisor as well as authentication and authorization controls in place for accessing cloud storage, it is likely segmentation controls are satisfied. Logging and forensics concerns may require the creation of virtual images suited for these purposes or may require cooperation from the cloud computing provider.
Takeaway: Companies may need to plan ahead and/or get cooperation from cloud providers regarding logging and forensics. Specialized virtual images can be created to assist with forensics or incident investigation.
Requirement 3: Protect stored cardholder data and Requirement 4: Encrypt transmission of cardholder data across open, public networks
Secure storage and transportation of cardholder data is an important aspect of the PCI standard. Controls outlined in the document can be easily accomplished by the company implementing the virtual infrastructure. These companies are fully capable of encrypting data before storing it within EBS or S3, utilizing full disk encryption within virtual images, and leveraging SSL to securely send sensitive data between components.
Takeaway: This requirement can be satisfied without the cooperation of the cloud computing provider.
Requirement 5: Use and regularly update anti-virus software or programs
Anti-virus can easily be applied to virtual images. It may also be necessary for companies verify and document the cloud provider's use of anti-virus as it applies to Host OS's, cloud storage, and other related components.
Takeaway: Companies should verify and document the cloud provider's use of anti-virus on Host OS's, cloud storage, and other components.
Requirement 6: Develop and maintain secure systems and applications
I am going to separate this section into two parts. One part is concerned with the secure development of custom applications. While it is straight forward to understand how this applies to the company implementing the virtual infrastructure, its not as clear whether items like Amazon's web services need to be pen-tested or verified. Hopefully, Amazon has already completed an assessment on these components and organizations can simply receive a high-level overview of the result.
The second part is concerned with applying security updates in a timely manner. This requirement can likely be satisfied by verifying and documenting Amazon's patch management procedures.
Takeaway: It's unclear whether the cloud computing provider's applications (like Amazon's web services) must be assessed. Additionally, the cloud provider's patch management process should be verified and documented.
Requirement 7: Restrict access to cardholder data by business need to know
Amazon has stated that they do not have shell or other similar access methods to organization's running virtual images. So far, I am unable to find any literature from Amazon that explicitly states that the provider cannot read or modify companies' data with S3 or EBS. This concern should be addressed with the provider prior to a PCI assessment. It's likely that even if this data is encrypted and Amazon can only access the cipher-text containing cardholder data, this will still not satisfy requirement 7.
Takeaway: Organizations should verify Amazon administrators cannot access or modify data (encrypted or unencrypted) within EBS or S3 storage.
Requirement 8: Assign a unique ID to each person with computer access.
While this section applies to standard items such as remote access user accounts and web application user accounts, it also applies to the management and manipulation of virtual images within Amazon EC2. Currently, Amazon does not include the ability to create multiple user accounts to be assigned to various system or network administrators within an organization. This means everyone must share a single account to turn on images, remove images, and make firewall changes.
One way this can be addressed is by creating a custom interface to Amazon's API. The custom interface should require users to login with unique user accounts. Services such as RightScale provide this functionality as well.
Takeaway: Roll your own interface to Amazon's API or leverage third party services like RightScale for requiring unique accounts and assigning privileges to administrators of the company's virtual infrastructure.
Requirement 9: Restrict physical access to cardholder data.
Data centers containing cardholder data should have controls in place to ensure only authorized individuals can gain physical access to network devices and systems. In order to be compliant, companies may need to verify and document how the cloud provider satisfies physical security concerns for requirement 9.
Takeaway: Organizations will need the cloud provider's cooperation to verify physical security requirements in the PCI standard are satisfied.
Requirement 10: Track and monitor all access to network resources and cardholder data.
Tracking and monitoring data access, creation of logs, and retention of logs are all items that a company can control within the cloud without the service provider's help. This section also requires internal/external network and application vulnerability scanning and penetration testing. Organizations can create vulnerability scanning engines and remote penetration testing boxes to satisfy these requirements, however the cloud server provider should be notified before performing any of these tests.
Implementation of a network intrusion detection/prevention system within the cloud may be difficult for organizations, but it may be sufficient to implement host intrusion detection software on each virtual image.
Takeaway: Create virtual images to complete tasks such as vulnerability scanning and penetration testing. Investigate the ability to implement a network intrusion detection system. If this is not possible evaluate whether host intrusion detection software is an appropriate mitigating control.
Requirement 12: Maintain a policy that addresses information security for employees and contractors.
Organizations will need to create security policies and procedures around management of resources within the cloud provider's infrastructure. Since cloud computing is somewhat new, this may be easier said than done.
Takeaway: In addition to existing information security policies, documentation need to be written regarding appropriate use and management of resources within the organization's virtual infrastructure.
References:
PCI DSS version 1.2
Amazon's AWS Security Whitepaper
As I began researching cloud computing, one question I continually asked others is how payment card applications or data could be placed in a cloud computing provider's infrastructure in a PCI-compliant manner. So far, I have not received a definitive answer to this question.
In order to understand the implications of this question, I decided to read through the PCI standard and try to determine what controls would need to be in place for an example company and implementation. In this example, a fictitious financial services company wishes to leverage Amazon's EC2, EBS and S3 offerings to host a loan payoff application and its data. This application allows customers to view current loan information and pay balances using a credit or debit card.
The network and server architecture for this system will be identical to the "Basic Failover Architecture" presented in RightScale's wiki. The application will be written in Java and the database will be SQL Server 2005. Database backups will be encrypted and archived using Amazon's S3 cloud storage. Communication between the client and the web server, the web server and the database server, the master database server and the slave database server, and the database servers and Amazon's S3 service will be encrypted using SSL.
PCI DSS Scope
The PCI DSS document, page 5, states network segmentation of credit card data or activities may limit the scope of a PCI assessment. The PCI assessor must evaluate the effectiveness of network segmentation controls and then make a decision based on these results.
In a cloud computing environment, there are both physical and virtual infrastructure devices that provide segmentation. Amazon's Security Whitepaper discusses the following components that provide segmentation:
- Configurable firewall (implemented at the Hypervisor layer)
- Strong separation of guest OS and Hypervisor
- Instance isolation (separation of running virtual images)
- Prevention of packet sniffing by other tenants
- Configurable "security groups" (similar to VLANs)
Takeaway: "segmentation" needs to be evaluated as it applies to virtual infrastructure and Amazon's physical infrastructure.
PCI DSS and Third Party Service Providers
Page 6 of the PCI standard discusses situations in which a company uses a third party service provider to provide cardholder data services. This section states that an assessor must clearly state which third party components should be included within a PCI assessment. The third party must have a PCI assessment conducted; however this assessment can be conducted at the time of the assessment of the original company. This means that cooperation from cloud computing service providers may be required to gain PCI-compliance for components within the cloud.
Takeaway: Companies will need to establish compliance of at least some of the cloud provider's components AND companies will likely need cooperation from cloud providers in obtaining PCI compliance.
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
There are a number of items within this requirement that refer to creating network diagrams, implementing firewalls, and other similar network controls. Organizations can easily fulfill these requirement as they apply to the virtual infrastructure within the cloud using the provided "security groups", Hypervisor firewall, and other similar features.
The unanswered question is to what extent the requirement applies to Amazon's physical infrastructure. This is particularly a problem if servers are constantly being spun up or down to automatically adjust based on needs/requirements. In addition, Amazon's S3 storage mirrors data across a number of geographically diverse locations. Documenting and assessing Amazon's the physical network for PCI is very tough. On the other hand, it may be sufficient to assess a sample of Amazon's data centers or physical network devices where data or servers could potentially be located.
Takeaway: It is unclear to what degree the cloud provider's physical architecture will need to be assessed in addition to the organization's virtual infrastructure.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
This section concerns default passwords, disabling unnecessary services, secure configuration of components, and the use of SSL. Most of this information applies to the virtual infrastructure.
However, item 2.4 and Appendix A list requirements that apply to shared hosting providers. These rules are concerned with segmentation of cardholder data, logging and forensics. Based on the controls implemented by the Hypervisor as well as authentication and authorization controls in place for accessing cloud storage, it is likely segmentation controls are satisfied. Logging and forensics concerns may require the creation of virtual images suited for these purposes or may require cooperation from the cloud computing provider.
Takeaway: Companies may need to plan ahead and/or get cooperation from cloud providers regarding logging and forensics. Specialized virtual images can be created to assist with forensics or incident investigation.
Requirement 3: Protect stored cardholder data and Requirement 4: Encrypt transmission of cardholder data across open, public networks
Secure storage and transportation of cardholder data is an important aspect of the PCI standard. Controls outlined in the document can be easily accomplished by the company implementing the virtual infrastructure. These companies are fully capable of encrypting data before storing it within EBS or S3, utilizing full disk encryption within virtual images, and leveraging SSL to securely send sensitive data between components.
Takeaway: This requirement can be satisfied without the cooperation of the cloud computing provider.
Requirement 5: Use and regularly update anti-virus software or programs
Anti-virus can easily be applied to virtual images. It may also be necessary for companies verify and document the cloud provider's use of anti-virus as it applies to Host OS's, cloud storage, and other related components.
Takeaway: Companies should verify and document the cloud provider's use of anti-virus on Host OS's, cloud storage, and other components.
Requirement 6: Develop and maintain secure systems and applications
I am going to separate this section into two parts. One part is concerned with the secure development of custom applications. While it is straight forward to understand how this applies to the company implementing the virtual infrastructure, its not as clear whether items like Amazon's web services need to be pen-tested or verified. Hopefully, Amazon has already completed an assessment on these components and organizations can simply receive a high-level overview of the result.
The second part is concerned with applying security updates in a timely manner. This requirement can likely be satisfied by verifying and documenting Amazon's patch management procedures.
Takeaway: It's unclear whether the cloud computing provider's applications (like Amazon's web services) must be assessed. Additionally, the cloud provider's patch management process should be verified and documented.
Requirement 7: Restrict access to cardholder data by business need to know
Amazon has stated that they do not have shell or other similar access methods to organization's running virtual images. So far, I am unable to find any literature from Amazon that explicitly states that the provider cannot read or modify companies' data with S3 or EBS. This concern should be addressed with the provider prior to a PCI assessment. It's likely that even if this data is encrypted and Amazon can only access the cipher-text containing cardholder data, this will still not satisfy requirement 7.
Takeaway: Organizations should verify Amazon administrators cannot access or modify data (encrypted or unencrypted) within EBS or S3 storage.
Requirement 8: Assign a unique ID to each person with computer access.
While this section applies to standard items such as remote access user accounts and web application user accounts, it also applies to the management and manipulation of virtual images within Amazon EC2. Currently, Amazon does not include the ability to create multiple user accounts to be assigned to various system or network administrators within an organization. This means everyone must share a single account to turn on images, remove images, and make firewall changes.
One way this can be addressed is by creating a custom interface to Amazon's API. The custom interface should require users to login with unique user accounts. Services such as RightScale provide this functionality as well.
Takeaway: Roll your own interface to Amazon's API or leverage third party services like RightScale for requiring unique accounts and assigning privileges to administrators of the company's virtual infrastructure.
Requirement 9: Restrict physical access to cardholder data.
Data centers containing cardholder data should have controls in place to ensure only authorized individuals can gain physical access to network devices and systems. In order to be compliant, companies may need to verify and document how the cloud provider satisfies physical security concerns for requirement 9.
Takeaway: Organizations will need the cloud provider's cooperation to verify physical security requirements in the PCI standard are satisfied.
Requirement 10: Track and monitor all access to network resources and cardholder data.
Tracking and monitoring data access, creation of logs, and retention of logs are all items that a company can control within the cloud without the service provider's help. This section also requires internal/external network and application vulnerability scanning and penetration testing. Organizations can create vulnerability scanning engines and remote penetration testing boxes to satisfy these requirements, however the cloud server provider should be notified before performing any of these tests.
Implementation of a network intrusion detection/prevention system within the cloud may be difficult for organizations, but it may be sufficient to implement host intrusion detection software on each virtual image.
Takeaway: Create virtual images to complete tasks such as vulnerability scanning and penetration testing. Investigate the ability to implement a network intrusion detection system. If this is not possible evaluate whether host intrusion detection software is an appropriate mitigating control.
Requirement 12: Maintain a policy that addresses information security for employees and contractors.
Organizations will need to create security policies and procedures around management of resources within the cloud provider's infrastructure. Since cloud computing is somewhat new, this may be easier said than done.
Takeaway: In addition to existing information security policies, documentation need to be written regarding appropriate use and management of resources within the organization's virtual infrastructure.
Thursday, February 19, 2009
Create a Security Strategy Before Utilizing Cloud Computing
Cloud computing providers such as Amazon EC2/S3, Microsoft Azure, or Google AppEngine offer pay-as-you-go services for hosting data, applications, servers, or entire data centers using the provider’s infrastructure. Cloud computing enables customers to scale resources up or down based on demand. This allows large retail web sites like Target.com handle an exponential growth in web traffic during “Black Friday” sales without wasting money on additional hardware that will only be used a few times a year.
Cloud computing resources are said to be elastic in that the customer can instantiate 5,000 machines within the cloud and only use (and pay for) the resources for two hours. HIPAA-compliant companies like TC3 Health use this strategy for processing months or years worth of healthcare claims in a short period of time.
Cloud storage can be leveraged to store large amounts of data in a highly available, globally accessible, fault tolerant manner. These benefits lead Nasdaq to add 30 to 80 gigabytes of data to Amazon’s S3 storage daily.
Cloud service providers like Amazon are partnering with big technology players like IBM, Oracle, Sun, and RedHat to appeal to enterprise clients. Experts predict that as offerings and underlying technologies mature, Fortune 500 companies will soon incorporate cloud computing into their business and IT strategy.
Companies who wish to adopt cloud computing should identify how their risk profile will change after moving from a traditional data center to a virtual one. Examples of security and compliance risks companies should address before adopting cloud computing are listed below. There are a large number of business risks to consider as well. The list below does not include any business risks.
Animoto
Target.com
TC3 Health
Nasdaq
Here are several popular cloud computing providers:
Amazon AWS
Microsoft Azure
Google AppEngine
SalesForce.com
Mosso Cloud Sites/Files
GoGrid
Cloud computing security papers:
Above the Clouds: A Berkeley View of Cloud Computing
Cloud computing resources are said to be elastic in that the customer can instantiate 5,000 machines within the cloud and only use (and pay for) the resources for two hours. HIPAA-compliant companies like TC3 Health use this strategy for processing months or years worth of healthcare claims in a short period of time.
Cloud storage can be leveraged to store large amounts of data in a highly available, globally accessible, fault tolerant manner. These benefits lead Nasdaq to add 30 to 80 gigabytes of data to Amazon’s S3 storage daily.
Cloud service providers like Amazon are partnering with big technology players like IBM, Oracle, Sun, and RedHat to appeal to enterprise clients. Experts predict that as offerings and underlying technologies mature, Fortune 500 companies will soon incorporate cloud computing into their business and IT strategy.
Companies who wish to adopt cloud computing should identify how their risk profile will change after moving from a traditional data center to a virtual one. Examples of security and compliance risks companies should address before adopting cloud computing are listed below. There are a large number of business risks to consider as well. The list below does not include any business risks.
- Compliance – When processing or storing credit card, banking, healthcare, or personally identifiable information within the cloud, organizations should create a strategy for ensuring the virtual implementation and the service provider will be compliant with relevant regulatory requirements or security standards.
- Application Layer Security – Organizations should assess whether new vulnerabilities related to accessing cloud storage, cloud databases (Amazon’s simpleDB, Google’s BigTable, or Microsoft’s SQL Data Services), or other technologies have been introduced into application code.
- Operational Security – A documented set of policies should be created regarding the use and management of cloud computing resources. For example, most cloud computing providers utilize a single set of credentials for making changes to the virtual data center. Organizations should not provide these credentials to every data center administrator nor should changes be made without proper approval. In addition, organizations should discuss the service provider’s operation security policies to ensure an appropriate level of assurance is provided.
- Incident Response – Organizations should identify a strategy for performing incident response within the cloud. This may require cooperation from the cloud computing service provider, or a custom incident response machine image for services like Amazon EC2 or GoGrid.
Animoto
Target.com
TC3 Health
Nasdaq
Here are several popular cloud computing providers:
Amazon AWS
Microsoft Azure
Google AppEngine
SalesForce.com
Mosso Cloud Sites/Files
GoGrid
Cloud computing security papers:
Above the Clouds: A Berkeley View of Cloud Computing
Subscribe to:
Posts (Atom)
Posts
