 top layer of the diagram illustrates various cloud implementations while the layers below it depicts the various approaches, technologies, con- trols, and organizations that impact the AIC security framework. The top layer depicts the spectrum of designs. They range from (a) an architecture that is based on a design with a single instance of OpenStack at a site, (b) to an architecture that is based on mul- tiple virtual instances of OpenStack within a site with a centralized control structure, and (c) to an architecture with a more distributed control structure and a more distributed tools structure. These designs impact the AIC security framework in many ways. From an individual OpenStack component perspective, the movement of OpenStack components can require new network routes, which must be evaluated and secured. In addition, as the OpenStack components evolve, they may require new interactions with systems outside of AIC. From an architecture perspective, changing the design (e.g., dual virtual OpenStack instances) can create new security requirements as a result of there being new flows and new connectivity. Each of these implementation options has defined solutions as to which security functionalities apply to each implementation. The next layer in the diagram highlights the fact that the network design has a significant role in the security framework. AIC is dependent upon many different types of networks, all with potential impacts to the AIC security framework. These networks include how AIC connects to external net- works or services, internal routing, and the use of virtualization. Two examples of how the various networks impact security include the use of SDN inside the environment (SDN-Local) and how net- works are connected. SDN-Local provides the ability to service chain capabilities. These capabilities can be security capabilities (e.g., FWs, data leakage protection) or could be application capabilities. Each of these will define or drive the security functionality needed and deployed to meet the