Decision Support Systems and the Cyber Fighter Associate Charles - PowerPoint PPT Presentation

Decision Support Systems and the Cyber Fighter Associate Charles Huber Fall 2015

Decision Support Systems • Intelligent systems that help make difficult decisions ‣ Suggest actions to a user • Composed of three interdependent systems ‣ Database Management System • Where the information is kept ‣ Model-base Management System • Where the information is fed • Makes decisions based on model rules and links ‣ Dialog Generation Management System • Output to the user Page

How It’s Made • These systems usually have many sensors that gather data from the environment • Sensor data is stored in the DBMS and filtered through the MBMS • Often MBMS takes the form of a graph • MBMS passes its decision to DGMS to be displayed to user • User very often will feed more information to sensors and begin the cycle again Page

Circular Thinking • The generally accepted decision-making process in the military is the OODA loop ‣ Observe OODA$Loop$ ‣ Orient Observes'and'Extracts' Uses'knowledge'bases'to' ‣ Decide data'from'world'and' reason'about'informa8on' converts'to'world'states' with'output'of'intelligent' Observe Orient ‣ Act decisions'and'ac8ons' Act Decide Output'being'intelligent' Searches'and'monitors'for' decisions'and'ac8ons' significant'events'in'data' and'responds'to'events' Page

OODA • Observe – Gathering of data about the environment from sensors • Orient – Filter data from the sensors into a form that is usable for decision making ‣ What is the meaning of the data? • Decide – Determine what options are available with the given orientation. ‣ Create plans and goals given the state of the environment • Act – Do something that alters the environment ‣ In DSS this usually takes the form of suggestions to a user Page

Now What? • How do you implement such a system? ‣ Cognitive engines • Cognitive engines are systems designed to think • Given the right set of rules a cognitive engine can be programmed to think a certain way. • The Solomon Engine by Veloxiti Inc. uses two different graphs to “think” ‣ Graphs basically define a rule set for how data is filtered and how plans and goals are created. Page

Solomon the Wise • The Solomon Engine uses two graphs to create its thinking structure ‣ Conveniently named the Observe-Orient graph (OOG) and the Decide-Act graph (DAG) ‣ Uses links to pass information between nodes in the same graph ‣ Uses monitors to pass information between graphs most of the time (more later) ‣ Monitors and links have virtually the same functionality but monitors are more powerful • The Solomon Engine provides its own output provider Page

What’s Missing? • The OOG and the DAG make up the MBMS • The output provider makes up the DGMS • The designer must implement his/her own DBMS ‣ This way DB can be structured to how the MB wants inputs. ‣ Database can be a completely separate entity from the Solomon Engine entirely Page

A Few More Things • The Solomon Engine uses a Domain Specific Language (DSL) for its coding ‣ Language has strong ties to Java (and JavaScript really) • Nodes in the OOG and DAG take the form of *.kb files ‣ *.kb files are then compiled into Java classes • Xbase identifiers used in front of variables inside nodes ‣ “keys” are values that must be set for a node to be created ‣ “attributes” are just normal variables • Can be Null Page

Links and Monitors • Connections between nodes in graphs ‣ Links connect nodes in same graph ‣ Monitors connect nodes in different graphs or connect plans to goals in the same graph • Contain some basic methods ‣ Links use compute setKeys, compute setAttributes, constraints ‣ Monitors use same update methods except constraint functions are different • Constraints ‣ Links use update, childRevoke, linkRevoke • Monitors use fire instead of update Page

The OOG • Consists of data structure called beliefs • Used to filter data • Each belief must have at least one key • Beliefs are connected using links ‣ Multiple parent beliefs can be linked to the same child belief Page

The OOG Page

The DAG • Consists of data structures called Plans and Goals • Follows two basic rules ‣ “In order to be satisfied, all of a plan’s child goals must be satisfied” ‣ “Any of a goal’s child plans should be sufficient for satisfying the goal” • The DAG can end up rather large due to these two rules • Graph looks like a decision tree with Plan nodes as the leaves ‣ Must have a root Plan. This plan must have at least one key and must be made when the engine is instantiated in code ‣ Actions live on Plan nodes Page

The DAG Page

On To The Good Stu ff • Has the Solomon Engine been used successfully before? ‣ Yes! The Pilot’s Associate and more recently the Warfighter Associate • The Warfighter Associate draws information from a variety of sensors ‣ Voice communication, text messages, weather sensors, UAV’s • Outputs suggestions for a variety of scenarios ‣ IEDs, injured soldiers, enemy troop movements, etc. Page

The Cyber Domain • Idea is to bring OODA loop into the cyber domain • The Cyber Fighter Associate (CyFiA) will eventually be a DSS that aids network admin and analysts in thwarting cyber attacks • Currently CyFiA runs on a simulation using the network simulator NS-3 ‣ Makes network agility decisions to stop and eradicate malware from a network ‣ Turn based simulation Page

Agility Maneuvers • Four maneuvers ‣ Patching – Distribute and implement a patch from some other node ‣ Healing – Software patches itself ‣ Quarantining – Functionality that is affected by malware becomes unusable ‣ IP Blocking – Node connections are removed to stop malware from spreading Page

Decisions Decisions • How do we determine which maneuver to pick? • CyFiA is programmed to have priorities ‣ Nodes have different attributes such as Security, Health, Capability, Batter Life, etc. ‣ Choose an attribute to prioritize and do that calculation first • For our simulation sake we focused primarily on maximizing node Health and Capability while minimizing Energy Costs (Battery Drain) • Order matters ‣ CyFiA needs to know which calculation to prioritize Page

Operation Priority • In the military, there may be an overall operation priority ‣ Defend Network, Prioritize Critical Nodes, All Services Available, etc. • CyFiA allows for two operational priorities ‣ Critical Nodes First (CNF) or Lowest Health First (LHF) • The operational priority cannot be changed • Calculation priorities can be changed Page

Experiments • Used a small tactical network of 10 nodes ‣ All nodes exactly the same • Chose a two nodes – one infected, one immune (has the patch) • NS-3 would send information to CyFiA, CyFiA would respond with an agility maneuver • Continues until all nodes have been patched Page

How’d We Do? • The point of a DSS is to make informed decisions faster ‣ Try to make CyFiA so its decisions are as good as the optimal solution • Optimal Solution: ‣ Highest average network health, security, and capability • So what are the values for optimal in a case like this? ‣ Assign values to health, capability, and security (0, 25, 50, 75, 100) ‣ We did an exhaustive search using NS-3 to determine the best values we could obtain by patching ‣ 400+ cases Page

How’d We Do? • Test CyFiA in 4 scenarios ‣ CNF with priority of health ‣ CNF with priority of capability ‣ LHF with priority of health ‣ LHF with priority of capability • CyFiA managed to patch the network optimally for all of our test cases • Good Right? ‣ Maybe. Page

Problems/Future Research • Our simulation is only one simple scenario ‣ Malware is not the only attack on a computer system or network • Battery Life does not drain quickly • Turn based system needs to go ‣ But NS-3 is so fast, so how do we find a timing balance so that it seems like someone is actually attacking the network? • How do we decide what agility maneuver to perform? ‣ Currently uses battery life to determine agility maneuver ‣ This might not always cause the best case. What if we need to plan ahead? Page

CyFiA OOG Page

CyFiA DAG Page

Simulation Network Page

Experiment Setup Page