Strassmann’s Blog

2013-02-03T11:41:00.001-05:00

Cyber War and the Threat of the Boomerang Effect

2013-01-31T17:29:00.002-05:00

http://www.securityweek.com/cyber-war-and-threat-boomerang-effect

Cyber weapons may be cheaper to make than tanks and nuclear arms, but they come with a dangerous caveat – once they are discovered, the target-er can become the targeted.

At Kaspersky Lab's Cyber Security Summit today in New York City today, the pros and cons of developing cyber-weapons such as Stuxnet and Duqu – and how their use can impact corporate environments – was front and center.

While it may not be possible to disassemble and reassemble a cruise missile after it is used, that is entirely possible when it comes to cyber-weapons, Kaspersky Lab CEO Eugene Kaspersky observed in a panel discussion.

"That," Kaspersky said, "is why my point is that a cyber-weapon is extremely, extremely dangerous…the victims will learn, and maybe they will send this boomerang back to you."

From his seat on the panel, Howard Schmidt, who served as the cyber-security coordinator for the Obama administration for three years, compared the situation to a passage from Sun Tzu's famous book, 'The Art of War.'

"You would never want to use fire in a battle if the wind's blowing in your face," Schmidt said. "That just makes sense. The second thing you want to do, if indeed you want to use fire and the wind is blowing in your face, you'd better hope you have nothing that will catch fire. The third thing is if you have something that catches fire, it better not be important to you."

"When we look at the pieces of malware out there that are being pushed around, a government may say 'this is a very, very well-crafted, very specific piece of malware designed to do something very specific.' To believe that's going to stay there and never ever be discovered, never ever be reverse engineered…that's just foolhardy," he said. "So what happens is you are playing with fire."

The bottom line, he concluded, is "why would you just sort of throw that out there and hope that it doesn't come back and hit you? Those are the things we really, really have to, on a nation state level, start to think about it."

Their commentary comes not long after the publication of 'Red October', a cyber-espionage attack that successfully compromised computer systems at diplomatic, government and scientific research organizations during a five-year period. No proof has been provided that it was government-sponsored. However, there have been widespread reports during the past two years that other malware, such as Stuxnet, was linked to efforts by the U.S. and Israel to sabotage Iran's nuclear ambitions.

Fighting the cyber war in some ways is akin to dealing with money laundering, Schmidt said, recalling that in the past many governments either participated in money laundering or looked the other way. Others however decided to try to crackdown on it. Likewise, some countries are reluctant to crack down on hackers whose activities benefit their economy, he said.

Operation Aurora – the cyber attack publicized by Google in 2010 – prompted the general acceptance of the fact that countries were perpetrating cyber attacks, Costin Raiu, director of the global research and analytics team at Kaspersky Lab, said during a presentation on the threat landscape for corporations. It was also proof that not all attacks were governments targeting governments – instead it was governments targeting companies.

He also noted that in the case of cyber-war, there can be collateral damage. In an example of this is Chevron, which disclosed in 2012 that some of its systems had been infected with Stuxnet in 2010.

While all corporations face a level of risk associated with cyber-attacks, some industries are more aware of the danger than others – principally because they have been hit harder by high-profile attacks, Kaspersky said.

"Those that have been a victim, you can guarantee at the next board meeting this was an agenda item," Schmidt said. "If they're good, not only was it an agenda item in the direct aftermath but…(now) every time there's a board meeting it will be on the agenda."

Software Defined Networking - A New Network Weakness?

2013-01-31T17:23:00.001-05:00

http://www.securityweek.com/software-defined-networking-new-network-weakness

Network virtualization, under the umbrella of Software Defined Networking (SDN), presents an opportunity for network innovation but at the same time introduces a new weakness which will more than likely be targeted once solutions become more commercially available.

Whether the underlying technologies used are OpenFlow or Overlay Virtual network, network virtualization solutions are based on a network controller which can be attacked in different ways. A successful attack on the controller will neutralize the entire network operation for which the controller is responsible – it can be said that there will be a new type of attack that will put the entire network operation under denial of service conditions.

A little background on software defined networking (SDN) which includes within it the overall trend of network virtualization and openflow:

OpenFlow/SDN challenges the basis of the old style networking, and suggests a completely new approach – a centralized algorithm and intelligence, rather than a distributed one (distributed algorithms are typically executed concurrently with separate parts of the algorithm having limited information about what the other parts of the algorithm are doing). This centralized approach leads to a democratization of networks, which means that anyone who wants to control the network could do so through programming, using an abstraction layer as the network operating system (Network OS).

The central network control entity is an essential part of the new SDN solutions and brings with it many advantages over the traditional way networks are handled today (you are welcome to read more about it in one of my recent blogs and column “network apps” and “Secure SDN” )

Having said this, the network controller presents a new weakness that can be the target of an attack. In order to illustrate the security issue here’s a simple example for the case of an openflow enabled network:

The basic openflow principle requires that each packet which represents a new “flow” (e.g, typical TCP flow, L3 IP level flow etc.) that enters the openflow network to be sent to the network controller. The controllers will calculate the best path this flow should be routed through and will distribute this knowledge, in the form of flow table entries to all OpenFlow enabled routers and switches in the network. Once this is done, further packets that are associated with the same flow will be routed through the network without any further involvement on the part of the controller.

The SDN, and more specifically OpenFlow technology, allows to define through software in the network controller what the network “flow” is. It can be a typical TCP connection or a pair of source and destination IP addresses, range of IPs, protocol type, etc.

Understanding this process reveals two main security weaknesses that are associated with new types of denial of service attacks:

• The data path infrastructures, i.e., the OpenFlow enabled switches and routers can now be a target of “flow table” saturation attacks.

• The controller entity can be flooded with packets that represent a new flow in rate that it cannot process – leading it to be in a DoS condition that “refuses” to let the new flow enter the network or reach their destinations (each flow can of course represent a new online business transaction or any other type of communication.)

As this is pretty basic and straightforward, I don’t want to give too many ideas to attackers. But, I would give one scenario of an attack on such SDN infrastructure that is supported by openflow:

1. An attack activates a new network scanner that generates legitimate traffic in the openflow supported network

2. The network scan tool is designed to reveal the “routing logic” that the controller was programmed to enforce and the definition of a “flow” in the network, i.e., is it a TCP connection, is it just a pair of IP addresses etc.

3. Once the “flow” definition is known to the attacker, the attacker can produce a high rate of traffic that generates new “flow” until it reaches the network controller capacity and puts the entire network in DoS conditions.

How Efficient is the Management of DoD Enterprise Systems?

2013-01-31T14:53:00.005-05:00

In March 2012 the GAO delivered to the Congressional Committee on Armed Services a report on Enterprise Resource Planning (ERP) Systems. It included ten systems with total estimated current costs of $22.7 billion [General Fund Enterprise Business System (GFEBS); Global Combat Support System (GCSS); Logistics Modernization Program (LMP); Integrated Pay and Personnel System (IPPS); Enterprise Resource Planning System (ERP); Global Combat Support System-Marine Corps (GCSS); Defense Enterprise Accounting and Management System (DEAMS); Expeditionary Combat Support System (ECSS); Integrated Personnel and Pay System (AF-IPPS) and Defense Agencies Initiative (DAI)].

The ERPs would be replacing legacy systems costing $0.89 billion/year. Replacing such systems would take anywhere from seven to fourteen years. When the ERPs are finally installed they would cost up to $207,561 per user and have a payback as high as 168 years.

The primary reason for building the new ERPs is to modernize the interfaces with 560 legacy systems already in place and connecting with 1,217 existing applications to meet changing requirements.

The projected payback years exceed the life expectancy of technologies in every case. That makes these investments questionable.

