Security Assessment Methodologies

 

A White Paper

By Robert A. Clyde

 

AXENT Technologies, Inc.

 

March 9, 1998

 


AXENT Technologies, Inc.
2400 Research 
BoulevardRockville, MD 20850  * www.axent.com

1. The "Business Problem": Minimizing Vulnerabilities

2. Why Security Assessment Tools?

How About a Tiger Team?

The Internet Gives Hackers an Edge

Typical Vulnerabilities to Detect

Emergency Response. Integrity Check

3. Early Assessment Efforts

4. Security Assessment. Essential Functionality

Network-wide reporting

Cross-platform operation

Framework for integration

Performance in large network

Bandwidth usage

Separation of duties

5. Types of Security Assessment Tools

A. Single-system based

B. Client-based

C. Network Probe

D. Manager/Agent

6. Summary of Assessment Methodologies

7. Conclusion

 

1. The "Business Problem": Minimizing Vulnerabilities

Today, enterprise networks are hodgepodges of diverse systems and platforms that include hundreds of UNIX, NetWare and NT servers, along with notebooks, PCs, midrange computers and mainframes. This intertwined, growing network is vital to the success of today. s business, but its complexity and diversity pose an information security challenge. As if the internal challenge were not enough, most networks also connect to the Internet, potentially exposing vital information assets to the world.

The foundation for true information security in any enterprise-computing environment is a security policy that balances risk and cost. After all, information security is a business issue, not just a technology issue, and the reason organizations want to protect information is for sound business purposes. A security policy should focus on delivering integrity, availability and confidentiality. Defining, implementing and controlling an effective policy in large, enterprise-wide, multi-platform environments seems like an overwhelming task. Despite policies written on paper, most companies have trouble quickly spotting the areas on their enterprise networks that are vulnerable and do not comply with policy.

At the March 5, 1998 Crossroads conference attended by top IT executives, only 38% of the attendees said they had a way to verify compliance with security policy. One of the speakers, Jim Patterson from Oppenheimerfunds stated, "Relying on an annual audit is not good enough. There are 364 other days in the year. " Unfortunately, a mere 17% of the IT executives claimed to conduct active daily monitoring of security policy compliance across the enterprise.

2. Why Security Assessment Tools?

Finding security vulnerabilities in an enterprise is a difficult and time consuming task. The complexity of our enterprises has increased rapidly. Many organizations report that they have more computer systems than users. Add to this the diversity of operating system platforms, routers, firewalls, network protocols, applications, web servers, databases, etc., and we can quickly see why trying to spot security vulnerabilities becomes so tough. Without sophisticated tools, it. s nearly impossible.

Assessment software tools provide a way to automatically discover and report vulnerabilities and find areas that do not comply with security policy. Some assessment tools address a specific platform like UNIX, while others provide cross-platform, enterprise-wide vulnerability reporting. Nevertheless, the basic purpose of any assessment tool is to help answer the question, "How secure are we?"

How About a Tiger Team?

One approach to answering the question, "How secure are we?" might be to have a tiger team of skilled security experts attempt to break into your enterprise. They would report all the different ways they found to penetrate the systems and network. However, the labor cost for such an effort prohibits its use on a frequent basis. Ideally an organization would like to know quickly about vulnerabilities so that they can bring their enterprise computing environment back into compliance before someone exploits the problems. Assessment tools provide the means to do this in an automatic and cost effective manner.

The Internet Gives Hackers an Edge

A few years ago, hacking took a lot of time and study. While expert hackers still abound, the Internet has entered a new era. Using almost any search engine, average Internet users can quickly find information describing how to break into systems by simply searching for key words like hacking, password cracking, and Internet security. Thousands of sites publish step-by-step instructions for breaking into or disrupting service to Windows NT systems, Web servers, UNIX systems, etc. The sites often include tools that automate the hacking process. In many cases the tools have easy-to-use graphical interfaces. For instance, a tool called crack automatically attempts to guess UNIX passwords. A similar tool called L0phtcrack breaks Windows NT passwords.

What does all this mean? Almost anyone with the motivation to break into systems can quickly obtain the technology to do so without having to become an expert hacker. In February 1998 several teenagers broke into Pentagon computers using sophisticated tools they found on the Internet.

Attacks can come from both inside and outside your organization. As the survey in the following chart illustrates, disgruntled employees actually represent a larger threat and typically cause more damage than hacker attacks. An effective assessment solution should detect vulnerabilities that can be exploited by insiders as well as outsiders. For example, a vulnerability which allows non-privileged NT users to gain full privileged access to a Windows NT server may be just as serious as a vulnerability which lets any Internet user gain access to a guest account.

