1. Computational Resiliency Steve J. Chapin, Susan Older Center for Systems Assurance Syracuse University Gregg Irvin Mobium Enterprises 24 July 2001Not for Public Release

2. Computational Resiliency – CSA Recap: What is Computational Resiliency? The ability to sustain application operation and dynamically restore the level of assurance during an attack. Application-centric self defense, built on replication, migration, functionality mutation, and camouflage.

3. Computational Resiliency Mission Critical Application Attack Degraded Application sufficiently Improved by Resiliency to perform Mission Critical Function Techniques applied to correct situation Computational Resiliency Result of Attack Degraded Application trying to perform Mission Critical Function

4. Not for Public Release Computational Resiliency – CSA Multi-Faceted Approach  Theoretical framework  reason about conformance to policy  Computational resiliency library  dynamic application management  System software support  scheduling/policy frameworks

5. Not for Public Release Computational Resiliency – CSA Computational Resiliency Library  Dynamic multithreading  Migration  Replication  Camouflage  Functionality reconfiguration  Policy-based management

6. Example of CRLib “Safe Zone” OASIS protection “The Wild” limited protection

7. The Benign State Dudley’s job (low priority) Bullwinkle’s jobRocky’s job

8. The Attacks Snidely attacks: blocked at firewall Dudley does nothing.

9. The Attacks Natasha attacks Rocky; caught by IDS.

10. The Attacks Rocky’s job migrates back into safe zone; Dudley must give up resources.

11. The Attacks Boris attacks Bullwinkle’s job. Some attacks succeed.

12. The Attacks Bullwinkle’s job employs camouflage, decoys, and migration.

13. Groups and Replication Group Processor  One group per computational task  User selects replication level, other policies  Group mapped across processors  Periodic liveness checks

14. Not for Public Release Computational Resiliency – CSA Theory Framework: Goals  Understand the interplay among core aspects of CRLib  Groups, locations, resources, schedules, …  Reason about effects of configuration and policy choices  Reason about applications’ conformance to desired behavior

15. Not for Public Release Computational Resiliency – CSA Framework Basics  Build on existing mobile calculi   -Calculus, Mobile Ambients, Join-Calculus  Capture essential features of CRLib  Replication  Migration  Reconfiguration  Camouflage

16. Not for Public Release Computational Resiliency – CSA A  -Calculus Primer  Collection of names  Represent information: values, communication links (channels), code  Have scope  Message-based communication receipt of a value on x transmission of y along x  Information mobility: information can be passed beyond original scope

17. Not for Public Release Computational Resiliency – CSA Finding a Service Provider Client wants to find a service provider: 1.Query the Service Directory, include a SASE. 2.Wait for response. 3.Upon receipt, submit request.

18. Not for Public Release Computational Resiliency – CSA Handling Service Requests  Service Directory repeatedly responds to queries, arbitrarily choosing provider.  Service providers wait for requests.

19. Not for Public Release Computational Resiliency – CSA b c a query

20. Not for Public Release Computational Resiliency – CSA b c a addr a b c

21. Not for Public Release Computational Resiliency – CSA b c a b

22. Not for Public Release Computational Resiliency – CSA b c a

23. Not for Public Release Computational Resiliency – CSA Initial Questions  What are the primary entities, as well as the relationships among them?  Groups, locations, failures  External events: DEFCON changes  Scheduling policies  Application policies  What is the most appropriate way to integrate those components?  And at what abstraction level?

24. Not for Public Release Computational Resiliency – CSA In Progress: Two Calculi  Higher-level calculus that incorporates the CRLib API  Captures groups, policies, etc.  Lower-level calculus that provides semantics for higher-level calculus  Captures abstract implementation details. Soundness of the translation will provide validation.

25. Not for Public Release Computational Resiliency – CSA A Thought Experiment Suppose there are two tasks, A and B, working in parallel:  A’s replication level: 4  B’s replication level: 2  Three processors: P1 P2 P3 Resulting behavior (modulo robustness) should be similar to system with single copies of A and B.

26. Not for Public Release Computational Resiliency – CSA Open Questions  How do we define “similar”, much less prove it?  Correctness  Performance  Robustness  What are sufficiently high-level yet informative performance measures?  How to model camouflage?

27. Not for Public Release Computational Resiliency – CSA Back to CRLib: Status  Multiple platforms  Windows NT/2000, Linux, SGI IRIX, Solaris  Heterogeneous resource management methods  Load-balancing across heterogeneous networks  Performance improvement by factor of 3  Demo this evening

28. Not for Public Release Computational Resiliency – CSA In Progress  Adding support for Byzantine failures  User-level option for authenticated messages  Based on Lamport-Shostak-Pease algorithms  Greater resiliency needed for nonauthenticated messages  Evaluating cost of replication  Compare to standard checkpointing

29. Not for Public Release Computational Resiliency – CSA Next Steps for Project  Tool for user policy expression  Choices for replication/recovery methods, agreement protocols, message-passing schemes  State-dependent policy specified via “chinese menu” approach  Scheduling framework  Schedulers that understand CR policies, resulting resource demands, user/process priorities  Build on previous MESSIAHS and Legion work  Finalize core CR calculi; turn to analysis techniques

30. Not for Public Release Computational Resiliency – CSA Open Issues  Cost/benefit analysis of CR  How much protection do we provide if the attacker knows what we’re trying to do?  How much is performance affected by message load, active replication, etc. ?  Potential integration with other OASIS projects