Managing Multi-Platform Clouds

Multi-Platform Cloud Software (MPCS) is a way for allowing the delivery of customized and scalable cloud services while deploying multi-vendor cloud technologies. It provides a solution for accessing a multiplicity of private and public cloud services simultaneously. It combines automated cloud services under unified governance and control for both virtual and physical servers and desktops. It applies to both private and public clouds. It unifies enterprise-wide policies while monitoring the costs of applications as seen from the user standpoint.

In order to make diverse cloud systems scale up to the enterprise level in large organizations, this issue must be first approached at the organizational level and only then worked down to individual clouds. DoD must be able to map the local cloud solutions before it would be in a position to address user-specific cloud services. This makes it necessary for DoD to set up a DoD-level software layer that enables aggregating already installed clouds into a capability that permits enterprise-level sharing of computing services.

MPCS software creates controls that define who can gain access to any local cloud. Central DoD management will then know where are all of the resources. It will have the knowledge what are the process for obtaining services from any component that is located anywhere. MPCS can offer the following:

1. Reservations. A cloud administrator can group computing resources (storage, network and compute) for management of from consoles at network control centers. The Reservation process then defines how DoD resources are organized, inclusive of the identification of costs.
2. Blueprints. Defines the computing environment such as security limitations, approval policies, cost profiles, service tiers, machine templates, SLAs, toolsets and methods (e.g. as offered by Amazon, Microsoft, Citrix, VMware and others) that users may be able to apply for access to their specific cloud.
3. Business-Aware Services.  MPCS will then have all of the information needed for extracting information from any designated cloud.
4. Personalization. Although the enterprise-level Blueprint contains everything needed to use data from a business unit that is insufficient. DoD will also need meta-data to describe the contents of all files. This would allow an enterprise administrator to give permissions for access to all information and thus make it possible to view DoD as a fully interoperable system from a user’s point of view.

SUMMARY
Multi-Platform Cloud Software reflects a realization that it will never be a uniform hypervisor that will manage enterprise data centers. What is needed is software that can manage VMware ESX, Microsoft Hyper-V, Citrix, and Oracle Xen-based hypervisors and Amazon Web Services' proprietary version of Xen, Amazon Machine Images.

With MPCS it will be possible to manage every suppliers' virtual machines as well, adding them to the on-premises, private cloud and extending its reach to workloads in the public cloud as well. This approach ultimately leads to a software-defined data center, where virtual machines are created and moved around as needed for most efficient operation. Instead of just managing virtual machines created under one hypervisor, it will be able to add other major hypervisors as well.

MPCS also fits the concept of central console for the software-defined data center, which brings configuration, performance management, and capacity management to virtual machine operations. The ability to collect information about each virtual machine as it is formed and to understand what share of a given task that virtual machine can perform, MPCS provides information to a system-of-systems that manages a variety of clouds at the same time.

The software vendor that knows how to use information derived from the configuration of different brands of virtual machines--and can manage their performance through MPCS--has gained the capability of becoming the dominant provider software-defined data centers. When capacity is needed anywhere in a diverse organization, it will be able to spin up additional virtual machines wherever they can be added seamlessly to the cluster, according to preset policies. When traffic wanes, MPCs will decommission virtual machines and consolidate those remaining on fewer physical hosts, according to preset policies.

While different clouds have different self-provisioning procedures, MPCS can pull it all together into a single cloud storefront across heterogeneous infrastructure pools for a giant organization such as DoD.

Questions about the Cloud Consolidation Policy

The main problem with migration into a cloud environment is siloed management. There are 3,000 separately funded IT projects in DoD. In each case there is hardly any funding available for cloud innovation. Contractors are overburdened while trying to serve customers to keep up with rising demands. The responses to requests for switching to cloud computing are slow while the poor utilization of $22.2 billion FY 13 O&M resources have the potential of funding such transformation. Meanwhile the processing capacity of DoD is sufficient to satisfy total needs. We have a good cloud migration strategy, but cannot progress further without a blueprint how to accomplish such a huge transformation.

DoD realizes that to gain economies of scale, it must share resources and automate configuration management at the enterprise level. Individual components are starting to turn to cloud vendors that provide solutions that promise to turn their operations into private clouds, such as Amazon EC2. Unfortunately that would creates only another isolated silo, even though a local CIO can then claim that progress is made in the desired direction.

