Download Supercharger Free Edition for Easy Management of Windows Event Collection
Wed, 14 Jun 2017 08:59:58 GMT
We just released a new and free edition of
Supercharger for Windows Event Collection which you can get here.
There are no time-outs
and no limits on the number of
computers you can manage with Supercharger Free.
I wanted to include more than enough functionality so that
anyone who uses WEC would want to install Supercharger Free right away. For non-WEC users, Free Edition helps you get
off the ground with step-by-step guidance.
With Supercharger Free you can stop remoting into each
collector and messing around with Event Viewer just to see the status of your
subscriptions. You can see all your collectors,
subscriptions and source computers on a single pane of glass – even from your
phone. And you can create/edit/delete
subscriptions as necessary.
I also wanted to help you get more from WEC’s ability to
filter out noise events at the source by leveraging my research on the Windows
Security Log.
Supercharger Free Edition:
- Provides a single pane of glass view of your entire
Windows Event Collection (WEC) environment across all collectors and domains
- Virtually eliminates the need to remote into
collectors and wrestle with Event Viewer.
You can manage subscriptions right from the dashboard
- Includes a growing list of my personally-built
Security Log noise filters that help you get the events you need while leaving
the noise behind
The manager only takes a few minutes to install and can even
co-exist on a medium loaded collector.
Then it’s just seconds to install the agent on your other collectors. You can uninstall Supercharger without
affecting your WEC environment.
I hope Supercharger Free is something that saves you time
and helps you accomplish more with WEC.
This is just the beginning.
We’ve got more exciting and free stuff coming. But you’ll need at least Supercharger Free to
make use of what’s next, so install it today if you can.
Thank you for supporting my site of the years. Here’s something new and free to say thanks.
email this
•
digg
•
reddit
•
dzone
comments (0)
•
references (0)
Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Live with Dell at RSA 2015
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
NEW Free & Easy to Use Tool, Event Log Forwarder for Windows
Sun, 22 Feb 2015 22:13:47 GMT
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):
and specify the address of your syslog server:
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
email this
•
digg
•
reddit
•
dzone
comments (0)
•
references (0)
Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Anatomy of a Hack Disrupted: How one of SIEM’s out-of-the-box rules caught an intrusion and beyond
Randy's Review of a Fast, Easy and Affordable SIEM and Log Management
Thu, 29 Jan 2015 17:46:06 GMT
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.
email this
•
digg
•
reddit
•
dzone
comments (0)
•
references (0)
Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Anatomy of a Hack Disrupted: How one of SIEM’s out-of-the-box rules caught an intrusion and beyond
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: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.
email this
•
digg
•
reddit
•
dzone
comments (0)
•
references (0)
Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
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:
Type
|
Description
|
Allow right
|
Deny right
|
2
|
Interactive (logon at keyboard and screen of system)
|
SeInteractiveLogonRight
Allow logon locally
|
SeDenyInteractiveLogonRight
Deny logon locally
|
3
|
Network (i.e. connection to shared folder on this computer
from elsewhere on network)
|
SeNetworkLogonRight
Access this computer from the network
|
SeDenyNetworkLogonRight
Deny access to this computer from the network
|
4
|
Batch (i.e. scheduled task)
|
SeBatchLogonRight
Log on as a batch job
|
SeDenyBatchLogonRight
Deny logon as a batch job
|
5
|
Service (Service startup)
|
SeServiceLogonRight
Log on as a service
|
SeDenyServiceLogonRight
Deny logon as a service
|
10
|
RemoteInteractive (Terminal
Services, Remote Desktop or Remote Assistance)
|
SeRemoteInteractiveLogonRight
Allow logon through Terminal Services
|
SeDenyRemoteInteractiveLogonRight
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.
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.
email this
•
digg
•
reddit
•
dzone
comments (0)
•
references (0)
Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Live with Dell at RSA 2015
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: 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.
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)
Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Live with Dell at RSA 2015
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)
Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
Live with Dell at RSA 2015
Live with LogRhythm at RSA
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
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 (http://www.ultimatewindowssecurity.com/sharepoint/logbindersp/crypticdata.aspx) 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: https://protect724.arcsight.com/docs/DOC-3181 for Exchange and https://protect724.arcsight.com/docs/DOC-3170 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)
Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
How to Audit Privileged Operations and Mailbox Access in Office 365 Exchange Online
LOGbinder SQL Beta is released! Join beta testers now
Whitepaper: Comparing Exchange Server's™ 3 Audit Logs for Security and SIEM Integration
Fri, 16 Nov 2012 16:27:36 GMT
This whitepaper by Randy Franklin Smith, provides an overview of the 3 different audit logs in Exchange and discusses their relative merits in terms of security value and how to integrate with your SIEM.
Download it now here.
email this
•
digg
•
reddit
•
dzone
comments (0)
•
references (0)
Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Live with Dell at RSA 2015
How to Audit Privileged Operations and Mailbox Access in Office 365 Exchange Online
SolarWinds Log & Event Manager Includes My Favorite Feature in a SIEM…
Fri, 29 Jun 2012 14:40:22 GMT
In conjunction with integrating SolarWinds
Log and Event Manager (LEM) with my LOGbinder
software I had an opportunity to get to know LEM and I thought I’d share some
of the highlights of what I discovered. Click here to download LEM now!
For me, the most important thing about a log management / SIEM tool
is its analysis functionality. How much
built-in intelligence does it have about common event logs and how powerful are
its capabilities for alerting you to important activity, reporting for
compliance and adhoc research? LEM
employs my favorite SIEM feature for increasing maximizing analytical power –
normalization.
Architected for
Normalization
With normalization, your SIEM vendor compiles schema of log
source agnostic event types that are common to nearly any technology. These event types include things like:
-
File operations
-
User account maintenance
-
Group membership changes
-
Configuration changes
-
Network traffic events
SolarWinds provides connectors for common log sources that
understand how to translate raw events from a specific log source into their
equivalent normalized event type. For
instance the screen print below shows a search based on Alert Type New Group
Member (in LEM, alerts are any events of interest – that is not
discarded).
When you query for this Alert Type you will get any group
membership additions from all monitored log sources. In the example above you see a member added
to a Windows local group as well as a new member added to a group in
SharePoint. That screen print really
illustrates the power of normalization.
You no longer need to be an expert in every arcane log format produced
within your organization. (It’s hard
enough to learn the Windows event log – much less all the other security logs
found on a typical network.)
As raw events come into LEM, the appropriate connector
compares the event to its alert criteria and discards unmatched events. The remaining events are normalized into
alerts. This processing takes place in
the local agent which increases efficiency since unimportant events are
discarded at their source. The
normalized alerts are then fed to the central LEM manager over an encrypted
connection which ensures security and audit integrity.
At the manager, alerts are processed according to the alert
distribution policy. Each alert may be
dispatched to one or more of the following:
1.
Alert Correlation Engine
2.
Console for display in dashboard Widgets or in
filter views
3.
Storage for future reports and analysis
Automated Response
through Rules
The Event
Correlation Engine is where Rules are processed. Rules define automated responses to
correlated alerts. LEM makes it easy to
define rules. You essentially build a
graphical flow chart of the rule by dragging and dropping conditions, actions
and Boolean logic operators on to the rule canvas; no cryptic data entry here!
The automated responses you can select range from sending emails
to your security analyst, to killing offending processes, updating a user
defined list or creating an incident.
The latter 2 are particularly interesting.
Incidents are a special kind of what I would call meta-alert
in LEM. You can define rules to trigger
Incidents from any alert that should be followed up on and for which you need
to document such follow up. While LEM
documentation suggests printing out a daily incident report and noting your
follow up and signoff on the hardcopy, I think it would be more efficient to
have the report emailed to a SharePoint document library. In the document library you could add
additional columns or workflows for documenting follow up and signoff.
User defined lists (called custom groups in LEM) allow you to
compare alerts against any list of items you define. For instance, you could create a list of
privileged users and then define multiple rules that use that same list to
identify activity where the actor or target is a privileged account. Of course the disadvantage of such lists
would be the burden of keeping them up to date.
That’s where the user defined list actions come in so handy. You can automate the maintenance of user
defined lists!
For instance you could create a rule for new group member
alerts where the group is Administrators, Domain Admins or Enterprise
Admins. Then set a response action that
adds the new member’s name to a Privileged Accounts list and a rule to handle
the opposite case where a user is removed.
Of course to handle nested groups you’d need to handle some additional
logic but a couple additional rules for maintaining an Admin-Equivalent Groups
list would do the job.
Interactive Analysis
The LEM console provides three levels of interactive
analysis. Starting on the Ops Center tab
(see below) you have a pane of customizable dashboards called widgets.
A Widget is a visualization (e.g. simple table or a pie/bar/line
chart) combined with a filter that controls which alerts are represented in the
Widget. This makes it easy to define key
security indicators and keep an at-a-glance eye on them. You can drill down into a Widget which takes
you to the next level of analysis – the Monitor tab (see below).
The monitor tab allows you to select a filter which displays
on the right, the alerts matching that filter.
Then when you select an alert, its details are displayed on the bottom
pane. When you enter the Monitor tab via
a Widget drilldown back on the Ops Center tab, LEM automatically selects the
same filter as the Widget you just came from making it easy to see the activity
behind the Widget.
You can select any data value in the Alert’s details and
select Explore which takes you to the 3rd level of analysis – the
nDepth display on the Explore tab (see very first screen print).
nDepth is a really cool way to do adhoc analysis of security
log activity. At its root, nDepth is a
search application that allows you to enter search terms in a single, Google-like
search field. And then of course the
matching alerts are displayed in a list underneath. However the capabilities go far beyond that
simple description.
In addition to displaying matching events as a simple list,
you can choose to visualize the data in a variety of chart formats, word
clouds, tree maps and more. Whenever you
change your search criteria, LEM adds your old criteria to the History list. Whenever you build a search you like and want
to re-use you can save the search and it appears in the Saved Searches
list. This makes it easy and superfast to
go back to recent searches or searches you knew you’d want to use again.
nDepth provides a number of ways to make it easier to refine
your search. In the Refine Fields pane
you see a list of all the field names found in the current result set. Under each field name you find a list of all
the values occurring for that field along with their count. You can drag any of these field names or
values to the search terms field and nDepth will automatically add a Boolean
expression that further filters the results.
You can highlight DNS names and IP addresses and run lookups
like Whois, traceroute, NSlookup. Or you
can on demand have any of the actions available to Rules described above to be
executed on the manager or agent system.
Wrapping Up
Beyond these three highly interactive and progressively
deeper analysis tools, you can also schedule reports to be automatically
produced and delivered via email. LEM
runs as a physical or virtual Linux appliance, the latter being easy to download
and quickly set up to run in your hypervisor.
Being a Linux appliance makes it easy to setup the appliance as a
separate isolated log management with access controls to prevent tampering by
admins of the systems you are monitoring which is an important architectural
consideration if you are depending on your SIEM to provide accountability over
admins. And though it’s a Linux system,
you don’t really need to be a Linux guru because the appliance can be almost
completely managed via the desktop console which runs on your workstation.
SolarWinds hosts an active user community called Thwack
where you can exchange filter, report and rule content, request new features, keep
up with new developments and get help from SolarWinds and community members.
SolarWinds Log and Event Manager is a capable SIEM software
solution that incorporates my favorite SIEM feature – normalization. The interface is highly visual with very few
instances where you must enter cryptic text and codes.
You can download a trial of LEM from
http://www.ultimatewindowssecurity.com/redir.aspx?name=sw_reg
email this
•
digg
•
reddit
•
dzone
comments (0)
•
references (0)
Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Anatomy of a Hack Disrupted: How one of SIEM’s out-of-the-box rules caught an intrusion and beyond
previous | next
powered by Bloget™