Indicates the percentage of sites that perceive a threat from a particular source. The sources listed are the top four threats.
1997 Computer Security Institute Survey

Typical Vulnerabilities to Detect

Robust security assessment tools check for hundreds of different vulnerabilities. For example, typical vulnerabilities include:

Password strength . easy to guess passwords, passwords that are too short, passwords that don. t have to be changed periodically

Account settings . improperly protected login scripts, excessive privileges, no password required

E-mail holes . UNIX sendmail vulnerabilities, improper e-mail file protections

Startup files . improper startup file protections or links that allow non-privileged users to gain root

Network parameters . NT RAS, NIS, UNIX .rhosts files, ftp, telnet, and other network service weaknesses or misconfigurations

File protections . improper file permissions that grant broader access than desirable

Out-of-date patch levels . operating system files that contain security holes

Improperly changed files . critical files and programs that no longer match required cryptographic signature, which could indicate the presence of Trojan horses, viruses, or backdoors

O/S specific problems . Windows NT registry vulnerabilities, NetWare NDS problems, UNIX suid files, OpenVMS SYSUAF problems, etc.

In addition to this O/S-oriented list, organizations also need to assess the security of their databases, applications, routers, webservers, and firewalls. While these generally reside on top of an operating system, they often include their own security subsystems that must also be checked for vulnerabilities. For example, are Oracle DBA roles granted too broadly or do the CGI scripts on a webserver contain holes? Today most security assessment products focus on operating system vulnerabilities, but products with the appropriate infrastructure are quickly expanding the scope of security assessment.

Emergency Response. Integrity Check

Attackers who compromise a network. s security often leave behind backdoors, malicious code, modified programs, secret accounts, and other nasty surprises. As part of the emergency response to an attack, security experts recommend checking for new vulnerabilities and ensuring the integrity of system and application programs. An assessment tool quickly performs this task and is an essential ingredient for an effective rapid response program.

 

3. Early Assessment Efforts

In the early 1980s, security assessment was done almost exclusively by EDP auditors. They used manual checklists and a few rudimentary tools to review the security of mainframes and mid-range systems. Organizations developed policies and the auditors compared the actual security in place against policy.

By the second half of the decade, security experts realized this approach had some problems. Auditors could rarely review security more than once a year, so most vulnerabilities remained in place throughout the year. The explosive growth of systems and users coupled with the advent of client/server computing gave rise to assessment tools as a means of reducing the cost of audits.

In 1986, Cubic Systems and Clyde Digital Systems released the Security Toolkit. This product allowed security managers and auditors to automatically discover vulnerabilities on VAX/VMS systems. It acted like a security expert, finding holes and vulnerabilities faster and far more accurately than manual methods. Computer Associates released a product called CA-EXAMINE to detect vulnerabilities on mainframes. Later Dan Farmer released a public domain program called COPS, a collection of UNIX routines, to check for vulnerabilities on UNIX systems. In 1991, Clyde Digital merged with Raxco and released a version of the Security Toolkit for UNIX.

All of these products were single-system oriented, running on one system at time. Before long it became apparent that we needed assessment tools that could look at multiple systems in the network. In 1994, AXENT Technologies, Inc. released the OmniGuard/Enterprise Security Manager (ESM), which used a manager/agent architecture to provide consolidated reports of vulnerabilities on large numbers of systems. The product was the first to provide integrated cross-platform reporting. Around the same time Dan Farmer released the first probe-style vulnerability assessment tool as public domain software called SATAN.

4. Security Assessment. Essential Functionality

Providing enterprise security assessment in today. s computing environment requires functionality that can meet the critical objectives of executives, operations, IT managers, security managers and auditors. These objectives take into account the realities of managing security in a complex environment with many systems, users, and applications. The critical objectives that must be addressed are:

Network-wide reporting

Security reports need to contain data for the enterprise, not just a server or a few servers. This is crucial in determining the true security health of the organization. Network-wide reporting allows management to understand the current strengths and weaknesses in the security policies incorporated across the company. If you want to manage security, you have to have a way to measure how good it is. Without a network-wide report, management may be lulled into thinking that because one group is secure, then everything must be secure. This also provides an auditor or management the ability to compare the security of different divisions of the company, whether they are located physically close together or around the globe.

