Slide 1

Slide 1 text

Automating Security with the OWASP Automating Security with the OWASP Assimilation Project Assimilation Project #AssimProj @OSSAlanR Alan Robertson Assimilation Systems Limited owasp.org/index.php/OWASP_Assimilation_Project http://AssimilationSystems.com

Slide 2

Slide 2 text

2/29 Biography Biography ● 35+ years in IT/development – 10 years in system management (SysAdmin) ● Founded Linux-HA project - led 1998-2007 – aka “Heartbeat” - now called Pacemaker ● Founded Assimilation Project in 2010 ● Founded Assimilation Systems Limited in 2013 ● Alumnus of Bell Labs, SuSE, IBM

Slide 3

Slide 3 text

© 2015 Assimilation Systems Limited 4/29 Security questions Security questions ● Do you think good security staff is easily available? ● Do you think security is going to get better soon? ● Do you think you have enough staff for security to keep up with changes at DevOps / Agile rates?

Slide 4

Slide 4 text

© 2015 Assimilation Systems Limited 5/29 Disturbing Trends... Disturbing Trends... 30% of break-ins come through “lost” systems (Verizon) 90% have had failures of unmonitored services (Turnbull) 71% are unable to stay in compliance (Verizon) 30% only start monitoring only after a problem (Turnbull) 30% of systems doing nothing useful (Koomey)

Slide 5

Slide 5 text

6/29 OWASP Assimilation Use Cases OWASP Assimilation Use Cases ● Tracking IP and MAC addresses ● Continuous validation of configuration against compliance rules ● Tracking software versions – (OS packages, GEMs, pip packages, etc) ● Tracking checksums of network-facing files ● Tracking services offered - ports, binaries, arguments, etc ● Tracking security configuration, permissions ● Monitoring status of servers and services (working correctly?) ● Scoring of security issues with triage tools ● Includes Docker containers ● Alerting on changes in configuration or status (any of the above) ● Near-zero configuration ● No pings or port scans

Slide 6

Slide 6 text

Highly S Highly Scalable Discovery-Driven calable Discovery-Driven Automation Automation Continuous Discovery drives everything ● Continuous extensible discovery (CMDB) – systems, switches, services, dependencies, system settings ● zero network footprint discovery process (using agents) ● Discovery eliminates most configuration ● Discovery Drives Best Practice Security Analyses ● All data goes into central graph CMDB (Config Mgmt Data Base) ● System naturally scales to ≈ 100K servers

Slide 7

Slide 7 text

© 2015 Assimilation Systems Limited 8/29 This all sounds unreasonable... This all sounds unreasonable... ● Huge scalability without complexity? ● Discovery without pings or port scans? Really?

Slide 8

Slide 8 text

© 2015 Assimilation Systems Limited 9/29 Simple Scalability Simple Scalability I can explain how we scale so your grandmother would understand...

Slide 9

Slide 9 text

© 2015 Assimilation Systems Limited 10/29 Assimilation Architecture Assimilation Architecture ● Central Collective Management Authority (CMA) – written in Python – directs and delegates most work to nanoprobes – does nothing as much as possible – Doing nothing scales really well – should scale into the 100K system range – Near-zero configuration – discovery drives everything ● Fully distributed “nanoprobe” agents – Simple, lightweight, policy-free – directions come from CMA – Written in 'C' – Run scripts for monitoring or discovery – Send/receive heartbeats – Listen for ARP, LLDP, CDP packets ● Neo4j graph database

Slide 10

Slide 10 text

© 2015 Assimilation Systems Limited 11/29 Assimilation Analysis / Reports Assimilation Analysis / Reports ● Comparison (“auditing”) against best practice hardening rules – default rules from IT Best Practices Project ● Risk scoring – for triage and mitigation management ● Unknown IP Addresses ● Automatic service monitoring ● Unmonitored services ● Triage related risk scores

Slide 11

Slide 11 text

© 2015 Assimilation Systems Limited 12/29 B Best Practice (hardening) Analyses est Practice (hardening) Analyses ● Triggered by Discovery Updates – Analysis occurs within seconds of change – No change => No analysis ● We can analyze anything discovered ● You can easily discover anything you want ● Alerts and Reports available

