Trending Behavior – The Fastest Way to Value

Our  SIEM Simplified  offering is manned by a dedicated staff overseeing the EventTracker Control Center (ECC). When a new customer comes aboard, the ECC staff is tasked with getting to know the new environment, identifying which systems are critical, which applications need watching, and what access controls are in place, etc. In theory, the customer would bring the ECC staff up to speed (this is their network, after all) and keep them up to date as the environment changes. Reality bites and this is rarely the case. More commonly, the customer is unable to provide the ECC with anything other than the most basic of information.

How then can the ECC “learn” and why is this problem interesting to SIEM users at large?

Let’s tackle the latter question first. A problem facing new users at a SIEM installation is that  they get buried in getting to know the baseline pattern and the enterprise (the very same problem the ECC faces). See this  article  from a practitioner.

So it’s the same problem. How does the ECC respond?

Short answer: By looking at behavior trends and spotting the anomalies.

Long answer: The ECC first discovers the network and learns the various device types (OS, application, network devices etc.). This is readily automated by the StatusTracker module. If we are lucky, we get to ask specific the customer questions to bolster our understanding. Next, based on this information and the available knowledge packs within EventTracker, we schedule suitable daily and weekly reports and configure alerts. So far, so good, but really no cigar. The real magic lies in taking these reports  and creating flex reports where we control the output format to focus on parameters of value that are embedded within the description portion of the log messages (this is always true for syslog formatted messages but also for Windows style events). When these parameters are trended in a graph, all sorts of interesting information emerges.

In one case, we saw that a particular group of users was putting their passwords in the username field then logging in much more than usual — you see a failed login followed by a successful one; combine the two and you have both the username and password. In another case, we saw repeated failed logon after hours from a critical IBM i-Series machine and hit the panic button. Turns out someone left a book on the keyboard.

Takeaway: Want to get useful value from your SIEM but don’t have gobs of time to configure or tune the thing for months on end? Think trending behavior, preferably auto-learned. It’s what sets EventTracker apart from the search engine based SIEMs or from the rules based products that need an expen$ive human analyst chained to the product for months on end. Better yet, let the ECC do the heavy lifting for you. SIEM Simplified, indeed.

Compliance Challenge Continues

Despite its significant costs and a mixed record of success, the compliance-related load imposed on today’s enterprise has yet to decrease. Current trends driven by government legislative efforts, and adopted at the executive level, favor the continuing proliferation of monitoring and reporting in operations, decision-making and service delivery. Even if existing legislation is repealed, it is not certain that compliance edicts will cease.

The response and responsibility for monitoring, recording, analyzing and reporting on compliance efforts will continue to heavily impact IT operations. Data is where it all starts; IT remains the main repository of enterprise information and data including the responsibility for maintaining and operating the network links between all parts of the organization. Therefore, they will experience the bulk of the operational load.

Enterprise compliance activities break down into three steps:

  1. Assessment – the effort undertaken by the enterprise to determine the operational differences between current operational procedures and those required to comply with legislated mandates. This can include defining activities to eliminate the gap.
  2. Implementation – the effort to design the required solution, acquire infrastructure, processes and products to implement the solution, and, finally, the actual implementation effort.
  3. Review, analysis, and reporting – this is the cycle of activities to get actionable information from the data collected, the reporting on the day-to-day state of compliance, warning when noncompliance threatens, and progress towards achieving compliance.

The first two tasks have benefited from the interest and efforts of a range of aggressive solution providers. The third continues to get an increasing amount of attention as experience demonstrates its criticality to assuring compliance in an evolving climate of control. The enterprise must be able to demonstrate that it has policies and procedures in place, but also that it monitors to assure these are followed (and initiating corrective action when they are not). Enterprise executives also become liable if abuses or weaknesses creep in to their systems as things change over time as the result of growth (organic, acquisition, etc.) or consolidation.

For all but the smallest enterprise, the task of monitoring activities, collecting data, analyzing, and reporting on the data is far too complex and time-consuming for manual completion. Complicating matters is the tendency for mandates to include demands for ‘timely’ reporting and ‘prompt’ corrective action. With an environment with little tolerance for slow responses, few enterprises can afford to run the risk of being perceived as being non-compliant with the attendant legal and financial penalties.

Today’s enterprise operates in an environment of growing complexity, escalating competition and, in the case of compliance regulations, increasing ambiguity. Ambiguity means that different groups can, and will interpret performance and operational actions in differing ways. This increases the risk of non-compliance. It also means that the parameters and requirements of reporting can and will change. IT must be able to quickly and reliably adapt its processes to comply with these changes.

Finally, in addition to externally, mandated procedures are those that are required by the enterprise. Any solution must be able to monitor and prove compliance with these custom procedures. The solution is to automate the effort to track, manage, and report on the compliance process.