The above table above is incomplete. For instance the Navy’s NEXTGEN is excluded even though it is projected to take 11 years and cost over $40 billions. There are also enterprise applications, such as the Defense Integrated Military Human Resources System (DIMHRS), which was aborted after spending over a billion dollars.

Much can be learned from an examination of the GAO report to find out how DoD invests in multi-billion projects:
1. The project implementation time always exceeds commercial practices. DoD pursues a sequential phase approach for planning, design, coding and implementation, which means that during each phase time-consuming agreements must be negotiated about interfaces.
2. Elongated project duration contributes to rising obsolescence. Program management is continually involved in negotiations about 1,217 interfaces with stakeholders while features are changing. This is increases costs and delays schedules.
3. The costs of every ERP continue rise as the alteration of requirements dictates revisions that propagate well beyond the scope of any ERP.
4. The non-standard user interfaces for each ERP require large investments in training and education. That is excluded from total costs because budgets do not include the payroll of military and civilian personnel.
5. Each ERP system has its own infrastructure. Each obsolete legacy systems must be custom-fitted into the changed ERP.

If DoD would adopt a standard Platform-as-a-Service (PaaS) model for every ERP it could offer for all connections a standard application program interfaces. Programs could then interact with the ERPs so that the developers can code sub-systems for connectivity using interchangeable interfaces. The adoption of such approach would materially reduce redundant work, cut costs and allow building of ERP’s incrementally.

The current approach to implementing ERPs is not working. The project time line is too long. That can be shortened only by adoption of a standard PaaS environment. To maintain interoperability during the transitions from legacy to new ERP applications the DoD CIO should impose standards that comply with open source formats. This would avoid spending money on tailor-make custom designs.

The new approach to the design of ERP software must rely on central direction how all programs can be executed. It also requires control of shared data definitions. Current inconsistencies in data formats impose a huge cost penalty. New efforts to start an ERP would have to be guided by strong direction that guides architecture, choice of cloud software and network design. Without such guidance the current efforts to complete stand-alone ERPs will cost too much and deliver results too late.

What is the Efficiency of DoD IT Spending?

2013-01-31T14:50:00.004-05:00

Any aggregation of computers, software and networks can be viewed as a “cloud”. DoD is actually a cloud consisting of thousands of networks, ten thousands of servers and millions of access points. DoD FY12 spending for information technologies is $38.4 billion. In addition IT includes the costs of civilian and military payroll as well as most IT spending on intelligence. The total DoD cloud could be over $50 billion, which is ten times larger than the budget of the ten largest commercial firms. The question is: how efficient is DoD in making good use of its IT?

Efficiency of any system is defined as the ratio of Outputs to Inputs, also known as the productivity ratio of any enterprise. If only a small fraction of Inputs is converted to Outputs then IT can be labeled as inefficient. The metric of the productivity ratio is always evaluated in dollars. Such numbers are readily available for DoD because the Office of Management and Budget (OMB) publish analyses of IT costs every year.

To make Output/Input evaluations require finding out how much of the available total IT budget is consumed in “management”, defined as “…costs incurred in the general upkeep or running of a plant, premises, or business, and not attributable to specific products or results.”
OMB lists the “information and technology management” function for IT. This includes all planning, administrative, management and acquisition costs as well as communications costs that cannot be attributed to any specific output.

This tabulation shows that only 48.8% of DoD functions are related to the costs of output. The remaining 51.2% is attributed to “management”, which includes expenditures for CIOs of OSD and components staffs. The IT Ouput/Input ratio for DoD can be estimated to be less than a half.
Is the 48.8% ratio a good measure of IT performance? Can it be compared with the best commercial practices?

I have worked with productivity numbers for more than thirty years. Have published over hundred articles and books on this topic and own a Registered Trade Mark on Information Productivity. In terms of IT spending per capita DoD is most comparable to the financial services sector because of its large amount of purchase transactions and huge assets. On the basis of comparison with major banks, whose IT budget for the top firms averages $2 billion, the IT productivity has always shown a ratio between 70% and 80% in contrast with less than 50% for DoD.

The primary reason for the difference between commercial firms and DoD are the expenditures for IT infrastructure maintenance ($7.7 billion) and for IT information security ($2.8 billion). These two items account for more than half of the communications expense that is included in the management costs of DoD.

With an estimated number of 15,000 networks the first priority for any future cost reductions should be the consolidation of communications. According to a 2006 GAO report the Global Information Grid (GIG) was supposed to achieve major reductions in the number of networks. That has not happened.
DoD must restructure its IT communication operations from an environment where it is vulnerable to multiple cyber attacks. Cutting down on the number of networks requires shifting of computing to a much smaller number of enterprise clouds. That will reduce costs as well as increase security.

Enterprise E-Mail and Collaboration Application for DoD?

2013-01-31T14:47:00.000-05:00

E-mail and collaboration (E&C) is the most attractive first step that leads to the realization of DoD enterprise-wide systems. E&C features are generic. They are functionally identical for everyone. Creating a shared directory of addresses and implementing security is well understood. Implementing E&C, as a Software-as-a-Service (SaaS), offers huge cost reductions. For instance, Microsoft Office 365 offers cloud-based E&C for $288/seat/year. Google offers a wide range of E&C services plus applications for $50/seat/year.

The only comparable cost for a similar service is the Navy Marine Corps Internet (NMCI), which is primarily targeted for the handling of E&C. The projected replacement cost is $2.9 billion/year or $7,700 per seat. Though the services offered by the replacement are not strictly comparable with a SaaS solution, the gap between a cloud system and the Navy proposal is too large to be overlooked. The life-cycle cash flow difference is in tens of billions.

If DoD could standardize on a secure E&C cloud additional enterprise-wide efforts would follow. The question is whether DoD should implement E&C by upgrading the current Navy operated environment, or to embark on a totally new direction using SaaS that runs on a secure Internet.
There has been already a good example of the successful migration of 80,000 GSA employees to the Google cloud. GSA simply disconnected from legacy e-mail and replaced it with a completely new low-risk service that delivers short-term net savings.

Army has now started moving its E&C to DISA. When attempting to take over DISA found that the existing network was polluted with inconsistencies. Local operators were acting as if they owned all applications by adding features and attachments. As an example, locations had improperly configured firewalls. Contractors applied unpatched software versions. Different circuit cards could not be synchronized. Consequently, local systems would not be interoperable when consolidated. Local variations had to be modified before systems could relocate into a unified environment. The Army conversion to an enterprise E&C has now been halted to clean up existing systems. The current choice is to migrate local versions to centrally administered server-farms.

Meanwhile, Congress has asked for an Army solution that would also fit Air Force, Navy and the Marines. That is an enormously demanding requirement, which calls for policy-level directions from the DoD CIO.

Standardizing e-mail for DoD includes a long list of add-ons such as application code security at NIPR and SIPR levels, provisions for archiving of all messages as well as assured back ups of transactions. All of these will have to be standardized, if enterprise system interoperability can deliver major cost reductions. Unfortunately, a wide variety of such add-ons are already code-embedded into the DoD servers and desktops. Existing systems are also integrated into Microsoft solutions where they would not qualify as an open source solution.

The effort to unify DoD e-mail has also run into integration problems for mobile devices. Interfacing with Android, Microsoft and Apple smart phones limits acquisition choices. Therefore, new policy-level directives will have to be issued that dictate which devices are allowed to connect to the network.
With rising pressure to reduce IT spending, there is an interest in considering centrally procured off-the-shelf commercial SaaS applications instead of proceeding with extremely expensive incremental migrations from the legacy environment.

Replacing all of the existing E&C with a single SaaS would accelerate the progression towards enterprise systems. Vendors would be able to compete for the lowest cost services without the hurdle of cross-platform conversion. Local modifications to support specific needs could be then bolted on by the Army, Air Force, Navy and Marine Corps as long as open source application interfaces would be followed.