The diagram below shows an example of a network-wide report. The green portion of the pie chart represents the percentage of the network in compliance with security policy or best practices. The red portion is the percentage with vulnerabilities and clearly not in compliance. The yellow portion shows areas with less serious problems. Ideally an assessment tool should allow drill downs from this enterprise summary to the specific details of the vulnerabilities in the red and yellow areas.

Cross-platform operation

Organizations seldom have just a single hardware platform, but rather a variety of platforms that handle the workload most efficiently. Enterprise data is stored within a heterogeneous network of servers and workstations. Securing that data could be the difference between an organization staying in business or losing the business to the competition. Security management must be capable of determining the security weaknesses across all platforms in the network. Having one or more platforms in a diminished security state poses a potential danger to the organization.

Even with network-wide reporting on multiple platforms, administrators should be able to watch over the security of all platforms from their own desktop. This simplifies the workload and provides consistency of security administration for IT administrators. Having a single desktop console allows an organization to purchase the platforms of their choice, knowing the security management will plug into the current infrastructure without additional software or technical training. This also ensures that the reporting for the enterprise provides a single view of the security of all critical data within the network.

Framework for integration

Security assessment tools should have the ability to integrate with the security of other applications easily. The correct framework allows for the management of applications, such as databases, web servers, etc. along with managing server security. By providing this information to a single desktop client, the tool can manage servers and critical data applications in a comprehensive and consistent manner. In addition, security assessment tools should plug and play with system and network management frameworks, allowing IT staff to view security vulnerabilities from their own familiar management consoles.

Performance in large network

Large networks typically have many servers and WAN links. When the processes to generate network-wide reports for multiple platforms do not run in parallel, network resources are consumed and, in the large networks, the processes may not finish in a reasonable amount of time. Security reporting operations must be scaleable to the enterprise and efficient enough that an enterprise-wide assessment can be run every day; otherwise, vulnerabilities are likely to be noticed by exploiters before the assessment tool can find them.

Bandwidth usage

Network bandwidth is a precious commodity. To allow daily vulnerability checking, the assessment tool should use a minimal amount of bandwidth.

Separation of duties

Security administration and systems administration duties must be separated to guarantee that the data is truly secure. This provides a mechanism for checks and balances for systems, networks and respective data. Without the concept of separate roles, administrators are verifying the integrity of their own systems or security administrators/auditors must have full rights on each system, including rights to manage servers, users and the data itself. For example, whoever sets security policy should not have the right to make security changes on production systems and vice versa.

5. Types of Security Assessment Tools

Over the last few years a number of security assessment products have appeared on the market. The security assessment market is relatively new, but growing fast. Based on their underlying methodologies, today. s security assessment products fall into four basic categories:

    1. Single-system based
    2. Client-based
    3. Network probe
    4. Manager/Agent

The following sections describe each security assessment methodology and how well it addresses the six critical operational objectives discussed earlier.

A. Single-system based

As indicated before, the earliest types of assessment tools used a single-system-based approach. The security reviewer executes the assessment software independently on every system to be checked, as shown in the diagram below. This is the technique used by products like Security Toolkit, COPS, CA-Examine, and ISS. System Security Scanner (S3).

The graphical user interface or command line interface is located on the same system where the software runs. This spreads the execution of security checks across the various systems but lacks any network reporting capabilities. The security reviewer must log into a privileged account or have privileges granted to the program in order to do the assessment. At the very least, the reviewer must have a user account on each system. In order to check the next system the reviewer has to log into that system and execute the same software again. No network architecture exists.

Because the reviewer executes the code on each system, one system at a time, the single-system-based architecture does not handle the critical assessment objectives particularly well. This is not surprising, since the single-system-based method was invented in the days of monolithic computing. Here. s how it fares against the critical objectives:

Network-wide reporting - Since the software is unaware of other systems in the network, it does not perform network-wide reporting.

Cross-platform operation . Product developers could port to multiple platforms, but this requires large rewrites of the software. Most products and programs only support a single O/S. A few support two. In any case, single-system-based assessment products have no cross-platform integration, because they lack network communication.

Framework for integration - Without true network operation, single-system-based software lacks the infrastructure for flexible integration with other devices, databases, and applications in the network. It may be possible to integrate the software with system management frameworks, but no single-system-based products have such tight integration today.

Performance in large network - The problem with this type of software is that a security reviewer must manually execute it on each system or painstakingly set up and maintain complex batch procedures on each system.

