Event Auditing and Logging

When something happens inside of a network, certain administrators and other interested parties might want to know what that something was. Without event auditing and logging enabled, those people wont be able to. In this post I want to describe some basics about event auditing and logging, some good practices as well as some proper configuration techniques in Windows environments. I plan to discuss other systems in future posts (a key concern being Unix systems and databases).

What is Event Auditing and Logging

Event auditing and logging, when properly configured, is essentially similar to having a properly installed camera surveillance system monitoring a bank. Of course, the camera system is only useful for real time monitoring if it is not connected to a recording device. The same circumstances are true in any computer system. The cameras can be pictured as the various logging sub-services in the various networked computers while the aggregate logging server and associated backup system can be pictured as the monitoring control room and recording devices.

Extending this metaphor, computer system controls over the logging sub-services should be as tamper-proof as possible (similar to the closed circuit monitoring system). Controls should also be placed over the "control room" (in this case the aggregate logging and reporting server). Only authorized individuals should be able to access this server, and even they shouldn't be able to edit the logs. Logs should be properly stored into a read-only storage device much like the recording devices in the control room.In large entities, considerations have to be made of aggregating even larger numbers of logs across wider geographic areas. In these situations, the "control room" might actually be a true control room with its own dedicated server sub-systems and controlled network access to ensure only authorized individuals can enter the room (reducing the chance that a log could be tampered with).

How the various logging services are configured and how the aggregate server is set up is a matter of employing multiple good practice security settings throughout the organization and its various systems in use.

Implementation

An initial gut reaction might be to turn on every setting related to security events and activity auditing within the environment and hope for the best, but a measured approach is necessary. An organization has a finite amount of available time, computing power, and storage space. The more logging that is enabled the more the logging activity uses all three of these things.

A proper response is to perform a risk assessment where the likelihood of a negative event happening and its impact is compared against the cost of implementing logging controls related to that event. Ultimately, the fewer resources that are available to an entity, the fewer logs that are going to be kept, and those that are kept need to be of the highest value (i.e., should the camera be aimed at the vault door or parking lot?).

The first step is to determine which assets are the highest values. Items of considerable note include servers hosting the primary business management core or enterprise resource management system; servers placed at the network perimeter (since they will be hit first by an external attack); and servers used to store personally identifiable information of customers. These servers should be the first servers to be considered for event logging.

Once high-value assets are determined, events that are the best indicators of negative activity or attacks within the network and on systems should be determined. A specific discussion of each major operating system and database system's event codes is beyond the scope of this post; however, I hope to do posts on each system in the future.

Below I list some basic good practice recommendations for Windows environments that I feel represent a good trade off between cost of the logging versus the risks associated with events that can be detected.

Windows Security and Audit Events

Windows security and audit events can be enabled for all servers and computers within the Active Directory domain of the entity through the use of group policy settings. An important note regarding the use of group policy: activating auditing across the entire domain by configuring auditing within the default domain policy is risky due to the volume of logs created. Also, log aggregation needs to be configured to safeguard the logs (which is simplified in current Windows Server 2012 environments). These group policy settings will not propagate to perimeter systems and should instead be loaded manually onto all perimeter servers (since perimeter systems should not be members of the domain).

I pulled these good practice recommendations out of the Microsoft Security Monitoring and Attack Detection Planning Guide which is an excellent write up of how to configure a Windows environment properly.

• Audit account logon events for success (failure auditing could cause a Denial of Service situation if an attacker attempts to logon repeatedly through a script).
• Audit account management for success and failure (successful modifications to accounts should tie to authorized requests).
• Audit directory service access should only be done if properly configured system access control lists have been developed.
• Audit policy change for success and failure (again, tie successes to authorized changes and failures should be immediate cause for suspicion).
• Audit privilege use should not be done due to its high volume and low value.
• Audit process tracking should only be done if authorized program lists have been developed. Further, this should only be activated on truly high value assets that are not web servers, test computers, or batch processing servers.
• Audit system events for success and failure (these events can be used to trace malicious installs or other system related security events).

Conclusion

Event auditing and logging should be thought of much the same way as a surveillance system is used at a bank. Proper setup of tamper-proof cameras, a monitoring room, and recording devices are crucial to ensure the proper security of the bank. The same is true for monitoring within a networked computer system. Logging should be enabled and protected from unauthorized users. Logs should be aggregated and monitored for real time attack detection. Logs should be backed up and stored for future forensic analysis in the event of an attack. Which assets that are protected should be based on a risk assessment weighing the entity's available resources against the potential losses resulting from events that go undetected.

With proper configuration, it is possible to detect and respond to attacks as the occur and have proof of the deeds committed. This will greatly improve system security.

NCUA Releases Distributed Denial-of-Service Mitigation Guidelines

I had the opportunity the other day to help put together a blog piece on our firm's blog. If you are involved in the Credit Union industry at all, I'd advise you check it out!

Virtualization Deployment Planning and Security