The critical issue in organizing enterprise e-mail and collaboration concerns the accountability for managing a shared computing environment for DoD. What is emerging is a shift of oversight from local CIOs to the operational accountability by the Cyber Command. Local CIOs could then concentrate on accelerating progress to catch up with commercial practices.

DISA is now proceeding with the implementation of the Army’s E&C. Progress is watched to see whether the 1992 goal of making DISA an enterprise services utility can be realized.

DoD Has an New Information Systems Strategy?

2013-01-31T14:44:00.004-05:00

We have now the “DoD IT Enterprise Strategy and Roadmap” (ITESR_6SEP11). The DoD Deputy Secretary and the Chief Information Officer signed it. This makes the document the highest-level statement of IT objectives in over two decades. The new direction calls for an overhaul of policies that guide DoD information systems. Implementation becomes a challenge in an era as funding for new systems development declines.

The following illustrates some of the issues that require the reorientation of how DoD manages information technologies:

1. Strategy: DoD personnel will have seamless access to all information, enabling the creation and sharing of information. Access will be through a variety of technologies, including special purpose mobile devices.

Challenge: DoD personnel uses computing services in 150 countries, 6,000 locations and in over 600,000 buildings. This diversity calls for standardization of formats for ten thousands of programs, which requires a complete change in the way DoD systems are configured.

2. Strategy: Commanders will have access to information available from all DoD resources, enabling improved command and control, increasing speed of action and enhancing the ability to coordinate across organizational boundaries or with mission partners.

Challenge: Over 15,000 uncoordinated networks do not offers availability and latency that is essential for real-time coordination of diverse sources of information. Integration of all networks under centrally controlled network management centers becomes the key requirement for further progress. Requires a complete reconfiguration of the GIG.

3. Strategy: Individual service members and government civilians will be offered a standard IT user experience, enabling them to do their jobs and providing them with the same look, feel, and access to information on re-assignment, mobilization, or deployment. Minimum re-training will be necessary since the output formats, vocabulary and menu options must be identical regardless of the technology used.

Challenge: DoD systems depend on over seven million devices for input and for display of information. Presently there are thousands of unique and incompatible formats for the supporting user feedback to automated systems. The format incompatibilities requires the replacement of the existing interfaces by means of a standard virtual desktop, which recognizes the differences in training and in literacy levels.

4. Strategy: Common identity management, authorization, and authentication schemes grants access to the networks based on a user’s credentials as well as on physical circumstances.

Challenge: This calls for the adoption of universal network authorizations for granting access privileges. This requires a revision of how access permissions that are issued to over 70,000 servers. The workflow between the existing personnel systems and the access authorization authorities in human resources systems will require overhauling how access privileges are issued or revoked.

5. Strategy: Common DoD-wide services, applications as well as programming tools will be usable across the entire DoD thereby minimizing duplicate efforts, reducing the fragmentation of programs and reducing the need for retraining when developers are reassigned or redeployed.

Challenge: This policy cannot be executed without revising the organizational and funding structures in place. Standardization of applications and of software tools necessitates discarding much of the code that is already in place, or temporarily storing it as virtualized legacy codes. Reducing data fragmentation requires a full implementation of the DoD data directory.

6. Strategy: Streamlined IT acquisition processes to deliver rapid fielding of capabilities, inclusive of enterprise-wide certification and accreditation of new services and applications.

Challenge Presently there are over 10,000 operational systems in place, controlled by hundreds of acquisition personnel and involving thousands of contractors. There are 79 major projects (with current spending of $12.3 billion) that have been ongoing for close to a decade. These projects have proprietary technologies deeply ingrained through long-term contract commitments. Disentangling DoD from several billions worth of non-interoperable software requires Congressional approval.

7. Strategy: Consolidated operations centers provide pooled computing resources and bandwidth on demand. Standardized data centers must offer access and resources by using service level agreements, with prices that are comparable with commercial practices. Standard applications should be easily relocated across a range of competitive offerings without cost penalty.

Challenge: The existing number of data centers, estimated at over 770, represents a major challenge without major changes in the software currently occupies over 65,000 servers. Whether this can be accomplished by shifting the workload to commercial firms, but under DoD control, would require making tradeoffs between costs and security assurance.

In summary, the redesign of operational systems into a standard environment is unlikely to be implemented on a 2011-2016 schedule unless DoD considers radically new ways of how to achieve the stated objectives.

Over 50% of IT spending is in the infrastructure, not in functional applications. The OSD CIO has a clear authority to start directing the reshaping of the organizations of the infrastructure. Consequently, the strategic objectives can be largely achieved, but only with major changes in the authority for the execution of the proposed plan. It remains to be seen whether the ambitious OSD strategies will meet the challenge of the new cyber operations.

Cutting IT Costs

2013-01-31T14:40:00.002-05:00

The adoption of Platform-as-a-Service (PaaS) has now opened new IT cost reduction opportunities. This option must now enter into DoD planning.

In FY11 DoD spent 54% of its total IT budget of $36.3 billion on its infrastructure. The remainder was spent on functional applications. In comparison with commercial practices the size of the DoD infrastructure is excessive. DoD has never managed to share its infrastructures. Programs were built as stand-alone “silos”, each with its stand-alone infrastructure.

For instance, even the simple effort to consolidate what is supposed to be a commodity application, such as a common e-mail for the Army, has ran into problems. The Army e-mail consolidation is difficult because of no shared standards, numerous local network modifications, inconsistent versions of software and incompatible desktops. The idea of placing parts of supply chain management, human resource systems, financial applications or administrative systems on shared platforms is too hard.
A sharing of the operational infrastructure is now feasible with PaaS platforms. PaaS calls for the separation between the software that defines the logic of an application and the method that describes how that applications will be placed in a computing environment.

A PaaS cloud provisions data center assets, data storage capacity, communication connections, security restrictions, load balancing and all administrative requirements such as Service Level Agreements (SLAs). A PaaS cloud can be private or public. It can support local needs or serve global requirements. A system developer can then concentrate exclusively on authoring the application logic. When that is done, the code can be passed to the PaaS platform for the delivery of results.

PaaS produces results without the cost and complexity of managing operations. In this way the total budget for a new application can be reduced. Programmers can concentrate on the business logic, leaving it to PaaS to take care of the hard to manage infrastructure. If you use PaaS all of the infrastructure components will be already installed. A PaaS cloud can then support hundreds and even thousands of shared applications infrastructures. Consequently, the total cost of DoD operations will decrease.

PaaS is an attractive solution except that each provider of platforms will try to lock up applications into their environment. Once an application code is checked into a vendor’s PaaS it will be difficult to ever check it out. There are hundreds of vendors who add refinements to their PaaS so that any extrication to another PaaS will remain as a restraint.

What a customer wants is not a vendor lock-in, but the ability to port applications from any PaaS to another. You can then shop for different terms of service from multiple suppliers. Portability of application code across PaaS services makes price competition possible. Availability of multiple PaaS clouds also makes for more reliable uptime.

To deal with the problem of interoperability across different PaaS vendors, VMware has just introduced the PaaS platform, the cloud foundry. What is unique is that this is open source software. A number of firms have already signed up to support this approach. The only restriction is that all of the applications must conform to compatible software frameworks such as Spring for Java apps, Rails and Sinatra for Ruby apps and Node.js.

An open source cloud platform prevents vendor monopoly, it allows for competitive procurement, makes cross-cloud support available and offers the exercise of multiple options how services can be delivered. Such arrangement will assure customers about improved quality and maintainability.
In the next few years DoD will have to depend on the cloud technologies that are available from contractors. Cloud computing services are available from several hundred firms. This includes Google, Microsoft, Amazon, Rackspace, AT&T, Verizon and many others. According to the 2012 National Defense Authorization Act , DOD must migrate its data from government-administered cloud services, and instead use private-sector offerings “that provide a better capability at a lower cost with the same or greater degree of security.”

