Appendix B: Frequently asked questions

Installation FAQ

What firewall ports must be enabled for ECC?

See the topic Configure software and hardware firewalls.

Can two or more computers each run ECC Administration console at the same time?

Yes. Administration Console reads its collection data from the ECC Server frequently, so any update made on one Administration Console will appear momentarily on any other Administration Console.

Some of my computers are on an Active Directory domain, while others are on a Workgroup. Can Nuix Enterprise Collection Center collect files from machines on either network?

Yes, Collection Center can collect files from machines residing on any domain or workgroup that is accessible from your network. Collected files can be saved to Destinations residing on computer which is a member of a workgroup or an Active Directory domain.

When configuring a network share as a Target Location, click the Advanced link to specify the user account required to connect to the share. When configuring a network share as a Destination path for a Collection, click the Advanced link to specify the user account required to connect to the share. Specify an Active Directory user account, password and domain to connect to a share on a computer which is a member of the domain. Specify a local account and password (with the domain left empty) to connect to a share on a workgroup computer.

Can ECC Client and ECC Administration Console be installed on the same PC?

Yes.

Can ECC Client be installed on a file server?

Yes, if the file server runs a supported operating system. Running ECC Client directly on a Windows file server allows file collections to successfully collect open files from local NTFS-formatted volumes.

Are there any special requirements for installing Collection Center components on a Virtual Machine?

So long as all hardware and software requirements are met, a properly provisioned and configured virtual machine should have no difficulty running a Collection Center component.

Can ECC Client Service be silently installed or upgraded via Group Policy and/or via logon script?

Yes. A Group Policy Object should be added and configured for each .MSI installer, and limited in scope to only machines designated for each of these installations. For details see topic ECC Client Installations via Group Policy.

Deployment via logon script is possible only if each user has local Administrator privileges. The logon script can launch the MSI installer using the msiexec.exe utility included with Windows. However, installations must run with local Administrator privileges. This requires the user who just logged in to have local Administrator privileges.

Security FAQ

How do I keep collected data secure?

Several measures can be taken to ensure the security of collected files. The following measures are not an exhaustive list and may not apply to your organization's security requirements.

When adding a new collection in ECC Administration Console, specify a "FileSafe" collection type. This ensures the collected files will be saved in a read-only format that requires special applications or tools to access. See the following question in this Security FAQ for more details.

The destination folder permissions granted to users, security groups and computer accounts largely determines who can access the collected files. If necessary, permissions to specific collection folders can be further limited once a collection completes (the permissions for the root destination folder should remain unchanged to allow future collections to be saved).

The physical security of the destination machines is also essential. Ideally, destination machines and the ECC Server would reside in a locked server room or other room with restricted access.

Although collected data can be quite large, consider performing backups of the data, if necessary.

Do FileSafe files – which contain the results of a file collection – have any password protection or encryption?

All FileSafe files are encrypted. FileSafe files can be unencrypted and extracted by running certain applications or utilities, such as GetData Forensic Examiner, Nuix Workstation, or utilities included with Nuix Collector.

Collections can be configured in ECC so that the new FileSafe which will store the collected files and folders will be password-protected. Only those with the password can decrypt the FileSafe to access its contents. A FileSafe file that lacks password-protection is not secure unless access to the file is restricted to authorized users only.

Are User IDs and Passwords for accessing UNC Targets encrypted?

User IDs and passwords are encrypted when stored on the ECC Server. This data is also encrypted when transmitted between the ECC Administration Console, the ECC Server and the ECC Client computers.

How do I keep computers with ECC Admin Console secure?

ECC Admin Console is a password-protected application; however, a user can log in to the program and then walk away from their desk, leaving the system vulnerable to unauthorized personnel. ECC Admin Console will automatically lock its screens if inactive for a preset number of minutes, which the user can change. Unlocking ECC Admin Console requires the user to re-enter their ECC user password.

While it is beyond the scope of this Guide to cover computer and network security, certain common security practices should be followed, including but not limited to:

Administration Console users should lock, log off, or shut down their computers when leaving their computers unattended. Configuring screen savers and sleep modes to prompt for a password when resuming or waking can also help.

Consider restricting login rights and authorized remote desktop users for any computer running ECC Admin Console.

Consider keeping ECC Admin Console computers in secure locations, such as offices which can be locked when unattended.

How do I keep the ECC Server secure?

While it is beyond the scope of this Guide to cover computer and network security, certain common security practices should be followed, including but not limited to:

Establishing a strong password for the built-in Administrator account as soon as ECC Server is installed and is accessible via ECC Admin Console. Other ECC user accounts also require strong passwords.