Slide 12

Slide 12 text

© 2015 Assimilation Systems Limited 13/29 Future Security Work Future Security Work ● Coordinate with vendor security updates – “Listen” to vendor security update announcements – Update scores when vulnerable packages found, fixed ● Do interesting things with checksums – Whitelists – Blacklists – “Minority Report” – 99 copies the same, one different... ● More discovery (firewall rules, etc) ● Integrate with SIEMs ● Add RBAC filtering ● What else should we be doing?

Slide 13

Slide 13 text

© 2015 Assimilation Systems Limited 14/29 Demo Demo Everything is discovered – nothing is configured manually ● What needs hardening ● How to Triage your hardening issues ● How to Demonstrate and Track Progress ● How to keep them in compliance (hardened) ● Visualizing Your Attack Surface ● Who has what package+version – Docker package discovery too!

Slide 14

Slide 14 text

© 2015 Assimilation Systems Limited 15/29 Summary of what’s cool... Summary of what’s cool... ● System knows more about your environment than you do ● Can discover anything you’d like to know ● Discovery keeps everything up to date (quasi-real-time) ● Best practice auditing/hardening check is continuous ● Scoring system helps manage mitigation process ● System has near-zero configuration ● Discovery includes Docker containers ● System also monitors servers, services ● Event API supports immediate notification of changes ● System scales unusually well

Slide 15

Slide 15 text

© 2015 Assimilation Systems Limited 16/29 Where to find this Information online? Where to find this Information online? http://assimilationsystems.com/category/getting-started/ 1. 15 Minutes To Better Security 2. An Hour To Better Security 3. A Half-Day To Better Security Where to See Similar Demos ● http://assimilationsystems.com/category/videos/ ● http://assimilationsystems.com/sample-demo-output/

Slide 16

Slide 16 text

© 2015 Assimilation Systems Limited 17/29 Get Involved! Get Involved! ● Get Assimilated! ● Contribute! – Users – give it a try – Security best practice experts – Testers, System Management, Continuous Integration – Designers – Developers (C,Python, Shell, PowerShell, JavaScript) – Porters (esp Windows) – Promoters, Publicists, Packagers, etc.

Slide 17

Slide 17 text

© 2015 Assimilation Systems Limited 18/29 Resistance Is Futile! Resistance Is Futile! These slides: bit.ly/BsidesLV16 Mailing List: bit.ly/AssimML @OSSAlanR #assimilation on irc.freenode.net Project Web Site: assimproj.org https://www.owasp.org/index.php/OWASP_Assimilation_Project Company Web Site: assimilationsystems.com Download: assimilationsystems.com/download

Slide 18

Slide 18 text

© 2015 Assimilation Systems Limited 19/29 Current discovery scripts Current discovery scripts ● auditd_conf - discovers settings in /etc/auditd.conf ● checksums - discovers checksums of network-facing binaries, libraries and JARs ● commands - discovers what commands are installed in standard directories ● cpu - discovers CPU information ● docker - discovers Docker instances and attributes ● fileattrs - discovers file attributes (permissions) of whatever files its asked to check out ● findmnt - mount table related discovery ● login_defs - /etc/login.defs discovery ● mdadm - Linux RAID configuration ● monitoringagents - discovery of installed monitoring agents ● netconfig - network configuration - similar to ifconfig ● nsswitch - discovery of /etc/nsswitch ● os – discovery information - basically uname -a ● packages - discovery of all installed RPM, DEB, pip (python), Ruby GEMs and node.js NPM packages ● pam - discovery of PAM configuration ● partitions - Discovery of partition information ● proc_sys - Discovery of Linux /proc/sys settings - basically everything ● sshd - Discovery of sshd settings ● sudoers - Discovery of /etc/sudoers settings ● tcpdiscovery - Discovery of services used and services provided (there were two slides on this subject) ● ulimit - root's default ulimit settings ● vagrant - Discovery of vagrant VMs and settings

Slide 19

Slide 19 text

Switch Discovery Graph from Switch Discovery Graph from LLDP / CDP LLDP / CDP

