The cybersecurity term “secure workloads” seems to be gaining a lot of traction in marketing materials lately. Yet, it has become a ubiquitous catchphrase that is often misused.
So, let’s cut through the fluff, and understand what “secure workloads” really are…
When it comes to cybersecurity, securing workloads means protecting all of the various components that make up an application (such as its database functionality).
In the past, delivering workloads securely was far simpler than it is today – since nearly every aspect of total workloads lived within an organization’s internal resources. Internal resources were trusted – and traffic going in and out of the organization was inspected at the perimeter. Workloads were protected using the age old “castle and moat” approach, with guards at the drawbridge checking everyone and everything going in and out.
Today, however, cloud computing has totally transformed the situation. Workloads (and portions thereof) regularly move across not only the internal organization, but over the Internet, and through one or more third-party cloud environments; there simply is no physical perimeter. Yet, somehow, the entire workload, for its entire lifecycle, must be kept secure – all resources must maintain their respective integrity, confidentiality, and availability; serious problems can occur if even a single part of a single workload is compromised.
Clearly, anything being transferred over insecure networks must be properly encrypted – but workload security entails much more than just encryption; it involves identifying, managing, and securing all relevant workloads, which, of course, if far easier said than done.
Various approaches to workload security typically involve (at a high level) some blend of the following:
• Micro-segmentation, in which workloads are divided and distributed into separate virtual segments, isolated from one another, in all environments in which they live. Such segmentation may occur not only at the network level, but also at layer 7 – controlling communications in and out of workloads on a per-application basis at the application-level of the OSI model.
• API Security functions that protect workload APIs from being accessed by entities that should not have access to particular API calls, whether such parties are external or internal to the organization, and regardless of whether they are situated on a local network or attempting to access via a “cloud” connection.
• Deploying security technology on a workload basis – for example, utilizing separate processes to scan each workload individually for vulnerabilities, for mistakes made by humans during installation and configuration, for corrupted data, and/or for the presence of malware, etc. Such a model also allows for different rulesets, with different evaluation criteria and actions-to-be-taken, to be applied to different workloads.
• Technologies to prevent lateral moves between workloads – preventing a party who has access to one workload from leveraging that access in some fashion to gain access to another workload. Such protection is essential, as without it, we cannot actually claim that workloads are actually isolated from one another.
• Filtering of all traffic entering cloud and internal environments at the application level to remove any malformed requests, content identified as malware based on signatures, content deemed risky based on heuristics, corrupted or malformed data, etc. Such an approach prevents problematic requests from reaching workloads – and, can sometimes protect more than one workload at a time.
• Virtualization, in which workloads are processed by different virtual machines that cannot see one another.
• A Zero Trust approach, in which effectively nothing is trusted until it actively establishes that it should be trusted. In such cases, the identities of workloads can be factored into authorization decisions. Of course, workload security is an integral element of any zero trust approach – because if workloads are compromised, it does not matter how well you authenticate requests – the responses to such requests may still be provided to unauthorized parties, or may be provided to authorized parties but with incorrect contents.
In short, why are secure workloads important? Because without them, our modern model of computing simply cannot function.
This post is sponsored by VMware.