® Context Aware Firewall Policies Ravi Sahita Priya Rajagopal, Pankaj Parmar Intel Corp. June 8 th 2004 IEEE Policy (Security)

Communications Technology Lab 2 Overview  Background  Motivation  Policy goals (example)  Intrusion detection->Host Host<-firewalling  Management  SAFire  Milestone conclusions

Communications Technology Lab 3 Background  Why firewall?  Defense in depth against software flaws (software complexity increasing)  Control over services accessed/exposed  Control over information flow across boundaries (platform or network)  Needed: Increased proactive response instead of reactive

Communications Technology Lab 4 Policy goals (example)  Track flow only if the session is initiated by client  By default, restrict all traffic other than allowed services control traffic  Create transient filters for the negotiated data flows  On the negotiated port, restrict access to specific allowed commands/capabilities for that service  When transferring data, block/flag suspicious content (so that it is checked) before it reaches apps  All traffic that causes invalid protocol state transitions must be blocked proactively

Communications Technology Lab 5 Advantages of host based FWs  Visibility into internal traffic – Can protect against internal attacks  Smaller number of flows, More state per flow – Decreased load on aggregation points  Enable finer access control in a mobile environment – Carry your security  Can use end-to-end protocol properties  Allow true end-to-end encryption of traffic which would otherwise be proxied by the network devices

Communications Technology Lab 6 IDS -> Host <- FW

Communications Technology Lab 7 Complex management  Infrastructure firewalls are needed  Host FWs=>number explosion, but valuable  Make security policies easier to map without sacrificing functionality  Make components tend towards autonomous behavior  Make it easier to correlate events across hosts and infrastructure

Communications Technology Lab 8 Why SAFire?  What are the sub-elements of such packet analysis  Allow building finer grain network access control policies  Rich enough to keep up with new network services/changes  Local remediation Abstraction of FW / IDS rules for a host

Communications Technology Lab 9 Capabilities identified  Packet data extraction and filtering  Flow state table management  Application layer rules  Pattern manipulation  Outsourcing policy decisions  Reuse of definitions  Dynamic rule management | HOST CONTEXT |

Communications Technology Lab 10 Sequence of steps  Express application protocol in a DFA  Map protocol states to the Generic PSM  Extract transition rules from the normalized PSM naming  Extract transition rules from the normalized PSM naming  Map to SAFire primitives (using tools)

Communications Technology Lab 11 Generic Protocol States Mapped to protocol specifics

Communications Technology Lab 12 Rule processing

Communications Technology Lab 13 Implementation

Communications Technology Lab 14 Conclusions  United model can comprehend HIPS+FWs  Language extensibility = parallel progress  Model allows security policy verification across implementations  Minimal tradeoff is processing overhead for mapping and translation  Context information on the host can be leveraged for finer access control  Initial prototype shows minimal delay from user POV

Communications Technology Lab 15 Thank you!  Questions/Comments to