SANs – Critical Log Review Checklist for Security Incidents

SANs – Critical Log Review Checklist for Security Incidents and Use Case Log sources

Three critical factors for successful SIEM deployment for effective Threat Detection.

This is the first of a number of articles, to discuss the details around developing effective Threat Detection strategy. These articles are specific in nature to each subject matter.

In this article, I explore, three critical factors for successful SIEM deployment, specially concentrating on the first main requirement, selecting optimal logs for your SIEM solution for effective threat hunting.

A modern SIEM should be viewed as a central nervous system, capturing data and generating information that security teams can use as intelligence to detect potentially malicious activity before any damage is realised, providing a safety net that can catch potential threats that might slip through traditional defenses.

Due to their complexity and demanding requirements, security information and event management (SIEM) solution projects fail and/or stall deployments common, where a SIEM solution was acquired and has been quietly gathering dust ever since the initial deployment.

Therefore it is important to follow a simple plan for a successful SIEM Deployment.

The following are (3) three critical factors for any SIEM successful deployment to deliver visibility into your cyber security health in realtime;

  1. Log sources selection – the data from log sources plays a vital part to give you the visibility of your whole IT real-estate in a single pane of glass.
  2. Use cases or correlation rules – these are the rules to identify threats using information from you log sources and correlating them threat intelligence.; Example Threats; IoC (Indicators of Compromise), TTP (Tactics , Techniques Procures), MD5, Filenames, IPs, Domains, C2, URLs,  ATPs, Registry keys, file hashes,Email addresses, email subject, links and attachments. Trying to identify to Known knowns, known unknowns, unknown unknowns
  3. Breach Attack Simulation – all too often, events that do make it to the SIEM don’t result in a notable or correlated event because of faulty configurations as well as problems around alerting, parsing, time stamping, routing etc., meaning that the likelihood of a human seeing and responding to the event is very low. Therefore, it is vital to, test Use cases via a Red Team and Attack scenario based on specific exploits.

SIEM Log source selection.

To obtain the maximum value out of a SIEM tool, it may seem tempting ingest and process large amounts of event data at once.

Rather than a “boil the ocean” approach, firstly priorities your logs sources, concentrate on baselining and normalising the following data sources in order of priority.

Consider the following categories to identify your potential Attack Surface;

  1. External facing Systems
  2. Security Devices
  3. Authentication Systems
  4. SaaS Apps
  5. Windows Systems
  6. Linux Systems
  7. Network Devices
  8. Internal Systems
  9. Mobile Devices
  10. Storage Systems
  11. COT (commercial off-the-shelf)

<Create Image of above>

Threat Detection in the Cloud is even more complex, while this article does apply to any environment. I will release a more detailed articles on Threat Detection for Azure and AWS in the near future. In short you need to consider;

  1. Cloud Control Pane
  2. Cloud Data Pane
  3. Cloud Services

