1 / 25

An open security defense architecture for open collaborative cyber infrastructures

An open security defense architecture for open collaborative cyber infrastructures. Xinming (Simon) Ou Kansas State University. The Great Plains Network Annual Meeting 2009 Kansas City, Missouri. Challenges to securing cyber infrastructures. Cyber warfare is asymmetric

jonco
Télécharger la présentation

An open security defense architecture for open collaborative cyber infrastructures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An open security defense architecture for open collaborative cyber infrastructures Xinming (Simon) Ou Kansas State University The Great Plains Network Annual Meeting 2009 Kansas City, Missouri

  2. Challenges to securing cyber infrastructures • Cyber warfare is asymmetric • Attack only needs to break a few points • Defense has to be comprehensive • Attackers have an upper hand in automation • Many automated exploit tools • Not so many good defense tools • Openness of academic cyber infrastructures • Unrealistic to have draconic control on access

  3. Multi-step Attacks Internet Firewall 1 buffer overrun Demilitarized zone (DMZ) webServer Firewall 2 NFS shell sharedBinary Trojan horse workStation Corporation webPages fileServer

  4. Reasoning System Apache 1.3.4 bug! Solution Linux security behavior; Windows security behavior; Common attack techniques Information about users potential attack paths Security expert System admin Network configuration Host configuration CERT advisory

  5. Suggested configuration change to harden security High-level security knowledge Automated analyzer baseline security status Security scanning and monitoring Information collection OVAL/Nessus Repository CVSS NVD Baseline security knowledge Broader Security Community Enterprise Network

  6. MulVAL Could root be compromised on any of the machines? User information Ou, Govindavajhala, and Appel. Usenix Security 2005 Interaction Rules from Security Experts Vulnerability Information (e.g. NIST NVD) Analyzer Answers Vulnerability definition (e.g. OVAL, Nessus Scripting Language) MulVAL Scanner MulVAL Scanner Network reachability information Network Analyzer

  7. Interaction Rules Oops! execCode(attacker, webServer, apache). execCode(Attacker, Host, PrivilegeLevel) :- vulExists(Host, Program, remote, privilegeEscalation), serviceRunning(Host, Program, Protocol, Port, PrivilegeLevel), networkAccess(Attacker, Host, Protocol, Port). internet networkAccess(attacker, webServer, tcp, 80). Derived Firewall 1 serviceRunning(webServer, httpd, tcp, 80, apache). From MulVAL Scanner webServer dmz vulExists(webServer, httpd, remote, privilegeEscalation). From MulVAL Scanner & OVAL, NVD

  8. MulVAL reasoning engine Proofs of assertions MulVAL Attack-Graph Toolkit Ou, Boyer, and McQueen. ACM CCS 2006 Security advisories Interaction rules Graph Builder Network configuration Datalog representation Logical attack graph Machine configuration Joint work with Idaho National Laboratory

  9. Test on a Real Network • Used MulVAL to check the configuration of four Linux servers • Reported a potential two-stage attack path due to multiple vulnerabilities on a server. • Three local kernel vulnerabilities • One buffer overflow bug in libpng • Local users are trusted • Web browser links libpng

  10. The next challenge: Situation Awareness system administrator Abnormally high traffic TrendMicro server communicating with known BotNet controllers Seemingly malicious code modules Found open IRC sockets with other TrendMicro servers Network Monitoring Tools memory dump netflow dump These TrendMicro Servers are certainly compromised!

  11. High-confidence Conclusions with Evidence Internal model ReasoningEngine Targeting subsequent observations Mapping observations to their semantics IDS alerts, netflow dump, syslog, server log … Observations

  12. High-confidence Conclusions with Evidence Internal model ReasoningEngine Mapping observations to their semantics Targeting subsequent observations IDS alerts, netflow dump, syslog, server log … Observations

  13. Observation Correspondence Mapping observations to Internal condition. what you want to know what you can see p obs(anomalyHighTraffic) int(attackerNetActivity) l obs(netflowBlackListFilter(H, BlackListedIP)) int(compromised(H)) l obs(memoryDumpMaliciousCode(H)) int(compromised(H)) l obs(memoryDumpIRCSocket(H1,H2)) int(exchangeCtlMessage(H1,H2))

  14. High-confidence Conclusions with Evidence Internal model ReasoningEngine Targeting subsequent observations Mapping observations to their semantics IDS alerts, netflow dump, syslog, server log … Observations

  15. Internal Model Logical relation among internal conditions. m1 m2 Condition2 Condition1 “leads to” relation i.e. Condition1 may cause Condition2 p c int(compromised(H1)) int(probeOtherMachine(H1,H2)) p c int(compromised(H1)) int(sendExploit(H1,H2)) p l int(sendExploit(H1,H2)) int(compromised(H2)) c p int(compromised(H1)), int(exchangeCtlMessage(H1,H2)) int(compromised(H2))

  16. Proof Strengthening f is certainly true proof strengthening f is likely true f is likely true Observations: O1 O2 O3

  17. The SnIPS system Done only once Observation Correspondence Internal Model Snort Rule Repository User query, e.g. which machines are “certainly” compromised? Reasoning Engine High-confidence answers with evidence (summarized tuples) pre-processing Snort alerts

  18. Automate Model Building for Snort Internal predicate mapped from “classtype” alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC guestbook.pl access”;uricontent:"/guestbook.pl”; classtype:attempted-recon; sid:1140;) obsMap(obsRuleId_3615, obs(snort(’1:1140’, FromHost, ToHost, _Time)), int(probeOtherMachine(FromHost, ToHost)), ?).

  19. Automate Model Building for Snort • Hints from natural-language description of Snort rules Impact:Information gathering and system integrity compromise. Possible unauthorized administrative access to the server. Possible execution of arbitrary code of the attackers choosing in some cases. Ease of Attack:Exploits exists obsMap(obsRuleId_3615, obs(snort(’1:1140’, FromHost, ToHost, _Time)), int(probeOtherMachine(FromHost, ToHost)), ). ? l obsMap(obsRuleId_3614, obs(snort(’1:1140’, FromHost, ToHost, _Time)), int(compromised(ToHost)), p)

  20. Coverage • Snort has about 9000 rules. • This is just a base-line and needs to be fine-tuned. • Would make more sense for the rule writer to define the observation correspondence relation when writing a rule.

  21. Experiment on Treasure Hunt data • Data collected during a graduate-level course exercise • Data set contains multi-stage attacks as in real world scenario • A large variety of monitoring data

  22. Some Results 192.168.10.90 was certainly compromised! | ?- show_trace(int(compromised(H), c)). int(compromised(’192.168.10.90’),c) strengthenedPf int(compromised(’192.168.10.90’),l) intRule_1 int(probeOtherMachine(’192.168.10.90’,’192.168.70.49’),l) obsRulePre_1 obs(snort(’122:1’,’192.168.10.90’,’192.168.70.49’,_h272)) int(compromised(’192.168.10.90’),l) intRule_3 int(sendExploit(’128.111.49.46’,’192.168.10.90’),c) obsRuleId_3749 obs(snort(’1:1807’,’128.111.49.46’,’192.168.10.90’,_h336)) A probe was sent from 192.168.10.90 An exploit was sent to 192.168.10.90

  23. Summary • Open knowledge sharing and automated knowledge reuse is key in effective cyber defense • Advantages of logic-based techniques • Publishing and incorporation of knowledge/information through well-understood logical semantics • Efficient and sound analysis by leveraging the reasoning power of well-developed logic-deduction systems

  24. Who We Are Argus: Cyber Security Research Group at Kansas State University http://people.cis.ksu.edu/~xou/argus/ Contact me: Simon Ou xou@ksu.edu

  25. Thank You! Questions?

More Related