In part one of my deep dive blog series on the Multi-Cloud Security Architecture, we addressed the foundational elements of the MCSA. This primarily focused on the architecture as being API-driven, distributed and independent from the underlying infrastructure. Now that we have addressed the foundational aspects that must be put in place, I will describe in greater detail what is included in the prevention layer of the Multi-Cloud Security Architecture.
The prevention layer speaks to the policy enforcement functionality of the system, including policy creation and segmentation. In order to take accurate and effective security actions to prevent attacks across the multi-cloud environment, it is necessary to deploy controls that are both ‘broad’ and ‘deep’. I use this phrase because it sums up the differences between a ‘security-rooted’ approach and the limited capabilities available within networking technologies.
Firstly, controls need to be broadly applicable across the diverse data center estate. What this means is that security controls must be deployed across on-premises private clouds, the variety of public cloud providers, as well as virtualized and physical environments. This assures the coverage of the security system across the entire IT attack surface, not just a limited part of the environment.
In addition to the increasing adoption of multi-cloud infrastructure, organizations are often operating in a ‘two speed’ IT world, by retaining legacy IT components for certain workloads (i.e. mission-critical applications that require uptime) while also sponsoring new greenfield cloud development for others (i.e. those that require on-demand scaling capabilities). This allows new developments to be unconstrained by limitations of the existing IT environment, which continue to be operated and need to be secured properly. So, as the potential attack surface is going to become quite diverse, security controls must be pervasive across this entire surface in order to reduce risk of attackers finding “gaps” to be compromised.
Also, security controls need to be broadly deployed regardless of network topology or underlying technology. This is partly since public cloud environments dictate their own networking stack, but also to prevent co-dependency between networking and security solutions with all the implications of technology lock-in.
Additionally, it is important to ensure that security controls can be deployed to protect a wide variety of workloads or endpoints. In many organizations, the storage appliance or mainframe is still as critical as the scale-out, cloud-optimized applications built upon open commodity platforms. The emergence of IoT-based technology within the enterprise that often support safety critical systems, such as security and medical devices, also require consistent security controls. These new platforms are examples of where agent technology might be challenged to be compatible across various operating environments.
A final aspect of the ‘broad’ control capability is the scaling property of any multi-cloud security solution. We need to be able to deploy controls in a linear ‘scale-out’ manner broadly across the ‘scale-out’ multi-cloud itself - which requires an API-driven approach, as discussed in part one of my blog.
‘Deep’ controls are necessary for the recognition and prevention of any but the most superficial or inexpert attacks, such as attackers that can bypass protocol-based filters. For a control to be considered deep, it needs to be able to establish context of the connection or transaction in a detailed and accurate manner. This context would include: the ability to understand the application utilizing a given protocol, additional information relating to user behavior and data access, and recognition of threat behavior buried deep within the communication itself. Typical technologies in this space may inspect deep into the communications or interact with a potential attacker in a way to better understand their intent. This approach is critical in establishing an accurate understanding of intent, to recognize attempts to conceal attacks and avoid false positives. Overall, deep controls improve the efficacy of the security system.
Policy enforcement isn’t the end for ‘deep’ processing capabilities. If we are to implement security best practices across the multi-cloud, rather than stranding silo’d functions in some DMZ and attempting to patch them into the data path with convoluted and complex traffic engineering techniques, then we need to incorporate deeper security functions ‘as-a-service’ for East to West traffic flows These functions include: the ability to prevent exploits against critical vulnerabilities, the ability to analyze user and application behavior, and the ability to interact deeply with endpoints communicating on unauthorized channels. All of these analytics capabilities provide increasingly useful context in assessing the intent of an actor. The deeper the understanding of behavior, the more accurate our detection can become. And, the more granular and assertive the controls we can apply in mitigation.
The final aspect of deep control is the ability to execute an action under certain conditions. For now, most data center security solutions are able to determine whether to allow or deny connectivity, which is a relatively limited set of tools. Alternatively, deep controls allow for traffic to be selectively processed in different ways, including quarantining and processing using a variety of different functions.
To summarize, broad and deep controls provide the prevention needed in the multi-cloud security architecture in regards to policy creation, enforcement, and governance. Come back next week to get the deep dive on the detection layer of MCSA and learn more about the pathway to multi-cloud security in our on-demand webinar.