DoD has too many business units that individually control their project budgets. Projects have different architectures. Projects have separate cost centers, versions of regulations, established policies and restricted funding. For instance there are 60 major programs in place that have matured over ten years, with total annual spending of $16 billion. These projects each contain numerous sub-contracts to support unique needs that cannot be satisfied by standard solutions that would be delivered through DISA brokerage.

Existing projects suffer from a lack of development and testing capacity. Each silo needs computing capacity quickly, but only for a short time. The testing and development capacity requirements differ depending on lease terms and locations.

Existing silos would be unable to share computing capacity for production. Compliance with supported software revision levels and patch management, such as offered by BMC, CA, Microsoft, HP, IBM and others, would prohibit the sharing of existing configurations.

Due to the relatively high cost of data center storage and desktop capacity existing silo administrators would be inhibited from deploying a standard approach to streaming a multiplicity of divers application software to a variety of virtual desktops. The diversity of over 500 data centers would prevent that without a massive data center consolidation effort that would have to precede cloud migration efforts.

Though virtualization of servers is only a partial step in the direction of cloud computing, that would not make it possible to share data from thousands of different databases. Any attempts to proceed with silo-level efforts virtualization would deliver only varying levels of automation, each with different scripts and a variety of incompatible vendor tools. When “cloud” capabilities are then enhanced for self-service inquiries that would have to fit rapidly changing data center resources. Shared cloud tools would have to include a level of policy, governance and automation to enable the cloud. This is so primarily because any cloud solution would have to be built in the context of a particular silo infrastructure, some of which is embedded in more than decade-long architectures. While this looks good on paper, such solutions would severely limit the scope how to operate across DoD.

One approach would be to include every cloud in a DoD-level service catalog. That would be replicated for each of the silos, creating a management nightmare when it comes to maintaining the service catalog for enforcing interoperability.

Regardless of the challenge of having to create a unified DoD configuration catalog, that would offer only a single standard set of interfaces to assure DoD-wide interoperability. Some systems and processes would have to be thrown out in favor of dumbed down cloud solutions that result from acquisitions that try to fit all needs. In all likelihood, most of such silo-level cloud solutions will have to fall out of the automation process due to variants that are needed to fulfill local needs, such as improvised social computing. With DISA designated exclusively only as the “broker” for making cloud acquisition choices, the chances are high that DoD will end up with new silos, each claiming some cloud capabilities but certainly not interoperable.

Consider the differences between how each DoD silo operates, the office of the DoD CIO will be faced with the enormous task of coordinating – through an elaborate committee structure - the details about software versions, machine naming, data definitions, network configuration, resource allocation, service levels, data center location and which management functions a user can perform after the silo has been completely restructured. There are hundreds of other attributes that will differentiate each silo as it migrates to cloud computing, but will remain incapable of enterprise-wide resource sharing.

SUMMARY

The just published “Cloud Computing Strategy” is an excellent policy-level document. It has not defined the specific steps that must be taken to proceed with implementation. What we have so far is not sufficient. Without implementation directions the current way of proceeding with silo-level clouds as well as with yet undefined DISA brokerage mission, the strategy is unlikely to achieve what is expected.

However, there are approaches that have already emerged how to set up a very large enterprise to operate with multiple cloud solutions.  In blogs that will follow, the operations

Centralized Access Control to Diverse Applications

Changes in the ways people are working have increased the pressure on organizations to access to their information assets anytime, anywhere. Employees are increasingly using non-desktop devices for work. Information assets now reside on the cloud, often outside of IT control. This requires separate access management that does not scale well. In addition, users are bringing their own applications to the workplace—often on their own devices—creating even greater problems. Through a hypervisor managed cloud it is now possible to simplify cross platform access to applications by centralizing management. Access to any SaaS, Web or Windows applications can be achieved through an Application Catalog that will deliver to end-users, on the device of their choice, on-demand connectivity.

Cross platform management centralizes policy-driven security controls, integrating with enterprise directory environment that enables access to virtualized applications.
From one central platform, IT can manage all SaaS, Web and Windows applications and view their usage. End users gain easy, on-demand access via their preferred devices.

