Loading...

powered by co-ment®
 

National Cyber Leap Year Summit 2009:  

Exploring Paths to New Cyber Security Paradigms  

Draft Report of Participants’ Ideas 

 

August 24, 2009 

New Game: Attacks only work once if at all. 

This document explores Moving-Target Defense as a path to this new game. 

 

The following ideas were captured in unedited form at the National Cyber Leap Year Summit. The ideas are a summary of the discussion of the participants in the Moving-Target Defense session.  They do not necessarily represent the opinions of the co-editors or the organizations they represent. The Summit is managed by QinetiQ North America at the request of the NITRD Program, Office of the Assistant Secretary of Defense Networks and Information Integration, and the White House Office of Science and Technology Policy. 

Please provide your comments, if any, by September 3, 2009 for utilization by the Summit’s program co-chairs. To add a comment, select the “Add” tab in the left navigation menu, select (highlight) the portion of the document you are commenting on, and provide your comment.  If commenting on an entire section, you may select the section heading to anchor your comment.

If you have any further questions or comments, please visit the National Cyber Leap Year Web site at the following address: http://www.nitrd.gov/NCLYSummit.aspx, or send email to leapyear@nitrd.gov.

 

What is the new game? 

In the current game, attackers win by taking advantage of the relatively static nature of our systems. For example, permanent, well known addresses, names, port numbers, etc. represent clearly identifiable parameters that turn vital servers and services into an easy target. Adversaries can plan at their leisure, relatively safe in the assumption that our key IT assets will look the same for a long time. They can map out our likely responses and stockpile a set of exploits that escalates in sophistication as we deploy better defenses. They can afford to invest significant resources in their attacks because they expect to persist in our systems for a long time.  In the new game we win by increasing the randomness or decreasing the predictability of our systems. By making the cyber terrain appear chaotic to the adversary, we force him to do reconnaissance and launch exploits anew for every desired penetration; the attacker enjoys no amortization of development costs. The new game, in this context, consists of considering very dynamic rather than static network architectures. In other words, the new game is about real-time distributed monitoring, control and diagnosis of very dynamic and flexible cyber environments.

 

1 Mutable Networks: Frequently Randomized Changing of Network Addresses and Responses

1.1 Description

A prerequisite for building successful cyber defense systems is to investigate effective countermeasures to scanning and reconnaissance attacks that allow for discovering network resources end-addresses and system finger print. Scanning and reconnaissance attacks are precursory steps to launching devastating attacks such as system penetration or denial of service. The objective of this project is to provide the ability to dynamically change the external host interfaces such as names, IP addresses, and port numbers. Also, the external response behavior should be randomly changed to counter scanning worms, and reconnaissance and finger printing attacks. These changes are accomplished by continuously outdating the collected system information within a short time window, and deceiving attackers to fake targets for further analysis.

In this proposed approach, networked systems (i.e., end-hosts) will be assigned different addresses frequently based on random functions such as hash tables. One approach is to select interfaces using the randomized round robin technique. The change has to be done: 

Redundancy can be added to this scheme using Virtual Machines to support recovery and diversity to the attack profile surface.  

We have two mechanisms to randomize external system responses: 

1.2 Inertia

1.3 Progress

1.4 Action Plan

Note: Must add specific actions - currently just listed technical issues

1.5 Jump-Start Plan

1.5.1 Technical Plan

1.5.2 Experimentation Plan

1.5.3 Team Collaboration and Bootstrapping

1.5.4 Case Study

 

2 Diversity in Software

2.1 Description

Currently, we live in a software monoculture - most computers run essentially the same software. This makes it easy for an attacker because the same attack vector is likely to succeed on most computers. If we make every computer run a subtly different version of the same software, a different attack vector is needed for different computers. From the perspective of the end-user, all the different versions behave in exactly the same manner, but they implement their functionality in subtly different ways.  

 

