Open Channel Foundation
Not Logged In |  | 
Open Channel Foundation


Quick Application Search:


HOSTS
Get this title!
¤ 
Get HOSTS
¤ 
Monitor new releases


Basic information
¤ 
HOSTS Discussion
¤ 
FAQ
¤ 
Contributors
¤ 
Vision & Direction
¤ 
History
¤ 
Documentation


Additional resources
¤ 
HOSTS Plugin Example
¤ 
HOSTS Process Flow
¤ 
HOSTS Results Summary Example
¤ 
HOSTS Test Failure Example
¤ 
HOSTS Test Series Example
¤ 
The HOSTS Structure


Foundation :: Security Applications :: HOSTS

HOSTS FAQ


Coming Soon
Back to top

An Administrative Resolution section will be added to the HOSTS FAQ, to assist the test engineer in evaluating failed test results. This section will help the test engineer to determine whether failed test step results truly represent a security failure or if they need to be reclassified.

What does the HOSTS distribution include?
Back to top

The current HOSTS distribution includes the main driver program, several common task plugin modules, and test input files based on a limited number of security test categories. (The common task plugin modules are subprograms that use a common approach for performing a given test. For example, plugins exist for evaluating file and directory attributes such as protections and ownership).

The HOSTS distribution comes with the following test cases:

Solaris 8/Sun OS 5.8:

  • Auditing
  • Discretionary Access Control (DAC)
  • Encryption and Encoding (Rudimentary check only)
  • File anomalies (e.g., world write files)
  • Identification and Authentication (I&A)
  • Miscellaneous (banners, cron, syslog, etc.)
  • Networking
  • Operating System Specific (e.g., devices)
  • Versions (OS, specific applications with vulnerabilities tagged to specific versions, packages)
Red Hat Linux 7.2/ 7.3/8 and Red Hat Advanced Server 2.1
  • Auditing using SNARE
  • Discretionary Access Control (DAC)
  • Encryption and Encoding (Rudimentary check only)
  • File anomalies (e.g., world write files)
  • Identification and Authentication (I&A)
  • Miscellaneous (banners, cron, syslog, etc.)
  • Networking
  • Operating System Specific (e.g., devices)
  • Versions (OS, specific applications with vulnerabilities tagged to specific versions, packages)

What capabilities does HOSTS provide?
Back to top

HOSTS currently provides the following capabilities:

  1. Define pass/fail criteria/conditions.
  2. Tag a given test step to a specific security requirement.
  3. Perform security testing with minimal operational intrusion or disruption.
  4. Add, modify, and remove test steps as requirements, operational environments, system services, and configurable options change.
  5. Add new common task subprograms through the creation of new plugin modules.
  6. Track anomalous files over time.

How can HOSTS be made available to a system?
Back to top

HOSTS can be made available to a system through either of the following formats:

  1. HOSTS can be executed directly from a mounted partition (e.g., directly from a compact disk (CD) or via a Network File Service (NFS) - mounted remote partition).
  2. HOSTS can be installed locally using the Unix tar command. The tar format was chosen to facilitate portability between Unix variants.

Are the results produced by HOSTS repeatable?
Back to top

Yes, the results produced by HOSTS are repeatable. Consecutive runs produce identical results. HOSTS can be used to monitor for system changes and to monitor a system's security profile. Monitoring for changes to a system or a system's security profile is facilitated by the ability to execute HOSTS in an automated manner (e.g.,cron). As one would expect, automated execution of HOSTS must be restricted to non-interactive test series. HOSTS can also be used for regression testing of functionality and capability.

Where will HOSTS not help?
Back to top

HOSTS will not help under the following circumstances:

  • Manual interactions are required, such as GUI responses (human acknowledgements, GUI content) and data entry at specific points
  • Dynamic return values (Note: format and common content such as date formats can be tested.)
  • Intrusion testing/external probing, which must be run on the host being tested
  • Systems without Perl

Equally secure yet mutually exclusive tests
Back to top

The need for unambiguous results led to a brief dilemma when it was realized that circumstances do exist where mutually exclusive conditions could exist, both of which represent an equally secure environment. For example, under some variants of Unix, the non-existence of a file is just as secure as when the file exists and a particular control variable has been specified.

A second situation arises when requirement differences occur between system builds on top of the COE. For example, Application X may require an FTP server. Application Y does not. Consequently, a test to verify that the FTP daemon has been disabled, when running an Application X system, would fail since FTP must be enabled. The same test must pass when executed on an Application Y system. Once again we have a case of mutual exclusivity – a test that will pass in one or more configurations but fails in others.

As a result, the ability to bypass specific tests was added to handle situations such as mutual exclusivity and mission non-applicability.


Open Channel Software runs entirely on Open Source Software. We return value to the Software community in the form of services and original software. Most of our content is currently available as source code, with the copyright owned by the original author, All Rights Reserved. Everything else is Copyright ©2000 - 2014 Open Channel Software.
Free SSL Certificate
View our privacy statement.
Contact webmaster at openchannelsoftware dot org with questions.