Recovery Manager for AD 10.3.2

Table of Contents

Introduction About Recovery Manager for Active Directory Architecture Overview Overview of Data Handled by RMAD Location of Customer Data Privacy and Protection of Customer Data Network Communications Authentication of Users and Services Role Based Access Control FIPS 140-2 compliance SDLC and SDL Customer Measures Globalization Third-Party Contributions

Role Based Access Control

Currently, Recovery Manager for Active Directory does not allow granular permission delegation for product settings and operations. Any locally logged-on accounts with local administrative rights will be able to gain control over the entire Recovery Manager functionality.

This requires ensuring that the security level for access to the machine with the Recovery Manager console is no lower than the security level for access to other parts of the Active Directory infrastructure.

FIPS 140-2 compliance

Backup encryption

RMAD allows backups to be encrypted and protected with a password, to prevent unauthorized access.

For Active Directory backup encryption, the product uses FIPS 140-2 validated AES-256 algorithms.

Table 1: Encryption of Backup Files

^{Cryptographic usage}	^{Cryptographic algorithm}	^{Cryptographic parameters}	^{Third-Party libraries}	^{FIPS 140-2 Certificates Windows Server 2016}
^{Symmetric encryption of bulk data}	^AES256	^{Key Encryption Key: CryptDeriveKey - CALG_AES_256 AES256 Mode: CRYPT_MODE_CBC Salt: CryptGenRandom - 16}	^{CryptoAPI (crypt32.lib) WMI: Win32_EncryptableVolume class}	^{AES: #4064, #5295 and #C2046}
^{Asymmetric encryption of bulk data}	^RSA	^{RSA Key Pair: CryptAcquireContext - PROV_RSA_AES CryptGenKey - CALG_RSA_KEYX}	^{CryptoAPI (crypt32.lib)}	^{RSA: #2192, #2193, #2195, #2833, #2834, #2847, #C2046 and #C2065}
^{Key Derivation}	^PDKDF2	^{Key Size = SHA512 ::BCryptOpenAlgorithm Provider - BCRYPT_SHA512_ALGORITHM, BCRYPT_ALG_HANDLE_HMAC_FLAG BCryptDeriveKeyPBKDF2 – iterations used meet 600,000 minimum requirement}	^{Cryptography Next Generation API (bcrypt.lib)}	^{PBKDF: Vendor affirmed}

Table 2: Encryption of Forest Recovery Project Files

^{Cryptographic usage}	^{Cryptographic algorithm}	^{Cryptographic parameters}	^{Third-Party libraries}	^{FIPS 140-2 Certificates Windows Server 2016}
^{Symmetric encryption of bulk data}	^AES256	^{Key Encryption Key: CryptDeriveKey - CALG_AES_256 AES256 Mode: CRYPT_MODE_CBC Salt: CryptGenRandom - 32}	^{System.Security.Cryptography.Algorithms.dll System.Security.Cryptography.Csp.dll System.Security.Cryptography.Primitives.dll mscorlib.dll netstandard.dll}	^{AES: #4064, #5295 and #C2046}
^{Key Derivation}	^PDKDF2	^{Key Size = SHA512 PaddingMode.PKCS7 Rfc2898DeriveBytes - iterations used meet 600,000 minimum requirement}	^{System.Security.Cryptography.Algorithms.dll System.Security.Cryptography.Csp.dll System.Security.Cryptography.Primitives.dll mscorlib.dll netstandard.dll}	^{PBKDF: Vendor affirmed}

Table 3: Encryption of Credentials

^{Cryptographic usage}	^{Cryptographic algorithm}	^{Cryptographic parameters}	^{Third-Party libraries}	^{FIPS 140-2 Certificates Windows Server 2016}
^{Symmetric encryption of secrets}	^AES256	^{DPAPI using CRYPTPROTECT_LOCAL_MACHINE flag, AES256-CBC algorithm Hash – SHA512 Random password - 16 bytes}	^{CryptoAPI (crypt32.lib) DPAPI (crypt32.lib)}	^{AES: #4064, #5295 and #C2046}

Table 4: Communication

^{Cryptographic usage}	^{Cryptographic algorithm}	^{Cryptographic parameters}	^{Third-Party libraries}	^{FIPS 140-2 Certificates Windows Server 2016}
^{Communication}	^{WCF TCP Transport Security,RPC over Schannel}	^{System.Net.Security. ProtectionLevel. EncryptAndSign; RPC_C_AUTHN_LEVEL_PKT_PRIVACY}	^{bcrypt.dll or bcryptprimitives.dll}	^#2937
^{Communication}	^{SSL TLS 1.2}	^{Negotiated by GSS (RPC over Schannel)}	^{Microsoft.Bcryptprimitives.dll or Bcrypt.dll}	^#2937

Recovery Manager for Active Directory has undergone a Quest internal Self-Affirmation process to confirm that all cryptographic usage relies exclusively on Third-Party FIPS 140-2 validated modules.

More information:

Microsoft and FIPS: https://www.microsoft.com/en-us/trustcenter/compliance/fips
Microsoft FIPS backgrounder: https://aka.ms/fips-backgrounder

SDLC and SDL

The Recovery Manager for Active Directory team follows a strict Quality Assurance cycle.

Access to source control and build systems is protected by domain security, meaning that only employees on Quest’s corporate network have access to these systems. Therefore, should a developer leave the company, this individual will no longer be able to access source control and build systems.
All code is versioned in source control.
All product code is reviewed by another developer before check in.

In addition, the Recovery Manager for Active Directory team follows a managed Security Development Lifecycle (SDL) which includes:

MS-SDL best practices.
Threat modeling.
OWASP guidelines.
Regularly scheduled static code analysis is performed on regular basis.
Regularly scheduled vulnerability scanning is performed on regular basis.
Recovery Manager for Active Directory has been validated in a Secure Technical Implementation Guidelines (STIG) environment. See Security Technical Implementation Guides (STIGs) for more information.

Recovery Manager for Active Directory developers go through the same set of hiring processes and background checks as other Quest employees.

Customer Measures

Recovery Manager for Active Directory security features are only one part of a secure environment. Customers should follow their own security best practices when deploying Recovery Manager for Active Directory within their environment.

Please select your product:

To serve you better, please complete the Purpose of your Chat:

Recommended Solutions for Your Problem

Recovery Manager for AD 10.3.2 - Security Guide

Role Based Access Control

FIPS 140-2 compliance

Backup encryption

SDLC and SDL

Customer Measures