Archive

Month: March 2012

Prism Microsystem’s founders decided early on that their goal and reason for the company’s existence was to design, develop and deliver SIEM services. As executives with a successful history in entrepreneurship, product development and enterprise management, they knew the risk and seductive promise of distractive diversification in pursuit of expanded revenues. They committed to concentrating specifically on SIEM functions of monitoring, discovery and warning about threats to security, compliance (in its multiple modes) and operational commitments.

Early on, their experience and careful listening to customers allowed them to align their message and product with market needs. SIEM was and is a specialized, dynamic and evolving task. In 2005, the most frequent question from potential customers was “Why do I need SIEM?” Many companies operated, more or less successfully, with in-place efforts at manual, home-grown and commercial solutions adapted from other functions. In actuality, this meant that such ‘solutions’ were time consuming, diverted scarce talent and yielded results that all too frequently fell far short of justifying the effort applied. EventTracker, among others, entered the market with an integrated solution designed specifically to do SIEM. With EventTracker, IT staff had in hand a collection of streamlined processes that reliably developed accurate, actionable information from log data. The benefits obtained from using these bespoke tools won over skeptics, as a result the SIEM solutions market grew. Enterprises became enthusiastic users of on-premise SIEM solutions.

By 2009, the increasing interdependencies resulting from infrastructure interactions and complex, dynamic service delivery elevated the need for fast, accurate analysis of vast amounts of data. SIEM solutions continued to evolve to meet the challenge of more adaptive and dynamic operating environments. Emerging trends in the application of IT technology led to increased integration of the infrastructure. IT responded to business and customer demand more reliable, faster delivery of high performance services. New services were created by assembling components. The result was increasing dynamic operation, increasing interaction of distributed components and infrastructure all of which had to be closely monitored to avoid problems with security, reliability, etc. This meant that SIEM was becoming both a more critical and specialized effort. Enterprises began looking for external expertise as the range of knowledge needed for SIEM management expanded with the an escalation in the depth and breadth of responsibility.

One example was the demand for organizational accountability resulting from well-publicized failures to protect private records. A wave of regulatory, governmental and enterprise operational mandates were put in place along with a sea-change in accountability. Executive managers were to be held accountable for the effective implementation of controls to assure compliance to an increasing number of continually evolving mandates covering security procedures, access control, performance, etc., as applied to a growing number of business functions. Just keeping current with external mandates was causing major headaches.

This focus on governance and responsibility irrevocably and dramatically changed the relationship between IT and business managers. IT operations and staff had long been intimately involved with and responsible for all aspects of data handling, process implementation, workflows, etc. necessary for compliance. Now, management and IT had to become partners in assuring effective compliance.

The result was increased complexity in maintaining effective monitoring and compliance mechanisms. SIEM had become an operationally critical issue and responsibility. As experience with compliance challenges accumulated and customer sophistication in SIEM matters increased, the demand was for more options. At all levels, including large enterprise, as well as mid-range (100 to 500 systems) and smaller businesses (below 100 systems), the demand was for more flexibility in selecting the range of available services, features and sophistication in analysis. They also were demanding pricing that allowed them to add functionality as their needs changed and the available budget grew.

The explosion of the Whatever-you-want-as-a-Service (XaaS) market also influenced customer demands and expectations. Companies were recognizing and accepting the fact that oftentimes it was to their advantage, both operationally and financially, to selectively outsource some IT services. XaaS services allowed customers to match the consumption of services to demand, spread out payments over a longer period of time, use only the services they needed and avoided responsibilities for maintenance, support, updates, etc.

By the end of 2010, it became clear that the interest in and demand for SIEM as a Cloud-based service was no flash-in-the-pan. Enterprise customers saw it as an increasingly attractive way to outsource services that required expertise and effort not part of their essential business competency and focus. SIEM as a managed service provided a way for the enterprise to free-up scarce IT resources to concentrate on improving competitive positioning, developing new services devoted to increasing revenues, lowering costs and improving performance to increase customer satisfaction.

The need for, and development of hosted enterprise-class SIEM and “Security monitoring as a Service” (SecaaS) became the next logical progression in the evolution of SIEM solutions.

There are several models for SecaaS: There is the Shared Cloud for small and medium size business. Data is collected locally, compressed, encrypted and sent to a central location for processing. Cost is kept low because companies ‘share’ the infrastructure. They avoid costs of dedicated SIEM infrastructure and support staff, but are guaranteed notification of disruptive events and activities. The companies and their respective data are isolated and protected from each other.

Then, there is the virtual private cloud deployment, for larger enterprise. Each company has its own private virtualized SIEM and data storage environment within the virtual private cloud, which isolates data from other customers. The architecture can handle 100’s of millions of events per day for each customer. Again, the customer saves by not having to purchase and maintain SIEM-specific infrastructure and support staff.

Finally, the Managed SIEM Service for those with a SIEM implemented on-site on their own infrastructure. The enterprise either lacks the manpower to or wishes to free staff from monitoring the infrastructure. It provides 24/7 monitoring and guarantees notification of any incidents or threat to managed services, key alerts and operating conditions.

At this point, we have to mention that today’s conventional wisdom consistently trumpets the superiority and lower cost of XaaS and Cloud solutions. However, recently this assumption is being challenged [1]. It is my believe that an Cost-Benefit comparison is a necessary best practice as part of any project analysis to determine which is the right way to go. But, that’s a topic for another column.

In The Information Diet, Clay Johnson wrote, “The modern human animal spends upwards of 11 hours out of every 24 in a state of constant consumption. Not eating, but gorging on information … We’re all battling a storm of distractions, buffeted with notifications and tempted by tasty tidbits of information. And just as too much junk food can lead to obesity, too much junk information can lead to cluelessness.”

Audit yourself and you may be surprised to find that you get more than 10 notifications per hour; they can be disruptive to your attention. I find myself trying hard (and often failing) to ignore the smartphone as it beeps softly to indicate a new distraction. I struggle to remain focused on the person in my office as the desktop tinkles for attention.

Should you kill off notifications though? Clay argues that you should and offers tools to help.

When designing EventTracker v7, minimizing notifications was a major goal. On Christmas Day in 2008, nobody was stirring, but the “alerts” console rung up over 180 items demanding review. It was obvious these were not “alerts.” This led to the “risk” score which dramatically reduces notifications.

We know that all “alerts” are not equal: some merit attention before going to lunch, some before the end of the day, and some by the end of the quarter, budget permitting. There are a very rare few that require us to drop the coffee mug and attend instantly. Accordingly, a properly configured EventTracker installation will rarely “notify” you; but when you need to know — that alert will come screaming for your attention.

I am frequently asked what is the maximum events per second that can be managed. I think I’ll begin to ask how many notifications per hour (NPH) the questioner can handle. I think Clay Johnson would approve.

Archives

Archives

This site uses cookies to store information on your computer. Some are essential to make our site work; others help us improve the user experience. By using the site, you consent to the placement of these cookies. Read our Privacy Statement to learn more.