Hosted Clouds for DoD?

Internally developed and DoD component-conceived private clouds for DoD are not likely to happen.

DoD does not have the software talent and cannot afford acquiring it in the next few years. DoD does not have the capital or the time to construct several billion dollar cloud data centers. DoD migration into the cloud environment can be only incremental. There are thousands of legacy applications that can be relocated to the cloud only gradually. DoD must rely on a hybrid approach during the transition of legacy systems from the current environment. During such transmission the capacity of any cloud operations would be vastly under-utilized.

The structure of current DoD operations shows a great diversity in meeting security requirements. From a less demanding security standpoint, there are $4.6 billions of business applications that may be easier to relocate. War fighting applications, ranging from NIPRNET to SIPRNET, are $11.7 billions. These are demanding and must migrate into a cloud only under conditions that guarantee no loss of data. In addition there are applications that are compartmented and would always remain off the cloud, running on DoD organic assets. However, the overarching problem for DoD is the $15 billions devoted to its infrastructure. DISA and diverse Agencies have attempted to support every security requirement for every DoD application and has not succeeded so far to deliver a unified approach.

One of the options that DoD should explore now is the hosting of its diverse requirements in commercial operations that deliver secure hosted clouds. In such arrangements commercial firms offer IaaS, PaaS or SaaS services. DoD would run network control centers and manage the high performance LANs and WANs that are necessary to access the Internet from DoD controlled client computers. The consequences of pursuing such policies would be a hybrid arrangement. It would lend itself to evolutionary migration while relieving DoD of the need to acquire the intellectual property for cloud operations. This would also avoid making huge investments for capital assets.

Another option is for DoD to hire a leading contractor to develop and build the required cloud capacity. The cost of such a program would exceed some of the largest weapon projects, with attendant risks. None of the existing IT contractors have the experience in building cloud operations. While DISA is trying to position itself as the provider of DoD computing it would be burdened by the same limitations as IT contractors.

SUMMARY
How hosted DoD clouds would function will require the institution of new policies. Here are few guidelines:

1. Business applications and generic services such as e-mail, open source office applications, collaboration systems, calendars, etc. could proceed along lines that have ben already established by GSA. *
2. The concept of operations for applications that exclude warfare would be IaaS. Multiple vendors, each with several data centers, would offer hybrid and interoperable services. This would allow DoD to relocate applications as needed. DoD Services will continue to exercise control through component-specific methods.
3. The concept of operations for applications that include warfare, but not intelligence, would be PaaS. DoD Services would continue to exercise control through component-specific operations except that databases will not be hosted commercially.

The shifting of the cost for cloud software and for cloud capital from DoD to secure commercial vendors offers a path how security can be increased while costs are reduced.

To conceive of such a plan will require an oversight organization. With the relocation of the position of the Assistant Secretary of Defense for Networks and Information Integration from the Office of the Secretary of Defense to DISA (which is managed by USCYBERCOM) the accountability for the planning of network defenses is in place.

With the rising emphasis on cloud computing as the solution to security while budgets are shrinking the need for action is here.



*http://pstrassmann.blogspot.com/2011/02/google-docs-are-step-into-cloud.html

Google Docs Are a Step Into the Cloud

Unisys partnering with Google and Section 8(a) contractors (Tempus Nova and Acumen Solutions) will deliver Google cloud-computing services to the General Services Administration (GSA). Their 15,000 employees will switch from desktops and laptops hosted on local servers to network-hosted applications operated from Google data centers. GSA is among the first federal agencies to move into cloud computing. * Competitors for the contract were also Microsoft and IBM who lost for unspecified reasons.

The Unisys fixed price contract is $6.7 million or $90/employee seat/year. GSA will still have to provide client computers, plus high bandwidth LAN connectivity to the Internet. The high responsiveness of Google will make possible the replacement of high cost “fat” clients with low cost “thin” clients for substantial additional savings.

We do not have a benchmark for comparing the GSA cloud deployment with current client/server operations. However, we do have data on the cost per seat for the NMCI project. ** Although NMCI does include on site management of equipment, from the standpoint of functionality the services are comparable in terms of the most frequently used features. The NMCI costs are either $1,818/employee seat/year or $2,230/employee seat/year if the full five year costs to the Navy are included. The disparity between NMCI and GSA cloud costs are just too large not to be left without further examination. 

