Scan Job needs a credential

When a job is provided to the scanning service, the service will receive the credential encrypted using the site public key. It will decrypt that credential using the site private key and remove the 128 bits of salt before sending it to the target.
The table below shows which keys are visible to the four components impacted by this design.

Device Credential s

Device credentials are used to login/access a remote device. Basic credentials are assigned to an associated protocol type and are used to establish the protocol connection to the remote device.
There are a number of cases when a two-stage process is required to access a remote device. Access of this type is typically through a proxy server and a two-stage credential set-up is required. The child credential is used to access the proxy server, the parent credential is used to issue a new command to access the remote device via the proxy server.
Note: credential escalation is different from the command escalation. Credential escalation uses an interim device to gain access to a remote target device. Command escalation is promoting a logged-in user's ability to execute a command on a remote device (e.g. by using the SUDO command).
Ordinary Credential Creation

Go through the following 5 steps to access credentials from the UI. This is covered in more depth in the User Guide.

Credential Escalation

The normal use of a credential is a direct login into a device. The scanning server takes the credential, creates a suitable connection and passes the credential over the connection to access the remote device.

Credential escalation is required when the above use of direct credentials login is not possible. The connectivity from the scan engine to the target does not allow a direct login into the remote device.

Parent credential: That provides the login user and password for a device or a group of devices. This credential should be created as if a direct connection to the device(s) was available. The only modification is that the connection type should be set to SSHProxy.
Child credential: The child credential provides a login user and password to access the proxy. The child credential allows the specification of the ongoing connection method and allows credential information provided in the parent credential to be used to remotely access the device through the proxy.
The parent child credential set allows this two-stage process to be created.

The Child credential (proxy credential) is likely to be shared between a number of Parent credentials. For this reason, once the child credential is attached to a parent credential, the child is no longer editable from the UI. This is to ensure that modification to the proxy credential is modified in a controlled manner.
Windows

We recommend using local admin rights on the Windows device being scanned to gather important system information via the Windows Registry and Windows Management Instrumentation (WMI). Local admin enables us to limit effects to individual machines while still maintaining control for optimal performance.
Note: The Scan Engine defaults to local admin rights. However, this is not a requirement, and the system can be configured to accommodate other roles with privileges sufficient to scan.
We recommend that you create a domain account which is added to the local administrator group across the domain.
While it is possible to configure WMI and the Registry to utilize other credentials other than local admin, local admin ensures that all domain-joined devices can be properly inventoried. Domain-joined Windows Servers and PCs utilize a Microsoft implementation of the Kerberos security protocol for secure login.
Use Active Directory policies and/or other mechanisms to restrict the account being used for scanning to the minimum required permission set. Such restrictions include:

• Disabling the account when scanning is not active.
• Limiting access to the remote device for this credential from the scanning server.
• Setting the account to be a non-interactive login (sometimes called service-only account).
• Using a one-way single trust relationship, so that authentication requests can only be passed from the domain in which the device to be scanned is in to the domain in which the scanning server is in.
• Using a firewall to block non-needed traffic.

Windows Remote Process Data Retrieval

The Scan Engine gathers the process information using the WMI protocol. This process creates a temporary file on the target machine. The credential used in scan operations must have the appropriate privileges to create this temporary file.
UNIX

When accessing UNIX and Linux systems, it is provided the option of either using Telnet or Secure Shell (SSH). We recommend the use of SSH to ensure the security of authentication credentials.
SSH proxy communication is possible and credential considerations are covered in Section 4.2.
The Scan Engine utilizes a variety of commands in order to retrieve as much relevant inventory data as possible from UNIX and Linux devices. The commands used are listed in the Command Access section of the Scan Prerequisites document. The credentials provided to the Scan Engine must have the authorization to run these commands.
Application Credentials

Oracle