A DoD customer contracts for a PaaS platform offering with features that are desired. In effect, the PaaS vendor delivers data center services while the customer retains full control over the application software.

DoD policy of Ocober 16, 2009 provides guidance regarding the use of Open Source Software. Open Source Software (OSS) is software for which the human-readable source code is available for use, study, reuse, modification, enhancement, and redistribution by the users. VMware PaaS meets the definition of commercial computer software and must be given statutory preference.
The broad peer-review enabled by publicly available open source code supports software reliability and security efforts through the identification and elimination of defects that might otherwise go unrecognized. The unrestricted ability to modify software source code then enables DoD to respond more rapidly to changing situations, missions, and future threats which otherwise would be constrained by vendor licensing.

The availability of the cloud foundry opens a new approach how to proceed with the migration to cloud computing. The more reliable PaaS may not take over unless DoD will change its thinking how to organize the development and operations of IT.

NOTE: Originally published as "Incoming" in AFCEA Signal Magazine, 2012

A third of all malware is encountered in the U.S.

2013-01-31T14:25:00.005-05:00

Legitimate sites and advertisements on the Web are much more likely to deliver malware than "shady" sites, according to a new study released Wednesday.

According to the Cisco 2013 Annual Security Report, the highest concentration of online security sites does not come from "risky" sites such as pornography, pharmaceutical, or gambling sites, but from everyday sites.

"In fact, Cisco found that online shopping sites are 21 times as likely, and search engines are 27 times as likely, to deliver malicious content than a counterfeit software site," the study says. "Online advertisements are 182 as times likely to deliver malicious content than pornography."

The U.S. retains the top spot among countries where the most malware is encountered, accounting for a third of all malware, the study says. Russia was in the No. 2 spot with almost 10%; China dropped to less than 6%.

"Most Generation Y employees believe the age of privacy is over (91%) and one third say that they are not worried about all the data that is stored and captured about them," the study says. "They are willing to sacrifice personal information for socialization online. In fact, more Generation Y workers globally said they feel more comfortable sharing personal information with retail sites than with their own employers' IT departments."

SUMMARY

Young U.S. Internet users accept malware from conventional sources.

SOURCE: Dark Reading, January 2013

Computers That Understand What You Say

2013-01-31T11:04:00.001-05:00

A smart-phone that engages in conversations is the next “Incoming” perturbation that will dictate how DoD will have to revise its information management practices.

DoD planners will have to include in their investment programs the availability of tactical consumer radios costing less than $300. The first firm to launch such technology is Apple with its iPhone 4S. It offers intelligent conversational capability. No other consumer computer firm has ever offered that before. We can be sure that other vendors will follow with similar products.

The iPhone 4S device is the first device that offers a reasonably capacity to perform natural language processing using semantic methods. Apple has applied computational linguistics to make it possible for the conduct of unstructured verbal and text exchanges to take place between computers and humans.
The application that does that is called SIRI. It depends for its capacity to talk back on semantic software that depends on its linguistic capability by extracting the meaning of word from the Apple cloud. Though SIRI still has problems responding to unusual requests, there are now a huge number of programmers who are enhancing the vocabulary of interactions while SIRI keeps “learning” from millions of conversations.

Over the past 20 years there have been many attempts to endow computers with a conversational capability. This involved the use of complex and very expensive special purpose hardware and software. What makes SIRI different is its reliance on packaging into a combination of conventional as well as innovative features that makes it possible to engage in simple conversations. The shirt-pocket sized iPhone include not only fully featured e-mail, office applications, calendars and an unlimited number of business applications but also a camera, a video recorder, GPS, geography-tagging, a compass, a gyro, a proximity sensor as well as face identification features.

Apple packed into a 4.9 oz. device UMTS/HSDPA/HSUPA (850, 900, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz); CDMA EV-DO Rev. A (800, 1900 MHz); 802.11b/g/n Wi-Fi (802.11n 2.4GHz only) as well as Bluetooth 4.0 wireless. This makes the iPhone a software-defined radio, which covers a spectrum of frequencies. It can be encrypted for security protection.
SIRI will talk in US and UK English (U.S.), Chinese (Simplified), Chinese (Traditional), French, French (Canadian), French (Switzerland), German, Italian, Japanese (Romaji, Kana), Korean, Spanish, Arabic, Catalan, Cherokee, Croatian, Czech, Danish, Dutch, Estonian, Finnish, Flemish, Greek, Hawaiian, Hebrew, Hindi, Hungarian, Indonesian, Latvian, Lithuanian, Malay, Norwegian, Polish, Portuguese, Portuguese (Brazil), Romanian, Russian, Slovak, Swedish, Thai, Turkish, Ukrainian, Vietnamese.

DoD planners can view the iPhone 4S as a harbinger of a revolutionary new approach how people will interact in the cyber sphere. Other manufacturers will be entering into a new technology race. The issue will be which of the many competing public clouds can support their respective devices with a superior capacity to conduct intelligent conversations without delays.

DoD information architecture will have to start adopting systems that will support person-centered applications. Though business applications may remain operating in the existing mode for a time, natural language applications should be focused on meeting the warfighter’s tactical needs. New systems should be able to offer the capacity to:

• To recognize the context of commands;
• To cope with inquiries that ask for summaries of complex data;
• Respond to silent texting, without keyboard inputs;
• Allow for terse communications about missions and objectives;
• Combine GPS, geography and intelligence information;
• Deliver situational awareness to individuals;
• Collect photo and video intelligence;
• Connect to diverse applications to obtain instant answers;
• Recognize diction characteristics of a sender;
• Use face recognition as means for biometric identification;
• Deal with multiple frequencies make it a software defined radio;
• Handle multiple languages for automatic translation of conversations;
• Track all communications and assign identity to an individual.

All of the linguistic intelligence of SIRI-like devices will remain, for several decades to come, on central clouds that house petabytes and even exabytes of semantic relationships. This must be available in real-time.

Semantic methods depend on an examination of millions of sentences to extract from communications relationships between the syntax of questions and the mostly likely context in which a word or a sentence have appeared before. This requires the uses of extremely fast parallel computers that will have to subdivide the task of finding the right answers.

To maintain a 100% reliable connection between local cell-phone devices and the central repository of semantic intelligence, DoD will have to depend on the availability of a multiplicity of “on the edge” servers. This is especially necessary in the case of deployment of expeditionary forces.
The availability of personal communicators that can hold conversations is a major breakthrough in the evolution of computing. Time has come for DoD planners to prepare for that. Intelligent communications will require different data centers and different networks.

NOTE: Originally published as "Incoming" in AFCEA Signal Magazine, 2012

Leaving Administrative Accounts Active on Routers

2013-01-31T10:57:00.005-05:00

A network and security hardware vendor revealed it issued long overdue patches for eight of its product families to limit access to administrative accounts that could have allowed attackers to compromise the products.

The backdoor access could have given an attacker complete access to the devices, provided they knew the password—and possibly have stolen an encryption key.

The vendor did limit access to the backdoor features to certain ranges of Internet addresses, but the groups of addresses included a number of servers for other companies and individuals as well. Compromising those servers could have given an attacker the ability to access vulnerable networking hardware.

In secure environments, it is highly undesirable to use appliances with backdoors built into them, even if only the manufacturer can access them.

Our research has confirmed that an attacker with specific internal knowledge of a router appliances may be able to remotely log into a non-privileged account on the appliance from a small set of IP addresses. These vulnerabilities are the result of the default firewall configuration and default user accounts on the unit.

The controversy comes as corporations and national governments worry over the security of the networking products manufactured across the globe. In October, the U.S. government recommended that companies not use products from Chinese manufacturers Huawei and ZTE, for fear that the Chinese government might insert a backdoor into the products. In August, researchers presenting at the annual Defcon hacking conference found enough vulnerabilities in Huawei's routers to allow attackers to compromise the devices remotely.