Bandwidth usage - Since the architecture has no network operation, bandwidth usage is not really applicable.

Separation of duties - In order for information security personnel to monitor security, they must log into each system, most likely with a privileged account. Alternatively, they could require that each system administrator periodically run the reports and submit them as printed reports to security. Both choices violate the principle of separation of duties. In the second case, security assessment adds more burden to an already overloaded operations staff.

B. Client-based

In a client-based approach the security reviewer executes the assessment software on a client workstation or system. No assessment code is present on the other systems in the network, as shown in the chart below. This is the technique used by products like Intrusion Detection, Inc.. s Kane Security Analyst and Bindview.

The client assessment software uses the available network communication to log into the various systems one at a time (or use network mounted file systems) and then pull back files to the client system for analysis. The security reviewer must have privileged access to the various systems in the network that are to be checked. Because a client-based assessment tool runs only in one place in the network, it also has some serious problems in meeting the critical operational objectives:

Network-wide reporting - While it. s possible that the client GUI could consolidate network-wide reports, most client-based products do not currently do this. In addition, if multiple users are running the product to generate reports, each user must execute their own copy of the client, resulting in a complete duplication of security checks and increased performance hits on the network.

Cross-platform operation - Since the code only resides on the client, cross-platform operation requires extensive programming which cannot take advantage of the native security features and calls of the other platforms in the network. Today client-based products generally only check one or at most two operating systems because of this difficulty.

Framework for integration - Without true network operation, client-based software lacks the infrastructure for flexible integration with other devices, databases, and applications in the network.

Performance in large network - Performance worsens dramatically as client-based software must check multiple systems. It may be acceptable for a handful of systems, but it quickly becomes unacceptable for larger networks. The time to complete checks across systems increases linearly as systems are added. For example, if a single system takes 20 minutes to do a complete check, 100 systems will take over 35 hours to check, and 1000 systems will take over 15 days to complete! Clearly a client-based approach is totally inadequate to the demands of a large network.

Bandwidth usage - Since all checks are done on the client, all data in the network to be checked must be uploaded over the network to be analyzed on the client. This creates tremendous amounts of network traffic if there are more than a handful of systems. For example, a simple MD5 or CRC check on critical system files will likely use over 100Mbytes of bandwidth per system. Every file checked must be transferred over the network.

Separation of duties - In order to execute client-based security assessment software, the security reviewer requires a privileged account on each system to check. This is against most companies. security policies and operating procedures. Moreover, for environments with more than a handful of systems, it becomes very difficult to provide and maintain such accounts.

C. Network Probe

Network probe assessment software is executed from a client and uses the network to probe systems and network devices for security vulnerabilities. While from the diagram below it looks similar to the client-based approach, a probe is quite different. A network probe mimics a tiger team attack. It does not require access to the various systems in the network, as the client-based approach does. Rather it scans the systems from the outside (as shown by the arrows that do not go into the systems) and attempts to find vulnerabilities.

Unlike all the other methodologies, the probe methodology looks at system problems from an outsider. s or hacker. s perspective. For this reason a probe-style product may be viewed as a complementary tool to the other types of security assessment software. It certainly cannot replace a complete security review of the network and systems, but it can provide a valuable sanity check of the perimeter defenses for a network. It requires no code or access inside the systems. Examples of network probe products include AXENT. s NetRecon, ISS. Internet Scanner, SATAN, and Wheelgroup. s NetSonar.

Because of the fact that probe software runs only in one place in the network, it handles the critical enterprise security issues as follows:

Network-wide reporting - The probe software could consolidate results for the network and many probe products do this today.

Cross-platform operation - Since the probe software mainly looks at network ports and vulnerabilities it can probe various types of O/S. s. However, since no probe code runs inside the various systems, it cannot check for many types of vulnerabilities, such as file protections, file signature changes, user account parameters, backup status, batch procedure configurations, etc. Many probe products use only IP. Superior probe products recognize that many systems and network devices speak other protocols and may have vulnerabilities relative to those specific protocols (e.g., IPX, SPX, NetBEUI, etc.).

Framework for integration - Without any code inside the system, the probe software has no way to check applications, databases, etc. It could check network devices like firewalls and routers (again from the outside only).

Performance in large network . Since the probe software has to send packets and then analyze the results for each system in the network, the more systems that are added to the network the longer it takes to run. Network probes on large numbers of systems can take hours or even days to run. Clearly a probe approach is inadequate to the daily security monitoring demands of a large network.

