Jeff Simpson - Cyber Maneuver Warfare and Active Cyber Defense - from ICCWS 16
•Download as PPTX, PDF•
3 likes•717 views
Presentation on Cyber Maneuver Warfare and Active Cyber Defense from the International Conference on Cyber Warfare and Security. Describes the scope and challenges of runtime service discovery in active wartime battlefields. Also provides an overview to the Argo (argo.ws) Runtime Service Discovery system.
Recommended
Recommended
More Related Content
Similar to Jeff Simpson - Cyber Maneuver Warfare and Active Cyber Defense - from ICCWS 16
Similar to Jeff Simpson - Cyber Maneuver Warfare and Active Cyber Defense - from ICCWS 16 (20)
Recently uploaded
Recently uploaded (20)
Jeff Simpson - Cyber Maneuver Warfare and Active Cyber Defense - from ICCWS 16
- 1. CYBER MANEUVER WARFARE AND ACTIVE CYBER DEFENSE JEFF SIMPSON DEFENSE INTELLIGENCE INFORMATION ENTERPRISE (DI2E) OFFICE OF THE UNDERSECRETARY OF DEFENSE FOR INTELLIGENCE (OUSDI) MARCH 18, 2016 3/17/2016Copyright (c) 2016 Jeff Simpson 1
- 2. BONA FIDES • 30 years of professional experience building software for academic, commercial, intelligence and military applications. Specialty in developing complex distributed application. • I was the Chief Federal SOA Architect for BEA Systems (WebLogic) • Chief Architect for a couple of DoD/IC Netcentric Warfare programs • Netcentric Enterprise Services (NCES) – SOA Foundation program • IC/DoD Enterprise Registry/Repository program (ER2) under the Director of National Intelligence • Chief Architect for OUSDI Service Discovery Focus Area • Author of the Argo runtime service discovery protocol and open source implementation used by various US intelligence Programs or Record such as DCGS. • Deployed to Afghanistan in 2013 and 2014 supporting intelligence and operations • NATO ISAF HQ in Kabul and USFOR-A RC-South in Kandahar. 3/17/2016Copyright (c) 2016 Jeff Simpson 2
- 3. CYBER MANEUVER WARFARE AND ACTIVE CYBER DEFENSE HYPOTHESES • Battlefield superiority is largely based on agile and rapid use of information and the creation of shared situational awareness of dynamically composed maneuver elements in the battlefield. • Cyber war will be used to manage the “initiative” of the enemy. • Network-based Moving Target Defense (NB-MTD) would be used as a defense tactic against various physical and cyber domain attacks and vagaries Current exercises and experiments are in progress and on-going 3/17/2016Copyright (c) 2016 Jeff Simpson 3
- 4. BATTLEFIELD NETWORK COMPLEXITY Problem: How to rapidly setup network, configure networked C2ISR applications and recover/reconfigure from kinetic/cyber attacks? 3/17/2016Copyright (c) 2016 Jeff Simpson 4
- 5. CURRENT CYBER ATTACK DEFENSE AND RESPONSE PROFILE • Assumptions • You’re preventing malware on secret operational networks (SIPR, JWICS, CENTRIX, BICES, etc.) • Non-combatant system administrators are always available to setup, configure and maintain battlefield C2ISR systems • That it’s easy to know and communicate the network locations of C2ISR systems • Mitigate classic cyber attacks (MITM, DDoD, etc) post-attack with classic responsive mechanisms • Isolate system and perform forensics, recovery, attribution, etc. What’s the bad guy thinking? • Infiltrate networks (pre-placed Trojans, social networking, insiders, etc.) • Kill or disable the system administrators who can fix stuff I break • Cause network mayhem to slow down military response by: • blowing up the physical networks • launching as many well-timed cyber attacks as I can (take out DNS and NTP) 3/17/2016Copyright (c) 2016 Jeff Simpson 5
- 6. TYPES OF ACTIVE CYBERSPACE MANEUVER Question: How do you maneuver in cyberspace? Answer: Change your system’s IP address Imagine all C2ISR systems are equipped with “Apple Bonjour” and can find other systems easily DNS is not helpful in the future cyberwar battlefield. • Initial setup and configuration of battlefield C2ISR applications • Configure connections between systems in ad hoc mobile networks • Dynamic Maneuver in operational network during battle conditions Problem: how do C2ISR apps “discover” the IP address of other networked C2ISR apps? 3/17/2016Copyright (c) 2016 Jeff Simpson 6
- 7. RUN-TIME SERVICE DISCOVERY Changing the IP address of a service is easy. Telling clients that the service moved and giving them what your new IP address is hard. 3/17/2016Copyright (c) 2016 Jeff Simpson 7
- 8. RUN-TIME SERVICE DISCOVERY TECHNOLOGY Central Registry based • UDDI • Consul • Zookeeper/Curator • Etcd • … and thousands of custom domain/application specific database implementations Distributed Pub/Sub Probe based • AllJoyn • WS-Discovery • Multicast DNS (DNS-SD/Bonjour/Avahi/Google NSD) • SSDP (UPnP) • … and hundreds of other domain specific protocols • Cluster management, Database replication, etc. Registries are prime targets of attack and are useless in ad hoc mobile and dynamic networks Pub/Sub types are all ”link local” network only and completely unsecure 3/17/2016Copyright (c) 2016 Jeff Simpson 8
- 9. CYBERWAR MANEUVER RUN-TIME SERVICE DISCOVERY REQUIREMENTS • Operate in a wide-area and ad-hoc networking environment • Participate with other service discovery mechanisms • Operate on a number of “private” discovery channels simultaneously • Easily integrated and configured with already deployed systems We couldn’t use any existing Pub/Sub Probe based technologies. 3/17/2016Copyright (c) 2016 Jeff Simpson 9
- 10. ARGO RUN-TIME SERVICE DISCOVERY • Argo is the DI2E Framework Service Discovery Solution • Open Source via GitHub – www.argo.ws • Satisfies the Cyberwar Maneuver run-time service discovery requirements ClientSoftware ServiceSoftware Argo Responder Transport Listener Probe Sender Transport Sender Response Listener Argo transports can be multicast, Amazon SNS and MQTT topics Argo Responses are via HTTP or HTTPS REST calls Probe Handler The handler plugin gets the configuration information for services. There are OOTB handlers for local files, UDDI and API Mgmt. Other plugins are easily developed. Probe Handler Probe Handler Consul UDDI Config File Transport Listener Transport Listener 3/17/2016Copyright (c) 2016 Jeff Simpson 10
- 11. CURRENT AND FUTURE EXERCISES • DI2E PlugFest ‘15 & ‘16 - Extending Interoperability and Reuse for the War fighter • The DI2E Plugfest is the annual demonstration of advancements in the DI2E. The purpose is to provide a environment of networked, interoperable and reusable components, the Plugfest eXchange, where vendors are able to deploy and show their tools to provide flexible, agile and data-driven capabilities to Warfighters. • http://di2eplugfest.org/ • Enterprise Challenge ’16 • EC is a multinational exercise focused on how soldiers in the field collect intelligence for tactical advantages while working on other enterprise objectives, including sensor interoperability, international partners’ interoperability, advancing DOD’s cloud computing strategy, supporting the Defense Intelligence Information Enterprise and conducting enterprise interoperability assessments of the various Command & Control and Intelligence systems. These exercise are utilizing the Argo Runtime Service Discovery infrastructure 3/17/2016Copyright (c) 2016 Jeff Simpson 11
- 12. RESULTS & QUESTIONS • Initial exercises show favorable results with the first two types of Cyber Maneuver • Initial setup and configuration of battlefield C2ISR applications • Configure connections between systems in ad hoc mobile networks • Promising signs of adoption in the DoD/IC community • Abandoning notions of “giant registry in the sky” – e.g. UDDI • Exercises that demonstrate a NB-MTD utilizing a Dynamic Maneuver mechanism are in the future 3/17/2016Copyright (c) 2016 Jeff Simpson 12
Editor's Notes
- Hello. My name is … When I mention warfare, I’m not talking about ”soft warfare” like taking down or defacing a government website or hacking and exposing some emails from Sony Pictures. I’m talking about a hot war, where large scale military maneuver elements go toe-to-toe in pitched battle. Where attack and maneuver with cyber weapons in cyberspace is just as real and damaging as attack and maneuver with conventional weapons in the physical domains.
- Before we dive in deep, I’d like to briefly cover my background.
- We have some hypotheses with respect to Cyber Maneuver Warfare. The first is Battlefield Superiority. Can we rely on agile and rapid use, sharing and coordination of shared situational awareness with maneuver elements and their supporting cyber assets in the battlefield. Secondly: Can Cyber maneuver warfare be used to “manage the initiative of the enemy”? In military doctrine, “The Initiative” is the ability to act first and dictate the actions of the enemy and control the tempo of battle. We know that there have been what I’d call “dress rehearsals” of this type of cyberwar that coordinates kinetic physical attack with cyber domain attacks. Israel and Russia both been known to have executes operations that executed a “combined effects” attack using cyber and kinetic elements. And lastly, can we use a network based Moving Target Defense as a tactic against various physical and cyber domain attacks. And can we use these techniques to mitigate the vagaries of operating in a dynamic mesh network battlefield.
- Computers run the modern battlefield. The speed and efficiencies the networked and computerized battlefield provide the Kill Chain cannot be underestimated. How do we use information to put metal on target and kill the bad guy? One of the major reasons that the US war machine is so powerful is the ability to execute with tremendous speed and agility. Surely, the smart weaponry helps, but you have to know where and when to shoot in order for it to be effective. Modern battlefields depend on computers to help analyze and coordinate modern maneuver elements in the various domains of the battlefield, Ground, Air, Maritime and Space. This is where the idea of Network Centric Warfare comes into play. What do “they” mean when they talk about Netcentric Warfare (NCW) using a Services Oriented Architecture? This diagram is the type folks use to show how NCW would actually be employed. Surely it looks complicated, but in actuality is far more complicated than this. The thing is, there are many assumptions in this picture in that need to be exposed in order to see where I’m going with this talk. One, all of these lines represent link in a mesh communication network. Many of these network links are more “hardcoded” than you might think. The routing through this network is a bit more static that one would hope for in a dynamic cyber battlefield. Further, the applications that are operating in this network, be they Command & Control or ISR or readiness, logistics, financial, etc. are, I guess, expected to operate in a Service Oriented Network. However, to get any of these application to work together, human administrators need to manually configure the applications to talk to other endpoint services exposed by other applications (or gateways) on the network. For the sake of reducing complexity in this picture, there are no security guards or other coalition network merging. However, in a coalition environment like we have in Afghanistan, that would be present. All of the nodes in this picture have some sort of C2ISR software – either sensors producing data, databases collecting the data and/or systems to help analyze and exploit the data. However, just having the network doesn’t mean that your C2ISR applications are magically connected. In NCW there is a built-in assumption that all of the data source and functionality of your application does not reside within the locally deployed client. Which means that the locally deployed client needs to be “configured” to talk to these network-based services. It means the client needs to know that IP address of the remote NCW service. In the normal world, we do this all the time every day. We look things up using Google as our discovery services and then just click on the HTTP links to get what we want or at least start the journey to what we want. When we want to print something from our Smartphone, we “just find” the printer on the network and print to it. Easy peasy. With it comes to war, things get a little more messy.
- There should be no real surprises on this slide with respect to the defense and response profile. Well, currently we make some pretty wide ranging assumptions. We assume that we can somehow keep malware (like viruses, crypto-ware, botnets, etc.) off of our secret operational networks. We run counter-intelligence operations to make sure we don’t have “bad guys” inside our ranks (the insider threat). We also assume that any system configuration will be done by humans who are always on standby to setup and maintain the computers (which works well when your in a war fighting goat-herders in Southwest Asia). The third assumption is just simply not sustainable. We assume that it’s easy to know the IP address (URL, DNS name, etc.) of the systems that we want to connect to. And finally, we currently approach mitigating cyber attacks in a responsive mode - we’ll clean it up after an attack has occurred. This shouldn’t be a surprise since this is pretty much the state-of-the-art in cyber defense and mitigation in the industry. It’s all just applied to the military networks as well. So, given this and that ridiculous picture we saw a couple of slides ago, what is the enemy thinking about is some future battlefield? They are going to go WAY out of there way to infiltrate networks. They are going to actively try to kill or otherwise neutralize the system administrators (who are currently mostly civilian contractors). They are going to employ any and all means to disrupt or deny network communication in order to show down what the US military machine does so well, get metal on target very quickly – much faster than anyone else can – with greater geographic reach and lethality that any military in the history of the world. The bad guys knows that speed and lethality is dependent on computers, networks and the exchange of information between those systems. Slow down the networks and C2ISR systems and you slow down everything else.
- Here is a quick list of how to do Cyberspace Maneuver. The list goes from simple to complex. However, this all begs the question: How do you maneuver in Cyberspace? What does that mean when you actualize it. In short, you maneuver in cyberspace by changing your IP address. Doing this can help mitigate many cyber attack scenarios (e.g. Denial of Service attacks) and it seriously disrupts the bad guys footprinting and surveillance of your network. Initial setup and configuration of battlefield C2ISR applications in a relatively static network This is what we do today. It’s very similar to corporate system administration in that we setup these systems assuming that all of the network locations will remain stable. Sure, we use DNS to configure these systems, but DNS is just a name lookup system with a very fragile hierarchical architecture (BTW the bad guys will kill DNS early and often in operational networks … today if we shut down DNS, then most of the modern miltiary opeartions centers would just stop working). So you can’t really rely on DNS. Plus DNS is completely unsecure and fragile, but that is a whole separate talk. The next two are actually closely related. “Configure connections between systems in ad hoc mobile networks” is where two maneuver elements in the battlefield merge and create an ad hoc mobile network between them. The two elements, such as a company, brigade, squadron, etc. want to share intelligence, tracks, readiness, inventory and other operationally relevant data to achieve a shared situational awareness. Or perhaps a Special Operations group enters a Forward Operating Base and want to upload images or other intelligence to the local IMINT server. This is the equivalent of BYOD in the next generation battlefield. The last one, ” Dynamic Maneuver in the operational network” means that the IP address of all the relevant C2ISR (and other) systems are constantly morphing their network locations. Why do this? Primarily this is done to thwart a plethora of active and potential network-based cyber attacks, and it further disrupts any surveillance or “footprinting” the enemy had done – it puts them back to square one and they have to reassess what IP address they want to attack. There are many reasons to do this, however, the primary reason is to keep operational system online and “black hole” various network-borne attacks. This is where we’d like to go, however, we need to get the first two types of cyberspace maneuver working first. Using the mantra “crawl, walk, run”. However, when all the systems are constantly changing IP addresses, what happens to all the clients that are connected? Well, they have to reacquire the IP address of the system they were connected to and then reconfigure themselves – preferably automatically and smoothly. So that leaves with with a problem. If clients need talk to network-avaialble services, and those services are executing “cyberspace maneuvar”, then how does the client keep talking to the right service? Imagine that the printer you selected from your phone keeps moving IP addresses all the time? You need an distributed and simple infrastructure and protocol that makes it easy to perform service discovery in a run-time environment that is in the middle of active kinetic and cyberspace warfare.
- Changing the IP address of a system is easy. Telling your clients that you’ve moved and giving them what your new IP address is hard. The idea of run-time service discovery has been around for a long time. The idea is that a client application, say an app on your phone or laptop, needs to connect to some service on the network to do something, like process something for me or query for some data. That that application is a web browser, as we need to type in the IP address of the HTTP server that has something on it we want to see. Well, you type the URL into the browser window How did you know that IP address (or URL). You either just knew it, were previously told or you discovered it using a discovery tool. However, we use dynamic service discovery all the time. There are three examples her on the left. The way “we” – the collective internet-using “we” – do discovery is by using Google. You type in your search and click on the link. The link is the “IP address” of the HTTP server you are looking for. However, Google is really just a ”giant central registry in the sky” that has a well known IP address for it’s “discovery applications” – e.g. google.com. We think of Google as “search” but really what it’s doing is discovering HTTP servers that happen to have information that you’re looking for. Say the application is some app on your phone as we want to print out something from that app to a local printer. Or, that now exists in the new YouTube apps, you can discovery a network connected TV (which these days is really a embedded computer with a big monitor) that can play YouTube videos. You can ”remote control” the TV YouTube app from your client device (phone, tablet or whatever) This is what we want to do for battlefield applications regardless of their platform. However, just taking existing “well known” technologies and applying them to the picture on the right has all sorts of problems.
- When it comes to service discovery technology, they myriad of available options fall generally into one of two camps. Central Registry based mechanism is basically an “IP Address” database. It might be worthwhile to note that DNS is NOT a discovery technology. There could be some confusion since there is actually a standard called DNS-SD (service discovery) but the DNS name translation service and the service discovery service basically only share the DNS API and the rest of the machinery is completely different – most due to the fact that DNS-SD is based on something called Multicast DNS, or mDNS which is the basis for many other runtime service discovery mechanisms. However, any Central registry, regardless of whether it’s federated or not, offers a prime target for attack to disable any dynamic configuration or moving target defense. Plus it offers a source of data for enemy surveillance of your operational networks. The Distributed Pub/Sub probe based model is much more appealing to the kind of discovery solution we’re looking for. However, all of the existing pub/sub probe based technologies and standards have some critical limitations such as the fact that they are ”link local” and not wide-area or ad-hoc mechanisms. – not to mention that they are completely unsecured.
- Way back in the day, when we were all under the spell of “SOA” from the software vendor community, the DoD and the IC thought that run-time service discovery directly equaled UDDI. We know now that the “giant registry in the sky” simply won’t work. So, at DI2E we looked and analyzed the existing run-time service discovery mechanism. It has to operate in an wide-area and ad-hoc networking environment. Discovery probes will need to traverse network boundaries and find services that are well outside of the local network. This is critical as ad hoc mobile networks dynamically form in a moving target network. It has to participate with other service discovery mechanisms It’s clear that many C2ISR systems and organizations will introduce a myriad of local “service discovery” technologies – there are just so many other technologies that systems will likely use. Any ubiquitous technology has to provide a simple “lingua franca” that can bridge disparate discovery technologies. It has to be able to send probes on a number of different transport mechanisms – like multicast or MQTT - simultaneously When we say pub/sub mechanism, we mean exactly that. For example, we could use multicast, but we might want to use JMS, or MQTT or some other domain specific pub/sub mechanism. The existing pub/sub probe based discovery mechanisms all utilize IP multicasting as the pub/sub mechanism. With the existing protocols (such as WS-Discovery, SSDP, Multicast DNS, AllJoyn, etc) the scope of the multicast transport is limited to the link local network – meaning that we couldn’t send out probes to long range targets on the wide-area network, at least not without creating specific multicast gateways (which kinda defeats the purpose). Further, the target requirement needs to allow discovery clients to use more than one pub/sub mechanism It has to be able to operate on a number of “private” discovery channels All of the other pub/sub probe based discovery technologies one have 1 channel. It’s not that sophisticated. We needed to be able to operate discovery using the same mechanism on multiple channels potentially with different transports (such as multicast or MQTT). It has to be easily integrated into already deployed systems. These last two are critical. Any service discovery technology has to be easily integrated and configured with existing battlefield technology. What we don’t want to do in put an accreditation burden on any existing systems in order to participate in the discovery ecosystem. Violating this requirement might mean that it would be at least 18 months before any C2ISR applications could use a ubiquitous service discovery technology. After reviewing all of the existing technology we realized that we couldn't use any of the existing standards or technology.
- We ended up designing and building a new protocol and architecture to handle the needs of the DoD and IC battlefield C2ISR applications. This DI2E Runtime Service discovery technology is called Argo – which is the “marketing name” for the technology. And it’s an open source project under Github released under the MIT license. Releasing it as open source was strategic. It’s very accessible and we’re looking to get wide adoption for the technology. Unfortunately I don’t have the time provide and in depth technical look at the protocol but I do want to highlight a few things. The fundamental idea of service discovery is to connect a client with some service. To do that the client needs the IP address of the services – once the client is configured (and assuming they have all the security credentials the services require) then a connection can be made. Argo provides the infrastructure to discovery that information - and satisfy the requirements I listed in the previous slide. The Argo Responder is the heart of the architecture. It is analogous to other “responders” found in other discovery technology such as Bonjour – you have a Bonjour multicast DNS responder on your phone right now that advertises services. It’s just a daemon running on the your phone, and Argo is the same thing – the Argo responder is a daemon that run on some host in your service ecosystem. You can have as many of them as you like. However all of these other technologies are limited as to where the get their list of services they can respond with. Argo uses a “plug-in” architecture to solve the problem of adapting to multiple service address data source. An responder could be configured with as many plugins as you like however the above example has plugins for a Consul server, a UDDI service and a local configuration file. Also, both clients and the Argo Responder can use different transports to send probes. Out of the box with the open source release, there are plugins for multicast, Amazon SNS and MQTT. Clients and responders can use as many transports as they like. These are very useful for creating those “private discovery channels” discussed in the last slide. When a client sends out a probe, that probe will be picked up by listening responders. If that responder has services that the probe has specified, then the responder will send the service records back to the client using a HTTPS REST call to an address specified by the client. This makes eavesdropping or Man in the Middle attacks on the protocol very difficult. I’d be more than happy to answer any questions about this after the talk.
- The DI2E is the Department of Defense’s (DoD) enterprise architecture component for the Intelligence Mission Area. As such it is part of the DoD Joint Information Environment and must federate with the other capability architectures across the DoD. Thus DI2E acts as a bridge between the DoD Joint Information Environment (JIE) and IC Information Technology Enterprise (ICITE).