Get My Score

Securing Modern Workloads

Securing Modern Workloads

This is the first blog in a series detailing workload best practices.

Per WikipediaA workload is the amount of work an individual has to do. There is a distinction between the actual amount of work and the individual's perception of the workload. Workload can also be classified as quantitative (the amount of work to be done) or qualitative (the difficulty of the work)”.

A more technical definition isThe amount of work performed by an entity in a given period of time, or the average amount of work handled by an entity at a particular instant of time”.

Various industry experts collectively define application, operating system, and middleware as a workload. Different workloads have different characteristics, and the best platform for a workload to run on depends on the nature of the specific workload. Expanding this idea further, typically in the cloud, workloads are segregated and categorized based on:

  1. Memory Footprint
  2. CPU Footprint
  3. I/O Footprint
  4. Distribution Footprint 
  5. Time Footprint

Let us briefly look at these.

  1. Memory intensive workloads – These workloads are typically oriented towards huge memory demands. Today these are modeled around production databases, in-memory databases such as SAP HANA, big data processing requirements such as Apache Spark or in-general high performance computing applications.

On AWS, these are called Memory optimized instances.

On Azure, these are called G-series VMs.

On GCP, these are called High-memory machine types.

  1. CPU intensive workloads – These workloads have high compute requirements. These are fulfilled using the latest processors and have significant boost for execution cycles per CPU wattage.

On AWS, these are called Compute optimized instances.

On Azure, these are called A-series VMs.

On GCP, these are called High-CPU machines.

  1. I/O intensive workloads – Here there are significant demands on IOPS while requiring low latency storage. For example, NoSQL databases.

On AWS, these are called Storage Optimized instances.

On Azure, these are called Ls-series VMs.

  1. Distribution footprint – These are not really VMs per-se but rather other workload execution mechanisms such as containers and unikernels. There are various cloud services that cover such workloads.

On AWS, it is called Amazon EC2 container service.

On Azure, it is Azure container service.

On GCP, it is Google Container Engine service.

  1. Time to execute – This is starting to get some traction. This refers to the serverless compute architecture where the actual code execution is handled by the cloud provider and billed based on the code execution time.

On AWS, it is called Lambda Functions.

On Azure, it is called Azure Functions.

On GCP, it is called Google Cloud Functions.

The solution to secure above varied workloads is easier said than done. There could be a plethora of security configurations that each one needs. Also, these workloads are heterogenous, multi-cloud or possibly hybrid in nature.

Some of the challenges you face are:

  1. You require a solution that supports agentless architecture – you can’t really install agents on containers, unikernels and functions based workloads. Additionally, you may not like the idea of agents consuming your critical CPU, Memory or IOs.
  1. You require a solution that supports your existing AuthN and AuthZ policies – you may not want to create a special IAM policy every time for a solution. Just a read-only policy is all that you feel is ideal.
  1. You require a solution that adapts to your scale – your cloud workload inventory is dynamic and regularly fluctuates to accommodate the needs of your business. You require security that adopts your flexibility and automatically stretch and compress as your business requirement demands.
  1. You require a solution that is available in the marketplace – it should be as easy as installing an app on your phone. Go to the marketplace, pick the solution and deploy it to protect you. That’s neat and handy.
  1. You require a solution that provides a single pane of glass – perhaps you don’t want to deploy multiple solutions for scanning your heterogenous workloads. A solution that could apply elastic fabric of assessments is much better. Moreover, a solution that cuts across the cloud and on-prem infrastructure is even better.
  1. You require a solution that understands heterogeneous workloads and dynamically adapts to the footprint. For example, you can’t really check for Linux partitions for container runtime. That configuration item is well suited for a full blown virtual machine only. A solution that could understand this minute details, is welcome! 
  1. You require a solution that could automate things for you. The security reports should be machine readable and it should be possible for you take automated actions on them. You are busy and seldom have time and interest to read the long security policy reports.
  1. You require a solution that could integrate with your existing software – You already have a SIEM, or Identity provider or Support desk. You need a solution that could read and write to these applications seamlessly. Out of the box interoperability is the key to your success.

Cavirin understands your workload requirements. We cover your heterogenous workloads both on the public cloud as well as on the hybrid cloud. We understand the challenges such as above that you face regularly and we are on a mission to exactly solve this one hard problem - continuous risk assessment to keep you aware of security drifts and continuously protect you.


© 2018 Cavirin Systems, Inc. All rights reserved.