RSRS Architecture Study

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

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

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

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

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

6. Comparison of Cognitive Projects AWDRAT Learn/Repair differencer model-based restoration variable observ. constraints data repair System models Model-based Executive Cortex query Taster DBs Learning model State estimate statistical learning Mission-aware response observe react compare Master DB

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 Create Variants Test Variants Attack-resistant variants Attack description Feedback Cognitive Immunity and Self-Healing • 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 Dawson creates variants from binary for Windows platforms Create Variants Test Variants Create Variants Test Variants Attack-resistant variants Attack-resistant variants Attack description Attack description Cognitive Immunity and Self-Healing Cognitive Immunity and Self-Healing

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

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 activities Learn/ refine model Control operator scope Cognitive Immunity and Self-Healing

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

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 Control Plane Self-regenerative Data Store (optional) Software Components SRS Commands A A A A Cognitive/ Reflective System Manager System Status Info Detectors, e.g. IDS and Failure Detectors Multicast L L L L M M M M D D D A Application Group L Network of Virtual Sensors High-dimensional search Event Disseminator M

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

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 • 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 • 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 • 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 • A short time later, the workstation hosting the replica and display application crashes • Critical applications use reconfigurable objects, so the system automatically starts a new replica on another workstation • The RSRS high-dimensional search module is activated to analyze recent log and other event data within the Operations Center • 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 • The cognitive/reflective component also notes that the application using the port is on the list of applications that interact with the display application • 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 • Another data center, after seeing the Operations Center report, is able to capture and analyze the attack • 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 • 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