Here is a list of main log sources for Threat Detection in order of priority;

  1.  DMZ
    • Any thing and everything inside your DMZ are external facing network/edge network. (This means every single IP, Interface and services, etc.
    • External Facing web websites/ips, etc.
    • WAF
  2. Internet / North-South Traffic (All external links) (Egress / Ingress)
    • Firewalls, Routers, SDNs, WANs and Switches
  3. Edge Firewalls
    • Layer 7 / NGFW
    • pfSense + Snorth and OpenID
  4. IDP/IDS (NIDS) full pack capture
    • NIDS (eg. Snort,,
    • Full Packet Capture/ TAP/Pcaps/NetFlows (eg. p0f, bro, and prads)
    • NetFlow, sFlow , cflow, J-Flow , FNF, IPFIX, NetStream, Appflow
    • NetFlow Security analysis: Detect changes in network behavior to identify network anomalies. NetFlow data is valuable forensic tool to understand and replay the history of security incidents. NetFlow Analyzer accounts for the following details from the NetFlow Packets;
      • Source and destination IP address
      • Source and destination port number
      • Input and output interface number
  5. DNS
  6. DHCP Servers (IPMAN)
  7. Authentication and Identity (AAA)
  8. Web Gateway/Proxy
  9. Email Gateway/Proxy
  10. CASB/SaaS Apps
  11. Endpoint Security systems
  12. Vulnerability Scanner
  13. Database Activity Monitoring
    1. e.g. Trustwave DbProtect
  14. Operation Systems (HIDS)
    3. Windows Systems
    4. Linux Systems
    5. OSX
  15. HIDS (eg.
  16. East-West Traffic
    • Routers
    • Switch CAM tables
    • Wireless
    • NAC
  17. Storage Systems
  18. DLP
  19. FIM e.g
  20. COT (commercial off-the-shelf)
  21. Device Register
    1. Asset Register / Risk Profile assessment
    2. CMDB
    3. ITSM
    4. Application Register
    5. e.g.
  • Log/SIEM
    • It can become extermely expensive to deploy Enterprise SIEM/Log solution for your whole network, what you can do is use a Opensource Log collector, just to collect the logs into central location you can control and deploy as you wish and then forward these logs into a Enterprise SIEM platformInsure any  opensource projects as commercial support, otherwise you are going to be left old software own your own to update. Make sure you can foward logs into the SIEM in a supported format, or RAW unparsed.
    • LogStash
    • GrayDog
    • Nagios/Zabbix
  • Certificate Management
  • Psychical Access/Security


uws-threat-hunting-101-white-paper.pdf 2019-06-22 13-34-21

Core Security Technologies

  1. Firewall
  2. WAF
  4. NetMon
  5. Identity Access Monitoring
  6. DNS
  7. DHCP
  8. AntiVirus
  9. Email Proxy
  10. Web Proxy
  11. CASB
  12. UEBA
  13. EDR
  15. Application Whitelist
  16. FIM
  17. DLP
  18. Vulnerability Scanner
  19. Database Activity Monitoring, Vulnerability Management and Rights Management
  20. Asset Register
  21. CMDB
  22. VPNs
  23. SIEM
  24. Log Collector
  25. Routers
  26. Switches
  27. Wireless
  28. MDM
  29. COT (commercial off-the-shelf)
  30. Application dependency mapping
  31. Configuration and Change Management
  32. Certificate Management
  33. Encryption Technologies
  34. SOAR
  35. Cloud Control Pane and Data Pane Monitoring. (all of the above.)


  • Intrusion detection systems
    Endpoint security (antivirus, anti-malware)
    Data loss prevention
  • VPN concentrators
  • Web filters
    Honey pots
  • Network logs
    DNS servers
    Wireless access points
  • WAN
  • Data transfers
    Private cloud networks
    Applications and devices
    Application servers
    Intranet applications
    Web applications
    SaaS applications
    Cloud-hosted servers
    End user laptops or desktops
  • Mobile devices



Use Cases

Examples for threat management use cases include real-time monitoring for external network threats, authentication failures, threat intelligence feed fusion, and user activity and behavior profiling and monitoring, authentication tracking and compromised account detection, tracking compromised and infected systems, malware detection by using network connectivity logs to identify outbound connections, and tracking system changes and other administrative actions. These will be accompanied by incident response processes and automated cross-data correlation and alerting.


Threat detection testing;

Periodic Attack Simulation based on Use cases, Red Teaming, Purple Teaming and Automated Pentesting on your critical assets (DNA – Database, Network, Applications) using tools and methods like;

While testing may seem daunting to some, without it, it is impossible to know whether what you intend on monitoring will actually be feasible. Similarly, simulated attacks should be used to verify that sufficient forensic data is being gathered to allow effective incident or breach investigation, especially sufficient to be used in legal proceedings.

External penetration tests provide an ideal testing bed to ensure that attacks are detectable with your current deployment. It is something that has to be verified before a breach occurs — afterward is too late.

  • Option 1 – Manually check that IoCs have been updated across your security controls.This would require checking that security controls such as your email gateway, web gateway, and endpoint security have all been updated with the latest threats’ indicators of compromise (IoCs) usually published by AV companies who detect the malware binaries first.
  • Option 2 – Create a ‘carbon copy’ of your network and run the threat’s binary on that copy.While safe, IT and security teams may be unaware of certain variations from the real deal. So while the attack simulation is running against an ‘ideal’ copy, your real network may have undergone inadvertent changes, such as a firewall running in monitoring mode, a patch not being installed on time, and other unintentional variations. The resulting mirror image has inadvertently become a ‘filtered’ one.
  • Option 3 – Build a homegrown simulation.While effective, developing your own malware simulation is a time- and resource-intensive effort that usually requires a dedicated threats or vulnerability assessment team.Moreover, even if you have the resources, the turnaround time for getting a live and safe simulation to work may not be ideal.
  • Option 4 – Run an automated simulation of the threat in your production environment.What if you could challenge your controls with a threat on the day that it hits the headlines? This is where automated security effectiveness testing can help.By running simulations of the latest cyber attacks against the controls required to detect them correctly, you can make sure your current security arsenal is catching risky IoCs, and close any gaps faster.
CSO table: Open-source ATT&CK test tools
  • Architecture risk analysis (ARA). About half of the software defects that create security problems are flaws in design. ARA identifies those flaws and determines the level of risks to business information assets.
  • Static application security testing (SAST). This helps teams find and fix security and quality weaknesses in proprietary code as it is being developed.
  • Dynamic application security testing (DAST). This tool tests applications while they are running, simulating an attack by a hacker.
  • Interactive application security testing (IAST). This also tests running applications, but unlike DAST, it uses code instrumentation to observe application behavior and dataflow. It’s useful for CI/CD (continuous integration/continuous delivery) development environments, where the priorities are speed and automation.
  • Software composition analysis (SCA). Almost every application in existence today is built, at least in part, on open source software components. SCA finds those components, along with any associated security vulnerabilities that have been reported against them.
  • Pen testing. This is best done at the end of development, and is considered an extension of DAST. The goal is to find vulnerabilities in web applications and services and then try to exploit them so developers can fix them before a product hits the market.

Attack simulation tools;

Beyond Threat Detection, Addressing the the dark side;

The cybersecurity specialist can’t escape from the knowledge that most of their worst days on the job will be caused by co-workers who carelessly/inadvertently circumvent security protocols for the sake of convenience.

  1. Reference information;
  1. 0



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s