A central Application Manager provides a cloud-identity platform for managing secure access to every SaaS application, regardless of the technology on which it was deployed. The identity access management (IAM) technology in unifies silos into a single identity, leveraging enterprise directories and enabling organizations to define access through enterprise polices. This increases the security, control and accountability for access to all information assets. Managers will gain control over user-access policies and can integrate into their existing workflow systems. Users gain on-demand access to all applications through an easy-to-use application catalog, a single Web-based workspace as result of a single secure login.

SUMMARY
A unified cross-platform capability is a giant step in the direction of simplification of secure access to a wide range of applications. This is particularly useful when applied to mobile applications where access privileges can be distributed to individuals from a central console. Such arrangement will make the deployment of a diversity of mobile devices feasible while maintaining control over access privileges.

Cost to Protect Secrecy

According to the New York Times, the federal government has spent over eleven billion dollars in 2011 to protect its secrets.[1]  This does not include the costs incurred by the CIA, NSA and other intelligence organizations. After adding the additional agencies, the total costs for protecting secrecy may exceed $13 billion.

This costs of does not involve only about $3.5 billion for IT security but also the expense for investigation and the granting of clearances, security training and the expense for security personnel.

SUMMARY
The cost of protecting the secrecy of government operations has risen at a steep rate. The administrative complexity of tracking security clearances from investigation to authorization has contributed to the steadily rising costs. Dozens of separate organizations are responsible and require standardization and speeding up.

[1]   Shane, S., Cost to Protect US Secrets, The New York Times, 7/3/2012, A11.

Cloud Outage Revives Reliability Concerns

Thunderstorms tore through the Mid-Atlantic region of the U.S. this weekend, causing widespread power outages that affected an Amazon Web Services datacenter in North Virginia.
Storms on the East Coast have shown us that disruptions in the cloud are inevitable, whether by the hand of Mother Nature or human mishaps. Enterprises have to respond with an infrastructure strategy that leverages the benefits of a cloud, and hedges that with a behind-the-firewall presence, giving them protection in a variety of circumstances.

Amazon's outage followed a day after another high profile cloud services providers experienced problems. On Thursday, several Salesforce customers in North America and Europe could not access the CRM platform due to "a rare dual-failure in our storage tier and in the active standby of our storage tie.

SUMMARY
A rare reported cloud failure incident does not reveal that for a premium price it is possible to purchase fail-over data processing. It is also not clear whether data centers without back-up generators were also prone to failure. It is unlikely that for the 700 DoD data centers there were sufficient fail-over provisions in place.

Back-up generators are now insufficient of high security applications. Even though electric power may be available, the communication connections from a data center may be also broken. Only a fully redundant multi-site distribution of fail-over clouds, such as now available from Google, can provide the  necessary safeguards  for essential critical applications.

Personal Access Control Systems (PACS)

Homeland Security Presidential Directive 12, Policy for a Common Identification Standard for Federal Employees and Contractors [HSPD-12] requires a common identification standard for federal employees and contractors, These identity credentials must be interoperable government-wide. This resulted in the Personal Identity Verification (PIV) Card, and associated documents, which technically define it. As of Q3 2011, the federal government has issued 4,270,560 PIV Cards to federal employees (91% of total federal employees) and 846,365 PIV Cards to federal contractors (81% of total federal contractors).


FIPS 201 (Federal Information Processing Standard Publication 201) is a United States federal government standard that specifies Personal Identity Verification (PIV) requirements for Federal employees and contractors.

FIPS 201 together with NIST SP 800-78 (Cryptographic Algorithms and Key Sizes for PIV) are required for U.S. Federal Agencies, but do not apply to National Security systems.

In addition, the federal government has implemented policy for non-federal issuers (NFIs) of identity cards to produce identity cards that can technically interoperate with federal government PIV systems and can be trusted by federal government parties. This resulted in the PIV Interoperable (PIV-I) Card. To-date the Federal Public Key Infrastructure (FPKI) has approved five PIV-I Card Issuers and one PIV-I Bridge. Conservative estimates for the number of active PIV-I credentials to be issued exceeds 25 million, serving non-executive federal, state and local agencies, first-responder organizations and others.
OMB designated GSA as the Executive Agent for government-wide acquisitions for the implementation of HSPD-12. OMB has directed federal agencies to purchase only products and services that are compliant with the federal policy, standards and numerous supporting technical specifications. In support of these mandates, GSA established the GSA FIPS 201 Evaluation Program Approved Products List.

