HECTOR Security Intelligence Platform Copyright 2012 Justin C. Klein Keane

About Me

 Justin C. Klein Keane  Information security (and application development) for University of Pennsylvania, School of Arts & Sciences  @madirish2600  http://www.MadIrish.net

Copyright 2012 Justin C. Klein Keane

About this Presentation

 Covers internally developed SEIM and security intelligence platform (HECTOR)  Lessons learned likely apply to any such platform, open or closed source, internally or externally developed  Feedback appreciated  Designed to provide food for thought in advance of the open source availability of HECTOR Copyright 2012 Justin C. Klein Keane

Why HECTOR

 Challenge of identifying 15,000 hosts across SAS  Proactive vulnerability identification  Asset management  Vulnerability disclosure mitigation  Aggregation of intrusion detection logs  Centralize honeypot and darknet data  Development of security intelligence platform Copyright 2012 Justin C. Klein Keane

Fundamentals

 No network span ports or taps required!

 HECTOR is designed to be an augmented asset management platform  All data is tied to hosts  Each host includes contact information for users as well as technical support  HECTOR designed to allow supplementary data to be linked with hosts, from port scans to incident histories to vulnerability reports Copyright 2012 Justin C. Klein Keane

Initial Challenges

 Lots of hosts means lots of data  Once you aggregate data how do you develop meaningful (and timely reports)?

 Once issues are identified, what next?

 Remediation tracking to keep reports topical  Initial configuration and data population  Keep noise to a minimum and utility to a maximum Copyright 2012 Justin C. Klein Keane

HECTOR Building Blocks

 PHP web front end  MySQL database back end  OSSEC intrusion detection system  NMAP scanning engine  Kojoney (or Kippo) based honeypot  Iptables based darknet sensors  Assignments (internal asset inventory)  Some Perl and Python for good measure Copyright 2012 Justin C. Klein Keane

How it Works

 Scheduled lightweight NMAP port scans that save profiles and alert on changes  Querying interface to provide insight into what assets offer what ports (and services)  Database contains many different tables but ultimately based around a single host table that is tied to IP addresses (“host” defined via network accessibility) Copyright 2012 Justin C. Klein Keane

Users and Groups

 Internal, or CoSign, based auth  Users are assigned to groups of hosts  User queries and reports are restricted to hosts assigned to groups for which the user is granted access  Users are e-mailed alerts based on port profile changes for machines in groups they're assigned Copyright 2012 Justin C. Klein Keane

Scripting Support

 PHP based scripts perform scans and report in XML which is migrated to the database  Extensible design so that Nikto, Nessus, and other scanning engines can produce reports  Scripts designed to be pluggable so new scripts can easily be added based on need.

Copyright 2012 Justin C. Klein Keane

Intrusion Detection ++

 Integrate intrusion detection to support workflow:    Attacker observed (malicious IP identified) Query other hosts that might have been attacked to identify a historical pattern Query database to find other hosts with services the attacker is looking for or profiles similar to victim Copyright 2012 Justin C. Klein Keane

Darknet Reporting

 Darknet shows trends in attacker port probes  New trends can be cross referenced with reports on the machines offering services sought by attackers  Mitigation can be deployed to defend these hosts  Alternatively honeypots can be deployed to gather additional data Copyright 2012 Justin C. Klein Keane

Vulnerability Management

 Vulnerability identified in a popular service  HECTOR allows organizations to quickly identify assets that could be vulnerable  Custom scripts can quickly be deployed for fine grained reporting  Alerts can be sent to contacts for each host  Follow up reports can be used to track remediation Copyright 2012 Justin C. Klein Keane

Lessons Learned

 Internal software development takes a really long time  Logistical considerations are always the most difficult challenge  As soon as software enters a useful beta it tends to migrate rapidly to essential service  Bug fixes tend to weight towards feature use  Simple NMAP scans are never simple  Remediation tracking is as difficult as vulnerability identification  Querying large data sets takes careful planning Copyright 2012 Justin C. Klein Keane

Summary Screen

Copyright 2012 Justin C. Klein Keane

Port Query Screen

Copyright 2012 Justin C. Klein Keane

Asset Summary

Copyright 2012 Justin C. Klein Keane

Asset Management Screen

Copyright 2012 Justin C. Klein Keane

Alerts Summary

Copyright 2012 Justin C. Klein Keane

Sample Report

Copyright 2012 Justin C. Klein Keane

System Configuration

Copyright 2012 Justin C. Klein Keane

Scan Schedule

Copyright 2012 Justin C. Klein Keane

Questions, Comments?

Copyright 2012 Justin C. Klein Keane