Expect Control Failures - Create Fail-Safe Security Models

The "Heartbleed" virus where OpenSSL's encryption ability was compromised, permitting the adversary to see user authentication information (User ID and associated password) was used as an excuse for data breaches by several firms. After all, once this information is known for a powerful user like a network engineer or an administrator, then your systems are wide open to the attacker.

Nevertheless, the design flaw in the above scenario is that their design assumed that the single factor “something you know” authentication credentials (user ID and password) would always be secure and known only by the authorized user. Their design did not expect this authentication control to fail, so there were no layers in place to provide security to either prevent a failure of this control or detect it – if it happened.  


Speaking directly to the choice of single factor authentication, with no compensating controls this security model is only appropriate for private networks with little or no internet access. The choice of a two-factor authentication design, particularly a two factor that was an Out Of Band (OOB) solution like using a cellular phone as the “something you have” would have prevented the breaches associated with the HeartBleed, because the adversary would not have had access to the cellular phone for authentication.

However, what if the two-factor authentication fails? Can we create a “Fail-Safe” security design that protects our data and information when this happens? Yes! A useful second layer is the deployment of an Intrusion Prevention System (IPS) and Intrusion Detection System (IDS) utilities. If an adversary does gain authentication information and access to our network, the Intrusion Detection would notice that the session activity of our “Administrator” is against policy, and that this ID is attempting to copy and export sensitive information – notify the Security Officer and perhaps terminate the session.


Finally, a third layer is to provide a Data Leak Prevention (DLP) layer that would examine data flows – both their size and content as well as inspect their destination, prior to permitting the data from leaving our network.


The firms that experienced a HeartBleed related breach deployed none of these layers. From where I stand, it was not so much the particulars of the HeartBleed virus that caused the breaches, the lack of a Fail-Safe security design was the root cause.