Guess who is the O-ISM3 information security professional in one second

Security Fundamentals Series

If you find that the traditional security concepts of confidentiality, integrity, and availability are sound, don't read any further.

If you think that these concepts have shortcomings, and you are looking for an alternative, check our Foundations of Information Security series of presentations:

Download the XML Schema for the Information Assurance Markup Language

Using O-ISM3 with TOGAF

In order to prevent duplication of work and maximize the value provided by the Enterprise Architecture and Information Security discipline, it is necessary to find ways to communicate and take advantage from each other’s work. We have been examining the relationship between O-ISM3 and TOGAF®, both Open Group standards, and have found that, terminology differences aside, there are quite a number of ways to use these two standards together. We’d like to share our findings with The Open Group’s audience of Enterprise Architects, IT professionals, and Security Architects in this article.

Checking Application Logs

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)
  • Events Logging Markup Language
  • Download the XML Schema for ELML

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?


Subscribe to O-ISM3 Vicente Aceituno´s Blog RSS