Anyway one accounts the costs, GSA’s IT budget will realize a huge reduction in operating expenses and in the elimination of most of its IT support personnel. GSA will also avoid substantial future capital investments for servers. In return GSA will receive e-mail, word processing, spreadsheets, presentation slides preparation means, collaboration applications as well as a wide range of diverse services that Google makes available at no cost. The applications migrated into the Google cloud represent the majority of GSA’s computing needs.

The source selection documents for choosing Google are not available and therefore we cannot say whether it was the price, the migration cost or security requirements that were the basis for the vendor selection.  We only know that the major objection to the engagement of Google came from Microsoft who were offering their online Business Productivity Only Suite consisting of the Microsoft Exchange Online for email and calendaring; Microsoft SharePoint Online for portals and document sharing; Microsoft Office Communications Online for presence availability and Office Live Meeting for web and video conferencing. Microsoft’s argued that the existing interoperability between Microsoft applications and the diverse GSA applications were not easily interoperable, if at all.

The differences between Google and Microsoft applications will be hard to ever reconcile. Google offers solutions that are based on open source programs, using published Apps APIs (Application Program Interfaces). What GSA is buying is a Software-as-a-Service solution where all application development and maintenance costs are already included in Google bills.

An examination of the interoperability between Google documents, spreadsheets and presentation software and Microsoft Office applications were found to be compatible. There appears to be no valid reason whey Google Apps cannot coexist with any other Microsoft linked applications that remain hosted on GSA servers.

Microsoft’s applications are tightly wedged into their Operating system environment. From a security standpoint, Microsoft application software, operating system and browser are also under continual attack. Hundreds of bugs are discovered every year. Until the fixes are installed, there is always a time during which Microsoft programs remains vulnerable. No such vulnerabilities have been as yet attributed to Google.

SUMMARY
The large savings available from the migration to Google Apps for the most frequently used GSA workloads offer a relatively easy and fast path into cloud computing. Other applications, such as database intensive uses, can be scheduled for transfer later or remain hosted on clouds that specialize in applications such as Oracle database services. There is no reason to suppose that GSA cannot operate in the future in a hybrid cloud environment where a part of applications are run by Google, some are run on other clouds and some remain hosted within GSA.

An important consideration in the choice of Google is the opportunity for GSA to disentangle itself from largely total dependence on Microsoft. GSA would now have an opportunity to choose from diverse computing clouds where interoperability can be competed primarily for the least cost as well as the highest levels of security.


*http://www.gsa.gov/portal/content/208417
** http://pstrassmann.blogspot.com/2010/12/nmci-economics-for-next-five-years.html 

Fictitious Identities on the Internet

The attractive person you encounter on Facebook, MySpace, LinkedIn, Nexopia, Bebo, Friendster, Orkut or many other social web sites outside of the U.S.A. could be actually a fake.

There are many ways of constructing such fictitious individuals, including persons invented by a government agency. *

An Internet IP address can be registered for as little as 99 cents/year for an <.info> domain or for $4.99/year for a <.com> domain. ** An operator can create a large number of personas, replete with background, history, supporting details, resumes, pictures and cyber presence that are technically, culturally and geographically credible.

Such fakes enable an operator to display a number of different online personalities from the same workstation. This can be done without fear of being discovered. E-mail, blog and collaboration applications can appear to originate from any part of the world for interactions through conventional online services or social media platforms. The fake includes user-friendly indications that maximize situational awareness, such as displaying real-time local information or weather.

Communications from fake personalities can have a wide range of motivation. This includes sexual enticement, accusation of misconduct, fictitious reports, bullying, slander or libel. The possibilities of abuse are limitless, especially if the allegations originate from different sources that appear to be credible. Fake sources are also ideal for spreading propaganda and can be used to spread misinformation about political matters. If a faker’s bona fides are questioned, a variety of references can be provided from multiple fake addresses.

SUMMARY
Except in cases where certification is authenticated by a government issued identity document, such as a CAC card in the case of DoD, other origins of Internet communications will remain untraceable.
With proliferation of Internet fake personalities, protective measures will have to be taken. For instance, in the case of DoD social computing, a government issued identity certification may have to be issued to safeguard communications between the military and private addresses.

