5.3 A need for standards, evaluation criteria and independent accreditation

As pointed out in paragraph 1.3, cost efficiency in use and development should be attained through the use of a modular approach and open interfaces. As far as the security management service and security engines are concerned, the separation of rules and processors means that in theory it should be possible to increase security in a modular way as this need arises by simply adding or upgrading functional packages (i.e. rules) and/or security engines. The security management service automatically checks for the modules that have been plugged in and knows about the provided functionality. The modules interoperate through standardized interfaces.

This approach assumes that predefined packages of functionality exist for various domains of security. Developers creating a rule-base for a particular area of security (e.g. network security) should group functionality according to the level of protection provided (varying from for instance ``base-line'' to ``advanced''). The customers then

1.

determine the protection required based on the outcome of a risk assessment for every area of security they wish to cover

2.

map the requirements onto a functional group -- this means that the functionality required is equal to or a subset of the functionality provided by the functional group

3.

select vendors that offer products for the area of security of their interest, both for hard- and software (possibly independently)

4.

select the hardware devices and their back- and front-end processors

5.

select the software package that offers functionality, i.e. the rules, as defined by the group they mapped their requirements onto

6.

create the security policy, translate the policy into a formal model and feed the definitions to the security management service

The check for mappings between the definitions, the rule-base and the functionality provided by the back-end processors and their associated devices is done by the security management service. Hardware vendors can concentrate on the equipment and back-end processors without having to think of applications for creating policies, configuring devices and dealing with events. Software vendors can concentrate on detection of attack patterns and selection of appropriate countermeasures, without having to worry about how the events that trigger the expert reasoning will be generated or how the countermeasure applications are to be invoked.

In order to accomplish all this we need a language to model security policy definitions, security relevant events and security relevant actions. The Common Intrusion Specification Language (CISL, [TUN98]^5.2) is an attempt to create a formal language that may address the description of intrusion detection events and responses. Its intention is to ``disseminate event records, analysis results, and countermeasure directives amongst intrusion detection and response components''. The following figure gives an illustration of the language.

Standards for other security relevant information -- audit log data for example -- would also be welcome. Some standard logging information is already required by evaluation criteria like the famous Orange Book (mainly with respect to access control though).

width


(InSequence

  (Login

     (Context

         (Time '14:57:36 24 Feb 1998')

     )

     (Initiator

         (HostName 'big.evil.com')

     )

     (Account

         (UserName 'joe')

         (RealName 'Joe Cool')

         (HostName 'ten.ada.net')

         (ReferAs 'FauxJoe')

     )

  )

  (Delete

     (Context

         (HostName 'ten.ada.net')

         (Time '14:58:12 24 Feb 1998')

     )

     (Initiator

         (ReferTo 'FauxJoe')

     )

     (Source

         (FileName (ExtendedBy UnixFullFileName) '/etc/passwd')

     )

   )

   (Login

      (CriticalContext

         (ReturnCode (ExtendedBy CIDFReturnCode) Failed)

         (Comment '/etc/passwd missing')

      )

      (Context

         (Time '15:02:48 24 Feb 1998')

      )

      (Initiator

         (HostName 'small.world.com')

      )

      (Account

         (UserName 'mworth')

         (RealName 'Mary Worth')

         (HostName 'ten.ada.net')

      )

   )

)

A rough English translation would of this S-expression would be :

 Three actions took place in sequence, at the times indicated.

First, someone logged into the account named 'joe' (real name

'Joe Cool') at 'ten.ada.net', from a host named 'big.evil.com'.

Then, about a half-minute later, this same person deleted the

file '/etc/passwd' from 'ten.ada.net'.  Finally, about

four-and-a-half minutes later, a user attempted but failed to

log in to the account 'mworth' at 'ten.ada.net'.  The attempted

login was initiated by a user at 'small.world.com'.

width

The AS-APIs define a set of calls, data formats and protocols for letting various modules communicate with each other, the central security management service or security engines. They need to be standardized for every group of APIs we distinguished in paragraph 2.2.

This approach makes it possible to have products evaluated for functionality and interoperability by independent bodies. Products are ranked according to the functionality they provide. Vendors create products that fit in various functional groups by defining packages of back-end processors with increasing functionality. This would simplify production (build a single product) yet allow for market segmentation (sell the entry points to functionality, the back-end processors, separately). Clients procure products according to their needs by looking at their requirements and comparing these to the predefined groups. By buying additional packages they can cover their extended need for protection over time, thus spreading the cost while preserving past investments. Customers can trust evaluated products to be compatible with systems that are already in place. Moreover, once an organization bought a module from a particular supplier, it can still turn to other vendors and select the products that best suit its growing needs without being tied to one particular supplier and his proprietary system. Vendors could also provide additional functionality on top of the existing open APIs to distinguish their products from others.

Footnotes

...[TUN98]^5.2

Other work is being performed on the development of a Common Intrusion Detection Framework (CIDF); the effort was initiated by the DARPA Information Technology Office. More information can be found at http://seclab.cs.ucdavis.edu/cidf.