Cyber War and the Threat of the Boomerang Effect

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?

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?

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?

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?

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?

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.