My first piece in this series, The definition of cloud computing: Why it matters to IT security, established that...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
the cloud is more than just a collection of services offered by business entities. Rather, from a security perspective, the cloud is a single, interoperable system comprising interrelated subsystems designed to deliver specific sets of on-demand services across entities. In this case, we define a system as "a set of interacting or interdependent components forming an integrated whole," and a subsystem as "a group of independent but interrelated elements comprising a unified whole." Together, they deliver services voluntarily (e.g., when services are negotiated and paid for) or involuntarily (e.g., malicious services delivered through the dark or deep Web).
Yet upon refining our definition of the cloud, enterprises must now grapple for a better understanding of such a complex system. To do so, organizations can use the method of visualization, or prototyping.
In this tip, we'll explain how enterprises can apply visualization to implement better end-to-end-cloud protection.
Where to start
Visualizing the cloud and its related entities enables security professionals to explicitly define objects, elements, boundaries and relationships. Once defined, enterprises can discard assumptions and begin to develop strategies for meaningful implementation. The result is effective protection, without conflicts, gaps or ineffective protections, of those infrastructures for which security pros are responsible.
Organizations can begin the visualization process by documenting concepts using tools such as an affinity diagram, which enables the grouping of unorganized concepts into organized themes and exposes the connections between them. Figure 1 is an affinity diagram that shows the context of the cloud's components using the qualifiers of system and subsystem, along with the characteristics and service models from the previous article's affinity diagram.
The diagram identifies that the Internet and/or ISPs and what is known as the dark Web make up the overall system and/or cloud, and shows the relationships among the various subsystems and/or clouds. It exposes the nature of the superset relationship among the various components and their systems based on the elements they comprise. Basically, one component contains the same elements of another component, and where a component is a superset base of characteristics of the service model, this demonstrates a dependent relationship. For example, access control lists (ACLs) are a superset of firewall rules. Why? Because firewall rules specify what traffic is allowed or denied, and in the same vein, ACLs specify based on a subnet, host or domain.
An affinity diagram like this helps an organization identify the components of cloud computing to identify where security elements (technology, policy or process) can be added, and also reveal possibly unintended opportunities among systems, components and elements.
What kind of opportunities are available? Let's say an organization runs a heterogeneous environment. Management would like a single source of truth for authentication across Windows and Unix/Linux systems. A current-state visualization identifies all sources of authentication and their capabilities, providing the realization that Windows Server 2008 R2 running Active Directory (AD) with Lightweight Directory Access Protocol can accomplish the task that management requires. This measure also allows the organization to leverage existing staff who already manage AD, while eliminating the need for authentication, authorization and accounting services, and subsequently eliminating the cost of ownership involved with maintaining an AAA server.
How to utilize virtualization for cloud security
As we've now visualized the cloud from an end-to-end perspective, an organization can determine which clouds are inert, or closed, meaning they will have little or no control. The dark Web is closed, for example, because it has been built on demand and by unknown people, the majority of whom are likely involved in illegal ventures. Organizations have no control over the software or files downloaded from the dark Web, meaning they may be clean or infected with malware. A peer-to-peer, or P2P, host serving pirated technology today may be gone tomorrow. An enterprise also cannot control whether its Consumer as a Service technology becomes part of the dark Web either, if a remote employee's home network is compromised.
Open clouds, on the other hand, are those that potentially can be trusted to interact with an enterprise's own cloud. The open cloud is any cloud infrastructure that seeks trust relationships with other infrastructures within the Internet. Software as a Service, Infrastructure as a Service and Platform as a Service (or SaaS, IaaS and PaaS) are all open models, for example, so an organization has the ability to configure enough of the environment to support its needs as a business entity (the same holds true for an individual).
With this visualization in mind, the appropriate protections for the various cloud models can be determined by using the ideation, or idea generation, technique of reversal, which basically takes goals and assumptions and forces converse thought outside of expected paradigms.
For example, let's say that the goal of a company is to deliver cloud services to businesses that manage credit card transactions. Now, reverse that goal to ask the question, "How do we keep malicious actors from infiltrating our cloud services (e.g., from wireless/from a hacked PC/from a malicious URL)?"
Reversal enables one to think in the same vein as those who attack cloud infrastructures. When combined with use-case-based scenarios, it ensures protections can be applied against legitimate threats, thereby eliminating FUD and wasted resources, both human and financial. Well-developed and -structured visualizations are presented using a story arc model (the story is told in parts). The first is a concept to set the scene, identify roles and encourage brainstorming. The next is a high-level overview of three states: the current state (e.g., this is what the organization has), the interim state (this is how the organization got here), and the final state (this is the outcome and associated costs). Amongst the roles to be played in the story arc model is the focal character, who starts with a specific set of traits and is changed by the end of the story.
To again give an example of how this method can be deployed in a real-world scenario, imagine that an organization determines it will invest in best-of-class network intrusion protection technology. The end-to-end story is one of notifying and preventing intrusions. The roles are filled by edge devices, gateway devices, various hosts and clients. The focal character is the concept of intrusion prevention, which will change over the course of the story arc from a single endpoint product to an enterprise-grade suite of technology comprising many roles. Producing an end-to-end artifact enables one to use the process of reversal, allowing questions to be asked about how a host should be configured to either prevent an intrusion or to alert the organization to an incident.
Sample questions to be asked in such a scenario include these: How is intrusion prevention accomplished on a router? What about on our databases? Who has access? The process may even reveal a story within a story. For instance, where should all the events go? Do we have security information and event technology, or is our SIEM even capable of aggregating that amount of data? Visualizations help reveals gaps, set priorities and develop realistic roadmaps.
Of course, visualization is not a single-step process, but rather one that requires a series of visuals designed to meet an intended audience or offer multiple perspectives to a wide audience. It may take several visualizations to clarify intent and direction, but the final result should be a clear understanding of an organization's cloud infrastructure and what it takes to provide end-to-end cloud protection.
About the author:
Ravila Helen White is the director of IT architecture for a healthcare entity. She is a CISSP, CISM, CISA, CIPP and GCIH, and a native of the Pacific Northwest.