Archive for the ‘Cloud Audit’ Category

Part II – PCI Cloud Computing Supplement: Technical Considerations

By Eric Sampson and Doug Barbin

In a previous article, we provided a summary of the key components of the PCI DSS Cloud Computing Guidelines (“cloud supplement”).  That article focused on roles, responsibilities, agreements, and audit considerations.  This article speaks more to the technical considerations.

Segmentation challenges

Cloud hosted environments often present new layers of responsibility for common shared layers, such as hypervisors and virtual infrastructure layers, which can present a single point of entry (or attack) for all systems above or below those shared layers.  The security applied to these layers is therefore critical not only to the security of the individual environments they support, but also to ensure that segmentation is enforced between different tenants’ environments.

Regardless of whether a hosted environment can achieve PCI DSS compliance, risks and threats persist, especially for shared cloud environments.  The need for adequate segmentation of client environments in a public or shared cloud is underscored by the principle that the other client environments running on the same infrastructure are to be considered untrusted networks.  The client has no way of confirming whether other client environments are securely configured or patched appropriately to protect against attack, or that they are not already compromised or designed with malicious intent.  This is particularly relevant where a cloud provider offers IaaS and PaaS services, as the individual tenants have greater control and management of their environments.

Virtualization Considerations

Virtualization requirements apply generally to cloud hosted environments.  The SSC had previously published the PCI DSS Virtualization Guidelines to discuss security considerations for virtual technologies.  In a complementary manner, the Cloud Guidelines reiterates some virtualization guidance and provides additional security considerations for cloud hosted environments.  Of note regarding technical considerations are the following:

  • VM-to-VM traffic does not pass through traditional network-based security controls, such as a firewall, router, or network IDS/IPS.  Rather, traffic can pass through virtual network routes.  The use of additional host-based security controls to monitor and control traffic, such as host-based firewalls and host-based IDS/IPS applications may be necessary.
  • Dormant virtual machines must be secured when dormant and not actively used for any period of time.  Security vulnerabilities can be introduced when dormant host is activated.  In the same vein, if a virtual machine can be removed and replaced, a malicious user can make modifications offline and introduce a malware infected virtual machine.
  • In cloud hosted environments, audit logs are available both at the virtual host and at the virtual machine operating system.  Cloud providers and tenants should discuss roles and responsibilities to ensure all audit logs are reviewed appropriately and in a timely manner.  Creating an environment where virtual host and virtual machine audit logs can be correlated into meaningful events is recommended.
  • Where the hypervisor has introspection capabilities, or the ability to control and monitor individual VM activity from outside the VMs, presents security challenges.  For instance, the introspection function allows files of VMs to be access within the privileged state of the hypervisor without an audit trail being generated by the VM.  This can present a greater concern for tenants of public, community, or hybrid cloud hosted environments than for tenants of private cloud services.  Tenants should be aware that any personnel with access to the introspection function on the hypervisor could potentially have access to data on any VM managed by the hypervisor.  Therefore, the introspection function should be carefully managed, controlled, and monitored to ensure that role-based access and segregation of duties is maintained.  For example, the hypervisor administration and hypervisor monitoring and auditing functions should be separated.

As noted in the previous article, many of the above issues apply equally in the world of SOC 1, SOC 2, ISO 27001 certification, and FedRAMP.

Please feel free to contact BrightLine if you have any additional questions.  BrightLine specializes in PCI validation for cloud providers.  We are also the only firm in the world that is a licensed CPA firm, PCI QSA, ISO 27001 certification body, and FedRAMP 3PAO.

Eric Sampson is a QSA at BrightLine who leads assessments for some of the largest SaaS providers in the US.  Doug Barbin is a Principal at BrightLine and the firm-wide practice leader for PCI.

 

SocialTwist Tell-a-Friend

Part I – PCI Cloud Computing Supplement: Know Your CSP!

By Eric Sampson and Doug Barbin