To gather detailed information required for an audit of Oracle, the Scan Engine needs to log on to the database and read certain tables. The user account used to access Oracle will require specific access privileges. The Oracle permissions are discussed in Section 5.3 of the Scan Prerequisites document.
MS SQL User

To gather detailed information required for an audit of Microsoft SQL Server, the Scan Engine needs to log on to the database with specific access privileges. The MS SQL permissions are discussed in Section 5.4 of the Scan Prerequisites document.
INFORMIX User

To gather detailed information required for an audit of Informix, the Scan Engine needs to log on to the database with specific access privileges. The Informix permissions are discussed in Section 5.5 of the Scan Prerequisites document.
ESX Access

To enable scanning of VMware ESX versions, the Scan Engine requires access to the VMware vSphere Web Services. The vSphere permissions are discussed in Section 5.1.1 of the the Scan Prerequisites document.
IBM PowerVM

To enable scanning of IBM PowerVM Virtualization environments, the Scan Engine requires SSH or Telnet access to the Hardware Management Console(s) (HMC) used to connect to the Managed Frames.  The HMC permissions are discussed in Section 5.1.2 of the Scan Prerequisites document.


User Interface Security

The UI has undergone penetration testing (PENTEST) by an external consultancy company.
Data Transfer between the UI and the Scan Engine database

UI to database

The Scan Engine submits data to the database via an authenticated SQL client server connection. Windows Server Internet Protocol security (IPsec) can be used to provide an additional layer of authentication and encryption for all data exchanged between the Scan Engine servers.
Secure Sockets Layer (SSL)

All cookie information will encrypted and secured when accessing the User Interface to prevent any monitoring of traffic between the server and any client machines. The UI will be configured to use the SSL provided a Certificate and HTTPS binding exists for the Default Web Site before an installation of the Scan Engine.
Database and Connection String Encryption

All information is stored in a SQL Server database. Manual queries and adding or removing information from the database requires a connection string and an associated set of login credentials.
This connection string is encrypted and includes:

• The server name
• The database name
• The security credentials required to access the database.

We can also add parameters to the connection string to encrypt the connection.
SQL Injection Attacks

SQL injections insert SQL commands into an SQL statement via webpage input. SQL injections input by malicious users alter SQL statements and compromise the security of a web application.
The Scan Engine uses parameterized queries and stored procedures to mitigate SQL Injection attacks.

• Parameterized queries use bound, typed parameters that keep the query and data separate through the use of placeholders known as bound parameters.
• Stored procedures help to create a layer of abstraction that limits the amount of information supplied by the webpage when connecting to the database via a web based query.

The common language runtime (CLR) functions in the Scan Engine operate with permissions set to safe, which means the managed code executing in the construct is unable to access external resources.
Cross Site Scripting Attacks

To prevent cross-site scripting (XSS) attacks, the Scan Engine uses a variety of security techniques on both input and output data.

• Input data: The Scan Engine validates and constrains input data to ensure submitted content is free of dangerous client-side scripts.
• Output data: The Scan Engine implements encoded output and encoded output URLs. Encoded output converts characters with unique HTML meaning into harmless HTML characters.

User Interface Access

Overview

The UI displays data and allows for scans and services to be started and stopped.
A user interface which has been compromised, using a technique such as session hijacking, could allow an attacker unauthorised access to the Scan Engine functions. A malicious user with access to these functions could affect the scan engine by stopping the service from running. It could also allow a malicious user to reconfigure the system and alter credentials. These risks are mitigated by the actions suggested in Security Recommendations in this document.
Login Management

All users are required to login before gaining the ability to access other UI pages. This is the first line of defense to prevent attacks.
See the table below for information on login security.

Note: These are the default security settings. These settings can be configured to suit the unique security needs of your organization.
Accounts and Roles

The Scan Engine uses an administrative account with a default username and password for demos and company use. However, the default credentials should be replaced with usernames and passwords that comply with the organization's security policy for a client installation.
The Scan Engine allows for multiple user accounts to be created and all accounts can fall under customer specific roles. The Scan Engine comes with the following default role:

