So far you've seen that Stalker and CMDS are complementary system-level IDSs that catch a number of attacks which scanners and network sniffers cannot The next few sections summarize some other important issues to consider about system intrusion detection.
Ease of Set Up
Both Stalker and CMDS are distributed, client-server products. Depending on your network configuration, the installation and setup can be simple or complex. The usual rule of "your mileage may vary" is a good one to keep in mind.
Agent code must be installed on each CMDS target or Stalker agent. Although some autodiscovery is provided, the Server or Manager will need to be made aware of which nodes to monitor. The time it takes to configure nodes is a small constant value in most cases, but you need to multiply this value by the number of nodes you have.
As with most systems that rely on host names and IP addresses for identification, the use of dynamic host configuration protocol (DHCP) or regular changes to host identifiers will require additional administration. If you treat all monitored nodes uniformly, administration is simpler. However, if you want to analyze different statistics or attack patterns on each node, your administrative workload also will increase. Any variability in your monitoring requirements per node naturally will drive configuration changes on either agents or servers/ managers.
Distributed Intrusion Detection
Neither Stalker nor CMDS track the activities of a given user across multiple systems unless the assumption is that a person will have the same UID across all systems in the enterprise. Because this assumption is highly unlikely—even though the login name might be the same, the UIDs across systems may not be equivalent—tracking the activities of a single user throughout the enterprise is not straightforward.
One solution would be to add to each audit record, when consolidated on the server, with the originating host IP address. Unfortunately, this solution does not work for systems with multiple network adapters because the node will have several IP addresses. Also, in sites where IP addresses are assigned dynamically with DHCP, relying on an IP address to be meaningful would be a mistake because it could be reassigned at a future time. The host's name would probably be more reliable. When consolidating activities across systems, CMDS relies on the host's name and UID paired together to uniquely identify a user.
Distributed systems management framework vendors, such as Tivoli, are all too aware of this identity problem in networked environments. The favored approach is to assign a framework-specific host identifier that is persistent across changes in IP addresses or other system parameters, such as the planar ROM ID. Assigning a network user name that is independent of the system on which a user operates also would be useful. However, such an extension would require changes in core parts of the OS, such as the login process and the generation of audit records, in order to track user activities across multiple systems. One research project prototyped this approach for intrusion detection across systems (Snapp et al., 1991).
No comments:
Post a Comment