John Mullen Steven Templeton Promia Incorporated 160 Spear St., Suite 320 San Francisco, CA 94105 415.536.1600

1. Promia, Inc. Cyber-TA Kickoff 28 September 2006 Experiences in DoD Security Management John Mullen Steven Templeton Promia Incorporated 160 Spear St., Suite 320 San Francisco, CA 94105 415.536.1600

2. CompanyOverview • Promia Founded – 1991, San Francisco • Privately Held, Profitable • Secure CORBA OO Enterprise Networking Tools • World’s First CORBA Security Product • Actively used in Corporations Worldwide • Intelligent Agent Security Manager (IASM) • SBIR Project – Deployed and Maintained Globally • Anti-Terrorism Indications and Warnings • SBIR Project • CRADAs • NSA R2, UC Davis

3. Our People

4. Intelligent Agent Security Manager • Intelligent Agent Security Manager (IASM) • Originated as Small Business Innovation Research Project • US Navy SPAWAR PMW-160 • Distributed Security Event Management System • Objectives • Substantially Reduce False Positive Alarms • Supports IDS, Firewall, Router, Host Event Logs • Increase Attack Detection Accuracy • Signature and Anomaly for known, unknown attacks • Reduce Workload to Monitor Asset Security Events • Integrated Asset Viewer • Passive, Minimally Active Asset Discovery • Asset Monitoring • Unauthorized Asset Detection

5. Global Tiered Perspective STRATCOM Tier - 1 Tier - 2 Norfolk, VA NCDOC CND Centers NMCI Naples, IT Regional Operation Center PRNOC Tier - 3 ECRNOC Bahrain Regional Operation Center Test NOCs: UARNOC SFNOC IORNOC CHASNOC Camps, Ports Bases, Stations, Network Operations Centers (NOSCs), Command Control Centers (SYSCONS) CONUS Yokokusa Guam Sasebo Atsugi Misawa Korea Okinawa Diego Garcia Singapore Naples Sigonella United Kingdom Rotab La Maddalena Souda Bay Ship Ship Strike Group Ship Ship Bahrain = Sites Upgraded to with Promia IASM v1.2.2 (07/06) = Sites Purchased and Scheduled for install

6. Physical Design and Configuration 6U 4U 1U

7. IASM Features • Designed for the DoD Global Information Grid • NearReal-time acquisition and normalization of security event logs and alerts from Network and Host IDS Sensors, firewalls, routers, and O/S’s • Signature-based analysis of normalized events, using both standard and site-specific Analysis Agents, to detect and generate IASM alarms about known security attacks • Anomaly-based significance assessment of normalized events to assess and generate alarms about novel security attacks • Configurable Concept Lattice for assignment of semantic meaning of security incidents • Open systems-based, modular architecture to accommodate custom analysis engines, sensors, etc. • Ability to customize Sensor Agents, Analysis Agents

8. Cyber-TA Project – Promia Tasks • Integrate SRI Anonymizer into IASM • Operate with 2 Test NOCs inter-enclaved • Measure Implementation Effectiveness • Report Findings, Demonstrate Results • Promia is on schedule with initial tasks

9. IASM

10. IASM Data Experience • Different collection sites • Multiple Navy NOCs. • FAA sites. • University sites. • Small business/personal sites. • Different IDSs • Intrushield • Snort • Cisco IDS • Real Secure • Promia sensors

11. How the IASM fits in • Back-end monitoring console • Data archival • Issues: • How will anonymized data affect alert aggregation and assessment? • What can be changed to mitigate problems resulting from anonymization strategy?

12. Cyber-TA + IASM • What have we learned about event monitoring that will have an impact on the Cyber-TA project.

13. Security Management in the Real World • Challenge Areas • Acceptance • Data volume • Data quality • Data analysis and presentation