In 2007, a series of vulnerabilities in Cisco's networking operating system would have allowed a knowledgeable attacker backdoor access to any product running the operating system. Last year, researchers found that a common embedded chip had backdoor functionality as well. In fact, one security professional estimated that 20 percent of consumer routers have backdoors as well as half all industrial control systems.

SUMMARY
It is a common error to leave administrative privileges to a router set at the vendor’s original access code. That creates a backdoor, often available from on-line maintenance manuals.

Distributed Denial of Service Extorts Ransom

2013-01-31T10:37:00.004-05:00

In late 2011, trading services firm Henyep Capital Markets came under a distributed denial-of-service (DDoS) attack that disrupted many of the company's service portals. With the attack came a demand for ransom. The flood of packets that hit the company's trading services topped 35M bps, combining a variety of network traffic types and focusing on both overwhelming the network and overtaxing the firm's application servers.

Rather than acquiesce to the criminals' demands, Henyep hired the firm Prolexic.
The initial DDoS attack caused performance issues on multiple Henyep trading websites for 24 hours. Company management did not respond to the DDoS attackers’ demand for a ransom in exchange for ending the attack. The company’s mitigation engineers restored access to all services on the sites within minutes after routing traffic through Prolexic’s global scrubbing centers where malicious traffic was removed.

Prolexic protects Internet-facing infrastructures against all known types of DDoS attacks at the network, transport and application layers through four DDoS traffic scrubbing centers.
Prolexic DDoS mitigation engineers in the U.S. quickly identified the initial attack as a SYN floodfollowed by multiple GET floods. The attack campaign peaked at 35.30 Mbps (bits per second), 8.10 Kpps (packets per second), and 122.00 Kconn (connections per second) over two days. Prolexic mitigation engineers were monitoring the attacks and counteracting the perpetrator’s changing attack vectors throughout the campaign. As a result, the attackers were unable to take down the Henyep site, nor disrupt services despite the length of the attack.

Recently, DDoS attackers tried to take down Henyep’s trading operations again with a 30 MbpsICMP flood and GET flood without success due to Prolexic DDoS protection. Throughout 2012, Henyep, like many other financial services companies, has continued to be the target of DDoS attackers, but Prolexic’s DDoS mitigation services have prevented any downtime.

With bandwidth capacity in excess of 800 Gbps, Prolexic’s in-the-cloud DDoS protection transfers DoS and DDoS attacks that overwhelm others. A proven network of DDoS scrubbing centers are located in London, Hong Kong, San Jose, California and Ashburn, Virginia.

Our DDoS scrubbing centers are supported by four Tier 1 global telecommunications carriers. It means we Prolexic mitigates the largest DDoS attacks by substituting immense anti-DDoS bandwidth. It can provide DDoS protection services for multiple clients and fight multiple DDoS attacks at once.
When a DDoS attack is detected, our DDoS protection services are implemented within minutes. Upon activation of DDoS protection, a Prolexic customer routes in-bound traffic to the nearest Prolexic scrubbing center, where proprietary DDoS filtering techniques, advanced routing, and patent-pending anti-DoS hardware devices remove DDoS traffic close to the source of the botnet activity. Clean traffic is then routed back to the customer’s network.

Because Prolexic dedicates more bandwidth to DDoS denial of service attack traffic they can provide protection even agains the largest and most complex DDoS attacks. Prolexic uses over 20 DDoS mitigation technologies – many of them proprietary.

Prolexic mitigates every type of DDoS attack at every layer including Layer 3, 4, and 7. We even have a proven solution against encrypted attacks that vandalize HTTPS traffic in real time. Further, we use certified FIPS-140-2 Level 3 key management encryption tools with passive SSL decryption for extremely high performance.

Summary
DDoS attacks can be blunted and then eliminated through high bandwidth capacity networks. Often DDoS attackers who see traffic has been re-routed through our DDoS mitigation network immediately abandon their attacks.

Acquisition of Cloud Software and Services

2012-08-25T14:59:00.004-04:00

There are now thousands of firms offering “cloud” services. They range from large suppliers, such as Amazon, Google and SalesForce, to specialized enterprises such as Terremark and Savvis. The potential scope of these firms is global since they can potentially deliver their products anywhere. These firms can be either cloud brokers, cloud managers, cloud operators (SaaS, PaaS or IaaS), cloud platform vendors, software providers (VMware, Citrix, Microsoft) or cloud hardware suppliers (IBM, Dell, HP).

The benefits of switching a firm’s highly customized data center operations into any combination of Private, Public or Hybrid clouds will decrease operating costs as well as deliver greater security, more effective utilization of capacity and improved availability. The evidence that cloud computing delivers such gains is undisputed. However, to realize the benefits of cloud computing will require making major changes in the ways computing is managed.

How to migrate into a cloud-based computing environment is a decision that every chief information officer is facing at this time. One can progress incrementally by starting with the progressive virtualization of in-house servers. Such gains can be made quickly as the number of computing platforms is reduced.

In another case, a firm can transfer its computing workload to a services provider, such as by outsourcing of its e-mail or accounting. Costs will be reduced and the quality of this service will improve. The problem with all such moves is that a firms’ IT operations will commit to an incremental improvement, without engaging on a path that would lead to much greater information effectiveness for the entire enterprise.

Here is a partial list of issues that occur when a firm pursues incremental cloud migration. In each case this involves acquisition of services from suppliers who offer only partial technology solutions:

1. Every one of the thousands of vendors will attempt to “lock in” its customers into progression that favors its proprietary offerings but only for the contracted work.
2. A proprietary contract will limit access to public cloud services. It is unlikely that such arrangements will be interoperable with proprietary private cloud services.
3. Data centers from different parts of an organization are likely to pursue incompatible cloud applications.
4. Security policies, back-up and fail-over capacity will be either inconsistent or not achievable.
5. The sharing of capacity and managerial control cannot be implemented. Large supervisory staffs will remain in place.

Cloud vendors have become specialized. They offer a variety of services each offering some sort of a “cloud” solution but never a complete answer to enterprise needs. [1] The following is an example of the variety of firms and the published standards that are currently available to guide cloud acquisition:

A customer should be able to select from the above list those suppliers that comply with open standards, such the Open Virtualization Format (OVF). [2] Specification describes an open, secure, portable, extensible format for the packaging and distribution of software to be run on virtual machines. OVF has arisen from the collaboration of key vendors in the industry and is accepted in forums as a future standard for portable virtual machines.

The Open Cloud Computing Interface (OCCI) comprises a set of open community-lead specifications. [3] OCCI is a protocol and API for a range of cloud management tasks. OCCI was initiated to create a remote management API for IaaS services, allowing for the development of interoperable tools for common tasks including deployment of autonomic scaling and monitoring. It has evolved into a flexible API with a focus on integration, portability and interoperability while offering extensibility. The current release of the Open Cloud Computing Interface is suitable to serve many other cloud models.

SUMMARY
The advancements in cloud computing have lead to a proliferation of vendor offerings as vendors are getting reorganized to support cloud computing that is interoperable and integrated. The most advanced feature of this turmoil is in the adoption of software-defined networks, as the functions of network switching and routing are getting relocated from hardware devices to software-managed servers. A similar evolution is now taking place in the shift from security hardware “appliances” (stand-alone fire-walls and malware-tracking) into software-defined capabilities. In this race towards the increased integration of cloud software with layers of server computing, rather than adding hardware devices, the leading firm is VMware. They have announced the open source “Cloud Foundry” as a new product.[4]

Budget pressures as well as increases in the demands for computing services have placed demands on chief information officers to accelerate the conversions to cloud computing. Thousands of new firms now offering cloud solutions need to be examined for a demonstration that their offerings will have a well-defined migration path for delivering long-term gains. As one of the selected acquisition criteria the demonstration of an evolutionary path will also have to include compliance with published standards as well as the absence of proprietary solutions.