PIV Card – is an identity card that is fully conformant with federal PIV standards. Only cards issued by federal entities can be fully conformant. Federal standards ensure that PIV Cards are interoperable with and accepted by all Federal Government relying parties to authenticate identity.

PIV-I Card – is an identity card that meets the PIV technical specifications to work with PIV infrastructure elements such as card readers, and is issued in a manner that allows federal and non-federal relying parties to accept the card to authenticate identity. PIV-I credentials provide identity proofing. Non-federal issuers make available PIV-I Cards. These must apply proofing process must be comparable with PIV that binds a card to a person. PIV-I does not assert that a background investigation was performed. Additional investigation requirements may be necessary based on actual assignment and asset risk.

In February 2011, OMB issued directives, which are applicable to end-users, integrators, solution providers, and manufacturers/developers, and mandates the following:

1. Effective immediately, all new systems under development must be enabled to use PIV credentials.
2. Effective the beginning of FY2012, existing physical and logical access control systems (LACS) must be upgraded to use PIV credentials.
3. Procurements for services and products involving facility or system access control must be in accordance with HSPD-12 policy and the Federal Acquisition Regulation.
4. Agency processes must accept and electronically verify PIV credentials issued by other federal agencies, and
5. The government-wide architecture and completion of agency transition plans must align as described in the Federal Chief Information Officers (CIO) Council’s FICAM Initiative.

PACS follow a process to authenticate users using one or more of a predefined set of credentials and then makes authorization decisions based on a predefined set of rules governing access. When this card is presented at an electronic reader, the identifier is checked against a proprietary, internal “white list” to make authorization decisions to a facility at an intended point of entry (e.g., door, turnstile, computer, laptop).

PACS are vulnerable to twenty-four cyber attacks that were listed in a table of common threats. The greatest exposure can be found in the communications between the security management system and the Certification Authority.

PIV and PIV-I cards are not applied in a uniform process. Depending on authentication mechanisms the cards can be deployed using a variety of methods. There are eight different versions of PIV and PIV-I cards:

1. Smartcard with crypto key, plus PIN with crypto proof, plus observed fingerprint. Three factor authentication.
2. Smartcard with crypto key, plus PIN with crypto proof, plus fingerprint. Three factor authentication.
3. Smartcard with crypto key, plus PIN with indirect verification assumption, plus observed fingerprint. Three factor authentication.
4. Smartcard with crypto key, plus PIN with crypto proof. Two factor authentication.
5. Card plus observed fingerprint. Two factor authentication.
6. Fingerprint. One factor authentication.
7. Smartcard with crypto key. One factor authentication.
8. Smartcard with printed security feature. One factor authentication.

SUMMARY
Physical Access Control Systems (PACS) allow organizations to assign different access requirements based on the risk of the physical asset being accessed. In this way, a PACS is used to mitigate the risk of a physical security breach. This makes PACS the most critical components of cyber defenses.
Over five million PIV cards have been issued plus over twenty-five PIV-I cards, each with twenty-four identified security vulnerabilities and multiples issuers. This makes the PACS the single greatest risk exposure for security compromises.

One important facet of a PACS is its authentication mechanisms. There are eight methods for identifying a PIV or a PIV-I. It is the combination of the widespread distribution of PACS plus the variety of authentication methods that makes the PACS managerially difficult to administer.

Software Defined Networks (SDN)

The explosion of mobile devices, server virtualization, and advent of cloud services are driving the networking industry to reexamine network architectures. Conventional networks are hierarchical, built with tiers of Ethernet switches and routers arranged in a tree structure. This design made sense when client-server computing was dominant. Such a static architecture is ill suited to the computing and storage needs of today’s enterprise data centers, campuses, and carrier environments.


Within an enterprise traffic patterns have changed significantly. In contrast to client-server applications where the bulk of the communication occurs between one client and one server, today’s applications access different databases and servers, creating a diversity of machine-to-machine traffic before returning data to the end user device. At the same time, users are changing network traffic patterns as they push for access to corporate content and applications from any type of device, connecting from anywhere, at any time and often using Voice and video over IP.

