Archive for the ‘Cloud Computing’ 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

High Profile Security Events Teach Important Lessons

Source – The Tampa Bay Technology Forum

With the millions of Apple IDs stolen earlier this month and the recent Go Daddy DNS outage, many organizations have started to reassess their own security and resiliency plans. Even if you were not one of the millions of people or companies directly affected from these incidents, there is no better time to reflect on the lessons learned and start implementing leading practices. The following are a few lessons we believe everyone should consider when it comes to outsourcing and data privacy.

Lesson 1 – During an Incident, Be Weary of the Hyper-Reporting

The Twittersphere and news media are hardly reliable sources for technology topics on good days, let alone when something bad happens. With Apple, it was reported that the missing data was stolen from an FBI laptop, only to find out later that they were actually taken from a Florida-based publishing firm. In the case of Go Daddy, early reports led us to believe that hacktivists caused the DNS failure; however, Go Daddy firmly refutes that any external influences caused the failure. So during an incident, always apply a healthy dose of skepticism to reporting.

Lesson 2 – Sweat the Small Stuff

It sounds obvious, but few companies have a bona fide incident management plan. That’s unfortunate because having a plan in place can substantially mitigate the potential impact of an incident. We witnessed a great example of why this is important last week when millions of websites relying on Go Daddy’s free DNS services failed. With widespread adoption of the Internet approaching the 20 year mark, a substantial portion of our IT community did not consider DNS failure a risk worth planning for prior to the Go Daddy failure. We can assume that points of failure previously thought to be remote possibilities will get much more attention going forward.

Lesson 3 – Know Your Partners

A message we tend to often hear is that a company may outsource a service, but it cannot relinquish the accountability for the potential risks to itself, employees, customers, and other stakeholders. This then leads us to the realization that company information may only be as secure or redundant as your vendors or business partners state so. An effective due diligence program is needed to monitor your third-party relationships. Companies can start with reviewing assurance reports (e.g SSAE 16 / SOC 1 or SOC 2 reports, ISO certification, etc.) and / or by conducting the appropriate first hand inquiries and inspections. These reviews will help provide comfort over the service organization’s internal controls.

Lesson 4 – Don’t Allow Vendors to be Single Points of Failure

While availability issues are more common, what if the company went out of business? If a company as large as Go Daddy can experience wide-spread problems, you should not think others are unsusceptible. If your service involves data being stored with the third-party, maintaining an independent backup is critical. Backup plans also include having access to other providers which may be able to step in and provide the services you need. Portability is supposed to be one of key selling points of cloud computing. Ultimately organizations should have the tools to either backup data or transition services to another provider in an emergency.

Lesson 5 – Integrate into Culture and Training

It might just seem like an additional item to add to the IT policy document or the growing list of mandatory training. However, you should encourage the significance of protecting non-public and critical data by provide data awareness training to your employees on a regular and consistent basis. As security and privacy audit professionals we default to look to technology or process-oriented solutions. However, what is clear is that the organizations that spend time undergoing training and awareness activities not only respond to incidents better, but they also better prevent them.

SocialTwist Tell-a-Friend

FedRAMP – 5 Things CSPs Should Already Know

I am delighted that BrightLine is now an accredited FedRAMP 3rd Party Assessment Organization (3PAO).  This is a testament to our extensive experience in the cloud service provider (CSP) space and  the qualifications and experience of a licensed CPA firm, PCI QSA company, and ISO 27001 certification body.

FedRAMP is a new federal government program with significant complexity pertaining to the overall authorization process, the assessment of CSPs, and how to attain, authority to operate (ATO) from a federal agency.  As one of the initial 3PAOs selected, BrightLine recognizes its responsibility to educate the CSP community about FedRAMP.

Over the coming months, you will hear from us on a variety of FedRAMP topics as we publish whitepapers; additional articles, and provide no-cost educational webinars.  In addition, BrightLine will provide one-on-one consultations with any CSP considering FedRAMP validation.

As an initial starting point, I have assembled what I believe to be the first five things a CSP should know when considering FedRAMP.

1. FedRAMP is an assessment program for any CSP seeking to provide services to federal agencies.

FedRAMP provides a standardized approach for baseline security assessment, authorization, and continuous monitoring of cloud products and services.  This new federal program is part of an overall strategy to reduce time and cost commitments incurred by agencies and CSPs.  Its “do once, use many times” framework reduces inefficiencies resulting from redundant agency security assessments.

2. FedRAMP will be mandatory for CSPs

While the deadline for implementation has not been finalized, FedRAMP is expected to be mandatory within the next three years.  However, “early adopters” are already starting the application process.

3. FedRAMP may be the most comprehensive audit your organization ever goes through.

Make no mistake; the assessment and the required preparation are extensive.  CSPs are required to adhere to a FedRAMP modified version of the NIST 800-53 control set which includes 296 controls across 17 domains.

For the actual assessment, BrightLine largely assumes responsibility for three major deliverables: the security assessment plan (SAP), security assessment report (SAR), and security assessment test cases, which document the testing of the above mentioned controls.

The CSP has responsibility for four noteworthy deliverables during the initial application process and approximately 12 others as part of the initial assessment.  This is in addition to documenting in-place security policies, procedures, and standards.  These detailed requirements are listed in section 10 of the FedRAMP Concept of Operations document and described further in various sections therein.  I highly recommend that any CSP considering FedRAMP authorization immediately read this “ConOps” document.

4. FedRAMP is not FISMA and CSPs are not FISMA-Certified.

The Federal Information Security Management Act (FISMA) is the regulation with which agencies must comply.  As part of their compliance, the agency is expected to assess the security of their third party service providers.  FedRAMP is a mechanism that allows agencies to bypass certain baseline controls testing by individual federal agencies.  The FedRAMP process does not result in a certification of any kind.  Furthermore, there is no such thing as FISMA “certified”.

5. A successful 3PAO assessment does not guarantee provisional authorization or ATO.

During the initial application process, CSPs are placed in prioritization by of the FedRAMP program management office (PMO).    An assessment cannot begin until the Joint Authorization Board (JAB) reviews the initial application and provides an approval to proceed with the process.

When the assessment is complete, the CSP submits the assessment reports and other documents as part of the authorization package.  The FedRAMP JAB performs an extensive review and, if approved, provides provisional authorization to the CSP.  Provisional authorization means that the FedRAMP PMO has verified the CSP’s compliance with FedRAMP requirements and listed the CSP on the centralized list of providers with provisional authorization.  Agencies will utilize that list as a starting point for to source cloud services.  Then, each agency must review the package and can decide if it wishes to grant ATO.  The agencies are free to impose additional requirements or request additional information as part of that process.

FedRAMP is a complex program with many moving parts. Therefore, it is very important to select a 3PAO that has in-depth expertise within the CSP space, experience reviewing and testing internal controls, specifically security controls, and the ability to provide other leveraged services to integrate compliance efforts.

BrightLine is actively working with many of our clients as they prepare for FedRAMP.  We provide executive orientation, on-site training and webinars, scoping and gap analysis. NIST 800-53 benchmarking, initial 3PAO security assessment, and mandatory annual 3PAO reassessment.

Additional information may be found on BrightLine’s website or on the FedRAMP website.  I recommend that you check both frequently.  Since FedRAMP is a new program, we expect a significant amount of new guidance to be posted over time.  Please contact us today if we can assist you.

SocialTwist Tell-a-Friend