Improve Forensic Visibility Within Your Network

Here's an article I wrote for RSA regarding how to improve forensic visibility within your network:

http://blogs.rsa.com/improving-forensic-visibility-throughout-a-complex-network/

Quick Primer on Ciphers, Protocols and Certificates

Transport Layer Security (TLS) and Secure Socket Layer (SSL) are cryptographic protocols meant to secure the communications from client to server over either internal or external networks. This is meant to ensure that the privacy and security of data being transferred over a network is secure from tampering or theft. We see these protocols used heavily in web browsers to connect to web servers offering the ability to perform transaction securely on their webpages.

The TLS protocol is the predecessor to the now aged SSL protocol and has variants that are widely used to encrypt and transfer secure data across the internet. The SSL protocol v3.0 is still used on certain systems, due to old hardware/operating systems, etc., but it’s been extensively disabled due to inherent security risks within the protocol. The newer TLS protocol has three versions, v1.0, v1.1 and v1.2 with versions 1.1 and 1.2 being deemed most secure. As of earlier this year the PCI council deemed that both SSL 3.0 and TLS 1.0 have been classified as insecure protocols and should be disabled on all services offering the ability to select this protocol. It’s not enough to have it dropped in priority, since it’s still possible that it could be chosen by older browsers, or by attackers using threats like BEAST/POODLE/DROWN that could attempt downgrade attacks to misuse the vulnerable SSL 2.0 & 3.0 protocol. At this point, the recommendation is to enable only TLS v1.1 and v1.2 due to security concerns with the lower versions.

After a network protocol is agreed upon by both client and server a cipher is determined next. This all happens with the negotiation between client and server and based off which network protocol will be in use will also assist with determining the cipher lists available for selection between client and server. Most of the secure ciphers that offer the best security are within TLS 1.1 and TLS 1.2 and in regards to TLS 1.2, it’s the only protocol that has the ability to run the secure GCM ciphers. These ciphers are more secure than their CBC predecessors. As with all things in encryption, the larger the key the better encryption, so looking at the ciphers this way helps too. These ciphers will be used going forward to encrypt data from client to server. 

Using these technologies with certificates allows for authentication of another party to validate that the server the client is attaching to is who they say they are. The certificate itself doesn’t have anything to do with the selection of the network protocol (SSL 3.0, or TLS 1.2, etc.), or the cipher suite that will be used afterwards. These are selected by the client and server, normally the client browser and the server’s operating system agreeing on how to secure the data in transit. When certificates are involved it’s verifying, normally via a third party certificate authority (like Verisign or GoDaddy) that the website you’re accessing is the actual server you’re intending on viewing. Certificates are used as a way of your browser trusting that you’re going to a legitimate website. The encryption happens based off the machine negotiation, not with the presence of a certificate. Data can still be sent securely, but you’re never sure from a client perspective if you’re sending data to the “real” server unless it’s been verified by a third party certificate. 

All these aspects, network protocols, ciphers and certificates, when used in tandem, give us the ability to have secure communications over the internet and protect the security and privacy of our data.

WhatsApp the Latest Target for Government Backdoor

Here's a great article from the NYTimes regarding how WhatsApp is now the latest target of the government encryption debate. We all knew this was coming - I wrote about the potential threat of the government going after other companies, specifically those developing mobile apps, and it seems like this will soon be the norm. You can read my article here.

What Happens If the FBI Beats Apple?

The battle for the San Bernardino iPhone is raging in the news and it’s pointing a large light on just how important mobile data has become.  This case will cause precedence on how a government entity will be allowed to request, or have direct access to, an individual’s private data. Apple is taking the stance that their user’s privacy is under attack if they give up the ability for others to access it freely. On the flip side the government is under the viewpoint that our national security is at risk if they can’t view it. No matter where you stand on this issue personally, it’s interesting to see that the largest case in country is being focused on mobile data and its corresponding security. This shows just how important the issues of mobile security have become and this case, no matter where you stand on it, proves that our mobile phones need to be secured and we need to understand the long term effects of what this means for mobile vendors, app developers and mobile device users. 

While this case will continually unfold throughout the next couple weeks, it has already shown us that the ability for security is needed and that the final decision could cause have major changes as to how mobile vendors develop their product from a security standpoint. If the ability to have a third party access data, or bypass the encryption, of a mobile device could start a trend of mobile app developers to enable strong encryption or security within their applications. This ability to access a mobile device could cause a stir among mobile app developers to start performing better security and encryption within their app and not rely on the security of the mobile phone as an umbrella. Certain apps pride themselves on security and encryption, E.G Signal, but I wonder if this will cause other apps to follow in their footsteps? Will this cause a windfall of encryption within mobile apps in attempts to have better privacy? And will the same question of encryption that Apples experiencing now occur on apps that have their data encrypted?  It would be an interesting trend to watch for after a decision is made. 

Also, dependent on the ruling of the iPhone case there might a shift of users who want more privacy move towards another mobile vendor. Apple seems to have a very strong following regardless and we saw many security and privacy upgrades made to iOS6, but will this decision end up making a few of these mute and affect Apples bottom line? Will there be users who felt safer on an iPhone before this case leave for another vendor in search of looking for more privacy? Will we see similar requests of the government sent down to Google, Blackberry, Windows, etc to have the same or similar capabilities? Yet again, this is another interesting trend to look for when the dust settles. 

Lastly, if this is the norm going forward will all new vendors that come into the mobile space have to adhere to allowing access, or bypass ability, to their mobile devices and applications? Will this become a standard applied to mobile vendors and application developers as part of their build process? There are many things to consider after the final decision is made on whether or not Apple needs to develop a way to have a third party bypass their encryption. Yes, this helps with national security and yes this could bypass privacy, but the follow ups going forward for mobile vendors regarding security could be long lasting and changing.

DROWN Attack Has Its Own Theme Song

Today it was announced that there’s a high level risk (DROWN Attack) within the OpenSSL library that allows malicious actors to create man-in-the-middle attacks against sessions using the ancient SSLv2 protocol. Not only are the sessions which are still using the antiquated SSLv2 protocol vulnerable, but any other service sharing the private key with this SSLv2 connection is at risk (E.G a web server using SSLv2, but a mail server using TLS 1.2 with the same certificate are both vulnerable since the key can be used to crack both sessions due to the SSLv2 vulnerability). At this point there is no fix for this vulnerability except removing SSLv2 from the enterprise. Which was named vulnerable about 20 years ago.

And now for the very first time a vulnerability has it's very own theme song. Too soon? I think not. It's been 20 years in the making. CUE THE MUSIC!!