The writing is on the wall.  For many businesses, cloud providers are becoming a key component of IT and business strategies, service delivery capability and scalability, innovation, and delivering new service models and solutions to market.  For merchants and service providers that store, process, or transmit cardholder data, the PCI DSS provides the requirements necessary to ensure a secure and compliant cardholder data environment.  Until recently, guidance was limited to the interpretation of existing PCI standards, which never fully accounted for today’s evolving cloud computing models. The release of the PCI DSS Cloud Computing Guidelines (“cloud supplement”), attempts to align core PCI goals with a better understanding of cloud provider and cloud customer (“tenant”) responsibilities to maintain a compliant cloud-hosted cardholder data.  BrightLine had the privilege of participating in this group. The document is, by default, supplementary and as with all PCI supplements does not supersede, replace, or extend the PCI DSS requirements.  In fact, the cloud supplement states they are provided especially to “[present] recommendations for starting discussions about cloud services” in giving cloud providers and tenants a point of discussion for approaching their individual roles and responsibilities in meeting the PCI DSS requirements.” In the cloud supplement, the SSC describes the following important areas, to name a few, for understanding provider and client relationships:

  • Cloud provider deployment and service models
  • How roles and responsibilities may differ among tenants and cloud provider environments including segmentation and scoping considerations
  • PCI DSS compliance challenges
  • Contractual needs
  • Technical security considerations

Understanding the Models Generally speaking, cloud provider service delivery models can be categorized into one or more of the following three areas: Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS).  Cloud provider responsibilities over security and operational controls and meeting PCI DSS requirements tend to increase from an IaaS model (most client responsibility) to a SaaS model (least client responsibility).  In addition, cloud providers can deploy hosted environments differently.  Tenants need to understand the cloud deployment model being utilized or proposed for their cloud hosted environment.  Cloud deployment models include private, community, public, and hybrid cloud (a combination of private, community, and/or public). Tenents need to understand the level of oversight or visibility they will have into the security functions that are outside their control.  If these security responsibilities are not properly assigned, communicated, and understood, insecure configurations or vulnerabilities could go unnoticed and unaddressed, resulting in potential exploit and data loss or other compromise.  Cloud providers can help their tenants understand how the service models being offered affect their tenants in terms of roles and responsibilities.

Written agreements Once cloud provider and tenants roles and responsibilities for operation, management, and reporting are understood for each requirement, a formal agreement with clear policies and procedures should be defined.  Contractual agreements are especially critical where control responsibility is outsourced to ensure the required security measures are being met and maintained by the cloud provider for the duration of the agreement.

Mind the Gap Be mindful of when a CSP claims “PCI compliance” for their cloud environment.  It is not uncommon for a provider to sell data center, managed, and cloud services only to have the PCI ROC/AOC cover the data center component.  This is why it is critical that a tenant and their QSA be able to understand the scope of what was and was not covered to be able to determine if additional procedures are required. It is also important to note that many of the above issues apply equally in the world of SOC 1, SOC 2, ISO 27001 certification, and FedRAMP.

In the next article we will discuss some of the technical considerations presented within the supplement.

Eric Sampson is a QSA at BrightLine who leads assessments for some of the largest SaaS providers in the US.  Doug Barbin is a Principal at BrightLine and the firm wide practice leader for PCI.

SocialTwist Tell-a-Friend

BrightLine Principal, Doug Barbin, To Speak During the Knowledge Congress Webcast Series About PCI-DSS For The Cloud

Via Business Wire

PCI – DSS in the Cloud: Practical Guide for Cloud Computing Security and Compliance

Tampa, FL- BrightLine CPAs & Associates Principal, Doug Barbin, will be part of a two-hour live webcast on Thursday, April 4, 2013 from 12:00-2:00pm EST.  The live webcast will discuss the importance of Payment Card Industry Data Security Standard (PCI-DSS) compliance.  While the PCI-DSS remains to be a challenge for many organizations, PCI-DSS compliance in a cloud computing environment can be even more daunting. It is therefore vital for financial institutions, merchants, and service providers to be informed of the latest and most significant issues with respect to PCI-DSS to help ensure cloud computing security and compliance within the organization, while at the same time minimizing the risk of any potential pitfalls.

Barbin will be part of key panel of experts discussing the fundamentals of PCI-DSS, cloud provider responsibilities, virtualization infrastructure, audit and assessments, strategic initiatives, and legal and regulatory issues.  Unlike some events that often feature technology or service providers, Barbin will be the only QSA along with attorneys who specialize in cloud service agreements and breach litigation.

BrightLine is offering complimentary passes to this event to its clients and prospective clients.  If you would like to claim CLE/CPE hours, a nominal fee of $49 is charged.  Interested parties who would like to listen to the live webcast can click here to register.

ABOUT BRIGHTLINE

