Security Analytics

1. Security Analytics Dr. Char Sample February 2014

2. Agenda • Definitions & Tools • Trends • Cloud • Big Data • TIOT • Behavior • Summary • Q&A

3. Section 1: Definitions & Tools

4. Definitions • Security Analytics – can be thought of as the process associated with developing insights to an environments actual security based on the inputs collected from the various security components. • Translation – Using data to inform a decision

5. Why Do We Care? • Security professionals are increasingly be required to be conversant in them. • Why? • Old solutions do not work. • The realization that the “easy button” is still elusive. • Analytics are where the “rubber meets the road” • Money! Analytics (for the time being) require human interactions and thought, generating JOBS.

6. Why Analytics Now? • Drivers • Cloud computing • Big Data • Existing technology shortcomings • New devices. • Mostly, this effort is being driven by the need to see beyond the host and the LAN. • Situational awareness.

7. Why Analytics Now? • Changing roles and expectations for security professionals. • Inadequacies of scan and patch approach have been exposed. • Dynamic network environment • Exposes C&A shortcomings • Exposes architectural assumptions and shortcomings. • Attackers are becoming more stealth. • No clear solution leader has emerged, so DIY. • Uniqueness of environments.

8. Security Analytic Components • Tools that we use to assist in gaining insight include: • Protocol Analysis • Traffic Analysis • Flow and Metadata • Logs (system, session, pcap, metadata, flow data) • System tools • Statistical models (Markov, Bayes, Fuzzy Logic, etc.) • Mathematical models (Clustering algorithms, neural networks)

9. Tools & Data • Tools & Data Used for Analytic Creation • Protocol Analysis – IETF standards • Log data • Signature data • Packet capture data (pcap) – tcpdump • Anomalous data

10. Tools & Data • Tools & Data Used for Analytic Creation • Traffic Analysis – Data quantities • Flow data – IPFIX, others. • Metadata – IPFIX with statistical knowledge, others. • Log data – syslog, application logs, etc. • Signature data – IDS signatures • Packet capture data (pcap) – tcpdump • Anomalous data • Scripting languages - perl, python

11. Tools & Data • Protocol Analysis • Commonly used commandsvs less used commands (debug, trace, post vs put) • Commonly used parameters with commands (executable commands, wrong type parameters)

12. Tools & Data • Traffic Analysis* • Unexplained changes in volume to existing IP addresses and ports • New destination IP addresses, and ports

13. Tools & Data • Signature data • Commonly used. • NIDS, some firewalls, AV, anti-malware • Highly accurate with known attacks • Performs a basic pattern match, can be done by hardware. • Low false positives, but high false negatives • 10% effective at detecting new or 0 day attacks • Best use is in lowering false positives from AD, and keeping out less sophisticated attackers. • Ineffective against nation-state and other sophisticated attackers. • Removal of this type of data leaves analyst vulnerable to information overload.

14. Tools & Data • PCAP data • Entire packet • Preferably put together into sessions. • Storage is a problem • Legally admissible evidence • Provides details that other data types are incapable of providing. • Removal of this data type results in a lack of detailed understanding of events seen by flow and meta data.

15. Security Analytic Tools • DNS lookup tools: nslookup, dig, whois • Mapping tools: IP_address to ASN, traceroute, arptable, netstat

16. Security Analytic Tools – DNS Info • DNS tool: nslookup

17. Security Analytic Tools – DNS Info • DNS tool: dig

18. Security Analytic Tools – DNS Info • DNS tool- whois: Internet domain name and network number directory service

19. Security Analytic Tools – DNS Info • DNS tool: whois (more from query)

20. Security Analytic Tools – Routing Info

21. Security Analytic Tools – Routing Info • Tools – traceroute (limited use): print the path between hosts

22. Security Analytic Tools - ARP • Connectivity tool- ARP: address resolution display and control

23. Conclusions • Several tools are available to assist in determining the nature of the activity these tools are diagnostic tools. • Connectivity tools: ping, traceroute • Routing tools: ASN – IP address mappings • DNS tools: dig, nslookup, whois • Log data

24. End Section 1

25. Section 2: Trends

26. Cloud & Big Data • The “Cloud” provides both the source of our data, and the ability to analyze it. • Cloud as defined by NIST – IaaS, PaaS, SaaS • Characterized by dynamic provisioning • Shared resources

27. Defining the Cloud

28. Defining the Cloud

29. Items to Consider • Virtual Machines • Network Infrastructure with multiple parties • Recall the earlier discussion on global routing and how routing works. • The importance of understanding the ASN relationships. • The role of layer 2 data • Remember the arp command • Multiple IP addresses associated with the same arp address indicates virtualization (cloud) • Even when arp addresses are unique there are certain ranges of arp addresses that are “fake” and are used with virtualization • Security products are layer 3 based so they typically do not see Layer 2 behavior.

30. Items to Consider • Problems in virtual environment require analysis of the CSP’s environment. • If you are in a public cloud sharing space with other entities how will you know if their space has not been compromised? • How can you be sure that allocated resources are clean? • It is not enough to know that the security apparatus in your virtual environment is working, that is only one piece of the puzzle.

31. Items to Consider • Layer 2

32. Items to Consider • More on layer 2 data • Bugs in the hypervisor • Provisioning and de-provisioning. • Is data really wiped? • How are requests authenticated and processed?

