Security & Timestamping

Complex Password Requirements

Using a simple userID and password to authenticate to an application has not been considered best practice for several years. Most users create passwords that are guessed easily or can be brute-forced with little effort. For a password alone to be considered reasonably strong, there needs to be at least 15 characters with a combination of upper case letters, lower case letters, numbers and special characters. Few applications require their users to meet such a stringent standard since users will quickly protest over this requirement.

Multi-Factor Authentication

Forensic Notes recognizes that a truly strong password policy can adversely impact the usability of the site. Instead, we leverage the Multi-Factor Authentication (MFA) option provided natively by Microsoft Azure. Registered users who correctly authenticate through their userID and a strong password will receive either a voice call or an SMS message to the mobile phone registered to their Forensic Notes profile. When they correctly respond to this challenge, they will be allowed access to the Forensic Notes application.

If the user does not have possession of the authentication device (ie: cellphone), then access will be denied.

Document Integrity

When presenting your Forensic Notes within a civil or criminal case, it’s critical to prove the sequence of events and when an entry was made to the case file. Forensic Notes recognizes this need and uses a trusted third party service to timestamp each entry.

All entries, uploaded documents, and files are stored in read-only format. This reduces the opportunity for data corruption and improves the integrity of the notes and files over the long term.

RFC 3161 Compliant Timestamps

Time stamps are RFC 3161 compliant. This means that your Forensic Notes are validated with a timestamp standard accepted throughout the Industrialized World. This allows you to demonstrate to the courts, or whatever authority you are testifying before, that your Forensic Notes were made at a particular time and that the notes have not been modified surreptitiously.

For more information on our trusted Timestamping Authority (TSA), view the Timestamping Authority – TSA page.

Saving your Forensic Note

The Forensic Notes application ensures that all communication between the client’s device and the Forensic Notes server is encrypted via an Extended Validation (EV) TLS/SSL certificate. Each Forensic Note is encrypted with a unique 256-bit symmetric encryption key prior to being stored within SQL Server. This unique encryption key is known as a Content Encryption Key (CEK).

After the CEK is generated, it is transmitted to the Azure Key Vault HSM which then encrypts the CEK using the public key of a 2048-bit asymmetric encryption key. This asymmetric encryption key is known as the Key Encryption Key (KEK). The KEK is created within the Azure Key Vault HSM which ensures that the private key required for decryption can never be viewed or exported for use in other applications. As a result, all decryption of CEK’s must occur within the HSM.

Finally, the encrypted CEK is then returned to the Forensic Notes server where it is stored securely for future use within the SQL Server.

TLS/SSL Certificate Details

Forensic Notes uses an Extended Validation (EV) certificate issued by Comodo Inc., a Certificate Authority (CA) leader. Extended Validation certificates are only issued after a rigorous verification process that validates key details about the requesting organization.

View Comodo’s Extended Validation (EV) information page for further details.

Viewing your Forensic Note

When a user accesses their data within the Forensic Notes application, the encrypted note and any associated attachments the user had added previously are decrypted by a two-step process. First, the Content Encryption Key (CEK) that is required to decrypt the user’s data must first itself be decrypted. The encrypted CEK is sent securely to Azure Key Vault HSM to be decrypted by the asymmetric KEK’s private key. Once decrypted, the symmetric CEK can now be used to decrypt the data associated to the Forensic Note.

Each Account can have a unique* KEK protected by the Azure Key Vault HSM that is used for the CEK encryption / decryption process.

Note: See “Saving your Forensic Note” above for further technical details regarding the CEK and KEK

Client Managed Encryption Keys

Enterprise clients are able to setup and manage their own Key Encryption Keys (KEK) within Azure Key Vault which allows the administrator to provide and deny access as they deem appropriate to the Forensic Notes application. Revoking access to the KEK would deem all Forensic Notes saved within that specific account unusable as there would be no known way to decrypt the information.

* Separate encryption keys are only included with select accounts. All other accounts utilize a common shared encryption key which is stored within Azure Key Vault HSM.

Data at Rest

Forensic Notes uses Transparent Data Encryption (TDE) and the Azure SQL Database managed service. The Azure SQL Database managed service creates a unique certificate for every database instance. These certificates are recycled at least every 90 days to keep in line with security best practices. The certificate is protected by a different key for each server.

Data at rest is protected by at least two layers of cryptographic services. The application encrypts data, documents and files as they are written to the database instance in the Azure SQL Database service. Additionally, the database instance is protected by a unique key on the database server. This, in turn, is protected by the server certificate.

Azure Key Vault Security

As indicated earlier, the Key Vault addresses key management as if it were a Cryptographic Service Provider. Access to the Key Vault and the HSM components are carefully controlled using multi-factor authentication, frequent changes in passwords, and four eye control where two security administrators must be present to conduct maintenance or administration of the Key Vault and its component Hardware Security Modules (HSM). This reduces the complexity and risk generally associated with Key Management. As a callable service, use of the Key Vault allows for future distribution of the application and its managed database services across a wide geographic area.

Finally, keys are replaced on a regular basis according to industry best practices

Encrypted Channels of Communication

From the moment you access the Forensic Notes application, your data travels in an encrypted path protected from unauthorized viewing. The session with Forensic Notes is protected through Transport Layer Security (TLS) which replaced SSL in most current browser versions and web hosting software. Both TLS and SSL use public/private key (asynchronous) encryption.

Once inside the Azure environment, Microsoft leverages its extensive experience in building and running some of the world’s largest online services to protect communications between the components of the infrastructure. While details of their specific configuration are proprietary, best practices require them to use IPSEC VPNs using synchronous encryption with key lengths of AES 256 or stronger.

Azure Penetration Testing & Audits

Additionally, as an enterprise-class service provider that supports both commercial and government clients, Azure is continually monitored and reviewed by third parties to assure the Azure customer base that Microsoft is meeting all standards in protecting their data and communications. This continual monitoring includes regular threat assessments, vulnerability reviews, and penetration testing.

The Microsoft Azure environment is compliant with over 20 different standards, both industry and government, that are required by different countries and organizations around the world. These standards are listed at https://azure.microsoft.com/en-us/support/trust-center/compliance/.