Virtualization is a huge hot button issue right now, everyone is jumping in feet first, but just because it is new doesn't mean you should install it in your data centers tomorrow. Yes, virtualization could save the federal government up to $30 billion by 2015 (as reported by MeriTalk), and yes, VMWare sponsored research shows significant decreases in operational expenses by those that adopt virtualization technologies. Virtualization could save you a lot of money, which is always nice for strained IT department budgets.

But, without a plan, without identifying risks, and without the proper knowledge at your disposal, none of those savings will ever materialize.

Planning and Identifying Risks

By planning, I don't just mean deciding between Microsoft Hyper-V technology and VMWare ESXi. Virtualization has a whole set of new risks and security concerns that need to be muddled through. If you don't consider these risks and plan for them, your virtualization implementation will fail or worse, appear to succeed until it hacked to pieces by a passing Script Kiddie.

By far the most significant risk to a virtual environment is the consolidation of hosts into one physical layer where one point of failure may be the new lynch pin in you operation. Imagine, for a moment, if a hacker managed to socially engineer one of you admin's passwords or use one of those exploits you've been meaning to patch. Then imagine the hacker taking a nice stroll through your hypervisor. What will he or she find? Well now that he has access to the host layer, he can easily dig into the guest operating system's files or even take them over, or copy them for offline analysis.

Secondarily to the security risk is the operational risk of consolidated servers. What if that shiny new server you just purchased craps out on you due to a faulty install or faulty manufacturing, then what happens to all the virtual servers you just lit up? They all die, with all the business applications on them. Sure, you'll be able to get them back up pretty quickly on a different server (hence the power of virtualization, right?), but the business owners will not pleased with the loss of availability and possibly missing SLAs.

Solutions

Virtual machines require the same sort of security as physical machines, including separation when required. It's important to note that you don't want to over-virtualize; this is where new virtual environments are being created when current servers could easily handle any additional functionality needed (just because it is easy to clone a new machine, you shouldn't necessarily always do it - the more operating systems in a network environment, the more chances for one to be configured incorrectly or become out of date).

As you can see, controls over virtualization are similar to traditional security controls, just with a little twist:

• Control change - only designated virtual machine administrators should be adding, creating or modifying virtual machines (even test machines should be controlled appropriately).
• Put standards in place (such as policies and procedures) - all virtual machines should be created equally based on baselines, and they should be maintained to the same standards throughout their business life.
• Physical separation - virtual machines may be able to communicate within the physical host even when configured properly - i.e., puting your DMZ and your back-end database in the same host isn't a good idea (check out some research describing hacks through a vSphere 5.0 to the host - Aidan Finn has a nice summary here).
• Segregation of duties - determine how to handle segregation of duties between system administrators, security administrators, developers and users. Virtual environments, if configured improperly, can allow any one of these groups to potentially gain access to data they shouldn't.
• Monitor, monitor monitor - can't stress this enough. Make sure the right tools are in place to ensure all communication is monitored. Virtual infrastructures allow for the creation of virtual networks that never leave the host. These networks still require firewalls, sniffers, intrusion detection, etc. Virtual monitoring tools need to be installed in every host to ensure you know what is going between your servers.

Conclusions

Virtual infrastructure needs to be understood by everyone (security admins, system admins, developers, and management) so that everyone understands the risks that are different from physical servers. Once everyone understands the risks, the proper preventive and detective controls need to be put in place to provide the same level of security as with physical servers.

This post was inspired by an ebook article at SCMagazine.com called Virtualization posted January 24,2013 (find original posting here).

Hello World!

Well, I've officially set up a blog...

And, I figured I'd start it off with a little introductions. My name is Blake R. Waud, I am a Certified Public Accountant working through my third year in the field. About a year ago, I began to move into the IT Audit group of my firm (specifically the IT Assurance and Security group). I am so far extremely happy with this move, IT auditing is so much more rewarding to me than financial statement auditing (where you basically tick and tie the numbers out).

Don't get me wrong, financial statement audits are important and serve a very specific public function that needs to be fulfilled, I just don't like doing it that much. I am not sure what it is, but I always get exhausted when I perform financial statement audit stuff.

Now, IT Audit, that's where things get interesting. This field is changing non-stop, I've been in it almost 2 years now and it's already radically different than when I first started. I love the challenge all the information poses and I further love the people. Maybe they are just the kind of people I've always got along with the best, but IT professionals just click with me.

I love to go into their areas, see how they work, see where I can help, and see where I can learn from them (yes I learn something from every client I visit - it is imperative to me actually that I do).

But, now that I've been doing this awhile, it is time to dig into my real passion - IT Security. I love security, and I am even more passionate about white hat side of it all. My goal is to become a respected ethical hacker/penetration tester in the field with a strong business background so that I can bring unique perspective.

To that end, I have begun to develop my personal brand, and this blog is part of that effort.

This blog will be a collection of information that I have learned and synthesized. I will post helpful recommendations and basic info that I have picked up along the way. Not only will this be available to everyone who reads this blog (and I do hope it helps some people), but it will help me know where I have come from and help me remember and find things I have researched.

So, without further ado...