Security, et al

There are a LOT of authentication companies at RSA 2015 this year.  It’s been fun learning the difference between them – and there are big differences.  

Arshad Noor from open source company StrongAuth (South Hall booth 2332), came by the UltimateWindowsSecurity.com booth (South 2240) and briefed me on the relatively new FIDO (Fast IDentity Online) authentication protocols.  FIDO protocols are interesting for a lot reasons but what Arshad said about “user presence” got my attention.  One of my top concerns is how a compromised user endpoint can effectively defeat even the strongest authentication schemes.  (2 Factor, SSO, Federation and Cloud Identity are Awesome but it’s all for Naught if You Leave this One Backdoor Open ) If your endpoint is compromised, malware can wait until you authenticate and then piggy back off that authentication using a host of different methods.  So you have to attack that on 2 different fronts: preventing malware and for really high value operations you need to get reassurance at that moment in time that the user is present and the one initiating that operation.  Just checking for user presence still doesn’t solve for every sophisticated scenario but it gets you a lot closer.  But as with all things security, if you aren’t careful you end up making things so inconvenient for the user that you get in the way of business and asking users to go all the way back through onerous authentication steps at seemingly random times is a great way to get in the way of business.  So that’s why Arshad got my attention when he mentioned “user presence”.  

FIDO makes it easy for an application, including web applications, to reach out to the users FIDO compliant token and ask for real-time user presence verification.  It’s up to the token vendor how to implement this but the example Arshad talked about was a simple token started flashing and LED.  All the user has to do is touch the token to say “yes, I’m here and initiating this transaction”.  Then the token signs the verification response with its private key tied to that application and user and sends it back to the server.  That’s got to be the lightest weight 2^nd factor user presence check I’ve seen.  I’ll be talking a lot more about the risks at the intersection of authentication and endpoint security but if you’d like to learn more about the FIDO protocols visit the FIDO Alliance.    

Dave Pack from LogRhythm dropped in to see me at the UltimateWindowsSecurity.com booth (come see us at booth 2240 South hall) booth here at RSA.  As you know LogRhythm has been sponsoring my real training for free webinars for many years and is one of my favorite SIEMs so I thought I’d do a quick interview to see what’s new at LogRhythm.

Video transcript:

Randy:  Alright, so we’re live here at RSA at the UltimateWindowsSecurity Booth and I got David Pack here.  We’ve done a lot of webinars together in the past on the Windows Security log.  LogRhythm has got an awesome SIEM.  You know how much I love it for a number of reasons.  So what’s new?  What are you guy’s doing?  What’s some big stuff?

David:  Yeah, so what we’re really focusing on is building a workflow to handle the full threat life cycle.

Randy:  Ok.

David:   You know, everything from that initial detection to providing the tools to validate and qualify the detection, moving it into case management where evidence can be gathered and you know, a true, full picture of the story be put together and then ultimately adding on automated response actions to that.  You know, the whole goal is to lower the time to detect these events and then also lower the time to respond to these events, get them identified and cleaned up as quickly as possible.

Randy:  So, you know, what is that that you’re doing?  Are you building, you know, I can take notes and I can add stakeholders to this incident and document what is my resolution?

David:  That’s right.  It’s a fully integrated case management feature within the SIEM and you know, the workflows are, you can add evidence, different types of evidence.  It could be log data, it could be raw logs, it could be attachments, it could be notes.  Add different collaborators in.  You could get to the case from a URL where you add an external collaborator that doesn’t actually have an account with a log in.  You might need HR to come do one specific task.  You can add them and then do their task and move on.

Randy:   Yeah, because what if you’ve got a company that is already using another collaboration tool, like, I hate to use other product names while I’m interviewing a good sponsor friend, but you know, like Asana, Wrike, because you know we are looking at using that kind of stuff, but that’s cool you could just create a new task or project over there if there’s other stakeholders that you don’t want in your SIEM.

David:  That’s right.

Randy:  And just put that URL there. 

David:  Yeah, and there’s an API to integrate and some integration in the works with some of those other popular ticketing and case management type systems that are out there. So we kind of understand we need to play well with other solutions.  This is really supposed to be the start at least of that threat management life cycle.