Page Level Permissions

It is supported page level permissions within the UI to allow control of which roles can access which pages.
Device Security Considerations

Agentless

The Scan Engine is agentless and makes no changes to the servers scanned in any way. No temporary files are created, and no scripts are copied to the target device or application being scanned See Windows Remote Process Data Retrieval for the single exception to this rule.
The set of commands issued by the scan engine are standard commands A number of the commands issued are privileged commands, e.g. dmidecode, available as standard on the target O/S. It is generally not possible to get the scan engine to run additional commands without referring to iQuate to create new versions of the product or using encrypted extension capabilities.
Denial of Service (DoS)

The Scan Engine architecture is self-throttling and will only attempt to scan a device or application when the available resources are available. Additionally, Scan Engine will only attempt to scan a particular IP address a maximum number of times (specified through the UI). This design prevents the scanning server from causing DoS type situations due to unintentional or intentional misconfiguration.
Ports

The ports used for discovery scans are defined within the UI and a typical installation of the Scan Engine would be behind the organization's firewall. The Scan Engine does not mandate the modification of firewall rules or exceptions.
Security Considerations

Binaries and code

All Scan Engine binaries are built upon .NET and take advantage of the provided security framework. Several measures are built-in for security including specialized .NET encryption to ensure the integrity of each binary in the release. Any screening of these binaries will show the author as iQuate.
iQuate can generate a checksum of the deliverable release installer and product binaries within the installer. These checksums can be verified by the person installing the software on the designated server to ensure no infection has occurred in transit.
Strict software revision tracking is employed internally in iQuate. This logs all changes to files across each release. Physical access to the source repositories servers is restricted, as is remote server access.
Access to the Database and Security

The Scan Engine database contains all the critical credentials and configuration data required to run. The security credentials required to access the database are protected and stored in an encrypted config file. The config file cannot be used on another machine, because the encryption mechanisms required to encrypt and unencrypt the config file are machine specific. NTFS permissions should be used to provide an additional layer of security to the config file. This prevents unauthorized users from being able to see or access the encrypted file.
Without the connection string to the database, the only way to gain access to the iQSonar Scan Engine would be to acquire local log on administrative rights to the server that houses the Scan Engine database.
Securing physical access is beyond the scope of this document.
Internet Connectivity and Updates

The operation of the Scan Engine does not require external internet access. By default the scanning server makes a single license request once every 24 hours outside the network to a licensing server, but this is optional and is not required. iQSonar iQSonar does not download any configuration information or update information from the internet. All software updates must be installed by the organization.
Personal Credentials

The Scan Engine does not collect any user's credentials when scanning machines in a network.
Information that may be considered falling within the Personally Identifiable Information (PII) domain can be collected. Typical information that may fall into this domain is the login names (and associated e-mail addresses) information associated with Oracle and SQL server application usage. This may be considered PII depending on the customer definition of PII.
Data such as credit card information is not collected.
Security Recommendations

Our aim is to ensure optimal security for clients. Go through the list below to see our recommendations based on the defense in depth security approach.

Data Policy

iQuate follows careful processes in relation to client data management before, during, and after engagements.
Data Review

Before any confidential data is reviewed or exchanged between iQuate and a client, a Non-Disclosure Agreement (NDA) is put in place. The terms of the NDA govern the subsequent sharing and management of data.
All data gathered by the Scan Engine remains on the client's server under the control of the client's administration team. 
When data must be exchanged outside of the client's network, the client's preferred secure mechanism for document sharing such as an extranet or document management system can be used.
Data Retention and Disposal

• iQuate's default policy is to retain client data so long as the contract is valid.
• Upon request, iQuate can dispose of client data immediately after the end of a contract or retain the information internally for future use.

Appendix A – Key Terms

[This page is left intentionally blank]