Security, et al

Randy's Blog on Infosec and Other Stuff

SolarWinds Makes It Easy to Detect SharePoint Breaches with Integration to LOGbinder SP

Mon, 07 Jul 2014 08:40:59 GMT

SolarWinds Log and Event Manager provides connectors for common log sources that understand how to translate raw events from a specific log source into their equivalent normalized event type.  I love event normalization like SolarWind’s LEM because it makes it so much easier to correlate events from multiple sources and to configure more generalized alerts, filters and reports.  For instance you can just ask for all logon failures without having to configure criteria for every example of logon failure logged by Windows, Linux, firewalls, etc.  That’s the power of normalization. 

SharePoint security is getting more and more attention because of the amount of sensitive unstructured data found there.  And with SharePoint’s self-service features sensitive data just keeps growing as end-users create more and more content.  In this age of Snowden-like information grabs it’s really important to detect unusual activity in SharePoint. 

But getting SharePoint logs into any SIEM is not a simple matter.  SharePoint audit logs are trapped inside SharePoint itself; there’s no log file or event log that a SIEM can consume through normal means.  Happily SolarWinds partnered with LOGbinder and has done an awesome job integrating with LOGbinder SP.  LOGbinder SP is an easy-to-deploy middleware purpose built to pull raw audit events out of SharePoint, translate all the cryptic codes and ID numbers and then export understandable audit logs which can be easily consumed by SIEMs through normal log collection means. 

Not only did SolarWinds create the necessary connector to consume SharePoint audit events from LOGbinder.  But as a SIEM Synergy Partner, SolarWinds took my recommended reports and alert specs for SharePoint and implemented them in a set of Filters, Rules and Reports for Log and Event Manager.  All you have to do is point Log and Event Manager at LOGbinder SP’s event log and you’ve got real-time monitoring and historical analysis of the Share Point security activity.  

Check out the screen print below showing SharePoint permission changes in Log and Event Manager.

And below is an example report showing document deletions in a SharePoint Document Library.

Here’s a list of some of the things in SharePoint you can automatically monitor or detect with Log and Event Manager:

  • Access control changes on documents and lists

  • Administrator changes

  • Group membership changes

  • Audit policy changes

  • Audit log tampering

  • Import/Export of Data

  • Item deletions

  • Who’s been viewing sensitive documents

SolarWinds did a great job implementing our monitoring and reporting recommendations, but thanks to Log and Event Manager’s (LEM) event normalization you can also correlate SharePoint audit events with similar audit activity from other log sources.  For instance you can search on a given user and see their activity as reported by SharePoint, Active Directory and any other log sources managed by LEM.  To learn more about LEM’s normalization and other features check out this blog or download Log and Event Manager here  You can download a trial of LOGbinder SP from and the integration pack for LEM and LOGbinder SP here  Try them out!

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

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

Monitoring File Permission Changes with the Windows Security Log

Mon, 05 May 2014 16:21:00 GMT