Enterprise data centers managers are now planning for a utility computing model, which might include a private cloud, public cloud, or some mix of both, resulting in additional types of traffic across the wide area network.

Enterprises have embraced both public and private cloud services, resulting in unprecedented growth of these services. Enterprise business units now want to access applications, infrastructure, and diverse IT resources on demand from a variety of network sources. To add to complexity, IT’s planning for cloud services must be done in an environment of increased security, compliance, and auditing requirements, along with business reorganizations, consolidations, and mergers that can change assumptions overnight. Providing self-service provisioning, whether in a private or public cloud, requires secure elastic scaling of computing, storage, and network resources, ideally with a common suite of tools.

Handling today’s “big data” datasets requires massive parallel processing on thousands of servers, all of which needs direct connections to each other. The rise of huge datasets is fueling a constant demand for additional network capacity in the data center. Operators of huge data center networks face the task of scaling the network to previously unimaginable size, maintaining any-to-any connectivity without going failing to support quality of service commitments.

In the SDN architecture network intelligence and state are centralized on virtual servers and not on switches or routers. As a result, enterprises gain unprecedented programmability, automation, and network control, enabling them to build software-based scalable, flexible networks that can instantly adapt to changing business needs.

The Open Networking Foundation (ONF), Software-Defined Networking (SDN) is transforming networking architecture by relocating many switching and routing functions from hardware to software. SDN is rolled out as follows:

1. Centralized management and control of networking devices from multiple vendors;
2. Improved automation and management by using common APIs to abstract the underlying networking details;
3. Delivery of new network capabilities without the need to reconfigure individual devices or wait for vendor releases;
4. Programmability by operators, enterprises, independent software vendors, and users (not just equipment manufacturers) using common programming environments;
5. Increased network reliability and security as a result of centralized and automated management of network devices, uniform policy enforcement, and fewer configuration errors;
6. Better end-user experience as applications exploit centralized network state information to seamlessly adapt network behavior to user needs.

SUMMARY
Networking technologies have so far operated with discrete sets of protocols designed to connect individual servers through routers and switches over arbitrary distances, link speeds, and topologies.
Protocols tended to be defined by vendors, with each solving a specific problem, on a specific device. This has resulted in the primary limitations of today’s networks: complexity and inflexibility. For example, to add or move any device, IT had to touch multiple switches, routers, firewalls, Web authentication portals, etc. and update VLANs, quality of services (QoS), and other protocol-based mechanisms using device-level management tools. In addition, network topology, vendor switch models, and software versions all had to be taken into account. Due to this complexity, today’s networks are relatively static as IT seeks to minimize the risk of service disruption.

The static nature of networks is in stark contrast to the dynamic nature of today’s environment, where server virtualization has greatly increased the number of hosts requiring network connectivity and fundamentally altered assumptions about the geographic location of hosts. Prior to virtualization, applications resided on a single server and primarily exchanged traffic with select clients. Today, applications are distributed across multiple virtual machines (VMs), which exchange traffic flows with each other. VMs migrate to optimize and continually rebalance server workloads, causing the physical end points of existing flows to change rapidly over time. VM migration challenges many aspects of traditional networking, from addressing schemes and namespaces to the basic notion of a routing-based design.

In addition many enterprises today operate an IP converged network for voice, data, and video traffic. While existing networks can provide differentiated QoS levels for different applications, the provisioning of those resources is entirely manual. IT must configure each vendor’s equipment separately, and adjust parameters such as network bandwidth and QoS on a per-session, per-application basis. Because of its static nature, the network cannot dynamically adapt to changing traffic, application, and user demands.

SDN allows direct access to and manipulation of network devices such as switches and routers, both physical and virtual. It is the absence of an open interface to these devices that has led to the characterization of today’s networking devices as monolithic, closed, and mainframe-like. Protocol like SDN is needed to move network control out of the individual switches to centralized control software.
SDN control software can control any SDN-enabled network device from any vendor, including switches, routers, and virtual switches. Rather than having to manage groups of devices from individual vendors, IT will be now able to use SDN-based orchestration and management tools to quickly deploy, configure, and update devices across the entire network.