Example

An employee (user_A) logs on to his workstation (host_1) and opens an FTP connection to a server called ftp.chips.com, accessed through a gateway (GW) that connects the organization's intranet to the outside world. The login process checks the user's credentials and the host's computer monitor notifies the computer security engine from the security management service of a successful login attempt. Additional processing can be done if the entry [user_A, host_1] of the access control condition matrix contains an access control condition vector (see figure 3.5). The security engine may wish to forward this event to the correlation engine that in turn interacts with other engines to detect anomalies by fitting various pieces of information together.

The system now knows that that particular user is present on the system. Next, the network monitor observes a stream of TCP/IP packets. It starts registering a session originating from the host. The network security engine is provided with event information and can check if certain rules apply to the source, destination and context of the connection. Entry [host_1, GW] is entered in the matrix. Rules that may apply with respect to the source (the subject), as indicated by the control conditions, may execute procedural logic depending on:

• authentication of the subject that opened a connection from the source address (requires interaction with the computer security engine)^3.3 ;
• whether the source host is listed as a compromised machine: this would enable the central security management to prevent further penetration of the system if the host is known to be successfully attacked;
• known vulnerabilities of the source machine (requires interaction with vulnerability scanners, which we defined to be a separate security service);
• the sensitivity level of the source host or the sensitivity of the information user_A has access to in the role he is currently assigned to -- this to prevent illegal information flows as described in a lattice according to the BLP-model;
• any existing sessions originating from that particular machine -- this information could be useful for calculating the amount of resources (bandwith for instance) used by that system and may require interaction with the auditing service;

Rules that are relevant to the destination address:

• is the destination internal or external to the organization (the host could be accessing the gateway or a machine beyond the gateway)?
• if internal (not relevant in this example):
  • what are the known vulnerabilities on the target machine, as reported by the vulnerability scanners?
  • who is logged on to the target machine? This is known to the computer security engine;
  • are there any existing communication sessions on the target host?
  • what is the integrity level of the target machine -- this to prevent illegal contamination of the target machine as depicted in a lattice according to the Biba model;
• if external (resource would be accessed through a gateway):
  • what is the name and location of the target machine?
  • what machines lie in the path towards the destination machine?
  • what is the perceived integrity level of an external host -- this to prevent illegal contamination of the target machine as depicted in a lattice according to the Biba model;

Contextual information could exist of:

• the network channel being used (ISDN dial-up connection, token ring network, ...);
• the protocol(s) being used at various levels (e.g. TCP encapsulated in IP that is tunneled using IP -- tunneling could trigger recursion, i.e. the inference engine to re-enter the access control condition matrix and go through the same checks with different data for source, address, protocol etc.);
• additional services required to understand the communication (encryption e.g.); communication with key management or encryption services may be relevant.

Footnotes

...

Notice that we have to distinguish between authenticating a computer host and the user at the application level.

... engine)^3.3