Randy:  I like that.  So instead of just hey there’s something you need to look at and then you’re on your own.  We’re going to facilitate the whole process because that’s really only the beginning, the alert in the SIEM or that light on the dash board, really that’s just beginning.

David:  That’s right.  What we were seeing, a lot of people were dropping alerts or you know, they’d start working on one and got pulled away to do something else, came back and a different alert may have came in and that initial one kind of was forgot about, so they didn’t really have a place to, alright let’s start a case here, formal workflow, formal collaborators, a place to gather other types of evidence and workflow and pull it all together.

Randy: I like it.  What about knowledge management.  Do you still work in the knowledge engineering area?

David: It’s LogRhythm Labs.

Randy: So, I’m always interested in that because obviously what built UltimateWindowsSecurity and what my folks, my audience is always interested in is how do we interpret log data and you guys have made such a big investment over the years with a whole department devoted to getting that knowledge and codifying it inside a log rhythm.  So, I’m always interested in hearing what’s new there.

David: So that’s still happening.  That’s just an ongoing investment, you know, we write all the parsing and normalization rules.  That’s really what enables our real time analytics engine to do its job, basically adding structure to all its log data.  So that’s an ongoing thing, something we always do for everything that can generate a log out there.  The other half of LogRhythm Labs is really focused on the security analytics, the actual analytic rules that are finding bad things that are happening.  So one of the things we’ve recently done is developed what we call a security analytics co-pilot service where we will help organizations get these analytical modules properly deployed in their environment, up and running.  We will have periodic check-ins to help them understand what is the meaning when this alert fires.  We’ll give them some recommended actions to take.  Okay, you might want to joule down on the impacted hose and then pivot off to this user and really kind of be their analytics co-pilot, help them get the most they can out of all the content that Log Rhythm Labs is producing.

Randy:  That’s cool.  You know, the fact that you guys, I know that I always harp on this, but it’s still, I think, core to what makes LogRhythm what it is and it’s the normalization and categorization, but here’s the thing that always gets me.  Alright, parse as many log sources as you can, but when you come up with a threat signature, you don’t have to write that threat signature for every log source out there that produces those kind of events, right?

David: That’s right.  

Randy:  Can you just explain how the fact that the events are normalized allows you really write that threat signature criteria or rule one time?

David: Right, so you know, so all of these rules are basically working against the normalized layer of data, LogRhythm terminology.

Randy: A log on is a log on is a log on.

David: A log on is a log on.  Every log that comes through the system is identified and what we call a common event, where a log on is a log on regardless of the operating system or the application.  So the rule might say, you know, X number of failed logons followed by logons, so classic use case, but because we’re normalizing everything across the board, it works against everything.

Randy:  Yeah, yeah, that’s cool.  Well, I love that.  I also love the fact, let me just put a plug in for my software company LogBinder.  You guys have integrated and normalized the events that our software LogBinder generates from SharePoint, SQL Server and Exchange right into the rest of everything else that LogRhythm can show you.  And so, we’ve got some customers in common that are using that to good effect.

David:  Absolutely, yeah, yeah it’s great data for SOC to have or an IT organization to have access to and it’s pretty difficult to get to work without a product like yours, you know, working with a product like ours.

Randy:  Yeah.

David:  It’s a great relationship.

Randy: Some good synergy.

David: A lot of good value there, absolutely.

Randy: Alright, well thanks, I know you have to get back to your booth.  Thanks for coming by, David.

David: Thanks Randy.  Thanks for having me.

If you are at RSA come see me at booth 2240 in the South Hall and LogRhythm is at 1207 South hall.  

Right or wrong, Syslog remains the de facto standard protocol for log forwarding. Every SIEM and log management solution in the world accepts syslog. So frequently you run into the situation of needing to forward Windows events via syslog. But Windows doesn’t support syslog and the “free” forwarders I’ve looked at in the past were just not pretty. Some even written in Java. Ugh. Besides being klunky and hard to configure they weren’t flexible in terms of which event logs they could forward much less which events within those logs.

But SolarWinds has just released a new and completely free Event Log Forwarder for Windows (ELF). ELF takes seconds to download, seconds to install and a minute to configure. Just select the logs you want to forward (below example shows successful and failed logons and process start events from the security log):

ELF runs as a background service and immediately starts sending events out via syslog as you can see here on my syslog server.

