From lrockwell@baker.ds.boeing.com Wed Sep  9 18:39:36 1998

David_
Here is the analysis of the Discovery Coordinator Functionality. You saw a 
draft of this diagram when we met in Virginia in August and more recently 
during our recent telephone discussion.
The purpose of this diagram is to "get the ball rolling" as far as nailing 
down functionality and interfaces for IFD 2.x. This diagram is consistent 
with and derived from the presentation at the PI meeting in Aspen.  I have 
used the SSD Architecture diagram from July and updated it to show the 
major elements of the Discovery Coordinator (pending receipt of the new 
improved SSD Architecture diagram). Putting on my "Object Oriented Design" 
hat,  I have allocated the functionality to five major components:
- Policy Projector
- Intrusion Correlator
- Response Recommender
- Response Selector and
- Log Query.
In addition, the Backplane Server provides registration and communication 
services required by the DC Application components.

To communicate with SSD functionality implemented in the Discovery 
Coordinator, the Backplane Server would be loaded on the machine hosting 
the SSD functionality (e.g. the Policy Server).  Calls to the Backplane 
Server with specifically formatted messages would route the information to 
the targeted component.  Responses would be passed back in the same manner. 
We had planned to use the same Network Management Interface you choose to 
use (Scottie, HPOV, . . . ) for (a) acquisition of Network Topology and (b) 
Situation Display and the same "Knowledge Base" for storage, retrieval and 
manipulation of policy information. After our recent discussion I have 
changed the functional diagram to show acquisition of Network topology and 
display of intrusions and responses via the Object Database.
However, we have retained the Network manager as part of the architecture 
and functionality as  a runtime option for our internal integration, test 
and demonstrations. I also show the Object Database GUI to tune the 
quantitative intrusion detection and response parameters derived by the 
D.C. Policy projector.

Some of the technical questions we still have for you are:
(1) Will the heartbeat include the Infocon state and any "Slidebar" 
settings? If not, from where will the Infocon state and any "Slidebar" 
settings come from?
(2) In the proposed initialization dialog between the SSD and the Discovery 
Coordinator what level of granularity is required for the Intrusion Detect 
and Response Capability Command? I have proposed reporting back to the SSD 
at the class level.
(3) When the security policy requires the SSD to grant permission for a 
response, what should we use for the timeout period?
(4) What should the Discovery Coordinator do if it becomes compromised 
(i.e. becomes Not OK)? Will there be a backup DC?

For ease of viewing, I have included most of the  diagrams in one file. The 
second file is an update to the Discovery Coordinator "language" 
description of the Policy Manager to DC interface.(It is included 
separately since it is in a larger format.) These will be the basis for the 
Discovery Coordinator Architecture and requirements document which I will 
work on upon my return from ISTI'98. Your continued comments, answers and 
insight are appreciated.

  

Best wishes,
Laurence
(253) 773-4713