In the case of commercial communications the existing certification authorities, such as obtained from Verisign, would require additional authentication of an individual by confirming the validity of a government issued driver’s license or passport. This would create unprecedented traffic on the Criminal Justice Information Network (CJIN) currently used by law enforcement agencies.

Fake personalities on the Internet are emerging as a new threat to communication. Right now there are too many easy ways how to establish Internet personalities. In due course this risk will have to be contained.


* http://www.bnet.com/blog/technology-business/so-why-does-the-air-force-want-hundreds-of-fake-online-identities-on-social-media-update/8728
** http://order.1and1.com/xml/order/Home;jsessionid=D5C95BB2FA9082F5EABCA0776C314EE2.TCpfix142b 

Modular Development is Not the Answer

The “25 Point Implementation Plan to Reform Federal Information Technology Management” issued by the U.S. Chief Information Officer on December 9, 2010 states that “… OMB found that many IT projects are scheduled to produce the first deliverable years after work begins, in some cases up to six years later. In six years, technology will change, project sponsors will change, and, most importantly, program needs will change. Programs designed to deliver initial functionality after several years of planning are inevitably doomed.”

The House Armed Service Committee has further elaborated on the current situation in DoD:  *
1. Only 16% of IT programs are completed on time and on budget.
2. 31% are canceled before completion.
3. The remaining 53% are late and over budget, with the typical cost growth exceeding the original budget more than 89%.
4. Of the IT programs that are completed, the final product contains only 61% of the originally specified features.

To deal with this situation the Office of the Federal CIO advocates the adoption of a modular approach to systems development, defined as “… delivery in shorter time frames … based on releases of high level requirements and then refined through an iterative process.” This would require deploying systems in release cycles no longer than six to twelve months, with initial deployment to end users no later than 18 months after the program is authorized.

The problem with such guidance is the disregard of typical time-lines for information technology projects. Constructing the Metadata for DoD databases is continuous. It is never finished and requires continuous investments that forever.

The time to develop a communications infrastructure for DoD takes decades. It may then take more than several decades to migrate into a new communications environment.

DoD has core business applications, such as in Finance or Human resources that remain in place with little change for many years.

Tactical applications have an extremely short life, which may be only a few hours while a mission lasts.

Attempting to solve DoD’s development problems with rapid paced modular development does not recognize that enterprises need to solve some long-term problems before short-term solutions can be implemented.

The following diagram illustrates the differences in the timing of programs:

Global:
Global standards take a very long time to evolve. DoD must select only a minimum of technical standards and enforce them across all applications. Emphasis placed on assuring interoperability with the least migration costs. Proprietary solutions must be avoided.

Enterprise:
Enterprise standards must be followed. Control over databases, over shared communications, security and survivability should never be included as an integral part of a development program. Enterprise directions should hold steady for decades. A DoD cloud is clearly a shared enterprise program, not a functional investment.

Process:
Functional processes, especially in business applications, should not be managed as modular releases, but planned and funded as multi-year programs. Core features of functional processes should be extracted by Services and Agencies as “plug-in” add on.

Business:
Businesses should be built as applications that have only unique and specific uses. There should not be multiple logistics, personnel or financial systems within a Service or an Agency.

Application:
Application Development and Maintenance can be decentralized to meet local needs.  Standard modular code should be used to compose programs that take advantage of an in-place infrastructure, thus minimizing the amount of investment that is required to deliver results. It is only here that the six to twelve month modular development schedule would apply.

Local:
Local applications should be composed from parts available from the Enterprise, Functional and Business levels. Depending on the capabilities of the DoD networks, local applications should be assembled in a very short time, often in hours.

Personal:
Personal applications should be totally separated from the DoD business to protect privacy. They should be subject to only records management controls.

SUMMARY
DoD projects that last more than six year, or be terminated only to be restarted again reflect the prevailing program management practices. What we have are programs that are attempting to develop their own unique infrastructure, with little dependence on Enterprise or Process services. Such an approach is expensive and time consuming. This situation is compounded by a limited enforcement of global standards.

DoD programs should not be cut into pieces that are launched incrementally. Programs should be fitted into an overall architecture in which complexity is solved by means of programs that have multi-year stability. That would leave short-term execution to depend on pre-fabricated modules that depend on the simplicity of using only minimal amounts of code while most of the code is extracted from the long lasting shared infrastructure.

* www.esi.mil/Uploads/HASCPanelReportInterim030410%5B1%5D.pdf