Archive

Personalization wins the day

Despite tough times for the corporate world in the past year, spending on IT security was a bright spot in an otherwise gloomy picture.

However if you’ve tried to convince a CFO to sign off on tools and software, you know just how difficult this can be. In fact, the most common way to get approval is to tie this request to an unrelenting compliance mandate. Sadly, a security incident can also help focus and trigger the approval of budget.

Vendors have tried hard to showcase their value by appealing to the preventive nature of their products. ROI calculations are usually provided to demonstrate quick payback but these are often dismissed by the CFO as self serving. Recognizing the difficulty of measuring ROI, an alternate model called ROSI has been proposed but has met with limited success.

So what is an effective way to educate and persuade the gnomes? Try an approach from a parallel field, presentation of medical data. Your medical chart: it’s hard to access, impossible to read — and full of information that could make you healthier if you just knew how to use it, pretty much like security information inside the enterprise. But if you have seen lab results, even motivated persons find it hard to decipher and take action, much less the disinclined.

In a recent talk at TED, Thomas Goetz, the executive editor of Wired magazine addressed this issue and proposed some simple ideas to make this data meaningful and actionable. The use of color, graphics and most important personalization of the information to drive action. We know from experience that posting the speed limit is less effective at getting motorists to comply as compared to a radar gun which posts the speed limit and framed by “Your speed is __”. Its all about personalization.

To make security information meaningful to the CFO, a similar approach can be much more effective than bland “best practice” prescriptions or questionable ROI numbers. Gather data from your enterprise and present it with color and graphs tailored to the “patient”.

Personalize your presentation; get a more patient ear and much less resistance to your budget request.

A. N. Ananth

Best Practice v/s FUD

Have you observed how “best practice” recommendations are widely known but not followed as much? While it seems more the case in IT Security, it is observed true in every other sphere as well. For example, dentists repeatedly recommend brush and floss after each meal as best practice, but how many follow this advice? And then there is the clearly posted speed limit on the road, more often than not, motorists are speeding.

Now the downside to non-compliance is well known to all and for the most part well accepted – no real argument. In the dentist example these include social hardships ranging from bad teeth and breath to health issues and the resulting expense. In the speeding example, there is potential physical harm and of course monetary fines. However it would appear that neither the fear of “bad outcomes” nor “monetary fine” spur widespread compliance. Indeed one observes that the persons who do indeed comply, appear to do so because they wish to; the fear or fine factors don’t play a major role for them.

In a recent experiment, people visiting the dentist were divided in two groups. Before the start, each patient was asked to indicate if they classified themselves as “generally listen to the doctors advice”. After the checkup, people from one group were given the advice to brush and floss regularly but then given a “fear” message on the consequences of non-compliance — bad teeth, social ostracism, high cost of dental procedures etc. People from the other group got the same checkup and advice but were given a “positive” message on the benefits of compliance– nice smile, social popularity, less cost etc. A follow up was conducted to determine which of the two approaches was more effective in getting patients to comply.

Those of us in IT Security battling for budget from unresponsive upper management have been conditioned to think that the “fear” message would be more effective … but … surprise, neither approach was more effective than the other in getting patients to comply with “best practice.”  Instead, those who classified themselves as “generally listen to doctors advice” were the one who did comply. The rest were equally impervious to either the negative or positive consequences, while not disputing them.

You could also point to the great reduction in smoking incidence but this best practice has required more than 3 decades of education to achieve the trend and still can’t be stamped out.

Lesson for IT Security — education takes time and behavior modification, even more so.

Come on Feel the Noise

It’s the line from a song in the 70’s, but quite apt when it comes to describing the Windows security log.  There’s no getting around the fact that there are a lot of useless and inexplicable events in the Security log, and the sooner you get comfortable with that the sooner you’ll save your sanity and get on with work.  In this article we’ll look at some common examples and noise events in the security and discuss strategies for dealing with them.

It is important to recognize noise.  First, the earlier in the log management process that noise can be discarded or ignored, the better for performance, bandwidth and storage.  Second, a lot of time can be wasted investigating what appears to be suspicious events, but which are, in fact, meaningless.

One example of high volume noise events are Kerberos service ticket renewal attempts generated on domain controllers.  Kerberos has two kinds of tickets – authentication tickets (also known as ticket granting tickets), and service tickets.  Authentication tickets (see event IDs 47684771 and 4772 on Windows 2008 and 627675 and 676 on Windows 2003) are connected with the actual authentication of the user (or computer) to the domain controller.  Service tickets vouch for a user’s identity to the member computers that the user subsequently accesses on the network.

When a user remains logged on (or a computer remains up) long enough, the service tickets expire and Windows needs to renew them with the domain controller.  A successful service ticket event (event ID 673 on Windows 2003 and 4769 on Windows 2008) can be useful by providing a record of the workstation and servers accessed by a user.  But a successful ticket renewal (event ID 674 on Windows 2003 and 4770 on Windows 2008) denotes nothing of value other than the fact that the user or computer remained logged on, or was powered up for a long time.  If a user remains logged on (or a computer remains up without being rebooted) for too long, the service ticket reaches it renewal lifetime limit and the domain controller finally rejects the renewal request, which generates a renewal failure.  There are other scenarios but at the end of day any kind of service ticket renewal (successful or failure) and any kind of service ticket request failure event is essentially noise.  Theoretically, malicious situations involving service ticket events could conceivably be generated, but in practice this is very unlikely, and there are no criteria that can be used to distinguish those events from all the background noise of other service ticket events.