Configuring the ECC Server and other ECC components for HTTPS communication and disabling unencrypted HTTP, especially if the ECC Server will be public-facing on the internet, and/or when using the ECC REST API (i.e. integrating ECC Server with Nuix Adaptive Security or other applications via REST). If ECC is not integrated with another Nuix product or REST application, be sure the high-level API is disabled via Server Properties.

Keeping the server in a physically secure location where only authorized personnel have access.

Installing the latest operating system updates and service packs.

Running a server edition of an antivirus product on the Server, and keeping it active and updated. This may impact performance of the ECC Server, particularly for large installations.

Setting file and folder permissions on the ECC Server in a manner where only authorized personnel and service accounts have access to key folders, including the database and log folders. Permissions must be set in a manner that does not impede the operation of the ECC Server service or any backup routines.

Upgrading the ECC Server application to the latest available version. This will often provide a newer version of Java with a current set of SSL protocols and cipher suites. If the upgraded ECC Server uses HTTPS, the HTTPS configuration should be scanned after each upgrade to see if any SSL protocols (such as TLSv1.2) or cipher suites have become weak or vulnerable. It may be necessary to reconfigure the upgraded ECC Server to disable protocols or cipher suites that have become weak, or to enable the newest protocols or cipher suites.

Following basic security practices for your organization's computers and overall network, such as:

Denying anonymous access, while requiring strong passwords for all user and service accounts.

Using a firewall and NAT mechanism to restrict access.

Maintaining active and updated antivirus products on all computers that connect to the network.

Installing the latest security updates for the operating system soon after they are released.

Installing security updates for commonly installed applications such as Adobe Reader, Adobe Flash Player, Apple QuickTime, Java, and other programs known to be vulnerable to malware. Even better: avoid installing such programs where possible (the Java included within most ECC installers is an exception to this guideline).

Educating users to recognize and avoid phishing schemes, avoid giving out their password information, and recognize other fraudulent practices.

Researching and reviewing security practices.

Contracting with a qualified computer security professional to conduct periodic audits of your organization's computer security practices.

Can I use a self-signed or company-issued SSL Certificate on an ECC Server?

Yes; however, using any SSL certificate that was not issued by a trusted Certificate Authority entails additional effort to deploy initially and to update.

A self-signed SSL certificate and a corresponding private key can be generated for you within the ECC Server Configuration Wizard. A copy of the self-signed certificate must then be installed (added) into the Java keystore of the ECC Server, so it will be trusted. It is also necessary to add this self-signed SSL certificate into the Java keystores for each installation of ECC Admin Console and ECC Client with Search.

An SSL certificate issued by an in-house certificate server has similar requirements as for a self-signed SSL certificate (mentioned in the previous paragraph). But rather than adding the SSL certificate to the Java keystores for each ECC application, you instead add a copy of the root certificate that the in-house certificate server used to issue the ECC Server's SSL certificate.

Note: Procedures for adding SSL certificates to Java keystores are documented in this guide under the topic SSL certificate procedures

Before any SSL certificate expires a newer SSL certificate should be issued and installed to take its place. This is more burdensome when the certificate is self-signed or company-issued, because of the numerous Java keystores which will need the updated certificate. So using an SSL certificate issued by a trusted Certificate Authority can make SSL certificate updates simpler.