33. Cloud IaaS • IaaS Analytic Basics • Understand the routing infrastructure of the cloud, all tenants and each cloud site. • Consider having data encrypted before it is sent to the cloud. • Understand the path between the CSP sites • Know the peering agreements between CSP locations. • Understand the routing between tenants. Most likely layer 2 technology will be used and virtual addresses will be set.

34. Cloud - IaaS • IaaS Analytic Basics • Routing • Look for the sudden appearance of new routers in tenant space. • Look for changes in routes, especially tenants suddenly having new traffic come through their space. • Look for changes in the CSP’s virtual router routes or the switch that would allow cross tenant access.

35. Cloud - IaaS • IaaS Analytic Basics • If CSP is managing DNS check delegation • If CSP is also running DNSSEC extra work must be done with DNSSEC key management issues, check the DNSSEC delegation dig +sigchase • Examine DNS data from inside the zone, cloud partition, also examine from the CSP and finally from an external point. • Verify views. • Disable recursion from external ANS. • Check DNS BIND logs, look for strange commands, executable statements, and other anomalous activity. • Examine for evidence of tunneling between tenants: queries from neighbors are a good clue. • Take note of queries to/from fast flux sites, especially those managed from other CSPs.

36. Cloud - IaaS • IaaS Analytic Basics • DNS • Look for changes in DNS Server’s arp address. • Look for cross tenant DNS/TCP traffic. • Look for changes in tenant zone information that are out of sync with normal updates. • Look for changes in authoritative nameservers (SOA) advertising. • Look for changes in MX records that direct away from known tenant mail hubs. • Look for tenants advertising multiple domains, domains that they may not own, or fast flux behaviors. • Look for tenants that set up recursive resolvers for other tenants. • Look for tenants that forward requests to other tenants. • Look for tenants that set up DHCP servers for other cloud tenants.

37. Cloud - IaaS • IaaS Analytic Basics • DNS • DNSSEC analytics • Look for changes in ZSK that are out of sync. • Look for changes in ZSK following new access to the server. • Look for activity surrounding changes to key management procedures or users for both ZSK and KSK • General • When dealing with a truly distributed attack it is possible that the IP addresses will change but the MAC addresses will be either the same or from the same pool of “fake” addresses. This would indicate that the attack is coming from a virtual environment.

38. Cloud - PaaS • PaaS • How is PaaS being utilized? • Programmers are a common reason for the need for PaaS • Test data can also reveal information about the organization. How will that data be protected? • If programmers are using: • Is DEBUG available? • How is the development environment wiped? • What about object permanence? • On the development platform: • Check security logs for signs of activity on the cluster ports. • Check for odd changes in activity on cluster hosts and ports. • Check for evidence of misconfigurations.

39. Cloud - PaaS • PaaS - Hadoop

40. Cloud - PaaS • PaaS Analytics • Look for changes in activity levels on the following ports: 8020, 50010, 50020, 50030, 50060, 50070, 50075, 50090, 50100, 50105. • Look for activity from new hosts on the above ports. • Look for signs of imposter NameNode attempts • Look for new mac address for NameNode • Look for appearance of new DataNodes, especially in existing clusters. • Look for strange commands and/or parameters. • Check authentication logs.

41. Cloud - SaaS • SaaS • Run lint checkers on new apps • Code review? • Signatures • Protocol Abuse • Command abuse

42. Cloud – SaaS Example

43. Big Data • The dynamic behavior of the cloud requires less traditional analysis to understand. • Unstructured, continuous data requires new methods • Finding patterns within Big Data is key to analytic development in the cloud • Architecturally, this will impact choices on security solutions.

44. Big Data • Big Data • Volume – obvious • Variety – many new types of data are available in “big data” that haven’t been used by security in the past, and this data is unstructured, e.g. streaming. • Velocity – dynamic relationships, everything from flow, to proxies, to pcap come in. Analysts cannot keep up with the data. • The 3 V’s of BD makes flow data extremely important!

45. Big Data

46. Big Data • What does the Hadoop explanation mean, why do we care? • There are several potential exploit areas that must be considered. • The distributed nature of the cluster • The each individual cluster inter-node issues • Communications between the NameNode and the DataNodes • Additional copies of data used to support HA • Software vulnerabilities within MapReduce & various libraries.

47. TIOT • The Internet of Things • NSA has declared 2014 the year of TIOT • Supervisory Control and Data Acquisition (SCADA) & Other Embedded Devices • Protocols: ARP, UDP, ICMP, DHCP,TCP, PPP, SNMP • Look for new entries into the arp table, look for new ports and new destinations.

48. Behavior • Recognition that technical methods alone are insufficient. • Understanding attacker “patterns of thought” • Understanding and anticipating “automatic thought processes” • Group behaviors • Game theory • Cultural influences* • Psychological influences

49. Summary • The security products and services industry has failed to keep up with the changes in the industry. • Consultants are now being asked to define and create security analytics. • A good understanding of tools and capabilities will assist in most cases along with understanding of user requirements. • Cloud security adds a new dimension since other tenants, the supply chain and the platforms must all be considered. • TIOT will stress the signature and AD models. • Big Data requires thought models and new visualization techniques.

50. END Section 2