Wednesday 1 February 2012

SSL for the #fail



Are we in danger of brainwashing employees to be susceptible to interacting with phishing sites or malicious sites by incorrectly using SSL internally?

IT departments and security teams spend many hours trying to educate internal users to try and ensure that they do not disclose sensitive information, such as passwords and account details or to visit phishing sites. But is this all undone by the poor use of SSL certificates? On the majority of infrastructure engagements undertaken over the last decade one issue always comes up – the use of SSL internally.

Many organisations will spend time and effort to implement a robust approach to the use of SSL for external (customer) facing web applications. They will deploy well configured certificates that hve not expired, signed with a strong hashing algorithm from a known certificate authority (ok, maybe we need to revisit that one!) and will have been configured to only support strong cipher suites and protocols.

However, move within the organisational boundary and all of these examples of good practice are forgotten and we will see the opposite state, where the norm is to find:
  •          SSL Anonymous Cipher Suites Supported
  •           SSL Certificate Expiry
  •           SSL Certificate Signed using Weak Hashing Algorithm
  •           SSL Certificate signed with an unknown Certificate Authority
  •           SSL Medium Strength Cipher Suites Supported
  •           SSL Version 2 (v2) Protocol Detection
  •           SSL Weak Cipher Suites Supported

Why do organisations implement such a flawed approach to internal use of SSL? Is it a lack of strategic direction, budget or maybe just a lack of thought?

Poor SSL certificate use can lead to compromise of sensitive data. The number of threat vectors that can be used against poorly implemented SSL increase when the attacker is on the same network as the service (man in the middle attacks etc.) It seems sensible that if SSL has been implemented to protect the confidentiality of the service then internally this would become as important if not more important than a service presented over the Internet?

What about the impact of a mixed message on the end user? Are we in danger of educating our employees that SSL warnings are ok to be ignored? If this is the message they come away with, whose responsibility will it be when this behaviour is then replicated at home and they click on the following?

No comments:

Post a Comment