[1] http://blogs-images.forbes.com/kevinjackson/files/2012/08/CloudTechSpectrum_Vendors_v21.png

[2] http://dmtf.org/sites/default/files/standards/documents/DSP0243_1.1.0.pdf

[3] http://occi-wg.org/

[4] http://www.cloudfoundry.com/

Defense Business Board Report on Cloud Computing

2012-08-20T13:33:00.001-04:00

The Defense Business Board (DBB) is one of the highest-level committees advising the Secretary of Defense. [1] Its report on “Data Center Consolidation and Cloud Computing” warrants attention to indicate what policy directions DoD should be following. [2]

The purpose of this note is to comment on DBB findings:
1. The Department’s FY12 budget for IT is reported as $38.5 billion, $24 billion of which is dedicated to infrastructure. Those numbers are incomplete since they do not include the payroll of 90,000 military and civilian employees, worth over $10 billion. It does not include the time expended by employees in administrative, support, training and idle time that is associated with over 3 million on-line users, amounting to at least $3,000 per capita/year, or $9 billion. [3] From the standpoint of potential DoD cost reduction targets the total direct IT should be considered to be at least $58 billion. In addition there are also collateral management costs such as excessive purchasing due to long procurement cycles, high user support costs to maintain separate systems and high labor costs due to inefficient staff deployment.
2. The report lists over 772 data centers in place, with a data center defined as having more than 500 sq. ft. Such count understates what is a data center since the footprint of modern computer facilities servers can be accommodated in less than 200 sq. ft. Therefore, the number if data centers eligible for consolidation is well over a thousand. Consolidating equipment represents the least expense. Most of the cost is in the re-alignment of files, communications and contract arrangements.
3. The DBB does not recognize that the cost of the infrastructure, or 62% of the total, is broken up into thousands of separate programs. Hardly any of the programs are interoperable from a logical or physical standpoint. The largest component of the infrastructure is $9.9 billion for telecommunications, largely managed by DISA. These costs are managed as an allocation of total costs rather than through transaction fees as is the generally accepted commercial practice and as was originally recommended as DoD policy in 1993 though DMRD 918.
4. What are the cost savings and benefits from the streamlining of DoD IT is not understood in the form of cost justifications. For instance, the re-wiring and software redesign costs for data center consolidation involve a major restructuring to fit enterprise-level standards for over 3,000 programs. Business cases that would support such effort have not been completed.
5. No recommendations have been made how to deal with loss of local operational control over applications. The re-assignment of dedicated staffs or contractors remains under local control. The task of restructuring major programs does not account for a large number of sub-contractors in each instance as well as for up 30% of the value of each program distributed to a multitude of small business operators who have embedded into applications unique features and functions.
6. The DBB has not spelled out the migration process how to simplify operations through standards, interoperable software and telecommunications that are tightly coupled with applications.
7. The entire cloud software implementation will be determined by policies that dictate the migration process at the enterprise and not component levels. The speed of migration will determine the rate at which savings can be realized. If the migration takes too long, the conversion into the cloud environment will most likely never pay off.
8. There will be huge reductions in manpower if the most efficient cloud computing policy is chosen for DoD. The required skill levels, especially as employment shifts from operations to development, will make it more difficult to recruit replacements. If contractors and sub-contractors are included, the total manpower affected exceeds about 300,000. The DBB has not addressed how this issue can be resolved.
9. The report offers a table with potential cost savings. DoD cannot use such data as benchmarks in the absence of any details how such efficiencies can be realized. Projected savings of 70-90% call for radical re-architecting of the DoD approach how to manage. For instance, in the absence of any discussion how the reduction of application development to 4 days can place, there is no explanation how changes of existing acquisition policies would make such projections credible. Without an indication what type of up-front investments is necessary makes any ROI forecasts without support.
10. The statement that “properly designed cloud systems can be more secure” has no merit. How the DoD enterprise would protect 7 million connected devices against insider compromises or instances where there are violations of security policy is not clear.
11. The admonitions that DoD needs strong governance and leadership, a clear strategy, a well articulated “concept of operations” as well as the removal of policy barriers is self-evident. Such assertions are without merit in the absence of specific recommendations.
12. The four-step migration sequence, with cloud acceptance as the last phase after all other rationalizations have taken place, offers an unrealistic sequence. DoD must start with well-articulated cloud architecture before proceeding with incremental migration. Incremental progress, without an overall plan, will arrest progress to only partial local improvements in the status quo.
13. DoD progress toward cloud computing cannot be achieved through hundreds of separate pilot programs. The limits on future funding calls for a concentrated effort. It cannot be done through program-based short-term savings, but through a radical overhaul of the existing infrastructure where the largest inefficiencies exist at this time.
14. The recommendation that the DoD CIO has veto power over IT spending but engages component CIOs as chief implementers while leveraging DISA, runs into conflict with Title 10 responsibilities. Without addressing this issue, the DBB report is “toothless”.
15. Applying a sequenced approach to data center consolidation as the high priority action addresses the least profitable initiative, with dubious payoffs. It keeps the implementation of cloud computing in the hands of the components and not primarily with the DoD enterprise. The strategic direction of DoD should aim towards enterprise-level cloud computing that mandates application consolidation as well as the enterprise-wide adoption of virtual personal appliances.

SUMMARY
The DBB report is incomplete. It does not offer actionable solutions. It only raises policy level questions, which is insufficient. As components are formulating FY13-FY18 budget requests they will find nothing in this report that will guide what re-alignments are needed to advance DoD towards cloud computing.

1 http://dbb.defense.gov/charters.shtml
2 http://dbb.defense.gov/pdf/Final%20IT%20Report%20with%20Tabs_FF9D.pdf
3 Gartner Research Note G00208726, 11/2010

The Deployment of Virtual Device Interfaces (VDI)

2012-08-19T18:10:00.006-04:00

Desktop and smart-phone virtualization allows organizations to adopt a centralized approach to the management of the configuration of computing devices to greatly reduce costs. By decoupling the applications as well as data and operating system from devices, and by moving these components into a pooled center a streamlined, secure way to manage distributed devices is feasible. Computing devices can be then centrally managed and desktop customers can realize many benefits.

VDI can manage tens of thousands end-user devices from a centralized administrative interface from where it allows provisioning, conﬁguration management, connection brokering, policy enforcement, performance monitoring and application assignment. VDI increases security and compliance by moving data into a computing center, centrally enforcing endpoint security and streamlining security countermeasures processes. Most important, VDI makes it possible to install security services against “spear-fishing” attacks that otherwise would be undetected.

VDI offers economics advantages. Centralizing the infrastructure makes it less costly for IT staff to provision, maintain and monitor desktop images across their entire life cycle while decreasing support calls and reduce end-user downtime. The Total Cost of Ownership (TCO) of unmanaged computing devices is $5,795/year. The comparable cost for VDI devices is $3,310. For instance, with the DoD population of more than 3 million devices suggests a potential direct cost reduction opportunity could be one billion dollars/year. When major savings from end-user costs (administration, training, repairs and downtime) are added that would increase the potential gains by $6.5 billion dollars.

For smaller firms the potential savings of $2,500,000/year could be realized for every 1,000 computing devices.

VDI delivers to users experiences across locations and devices over the LAN and WAN in terms of lower latency and much higher uptime reliability. Users can connect to the VDI environment a wide range of devices including desktops, thin or zero clients, and mobile devices. Mobile users can access their VDI desktops even if disconnected from the network provided that they re-synchronize their applications afterwards. A software configuration management console enables IT administrators to centrally administer thousands of VDI desktops from a single image for the management, provisioning and deployment.