I love how easy it is to filter exactly which events are sent. This allows you to filter out noise events at their source – conserving bandwidth and log management resources all the way down the line.

But what if you have many systems that need to be configured to forward events? I took a look at the folder where ELF was installed and found a LogForwarderSettings.cfg file that is very easy to read. Moreover there’s even a LogForwarder.PDF file in the Docs folder that fully documents this settings file. I don’t see anything installation dependent in this file so it looks to me like you could use the ELF GUI Client to configure one installation and then copy LogForwarderSettings.cfg to all the other systems where you want the same behavior.

You can download SolarWinds Event Log Forwarder here http://www.solarwinds.com/register/registrationb.aspx?program=20056&c=701500000011a71&CMP=BIZ-TAD-RFS-ELF_Review-ELF-DL-2015

One of the most frequent complaints I hear from you folks is “We need a SIEM but can’t afford the big enterprise solutions.”  And as a tech-heavy small business owner I truly understand the need for software that installs in minutes and doesn’t require a ton of planning, learning, design and professional services before you start getting results.

Well, I’ve installed SolarWinds Log and Event Manager (LEM) in my lab and I can say that it is all of the above and more.  There’s actually no install of software or provisioning of a server because it’s a prebuilt virtual appliance.  When you download and run the LEM install package it simply unpacks the OVA template.  You just open VMWare or Hyper-V, deploy a new VM from template and point it at the file from SolarWinds.  After it boots up for the first time all you have to do is point your web browser at its DHCP assigned address which you can see in VMWare or Hyper-V.  Answer a few configuration questions such as static IP address and you are up and running.  To start pulling events from your servers click on Ops Center and click on the green plus sign.  We’re talking minutes.

LEM has all the features you need and expect from a SIEM.  And it’s flexible; you can monitor server logs with or without agents and you can also accept SNMP traps and Syslog flows from devices and UNIX/Linux systems. 

LEM is affordable, too.  It starts at $4495 and monitors up to 30 servers.  That’s the total price – no server OS or databases to license much less manage.

Since there’s such a need for affordable SIEM and log management and so many of you in my webinar are still trying get by with free utilities I’ve partnered with SolarWinds to raise awareness about LEM.  Please download it and try it out.  Even if you don’t have a virtualization server, you can still run the virtual appliance with a free desktop virtualization program like VM Player.  

LEM is affordable but it’s not “cheap” software.  LEM is actually one of the few SEIMs out there that implements my #1 feature: normalization and categorization.  LEM understands what events actually mean from each of the many, many log sources it supports.  By that I mean that whether the event comes from Linux, Windows, Cisco or anything other source if it’s a logon event (for instance) it gets parse and categorized as such.  This is important because every log source out there logs the same kind of events but in a different format.  None of us have time to learn all the formats and arcana out there about each log source.  LEM’s normalization makes so many things not only possible but also effortless.  For instance “show me all failed logon events for Randy Smith across all my systems and devices regardless of log source and format”.  Voila!

So, please, take a look at LEM.  Download it here.  

Many organizations are seeing surges in the amount of unstructured data in their environments, even as new data breaches come to light every week. As a result, those organizations face increased audit and regulatory pressure regarding loose access controls over unstructured data that might contain sensitive information such as Social Security numbers, credit card data, health care information and proprietary data.

Download this white paper to discover:

• How unstructured data can lead to increased costs and security vulnerabilities
• A seven-step process for establishing information owners for unstructured data
• A solution that helps automate the complex processes of governing and controlling unstructured data

Click here to download the white paper.

I just wrote a new whitepaper about SQL auditing. 

Security analysts must have meaningful, relevant audit data from the mission critical applications such as SQL Server. Database admins must have no disruptions nor degradation to the performance of the mission critical instances of SQL Server. Beginning with SQL Server 2008,versions of Microsoft SQL Server offer a new, superior SQL audit capability custom-built to meet demands.... 

...to continue reading over at LOGbinder.com click here.

This article was first published in EventTracker’s EventSource Newsletter:http://www.eventtracker.com/newsletters/auditing-file-shares-windows-security-log/#open

Over the years, security admins have repeatedly ask me how to audit file shares in Windows.  Until Windows Server 2008, there were no specific events for file shares.  About the best we could do was enable auditing of the registry key where shares are defined.  But in Windows Server 2008 and later there are 2 new subcategories for share related events:

