Auditor Help: Security

Security Resources
      Resources SANS Top 20 (
      Resources NIST(
      Resources CIS (
      Resources NSA (
      Resources Microsoft (

Auditor Security

Agentless software reduces complexity by exclusively utilizing resources available to the workstation running the software. Fortunately, Ecora's software is designed to take advantage of common secure processes available within the environment. The stream of data over a network created by the Auditor can be encrypted, but depends largely upon the workstation and the client/server environment implemented. In most environments, this means we will use established and previously approved methods for all communication.

Auditors for Microsoft Windows NT, 2000, Exchange 5.5 and NetWare do not require passwords, but use the software operator's rights established during login. This eliminates any requirement of password transmission. Much of the data transmitted during the documentation process is binary, although it is not usually encrypted by default. It is recommended that Auditor be run by the appropriate administrative account for the respective product. Microsoft Windows 2000 supports IP Security through the key-based Internet Message Access Protocol (ISAKMP) and IP Encapsulating Security Payload (ESP) when the client and servers are so configured. By implementing IP Security on Microsoft Windows 2000, all client/server network communications, including the documentation process, becomes encrypted. These higher levels of encryption are entirely dependent upon configurations within your environment.

Auditor for Exchange embraces the methods of the NT, 2000, and Exchange 5.5, but offers additional features permitting an alternate user name and password to authenticate to the directory. This allows access to servers beyond the context of the operator's login rights. This takes advantage of the Windows NT Security Support Provider Interfaces (SSPI), allowing flexibility in authentication options. The major advantage of using SSPI is different types of authentication to Active Directory clients and to encrypt the session. Generally, this utilizes a secure public/private key exchange with a negotiated cipher, but is dependent upon the operating system and Exchange revisions, service packs, and configuration options in your environment.

Auditor for Oracle uses the Oracle password protocol to enable over-the-wire password encryption. This employs a single-session key that encrypts authentication passwords with negotiable cipher strength. Auditor automatically adapts to higher levels of secure communications installed and server configuration. Importantly, Auditor is completely functional with a read-only, SELECT_ANY_TABLE, user account. This allows the documentation process to be performed without the risk associated with elevated privileges.

The Lotus Domino Auditor relies upon the Domino client installed on the workstation, as well as server configuration options, to determine the level of encryption and the security of communication. The Lotus Domino Auditor inherits the same level of security as the client software. A public/private key pair method with negotiable ciphers is available for all client-server communication. It is important that administrators recognize and implement security options as required in their environment.

Solaris and Cisco Auditors support the Secure Shell (SSH) protocol, which offers end-to-end encryption of the communication channel. SSH utilizes a Secure Sockets Layer (SSL) key-based negotiated cipher to encrypt all network communication. Clear-text, telnet-based communication is also supported for Cisco and Solaris.

Auditors for Oracle, Solaris, Exchange 2000, Domino, and Cisco include an option to cache passwords on disk. These passwords are used during the authentication process for ease of repetitive use and unattended scheduling features. Ecora Auditors that cache passwords employ the Blowfish algorithm as the cipher to encrypt passwords on disk. It is a secret-key block cipher that iterates a simple encryption function 16 times. The block size is 64 bits and the installation-unique key is pseudo-random generated at 448 bits, the protocol maximum. The key is locally generated and unique to each site and should help negate any software "back door" concerns. Encryption keys for the cached passwords are stored in a "*.cert" file within the software's directory hierarchy. The *.cert file is stored within the individual installation folders, typically a subdirectory of Program Files. These *.cert files should be considered for safekeeping; encrypted or moved to a more secure location (such as removable media), but must be available in the native format and location during the documentation process. With proper cert control, the configuration can be secured while the software is protected from unauthorized use. If the software operator chooses not to cache passwords, the file is temporary and deleted immediately after use. In the unlikely event an error occurs, the file could become stranded.