Log monitoring is difficult for many reasons. For one thing there are not many events that unquestionably indicate an intrusion or malicious activity. If it were that easy the system would just prevent the attack in the first place. One way to improve log monitoring is to name implement naming conventions that imbed information about objects like user accounts, groups and computers such as type or sensitivity. This makes it easy for relatively simple log analysis rules to recognize important objects or improper combinations of information that would be impossible otherwise.

However asking for special naming convention changes for the sake of log monitoring may be difficult to pull off. It’s common to treat log monitoring as strictly one-way activity in relation to the production environment. By that I mean that security analysts are expected to monitor logs and detect intrusions with no interaction or involvement with the administrators of the systems being monitored other than for facilitating log collection.

I realize that such a situation may not be easy to change but if security analysts can have some input in the standards and procedures followed upstream from log collection they can greatly increase the detectability of suspicious or questionable security events. Here’s a few examples.

There are at least 3 kinds of user accounts that every organization uses:
• End-user accounts
• Privileged accounts for administrators
• Service/application accounts

Each of these 3 accounts are used in different ways and should be subject to certain best practice controls. For instance no person should ever logon to an interactive logon session (local console or remote desktop) with a service or application account. But of course a malicious insider or external threat actor is more than happy to exploit such accounts since they often have privileged authority and are frequently insecure because of difficulties in managing these accounts. Conversely, end-user and admin accounts assigned to people should not be used to run services and applications. Doing so will cause all kinds of problems. For instance, if Service A is running as User B and that user leaves the company, Service A will fail the next time it is started after User B is disabled. In audits I’ve seen highly privileged admin accounts of long departed employees still active because staff knew that there were different applications and services running with these credentials. This of course creates all kinds of security holes including residual access for the terminated employee.

Event ID 4624 makes it easy to distinguish between different logon session types with the Logon Type field. See the table below. But of course Windows can’t tell you what type of account just logged on. Windows doesn’t know the difference between end user, admin or service accounts. But if your naming convention embeds that information you can easily compare account type and logon type and alert on inappropriate combinations. Let’s say that your naming convention specifies that service accounts all begin with “s-“. Now all you need to do is set up a rule to alert you whenever it sees Event ID 4624 where Logon Type is 2 or 10 and account name is like “s-*”.

This is just one example of why it is so valuable to implement naming conventions that embed key information about objects. If you name groups with prefixes or something else that tags privileged groups as such, it now becomes very easy to detect whenever a member is added to privileged group. Perhaps you follow certain procedures to protect privileged accounts from pass-the-hash attacks such as limiting admins to only logging on to certain jump boxes. If privileged accounts and jump box systems are recognizable as such by their name then you can easily alert when a privileged account attempts logon from a non jump box system.

This of course requires upfront cooperation from administrators who may resistant to changing their naming styles just for the sake of logs. And you need to get to know the procedures and controls used to keep your network secure so that you can configure your SIEM to recognize when intruders or malicious insiders bypass these controls. But both challenges are worth the effort to face.