Another example of noise that appears to be a event are the sometimes frequent occurrences of event ID 537, “Logon failure – The logon attempt failed for other reasons”, where user name is blank. Concerned admins may worry an attack is underway, but looking at the the sub status code in the event description  should confirm or allay these fears: if the code is 0xC0000133, “The time at the primary domain controller is different from the time at the backup domain controller or member server by too large an amount” (and it usually is), there is no security issue this is simply a time sync problem on the initiating computer or the domain controller.

Dealing with the quantity and variety of events can be overwhelming but several strategies can help prevent losing too much time on noise events.

First, known noise events should be identified, such as those described above.  Configure the log management / SIEM solution to suppress or filter these events from any alerts that are received or reports that are reviewed on a regular basis.  Document the justification for filtering those events so they are properly identified as noise or unimportant.

Next, set up alerts and reports for events that are known to exist, and are considered important enough to generate an alert or appear in the daily report.  There may be other events that don’t deserve a response but which should be reviewed for compliance purposes.  If entire logs aren’t already being archived, (including noise events), make sure that that the log management process records and archives these events.

Finally, the remaining events are those that are unknown, or unclassified.  Whatever the log management processes and technology, there should be a way to view any such “unclassified” events.  Periodically reviewing these events should prompt revisions to the criteria for the classification types described above with the eventual goal of no unclassified events.  This ensures unknown but important events aren’t missed, and provides a systematic way for managing noise.

While the Windows security log records all events from a finite set of IDs documented at www.ultimatewindowssecurity.com/securitylog/encyclopedia.aspx, many other logs, like those from Linux and Unix, have no well-defined and bounded event schema.  Even with the new subcategory audit policy structure released in Windows Server 2008, Windows audit policy is not granular or flexible enough.  The is true for for other log sources.

Security logs aren’t like a financial audit trail where every transaction and penny can and should be justifiable.  Get comfortable with noise events in your logs; through audit policy refinements, useless events can be reduced and real threats can be more readily identified.

About the Author

Randy Franklin Smith is an internationally recognized expert on the security and control of Windows and Active Directory security who specializes in Windows and Active Directory security. He performs security reviews for clients ranging from small, privately held firms to Fortune 500 companies, national, and international organizations.

Randy Franklin Smith began his career in information technology in the 1980s developing software for a variety of companies. During the early 1990s, he led a business process re-engineering effort for a multi-national organization and designed several mission critical, object-oriented, client/server systems. As the Internet and Windows NT took off, Randy focused on security and led his employer’s information security planning team. In 1997, he formed Monterey Technology Group, Inc where he serves as President.

You can contact Randy at rsmith@ultimatewindowssecurity.com

Subtraction, Multiplication, Division and Task Unification through SIEM and Log Management

When we originally conceived the idea of SIEM and log management solution for IT managers many years ago, it was because of the problems they faced dealing with high volumes of cryptic audit logs from multiple sources. Searching, categorizing/analyzing, performing forensics and remediation for system security and operational challenges evidenced in disparate audit logs were time consuming, tedious, inconsistent and unrewarding tasks.  We wanted to provide technology that would make problem detection, understanding and therefore remediation, faster and easier.

A recent article in Slate caught my eye; it was all about Infomercials…staple of late night TV and a pitch-a-thon that was conducted in Washington DC for new ideas. The question is just how would you know a “successful” idea if you heard it described?

By now, SIEM has “Crossed the Chasm” , indeed the Gartner MQ puts it well into mainstream adoption, but in the early days, there was some question as to whether this was a real problem or if, as is too often the case, if SIEM and log management was a solution in search of a problem.

Back to the question — how does one determine the viability of an invention before it is released into the market?  Jacob Goldenberg, a professor of marketing at Hebrew University in Jerusalem and a visiting professor at Columbia University, has coded a kind of DNA for successful inventions. After studying a year’s worth of new product launches, Goldenberg developed a classification system to predict the potential success of a new product. He found the same patterns embedded in every watershed invention.

The first is subtraction—the removal of part of a previous invention.

For example, an ATM is a successful invention because it subtracts the bank teller.

Multiplication is the second pattern, and it describes an invention with a component copied to serve some alternate purpose.  Example: the digital camera’s additional flash to prevent “red-eye.”

A TV remote exemplifies the third pattern: division. It’s a product that has been physically divided, or separated, from the original; the remote was “divided” off of the TV.

The fourth pattern, task unification, involves saddling a product with an additional job unrelated to its original function. The iPhone is the quintessential task unifier.

SIEM and log management solutions subtract (liberate) embedded logs and log management functionality from source systems.

SIEM and log management solutions (via aggregation) the problems that can be detected with correlation that would have gone unnoticed otherwise.

EventTracker also meets the last two criteria–arguably decent tools for managing logs ought to have been included by OS and platform vendors (Unix, Linux, Windows, Cisco all have very rudimentary tools for this, if anything); so one can say EventTracker provides something needed for operations (like the TV remote) but not included in the base product.

With the myriad features now available such as configuration assessment, change audit, netflow monitoring and system status, the task unification criteria is also satisfied; you can now address a lot of security and operational requirements that are not strictly “log” related – “task unification”.

When President Obama praised innovation as a critical element in the recovery in his State of the Union, he may not have had “As Seen on TV” in mind but does SIEM fit the bill?

What’s the message supposed to be?  That SIEM and log management solutions are (now?) a good invention? SIEM has crossed the chasm!