As a result, any specific attack will succeed only on a small fraction of systems and will no longer sweep through the whole internet. An attacker would require a large number of different attacks and would need to target the specific software versions that are susceptible to each specific attack, which radically increases the cost to the attacker. The effective penalty to the attacker is the inability to amortize knowledge over a series of attacks. - each attempt is distinct from any previous attempt or attempts. If multiple versions of the same software are run in parallel on a single computer, attacks could be detected in real-time when the behaviors of the versions diverge as the result of an attack that is successful on only some of the versions, but not on others. 

2.2 Inertia

Until now, software was predominantly shipped "in boxes on a CD". Mass production of the CDs made it impractical to give every user a different version. But we are rapidly transitioning to software distribution over the network, where this is no longer a concern. 

There is a cost associated with creating diversity. Until now, people have been oblivious to the risks and have not embraced the idea of paying for security. The tradeoff between security vs. performance is only now becoming better understood by a wider audience.  

Until now, we have focused on creating the "best" version, e.g., in compiler optimizations. Only one of the versions can be the "best". So if we give a different version to every user, by definition, not everyone can have the "best" version. So there is a performance cost associated with this solution. There is an additional intrinsic cost of diversity - configuration management, centralized administration, etc. might become more onerous.  

Security has in the past focused on "predictability" and testing. The idea of running completely different code on each individual computer requires a radical shift in thinking and culture and certification and accreditation, because, by definition, one can no longer test all of the versions, but one is required to trust the compiler.  

Understanding the complexities of software and hardware dependencies among linked/embedded applications is not well preserved

2.3 Progress

Distribution of a different program version to each and every customer becomes feasible when software is downloaded via the network rather than installed from a CD. We have just arrived at the point when many programs are now routinely installed only from the internet. For example, more than 400 million people have downloaded the Firefox browser.  

Computers now have such high performance that paying a small performance overhead such as 5%-10%, for the extra security brought about by diversity, may be worth the cost in many contexts.  

Compilers have advanced very significantly, so that automated generation of variants is now a reliable and predictable process. Even dynamic compilation is now routinely employed with very high reliability. For example, Apple has transitioned millions of users from the PowerPC to the Intel architecture using a fully automated just-in-time compiler without any reported incidents. The reliability of these compilers is stunning, considering that they have been able to automatically translate programs of the size of the Microsoft Office suite fully unattended, without any testing of the resulting output, and on-the fly.  

Multi-core processors offering high degrees of parallelism (80 cores already announced by Intel) make it feasible to run several slightly different versions of just one program in parallel.  

2.4 Action Plan

2.5 Jump-Start Plan

Pick an existing open-source project (Firefox, Apache) with documented past vulnerabilities. Modify the compiler used in its build process to generate many functionally equivalent versions simultaneously. Run old software versions with known vulnerabilities through the diversity mechanism and measure which proportion of attacks no longer succeed on the diversified code base. 

 

   

3 Robust Random Authentication

3.1 Description

Tests to authenticate someone vary dynamically (at different points)  

3.1.1 Concerns

3.1.2 Mitigation

3.1.3 Benefits

3.2 Inertia

3.3 Progress

3.4 Action Plan

3.5 Jump-Start Plan

3.5.1 Use Case

As part of this effort we would include a number of examples and test cases that can serve as explicit illustrations of how the pilot can be expanded and used by a larger audience. One test case could be to have three or more financial institutions, at least one non-financial company and at least one government agency cooperate to use interoperate medium Federal Institute of Processing Standards (FIPS)/National Institute of Standards and Technology (NIST, Level 3) assurance credentials for login to multiple online sites. The scenario might include a member of another critical industry requiring high identity assurance, such as the healthcare industry. The scenario could also illustrate how authentication could be applied to smart devices such as power grid sensors.

 

 

4 Robust Random Authentication

 Idea: Most cryptographic techniques, protocols and implementations today are brittle and vulnerable to catastrophic collapse of security due to a single point failure. This is in part because remote penetration, social engineering, insiders, supply chain modifications, and the age-old practice of bribery continue to provide successful means to bypass cryptography. Better cryptography, longer key lengths, algorithm composition, etc., do absolutely nothing to remediate these bypass vulnerabilities. The goal is develop a new generation of cryptographic systems that are resilient to multiple compromises. Although new cryptography can incorporate multiple hard mathematical problems, attention to the broader range of attack surfaces is necessary to staunch current hemorrhaging. 

