Happy Easter!


Five telltale signs that your data security is failing and what you can do about it

5 telltale signs that your data security is failing and what you can do about it:

1) Security controls are not proportional to the business value of data

Protecting every bit of data as if it’s a gold bullion in Ft. Knox is not practical. Controls complexity (and therefore cost) must be proportional to the value of the items under protection. Loose change belongs on the bedside table; the crown jewels belong in the Tower of London. If you haven’t classified your data to know which is which, then the business stakeholders have no incentive to be involved in its protection.

2) Gaps between data owners and the security team

Data owners usually only understand business processes and activities and the related information – not the “data”. Security teams, on the other hand, understand “data” but usually not its relation to the business, and therefore its criticality to the enterprise. Each needs to take a half step into the others’ domain.

3) The company has never been penalized

Far too often, toothless regulation encourages a wait-and-see approach. Show me an organization that has failed an audit and I’ll show you one that is now motivated to make investments in security.

4) Stakeholders only see value in sharing, not the risk of leakage

Data owners get upset and push back against involving security teams in the setup of access management. Open access encourages sharing and improves productivity, they say. It’s my data, why are you placing obstacles in its usage? Can your security team effectively communicate the risk of leakage in terms that the data owner can understand?

5) Security is viewed as a hurdle to be overcome

How large is the gap between the business leaders and the security team?  The farther apart they are, the harder it is to get support for security initiatives. It helps to have a champion, but over-dependence on a single person is not sustainable. You need buy-in from senior leadership.

Happy St. Patrick’s Day-Compliance


How to Use Process Tracking Events in the Windows Security Log

I think one of the most underutilized features of Windows Auditing and the Security Log are Process Tracking events.

In Windows 2003/XP you get these events by simply enabling the Process Tracking audit policy.  In Windows 7/2008+ you need to enable the Audit Process Creation and, optionally, the Audit Process Termination subcategories which you’ll find under Advanced Audit Policy Configuration in group policy objects.

These events are incredibly valuable because they give a comprehensive audit trail of every time any executable on the system is started as a process.  You can even determine how long the process ran by linking the process creation event to the process termination event using the Process ID found in both events.  Examples of both events are shown below.

Process Start WinXP/2003 592 A new process has been created.Subject:

Security ID: WIN-R9H529RIO4Y\Administrator
Account Name: Administrator
Account Domain: WIN-R9H529RIO4Y
Logon ID: 0x1fd23

Process Information:

New Process ID: 0xed0
New Process Name: C:\Windows\System32\notepad.exe
Token Elevation Type: TokenElevationTypeDefault (1)
Creator Process ID: 0x8c0

Win7/2008 4688
Process End WinXP/2003 593 A process has exited.Subject:

Security ID: WIN-R9H529RIO4Y\Administrator
Account Name: Administrator
Account Domain: WIN-R9H529RIO4Y
Logon ID: 0x1fd23

Process Information:

Process ID: 0xed0
Process Name: C:\Windows\System32\notepad.exe
Exit Status: 0x0

Win7/2008 4689

Trying to determine what a user did after logging on to Windows can be difficult to piece together.  These events are valuable on workstations because often, they are the most granular trail of activity left by end-users: for example, you can tell that Bob opened Outlook, then Word, then Excel and closed Word.

The process start event tells you the name of the program and when it started.  It also tells you who ran the program and the ID of their logon session with which you can correlate backwards to the logon event. This allows you to determine the kind of logon session in which the program was run and where the user (if remote) was on the network using the IP address and/or workstation name provided in the logon event.

Process start events also document the process that started them using Creator Process ID which can be correlated backwards to the process start event for the parent process.  This can be invaluable when trying to figure out how a suspect process was started.  If the Creator Process ID points to Explorer.exe, after tracking down the process start event, then it’s likely that the user simply started the process from the start menu.

These same events, when logged on servers, also provide a degree of auditing over privileged users but be aware that many Windows administrative functions will all show up as process starts for mmc.exe since all Microsoft Management Console apps run within mmc.exe.

But beyond privileged and end-user monitoring, process tracking events help you track possible change control issues and to trap advanced persistent threats.  When new software is executed for the first time on a given system it’s important to know that, since it implies a significant change to the system or it could alert you to a new unauthorized and even malicious program running for the first time.

The key to this seeing this kind of activity is to compare the executable name in a recent event 592/4688 to executable names in a whitelist – and thereby recognizing new executables.

Of course, this method isn’t foolproof because someone could replace an existing executable (on your whitelist) with a new program but with the same name and path as the old.  Such a change would “fly under the radar” with process tracking.  But my experience with unauthorized changes that bypass change control and APTs indicates that while certainly possible, the methods described here-in will catch their share of offenders and attackers.

To do this kind of correlation you need to enable process tracking on applicable systems (all systems if possible, including workstations) and then you need a SIEM solution that can compare the executable name in the current event to a “whitelist” of executables.

How you build that whitelist is important because it determines if your criteria for a new executable is unique to “that” system, or if it is based on a “golden” system, or your entire environment.  The more unique your whitelist is to each system or type of system, the better.  You can build the whitelist by either scanning for all the EXE files on a given system or by analyzing the 592/4688 events over some period of time.  I prefer the latter because there are many EXE files on Windows computers that are never actually executed and I’d like to know the first time any new EXE is run – whether it came with Windows and installed applications out of the box or whether it is a new EXE recently dropped onto the system.  On the other hand if you only want to detect when EXEs run which were not present on system at the time the whitelist was created, then a list built from simply running “dir *.exe /s” will suffice.

If you opt to analyze a period of system activity make sure that the period is long enough cover the full usage profile and business process profile for that system – usually a month will do it. Take some time to experiment with Process Tracking events and I think you’ll find that they are valuable for knowing what running on your system and who’s running it.

SIEM Simplified for the Security No Man’s Land

In this blog post, Mike Rothman described the quandary facing the midsize business. With a few hundred employees, they have information that hackers want to and try to get but not the budget or manpower to fund dedicated IT Security types, nor the volume of business to interest a large outsourcer. This puts them in no-man’s land with a bull’s-eye on their backs. Hackers are highly motivated to monetize their efforts and will therefore cheerfully pick the lowest hanging fruit they can get. It’s a wicked problem to be sure and one that we’ve been focused on addressing in our corner of the IT Security universe for some years now.

Our solution to this quandary is called SIEM SimplifiedSM and stems from the acceptance that as a vendor we could go developing all sorts of bells and whistles to our product offering only to see an ever shrinking percent of users actually use them in the manner they were designed. Why? Simply put, who has the time? Just as Mike says, our customers are people in mid-size businesses, wearing multiple hats, fighting fires and keeping things operational. SIEM Simplified is the addition of an expert crew at the EventTracker Control Center, in Columbia MD that does the basic blocking and tackling which is the core ingredient if you want to put points on the board. By sharing the crew across multiple customers, it reduces the cost for customers and increases the likelihood of finding the needle in the haystack. And because it’s our bread and butter, we can’t afford to get tired or take a vacation or fall sick and fall behind.

A decade-long focus on this problem as it relates to mid-size businesses has allowed us to tailor the solution to such needs. We use the behavior module to quickly spot new or out-of-ordinary patterns, and a wealth of existing reports and knowledge to do the routine but essential legwork of  log review. Mike was correct is pointing out that “folks in security no-man’s land need …. an advisor to guide them … They need someone to help them prioritize what they need to do right now.” SIEM Simplified delivers.  More information here.