The primary responsibility for implementing the policies and reporting about these efforts falls on enterprise IT. IT must deal with these as well as expanded demands for service with staffs stretched to the limit with the technical and operational demands of increasingly complex day-to-day activities. It’s not possible to meet compliance monitoring and reporting with manual efforts. Such approaches are too slow, inconsistent in application, and unable to stay current with the pace of change in today’s dynamic enterprise.

Based on hard won experience in automating business processes, enterprises have embraced policy-driven automation to relieve the burden and risk associated with manual processes. This delivers flexibility, adaptability, and scalability with a timeframe and ease of implementation that meets compliance and operational needs. Hence, the popularity of SIEM and log management solutions and the popularity of integrated solutions that allow seamless growth and application across the enterprise environment.

It is important to know the specific requirements and results needed by the enterprise to avoid selecting a SIEM solution that is too complicated to use or feature-weak to meet enterprise needs. For most, a modular, automated, integrated, policy-driven and process-oriented solution will prove to be the most effective and flexible choice.

SIEM Fevers and the Antidote

SIEM Fever is a condition that robs otherwise rational people of common sense in regard to adopting and applying Security Information and Event Management (SIEM) technology for their IT Security and Compliance needs. The consequences of SIEM Fever have contributed to misapplication, misuse, and misunderstanding of SIEM with costly impact. For example, some organizations have adopted SIEM in contexts where there is no hope of a return on investment. Others have invested in training and reorganization but use or abuse the technology with new terminology taken from the vendor dictionary.   Alex Bell of Boeing first described these conditions.

Before you get your knickers in a twist due to a belief that it is an attack on SIEM and must be avenged with flaming commentary against its author, fear not. There are real IT Security and Compliance efforts wasting real money, and wasting real time by misusing SIEM in a number of common forms. Let’s review these types of SIEM Fevers, so they can be recognized and treated.

Lemming Fever: A person with Lemming Fever knows about SIEM simply based upon what he or she has been told (be it true or false), without any first-hand experience or knowledge of it themselves. The consequences of Lemming Fever can be very dangerous if infectees have any kind of decision making responsibility for an enterprise’s SIEM adoption trajectory. The danger tends to increase as a function of an afflictee’s seniority in the program organization due to the greater consequences of bad decision making and the ability to dismiss underling guidance. Lemming Fever is one of the most dangerous SIEM Fevers as it is usually a precondition to many of the following fevers.

Easy Button Fever: This person believes that adopting SIEM is as simple as pressing Staple’s Easy Button, at which point their program magically and immediately begins reaping the benefits of SIEM as imagined during the Lemming Fever stage of infection. Depending on the Security Operating Center (SOC) methodology, however, the deployment of SIEM could mean significant change. Typically, these people have little to no idea at all about the features which are necessary for delivering SIEM’s productivity improvements or the possible inapplicability of those features to their environment.

One Size Fits All Fever: Victims of One Size Fits All Fever believe that the same SIEM model is applicable to any and all environments with a return on investment being implicit in adoption. While tailoring is an important part of SIEM adoption, the extent to which SIEM must be tailored for a specific environment’s context is an important barometer of its appropriateness. One Size Fits All Fever is a mental mindset that may stand alone from other Fevers that are typically associated with the tactical misuse of SIEM.

Simon Says Fever: Afflictees of Simon Says Fever are recognized by their participation in SIEM related activities without the slightest idea as to why those activities are being conducted or why they important other than because they are included in some “checklist”. The most common cause of this Fever is failing to tie all log and incident review activities to adding value and falling into a comfortable, robotic regimen that is merely an illusion of progress.

One-Eyed King Fever: This Fever has the potential to severely impact the successful adoption of SIEM and occurs when the SIEM blind are coached by people with only a slightly better understanding of SIEM. The most common symptom occurring in the presence of One-Eyed King Fever is failure to tailor the SIEM implementation to its specific context or the failure of a coach to recognize and act on a low probability of return on investment as it pertains to a enterprise’s adoption.

The Antidote: SIEM doesn’t cause the Fevers previously described, people do. Whether these people are well intended have studied at the finest schools, or have high IQs, they are typically ignorant of SIEM in many dimensions. They have little idea about the qualities of SIEM which are the bases of its advertised productivity improving features, they believe that those improvements are guaranteed by merely adopting SIEM, or have little idea that the extent of SIEM’s ability to deliver benefit is highly dependent upon program specific context.

The antidote for the many forms of SIEM Fever is to educate. Unfortunately, many of those who are prone to the aforementioned SIEM infections are most desperately in need of such education, are often unaware of what they don’t know about SIEM, are unreceptive to learning about what they don’t know, or believe that those trying to educate them are simply village idiots who have not yet seen the brightly burning SIEM light.

While I’m being entirely tongue-in-cheek, the previously described examples of SIEM misuse and misapplication are real and occurring on a daily basis.   These are not cases of industrial sabotage caused by rogue employees planted by a competitor, but are instead self-inflicted and frequently continue even amidst the availability of experts who are capable of rectifying them.

Interested in getting help? Consider SIEM Simplified.