On systems running 2003, any User account needing the ability to read other system’s event logs required that the registry to be edited and some SDDL (Security Descriptor Definition Language) entries be made on all respective remote systems. In 2008 it has been simplified by utilizing a group that has read access by default. It’s called “Event Log Readers” group.

That’s great and makes it much easier to grant this type of access, but what if I want the User accounts defined in this group to be restricted to certain event logs only? This too is possible, but you need to remove the SID of the local Event Log Readers group. The command-line utility called “wevtutil” allows this to be performed. And not all Event logs are readable, such as any of the “Application and Service” logs, until access is granted to the Event Log Readers group. The wevtutil command allows this to be performed as well.

When using the wevtutil command, you will want to first view the “channelAccess” string:

wevtutil gl security ;”gl” means “Get log configuration information” and displays the channelAccess string as noted below.
channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0×5;;;BA)(A;;0×1;;;S-1-5-32-573)
The value of “(A;;0×1;;;S-1-5-32-573)” is what grants (A = Allow) read (0×1 = Read) access to the Event Log Readers group (SID = S-1-5-32-573). Append similar strings to the channelAccess string to grant read access to a specific SID.

To remove read access from the Event Log Readers group, execute the following command:
wevtutil sl security /ca: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0×5;;;BA)
Note the removal of (A;;0×1;;;S-1-5-32-573).

While SDDL entries can appear to be “confusing” they are also a useful place to verify access to specific event logs for troubleshooting purposes.

So “keys to the kingdom” don’t have to be delegated if time is taken to address the specific access requirements in your organization.

The Wall Street Journal is reporting that Nortel Networks was breached for over a decade with hackers (thought to be Chinese) enjoying unrestricted access.  This is the latest reminder (see Symantec, Mitsubishi Heavy Industries, RSA and Northrup Grumman, and the United States Chamber of Commerce) of how vulnerable corporations and agencies seem to be when it comes to nation state sponsored cyber espionage.  It is also a stark reminder of how a basic compromise (stolen credentials) can become an expansive and stealthy breach across a broad corporate network.

Industrial espionage is nothing new.  Nations have always sought to bridge technology gaps by acquiring what others possess.  With the rise of the Internet, it just became so much easier.  Gone is the need to bribe an employee, embed a spy, break into a site.  Simply compromise a password, login, and go to work.  When you have a 100s or 1000s of highly trained electrical and computer science engineers at your disposal, what chance does an unprepared adversary have?

Should we really be surprised – especially those of us who grew up in the cold war – that Nations would aggressively compromise corporate and agency network in support of their own economic interests?  As a patriot of my country, I have to wonder how many US corporations are breached and leaking right now?  I’m afraid the number would be appalling – it is likely very high.

US corporations and agencies (and those of our allies) must become more diligent and vigilant in their approach to network security monitoring.  The perimeter simply cannot hold, cyberthreats will find a way in.  When they do, the ability to detect and quickly respond is paramount.  The leaking can be stemmed but only when appropriate resources and effort is invested.  Until then, the wake up calls will continue to get louder.

Everyone knows how commonplace USB flash drives are today, so it comes as no surprise that they’ve become a fixture in workplaces around the world. However, in the face of potential malware and other insider threats, such as data loss or tampering, it may be time for stricter policies on their usage. After all, removable thumb drives may have been responsible for malware as infamous as the Conficker and Stuxnet worms—and there are always newer, more dangerous threats evolving every day. This should be disturbing for a number of reasons. Not only do you have the aforementioned threat of all sorts of malware (which will inevitably lead to a loss of time, money, effort, etc.), but the company’s reputation is also at stake. A study done by the Ponemon Institute (http://www.darkreading.com/security/attacks-breaches/231901835/study-how-data-breaches-damage-brand-reputation.html) showed that a data breach can cause a brand’s value to plummet by 12 to 25 percent.

So how can you best protect your company from these USB-related nightmares? If your company has absolutely no need for USB flash drives in the workplace, then – of course – they can be banned entirely. In many situations, this isn’t very practical. Instead, try these options:

1. Disable autoplay/autorun for all USB and CD/DVD drives. This will prevent malicious programs from automatically executing – on your network.

2. Consider updating your software. A Microsoft blog post (http://blogs.technet.com/b/mmpc/archive/2011/02/08/breaking-up-the-romance-between-malware-and-autorun.aspx) states that “Windows XP users were nearly 10 times as likely to get infected by [Autorun malware] in comparison to Windows 7.” Why? Windows Vista and Windows 7 have features which provide more protection against autorun’s ability to spread malware.

3. Consider encrypting all company-owned flash drives.

4. Enforce (or develop) USB flash drive-related policies. Also consider mentioning the dangers of USB flash drives in company training. No matter how technology-savvy your employees may seem, no company is immune to human error. The Department of Homeland Security (http://gcn.com/articles/2011/06/30/dhs-test-found-thumb-drives-disks-network.aspx), for example, found that 60% of USB drives (deliberately planted in places like federal agency parking lots) were inserted into company computers after they were picked up by unsuspecting workers. This number skyrocketed to a whopping 90% when the USB drives had the Department of Homeland Security logo. Many times, your biggest weakness might not be a malicious insider, but an employee who simply doesn’t understand the potential security risks of their actions.

5. Lastly, give Data Loss Defender a try. This is a little-used tool in LogRhythm which can help you monitor and/or prevent the use of USB flash drives (as well as CD/DVD drives).
From Deployment Manager, select:
Tools —> Administration —> Data Loss Defender Policy Manager. From here, you can create a policy which can monitor or eject certain media.

To enable the policy, click on the System Monitor Agents tab, double-click on the agent, and select:

Endpoint Monitoring tab —> Data Loss Defender tab —> Enable Data Loss Defender

After restarting your agent, your policy will be enforced. You should start seeing logs which show the connecting of USB drives…

…and any data which may have been copied to the device:

If you’ve enabled the eject feature, you’ll also receive a confirmation of the ejection:

With these tools, as well as the help of policies and procedures which spell out the proper use of these devices, you’ll be able to take another step closer to a safer corporate network.

The audit trail is the system’s, or at times an application’s, log data. Syslog or Windows event logs or application database tables usually contain this data. It used to be considered “noise” or an unnecessary processing burden. With regulatory and compliance requirements mandating that this “audit trail” be reviewed and maintained (i.e., retained for a specified period of time), SIEM vendors are faced with questions such as “Do we keep what we have or enhance the audit trail to better support our target markets?”. And since the former solution is generally the easiest, that seems to be the most frequent choice that organizations are making. After all, why change what is “working”?

So why aren’t compliance mandates being applied to vendor products? Specifically the audit trail subsystem, which is lacking in most SIEM solutions. When reviewing a SIEM (or any other compliance-related product), don’t overlook this aspect and don’t simply believe that all is good because they “support syslog”. Vendors should ensure their audit trail/log data is readable by almost any means. That it includes the who, what, why, where details, that almost all logs can be tied to a user account vs. system/application account. Moreover, the auditing subsystem should allow for granular tuning to log all or only what is necessary.

Standards for events and log formats are somewhat taking hold, but it will be some time before everyone is on board and adopts this into their products. Some of the above can be achieved through pre-process filtering via scripts or robust syslog daemon, but there should be an “Audit Trail Minimum Requirements Standard” that ensures that any product that has this “seal of approval” can and will log exactly what is needed to better support compliance and simplify the requirement to periodically review these audit trails.