HECTOR
Security Intelligence Platform
Copyright 2012 Justin C. Klein Keane
<jukeane@sas.upenn.edu>
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
<jukeane@sas.upenn.edu>
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
<jukeane@sas.upenn.edu>
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
<jukeane@sas.upenn.edu>
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
<jukeane@sas.upenn.edu>
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
<jukeane@sas.upenn.edu>
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
<jukeane@sas.upenn.edu>
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
<jukeane@sas.upenn.edu>
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
<jukeane@sas.upenn.edu>
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
<jukeane@sas.upenn.edu>
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
<jukeane@sas.upenn.edu>
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
<jukeane@sas.upenn.edu>
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
<jukeane@sas.upenn.edu>
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
<jukeane@sas.upenn.edu>
Summary Screen
Copyright 2012 Justin C. Klein Keane
<jukeane@sas.upenn.edu>
Port Query Screen
Copyright 2012 Justin C. Klein Keane
<jukeane@sas.upenn.edu>
Asset Summary
Copyright 2012 Justin C. Klein Keane
<jukeane@sas.upenn.edu>
Asset Management Screen
Copyright 2012 Justin C. Klein Keane
<jukeane@sas.upenn.edu>
Alerts Summary
Copyright 2012 Justin C. Klein Keane
<jukeane@sas.upenn.edu>
Sample Report
Copyright 2012 Justin C. Klein Keane
<jukeane@sas.upenn.edu>
System Configuration
Copyright 2012 Justin C. Klein Keane
<jukeane@sas.upenn.edu>
Scan Schedule
Copyright 2012 Justin C. Klein Keane
<jukeane@sas.upenn.edu>
Questions, Comments?
Copyright 2012 Justin C. Klein Keane
<jukeane@sas.upenn.edu>