VDI is installed on a virtual infrastructure, which includes virtual machine hypervisors and the management center to create and manage the virtual machines. End users open VDI Clients on endpoint devices to log in to their desktops, which are “views” of all virtual machines such as Windows desktops. Users can access their desktops from a variety of endpoint devices where VDI is installed such as Macintosh, Windows, and Linux computers, thin clients, zero clients, iPads, and Android-based tablets.

To install VDI, the following installations are necessary: Cloud network and storage connections; Microsoft active directory and domain controllers and hypervisors. The VDI Connection Server will then authenticate client users through the integrated Windows Active Directory, which connects the users to their virtual desktops. Users can also connect directly to the central desktop. For remote connections, a wide range of security servers will stand as protection between the clients and the internal network.

Each VDI virtual machine desktop has within it: an operating system; a VDI agent; the user profile (“persona”) and installed applications. From the VDI administrator console it is then possible to view all VDI components.

VDI ultimately requires the adoption of a standard protocol so that an organization can operate seamlessly with a single common platform from the desktop to the datacenter. That enables private and public cloud based desktop services across a variety of hybrid cloud services. Proprietary VDI protocols from firms such as IBM, Microsoft, Oracle and VMware offer VDI capabilities, which are, however, in most cases are not interoperable.

SUMMARY
Installing the VDI environment could be a complex, multi-step process depending on the options: 1. The VDI host infrastructure must be installed. 2. Set up VDI view agents, inclusive of templates must be integrated. 3. Installing Microsoft Active Directory and Domain Controller services is necessary. 4. VDI composer database and SSL security certificates must be added. 5. VDI connection servers must be loaded to dedicated physical machines. 6. Configuration of VDI transfer software, such as Windows applications must be completed. 7. Desktop pools of hardware need to be set-up. 8. Security services require installation. 9. The entitlement of individuals to their respective desktops must be designated. 10. Network connections are required for customized configurations. 11. Personal profiles must be installed.

If VDI is getting installed into a private cloud that captures a wide range of existing configurations (Windows, Linux, etc.) the conversion will be costly and the payback will take a long time. If the VDI takes place after the migration to thin clients has already taken place, the conversion will be easier.
The adoption of VDI does not necessarily have to be made into a private cloud environment. It could be implemented as a hosted service that already includes VDI as a standard offering.

The current DoD policy to rapidly migrate thousands of diverse and customized configurations offers an enormous challenge. To achieve major cost reductions in short order will require directions from an enterprise architectural level and not from the standpoint of thousands of existing individual programs that will have to be harmonized.

Containing User-Activated Security Threats

2012-08-17T13:23:00.002-04:00

The single largest security threat at this time is through network breaches. Employees are direct targets of adversaries who have the objective of penetrating networks to gain access and then exploiting it do further damage. The most successful attack is spear-phishing employees with email containing links to malicious sites. The adversary is tricking an employee into becoming an accomplice to network breach every time they click on a link that looks innocent but hides an attack. Every employee is therefore a potential point of weakness in security.

A well-designed attack has a high chance of success. Every employee is a potential contributor to a security breach, from the intern to the chief executive. The adversaries also know that internal network security to protect many incoming transactions is for all practical purposes non-existent. After gaining access to a single machine, an attacker can move laterally to seek out the keys to the entire network. This is a problem that demands a sophisticated technology solution to aid the internal security team in identifying and then isolating the adversary while protecting the network.

At present, the infections are usually detected weeks and even after the fact. Damage is prevented after the adversary has had ample time to both access the network and steal sensitive data. While one attack gets cleaned up, the adversaries are already launching another penetration.

