Tag Archives: compliance

Your Pets Don’t Belong in the Cloud

At too many organizations, I’ve seen a dangerous pattern when trying to migrate to public Infrastructure as a Service (IaaS) i.e. Cloud. It’s often approached like a colo or a data center hosting service and the result is eventual failure in the initiative due to massive cost overruns and terrible performance. Essentially, this can be attributed to inexperience on the side of the organization and a cloud provider business model based on consumption. The end result is usually layoffs and reorgs while senior leadership shakes its head, “But it worked for Netflix!”

Based on my experience with various public and hybrid cloud initiatives, I can offer the following advice.

  1. Treat public cloud like an application platform, not traditional infrastructure. That means you should have reference models and Infrastructure-as-Code (IaC) templates for the deployment of architecture and application components that have undergone security and peer reviews in advance. Practice “policy as code” by working with cloud engineers to build security requirements into IaC.
  2. Use public cloud like an ephemeral ecosystem with immutable components. Translation: your “pets” don’t belong there, only cattle. Deploy resources to meet demand and establish expiration dates. Don’t attempt to migrate your monolithic application without significant refactoring to make it cloud-friendly. If you need to change a configuration or resize, then redeploy. Identify validation points in your cloud supply chain, where you can catch vulnerable systems/components prior to deploy, because it reduces your attack surface AND it’s cheaper. You should also have monitoring in place (AWS Config or a 3rd party app) that catches any deviation and  automatically remediates. You want cloud infrastructure that is standardized, secure and repeatable.
  3. Become an expert in understanding the cost of services in public cloud. Remember, it’s a consumption model and the cloud provider isn’t going to lose any sleep over customers hemorrhaging money due to bad design.
  4. Hybrid cloud doesn’t mean creating inefficient design patterns based on dependencies between public cloud and on-premise infrastructure. You don’t do this with traditional data centers, why would you do it with hybrid could?
  5. Hire experienced automation engineers/developers to lead your cloud migration and train staff who believe in the initiative. Send the saboteurs home early on or you’ll have organizational chaos.

If software ate the world, it burped out the Cloud. If you don’t approach this initiative with the right architecture, processes and people, there aren’t enough fancy tools in the world to help you clean up the result: organizational indigestion.

burping_cloud

 

Tagged , , , , , , , ,

PCI Purgatory*

*Updated: Now with Extra Snark!

Let me clarify, I’m not a QSA, ISA or any other type of SA**. But as the senior architect for a security team, I’m usually expected to have the last word on technical implementations. Like many, I’ve been stuck in PCI purgatory since the release of the 3.0 standard. New requirements to interpret, countless discussions with the QSA and the acquirer, arguments with the rest of the organization who barely understand payments and think they get to have an opinion: it makes me want to shred all my own credit cards. In addition to the scoping changes with ecommerce, the Service Provider definition was modified.

Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).
Okay, I admit it, I didn’t pay much attention to this. It didn’t really seem that different. But the devil is in the nuanced PCI details. We recently engaged a contractor who performs third-party security for my organization. He was new to PCI DSS and we wanted to modify our TSP questionnaire to capture PCI DSS status if the partner was capturing payment card data for us and interacting with our payment processor on our behalf, using our merchant ID. He actually READ the new standard, pointing out that these entities were now considered service providers and to my horror, I discovered he was correct. I also realized that EVERYONE seems to be freaking out over this, most getting it completely wrong.

If there was even one iota of doubt left in my mind, this section from the PCI DSS Information Supplement: Third Party Security Assurance resolved it:

Examples of ThirdParty Service Providers

Below are examples of types of services and providers with which an entity may work:

  • Organizations involved in the storage, processing, and/or transmission of cardholder data (CHD). Third-party service providers in this category may include:
    • Call centers
    •  E-commerce payment providers
    •  Organizations that process payments on behalf of the entity, such as a partner or reseller
    • Fraud verification services, credit reporting services, collection agencies
    • Third-party processors
    • Entities offering processing-gateway services
  • Organizations involved in securing cardholder data. TPSPs in this category may include:
    • Companies providing secure destruction of electronic and physical media
    • Secure storage facilities for electronic and physical media
    • Companies that transform cardholder data with tokenization or encryption
    • E-commerce or mobile-application third parties that provide software as a service
    • Key-management providers such as key-injection services or encryption-support organizations (ESO)
  •  Organizations involved in the protection of the cardholder data environment (CDE). TPSPs in this category may include:
    • Infrastructure service providers
    • Managed firewall/router providers
    • Secure data-center hosting providers
    • Monitoring services for critical security alerts such as intrusion-detection systems (IDS), anti- virus, change-detection, compliance monitoring, audit-log monitoring, etc.
  • Organizations that may have incidental access to CHD or the CDE. Incidental access is access that may happen as a consequence of the activity or job. TPSPs in this category may include:
    • Providers of managed IT delivery channels and services
    • Companies providing software development, such as web applications
    • Providers of maintenance services

So stop arguing with reality (and me). Oh and for the record, I don’t care what you, your mom, your dry cleaner, or another merchant thinks about PCI. I love those people who spend 30 minutes going through the standard and think they understand it because they’ve read the words. As most of us know who’ve worked with PCI for any amount of time, it’s a bit like pornography. Everyone has a different definition. As far as security and compliance teams are concerned, the only opinions that matter come from the acquirer, the QSA and the organization’s ISA. Moreover, a security team for an organization usually has thousands of hours of combined experienced in PCI DSS. A non-practitioner offering us “suggestions” is the equivalent of someone offering Misty Copeland advice about her grand jetes after taking one ballet class.

**Qualified Security Assessor, Internal Security Assessor

Tagged , , ,
%d bloggers like this: