Sanford Whitehouse - Floating By

23 June 2008

Drawing Lines

Posted by sanford under: Log Standards .

Developing a logging standard will start by sorting out relationships, making distinctions, setting boundaries, and creating working assumptions. A jigsaw puzzle solver might advise flipping over the pieces, sorting them by color or pattern, and starting with the border first. Commonalities lead to other relationships. Assembling a subset of pieces can be done in isolation from the rest of the puzzle. After a while, the growing subsets can be joined until the picture is complete. Same here.

On to the flipping. The first step is to separate fact from desire.

A log message is record of an event or about events. It presumes no importance, and does not know where it fits in the world. It is information, clear or incomplete, verbose or cryptic. Do with it what you will, but do not presume it to be anything more. Not looking too closely, it is a statement that must be presumed to be fact.

When identifying an event by terms such as “security”, “auditing”, or “operations” a use case is being applied. A comfortable classification. It can be based on convention, the purpose of a product consuming the log, the perspective of the user in need of the log, or other grouping or abstraction. As such, it is based in judgment and objectives, and subject to change.

Security folks will see security in any event. Type is relevant only to security risk evaluation. The security industry does have general agreement about some events. Still, new threats are constantly discovered. The overall level of risk changes from day to day.

Messages used for auditing have a high dependence on use. Security is one, general policy is one, and business practice monitoring and policy is still another. The sets of messages that satisfy each are not identical. The repercussions from one use can lead to litigation, from another it’s just another message tossed into the basement file cabinet.

Operations has mixed perspective. It can be network traffic through an enterprise or the state of the product delivering the traffic. The message type depends on the user, the use, and the part of an infrastructure where it is being applied.

This is fodder for use standards, not a logging standard.

It’s natural for early efforts to mix facts with results. Subject matter experts (SME) may be the initial drivers or heavily involved. Without an objective foundation the available references are experience, best practices, and professional agreement. They are important references though. As use cases, they define how a logging standard will be used. In other disciplines, a third party may be brought in, with the stakeholders and SMEs, to sort out the various classifications and perceptions, without losing perspective. A logging standard must be objective in structure and form, and respect the areas it will be applied.

Now for sorting.

With a starting point that removes opinion from the mix, other points rise to the top. One example is division of associations.

Any message may contain information where valuation beyond the event is only possible with knowledge of the product. (I use “product” to define anything that can record an accessible log.) A way to start down this path is through the definition of the three basic event types.

Application

Any event about the product doing it’s job, satisfying it’s purpose, and generally the only message of concern throughout the various user, IT, and company levels. A firewall rejecting traffic, a ticking system creating a ticket, a sensor recording the internal pressure of an oil pipeline, a user adding a PDF file to a documentation catalog, a user login.

Operational

The state of the product, the state of the product’s relationship with its environment, and any internal processing supporting the product’s application. Open connection threshold warnings, replicating directory server contents, start up, shut down, the steps to close a user session.

Administrative

Change to the product’s operational or application state or configuration. Adding firewall rules, adding a user, setting the minimum memory threshold, adding a DNS zone.

To restate a classic problem, how are these events known to be what they are? An administrative event requires a user with administrative privileges. So, if an administrator is involved, it must that type of event. Hmmm. Okay, answer these questions:

1. How does one identify an administrator?

It’s standard advice to not use default administrative accounts. How does one know if “tretiak” is an administrator or a user? Well, by the operation of course!

2. By the operation?

There may be common operations known to require administrative privileges. List them. Then list operations that any user can perform except when administrative super strength is needed. Then list the operations in terns of the oil pipeline sensor.

Okay, then by the objects that are changed!

3 By what is changed?

A set of unknowns just a large at the previous points. Sit two OS SMEs in a room. One has depth in i/5OS. The other is Windows. Ask them to list the objects touched in common administrative practices. Start a stop watch. Count the puzzled expressions that happen in 60 seconds.

What’s left? A choice, that does not need to be made now. Only acknowledged. Either the product generating the log has to state what type of message it is, or the log standard must allow for the application of domain specific information, outside the standard.

Which way, in terms of the standard is best? Either or both?

One Comment so far...