• File Share

• Detailed File Share

File Share Events

The good news is that this subcategory allows you to track the creation, modification and deletion of shared folders (see table below).  You have a different event ID for each of those 3 operations.  The events indicate who made the change in the Subject fields and provides the name of the share users see when browsing the network and the patch to the file system folder made available by the share.  See the example of event ID 5142 below.

A network share object was added.

Subject:
  Security ID:  W8R2\wsmith
  Account Name:  wsmith
  Account Domain:  W8R2
  Logon ID:  0x475b7

Share Information:
  Share Name:  \\*\AcmeAccounting
  Share Path:  C:\AcmeAccounting

The bad news is the subcategory also produces event ID 5140 each and every time a user connects to a share.  The data logged, which includes who accessed it and their client IP address, is nice but the event is logged much too frequently.  Since Windows doesn’t keep network logon sessions active if no files are held open you will tend to see this event a lot if you enable “File Share” audit subcategory.  There is no way to configure Windows to produce just the share change events and not this access event as well.  Of course that’s the point of a log management solution like EventTracker which can be configured to filter out the noise. 

Detailed File Share Events

Event ID 5140, as discussed above, is intended to document each connection to a network share and as such it does not log the names of the files accessed through that share connection.  The “Detailed File Share” audit subcategory provides this lower level of information with just one event ID – 5145 which is shown below.

A network share object was checked to see whether client can be granted desired access.

Subject:
  Security ID:  SYSTEM
  Account Name:  WIN-KOSWZXC03L0$
  Account Domain:  W8R2
  Logon ID:  0x86d584

Network Information:
  Object Type:  File
  Source Address:  fe80::507a:5bf7:2a72:c046
  Source Port:  55490

Share Information:
  Share Name:  \\*\SYSVOL
  Share Path:  \??\C:\Windows\SYSVOL\sysvol
  Relative Target Name: w8r2.com\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\Machine\Microsoft\Windows NT\Audit\audit.csv

Access Request Information:
  Access Mask:  0x120089
  Accesses:  READ_CONTROL
     SYNCHRONIZE
     ReadData (or ListDirectory)
     ReadEA
     ReadAttributes

Access Check Results:
  READ_CONTROL: Granted by Ownership
     SYNCHRONIZE: Granted by D:(A;;0x1200a9;;;WD)
     ReadData (or ListDirectory): Granted by D:(A;;0x1200a9;;;WD)
     ReadEA: Granted by D:(A;;0x1200a9;;;WD)
     ReadAttributes: Granted by D:(A;;0x1200a9;;;WD)

This event tells identifies the user (Subject fields), the user’s IP address (Network Information), the share itself and the actual file accessed via the share (Share Information) and then provides the permissions requested and the results of the access request.  As you can see this event actually logs the access attempt and therefore you will see failure versions of the event as well as success events. 

But be careful about enabling this audit subcategory because you will get an event for each and every file accessed through network shares – every time the application opens the file.  That can be much more frequent than you’d imagine for some applications like Microsoft Office.  Conversely, remember that this category won’t catch access attempts on the same files if a locally executing application accesses the file via the local patch (e.g. c:\docs\file.txt) instead of via a patch. 

Instead you might want to consider enabling auditing on individual folders containing critical files and using the File System subcategory.  This method allows you to be much more selective about who, which files and what types of access are audited.

For most organizations I suggest enabling the File Share subcategory if it’s important to you to know when new folders are shared.  But you will probably want to filter out all those occurrences of 5140.  Then if you have file level audit needs, turn on the File Access subcategory, identify the exact folders containing the relevant files and then enable auditing on those folders for the specific operations (e.g. Read, Write, Delete) necessary to meet your audit requirements.  Don’t enable the Detailed File Share audit subcategory unless you really want events for every access to every file via network shares.

There are 5 different ways you can logon in Windows.  We call them logon types.  The Windows Security Log lists the logon type in event ID 4624 whenever you logon.  Logon type is what allows you to determine if the user logged on at the actual console, via remote desktop, via a network share or if the logon is connected to a service or scheduled task starting up.  The logon types are:

 There are a few other logon types recorded by event ID 4624 for special cases like unlocking a locked session but these aren’t real logon session types.　