BrightLine CPAs & Associates is a leading provider of attestation and compliance services. BrightLine is the only company in the world that is a CPA firm, a globally licensed PCI Qualified Security Assessor, an ISO Certification Body and a FedRAMP 3PAO. Renowned for expertise tempered by practical experience, BrightLine’s professionals provide superior client service balanced by steadfast independence. BrightLine’s approach builds successful, long-term relationships and allows clients to achieve multiple compliance objectives using a single third party assessor.

 

SocialTwist Tell-a-Friend

Auditing DevOps – Developers with Access to Production

 

DevOps, like Agile development before it, accents the continuous evolving state of software development, particularly in cloud-base software.  Like any technology change, there is no surprise that auditor and security professionals are challenged as the traditional separation of duties line becomes more and more gray.  As someone who oversaw product management in an Agile / SaaS development environment and now manages audits and certifications for leading edge cloud solution providers, I offer my perspective.

Agile and DevOps are similar in the sense that they both emphasize communication, collaboration, and integration among software developers and IT operations personnel.  However, Agile also puts a heavy emphasis on the roles of the product owner (product manager) and end user.  We also must keep in mind that Agile has also been around for several years and has the luxury of multiple documented methodologies and frameworks.

DevOps is a response to the interdependence of software development and IT operations. Its goal is to help an organization rapidly produce software products and services. DevOps has actually been in practice for a few years, although gained US prominence with its use by companies such as Google and Facebook.  A good overview of the newer DevOps concept can be found on Gene Kim’s website as part of a book he, Patrick Debois, and others are is writing on the topic.  There is also a good presentation here.  In short DevOps includes the following key characteristics:

  • Use of Agile development processes
  • Increased collaboration between development and IT operations personnel going as far to create the blended “DevOps” role
  • Rapid and frequent releases (elevation to production), sometimes multiple times throughout the day
  • Increased automation for application development and production management, including heavy use of cloud and virtualized environments
  • Ability for development personnel to access production systems to troubleshoot and remediate issues that arise

So what does this mean to an auditor?  Testing separation of duties is as customary to IT auditing as testing password configurations.  Whether it is PCI, ISO 27001 certification, or an SSAE 16 examination, almost all assessments include some type of comparison between who has the ability to generate source code and who has the ability to promote it to production.  These controls are still important to the fundamentals of IT auditing and the underlying compliance requirements still hold true, that software development controls must provide reasonable assurance against unauthorized changes to production systems.

So now what?  Failed PCI assessments?  Qualified SSAE 16 opinions?  While it is true that separation of duties is one of the common reasons for SSAE 16 report qualifications, it is also an area that BrightLine has seen emerging trends towards heavy use of compensating controls for both SSAE 16 examinations and PCI validation.  The following are some examples:

  • Automated and traceable authorizations for promotion of code to production
  • Role-based access controls that acknowledge when DevOps personnel have access to production systems and document the specific use cases
  • Encryption and logical access controls which essentially “lock-out” the cloud provider from the data of its tenant customers
  • File integrity monitoring (and alerting) on changes to production code versus the traditional focus on critical operating system executable
  • File access monitoring on the source code itself with appropriate alerting
  • Extensive logging and daily, if not real-time, log review of the above data sources

It is important to note that from a monitoring perspective, changes to files must create notifications that span across functional groups.  In other words, a change alert must be sent not only to the DevOps team but to management and/or an independent security or compliance function within the company.  From a process perspective, the increased communication and collaboration inherently creates an environment whereby an unscheduled or unauthorized change is more likely to be noticed.  It goes without saying that there should be a documented follow-up and response process for any such notifications. Furthermore, daily deployments, coupled with necessary roll-back procedures allow the potential impact of an unauthorized change to be reduced.

Several people may argue that some of these compensating controls would be detective in nature and not preventative.  But what is the alternative?  Fail the control, qualify the opinion?  More importantly, was your organization really that much more secure under the traditional waterfall model?

As auditors, we need to do what we are supposed to do – understand the processes, evaluate the controls, identify the potential impacts / risks, and provide an independent report.  Then the users of the reports can make an intelligent decision as to whether or not they were better off with a traditional development methodology.  From my vantage point, DevOps and Agile are here and will continue to be so until a new approach that bends the rules even more is introduced.

 

SocialTwist Tell-a-Friend

Accounting Today / WebCPA – “An Introduction to SOC 2″

