1. RSRS Architecture Study Doug Blough and Calton Pu CERCS/Georgia Tech

2. Study Outline Part 1: Architectural Analysis and SRS Evaluation 1.Develop high-level architecture concept 2.Study existing projects and evaluate how they fit with architecture 3.Evaluate program strengths/weaknesses vis-a-vis architecture Part 2: Moving Forward 4.Develop more concrete architecture 5.Apply architecture to system examples and an application scenario

3. Part 1: Architectural Analysis and Evaluation of SRS Projects

4. Biologically-Inspired Diversity Tools (BID) Cognitive Immunity and Regeneration Environment Reasoning About Insider Threats Applications Granular, Scalable, Redundant Data and Communication (GSR) Monitor Learning Actuator GS R BID GS R Attacks RSRS Architecture

5. RSRS Architecture applied to Cognitive Area Biologically-Inspired Diversity Tools (BID) Cognitive Immunity and Regeneration Environment Applications Granular, Scalable, Redundant Data and Communications (GSR) Monitor Learning Actuator Attacks

6. Comparison of Cognitive Projects variabl e observ. data repair cons traint s AWDRAT differe ncer restor ation model- based Model-based Executive obse rve react comp are Cortex State estimat e Mission- aware respons e statistica l learning Learn/Repair System models Learnin g model Taster DBs Master DB query

7. Summary of Cognitive Projects 3 of 4 projects employ model-based approaches (Model-Based, AWDRAT, Cortex) Model-based approaches are well-suited for embedded systems, e.g. autonomous vehicles, or single applications, e.g. SQL Cognitive approaches still need to be developed and proven for large complex systems Learn/Repair is developing self-regenerative techniques that can be applied inside a program

8. RSRS Architecture applied to Diversity Area Biologically-Inspired Diversity Tools Cognitive Immunity and Self-Healing Attack- resistant variants Attack description Create Variants Test Variants Feedback Monitoring: After the variants are created, their resistance to attacks is evaluated Learning-Based Diagnosis: The winning variants are stored in a KED, while the losing variants are marked as such or discarded Regenerative Actuation: The winning variants are used to increase system robustness by replacing vulnerable components, possibly by a Cognitive component or system

9. Comparison of Diversity Projects Genesis creates variants at multiple levels: compilation, linking, loading, run-time Cognitive Immunity and Self-Healing Attack- resistant variants Attack description Create Variants Test Variants Dawson creates variants from binary for Windows platforms Cognitive Immunity and Self-Healing Attack- resistant variants Attack description Create Variants Test Variants

10. Summary of Diversity Projects Genesis generates program variants from source using techniques such as Calling Sequence Diversity and Instruction Set Randomization DAWSON generates program variants from binary for the Windows environment using techniques such as variable location (stack/heap) randomization and address (DLL/IAT) randomization

11. RSRS Architecture applied to Redundancy Area Sensors, Monitors & Sources Biologically- Inspired Diversity Tools Reasoning About Insider Threats Applications Cognitive Immunity and Self-Healing GSR Sensors, Monitors & Sources Event Dissemination and Processing QuickSilver/Cayuga GSR GSR Communications QuickSilver/Ricochet GSR Object/Data Mgmt SAIIA, IITSR

12. Summary of Redundancy Area Steward (SAIIA) provides intrusion-tolerant objects over wide-area networks IITSR focuses on Byzantine-tolerant data/object replication QuickSilver considers scalable and reliable mechanisms, e.g. group multicast and event dissemination Projects are primarily focused on performance (as called for in BAA) but do not investigate internal self-regeneration or reconfiguration (static fault tolerance is provided, in general) Opportunities exist to extend existing projects to provide self- regenerative redundant components, which could provide building blocks for larger self-regenerative systems, e.g. a self-regenerative replicated data store or self-regenerative objects Scalable event dissemination and processing is critical for RSRS architecture

13. RSRS Architecture applied to Insider Area Reasoning About Insider Threats Monitor activitie s Control operato r scope Learn/ refine model Cognitive Immunity and Self-Healing

14. Comparison of Insider Projects PMOP Cognitive Immunity and Self-Healing Send harmful action for remediation Potential action behavior monitor operating model assess harm/intent Normal/error Danger/ Malicious High Dimensional Search/Monitoring Cognitive Immunity and Self-Healing Restrict privileges Refine Model sensor net HD search engine reposit ory Respons e engine