Bandwidth usage . To detect vulnerabilities from the outside, probes send many packets over the network and tend to use a lot of bandwidth. The bandwidth usage increases linearly as more systems are added to the network. Certain probe products can cause network storms using up massive amounts of bandwidth and denying access to legitimate users. For these reasons probes are generally used on an occasional basis, such as when a new firewall is installed or reconfigured.

Separation of duties . A probe tool does not require privileges. It. s trying to find holes in other systems from the outside. Hackers make use of some probe tools to find ways to break in. Probes can be dangerous if they are not used properly and carefully.

D. Manager/Agent

The manager/agent assessment methodology provides an infrastructure for efficient enterprise-wide security assessment. As shown in the chart below, the security reviewer uses a console or GUI to control the assessment. The console talks to a manager, which in turn talks to agent assessment code on the various systems in the network.

The various agents can execute security reviews simultaneously throughout the network. In addition, the security reviewer does not need to have a user account or privileges on any of the production systems. AXENT. s OmniGuard/Enterprise Security Manager (ESM) is an example of a product that uses the manager/agent assessment methodology. The manager/agent architecture uniquely handles all of the critical issues for enterprise security management:

Network-wide reporting - Reports are consolidated at the manager. A security reviewer can easily access network-wide reports by connecting the console to one or more managers to retrieve security data. The console can provide compelling security summaries for the entire enterprise. Multiple security reviewers can connect to the same manager without leaving their desks or requiring the assessments to be redone. Enterprise reporting for large-scale sites requires the ability to connect to multiple managers and roll up summary reports across regions, departments, or divisions.

Cross-platform operation - Agents run on various platforms reporting back to a manager. A manager can control agents on many different platforms. Because the agents are running on the various systems, they can perform comprehensive and detailed platform and application security vulnerability checks.

Framework for integration . Developers can create new platform agents without changing the manager and GUI. In addition, because code exists on each system, it is possible to have agent modules that interface with applications, databases, web server software, firewalls, and routers.

Performance in large network . As more systems are checked, performance does not decline perceptibly. This is because the agent code on each system does the bulk of the work and allows the checks to be run in parallel across the network. Hundreds and thousands of systems can be checked on a daily basis. The overhead on individual systems is relatively small. Since agents must be installed on each system, a superior manager/agent product should have automated remote install and upgrade capabilities.

Bandwidth usage . Since agents do the bulk of the analysis and checks locally, only exceptions and critical information are uploaded to the manager. This keeps network traffic to a minimum, typically just 10-30K per system checked. The performance advantages allow manager/agent assessment tools to be used on a daily basis, even in large networks.

Separation of duties - Security administrators do not require accounts on each system. They only need access to the GUI and appropriate manager privileges within the tool. On the other hand, system administrators can see the same vulnerabilities, but they can be prevented from changing the policy against which the security checks are executed. They can quickly see security problems and fix them, but they can. t change the rules in the security policy. This gives manager/agent assessment software the flexibility to adhere to the realities of the way security and system management operations are run in today. s enterprises.

6. Summary of Assessment Methodologies

The high performance and low bandwidth usage of the manager/agent methodology makes it the only one that can be used on a daily basis in a production environment. As shown by the tables below, the other methodologies do not meet the essential functionality for enterprise-wide assessment.

Critical Objectives

Single-system

Client-based

Probe

Manager/Agent

Network wide Reporting

No

Yes

Yes

Yes

Cross Platform

No

Difficult

Yes

Yes

Framework for Integration

Yes

No

Difficult

Yes

Performance . large network

NA

Poor

Poor

Excellent

Bandwidth use

NA

High

Very High

Very low

Separation of duties

No

No

Yes

Yes

7. Conclusion

A manager/agent assessment product checks the same vulnerabilities as a client-based or single-system-based product, rendering those tools unnecessary. However, a network probe product performs useful checks from an outsider. s perspective, whereas all the other tools give an inside view. Occasionally, such as after a firewall reconfiguration, it makes sense to run a network probe to mimic a hacker. s view of the network. For this reason, a complete security assessment solution should include both a manager/agent product for daily use and a network probe product for spot checks. Ideally these tools should be integrated, so that from a single console you can see the vulnerabilities discovered by both types of assessment products. AXENT. s Enterprise Security Manager and NetRecon are integrated to provide this type of consolidated view.

Author | Title | Track | Home

Send email to Interex or to the Webmaster
©Copyright 1999 Interex. All rights reserved.