Slide 20

Slide 20 text

© 2015 Assimilation Systems Limited 21/29 Why a graph database? (Neo4j) Why a graph database? (Neo4j) ● Humans describe systems as graphs ● Dependency & Discovery information: graph ● Speed of graph traversals depends on size of subgraph, not total graph size ● Root cause queries  graph traversals – notoriously slow in relational databases ● Visualization is Natural ● Schema-less design: good for constantly changing heterogeneous environment ● Graph Model === Object Model

Slide 21

Slide 21 text

© 2015 Assimilation Systems Limited 22/29 Monitoring Pros and Cons Monitoring Pros and Cons Pros Simple & Scalable Uniform work distribution No single point of failure Distinguishes switch vs host failure Easy on LAN, WAN Multi-tenant approach Cons Active agents Potential slowness at power-on

Slide 22

Slide 22 text

"sshd": { "exe": "/usr/sbin/sshd", "cmdline": [ "/usr/sbin/sshd", "-D" ], "uid": "root", "gid": "root", "cwd": "/", "listenaddrs": { "0.0.0.0:22": { "proto": "tcp", "addr": "0.0.0.0", "port": 22 }, sshd Service JSON Snippet sshd Service JSON Snippet (from netstat and /proc) (from netstat and /proc)

Slide 23

Slide 23 text

"ssh": { "exe": "/usr/sbin/ssh", "cmdline": [ "ssh", "servidor" ], "uid": "alanr", "gid": "alanr", "cwd": "/home/alanr/monitor/src", "clientaddrs": { "10.10.10.5:22": { "proto": "tcp", "addr": "10.10.10.5", "port": 22 }, ssh Client JSON Snippet ssh Client JSON Snippet (from netstat and /proc) (from netstat and /proc)

Slide 24

Slide 24 text

© 2015 Assimilation Systems Limited 25/29 Service Monitoring based on HA Technologies Service Monitoring based on HA Technologies ● Well-proven architecture: – reliable “no news is good news” ● Implements Open Cluster Framework standard (LSB and others – Nagios coming!) ● Each system monitors own services ● Can also start, stop, migrate services

Slide 25

Slide 25 text

© 2015 Assimilation Systems Limited 26/29 How does discovery work? How does discovery work? Nanoprobe scripts perform discovery ● Each discovers one kind of information ● Can take arguments from environment ● Output JSON CMA stores Discovery Information ● JSON stored in Neo4j database ● CMA discovery plugins => graph nodes and relationships

Slide 26

Slide 26 text

© 2015 Assimilation Systems Limited 27/29 A Few Canned Queries A Few Canned Queries allipports get all port/ip/service/hosts allswitchports get switch connections crashed get crashed servers shutdown get gracefully shutdown servers downservices get nonworking services findip get system owning IP findmac get system owning MAC unknownips get unknown IP addresses unmonitored get unmonitored services

Slide 27

Slide 27 text

© 2015 Assimilation Systems Limited 28/29 OS discovery JSON Snippet OS discovery JSON Snippet { "nodename": "alanr-1225B", "operating-system": "GNU/Linux", "machine": "x86_64", "processor": "x86_64", "hardware-platform": "x86_64", "kernel-name": "Linux", "kernel-release": "3.8.0-31-generic", "kernel-version": "#46-Ubuntu SMP ...", "Distributor ID": "Ubuntu", "Description": "Ubuntu 13.04", "Release": "13.04", "Codename": "raring" }

Slide 28

Slide 28 text

Massive Scalability – Massive Scalability – or or “I see dead servers in “I see dead servers in O O(1) time” (1) time” ● Adding systems does not increase the monitoring work on any system ● Each server monitors 2 (or 4) neighbors ● Each server monitors and discovers its own services ● Ring repair and alerting is O(n) – but a very small amount of work Current Implementation

Slide 29

Slide 29 text

© 2015 Assimilation Systems Limited 30/29 Minimizing Network Footprint Minimizing Network Footprint (in roadmap) (in roadmap) ● Support diagnosing switch issues ● Minimize network traffic ● Ideal for multi-site arrangements