4.1 Description

Cryptographic systems can collapse due to failures in multiple dimensions, or attack surfaces, often beyond the crypto-analytic components. By making these dimensions impervious to single failures, attackers will face increased work factors. Below are listed dimensions of fragility together with approaches to improve resiliency.  

4.1.1 Randomizer Failure

4.1.2 Incorrect Implementations (Supply chain)

4.1.3 Secret Key Compromise

4.1.4 Side Channels and Covert Channels

4.1.5 Software Bugs

4.1.6 Hardware Failure

4.1.7 Depot and Distribution Vulnerabilities

4.1.8 Weak Standards

4.1.9 Loss of Physical Security

4.1.10 Novel Attacks

4.2 Inertia

4.3 Progress

4.4 Action Plan

4.5 Jump-Start Plan

4.5.1 Use Cases

5 Connectivity Diversity

Introduce duplicative, rotating network connectivity, redundancy in throughput, larger number of network traffic paths  

5.1 Description

Connectivity diversity (or path diversity) refers to the ability to provide multiple physical and virtual paths between information sources and users. It includes physical path, transmission media, logical path, provider (carrier), and technology diversity. Also included is the capability to create unpredictable and dynamic paths using intelligent Sense-and-Respond mechanisms that minimize the opportunity for single-points of failure. This makes Denial of Service (DoS) attacks and Man-in-the-Middle (MiM) attacks more difficult to achieve because the path that data packets travel through the network changes in unpredictable ways. End systems do not need to know the algorithm for the path changes; they only the network equipment including edge routers needs to know this. Although the technology exists for path diversity and re-routing, the Game Change is to change paths "unpredictably" (from an attacker's perspective) with Sense-and-Respond intelligence.  

The business case / benefits for connectivity diversity (in addition to the cyber-security benefits) includes the use of path diversity as a mechanism to support disaster recovery / continuity of operations Disaster Recovery (DR)/ Continuity of Operations Plan (COOP). 

5.2 Inertia

Why have we not done this before? What would derail the change?  

5.3 Progress

Why technically is this feasible now?  

Why environmentally is this feasible now?  

What would mitigate our doubts?  

5.4 Action Plan

What are reasonable paths to this change?  

What would accelerate the change?  

5.5 Jump-Start Plan

Pieces of the action plan that can be started now  

An example use-case is to have a network with multiple physical and logical paths available using current routing and recovery techniques, engage NSA or other skilled red team to perform a Distributed Denial of Service (DDoS) attack targeted at denying service at a target host; then enabling connectivity diversity and performing the same DDoS attack - access to the host should remain available using other network paths and media. (This use case / test case should prove the hypothesis of defeating DDoS attacks.)  

Start longer-term research efforts by building collaborative teams such as:  

 

 

6 Decoys

What does this change look like? 

Most applications, systems and networks are not perfectly secure. Hence, it is a matter of time until they can be compromised in a targeted attack. The core idea of decoys is to distinguish attackers from authorized users and additionally provide a large number of decoys (fake targets) to attackers while only providing the real targets to authorized users. As a consequence, attackers will be slowed down (probably confused or discouraged) by interacting with fake targets and defense will be able to easier distinguish authorized from unauthorized activities, i.e., detect new attack activity. Ideally, this mechanism will be invisible to the authorized user.  

6.1 Description

Decoys provide several advantages to defenses in cyberspace. First, they can decisively delay and confuse attackers by presenting them with fake targets. Second, since decoys are not usually accessed, any such access points to ongoing attacker activity, which can range from mapping out networks to launching exploits or denial of service attacks. Detecting new or newly initiated attacks, together with slowing down the attacker, the defense wins valuable time to prepare a response or to study attacker's behavior to discover unknown ways of attackers (unknown vulnerabilities or new ways of evading firewalls, anti-virus, or access controls). Decoys can take different forms to effectively protect various security targets. They can fake systems, virtual machines, applications, data, or networks.  

Attackers end up at decoys because the decoys are reachable over shortcuts or they may bypass common access control patterns. The decoys increase the attack surface while decreasing the probability of a successful attack on the real target and hence reduce the attack Return on Investment (ROI).  

To significantly slow down and frustrate the attackers, the ratio of real: decoy targets must be very low, for example on the order 1:10000. This, in essence, creates a large additional attack surface that an attacker needs to cover before eventually zooming in on the real target (c.f., Honey pots and Honey nets). There are several ways to 'slow down' attackers at decoys; they reach from simply shallow multi-system emulations listening on ranges of unused network addresses to full fake run-time environments with fixed IP and real business application configurations (traps, jails) that are more difficult to distinguish from real targets even for attackers taking control of the decoy.

6.2 Inertia

Why have we not done this before? What would derail the change?  

6.3 Progress

Why technically is this feasible now? Why environmentally is this feasible now? What would mitigate our doubts?  

6.4 Action Plan

What are reasonable paths to this change? What would accelerate this change?  

6.5 Jump-Start Plan

Pieces of the action plan that can be started now  

6.5.1 Use Cases

 

7 Configuration-Space Randomization for Infrastructure

7.1 Description

Configuration is the glue that logically integrates components to support end-to-end services. It defines the logical structures and relationships at and across multiple protocol layers. Acquiring this information is critical for attack planning, e.g., for identifying high-value targets, the paths to reach them, the intermediate components to compromise, and customizing attacks to each target. We propose to make this information much harder for an adversary to acquire by randomizing it, but, doing so in such a way, that end-to-end services continue to be available. This is analogous to address-space randomization for software that makes it much harder to plan buffer overflow attacks and frequency hopping that makes it difficult to plan jamming attacks on communication links.  

Notes  

7.2 Inertia

7.3 Progress

7.4 Action Plan

7.5 Jump-Start Plan

7.5.1 Use-cases/Scenarios

 

8 Distributed Data Shell Game

Idea: Break data into pieces and move it around. The results will ensure all aspects of CIA: Confidentiality, Integrity and Availability. The process obscures data thereby assuring confidentiality. Any violations of a piece of data's integrity will result in failure to recombine. Availability is enhanced by distributing the risk across locations and allowing recovery when a location is lost. The addition of cryptography to the system will further increase confidentiality and privacy. 

Concerns  

Mitigation  

8.1 Description

8.2 Inertia

8.3 Progress

8.4 Action Plan

8.5 Jump-Start Plan

8.5.1 Use Case

 

9 Security on Demand

Change the current mindset from the idea that security needs to keep bad guys out to assuming that we are essentially in a fundamentally insecure environment. Therefore, if you need security (trustworthiness), you need to do things differently. The "things you would do differently" will present a computing void to the adversary (i.e., if he breaks in he will not find the address book, which will reside on the detached stick; if a zombie is installed, most of the time, he will not have a fully functional network to propagate-in general, he will have access to useless information, resources etc, or things that will become useless within a short period of time). You will dynamically constitute a "trustworthy cocoon" -- on demand, to run the application that needs higher security. The cocoon will include the application as well as the infrastructure you need to use that application, and the trustworthiness will be verifiable. At the same time, the cocoon will take a different shape (variant) each time, and each cocoon will be short lived, and exposed to public networks for a short duration.  

Note this is not a silver bullet to all problems-- this technique will work better for applications that do not need long duration sessions. 

Concerns  

Mitigation  

9.1 Description

9.2 Inertia

9.3 Progress

9.4 Action Plan

9.5 Jump-Start Plan

9.5.1 Use Case

 

 

10 Security on Demand

Change the current mindset from security needs to keep bad guys out to assuming that we are essentially in a fundamentally insecure environment. Therefore, if you need security (trustworthiness), you need to do things differently. The "things you would do differently" will present a computing void to the adversary (i.e., if he breaks in he will not find the address book, which will reside on the detached stick; if a zombie is installed, most of the time, he will not have a fully functional network to propagate-in general, he will have access to useless information, resources etc, or things that will become useless within a short period of time). You will dynamically constitute a "trustworthy cocoon" -- on demand, to run the application that needs higher security. The cocoon will include the application as well as the infrastructure you need to use that application, and the trustworthiness will be verifiable. At the same time, the cocoon will take a different shape (variant) each time, and each cocoon will be short lived, and exposed to public networks for a short duration.  

Note this is not a silver bullet for all problems-- this technique will work better for applications that do not need long duration sessions. 

Concern  

Mitigation:  

10.1.Description

(Concept of Operations (CONOPS)) What will it look like?  

Imagine the future where traditional desktop/laptop computers have become the chassis on which key chain computing Secure Digital Input/Output (SDIO) devices with enough CPU and memory to run Linux and at least one VM can be plugged in-- the laptop/desktops will only be used to provide the IO/peripheral functions to the key chain devices. You will have one dedicated device for each of your critical applications (e.g., email, banking, Google app client etc.) running a VM specialized to run that app—(e.g., all other services and ports disabled). A verified version can be preloaded to the device, but the VM can also have software to load variants of the app (leverage SW diversity) from a "trusted source" (see below for how to get to that source). It is also conceivable that the device will only have a very basic loader-- and when you connect to the network you will be pushed a secure variant of the entire VM.

If you need to use banking, you plug in the "banking app" device. The device-chassis pair engages in attestation checking (TPM and other HW support in modern processor architectures). If the check succeeds, the device boots up. Then, from the device's memory, a functionally equivalent variant of that application could be loaded to run on the device. (Alternatively, as noted before, a variant can be downloaded after you have network access).  

When the device boots up, you (the user) request a protected path (imagine establishing a VPN tunnel) to destination from your network provider. For this to work, like a telephone network, the chassis must have a dial tone--i.e., instead of always on broadband, the chassis is connected to the ISP with a very basic highly controlled channel. If your request for secure path is granted, you have a fatter pipe, but also with VPN-type protection. You can have better QoS if you pay more:  

Benefits  

10.2 Inertia

 

 

Derailers  

10.3 Progress

Feasible Technology  

Environmentally Feasible 

On the environmental front: realization that we are under attack, and perfect security that will prevent that is a pipe dream. 

10.4 Action Plan

10.5 Jump-Start Plan

Do an advanced technology demonstration (ATD) pilot on a moderate scale: choose one application (a good attack target such as outlook and exchange), give 500 random volunteers the stick device loaded with SoD client and host a dynamically managed SoD exchange servers in multiple clouds. Use BoD among the Exchange servers, allow volunteers to request for protected service from the ISP. Engage a red team to attack the clients. This project is shovel ready (BBN Technologies and CSC inputs to the NITRD Conference Leap Year processes provide more detail, prior work from a SANS can be rolled in as well) and can be started in the next 60-90 days. The project will have a 9 month development phase (to work out the right scope and remaining engineering) followed by a 9 month field trial.  

10.5.1 Use Case

 

 

11 Terrorist Organization Model

Idea: use the decentralized nature of terrorist groups and cells as a reference model for a new information system. Terrorist groups are hard to penetrate, not susceptible to large losses if a subpart is compromised, and can work autonomously with a very small rule set. This model is a "game changing" idea in that it approaches computer and network science in a radically different manner. 

Mitigating  

11.1 Description

This is a fundamentally different approach to information systems as compared to today's hierarchical models.  

11.2 Inertia

There would be significant cultural resistance to this approach, due to the many decades of development invested in the current architectures and reference models. Also, the idea of "terrorist groups" is offensive to many and might hamper good innovation and creativity. There are many unknowns and not much literature on the specifics of how these groups communicate and protect themselves. 

11.3 Progress

Some applications use an early and crude application of this methodology such as Massive Multiplayer Online Games (MMOGs), disposable hardware devices, social networking sites, web 2.0, and the portion of our society known as "Generation Y". Service Oriented Architectures (SOAs) might also provide some insight into how this model might work due to the "loose coupling" of services offered by SOA.

11.4 Action Plan

Need to better understand how terrorist groups organize, how their information networking evolves, why they are hard to penetrate, where the resilience comes from, and how the capturing of one person or cell has little impact on the entire operation. These groups might follow the principles of complex and chaotic systems, which could in turn provide insights for a new reference model for information systems. 

11.5 Jump-Start Plan

12 Smart Motion Adaptation Management

Redundancy and diversity in SW, infrastructure and resources create the space where defended systems can shape shift. Develop a sound model to manage the movement in that space such that it is unpredictable to the attacker. Use variety of modeling techniques including but not limited to game-theory, machine learning, statistical, control theory, cognitive reasoning and planning to develop the algorithms that manage the dynamic system behavior. 

12.1 Description

The "smart management" will use the various options and/or possibilities unleashed by other techniques. For example, how to place replicas, which address/port to use, which variant to use, how to configure the network (overlay/interconnection) etc. all dynamic adaptation decisions will be governed by this smart management mechanism.  

Benefits  

12.2 Inertia

Derailers  

12.3 Progress

Feasible Technology 

Environmentally - The stakeholders are more receptive now-- with the adaptation space growing large, smart management is inevitable.

12.4 Action Plan

12.5 Jump-Start Plan

 

 

A Acronyms  

Acronym 

Description 

ATD 

Advanced Technology Demonstration  

AMD 

Advanced Micro Devices 

AMT 

Active Management Technology 

ARL 

Army Research Laboratory  

ARO 

Army Research Office 

BoD 

Bandwidth on Demand 

CAIDA 

Cooperative Association for Internet Data Analysis  

CapEx 

Capital Expenditure 

CDN 

Content Delivery Network 

CONOPS 

Concept of Operations 

COOP 

DisaContinuity of Operations Plan 

COTS 

Commercial Off-the-Shelf 

DARPA 

Defense Advanced Research Projects

DDNS 

Dynamic Domain Name Service 

DDoS 

Distributed Denial of Service 

DETER 

Testbed for Network Security projects 

DHCP 

Dynamic Host Configuration Protocol 

DHS 

Department of Homeland Security 

DNS 

Domain Name System 

DOI 

Digital Object Identifier 

DoS 

Denial of Service 

DR 

Disaster Recovery  

DREN 

Defense Research Engineering Network  

FPGA 

Field Programmable Gate Array 

FIPS 

Federal Information Processing Standards 

GENI 

Global Environment for Network Innovations

HR 

Human resources 

HSRP 

Hot Standby Router Protocol 

IDS 

Intrusion Detection System  

IETF 

Internet Engineering Task Force 

IPS 

Intrusion Prevention System 

IPv6 

Internet Protocol Version 6 

JIT 

Just-in-Time 

KVM 

Kernel-based Virtual Machine 

MANET 

Mobile Adhoc Networks  

MMOG 

Massive Multiplayer Online Games Massive Multiplayer Online Games  

MPLS 

(Multi-protocol Label Switching 

NAT 

Network Address Translation 

NSA  

National Security Agency 

Nessus 

A network scanner tool 

NIST 

National Institute of Standards and Technology 

Nmap 

Network Mapper 

NSA 

National Security Agency 

NSF 

National Science Foundation 

OpEx 

Operation Expenditure 

OTP 

One Time Password 

PII 

Personally Identifiable Information 

PKI 

Public Key Infrastructure 

QoS 

Quality of Service 

ROI 

Return on Investment 

RPR 

SONET Rapid Path Restoration (RPR) 

SAT 

Boolean Satisfiability  

S&T 

Science and Technology (S&T) 

SCADA 

Supervisory Control And Data Acquisition

SDIO 

Secure Digital Input/Output 

SOA 

Service Oriented Architectures 

SoD 

Security on Demand 

SLA 

Service Level Agreement

SONET 

SONET Rapid Path Restoration (RPR) 

SSL 

Secure Sockets Layer 

VT 

Virtualization Technology  

TCP 

Transmission Control Protocol 

TPM 

Trusted Platform Module (TPM), 

TC 

Trusted Computing 

vBNS 

Very Highspeed Backbone Network Service 

URN 

Uniform Resource Name (URN 

VLAN 

Virtual Local Area Network 

VoIP 

Voice Over Internet Protocol 

WIFI 

Wireless Fidelity 

Xen 

Open source industry standard