Security, et al

Randy's Blog on Infosec and Other Stuff

Always Enable Auditing - Even for Logs and Systems You Don’t Actively Review

Mon, 19 Mar 2012 12:48:29 GMT

I have 2 rules of thumb when it comes to audit logging.  First, if it has a log I recommend enabling it – as simple as that.  The only exceptions are prohibitively verbose logging options associated with debugging or the surprisingly rare case where logging has an impact on performance.  Second, if you can collect the log and archive it with your log management/SIEM solution, do it - even if you don’t set up any alert rules or reports. 

I’ve repeatedly seen the value following these 2 rules for several reasons.  First, you really never know what audit log data will be valuable in a forensics situation and there is no way to reconstruct log data after the fact.  Enable auditing beforehand or forever hold your peace.  The most obscure or seemingly unimportant systems and applications may end up being crucial to determining the extent or root vector of an intrusion or critical to building your case in insider investigations.  One time I was called upon to help document a case of inappropriate behavior by a user and the client program for a popular Internet provider who at the time provided a log which proved very helpful in showing the user accessed certain forums at specific times linked to the actions being investigated.

Security events that you don’t necessarily monitor and respond to may also be valuable in providing documentation that you performed certain actions when necessary as part of a compliance related matter.  For instance in my standard audit recommendations for Active Directory I suggest auditing and archiving events related to the disabling and deletion of accounts and group membership removals.  There is typically no need to review these events but when the auditor comes around you can use them to document that you removed access in response to changes in employee status and role.

Finally, audit logs even if not reviewed can serve as a powerful deterrent against malicious actions and policy violations by end users and administrators alike.  If they know that their actions are being recorded and can be looked up and used against them in the future they will be much less likely to take chances.  But that’s only true if the audit logs are collected an archived to a system separate from the people being monitored.  Otherwise, especially in the case of administrators, logs a vulnerable to deletion or tampering.

What are some common logs that you should consider enabling and if possible adding to your log management process for collection and archival besides the obvious candidates like your domain controller security logs?  First and foremost, I strongly recommend you enable appropriate auditing on member servers and at least securely archiving them with your DC logs.  Many of the most critical security events on your network are only caught by your member servers.  This would include attempts to break into member servers with local accounts, security configuration changes, programs executed and files accessed.  Then like I stressed in last month’s article there is a wealth of security information in your workstation security logs.  I understand that you have a lot of workstations and it may be a challenge to collect and archive that many logs and that amount of data, but at least enable auditing on those workstations.  Set maximum log size to 300MB and chances are the audit data will be there when you need it even if you aren’t centrally managing them.

Besides the Windows security logs of all your systems, what are other good candidates for logging?  I highly recommend enabling DHCP server logging because many other security logs list the IP address but no other information to identity to identify the client.  If you have your DHCP logs you can look up that IP address and date and time against the lease events to figure out the MAC address and likely the computer name of the system that had that IP address at the time the event was recorded.  If you use RRAS (Routing and Remote Access Server) be aware that it has client authentication and connecting logging capabilities which record important events not sent to the Windows security log.  The same goes for IIS.  IIS can log every incoming request to any web based application you host including URL, verb, result code, client IP address and more.  This is critical for tracking down attacks against your website and other web based applications.  More and more companies are beginning to store and process security and compliance critical information in SharePoint and SharePoint too has an audit log capability.  Exchange 2010 has a new non-owner mailbox activity log and a new administrator audit log.  VMWare has an audit capability that is critical to ensuring accountability over your virtualization infrastructure.  SQL Server 2008 has a new audit log too.  Even Microsoft Dynamics CRM 2010 has an audit capability. 

 It seems like every software vendor is seeing the need to provide audit trail capability which is good news for information security but it also means we need to learn how to at least turn on these new audit features and ensure we don’t inadvertently consume too much storage or other resources.   And remember, there’s good reason to enable auditing even if you aren’t regularly reviewing or monitoring the logs.  If at all possible get these logs out of the systems and applications where they are generated and into your separate and protected log management/SIEM solution so that the integrity of these audit trails in ensured.  Follow these steps and chances are you will score points in the future when you can explain who did what and when they did it!

email this digg reddit dzone
comments (0)references (0)

Related:
New Features in LogRhythm 4.0 Deserve a Place on Your Short List
Virtualization Security: What Are the Real World Risks?
Always Enable Auditing - Even for Logs and Systems You Don’t Actively Review
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log

The Year I Started Being Afraid

Mon, 12 Mar 2012 13:53:34 GMT

