Security planning

Review the following topics for information about how TrueSight Network Automation provides security and for recommendations on deploying securely:

Security assessment FAQs
Handling of web security vulnerabilities in TrueSight Network Automation
Data security

Security assessment FAQs

Question	Response
Does the product development follow a Security Development Lifecycle (SDL) process?	No. The Network Automation product does not follow a formal SDL process. However, many aspects of the SDL process are considered during our development lifecycle and are documented as follows.
Do you conduct security reviews? If so, what?	Yes. Security-related product testing is done as part of each release. In addition, the BMC AppSec team performs penetration and other security tests on our product prior to each release.
Do you use any tools to test for vulnerabilities?
Static Code Analysis tools	Yes. FindBugs is run against each nightly build. The results are analyzed frequently and all high severity items are addressed before product release.
Dynamic Code Analysis tools	Yes. Nexus IQ Server dependency checks are run against each nightly build. The results are analyzed frequently and all high severity items are addressed before product release.
Penetration testing tools	Yes. IBM AppsScan and Nessus are used by the BMC AppSec team to perform penetration testing before each release. The results are analyzed and all high severity items are addressed before product release.
Can you provide the results of these vulnerability reviews performed?	Yes. BMC can provide the report from the BMC AppSec team upon request.
Have you closed on vulnerabilities found for the subject application using these application security reviews?	Yes. All High/Severe issues are required to be closed before releasing the software as part of our Quality Certification (QCert) checkpoint; low/medium issues are reviewed and assessed on a case-by-case basis.
Are you committed to perform regular security reviews of the application and resolving vulnerabilities identified?	Yes, BMC is committed to resolve all Common Vulnerability Scoring System (CVSS) High and Critical vulnerabilities found in our code and remediate any found in 3^rd party components we include and ship with our product. BMC's AppSec team performs regular penetration tests during the product's release lifecycle. See www.bmc.com/security for BMC's disclosure and alert details. BMC and the Network Automation product are committed to monitor, find, and resolve security-related product issues both during our release process and after releases are available to customers. For the Network Automation Product: Nexus IQ Server 3^rd Party dependency checks are run and reviewed on every nightly build; issues are resolved shortly after they are detected 3^rd Party Dependencies are updated to the latest versions several times during our release lifecycle BMC AppSec team performs penetration and other security-related testing on the product at least once prior to release QA team runs AppsScan (penetration testing tool) regularly during the release lifecycle; issues are resolved shortly after they are detected BMC Quality Certification (QCert) contains a security section that all products must complete and pass before receiving executive sign-off for release
Is the product FIPS-140 compliant?	Yes. Network Automation is Federal Information Processing Standard (FIPS) Publication 140-2 compliant. Network Automation uses the RSA JSafeJCE security provider for FIPS compliance.
What type of encryption is used for storing sensitive data?	AES256 is used for storing sensitive data.
What type of encryption is used for communication between the application server and remote device agents, and agent and devices?	For communication between the Network Automation application server and the Network Automation remote device agents, Network Automation uses the TLSv1.2 handshaking protocol and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. For communication between the agent and devices, Network Automation establishes an SSH connection with the device. Network Automation supports the Advanced Encryption Standard (AES) algorithm with 128, 192, or 256-bit key lengths.
What kind of encryption is used when the database is not fully encrypted, for example, when using Oracle?	All passwords used for local authentication and in Device Security Profiles (DSPs) are encrypted. Configuration files do not reside in the file system but are encoded and stored in the database.

Handling of web security vulnerabilities in TrueSight Network Automation

Network Automation is capable of handling the following web security vulnerabilities:

Cross-Site Scripting (XSS) attack
Cross-Site Request Forgery (CSRF) attack
Brute force attack

XSS attacks

XSS attack is a type of web application vulnerability wherein an attacker can execute malicious scripts (also known as a malicious payload) into a legitimate website or web application. XSS enables attackers to inject a client-side script (usually JavaScript) into web pages that are to be viewed by other users through HTTP requests. Attackers can use this type of vulnerability to bypass access controls such as the same-origin policy.

To run the malicious JavaScript in the victim's browser, the attacker usually injects it into one of the pages that the victim downloads from the website. This can happen if the website directly includes user input in its pages.

CSRF attacks

CSRF attack is a type of vulnerability that forces users into submitting malicious requests and executing unwanted actions on a web application in which they are currently authenticated. This attack usually targets requests that cause a state change on the server, such as changing password for a user.

Network Automation prevents the CSRF attacks by associating a session token (also called CSRF token) with every state-changing request by a user. The server rejects the request with an error message if the token cannot be validated.

Brute force attacks

Brute force attack is a trial and error method used by application programs to obtain information such as a password or personal identification number (PIN). The application programs try to decode encrypted data through exhaustive efforts rather than employing intellectual strategies.

Network Automation prevents brute force attacks by locking a user. If a user provides an incorrect password while logging in to Network Automation, the user gets locked after a particular number of failed login attempts. Either the user gets unlocked automatically after a specific time period or a user with the Unlock Users right can unlock the user. For more details, see Locking-or-unlocking-users.

Data security

Network Automation is capable of using SSL and HTTPS for all communications between the Network Automation application server, Network Automation remote device agents, devices, and users. It is also capable of using secure protocols such as SSH and Secure Copy Protocol (SCP) to that extent that devices support them.

