Comparing legislative and compliance security frameworks, you will see a definite synergy in what they suggest is important to security monitoring. Interestingly, their focus isn’t on collecting every piece of information and security-related event, then trying to figure out what to do with it. What you need to do is understand the value of specific log sources in your ability to detect threats, then tune them to make sure you get the optimum flow of information from them.
ASD ISM
Take, for example, the Australian Signals Directorate’s Information Security Manual (ISM), last updated in December 2019. There are two specific control references related to event logging and auditing that tell us exactly what should be logged (and hence collected).
ASD ISM Control Reference 0584
Control reference 0584 says, “For any system requiring authentication, logon, failed logon and logoff events are logged.” This control applies to all levels of government systems, not just higher classifications, since who is using the systems and at what time they are interacting with them helps investigators figure out the timeline of occurrences should a breach occur.
ASD ISM Control Reference 0582
Control reference 0582 is even more specific, saying, “The following events are logged for operating systems: access to important data and processes: application crashes and any error messages, attempts to use special privileges, changes to accounts, changes to security policy, changes to system configurations, Domain Name System (DNS) and Hypertext Transfer Protocol requests, failed attempts to access data and system resources, service failures and restarts, system start-up and shutdown, transfer of data to external media, user or group management and use of special privileges.”
Security Monitoring to ISM Requirements
You should record anything to do with access to critical assets. That means your security team needs to look at what is important to the business and prioritise event collection capability based on criticality. While this might seem obvious, often operational security teams can’t see the wood for the trees, since the volume of information out there is astronomical. Let’s look at each element in ISM control 0582 to see what it means to security teams and how they might consider implementing their Security Information and Event Management (SIEM) system to become compliant.
Application Crashes and Error Messages
If an application crashes, it typically records information relating to the memory state, process interactions, and what the user was doing to create that failure state. This information, under normal circumstances, is useful for the vendor or application developer since it can help debug the application, but in some cases, the failure might be because an adversary was trying to find ways to break the application to help extract sensitive data. Often the tools and techniques hackers use will push applications into these failure states, so you should investigate any events that tell the SOC this has happened.
Attempts to use Special Privileges
Special privileges are authorisations for system access given to trusted individuals so they can perform administrative duties. Organisations reserve use of special privileges for those administrative staff who are most trustworthy, because misuse could lead to serious consequences. On a day to day basis, use of privileges is often consistent, with admin staff resetting passwords, restoring files from backup, installing software and rebooting devices, however, anything that looks unusual or even mildly suspicious, investigate. If the SOC gets an event from the backup system that says the “super admin” account has accessed the service on a Sunday afternoon, when scheduled maintenance happens on Monday nights, investigate.
Changes to Accounts and Policy
Group changes in Active Directory (AD), for example, can indicate a hacker is attempting to gain access to information only available to that group. Similarly, any change to system policies can tell the security team that someone is attempting to circumvent security controls by changing the rules. All of these changes in system state are legitimate, but they also occur when a hacker is using these system functions for nefarious purposes. The SOC should investigate each instance of account changes and system/security policy changes to confirm they are authorised, so building the process for verifying these changes as authorised is also important. Any changes to system configuration should always be verified and investigated if there is no evidence it is permitted.
DNS and HTTP Requests
It may seem excessive to record all DNS and HTTP activity, as this will result in a lot of requests and a lot of data. However, a forensic investigation without this information is incredibly difficult, and building an evidence timeline is nigh on impossible without it. You can also proactively monitor for DNS threats, such as zone transfers and IP address changes for critical network hosts, as these events occur when an attacker is exploiting DNS. There are also legitimate cases when DNS zone transfers occur, but they happen on a known schedule, so it’s easy to tell when something is suspicious.
System Failures
All kinds of system failure should be monitored and investigated as a potential security incident. Many of these are system management issues and not security incidents, but the process should be for the security team to dismiss them after confirming they are benign, rather than having them routed to the service management team for remediation. If the software fails on a critical document management system, for example, the IT management team will try to restart the service so that users can get on with their work. If it failed because it was under attack, then restarting the service could overwrite crucial evidence that could help stop the hacker in their tracks.
Using a Next Generation SIEM to Guide SOC Monitoring
Using a next generation SIEM solution for security monitoring gives your SOC a high-volume, high-speed capability with inbuilt threat intelligence and behavioural anomaly detection. All the information your team is now collecting, based on the ISM logging recommendations, can now be ingested into the SOC’s primary monitoring platform, where real-time analysis quickly and accurately detects non-compliances, anomalous activity and unauthorised changes of configuration or use of privileges.
Huntsman Security’s Next Gen SIEM can collect, store and alert on all available authentication information, including successful and failed logins and logoffs to ensure that you record a full authentication history for all users. The SIEM can also collect all important information from the operating system, including all activities relating to privilege escalation, group policy and domain membership modifications, and all access attempts.
By ensuring the SOC gets this full picture of potentially suspicious activity, you remain in control, resting assured your monitoring solution is keeping your business safe.
Find out more about Security Monitoring and ISM Compliance
Products
Solutions by Industry
Learning & Resources
About Huntsman