BrightLine’s Chris Schellman published an article in Accounting Today titled “An Introduction to SOC 2″  The article can be found here.

SocialTwist Tell-a-Friend

CSA, CloudAudit, & SAS 70 – Cats and Dogs Working Together

Over the past several weeks, there has been significant announcements made by the Cloud Security Alliance (CSA).  First, at the RSA conference in London, CSA launched version 1 of its Consensus Assessment Questionnaire.   In addition, CloudAudit.org, a group I am heavily involved with and co-chair the standards integration group, announced that it has merged with the CSA.

The purpose of this article is to speak to how the guidance and toolsets, created by CSA, along with the data sharing specifications developed by CloudAudit can actually improve your audits, including those commonplace and often controversial SAS 70 audits.

Stipulations and Rat-Hole Prevention

Before I get into how the work of CSA and CloudAudit impact SAS 70, SSAE 16, or other CPA attestations, the following topics are NOT addressed in this article:

  • Telling your customers you have a SAS 70 is not enough (a.k.a. the dead horse).  Covered here.
  • Marketers incorrectly market SAS 70s.  Covered here.
  • SAS 70 and SSAE 16 are for cloud services that impact financial reporting.  Other attestation alternatives are discussed here.

How CSA and CloudAudit Work with a CPA Attestations

The following diagram shows the key pieces that come together between the CSA, CloudAudit, and the independent practitioner or auditor.

Following the above diagram:

  1. The CSA has published original research about risks and threats to cloud computing forming the basis for its common body of knowledge.  The first publication was in April of 2009 and the current version(2.1) is from December of 2009.
  2. The CSA Cloud Controls Matrix (CCM) takes the risks identified by the guidance and aligns them to published standards and regulations such as ISO 27002, NIST, HIPAA, COBIT, and PCI to create a matrix of common control activities for cloud providers.
  3. The CSA Consensus Assessment Imitative (CAI) provides a standard questionnaire which asks yes/no questions to a cloud provider as to whether or not they meet the functional requirements from the CCM.
  4. CloudAudit.org – For those unfamiliar with cloudaudit.org, think of it as the “how” controls information is communicated, not the what.  Earlier this summer the group released an API specification which allows cloud providers to publish information to a defined directory structure (or namespace) which can be queried manually or utilizing automated tools such as GRC technologies.  It has also published compliance paks which allow providers to focus on controls related to specific standards like PCI or ISO 27002.  CloudAudit also has the added intent of incentivizing providers due to the fact that their competition may be doing so.
  5. All of the above, whether manual or automated through CloudAudit, form the basis for Management Assertions or what controls the cloud provider has put in place.
  6. These management assertions form the basis for the tests performed to ultimately issue a report that typically includes an independent practitioner’s opinion letter, description of controls, and results of substantive testing procedures regardless of whether the audit falls under SSAE 16 or one of the broader attestation standards under AT 101.

Rumor has it that the AICPA is currently evaluating CSA research and toolset to publish guidance in 2011 related to cloud computing and Service Organization Controls (SOC) frameworks.  While this is an excellent step forward, there is nothing stopping CPA firms from conducting this type of assessment today (or years ago for that matter).  Service providers have historically aligned with frameworks like COSO, COBIT, and ISO 27002 to the extent it makes sense for their business.  These controls and the organization provided by the frameworks are brought forward into the SAS 70, SSAE 16, and/or AT 101 reports.

This doesn’t mean the reports mean you re COBIT or ISO 27002 compliant, but an attestation report is meant to reflect the substance and form of a service provider’s controls.  All control assertions must be taken within the context of the audit or assessment itself.  For a cloud provider that hosts financial applications that impact financial reports, I would assess their CSA CCM-based security controls but also many others related to data processing, change management, and operations as part of an SSAE 16 assessment.

The bottom line is there is absolutely nothing stopping a cloud provider from adopting the controls set forth by the CSA, making the assertions that such are in place, and then having their auditor come attest to the same.  Furthermore, if a provider uses a mechanism such as CloudAudit.org to make and share their assertions, it will reduce the amount of time (and cost) spent gathering data and understanding the environment.  This ultimately allows the auditor to focus on their core mission of analysis, testing, and the issuing of opinions and not data gathering.

Expect more announcements to come as the CSA holds its annual meeting in Orlando this coming week!

SocialTwist Tell-a-Friend