Note: All direct communication between ECC components (Server, Admin Console and Client) is protected by built-in encryption, even if HTTPS is disabled.
‎
‎Enable HTTPS in ECC Server to provide additional encryption, which is needed for protecting REST connections between ECC Server and Nuix Adaptive Security, Nuix Workstation or other REST client application (i.e. any time the ECC Server's high-level API is enabled). HTTPS can also encrypt web browsing sessions used to download Nuix Launcher or to initially launch Admin Console. Such activities are low risk as they do not involve transmission of your organization's data.
‎
‎Whenever HTTPS is enabled in ECC Server, it is considered a best practice to also disable HTTP, so that only HTTPS can be used to connect to the ECC Server.

 

Tip: HTTPS is strongly recommended for any ECC Server that is public-facing on the internet; however, if you need your ECC system exposed on the internet it is preferable to deploy an external messaging router. Please contact Nuix Support for details.

Can I use the newer 2048-bit SSL Certificates to secure ECC Server sessions?

Yes. An SSL certificate for Collection Center should have a key length of at least 2048. Longer keys are generally more secure but may incur a performance penalty.

When using SSL, why should the SSL 2.0 and SSL 3.0 protocols be disabled?

In 2011, the Internet Engineering Task Force published "Request for Comments 6176", which details known vulnerabilities in SSL 2.0 protocol, and recommends that the protocol no longer be used. In the Fall of 2014, the POODLE attack was discovered, rendering SSL 3.0 insecure. TLS v1.0 and TLS v1.1 protocols became vulnerable to other exploits soon after. To avoid these vulnerabilities, SSL in ECC Server is configured to operate using only newer protocols: TLS v1.2 and TLS v1.3 (as of the time of this writing).

New computer security vulnerabilities are discovered almost every day. There may come a time when the TLS v1.2 protocol must be disabled as part of maintaining a secure system. Also, certain cipher suites used by each of the SSL protocols may become vulnerable to new exploits and should then be disabled. Periodic SSL security scanning (discussed in the next paragraph) can help identify newly vulnerable protocols and cipher suites.

Do I need to do anything to protect ECC Server against the Heartbleed security bug?

No, the Heartbleed security bug is present only in certain older versions of OpenSSL which are not used by ECC. If your ECC Server is public-facing and using Port 443, you can test it for Heartbleed, POODLE and other SSL-related vulnerabilities using an SSL online scan tool, such as the free tool provided by SSL Labs. You can also test for Heartbleed vulnerabilities from within your LAN using a current version of the open source utility nMap; however, this utility must be run from a different computer than the ECC Server.

Note: Nuix does not recommend or warrant any third-party products or services, such as OpenSSL, the SSL Labs Scan Tool or the nMap network scanner.

Monitoring and email notification FAQ

Can Collection Center send SMS text message alerts?

Not directly; however, you can configure email alerts to send to an email address at an Email-to-SMS Gateway. This will result in an SMS text message being delivered to the specified cell phone number. Most cellular carriers offer such Email-to-SMS Gateways; refer to Wikipedia's List of SMS Gateways at http://en.wikipedia.org/wiki/List_of_SMS_gateways for details.

For example, a cell phone in the United States carried by AT&T Wireless with the phone number (415) 555-1212 can receive SMS text messages by sending email alerts to 4155551212@txt.att.net. Carriers may charge the recipient's cell phone account for every SMS message delivered in this manner.

Short Message Service (SMS) emails are limited to a maximum of 160 characters, which may be too short to relay an ECC email notification. Multimedia Messaging Service (MMS) messages can be longer than SMS messages. The above list of SMS Gateways also contains email addresses for sending MMS messages. In the example, above, an MMS message would be sent to the email address 4155551212@mms.att.net. Receiving an MMS message may cost the recipient more than receiving an SMS message, depending on the carrier.

Can Collection Center be monitored using common network monitoring tools?

ECC Server is self-monitoring. Nevertheless, it is possible to monitor certain aspects of Collection Center using scripts or third-party network monitoring tools. The following approaches outline several possibilities:

ECC Client on Windows writes to the Windows Application Event Log when various activities or error conditions occur. The Event Sources for these log entries are shown in the following table:

Certain network monitoring tools can be configured to watch for the presence of specified Windows Event Log entries (e.g. Error or Warning events with one of the above Event Sources) and act accordingly.

ECC Client on Linux and macOS write to the system log.

Any computer running ECC Client or ECC Server can be monitored to ensure the computer itself is online, and that the ECC process or service is running. Various scripts are available which can do such monitoring, provided the necessary firewall ports are open between the computers being monitored and the computer performing the monitoring.

On Windows computers running ECC Client or ECC Server, the Windows Performance Monitoring system (PerfMon) can be configured. PerfMon statistics can be monitored by many network monitoring utilities.

Some network monitoring utilities can be configured to detecting an incoming email message that matches specified criteria, and act accordingly. Such tools can be configured to detect and act on email notifications and alerts sent from ECC Server.

Networking FAQ

Can I make my ECC Server accessible across the public internet – without a VPN – by implementing SSL security?

HTTPS and SSL can provide some protection for an ECC Server exposed to the public internet; however, the ECC Server will still be more vulnerable to hacking when public-facing.

Recommendation: keep your ECC Server and ECC Administration Console computers behind the organization's firewall and NAT router. And do not associate a publicly routable IP address with the ECC Server. If you need to perform collections beyond the firewall without a VPN, consider deploying an external messaging router on the internet, while leaving your ECC Server behind your firewall. Please contact Nuix Support for details.

If you must make your ECC Server accessible across the public internet, be sure to follow common practices for "hardening" the security of your ECC Server, for example:

Use a 2048 bit SSL certificate, signed with the SHA-2 hashing algorithm, from a trusted Certificate Authority, rather than a self-signed certificate.

Verify the SSL configuration using an online SSL scanner such as the SSL Server Test provided by Qualys SSL Labs.

Keep the server operating system current with security updates.

Periodically check with Nuix for updates to the ECC Server program.

Install an antivirus product suitable for the server's OS.

Configure a firewall to limit traffic on unused ports.

Consider placing the ECC Server on a subnet that is not publicly accessible, then place a load balancer or reverse proxy in front of the ECC Server. The load balancer can be public-facing for incoming connections, while connecting privately to the ECC Server.

Consider blocking sessions from IP addresses originating in countries where your organization does not operate.

The above list is not a comprehensive list of security practices; consult with a computer security professional if necessary, for guidance on securing your server.

Can I install ECC Client on computers that are connected via a VPN, and will Collections run properly on these computers?

Yes, ECC Client can be installed on computers that are connected via a VPN, and collections can run across a VPN connection. However, VPN connections are often much slower than local connections, and therefore cause collection bottlenecks. To minimize the impact of VPN bottlenecks, it is best to do one of the following:

If the remote computers are portable machines that can be brought into the main office, consider running the collections when these machines are connected directly to the main office LAN.

If possible, use Collection Criteria and targets with specific folders to keep the size of the collection small.

If possible, have the remote computers collect to a local destination folder or drive. If large amounts of data need to be collected from offsite locations, the data can be collected onto a local NAS device or external hard disk, so the device can later be shipped to the main office.

Consider using Nuix Portable Collector™ to collect from a limited number of remote computers. The Destination can be a local NAS device or external hard disk, which can be shipped back to the main office. A license to use Nuix Portable Collector may be included in your ECC license. Contact your Nuix account representative for details.

Should each subnet have its own ECC Server?

No. So long as your subnets have routing between them, it is generally best to have a single ECC Server in a given location. But it may be necessary to deploy multiple ECC Servers if your organization is very large or has significant numbers of custodian computers in multiple locations.

It is possible to run ECC Administration Console and connect to different ECC Servers (one at a time) across secure VPN connections. This allows a single ECC Administration Console to manage collections in multiple locations.

Ultimately, collections from several branch offices may need to be consolidated into one location at the main office. Doing this consolidation across VPN connections can be impractical due to bandwidth limitations.

One way to address limited VPN bandwidth is to use a local NAS device or external hard disk as Destination in each branch office. After the collections complete, these Destination devices can be shipped to the main office for consolidation.

But even if all collected data will eventually be sent across the network to one location, it may still be beneficial to have multiple collections with distinct Destinations in each branch office. Doing so can reduce network traffic during the initial collection.

Should each subnet or VLAN on the local network have its own Destination server or storage device?

If the local network is large enough to justify subnetting or VLANs, then it is likely beneficial to have distinct Destination locations available on each subnet or VLAN that is subject to collection activity.

Having multiple Destination machines within a single subnet may also alleviate performance bottlenecks in certain circumstances. See the Performance FAQ, below, for details.

Performance FAQ

My collection just started, and now the destination machine is very slow, or the entire network is sluggish. What can I do?

If the number of active collection jobs is bogging down your network, you have several options:

Use ECC Administration Console to pause some of the individual collection jobs, until network responsiveness improves. Let the remaining collection jobs finish before resuming some or all of the paused jobs. This approach allows you to set the "pace" of a collection.

Note: Be sure your ECC user is configured to subscribe to Job Stage Change email notifications.

Use ECC Administration Console to pause or cancel the entire collection. Resume or reschedule the collection to run during a weekend, or after upgrading to faster hardware.

Cancel the collection, then create several smaller collections and schedule them to run at different times.

Do nothing and allow the collection to proceed.

With multiple Clients performing simultaneous collections, how can I ensure the Destination will not be a bottleneck?

A destination machine's network bandwidth or disk I/O capacity can be overwhelmed by the simultaneous collection of several Client machines, as outlined in the following Performance Bottleneck Table:

Performance Bottleneck Table (Example)

Note: Mbps = megabits per second
400 Mbps = 40 megabytes per second
1000 Mbps = 1 Gigabit per second
10,000 Mbps = 10 Gigabits per second

In the example table above, four ECC Clients are each sending data onto the network, limited by the 40 MBps maximum sustained transfer rate of their hard disks. Taken together, the four ECC Clients are attempting to save 160 MB each second on the Destination.

The switch that the four ECC Client PCs are connected to features gigabit connections to each PC, plus a 10 gigabit uplink port. The switch can easily handle the 400 Mbps of data from each client (plus overhead). And the switch can pass this data along to the rest of the network at full speed, using the 10 Gigabit uplink.

The Destination machine is connected to a different switch, which also features a 10 Gigabit uplink port. But the switch port that connects to the Destination computer is only Gigabit, which will cause a bottleneck trying to send data coming in at 1600 Mbps. The Destination computer's network adapter is also Gigabit, and also a bottleneck. So the Destination computer – despite having a high-performance SAS RAID array – is limited by a gigabit NIC and gigabit switch connection: it can receive at most 100 MB per second.

Adding more ECC Clients to this collection would compound the performance bottleneck, as would collecting from ECC Clients equipped with high-performance SSD drives.

Several options are available to ensure collections do not overwhelm the network or unduly degrade performance.

If the collection has already begun, consider pausing some of the individual collection jobs for certain targets. Resume paused collection jobs in batches, until the entire collection has finished.

Schedule collections to run during evenings or weekends when network utilization is lowest.

Break up large collections into multiple collections. Each collection can have a unique Destination. Ideally, each Destination machine would reside on the same subnet as the ECC Client machines performing the collection.

Reconfigure hardware to improve performance. In the example, above, two gigabit network adapters in the Destination computer could be link-aggregated to two switch ports, doubling the network throughput of the Destination computer and eliminating the bottleneck.

Specify Destination paths residing on high-performance servers or NAS devices with plenty of free disk space. Ideally, these destination machines feature:

High-speed network connections: such as Gigabit Ethernet. Link aggregation can be used, where supported, to bind multiple NICs in a computer to multiple switch ports, to increase bandwidth. Newer 10 Gigabit Ethernet (and faster) technologies are available as well.

High-performance storage: high-rpm disks, RAID arrays and SAN storage systems offer varying degrees of performance. Enterprise-grade SSD drives offer the highest performance, but typically lack the capacity or cost-effectiveness to be used as collection destinations.

How can I determine where collection bottlenecks are occurring?

Collections running across a WAN or VPN connection are likely bottlenecks due to the limited speed of such connections.

To identify bottlenecks occurring on your LAN, create a "Performance Bottleneck Table", as described earlier in this FAQ. List each computer involved in a collection (including PCs running ECC Client, machines holding file collection Target locations, and machines serving as Destinations. Fill out the table with estimates of maximum sustained disk and network I/O speeds at each device, based on the published specifications for each device's hard disk and network adapter. The bottleneck may be apparent once you complete this table.

Run a few test collections with a smaller number of systems and see how close your estimates (from the Performance Bottleneck Table) compare to actual measured performance. Writing and reviewing a Performance Bottleneck Table for a smaller collection will give you a feel for the impact of a collection on your system. This may help you judge when to break up a large collection into multiple collections. Such testing may also point out the need to make hardware changes or select alternate hardware, e.g.:

Using link aggregation to team two NICs in a server to two switch ports, as a way to nearly double network I/O on a particular server.

Using a faster machine as a Destination server.

Your local Ethernet switch and router infrastructure can cause a bottleneck. Often, such bottlenecks can be identified by filling out a Performance Bottleneck Table. Dynamically monitoring the performance of your Ethernet network is another way to identify bottlenecks. Many managed switches, routers and VPN/firewalls offer a way to monitor network performance and identify bottlenecks. You can also use PRTG and similar network performance monitoring utilities to look for bottlenecks across your network.

Windows PerfMon can be configured on Microsoft Windows computers serving as collection Clients (workers), Target servers or Destination servers. PerfMon can provide insight into how disk I/O, processor, memory and network bandwidth are being utilized while a collection runs. PerfMon requires some resources and may impact overall performance somewhat.

The ECC Client machines can generate huge amounts of disk and network I/O. Nevertheless, bottlenecks tend to occur on Destination machines, and can also occur on low-performing Target machines, or any machine being accessed across a slower WAN or VPN connection.

Each ECC Client computer must "check in" with the ECC Server frequently. These frequent checks contribute to network traffic and can cause some delay when a large number of ECC Client computers are active. If you have more than 100 ECC Client computers consider increasing the default StatusUpdateTime value; for details see topic Configuring ECC Client Computers.

The ECC Server is relatively lightweight in its I/O demands, so it is rarely – if ever – a bottleneck. ECC Administration Console places light-to-moderate demands on ECC Server and the network. Whether ECC Administration Console is running while a collection is executing should make little difference in performance. But for larger installations with thousands of ECC Client computers, it is best to minimize the number of computers running ECC Admin Console at the same time.