Events Logging Markup Language

Can you think of performing a Forensic analysis on a system with no records, no logs? Neither can I. Logs contain events like startup, restart, abnormal termination of services, physical and logical thresholds being exceeded, access to resources, network connections, privilege and access rights changes, configuration changes, etc. Logs are generated everywhere, in a multiplicity of formats, with different transports, API and formats. There are quite a few standards, for example:

  • CEE (MITRE initiative)
  • CEF (ArcSight)
  • Extended Log File Format (W3C)
  • WebTrends Enhanced Log file Format.
  • WSDM Event Format (OASIS)
  • XDAS – Distributed Audit Service (The Open Group)
  • RFC3164 – syslog (IETF)

It would be interesting to be able to check if all the important event are considered as part of the requirements of the design of an application. This can prevent nasty surprises when analyzing an incident. Using a good model of an information system can make this task relatively easy. Such a model would model an information system using the following elements:

  • Repositories (Credentials): Any temporary or permanent storage of information, including RAM, databases, file systems, and any kind of portable media;
  • Interfaces: Any input/output device, such as screens, printers and fax;
  • Channels: Physical or logical pathways for the flow of messages, including buses, LAN networks, etc. A Network is a dynamic set of channels;
  • Borders define the limits of the system.
  • Services. Any value provider in an information system, including services provided by BIOS, operating systems and applications. A service can collaborate with other services or lower level services to complete a task that provides value, like accessing information from a repository;
  • Sessions. A temporary relationship of trust between services. The establishment of this relationship can require the exchange of Credentials.
  • Messages (Instructions) . Any meaningful information exchanged between two services or a user and an interface.

For a log entry to be complete it should contain at least the following elements:

  • Every event can have an eventID.
  • If the event is not logged by the agent of the event, the "logger" can be identified using a "loggerID".
  • The "agent" of the event can be identified using a "sourceID".
  • The "agent" of the event can stay in different locations, identified using a "addressID".
  • The "credential" used by the source to perform a request can be identified using a "credentialID".
  • The "resource" (subject) of the event is identified using a "resourceID".
  • The "request" (access attempt) performed has a "RequestType" and a "Result". The reason for the "Result" is stated in the "ResultText".
  • The "payload" contains the information necessary to perform the request.
  • "dateTime" is the date and time when the request is performed.
  • "signature" is the digital signature of the event using the "credentialID".
  • "hash" is the digital summary of the event. It is recommended that the hash of the previous event in the Record is used to calculate it.

For example:

<sourceID></sourceID><addressID></addressID><loggerID>slacker proftpd[25530]</loggerID><Result>success</Result><ResultTextFTP session closed. </ResultText><dateTime>21/5/2007 20:22:14</dateTime>>">>

<sourceID></sourceID><addressID<</addressID><credentialID>abad</credentialID><loggerID> proftpd[31806]</loggerID><RequestType>login</RequestType><Result>failure</Result><ResultText>no such user found</ResultText><dateTime>21/5/2007 20:21:21</dateTime>

Using this scheme, it is possible to check how complete is a log, by checking:

  • If events need an unique identifier, or even a digital signature or a hash.
  • If there is a need to distinguish the process performing the action from the process logging the event.
  • if there is a need to identify the origin (agent) of the action.
  • If there is a need to identify the logical or physical location of the origin (agent) of the action.
  • If there is a need to identify the credentials used by the origin (agent) of the action.
  • If there is a need to identify the resource that is being accessed by the the origin (agent) of the action.
  • If there is a need to identify nature of the action (RequestType) performed on the resource.
  • If there is a need to identify the result of of the action performed on the resource.
  • If there is a need to identify the date and time of the action performed on the resource.

You can find a list of types of request and results here:

Using this list of type of request can very useful, as the RequestType indicates what is the type of resource being accessed, making it easier to read the log.

How do you check if your log designs are complete and contain all the information you might ever need?

Swiss Armed Forces using O-ISM3

by Lars Minth 29.03.2011

The usage of ISM3 within the Information Assurance program of the Swiss Armed Forces is threefold:

  • first there is the necessity to comply with a couple of regulations inter alia the ISO 27k family, ISO 31000 and ISO 20000.
  • then the development of measurable and achievable security processes is very demanding in such a high security environment while the pure implementation of ISO 27k, especially its controls, is not sufficient to prove a Return of Security Investment (ROSI)
  • at last the governance of security in a highly decentralized organization needs a clever structuring.

Basically in all of these action areas ISM3 is giving us a helping hand and therefore saving us time and money to develop an own interpretation of ISO 27k. ISM3 came into the focus of the Swiss Armed Forces during a study about a business-driven implementation of an ISMS in order to regain management attention and acceptance for the restructuring of security. ISM3 itself is not a new invention but a straight forward and enabling approach to comprehend existing security frameworks in order to make security understandable for the rest of the (business) world. During the long process of aligning diverse security initiatives within the Swiss Armed Forces ISM3 is and will be the central repository and helping cornucopia to establish security processes which are measurable, acceptable and achievable in the sense of ROSI. The methodology ISM3 provides is helping to achieve ROSI while the ISM3 security processes in detail are helping to focus on the servicing and main-tenance of security at all levels: operational, tactical and strategic.