Thursday, March 26, 2009

Software Assurance Maturity Model 1.0 Released

Pravir Chandra recently released the 1.0 version of the Software Assurance Maturity Model (SAMM). I recommend everyone visits the www.OpenSAMM.org website to review model. Jim Manico also interviewed Pravir on OWASP Podcast #14, where they discussed SAMM becoming an OWASP project and briefly discussed why two distinct models, the Building Security In Maturity Model (BSIMM) and SAMM have emerged.

The newest version of SAMM provides new introductory content including an executive summary and a clear explanation of the model's focus on providing security activities centered around business functions.

Version 1.0 also includes a guide for assessing organizations against the SAMM. Companies can use the provided worksheet consisting of yes or no questions to acertain the maturity of a software security development process. This could be applied to help:
  • Decide whether to purchase software from a vendor
  • Determine which software-as-a-service or cloud computing providers to select
  • Choose whether to develop software in-house or to contract out the work
  • Determine where the weaknesses in your organization's software security process are
  • Demonstrate progress in improving your organization's software security process
SAMM also includes roadmaps for various industry types. These roadmaps demonstrate Pravir's assertion that all organizations do not necesarilly need to have a maturity of "3" in ALL security practices. Sample roadmaps are defined for the following industry types:
  • Independent Software Vendor
  • Online Service Provider
  • Financial Services Organization (New)
  • Government Organization (New)
Again, I encourage everyone to review the Software Assurance Maturity Model at www.OpenSAMM.org.

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
  1. 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."

  2. 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."

  3. http://status.aws.amazon.com/s3-20080720.html
  4. http://aws.amazon.com/s3-sla/
  5. 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/