BluSKY Data Security

Overview 

Security Considerations

Communications

• All communications through the website are over TLS
• All communications to the panel are over TLS
• All communications between the panel and OSDP Readers can be over TLS
• In short, all data in transit is encrypted

Login credentials

• All login credentials are stored as a one-way hash – nobody at BB knows your password or can log in as you
• All change activity to passwords (who, when, but not what) are stored in a separate audit table, so anyone trying to change passwords cannot cover their tracks
• Changes to personnel, access rights, roles, permissions, hardware states, and operator activity are all audited and can be reported on as well as used for IFTTT rules
• Login credential changes are confirmed via 2-Factor authentication
• ASP.NET Identity supports OWIN – possible to integrate with Facebook, Google, and other authentication providers

Physical Access

• All data and servers are located inside of Microsoft Azure datacenters.
  • There is NO outside access allowed
  • Microsoft’s ability to maintain security standards through 3rd party certifications far exceeds smaller organizations’ ability to do so
    • ISO/IEC 27018, ISO 27001, HIPAA, FedRAMP, SOC 1 and SOC 2, as well as country-specific standards like Australia IRAP, UK G-Cloud, and Singapore MTCS.
  • https://www.microsoft.com/en-us/Trus...e/default.aspx

Logical Access

• Access to data remotely via the Azure portal is strictly locked down
  • IP based filtering
  • User-based filtering
• Audit logs

Backups

• Automated, real-time geographical replication
• Automated incremental backups hourly
• All disk-based backup = No tapes to “walk away”

Security of Data in Transit

When people think of data security, they often think of the data being secured on the server or when it is backed up for off-site storage. This is only a small part of the overall solution. In order to be truly safe, data needs to be protected both while “at rest” on the server and while “in transit”, when it is being displayed in your browser or transferred to your access control panels. BluBØX uses proven, industry-standard techniques to ensure that all of your data is safe while it is moving between machines. We will discuss further details on subsequent pages.

When the SSL protocol (used by HTTPS) was standardized by the IETF, it was renamed to Transport Layer Security (TLS). Many people use the terms TLS and SSL interchangeably, but they are technically different since each describes a different version of the protocol. In the past year, SSL v3 has been deemed insecure and we have disabled this “fall back” strategy on our servers. All communications now use TLS.

When TLS is used correctly, a third-party observer can only infer the connection endpoints (IP address), type of encryption, as well as the frequency and an approximate amount of data sent, but cannot read or modify any of the actual data. Since HTTPS (on the web browser) and TLS (used by the panels) are fundamentally the same things – they both use the same industry-standard technology of trusted certificates.

Certificates are the key to the security, so let’s take a closer look at how they work. The TLS process that is used by both the website and the panels uses certificates and cipher keys to ensure a secure connection.

A TLS connection between a client and a server is set up by a handshake, the goals of which are:

• To validate to the client that it is talking to the right server
• For the client and server to agree on a cipher suite, which includes which encryption algorithm will be used to exchange data
• For the parties to agree on any necessary keys for this algorithm

Once the handshake is completed, each party can use the agreed algorithm and keys to securely send messages to each other.

The Digital Handshake

1. Hello - The handshake begins with the client sending a “ClientHello” message. This contains all the information the server needs in order to connect to the client via TLS, including the various ciphers and TLS version that it supports. The server responds with a “ServerHello” message, which contains similar information required by the client and a decision from the client’s preferences about which cipher suite and version of TLS will be used.
2. Certificate Exchange - Now that communication has been established, the server has to prove its identity to the client. This is achieved using its certificate, which contains the owner, the domain or machine it is attached to, the certificate’s public key, the digital signature and the certificate’s valid date range. The client then decides if it either explicitly trusts the certificate because it matches one in its stored list, or if it has been verified and trusted by one of the Certificate Authorities (CAs) that it implicitly trusts.
3. Key Exchange - The encryption of the actual data exchanged by the client and server will be done via a “symmetric algorithm”, which was agreed upon during the Hello phase. A symmetric algorithm uses the same key for both encryption and decryption, whereas an “asymmetric algorithm” requires a public/private key pair. Both parties need to agree on and use the same symmetric key, and this process is accomplished securely by asymmetric encryption using the server’s public/private keys.

How Key Exchange Works: The client starts by generating a random key which it is proposing to be used for the ongoing communications via the symmetric algorithm. It encrypts this key using the server’s public key and sends this encrypted key to the server, where it is decrypted using the server’s private key. Since only the server knows its private key, and only the private key can decrypt the proposed symmetric key, only the server and the client now know the secret key to be used between each other. HTTP messages can now be sent securely. The other party is the only one who knows how to decrypt this message, and so Man In The Middle Attackers are unable to read or modify any requests that they may try to intercept.

Why would the client trust a certificate?

There are two sensible reasons why a client might trust a certificate:

• If it’s on a list of certificates that the client has in its store of trusted certificates
• If it’s able to prove that it is trusted by the certificate authority of one of the certificates on the above list

The first method is easy to validate. Every browser has a pre-installed list of trusted certificates from Certificate Authorities (CAs) that you can manage. These certificates are controlled by trustworthy organizations like Symantec, DigiCert and GoDaddy. You can also add your own explicit certificates to the list. If a server returns a certificate from that list then you know you can trust it.

The second method is more complicated. It’s easy for a server to tell you that Symantec or DigiCert “knows” them and that you should trust them, too. But if the client asked Symantec if they “know” the server, there is no way for Symantec to know for certain, since they aren’t part of the direct conversation. This is where digital signatures come in.

What is a Digital Signature and how does it work?

As already discussed, certificates have an associated public/private key pair. The public key is distributed as part of all certificates, and the private key is kept safely guarded by the owner. This pair of asymmetric keys is used in the TLS handshake to enable the exchange of a symmetrical key that both parties will use to encrypt and decrypt data. The client uses the server’s public key to encrypt the symmetric key and sends it securely to the server. Then the server uses its private key to decrypt it. Anyone can encrypt using the public key, but only the server can decrypt using the private key (because it is safely guarded and not shared with anyone).

The opposite is true for digital signatures. A certificate can be “signed” by another authority, whereby the authority certifies that they have verified that the owner of the certificate also owns the domain or machine listed on the certificate. In this case, the authority uses their private key to encrypt the contents of the certificate, and this cipher text is attached to the certificate as its digital signature. Anyone can decrypt this signature using the authority’s public key, and verify the results. But only the authority can encrypt content using the private key, and so only the authority can actually create a valid signature in the first place.

So if a server comes along claiming to have a certificate for blusky.blub0x.com that is signed by GoDaddy (or some other CA), your browser doesn’t have to take its word for it. If it is legitimate, GoDaddy will have used their secret, private key to generate the digital signature on the server’s TLS cert, and your browser can then use can use their public key to check that this signature is valid. GoDaddy has already taken steps to ensure that BluBØX really does own blusky.blub0x.com, and so given that your client trusts GoDaddy, it can be sure that it really is talking to BluBØX Security, Inc.