User access requires a user name and password. Fine-grained control for the roles and rights of users is provided; see the Managing-access.

Encrypting the Oracle external database

To manage devices in Network Automation, the infrastructure manager must be able to encrypt Network Automation data files on the file system and when performing client-server CRUD operations in the Oracle Database. Network Automation version 20.02 supports encryption for Oracle database 11g R2 and 12c.

Prerequisites

Ensure that you meet the following preconditions before encrypting the Oracle external database:

Network Automation is integrated with Oracle Enterprise database
Wireshark is installed on the computer on which Network Automation is installed

To enable network-level encryption on an existing TrueSight Network Automation server or a freshly installed server

Log on to the computer where Oracle Enterprise database has been installed.
Open sqlnet.ora located at %ORACLE_HOME%\NETWORK\ADMIN and add the following entries:
SQLNET.ENCRYPTION_SERVER = REQUESTED
SSL_CLIENT_AUTHENTICATION = true
SSL_CERT_REVOCATION = NONE
Restart the Network Automation server.
Use Wireshark to snoop and check whether the data is encrypted.

To enable Oracle transparent data encryption (TDE) on a fresh TrueSIght Network Automation installation

Create an Oracle database wallet with a master encryption key by using the tutorial at http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/11g/r2/prod/security/tde/tde.htm.
Verify that the DB vault has been created and is in the open state.
Create an encrypted Tablespace within the Oracle server.
Create a user on the Oracle server, which is tied with the encrypted Tablespace created in step 3.
Choose Oracle Database when installing Network Automation afresh, specify the user credentials created in step 4, and complete the installation.
Note
Do not create the Oracle user by using the Network Automation installation program.
Verify tables and database-related details from the Oracle Console.
Note
The database wallet must be open to enable the Network Automation server to access the database.

To enable Oracle TDE on an existing TrueSight Network Automation installation

Stop the Network Automation server.
Create a new encrypted Tablespace within the Oracle server.
Export the Network Automation database schema to a backup dump file.
Import the Network Automation database schema that is exported in step 3 to the newly created encrypted Tablespace. (Use the remap_tablespace=old_tablespace : encrypted_tablespace parameter).
Verify the database objects and data from the Oracle Console.
Start the Network Automation server and verify the integrity of the Network Automation server and all the data.
Note
The database wallet must be open to enable the Network Automation server to access the database.

Encrypting the SQL Server database

Enabling the network-level encryption on SQL Server

Network Automation 20.02 supports network-level encryption for the following SQL Server versions:

SQL Server 2016
SQL Server 2014
SQL Server 2012

To enable the network-level encryption

Log on to the SQL Server Configuration Manager.
Under SQL Server Network Configuration, double-click MSSQLSERVER.
On the Flags tab, check the value of the Force Encryption parameter.
- If the value of Force Encryption is set to Yes, you do not need to perform any steps on Network Automation. The network-level encryption is forced for all the communication.
- If the value of Force Encryption is set to No, while installing Network Automation, on the Database Information panel, in the Additional Database URL Options field, specify encrypt=true. For information about this field, see Installing-the-application-server-on-Windows or Installing-the-application-server-on-Linux.

Enabling SQL Server TDE

TDE uses Database Encryption Key (DEK) which is secured by a certificate and kept in the master database. DEK is either protected by certificate or an asymmetric key secured by Extensible Key Management (EKM) handler with the help of Microsoft Cryptographic API (MSCAPI). In TDE, data is encrypted using Advanced Encryption Standard (AES) and Triple Data Encryption Standard (3DES) encryption algorithms.

Network Automation version 20.02 supports TDE for the following SQL Server versions:

SQL Server 2016
SQL Server 2014
SQL Server 2012

Note

Network Automation supports TDE out-of-box and no changes are required on the Network Automation side. You need to make changes on the database side. Contact your database administrator to enable TDE.
The instructions provided in the following procedure are only for reference purpose. For detailed instructions, see the SQL Server documentation.

To enable SQL Server TDE

Create a master key with a strong password:
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>';
GO
Create a certificate:
CREATE CERTIFICATE <certificateName> WITH SUBJECT = '<subject>';
GO
Create the DEK with AES_128 algorithm using the certificate you created:
USE <databaseName>;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE <certificateName>;
GO
The following warning appears which indicates that you should back up the certificate and private key (DEK):
The certificate used for encrypting the database encryption key has not been backed up.
You should immediately back up the certificate and the private key associated with the certificate.
If the certificate ever becomes unavailable or if you must restore or attach the database on another server,
you must have backups of both the certificate and the private key or you will not be able to open the database.
(Optional) Back up the certificate and DEK:
USE master
GO
BACKUP CERTIFICATE <certificateName>
TO
FILE = 'C:\Backup\<certificateName>'
WITH PRIVATE KEY (FILE = 'C:\Backup\<DEK>', ENCRYPTION BY PASSWORD = '<password>')
GO
Enable encryption on the database that you want to enable for TDE:
ALTER DATABASE <databaseName>
SET ENCRYPTION ON;
GO
Verify certificate details and DEK details:
USE master
GO
SELECT encryptor_type, key_length, key_algorithm, encryption_state, create_date
FROM sys.dm_database_encryption_keys
GO
A value of 3 for encryption_state indicates that TDE has been enabled.