15. Summary of Insider Area PMOP uses a model-based approach HDSM uses a model-based approach to represent insider knowledge acquisition and high-dimensional search techniques for identifying suspicious activity from large sensor network output High-dimensional search is a candidate for learning-based diagnosis for large complex systems

16. Summary of Findings All SRS program areas fit well within RSRS architecture concept More work is needed on cognitive approaches for large complex systems Examples of critical technologies for RSRS: scalable and reliable event dissemination/processing, high- dimensional search, biodiversity generators Opportunities exist to develop self-regenerative building-block components from some of the SRS technologies

17. Part 2: Moving Forward

18. RSRS Structural Architecture for Complex System Event Disseminator Cognitive/ Reflective System Manager M L A Control Plane System Status Info SRS Commands M Application Group Software Components D Detectors, e.g. IDS and Failure Detectors Network of Virtual Sensors A M A Multicas t LL M A L M A L DD Self-regenerative Data Store (optional) High- dimension al search

19. RSRS Structural Architecture for System of Systems Global Event Disseminator Centralized Event Analyzer (optional) M L A

20. Military Data/Operations/Command Center

21. DCGS Global C4ISR Enterprise

22. Time-Critical Targeting (TCT) Executed within Air Operations Centers Time-sensitive target with limited window of opportunity Tasks: find, fix, track, target, engage, and assess Applications: intelligence preparation, terrain analysis, target development/nomination, weapon-target pairing

23. RSRS Scenario with TCT and DCGS 1.TCT tasks are underway when a non-critical display application reports a data structure corruption event; the data structure is automatically repaired and the application continues; a few minutes later, another corruption is reported and repaired, although the application is forced to display at a lower resolution 2.The RSRS cognitive/reflective component queries DCGS event streams for recent reports and notes that a larger-than-expected number of workstation crashes have occurred over the last 15 minute period 3.The cognitive/reflective component then receives a report of errors from a replica, which is running a critical TCT task and is hosted on the same workstation as the display application

24. RSRS Scenario, continued 4.A short time later, the workstation hosting the replica and display application crashes 5.Critical applications use reconfigurable objects, so the system automatically starts a new replica on another workstation 6.The RSRS high-dimensional search module is activated to analyze recent log and other event data within the Operations Center 7.The search reveals unusual activity on the Operations Center gateway and a connection from the gateway to the crashed machine via a rarely-used port shortly before data corruption began

25. RSRS Scenario, continued 7.The cognitive/reflective component also notes that the application using the port is on the list of applications that interact with the display application 8.The RSRS actuator takes the following actions: It disseminates its analysis results (suspected application and port) to all other data/command/operations centers via DCGS It temporarily disconnects the Operations Center from DCGS and shuts down the gateway It reboots the failed workstation and disables the suspected application and port on all workstations

26. RSRS Scenario, continued 9.Another data center, after seeing the Operations Center report, is able to capture and analyze the attack 10.The attack info is then used by a bio-diversity generator to create a resistant variant of the targeted application, which it distributes to other centers via DCGS 11. Once the TCT operation is completed, RSRS reconnects the Operations Center to DCGS, receives and installs the new variant on all machines, and reopens the closed ports

27. Use of SRS Technologies in RSRS Learn/Repair: self-regeneration within software components, monitoring and event generation Cognitive model-based approaches: self- regeneration within embedded systems, e.g. UAVs, or single applications Cortex: self-regenerating databases Dawson, Genesis: generation of resistant software variants

28. Use of SRS Technologies in RSRS HDSM: Analysis of event streams containing diverse event types and widely varying granularities and time scales SAIIA: object replication, reconfigurable and/or self-regenerating objects? IITSR: data replication, reconfigurable and/or self-regenerating data stores? QuickSilver: robust communication within the data center; event dissemination and filtering within the data center and across enterprise

29. RSRS Architecture - Next Steps Integrate SRS technologies Architect cognitive reflective component Study how existing systems can be integrated with RSRS architecture, e.g. using wrappers and external monitors Apply RSRS to complex system and demonstrate successful self-regeneration in scenario like TCT or alternative