14. Gaining the Trust of the Customer • More Social than Technical • Resistance to Acceptance • When lives at stake • When $$$ at stake • Number of people affected • Attitude toward project, vendor • Personality (disorders) • How does the system affect the security of the organization? • How does it affect the mission of the organization? • Perceived value of system • Operator focus • Voluntary vs. Mandatory • Must convince groups that participation in Cyber-TA is in their own best interest, and that any risks regarding privacy or the operation of their site to be minimal.

15. Volume of Alert Data • Single site alert volume typically less than 1M alerts per day. • After reduction and processing, <8 per hour. • Majority of activity not significant (i.e. actionable) • Many alerts can be aggregated w/o significant loss of information. • Significant variation between sites. • Traffic, architecture and IDS dependent. • Site specific pre-processing may be useful solution. • Archival • Can be a big task, but not a problem given resources. • Processing • Not significant for stateless or minimal state analysis. • Database performance is important. • Load balancing parallelism is useful • Bandwidth

16. Sensor Process Extension • Integrate data summarization into Cyber-TA sensor. • Goal • Reduce bandwidth • Increase anonymization • Mitigate some attacks on Cyber-TA system • Enhance analysis w/o compromising security of data collection site.

17. Sensor Process Extension • Alerts are summarized at the sensor prior to anonymization. • Degree of summarization based on: • Volume of data • Higher volumes tend of force higher levels of summarization • Similarity of data • Statistical and heuristic relations considered • More similar data will aggregate to higher levels • “Interestingness” of activity • Heuristic • Anomalousness • Modifiable by Cyber-TA participants.

18. Sensor Process Extension • High volume of same/similar activity more highly aggregated. • Multiple DoS alerts w/ identical attributes • Can “roll-up” those w/ same timestamp, contiguous timestamp (add count and duration), only vary in high source port (replace w/ “MHP”). • Dissimilar activity not aggregated. • Lone Buffer-Overflow w/ scans • In bound vs. outbound worms. • Low importance features more highly aggregated. • High ports, multiple IPs set by load balancer. • Normal activity more highly aggregated. • Don’t need details on yet another port 80 host sweep, background traffic worm, or FP artifacts of site architecture. • Interesting or security-significant activity less highly grouped than that identified as less interesting or not security significant. • Requests for details of specific alerts honored. • Activity targeting critical servers. • Alerts for attacks on host w/ known vulnerability.

19. User-specified Interestingness Requests • From Cyber-TA participant or Cyber-TA prime. • Require negotiation w/ participants • Heckman: • May require request validation. • Domain specific language to support request validation

20. Security Management in the Real World Time Synchronization • Accurate time information required for accurate assessment • Accurate time information difficult to obtain • Clock Sync • constant: clock skew, Time Zones, network propagation • Variable: clock drift, reset, propagation • IDS quirks • Sigs received “out of order” from IDS • NTP not viable solution

21. Security Management in the Real World Localization • Not all Networks are the Same • Network Architecture effects Detection • NATing, Firewalls, Sensor Placement, Load Balancers • Same alert on different networks may indication different activity.

22. Security Management in the Real World Sensors are far from perfect. • Can be their own worst enemy… • Extreme number of false positives. • Most really just advisory. • Can be DoS attack • Signatures are rarely current • Current signatures rarely good • Can be surprisingly effective in novel ways • Signature based methods limit analysis potential.

23. Security Management in the Real World Poor Sensors (cont.) • Medical analogy: • Signatures not primary detection tool. • Primary action based on signs and symptoms. • Can we develop a new class of sensors that monitor ”signs and symptoms”? When problem is detected, signatures on “rule-outs” are tried. Details of sensor alerts are processed for common patterns that could lead to first cut of auto-generated signature. Should be over specific (to avoid false negatives), then refined as more tagged alerts are processed. • Network vs. Host sensors (observed vs. reported) • Should Cyber-TA project develop and run S&S rules for wide internet health monitoring and epidemiologic analysis