Originally published at Lumension.com
http://blog.lumension.com/4675/the-year-i-started-being-afraid/


I’ve been in IT since I was a kid. I was a real, stereotypical nerd. While other computer nerds were learning to program games, I turned up my nose at their childish efforts and learned database programming because at 12 I actually wanted to write accounting software. I know, I know, weird. Anyway I say this to underline the fact I’ve been in technology since PC’s first came out and business technology at that.

When the Internet and Windows NT got big in the nineties I switched from development to security – so I’ve been there. But except for a brief period when I got my first constant connection to the Internet, I haven’t been afraid. I’ve respected the risks of the Internet and the danger from the bad guys on it but I’ve never been paranoid like many of my other colleagues in infosec. I’ve always taken sensible measures, ran AV most of the time, kept my attack surface small and monitored my logs. And I’ve only had 2 security incidents over that time. I got the “Ethan Frome” Word virus which was harmless and after that my Windows 2000 based IIS web site suffered SQL injection once which broke some drop down lists on the site.

Then Things Started to Change

So, I’ve always felt pretty safe with my informed, common sense approach. But last year that started to change. Part of it is because my business is growing. More people are on my network. More endpoints connect to my network. There’s more to protect. Part of it is the accelerating sophistication of bad buy technology. Malware is getting more sophisticated and beginning to outpace signature based detection. The bad guys’ work in content related vulnerabilities is outflanking us by going beyond OS and penetrating us via PDFs, JPGs, Flash files, ad nauseam. But the biggest part I think is that that bad guy of the last few years is a new and different bad guy.

It used to be loosely organized nihilistic antisocial kids defacing web sites sometimes for ostensibly social causes but sometimes for the pure nihilism of it. Or, in other instances, it was “security researchers” trying to make a name for themselves or their companies. And the scenarios I would describe in my security and audit classes where just that – theoretical scenarios about would could happen in theory. But when pressed for real examples and anecdotes, I usually came up short. It was more like “this is what could happen if we were in the middle of a Mission Impossible movie.”

But today, Mission Impossible scenarios are happening all the time. The biggest, most respected name in strong 2-factor authentication gets hacked. Then a major defense contractor apparently gets hacked as the fruits of the first attack.

The bad guys are now financially and politically driven. What are more powerful motivators than that? What can gather greater resources and stimulus than money and power? Religion is the only thing I can think of. But money and power are more than enough for now.

So I’m now taking information security more seriously for my business than I ever have before. And while it’s tempting to think about my little datacenters out there exposed to the Internet 24/7 or the data in the few cloud services we use, what keeps me awake at night – well, I’m not really at the point of losing sleep, but let’s say if I did wake up at night and start thinking about the security of my business – is endpoints.

Time to Worry About Your Endpoints

Endpoints worry me. There’s so many. They are so exposed. Endpoints process so much content directly from the Internet. And so intimately – a file server or a SharePoint site may store files from the Internet but it’s on the endpoint where they are actually parsed and rendered. (To be accurate, and while not extremely common, SharePoint servers are getting pretty intimate with content today given how Visio, Access and Excel is actually parsed, rendered and manipulated by SharePoint, within SharePoint itself.) And the bad guys know this. The endpoint is the initial target of APTs.

At least I realize this. Too many folks in management, IT, infosec and Internal Audit, still have the mainframe philosophy superimposed on servers: “all my data is on my server so I need to protect my server. Endpoints aren’t that important because that isn’t where the data resides.”

I’m preaching to the converted when I say “Wrong”, right? Let’s just put aside the reality there is confidential, sensitive data out there on nearly every laptop, workstation and smartphone. Let’s just assume for a minute that no important data is on a given endpoint.

Doesn’t matter. That laptop or other endpoint is still part of your trusted computing base and if it gets compromised, you’re in trouble. After all, I don’t think anyone believes the seed codes for SecurID tokens or anything else proprietary about SecurID technology was on the endpoint initially hacked at RSA when that poor employee opened the intriguing email about next year’s recruiting plan. But that’s where it started and we all know where it ended.

The security of your endpoints – of all our endpoints – is more than important – it’s critical. And I’m going to put some real effort into endpoint security this year. I hope you do too.

 

Originally published at Lumension.com
http://blog.lumension.com/4675/the-year-i-started-being-afraid/

email this digg reddit dzone
comments (0)references (0)

Related:
Virtualization Security: What Are the Real World Risks?
SolarWinds Log & Event Manager Includes My Favorite Feature in a SIEM…
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
Automating Review and Response to Security Events

previous | next

powered by Bloget™

Search


Categories
Recent Blogs
Archive