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:

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>proftpd.lab.ossec.net</sourceID><addressID>192.168.20.10</addressID><loggerID>slacker proftpd[25530]</loggerID><Result>success</Result><ResultTextFTP session closed. </ResultText><dateTime>21/5/2007 20:22:14</dateTime>>">>

<sourceID>proftpd.lab.ossec.net</sourceID><addressID<190.48.150.156</addressID><credentialID>abad</credentialID><loggerID> proftpd.lab.ossec.net:21:slacker 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?

Results of the O-ISM3 Challenge

The current state of affairs is that most information security professionals use the concepts of Confidentiality, Integrity and Availability for audits, consulting projects, risk assessment and management, and development of new standards. These concepts present a series of problems that have yet to be solved:

  • They're incomplete. Some professionals suplement them with concepts like Possession, Utility, Risk, Authentication, Authorization, Audit, Non-Repudiation and Accountability. This means performance and delivery vary greatly depending on what professional or company you use.
  • They're ambiguous. Many professionals and even published standards give different definitions of Confidentiality, Integrity and Availability. This adds more undesirable variance.
  • They are not operational. Consequently, Threats, Incidents, Vulnerability and Weakness among other concepts can't be reliably defined in terms of Confidentiality, Integrity and Availability reliably, increasing the ambiguity of definition. Even seasoned professionals don't agree on just what an Incident or a Vulnerability is. If you can't agree on what something IS, how can you manage it?
  • They don't have units of measurement. This makes it impossible to manage information security quantitatively. Bye, bye, optimization of resources.

The use of ambiguous, incomplete, not operational concepts without units of measurement has created a number of problems for information security management. Communication with between specialists and non-specialists in information security is difficult. Demonstrating the value of information security is difficult. Generally speaking, the use of these proxy concepts that don't add value makes information security management more difficult that it needs to be. Time is wasted, security projects that need funding don't get it, and trendy projects with little return get the green light. Luckily, change is possible.

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.

Bankia’s experience with O-ISM3

CajaMadrid (now Bankia) started using O-ISM3 in the security process of ethical hacking of systems and applications. Several enhancements were made in order to measure the metrics of this process, and a Service Level Agreement was established based on those metrics. Using O-ISM3 criteria, the classification of information systems, which determines how frequently the systems are tested, was improved.

As a result of O-ISM3 implementation, the team’s productivity doubled during the first year. The follow-up reports with metrics made collaboration between developers, system administrators and security personnel easier and more productive. The information available is so detailed that CajaMadrid now uses objective criteria to give an award to the manager whose applications or systems present the fewest vulnerabilities, and vulnerabilities that are found are fixed faster.

The methodology’s orientation on deliverables makes the entire evidence-generating activity possible, which means that it is auditable, measurable and manageable. As the management system is metrics based, daily operations do not require audits for improvement, speeding up the improvement cycle significantly. When metrics correlate well with pursued goals, process improvement leads directly to the achievement of goals with greater effectiveness, efficiency and quality. Metrics make the status and progress of activities clearly visible, making it easier to reach agreements with our internal client and partners, and communicate our achievements to upper management. Ultimately, this methodology allows information security to be managed using best practices that apply to business in general. Based on the success of the methodology, we are extending the use of the method to other processes.

Bankia is ISO27001 and ISO20000 certified, and uses CMMI-3 and standards like ITIL, OSSTMM and many others. O-ISM3 integrates seamlessly with all of them and we have even received a positive note about our ISMS certification thanks to ISM3. We are very interested in the method, and once it has been set up, it is simple to use.”

Pages