A whitepaper response

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

A whitepaper response

Sanford Whitehouse-2
For those that don't know me, I work with Anton at LogLogic.  I'm an
architect in the LogLabs group.  Previously at Counterpane where I
managed the log support engineering group for a number of years.

Anton recently asked that I join the fray.  It seemed reasonable to
start with a quick, semi-ambiguous, overly ambitious response to the
whitepaper.  Apologies for the length.

A very interesting paper.  Well done.  It approaches a number of
problems for log management vendors, and introduces new conceptual
solutions to the problem of log standards.

The CEET is an attempt to create a representation of an event in the
same manner as discrete log information such as ports, users, and files.
Discrete information is defined by the technology it represents.  Event
descriptions have a broader base, beyond technology, moving into
implementation and design.  To achieve parity use of event information
equally distinct definitions and relationships must be created.  When
achieved, one of the major barriers for effective log use will diminish.

The CLT does not challenge current product needs or use.  It is a clever
approach to particular vendor issues.  This can be performance affected
by volume and rate (binary), flexibility for interoperability with
vendor suites, and vendor/3rd party interoperability beyond log level
information (XML), or industry standards (SNMP).  By not having to
change complex logging code or refocus current objectives, the support
cost for the product vendor is lessened.

The CLS is a long time desire.  Security folks have been frustrated by
incomplete information, and varied expressions for the same data.
Including it in the CEE standard is natural.  Justification for the CLT
and CLS is stronger by association.

The CELR is an objective for product vendors and log management vendors.
Many product vendors are at a loss for what to log.  The perceptive
vendors understand this can be a growing issue with a business impact.
And they are at the "tell-me-what-to-do" stage.  Compliance is the new
800 lb gorilla.  Common knowledge of what is important is slim.  They
are also concerned to move out into an standard they may have to retreat
from.  Log management vendors want the result to be useful.

One general observation is it would benefit by expressing why this
should be adapted by product vendors.  It describes a number of
interesting scenarios fit to security and log management objectives.
The benefits section has arguments used by most logging standards.  Some
statements may benefit from additional information.  For example, the
statement "Event Producers ... will be able to decrease cost associated
with logging and reuse log libraries" could use expansion.

I get the impression that how this will work is still unclear.  For
example, the description of the taxonomy appears to mix desired
information (user) with the event description (event) and a taxon that
may not be relevant (status) but generally considered useful.  This
blurs distinctions between analytical use and event taxonomy.  A common
point of confusion in some of mail list discussions.

The extent the CLT will need to go to be successful could be more
strongly represented.  The paper is strongly biased toward security.
This is understandable. Up to the day compliance mandates and
regulations arrived, security was the only industry segment with a
driving concern for logs.  Those roots mask the other, perhaps larger
areas where it will need to operate.  More than 95% of all logs have
clear use.  Only a fraction of them have explicit or implicit security
relevance.  It does not touch on financial transaction recording, or
obvious areas such as workflow monitoring or operational
troubleshooting.  Further examples of operational, organizational, and
financial benefits will help demonstrate CEE value to non-security
stakeholders.

Compliance products treat audit trails as a mandated requirement.  It's
not what sells the product.  How CEE would work to meet customer
compliance monitoring be expanded.

The stakeholder motivations section could be expanded, or need a
foundation.  The 'standard' arguments in the software vendor column have
little meaning.  The 'audit feature development' benefit suggests a few
things.  It raises questions.  "Know what your users want..." presumes
software vendors care.  A section on why they should be a stakeholder
would be good instead of an involved party.

The IT users column has a number of known statements.  "Support
higher-level compliance requirements" may mean more to IT folks well
versed in compliance.  An improved audit trail is only one of the
benefits.

The Log management vendors column has good points for log management
vendors.  The points that imply lower cost of log support could be
added.  There are any number of other benefits.

The Recommendations row is a uncomfortable.  Transport, syntax, and
taxonomy are functional layers.  They address problem areas with
technical solutions and use case benefits.  Recommendations feels like
subjective use cases, recipes for correct logging that need to be
rewritten for each product and product application, and anticipated use.
Several points for a functional, what-to-log framework and guidelines
quickly come to mind.

The oil pipeline is a good scenario that could be exploited further.
It's an expression of complexity and the ramifications of failure.  The
first part of the first paragraph does not go far enough.  Anyone
familiar with such a scenario would question it.  Most such systems have
integrated monitoring capabilities.  Operational issues would be quickly
detected.  An attack on the system could show changes in the monitoring
information.  The most common concern is dealing with day-to-day issues
outside those anticipated by the monitoring system designers.  It's not
hard to image an effective logging system could reduce issues with
complex integration efforts within the monitoring software.  The log
management system effectively becomes the integration point.

Another example, building off that, is the problem of layered products.
Many product vendors rely on third party software to complete their
systems.  Most any appliance relies on a third party web server, VPN,
database, and any number of lesser pieces.  They seldom have the
resources to become experts.  CEE can reduce the need for 3rd party
expertise in troubleshooting and root cause analysis.  Simple
correlation can lead quickly to the root event that caused an event
cascade leading to failure.

If there is an aspect of any standard that should be stated, it is the
reason vendors should adopt it.  What benefit do they receive by giving
up ownership of their logs?  What will hurt them if they chose to go
another direction?  With so many companies moving to multi-function
products and enterprise scale manageability, why should
interoperaterability with competitors at any level benefit them?

On a final point, many vendors and users don't know how to log.  What to
log is always important.  Availability of logs, especially in cases of
non-native export capabilities can be a blocking issue.  Examples are
log rotation, file access, database unique references, and others.

Sanford