For many organizations moving to the cloud, Infrastructure as a Service (IaaS) like AWS EC2, Azure Virtual Machines or Google Compute Engine often forms the backbone of their cloud architecture. These services allow you to create instances of pretty much any operating system almost instantly.

Unfortunately, moving your IT infrastructure to the cloud doesn’t relieve you of your compliance or security obligations. Each public cloud provider publishes its own version of a shared responsibility model. In all of them, the customer, not the cloud provider, is responsible for operating system and application configuration security and compliance.

Responsibility for security and compliance do not go away when you migrate assets to the cloud. Rather, it becomes more challenging. According to a Gartner survey of 505 organizations that use public cloud services, 30% of them cited agility as their top reason for their adoption of cloud services (second only to cost savings at 34%). And no wonder. The ability to automate the deployment of assets allows organizations to scale their infrastructure up and down as needed, which also helps them achieve those cost savings.

The dynamic nature of IaaS either creates or magnifies challenges with which security and governance teams need to contend. For example, when a new EC2 instance is created and started, how would you prove to an auditor that its configuration is compliant with PCI, SOX, HIPAA, or any other of a number of standards that organizations are required to comply with? How can you ensure that the system is configured securely when it starts up?

The lifetime of a physical server in an IT environment is often measured in years. This meant that there was often sufficient time during provisioning to get an agent installed and run a configuration scan before the server (Read more...)