Unstructured data access governance is a big compliance concern. Unstructured data is difficult to secure because there’s so much of it, it’s growing so fast and it is user created so it doesn’t automatically get categorized and controlled like structured data in databases. Moreover unstructured data is usually a treasure trove of sensitive and confidential information in a format that bad guys can consume and understand without reverse engineering the relationship of tables in a relational database.
Most of this unstructured data is still to be found on file shares throughout the network and file system permissions are the main control over this information. Therefore knowing when permissions change n unstructured is critical to governance and control. File permissions should normally be fairly static but end-users are by default the owner of files and subfolders they create and can therefore change permissions on those files. And of course administrators can change permissions on any object. Either way you need to know when this happens and I’m going to show you how with the Windows Security Log.
First we need to enable the File System audit subcategory. You’ll find this policy in any group policy object under Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies\Object Access. Enable File System for success. (By the way, make sure you also enable Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Audit: Force audit policy subcategory settings to override audit policy category settings to make sure your audit policy takes effect. Now you need to enable object level auditing on the root folders containing your unstructured data. For instance if you have a shared folder called c:\files, go to that folder in Windows Explorer, open the security tab of the folders properties, click Advanced and select the Auditing tab. Now add an entry for Everyone that enables successful use of the Change permissions as shown below.
At this point Windows will begin generating 2 events each time you change permissions on this folder or any of its subfolders or files.  One event is the standard event ID 4663, “An attempt was made to access an object”, which is logged for any kind of audited file access like read, write, delete, etc.  That event will show WRITE_DAC under the Access Request Information but it doesn’t tell you what the actual permission change was.  So instead, use event ID 4670, “Permissions on an object were changed”, which provides the before and after permissions of the object under Permissions Change as shown in the example below.
I know what you are thinking. “What does D:AI(A;ID;FA;;;AU)(A;ID;FA;;;WD)(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1200a9;;;BU) mean?” That my gentle reader is the original access control list of asdf.txt but in the very cryptic Security Descriptor Definition Language (SDDL). SDDL definitely isn’t something you want to manually parse and translate on a regular basis. But you can when necessary.
Look for the “D:” which is close to the beginning of the string or even the very beginning in this case. “D:” means Discretionary Access Control List (DACL) which are the actual permissions on the object as opposed to other things that show up in a security descriptor – like owner, primary group and the audit policy (aka SACL). Until you hit another letter-colon combination like “S:” you are looking at the object’s permissions. An ACL is made up of Access Control Entries which correspond to each item in the list you see in the Permissions tab of an object’s properties dialog. But in SDDL before listing the ACEs comprising the ACL you will see any flags that affect the entire ACL as a whole. In the example above you see AI as the first element after D:. AI stands for SDDL_AUTO_INHERITED which means permissions on parent objects are allowed to propagate down to this object.
Now come the ACEs. In SDDL, each ACE is surrounded by parenthesis and the fields within it delimited by semicolons.  The first ACE in the event above is (A;ID;FA;;;AU). The first field tells you what type of ACE it is – either A for allow or D for deny. The next field lists any ACE flags that specify whether this ACE is an inherited ACE prorogated down from a parent object and if and how this ACE should propagate down to child objects. The only flag in this ACE is ID which means the ACE is in fact inherited. The next field lists the permissions this ACE allows or denies.  In this example FA stands for all file access rights.  The next 2 fields, Object Type and Inherited Object Type, are always blank on file system permissions (hence the 3 semicolons in a row); they are only used places like Active Directory where there are different types of objects (user, group, computer, etc) that you can define permissions for. Finally, the last field is Trustee and identifies the user, group or special principal begin allowed or denied access. Here you will either see the SID of the user or group if the ACE applies to a so-called “well-known” SID you’ll the corresponding acronym. In this example AU stands for Authenticated Users.
Event ID 4670 does a great job of alerting you when permissions change on an object and telling you which object was affected and who did it. To go further and understand what permissions where actually changed you have to dive into SDDL. I recommend Ned Pyle’s 2-part TechNet blog, The Security Descriptor Definition Language of Love for more information on SDDL.
(This article first appeared as a newsletter on the EventTracker website.)

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

Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
Pay Attention to System Security Access Events
Monitoring File Permission Changes with the Windows Security Log
Why Workstation Security Logs Are So Important

Cool Stuff at RSA

Thu, 13 Mar 2014 12:36:15 GMT

I found some pretty cool stuff at RSA. Some new technologies that I’ve never thought of before and others that are just as fun as they are valuable.

More Fun with Hard Drive Destruction

Fun and an effective solution to a vexing problem – old hard drives full of sensitive information. Garner Products’ booth showed off some epically cool machines to take care of that problem. 
Using a magnet rivalling those in MRIs, the HD-3WXL, can degauss one hard drive every 10 seconds. But even cooler is the PD-5 which physically breaks drives in half.
You have to watch this video– How fun is that? Plus the drive can still be disassembled and recycled as opposed to shredders which create a toxic waste disposal problem.

You Can’t Trace My Packets

My Neat-O-Meter redlined at Dispersive Technologies’ booth when I grasped what they do, which is a new way to securely send information over the Internet. Quantum Encryption you ask?  Ha! That is so passé. The VSV products use a “spread spectrum” approach to breaking data up and sending it over many, unpredictable paths over the Internet as a way to defeat man-in-the-middle attacks. Any given observation point only sees a fraction of the data being transmitted. There’s not many entities that could even begin to try to observe every path (see my Elephants and Irony at RSA post). With VSV products both endpoints securely negotiate and dynamically adjust their use of multiple “deflectors” on the Internet to scramble their data and send different bits of it along completely different paths. Sounds slow? Rob Smith (no relation to yours truly) explained that the endpoints automatically and dynamically stop using deflectors on slow paths and sometimes produce greater throughput than traditional shortest path network.

No More Excuses for Security Unawareness

Finally, we all know that at the end of the day, with every security technology deployed, your weakest link remains the human element. And we all tend to pay lip service to the need for security awareness training. But what do we do about beyond putting up some posters and having new hires sign some documents when they first come in? And how many managers will approve and pay for in-person training sessions which users quickly forget about? How do you increase security awareness and sustain it over the long haul?  That’s what I liked about what I saw at Visible Statement’s booth. Their software integrates with your endpoint with just the right amount of animated security awareness training and supports many different languages.

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

Automating Review and Response to Security Events
The Growing Threat of Friendly Fire from Vendors
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
Virtualization Security: What Are the Real World Risks?

Elephants and Irony at #RSAC

Mon, 03 Mar 2014 14:43:14 GMT

I was amazed when I saw the Beijing Zhongguancun Overseas Science Park (Elephant #1) in the North expo hall.

Beijing Zhongguancun Overseas Science Park
Some folks come out and say it and some use euphemisms but when people talk about APT actors, that boogeyman is commonly regarded as China. At least until Snowden, which brings us to NSA's large booth in the South expo Hall - Elephant #2.
Back to Elephant #1 for a second. "Who knew there were security software companies in China?" - was my question. But attendees are asking "Who would install a highly trusted piece of security software written in China?". Ironic. Being an honest IT security firm in China can't be fun. One gentlemen we breakfasted with confirmed it's an uphill battle.
If that's ironic, then a German colleague's comment is irony2. "Who really wants to buy IT security software from a US vendor after all the Snowden revelations?" Wow, Chinese and American security companies in the same boat? I begin to see the logic behind Germany sponsoring a large pavilion in the north hall spotlighting their country's security firms.
The irony continues when you think about the Chinese-made chips and US-written software running on security appliances on display.
I wonder where all of this will lead or if it will eventually blow over.

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

Automating Review and Response to Security Events
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
The Growing Threat of Friendly Fire from Vendors
Virtualization Security: What Are the Real World Risks?

In search of great technology at #RSAC among all the noise #filtering

Wed, 26 Feb 2014 15:13:44 GMT

Dominant impression: "If you can’t say it, you don’t know it."  So many booths; so little idea of what they do. I know they don’t do everything.

None of us do. Not even the titans of the infosec industry. So one of us: either yours truly or the infosec marketing collective mind is belaboring under a fundamental misconception. And it would be so nice if one of us were disabused of it. This sounds ludicrous as I write it but are companies consciously trying to hide the space in which they play? I can see that there are some disadvantages to be pigeon-holed or typecast. Those are negative terms. But isn’t "targeted" and "qualified" the other, positive, side of that coin?
Here’s a few exhibitors where you can walk up, understand what they offer at a glance and get some real information from someone that understand what their company does and offers. These certainly aren’t the only companies with great technologies but these make it easy for you find them:
  • LogRhythm - Powerful SIEM with a massive investment in "knowledge engineering" and log normalization
  • Lumension - Awesome endpoint security.  Cut every head of the endpoint security medusa with on agent and a single pane of glass
  • STEALTHbits -  Powerful yet affordable technology for data access governance
  • ManageEngine - Affordable, easy-to-use SIEM and other cool solutions like privileged password management
  • SolarWinds - Affordable, easy-to-use SIEM with normalization
  • Dell Software - Staggering array of IAM and GRC technology

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

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

Auditing File Shares with the Windows Security Log

Thu, 02 Jan 2014 15:22:25 GMT

This article was first published in EventTracker’s EventSource Newsletter:

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.

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

Share Information:
  Share Name: 
  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. 


A network share object was accessed


A network share object was added.


A network share object was modified


A network share object was deleted.


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.

  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: 
  Share Path:  \??\C:\Windows\SYSVOL\sysvol
  Relative Target Name:\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\Machine\Microsoft\Windows NT\Audit\audit.csv

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

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.

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

Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
Auditing File Shares with the Windows Security Log
Virtualization Security: What Are the Real World Risks?
Following a User’s Logon Tracks throughout the Windows Domain

Pay Attention to System Security Access Events

Tue, 19 Nov 2013 13:15:50 GMT

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:



Allow right

Deny right


Interactive (logon at keyboard and screen of system)


Allow logon locally


Deny logon locally


Network (i.e. connection to shared folder on this computer from elsewhere on network)


Access this computer from the network


Deny access to this computer from the network


Batch (i.e. scheduled task)


Log on as a batch job


Deny logon as a batch job


Service (Service startup)


Log on as a service


Deny logon as a service


RemoteInteractive (Terminal Services, Remote Desktop or Remote Assistance)


Allow logon through Terminal Services


Deny logon through Terminal Services

 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.
   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.

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

Virtualization Security: What Are the Real World Risks?
SolarWinds Log & Event Manager Includes My Favorite Feature in a SIEM…
Automating Review and Response to Security Events
Security Log Step-by-Step: Avoiding Audit Policy Configuration Pitfalls

Using Dynamic Audit Policy to Detect Unauthorized File Access

Tue, 15 Oct 2013 13:43:49 GMT

This article was first published in EventTracker’s EventSource Newsletter:

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.

The same audit policy is defined but look at the “Add a condition” section.  This allows you to add further criteria that must be met before the audit policy takes effect.  Each time you click “Add a condition” Windows adds another criteria row where you can add Boolean expressions related to the User, the Resource (file) being accessed or the Device (computer) where the file is accessed.  In the screen shot below I’ve added a policy which accomplishes what we described at the beginning of the article.


So we start out by saying that Everyone is audited when they successfully read data in this file.  But then we limit that to users who do not belong to the Engineering group.  Pretty cool, but we are only scratching the surface.  You can add more conditions and you can join them by Boolean operators OR and AND.  You can even group expressions the way you would with parenthesis in programming code.  The example below shows all of these features so that the audit policy is effective if the user is either a member of certain group or department is Accounting and the file has been classified as relevant to GLBA or HIPAA compliance.

You’ll also notice that you can base auditing and access decision on much more that the user’s identity and group membership.  In the example above we are also referencing the department specified on the Organization tab of the user’s account in Active Directory.  But with dynamic access control we can choose any other attribute on AD user accounts by going to Dynamic Access Control in the Active Directory Administrative Center and selecting Claim Types as shown here.

You can create claim types for about any attribute of computer and user objects.  After creating a new claim type for a given attribute, it’s available in access control lists and audit policies of files and folders throughout the domain. 

But dynamic access control and audit policy doesn’t stop with sophisticated Boolean logic and leveraging user and computer attributes from AD.  You can now classify resources (folders and files) according to any number of properties you’d like.  Below is a list of the default Resource Properties that come out of the box.

Before you can begin using a given Resource Property in a dynamic access control list or audit policy you need to enable it and then add it to a Resource Property List which is shown here.

After that you are almost ready to define dynamic permissions and audit policies.  The last setup step is to identity file servers where you want to use classify files and folders with Resource Properties.  On those file servers you need to add the File Server Resource Manager subrole.  After that when you open the properties of a file or folder you’ll find a new tab called Classification.

Above you’ll notice that I’ve classified this folder as being related to the Transmogrifier project.  Be aware that you can define dynamic access control and audit policies without referencing Resource Properties or adding the File Server Resource Manager subrole; you’ll just be limited to Claim Types and the enhanced Boolean logic already discussed.

The only change to the file system access events Windows sends to the Security Log is the addition of a new Resource Attributes to event ID 4663 which I’ve highlighted below.

This field is potentially useful in SIEM solutions because it embeds in the audit trail a record of how the file was classified when it was accessed.  This would allow us to classify important folders all over our network as “ACME-CONFIDENTIAL” and then include that string in alerts and correlation rules in a SIEM like EventTracker to alert or escalate on events where the information being accessed has been classified as such.

The other big change to auditing and access control in Windows Server 2012 is Central Access Policies which allows you to define a single access control list or audit policy in AD and apply it to any set of computers.  That policy is now evaluated in addition to the local security descriptor on each object. 

While Microsoft and press are concentrating on the access control aspect of these new dynamic and central security features, I think the greatest immediate value may come from the audit policy side that we’ve just explored.  If you’d like to learn more about dynamic and central access control and audit policy check out the deep dive session I did with A.N. Ananth of EventTracker: File Access Auditing in Windows Server 2012. 


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

Using Dynamic Audit Policy to Detect Unauthorized File Access
Security Log Step-by-Step: Avoiding Audit Policy Configuration Pitfalls
Virtualization Security: What Are the Real World Risks?
The Art of Detecting Malicious Activity with Logs

New Technical Brief by Randy Franklin Smith

Mon, 14 Oct 2013 15:43:28 GMT

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.

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

Security Log Step-by-Step: Avoiding Audit Policy Configuration Pitfalls
Auditing File Shares with the Windows Security Log
New Technical Brief by Randy Franklin Smith
Audit Myth Busters: SharePoint, SQL Server, Exchange

Audit Myth Busters: SharePoint, SQL Server, Exchange

Wed, 02 Oct 2013 08:44:19 GMT

Had many, many valuable conversations with colleagues in DC a couple weeks ago at HP Protect 2013 about auditing and monitoring SharePoint, SQL Server and Exchange.  This is a tough subject because there are so many details.  You can’t just answer "Are you currently monitoring SharePoint/SQL/Exchange: Yes/No?"

This is because each of those applications have multiple logs with widely ranging security value and content.  Also, there are some existing connectors from HP for these apps but their capabilities, caveats vary greatly - as well as exactly which logs and versions of SharePoint/SQL/Exchange they apply to.  Many folks are making decisions and/or belaboring under one or more misconceptions. 

In this post I'm going to try to quickly bust a few of those and myths and provide links to where you can get more details.  It’s kind of specific to ArcSight users but has value to anyone with a SIEM and Microsoft apps.

1. We are already monitoring SharePoint. 

OK, but what are you actually monitoring in SharePoint?  SharePoint has about 4 different logs.  Only one of them is the actual SharePoint Audit Log with security activity.  And that log is not available through normal log collection means.  Just recently HP released a SmartConnector for SharePoint.  But this SmartConnector simply uses JDBC to pull the raw audit log from the SharePoint DB.  Take a look at the raw audit log in SharePoint ( Getting the raw SharePoint audit log into ArcSight allows you to say you are collecting the SharePoint Audit log but try understanding and responding to the events.  Things like user 17 and role 42 are not translated, so you don’t know who or what you are dealing with.  Check here for more non-commercial information on the SharePoint audit log.  Learn how we solve the problem with LOGbinder SP here.

2. We are already monitoring Exchange.

Again, what are you actually getting from Exchange?  Exchange has 3 different logs that are valuable to security.  The message tracking log tracks message flow and is available through a connector for Exchange Message tracking.  While it’s incredibly voluminous, it does allow you to track all inbound and outbound emails, but it doesn’t track:

-          Non-owner access to other mailboxes

-          Mailbox copies and exports

-          Privileged user operations

-          Administrative changes

-          Security policy and configuration changes

For non-owner mailbox access auditing, you need the mailbox audit log.  As of Exchange 2010 that log is not a log file nor is it sent to the Windows event log.  Each mailbox has a hidden folder where it stores audit records for that mailbox.  There is a SmartConnector for the Exchange mailbox audit log and it is practical if you need to audit a handful of mailboxes and do not require full audit log integrity.  See my comparison here between that SmartConnector and LOGbinder EX. Check here for more non-commercial information on the mailbox audit log. 

The 3rd log in Exchange, admin audit log, is extremely important because it gives a full fidelity audit trail of all privileged user activity in Exchange including:

-          Exports and copies of mailboxes

-          Changes to security policies

-          and about 600 other operations

This log is also completely inaccessible to SIEMs because it’s stored in a hidden mailbox of all places in Exchange.  There is no connector at all, but we do handle it beautifully with LOGbinder EX.  Check here for more non-commercial information on the admin audit log. 

What about SQL Server auditing? 

SQL Server 2008 added a new and beautiful, true, honest-to-goodness audit capability.  It blows the old SQL Trace out of the water.  No comparison.  SQL Audit can send events directly to the Windows event log which you could then pick up with the WUC or Snare, etc.  But if your DB admin has anything to do with it you may run into trouble because of the performance load of both logging and retrieving those events through the heavy Windows event API.  Microsoft recommends using the other output option which is to a binary log file on some other server on the network.  This is the most efficient high speed low overhead method of getting audit events off of a busy production SQL Server.  If you need that option, LOGbinder SQL is there to help.  The other issue with collecting SQL audit events from the Windows event log is that SQL Server logs every possible operation (we’re talking 100s of them) as just one generic event ID with the same static text and fields.  Can you say cryptic?  We can help with that too.  More, non-commercial, information on SQL Server Audit here. 

Some other educational resources right here on 724 are: for Exchange and for SharePoint.

I hope this helps and feel free to reach out to me anytime…

Randy Franklin Smith

Security Log Nerd

Designer of LOGbinder

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

Audit Myth Busters: SharePoint, SQL Server, Exchange
LOGbinder SQL Beta is released! Join beta testers now
Security Log Step-by-Step: Avoiding Audit Policy Configuration Pitfalls
Release of LOGbinder SP 3.0

previous | next

powered by Bloget™