| Previous | Table of Contents | Next |
Security Dynamics’ KSA and KSM
As part of the rush of IDS vendor acquisitions, Security Dynamics picked up KSA and KSM when it acquired Intrusion Detection, Inc. KSA is a vulnerability assessment tool, and KSM is an NT event log monitor.
KSA is built upon the consulting theme of Best Practices. A sound security policy states guidelines such as password composition rules, login failure thresholds, password assignments, file access rights, and logging. KSA scans systems for adherence to best practices guidelines and impressively reports results. Six major areas that KSA investigates are: account restrictions, access control, password strength, system monitoring, data integrity, and data confidentiality. Some of the vulnerabilities evaluated by KSA are as follows:
KSA supports distributed analysis of target nodes with reporting to a central system. Another feature reads the event log and looks for violations such as failed login attempts and other security activities (administrator login events). Interesting events are counted and displayed in graphical bar charts or in printed reports.
One of the useful additions to KSA is an inverse ACL map. Knowing the resources a user or group can access, and the access rights associated with that resource are both useful reports. Operating systems easily display the object along with the subjects and access rights for that object. However, displaying the opposite view is tedious when attempted manually. KSA provides a view of ACLs from the subject’s perspective, thus showing all resources that a subject can access. This feature, long part of RACF on mainframe computers, is not always available on other operating systems.
The KSM concentrates on event log analysis and alerts. Like eNTrax, the log is read in intervals as short as one minute. Multiple target nodes can have their event logs consolidated on a central console. Because KSM uses the event log, activities such as SYN Flood or Ping of Death are not detected. Network packets are the source of data for these attacks. Events that KSM monitors include logins, logouts, service starts, auditing configuration changes, and file accesses.
KSM ships with alerting capabilities today but does not currently support countermeasures, such as killing processes. This feature is likely to be supported in the future. Like other NT IDSs, the set of attack signatures is limited to those provided by the vendor. The capability to add signatures in the future also will be available. A number of predefined reports are provided with KSM including Most Targeted Machines, Suspicious User Activity, and a Top 10 Most Wanted Users. Data for reports can be limited to date and time ranges as well. Attack patterns analyzed include password cracking attempts, browsing, denial of service, privilege violations, ghost IDs, failed logins or file accesses, masquerading, and Administrator ID abuse.
As you’ve seen in this chapter, NT is a favorite target of hackers. Many of the internals for NT are not publicly available for review. At a 1997 DEFCON conference, Microsoft representatives asked a team of NT security experts what could be done to improve the security of NT. Most of the panel members remarked that documenting and publishing information would be a significant step forward.
Echoing the sentiments of other DEFCON participants, the panel members pointed out that it was difficult to securely configure NT systems for customers because the internal workings remained a mystery. Undocumented registry entries can lead to exposures because the consequences of ACL changes for those entries are not well understood by the public. Hackers, though, always find a way to discover the hidden secrets. In response to this request, Microsoft has sought advice from several independent security companies on the best way to document and make available this information. Hopefully, the knowledge will soon be shared.
One important message delivered over the last year or two is that a system evaluated at C2 level is not necessarily secure. True, Microsoft NT received its C2 evaluation with a nonnetwork attached system, but some of the attacks that have been announced against NT did not require remote access. Many weaknesses could be exploited by a user who might rely on a shared NT computer in the corner of a lab. A stamp of approval is only as good as the humans who build the system and those carrying out the evaluation. People make mistakes, and improperly protected registry entries in out-of-the-box configurations of NT show that even government-evaluated systems can still have flaws.
The popularity of NT is growing along with its install base. The market for NT IDSs is strong and also should grow during the next several years. One could predict that the marketplace for NT IDSs will be more competitive because the NT event log is easier to access and understand than UNIX audit logs. However, any of the IDS vendors currently working in the NT space will quickly point out that many mysteries lurk in the event log. Changes between service packs have caused more than one IDS vendor to rewrite code because events were no longer reported or the format of an event had changed.
Because Microsoft is planning major changes to NT security in its next major release (Microsoft 1997), you can expect the market to churn some more. Early access to NT V5.0 is a must for IDS vendors. Changes including support for Kerberos, moving registry entries into a directory service, and X.509 will push vendors to adjust their tools to incorporate and monitor new features.
| Previous | Table of Contents | Next |