Threats

The following sections describe some of the possible threats to IG, which you can mitigate by following the instructions in this guide.

Reconnaissance

The initial phase of an attack sequence is often reconnaissance. Limit the amount of information available to attackers during reconnaissance, as follows:

Avoid using words that help to identify IG in error messages, such as those produced by the entity in a StaticResponseHandler. For information, see StaticResponseHandler.
Reduce the global log level from TRACE or DEBUG to INFO. For information, see Changing the Global Log Level.

Cross-Site Scripting

In Cross-Site Scripting (CSS) attacks, malicious scripts are injected into otherwise benign and trusted websites. When you are using a StaticResponseHandler, secure responses from cross-site scripting, as follows:

Sanitize any external input, such as the request, before incorporating it in the response.
Specify Content-Type in the headers property of StaticResponseHandler when an entity is used. (Required by default, from IG 7.)
Set the response header X-Content-Type-Options: nosniff to prevent the user agent from interpreting the response entity as a different content type. (Set by default, from IG 7.)
Set a restrictive value in the Cache-Control response header. For example, setting Cache-Control: private indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache.

Compromised Passwords

Despite efforts to improve how people manage passwords, users have more passwords than ever before, and many use weak passwords. You can use identity and access management services to avoid password proliferation, and you can ensure the safety of passwords that you cannot eliminate.

Manage passwords for server administration securely. Passwords supplied to IG can be provided in files, through environment variables, or as system property values. Choose the approach that is most appropriate and secure for your deployment.

Misconfiguration

Misconfiguration can arise from bad or mistaken configuration decisions, and from poor change management, causing the following behaviour:

Routes fail to load, or succeed in loading but cause unexpected behaviour.

Depending on the configuration error, features can stop working in obvious or subtle ways.

For example, if a configuration change prevents the server from making HTTPS connections, many applications can no longer connect, and the problem is detected immediately. However, if a configuration change allows insecure TLS protocol versions or cipher suites for HTTPS connections, some applications negotiate insecure TLS, but appear to continue to work properly.
Access policy is not correctly enforced.

Incorrect parameters for secure connections and incorrect ACIs can lead to overly permissive access to data, and potentially to a security breach.
The server fails to restart.

Although failure to start a server is not directly a threat to security, it can affect service availability.

To guard against bad configuration decisions, implement good change management:

For all enabled features, document why they are enabled and what your configuration choices mean. This implies review of configuration settings, including default settings that you accept.
Validate configuration decisions with thorough testing.
Maintain a record of your configurations and the changes applied.

For example, use a filtered audit log. Use version control software for any configuration scripts and to record changes to configuration files.
Maintain a record of external changes on the system, such as changes to operating system configuration, and updates to software such as the JVM that introduce security changes.

Unauthorized Access

Data theft can occur when access policies are too permissive, and when the credentials to gain access are too easily cracked. It can also occur when the data is not protected, when administrative roles are too permissive, and when administrative credentials are poorly managed.

Poor Risk Management

Threats can arise when plans fail to account for outside risks. To mitigate risk, develop appropriate answers to at least the following questions:

What happens when a server or an entire data center becomes unavailable?
How do you remedy a serious security issue in the service, either in the IG software or the connected systems?
How do you validate mitigation plans and remedial actions?
How do client applications work when the IG offline?

If client applications require always-on services, how do your operations ensure high availability, even when a server goes offline?

For critical services, test expected operation and disaster recovery operation.

IG 7.1.2