Cloud service providers provide a variety of technologies such as logs, APIs, and native agents to help security teams achieve compliance, visibility, and control in the entire application stack.
In a cloud environment, security responsibilities are shared by the cloud service provider (CSP) and the corporate security team. In order to help the security team achieve compliance, visibility, and control in the entire application stack, cloud service providers and security vendors have added various innovative measures in different layers. In this article, we will compare these measures and provide a framework for companies to think about these measures.
Cloud service providers are launching new services at an alarming rate, enabling enterprise application developers to bring new business value to the market faster. For each new service, while cloud service providers assume more and more security responsibilities, they also enable corporate security teams to focus more on applications. In order to be able to provide visibility and security and enhance existing tools in this diverse and rapidly changing environment, cloud service providers provide logs, APIs, native proxies, and some other technologies for enterprise security teams to use.
2. Specific technical measures
There are many different measures to achieve security, and each measure has different trade-offs, including visibility and depth, ease of deployment, required permissions, cost, and scale of adaptation.
(1) API and log
APIs and logs are the best way to detect cloud accounts and discover unusual activities that are of interest to security teams in these accounts. Using these mechanisms, various account data can be easily obtained, and the security team can perform cross-account access to many accounts in the organization without having to do more work. This measure provides great visibility, but it needs to be supplemented by protective measures.
(2) Mirror and snapshot analysis
Mirroring and snapshot analysis is a good measure to obtain more in-depth workload data before and during application startup. This measure can analyze the disk image/snapshot of the running system to detect all anomalies, vulnerabilities, configuration events, etc. Snapshots provide in-depth data about the workload, but memory resident issues, such as fileless malware, may not be detected. In addition, as we move to temporary workloads, periodic analysis of snapshots may be of limited use. In addition, this mechanism may not be suitable for cloud services that cannot obtain disk snapshots. This measure provides in-depth data of the snapshot, but it needs to be supplemented with some protective measures to be effective.
(3) Native Agent and script
Native agents and scripts are a good measure. By providing a simple way to strengthen cloud native agents (such as SSM) to achieve deeper visibility and control. According to the functional principle, these agents can have a high resource utilization rate. Native Agent support is limited by the capabilities provided by cloud service providers, such as operating system support/functions. In many cases, the commands run by the native agent will record the required information, which means that we need to work in parallel with the logging measures.
(4) DaemonSet and Sidecar container
DaemonSet and Sidecar containers are a way to easily deploy agents in container and serverless environments. Sidecar allows each pod to run a container, which can provide in-depth data, but the resource usage and cost are high, because multiple sidecars will run on one server. Sidecar can work in a container serverless model, but the DaemonSet container cannot be used in this model. Since Sidecar and DaemonSet function like Agent, many of the Agent restrictions mentioned in this article also apply.
Agent provides the deepest visibility and best controllability of the operating environment of the application by running the code together with the application. However, this measure is difficult to implement because the security team needs to have in-depth host discovery capabilities in advance to deploy these agents. There is also resistance to installing the Agent, because it must run on every machine, and the security team does not have the authority to run software on every machine, especially in a cloud environment. Depending on the use cases supported, the resource usage and cost of this solution can be high. Newer technologies (such as the extended Berkeley packet filter eBPF) can reduce the agent’s resource consumption and make it easier to be widely accepted.
(6) Built-in mirror/code
The built-in mirror/built-in code measures allow security to be built into the deployed application mirror. This makes it possible to complete the deployment of security functions without deploying Agent on each workload. This measure provides in-depth visibility of the application, even for serverless workloads. However, since the code must be added during the build process, huge resistance will be added when the code is compiled, and it is necessary to provide code libraries for various application languages.
Each security measure has its own unique trade-offs. Since different teams use different platforms, no one measure can meet all the needs of various teams.
As time changes, different cloud services will be at different maturity levels. Security teams need to take a step-by-step approach, choosing easy-to-integrate solutions at the beginning of the service adoption cycle to provide basic protections for security and visibility. As the applications on the service mature and more high-value applications are gradually launched, it is necessary to provide more in-depth discovery and control security measures to supplement existing measures.
No single measure can satisfy all customer use cases, and different security solutions are at work at any time. We are moving towards a world where security measures are more diverse, and these measures must be combined to help protect corporate security.