Knowing the session type in logon events is great but you can also control users’ ability to logon in each of these 5 ways.  A user account’s ability to logon is governed by 5 user rights found in group policy under Computer Configuration/Windows Settings/Security Setting/User Right Assignments.  There is an allow and deny right for each logon type. In order to logon in a given way you must have the corresponding allow right.  But the deny right for that same logon type takes precedence.  For instance, in order to logon at the local keyboard and screen of a computer you must have the "Allow logon locally" right.  But if the "Deny logon locally" right is also assigned to you or any group you belong to, you won’t be able to logon.  The table below lists each logon type and it’s corresponding allow and deny rights.

Logon rights are very powerful.  They are your first level of control – determining whether a user can access a given system at all.  After logging in of course their abilities are limited by object level permissions.  Since logon rights are so powerful it’s important to know if they are suddenly granted or revoked and you can do this with Windows Security Log events 4717 and 4718 which are logged whenever a given right is granted or revoked respectively.  To get these events you need to enable the Audit Authentication Policy Change audit subcategory.

Events 4717 and 4718 identify the logon right involved in the "Access Granted"/"Access Removed" field using a system name for the right as shown in corresponding column in the table above.  The events also specify the user or group who was granted or revoked from having the right in the "Account Modified" field.

Here’s an example of event ID 4717 where we granted the "Access this computer from the network" to the local Users group.　

System security access was granted to an account.
Subject:
　　 Security ID:　 SYSTEM
　　　 Account Name:　 WIN-R9H529RIO4Y$
　　　 Account Domain:　 WORKGROUP
　　　 Logon ID:　 0x3e7

Account Modified:
　　 Account Name:　 BUILTIN\Users

Access Granted:
　　 Access Right:　 SeNetworkLogonRight

There’s just one problem.  The events do not tell you who (which administrator) granted or revoked the right.  The reason is that user rights are controlled via group policy objects.  Administrators do not directly assign or revoke user rights on individual systems; even if you modify the Local Security Settings of a computer you are really just editing the local group policy object.  When Windows detects a change in group policy it applies the changes to the local configuration and that’s when 4717 and 4718 are logged.  At that point the user making the change directly is just the local operating system itself and that’s why you see SYSTEM listed as the Subject in the event above.

So how can you figure out who a granted or removed the right?  You need to be tracking group policy object changes is a topic I’ll cover in the future.

This article was first published in EventTracker’s EventSource Newsletter: http://www.eventtracker.com/newsletters/using-dynamic-audit-policy-to-detect-unauthorized-file-access/

One thing I always wished you could do in Windows auditing was mandate that access to an object be audited if the user was NOT a member of a specified group.  Why?  Well sometimes you have data that you know a given group of people will be accessing and for that activity you have no need of an audit trail. 

Let’s just say you know that members of the Engineering group will be accessing your Transmogrifier project folder and you do NOT need an audit trail for when they do.  But this is very sensitive data and you DO need to know if anyone else looks at Transmogrifier. 

In the old days there was no way to configure Windows audit policy with that kind of negative Boolean or exclusive criteria.  With Windows 2008/7 and before you could only enable auditing based on if someone was in a group not the opposite.

Windows Server 2012 gives you a new way to control audit policy on files.  You can create a dynamic policies based on attributes of the file and user.  (By the way, you get the same new dynamic capabilities for permissions, too). 

Here’s a screen shot of audit policy for a file in Windows 7.

Now compare that to Windows Server 2012.

I have a new technical brief titled "Who, What, When, Where and Why: Tracking the 5 W's of Change in Active Directory, SharePoint, SQL Server, Exchange and VMware".

Your organization relies on you to prevent and detect tampering, unauthorized access or human error to your key enterprise technologies, including: Active Directory, SharePoint, SQL Server, Exchange and VMware.

In this brief, Windows security expert Randy Franklin Smith explores the 5 W's of auditing critical changes to your core technologies by discussing:

• The types of activities that you can audit
• How to enable auditing and where to find audit data
• The hidden gaps, caveats and weaknesses of built-in auditing tools
• How ChangeAuditor from Dell Software fills the gaps in auditing

You’ll come away with a better understanding of the limitations and capabilities of native auditing tools and why a third-party solution might be the best approach to protect your systems, data and your company’s productivity and bottom line.

Click here to read more.