Most of the existing counter-measures rely upon are reactive technologies. They require a list of known bad malware or websites in order to detect or block malware. These technologies no longer work against today’s adversaries who morph their signature while bringing down websites on an instant basis. Malware authors have produced seven millions brand new variants in the first quarter of 2012 (https://portal.mcafee.com/downloads/). Malware authors are also utilizing polymorphic techniques in which malware mutates instantly to evade detection. The reactive defense perimeter has been shrinking while the vendor provided anti-virus protection keeps detect less than 19% of new incursions.

The existing anti-malware paradigm must now change. It must evolve from protecting assets that are statically placed behind layered defenses to one of protecting those assets wherever they may be. The employee has now become the primary target. Every one of multiple mobile computing devices must be guarded. According to the US-CERT first quarter FY2012 phishing and malicious websites now account for 58% of direct attacks against employees who clicked permission for access.

One traditional way of protection is to build a better network firewall. Firewalls are designed to stop inbound threats to services that should not be available to an outsider. Unfortunately, firewalls are ineffective since they block only inbound attacks. But, browser malware is initiated by outbound requests that pass through the firewall after a user clicks to admit them. The attacker therefore doesn’t need to try to penetrate the network. The employee pulls it in from the inside!

While application whitelisting is effective at preventing standalone malware, more than a half of attacks exploit known applications including the browser, document readers, and document editors. Increasingly, Microsoft Office documents are the most vulnerable and widely used applications. These applications present a rich environment for attackers to exploit vulnerabilities. They also provide fertile ground for adversaries to dupe users into clicking on links and opening social applications such as Facebook and Linked-In. As malware exploits those applications, the cyber adversary gains a foothold in the enterprise. The malware has then access to that machine, to the data on that machine, and to all network devices to which that machine is connected.

For example, two of the recently most widely reported attacks – on RSA and on the Iranian nuclear site – were initiated through penetration of employees’ computers. In each case an infected transaction was inadvertently admitted. This enabled further attacks to proceed even though there was extraordinary security protection already in place.

SUMMARY
Over the past few years it was believed that a breach that has been admitted into a desktop couldn’t be stopped. After the fact detection offered the only prevention means. Reactive list-based reject approaches could not stop direct threats. Intruders had to be detected first but the question remained how to identify an intruder.

A new approach takes the most highly targeted unprotected applications in a network (such as the Web browser, PDF reader, Office suite, .zip files, e-mail) and places them into a separate virtualized computer. Every time any application is opened, or anytime an attachment comes from outside the network, a completely separate Virtual Machine environment is created. By creating such an environments, all malware – whether zero-day or already known – is tagged and prevented from attacking the host as a pathway for breach. It remains completely isolated on its own VM.
When an infection is detected inside such controlled environment, the user is alerted for potential discarding the tainted transaction and then to rebuild it to a clean state. Forensic details are then captured to feed such intelligence into security infrastructure surveillance.

It will require a massive conversion of millions of existing DoD desktop and mobile devices to operate through Virtual Device Interfaces (VDI) to achieve anti-phishing protection.

The Navy’s NGEN Program is Contrary to DoD Policy

2012-08-11T12:38:00.003-04:00

The original $8.8 billion NMCI contract with EDS expired in September 2010. Three years before that NGEN (New Generation) replacement program was launched. Until 2011 NGEN has spent $432 million on work preparing for the transition. With NGEN now scheduled to start in 2014, the original NMCI contract has been meanwhile supplemented by and additional $5.5 billion.

Does NGEN hold up to the promise of providing the Navy and the MC with information superiority that meets 21st century requirements? We do not think so. What we are getting is a rehash of what is now an obsolete approach.

When EDS took over NMCI, it assembled thousands of disaggregated networks and turned them into a unified program with a common level of security and service. However, the Navy and the MC didn’t get an understanding of what made up NMCI because EDS held that. There was no understanding of what was the cost of the system, how many people it took to run it, and what are were the contributions to the users. When a continuity of the contract took over in 2010, NMCI was broken up and divided it into services. One segment was transport, which was the wires, fibers, routers and switches that are on the base and local area networks. For wide area networks DISA offered services. Help desk, email, data centers, video teleconferencing, voice-over-IP and the deployments of end-user devices was organized separately. In addition that was a hardware segment, which is mostly hardware on people’s desks as well as a software segment that delivers the software for end-users and the software required to operate the network. As result NMCI was broken into 38 services. As result the total cost of NMCI was finally known but still without a comprehension of how it all fit together.

The objective of NGEN is not only to know what the pieces of NMCI cost but also how the fits together, which should enable to compete separate pieces and parts. The forthcoming RFP competes the transport and enterprise services portions separately. This includes a 35% of total award for small business, which further complicates the entire bidding process.

The latest version of the NGEN RFP was released on May 9, 2012, allowing bidders additional weeks for questions. Final proposals are due July 18. The source selection process will then proceed to completion in February 2013. At that time, there will be a contract award to begin executing the transition plan starting in April 2014.

The Navy and the MC have already purchased the lion’s share of the infrastructure—routers, switches, cables, as well as computer hardware to reduce costs. The government now owns the infrastructure as well as the NMCI intellectual property how the network operates. There is a corpus of 450,000 documents available to bidders for guiding their directions. By owning the infrastructure, by purchasing the government rights to the NMCI intellectual property and by making the intellectual property available to industry NGEN is now largely defined to operate similarly as NMCI.

SUMMARY
NGEN is proposing to replicate the NMCI infrastructure. It imitates the NMCI operating methods. It hopes to reduce server costs through virtualization, which can deliver only minor savings. Despite of its age of over 15 years, NGEN does not represent innovation but a reversion to cold-war thinking.
NGEN directions deviate from the following small selection of the OSD strategic directions:

1. Individual programs will not design and operate their own infrastructures to deliver computer services. NGEN persists in operating a program-level infrastructure.
2. DoD will operate an enterprise level cloud-computing infrastructure. NGEN will be only Navy/MC used.
3. DoD will make possible to rapidly construct and then to deploy applications. NGEN has been broken up into 38 separate services. This requires extensive integration before a new application can be launched.
4. Global data and cloud services will be available regardless of any DoD access point or device. NGEN will be built to support primarily the Navy and MC.
5. The OSD CIO will be responsible for the Enterprise Architecture that will define how the DoD cloud is designed, operated and consumed. NGEN is architected to imitate NMCI.
6. DoD will implement enterprise file storage to enable global access to data by any authorized user, from anywhere and from any device. Enterprise-level data interoperability is not a NGEN objective.
7. DoD-wide computing will not be limited to Components but also to others such as throughout the Federal government, mission partners and commercial vendors. Universal connectivity is not included in NGEN.

The latest DoD “Cloud Computing Strategy” mandates system implementation that differs from the directions that NGEN is taking. NGEN is continuing with a relatively low level of funding because it preserves much of the current NMCI infrastructure and does not make a decisive commitment to major cost reduction available through cloud computing. To conform to OSD directions NGEN will have to re-examine its current approach.

Consolidate Count of Applications, not Count of Data Centers

2012-08-10T17:56:00.004-04:00

The Army will achieve much bigger savings from eliminating application duplication and from preparations of apps to movement to cloud computing than from physical data center consolidation. To date, the Army has identified 16,000 applications that are running at post camps. The challenge is working ways how to devise application modernization and consolidation.

So far the Army’s data center consolidation efforts have been a “forklift operation,” which is moving servers from one location to another. That is costly but without demonstrable payoffs.

The Army is not showing major saving from cutting data centers through merely relocating servers. The savings are in the elimination of the duplication of maintenance and support costs of local applications, usually performed buy local contractors.

Just how many data centers the Army has is still an unknown. It has been estimated that the Army currently has about 500 data centers where a center is defined as a facility with 300 square feet or larger fully devoted to data processing. That is now defined as a closet, room, floor or building for the storage, management and dissemination of data and information.

SUMMARY
The costs of IT are not in servers, which are not expensive, but in the expense for support and maintenance labor. Any efforts that concentrate on the numerical elimination of the data center count – especially if this count is magnified through changing definitions – will lead to misleading conclusions. Data center elimination should be measure in the reduction in total operating costs, not in counting installations. This makes application consolidation a much greater challenge, as code has to be transported into virtual computing that can accept compatible policy implementation, such as security.

What is the Age of DoD Silos?

2012-08-04T16:41:00.000-04:00

Last month we reported that there were 2,904 separately funded FY12 IT budgets. Many of these would be set up to operate their own and incompatible networking, storage, server, operating systems, middleware or control commands.

Silos have a long history in DoD. They often stretch for decades. During a long development time they create distinctive formats that keep reducing the interoperability with other solutions. The enclosed tabulation of some long-term projects accounts for 18% of total IT spending, This illustrates up to 35 years during which program managers and contractors keep developing silo-specific features.

Over a decade any IT investment will lock in unique codes and interface formats. Programs will be continually re-written for updating information technologies. To maintain connections will requires continuous modification of the supporting infrastructures of two or more silos. Format translations and compatibility bridges for files will have to be constructed and maintained. That adds large amounts of support costs and increases the problems of maintaining security. Contractors will be kept permanently busy just keeping the various reporting arrangements consistent.

DoD cannot afford supporting the continuous stream of maintenance costs associated with decades long software development cycles. As an immediate remedy it is now in a position to acquire software that will accelerate the adoption Information-as-an-Infrastructure (IaaS) solutions. There are now hundreds of cloud services firms that offer such technologies, though they range from proprietary (such as Amazon, Microsoft and Google) to open source (such as VMare) solutions.

Instead of keeping up separate infrastructures for each silo, DoD can start migrating to a much smaller number of infrastructures. This can be done by evolutionary migration. Each legacy silo applications can be “encapsulated” into a virtual package so that it can now run on its own virtual computer.

Such virtual computers can take advantage of pools of shared servers, of disk memory and of a shared communications environment. Capacity utilization will then increase. Security policies will be enforceable across an entire range of virtual computers. The conversion to IaaS services will become one of the principal means for delivering the projected reductions in the number of data centers that is presently receiving widespread attention.

Though a reduction in the number of data centers will result in cuts in expenses for brick and mortar facilities as well as for managerial overhead, the major gains will come from the pooling of processing capacity for better utilization and for sharing of disk memories that will offer reductions in the required disk space. Hard to quantify gains will come, however, from the consolidation of security services. Formerly costly security enforcement means, such as expert manpower and specialized security appliances will now be available for more consistent control of security measures.

Instead of elongating project schedules for individual silos, DoD should be able evolve in very short order to a much smaller number of enterprise infrastructures, each subject to central controls for assuring data and communications interoperability. Existing silo budgets for separate infrastructures will have to curtail further spending on infrastructure to fund a much smaller number of pooled enterprise solutions. Such migration could start in the next fiscal year by shifting processing of parts of some applications from legacy silos to a limited number of commercial public clouds from where they would support as “hybrid cloud” solutions without users seeing much of a difference. After sufficient experience is gained, parts of such solutions could then relocate into DoD owned and operated private clouds.

DoD will have to find a method for extracting funds from increasingly obsolete legacy programs to Joint enterprise projects that offer a shared infrastructure. Such a move will allow DoD components to concentrate on applications, but without their prohibitively expensive custom-made infrastructures.

The original 1992 intent for creating DISA was to make it a shared provider of enterprise services. The fiscal mechanism for delivering such services has been long available as working capital funds that can be used to charge individual users not as allocations of fixed costs, but as a fee for services used. Transaction-based pricing will have to be instituted in this new environment so that components can make competitive comparisons as they shifts cloud workloads between cloud services in a hybrid environment.

Managing Multi-Platform Clouds

2012-07-19T12:13:00.004-04:00

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

2012-07-16T10:57:00.003-04:00

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

2012-07-13T17:46:00.000-04:00

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

2012-07-04T09:02:00.002-04:00

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

2012-07-04T07:27:00.000-04:00

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)

2012-07-02T14:22:00.008-04:00

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.