Information Security: Advanced SIEM Techniques
Download as PPTX, PDF3 likes2,030 views
Joe Partlow discusses advanced SIEM optimization, highlighting its importance in monitoring and analyzing security logs to defend against threats. He emphasizes the need for constant configuration and tuning of SIEM systems to manage the overwhelming volume of logs and alerts from various sources. Strategies for improving SIEM effectiveness include aggregating events, tuning alerts, and ensuring visibility across all network segments and applications.
Information Security: Advanced SIEM Techniques
- 1. Advanced SIEM Optimization Joe Partlow BSides Atlanta 2015
- 2. Joe Partlow ([email protected]) – CISO, ReliaQuest Been in the IT and information Security industry for 15+ years and has experience in Operations Management, Information Security, Network Security, Systems Design, Risk Assessment, Database Administration, Network Infrastructure, Web Application Development, Systems Design & Integration and Project Management. I just spend a lot of time playing around with SIEM and logging!
- 3. • Blue Team vs Red Team? • Who currently manages a SIEM at work? User of a SIEM?
- 4. Security Incident & Event Management (SIEM) systems allow you to consolidate the million log sources you have in one spot and perform advanced correlation across all the various log sources. • Compliance tells us we have to… • Ex. Did the increase in WAF entries also correspond with login attempts for our various internal applications or servers. • You can’t defend against things you can’t see. • Try searching across each individual server’s event logs for all activity from a particular timeframe • Logs are boring so let’s make something to analyze and alert on this stuff for us. • We don’t if we try to block it first from our IPS/Firewall, then you don’t have to worry about it right
- 5. This is not a set it and forget tool like a firewall. SIEM tools require constant configuration and optimization instead of small incremental changes. Many of the same problems as IDS/IPS: • Need to constantly create/tune rules/alerts to adjust for new attack signatures • Business is always evolving and adding new technologies and applications and we need to monitor those logs • Easy to get overwhelmed with sheer volume of logs and alerts from those logs • Expensive! (Time and money)
- 6. All is not lost! It’s easy to feel like security and monitoring is a losing battle, but let’s find some ways to make it easier on ourselves. • Filter/Aggregate events – Start with importing all logs until you see what you are getting, then scale back to what is important. Use splunk or MS LogParser for large files (ex. IIS logs). • Tune alerts – Flooding the security team mailbox with 1000’s of alerts just makes them get ignored or disabled. Make sure set realistic thresholds and aggregate alert events. • Don’t overwhelm the SIEM – Make sure you scale up the SIEM hardware as you add devices across the enterprise. Start with critical or PCI/HIPAA/X systems and move outward. Slowness of the tool is one of the most common complaints. • Those were easy, now for the hard ones…
- 7. Windows event logs and syslog are only the beginning. Other types of logs are important as well: • Applications – In-house operational apps, HR, billing, manufacturing, etc. • Windows protections – HIDS, AV, EMET, Applocker • Weblogs - IIS, Apache, etc. - Poor man’s WAF • Databases – User Auditing has disadvantages, customize what to get pulled and logged. • MDM – Many users using mobile devices on the network, restrict and monitor via MDM or at least DNS. • SNMP config data – Performance data might overwhelm but could be aggregated with OSSEC or Nagios…
- 8. • VOIP servers – Asterisks etc… • Cisco UCS API – better than SNMP • DNS/DHCP logs • SQL Server DMV - (Dynamic Management Views) for advanced SQL data (mirroring, Full-Text Search, Filestream/filetable etc.) • How to get them (show 1337 code): • Convert to syslog or write to windows event log
- 9. You must get visibility into EVERY area of the business and network. Most companies don’t know what to log or even what is available. These include in-house applications, databases, web logs and of course system logs. We could have a whole con for this, but some questions to ask are: • VMware – Do you have visibility when new machines are created or deleted? • Web Servers/WAF – Can you tell if injection attacks are being thrown at you and if they were successful? One of the most common causes of breaches so make sure you can see them. • Show leet code • Configuration auditing – do you know what machines are running cracked Photoshop? Wireshark? Metasploit? Users don’t have admin rights to their workstation, right? • Windows Updates – Do you know if a system hasn’t been patched or rebooted in awhile?
- 10. • DNS records – Would you know if you got hijacked? ? Any bots phoning home? How many users are going to www.securitytube.com? Draft them onto the team or monitor all activities… • OpenDNS has an API • DHCP – need to attribute activity to a user. Match IP to workstation and even logged on user… (PowerShell is awesome!) • Amazon/Azure Cloud API – Find out what’s up with your cloud • Microsoft enterprise – SharePoint, exchange, Forefront, Azure, System Center, etc. • Google Maps Integration – Hook up geo location or zip code mapping to visually map • Create dashboards and reports around every technology coming into the SIEM. It’s too helpful and expensive to just be used as a log repository (although very common). • Any other interesting ones deployed in your environments? I have prizes…
- 13. Unfortunately most of the time the security team is last to know about servers being brought online or decommissioned. We need to have a handle on the device inventory. What can we do? • Regular nmap scans and bounce against internal SIEM host inventory • Import vulnerability scans – Cuts down on noise by adjusting severity of alert if destination system has a vulnerability on that port. • Import from inventory systems (Altirus, HPNA, SCCM, MS Excel etc.) – Keep it up to date! • Set baselines – Run the SIEM for a few weeks to know what is a normal amount of login attempts, protocols in use, netflow traffic, etc. before you turn on all the alerts.
- 14. This is probably one of the biggest areas for improvement and one of the least common setup that I see. It’s time consuming to setup and maintain the lists and expensive to buy them, but usually your first indicator of malicious attempts… • Very easy to setup an alert for matching on any source or destination IP that is in our bad people list. • Do you have customers in other countries? If not, start with this. If so, should it only be web traffic? Probably not SSH… • Problem is that no-one has time to keep up with all the new threats. We all wish we could spend time doing actual research instead of looking at account lockouts… • Anyone able to run honeypots? How about just honey hashes or canary files/records? • OSINT is our friend! Alienvault, Facebook, etc. all have threat sharing programs.
- 15. • Live memory monitoring – Most malware only memory resident, so let’s try to find it before it hits the network. Ex. EnCase enterprise, regular Volatility dump/analysis. • Live network monitoring – Use your IDS/IPS Integration, it’s not as common as it should be. PCAP parsing, Nield tool looks promising as well… • Continued expansion of UTM – The more sources we can get, the better. (AV/Malware/Phishing etc.) • Integration Commands – Cool feature in ArcSight to extend functionality (use Snort, nmap, windump, nessus, forensics from within an event viewer) • Mobile devices – Android logging library now has built-in splunk logging available
- 16. Monitor the latest attacks – How many people are monitoring for well known, misbehaving URLS or IP addresses • Threatstream/Mandiant/Looking Glass/etc. – Commercial feeds • APT1 • Dshield • Malwaredomainlist.com • Known botnets or C&C servers • List goes on and on and new ones daily…
- 17. • With great power comes great responsibility. • Make sure it’s your network. Just sharing pastebin links get you terrorism charges – ask Weev • Make sure you know where your network ends. Don’t trust the A records! • Make sure you are authorized to run pen tests on your network (even if you are on the security team) • Work with the sys admins. Accidents happen and you don’t want to explain to the C-Level guys why you caused a production outage. Or even worse, that it took hours to figure out why. • Work with those red teamers – these guys will be more than willing to point out the weak points
- 18. Attackers are sharing techniques and tactics, but rarely seen on the defensive side. I know it’s not as glamorous as trading 1337 sploitz, but let’s face it, most of us are tasked with this day to day • Forensics sites and forums are good start • SANS ISC Diary (http://isc.sans.edu/diary.html) • AlienVault Community – More and more SIEM vendors are trying to do this • Local groups (Vendor specific, Def Con, Linux User Groups, Hackerspaces, etc.)