1. Introduction to WOLFASI: Workshop on Logical Foundations of an Adaptive Security Infrastructure Leo Marcus The Aerospace Corporation Los Angeles July 13, 2004

2. Goals of Talk Introduce Adaptive Security Infrastructure Discuss assurance and formalization State some tentative definitions and theorems

3. Need for Adaptive Security Static security architectures cannot cope with rapidly changing security environment, including: –physical parameters –threats –attacks –policies –mission goals Systems designed for extended many- decade life –Cannot predict and handle future threats by current built-in non-flexible mechanisms

4. Goal for Logical Foundations of an ASI Understand how such a system works!

5. Need for Assurance Systems are being specified, designed, and built without a good method for architecting system- wide adaptive security mechanisms, and without a good method for gaining confidence that the mechanisms to be employed will deliver what, and only what, is needed. Without assurance, the cure may be worse than the disease.

6. Need for Formalization of Adaptive Security Assurance that proposed adaptive security mechanisms will perform as hoped (specified) Currently: rather haphazard collection of devices, poorly specified, with some testing Near future: rigorous specification and analysis Distant future: formal specification and proof. To begin: formalize significant aspects of proposed real system

7. Possibility of Proof How can we prove anything about such a complicated system, when we can barely prove the most rudimentary security properties of the most rudimentary devices? Answer: hierarchy! –Assuming the building blocks (protocols, algorithms, devices, interfaces) work as advertised, how do they function together? Define the problems that components must solve

8. Adaptive Security Infrastructure (ASI) Unified approach conceptually composed of –Sensor, –Analysis, and –Response capabilities To coordinate –Detection of security-relevant input –Security policy –User input –Analysis –Response

9. Adaptive Security Infrastructure Environmental Sensors Virus Defs Threat Warnings Analyzer and Policy Engine User IDS outputs Responder (Rest of the) System Detector User

10. Adaptive Security Infrastructure Environmental Sensors Virus Defs Threat Warnings Analyzer and Policy Engine User IDS outputs Responder (Rest of the) System Detector Us er

11. Adaptive Security Infrastructure Environmental Sensors Virus Defs Threat Warnings Analyzer and Policy Engine User IDS outputs Responder (Rest of the) System Detector Us er

12. Adaptive Security Infrastructure Environmental Sensors Virus Defs Threat Warnings Analyzer and Policy Engine User IDS outputs Responder ( Rest of the ) System Detector Us er

13. Potential Responses I. Defensive: intended effect internal allocation of resources (e.g. power; turning devices on or off) routing (including or excluding nodes) access rights crypto algorithms, keys, protocols sensor networks auditing authentication intrusion detection system settings (altering the false positive/negative ratio) patches device or data destruction installation of new hardware or software

14. Potential Responses II. Offensive: intended effect external Electronic –bombs, etc. Physical –bombs, etc.

15. State of the Art Much work on detailed aspects of specific components –Intrusion detection –Sensor networks –Architectures –Security policies Much less work on unifying principles

16. Principles for Formalization Mathematical logical framework Abstract from realistic scenarios Not directly concerned with –Usability –Current technology Long term goal: uniform semantics to allow rigorous specifications and verifications of –Architectures –Properties –Capabilities Should yield coherent and interesting research directions for component areas

17. Basic Assumptions ASI exists in a temporal and spatial world Policy, detection, analysis, and response all have temporal and spatial aspects that must be first class citizens in the formalism Otherwise, significant and interesting real issues will not be modeled Need common semantics connecting policy, detection, analysis, response

18. Research Issues 1. How should the semantics of a dynamic security policy be specified? 2. How should we take into account the global- local nature of all components of an ASI? 3. How should we specify the "security-relevant resources" available so that at any time the analyzer can choose an appropriate response? 4. How should we unify the temporal-spatial reasoning aspects? 5. What are the decidability or complexity issues in such a system? 6. What is the role of "approximate security"?

19. Research Issues: Spatial Hierarchical architecture Central (local) and distributed (global) detection, analysis, and response coordination Smooth transition between hierarchies Testability of policy satisfaction Enforceability of response

20. Research Issues: Temporal Duration of response Synchronization Relative speeds of changing environment, detection, analysis, communication, response Incorporation of time in policy Acknowledgments, success reports

21. Three examples Dynamic security policy –Specification language –Analysis –Testing for adherence or consistency Pervasive hierarchy assumption –All aspects of ASI are hierarchical Response specification –As a dynamically changing resource/scheduling problem –Language and semantics (effect, efficiency, etc.)

22. Goals for Specification of Adaptive Security Policy Facilitate analysis: Test/prove adherence or consistency Provide an umbrella guide for deciding if future events, actions, or responses are to be permitted or tolerated Automate reasoning about policy change within the context of larger policy or policy hierarchy

23. The Pervasive Hierarchy Assumption Arbitrary architectural structures (patterns of connectivity, e.g. networks) can exist within the system and within the ASI These structures may be dynamically changing Any aspect of specification, detection, analysis, or response can be considered in a version relativized to any structure

24. Defining Local Policy Let H be a hierarchy description, A an ASI specification (not individual instantiation), and P a policy. 1.P is local with respect to H in A if the satisfaction of P in A is dependent only on the satisfaction of some other (“test”) policy in all subsystems satisfying H. 2.Play with quantifiers 1.For all instantiations of A there is a test policy for P such that… 2.There is a test policy for P such that for all instantiations of A… 3.….in some subsystems satisfying H

25. Specification, Derivation, and Verification of Response A response is a distributed program/algorithm to be run concurrently with ongoing ASI operation Specify and evaluate responsive resources –Including communication channels, if needed –Current strength and location Plan appropriate action in time and space Coordinate response with analysis –Temporary and local fixes while long-term global solution is researched

26. Other Topics Approximate security –Specify achievable security goals Statistical properties Game-theoretic view –Between environment and ASI –Restrict the environment and design the ASI so the adversary does not have a winning strategy

27. Future Theorem For any system S implementing the specification S For any ASI A implementing the specification A For any dynamic security policy P of type P For any environment E satisfying conditions E S+A satisfies P in E

28. Problem Given E, P, and S, find A, as in previous slide As E gets more “realistic”, P has to get weaker in order for there to be any hope of finding an appropriate A. This weakening can be –Temporal (allow for longer lapse) –More approximate (allow for less secure)