Servers should be kept in a physically secure location with access by authorized personnel only.

The corporate network should be physically secured against eavesdropping or packet sniffing. Any packets associated with the administration of QuickFinder should be the most secured.

Access to QuickFinder indexes, configuration settings, and logs should be restricted. This includes file system access rights, FTP access, access via Web utilities including QuickFinder Manager, and any other type of access to these files.

Configuration settings that serve to send QuickFinder data to other servers or e-mail accounts or that protect QuickFinder data should be examined periodically to ensure that they have not been tampered with.

When synchronizing QuickFinder indexes, configuration settings, or templates to servers outside the corporate firewall, both QuickFinder Authentication and the HTTPS protocol should be employed (see Modifying Administrator Authentication Settings). Because this ultimately sends the entire QuickFinder configuration of a server to another server, great security precautions should be taken.

When QuickFinder is administered by users outside of the corporate firewall, both QuickFinder Authentication and the HTTPS protocol should be used. A VPN should also be employed.

If a server is accessible from outside the corporate network, a firewall should be employed to prevent direct access by a would-be intruder.

Audit logs and query reports should be kept and analyzed periodically.

Previous versions of QuickFinder stored username and passwords in config files. After updating to QuickFinder 5.0, the username and passwords are still stored in the config files until the config file is updated. At that point, the passwords are moved to CASA. Until they are moved to CASA, users who gain access to the qfind.cfg file can use the specified UserIDs and passwords to access those sites themselves.

A memory walker could discover usernames and passwords. If a user somehow has access to the server and could manipulate the memory, he or she could possibly get the passwords because passwords are not immediately cleared from memory or obfuscated in any way.

Usernames and Passwords are stored in CASA by using the Tomcat user. Other applications running in Tomcat, or users that know the Tomcat user credentials, could potentially get the usernames and passwords for the remote servers. In order to take advantage of this, an application needs to be installed as an Apache application and then specifically call CASA with the correct ID to get the passwords.

Although a QuickFinder Manager administrator might not have access rights to the entire server, QuickFinder Engine's File System repository and indexer might. The QuickFinder administrator can generate an index of the entire server, then see the first 255 bytes of the file (search descriptions).

Users might try to gain access to the index files. If a very sophisticated user properly decompiles the indexes, he or she might be able to discover the structure of the indexed files and rebuild the content of the files. An administrator should know where the index files are stored and what permissions are granted to those index files. An administrator should also be aware that an index file stored on a file system that is actually a remote mount might expose the index files to the security vulnerabilities of that remote mounted file system. For example, if the remotely mounted file system uses unsecured NFS, a network listener could listen for the packets on the network and reassemble the index or simply do a remote mount as the Apache user with no authentication required. Even users who cannot rebuild the contents of the files can still see the first 255 relevant text bytes by simply performing searches and reading the descriptions. To the best of our knowledge, even if users have access to the index (and the index format spec), they would still have a very difficult time rebuilding the file contents.