Companies beware of SSL decryption in your proxy!

The ubiquitous rise of SSL as a means of confidentiality pushes towards new security problems and new ways to manage it...
I guess we could have figured it out from the very definition of SSL, but to me it appeared only clearly at the beginning of this year. With this number of protocols using SSL, with this everyday HTTPS, with everyone buying things on the Internet, the SSL protocol spread to ubiquity and its use went from precise pieces of software and knowledgeable people to every kind of software and mainstream people. From this situation, I saw the explosion of:

• bad implementations of SSL in all kinds of software,
• attempts to attack the protocol, new (so to say) man-in-the-middle attacks,
• bad uses of SSL (weak cypher, self-signed certificates for public use, etc)
• impatience from top management about the inability of IT services to provide statistics about the SSL traffic of their employees.

For all these reasons, I made the bet 2010 would see the introduction of new tools to manage SSL, make statistics from it, filter it, assess its security and so on. I found that Forefront TMG (the name of MS ISA for 2010) does quite a part of the job by decrypting the SSL flows between the LAN and the Internet. Once decrypted, you can do all the usual with those flows: filtering, statistics, eavesdropping...

My point is: it's not a secure practice yet, and probably never will.

There are two parts in my argument, the first is the legal and compliance point of view. If SSL is encrypted, it's in order not to be read, as dumb as it may sound. The company might not be allowed, under the laws of the country, to listen to employees' encrypted traffic. For instance, in France, I wouldn't be allowed to listen to private connections to online banking sites. Plus it brings back the threat of the tactless/malevolent administrator.

The second part is the technological one. SSL is ubiquitous and, to some extent, that's a chance. It means that the client software may have a variety of vulnerabilities and weaknesses in the implementation of SSL. For instance, if the SSL traffic flows from three browsers, two media players, ten business applications, then a vulnerability would probably affect only one in fifteen pieces of software using SSL. The targetability of unproxyfied SSL can grossly be compared to the average of vulnerabilities of the various pieces of software that use it. The targetability of proxyfied SSL is that of the proxy.

Would you trust ISA better than Firefox? Suppose that you have an endpoint tool that examines SSL, if its security features are better than those of the proxy, you probably lose these capabilities during the decryption/encryption phase of the proxyfication.

Of course, SSL remains a cloudy mystery, threatening to some extent, but I think this is not the good way out of it. But let's have a look at these technos, because I'm sure we'll have to cope with them anyway.

The technology SPOF

When I'm thinking availability, a lot my time and thoughts go to the careful search for SPOFs.

1. I do look for hardware SPOFs, like a unique machine doing an important job and requiring a backup in case of breakdown. [first step of a BCP]
   
2. I also do look for network SPOFs, like making sure the backup has the same network accesses as the master machine, so that it doesn't remain alone, useless. The same is true for firewall accesses and all kinds of filtering that network flows do undergo. [careful execution of the BCP]
3. I furthermore do look for configuration SPOFs. These consist of the rather funny case when the backup machine is up, reachable on the network, but the clients are not aware it's there and so don't undertake anything with it. This is usually the case when IP addresses are not switched automatically between the master and the backup or when a configuration screen allows only to type in one server, not two or many. Hopefully, this should not happen with MS Domain Controllers, the way they work (or we would hear this kind of SPOF more often). Anyway, it's still recurrent in many "small vendor" appliances and in the application world. [very careful execution of the BCP]
4. Nonetheless, a terrific SPOF remains: the technology SPOF. You have the backup machine, it's reachable, and others are aware that they should communicate with it. But the backup suffers from the same technological incident as the master machine did.
   Say, for example, that the master breaks down because it fails to handle a large quantity of "client data" (or anything) that has to be treated. The backup will also break down under the same charge.
   Let's take another example, the server is an application connecting to a database. The database received a minor software update that changes something that makes the master server go crazy. The backup takes the job and goes crazy too.
   Third and last example, you have a nice application server with scheduled tasks that make needed job. One fails and the server goes down, unable to continue its work. At that moment, the backup goes up and launches the same scheduled task, failing also... [and that's outside the perimeter of most BCPs]

That's the time when you'd want to have another way to provide your service. That's the moment when you are forced to remember that the machine is not here just to be here and working, it's here to help provide a service. And that service may be provided otherwise. That's the time when you enjoy having a well-prepared DR plan, with forethought reduced/degraded modes...

Monthly ITsec Leadership Quotes and Articles: August 2010

• Second attempt, sequel to What's "a risk" anyway?, on riskmanagement.com.
• 7 questions that staff performance in small and medium-security for better, an industrial medicine article that applies well to IT management, to my mind.
  
• Bob Carr on Leadership in a Crisis.
• Michael Krigsman (that I quote often): Do large projects really fail more often?.
• Also Michael Krigsman: Federal gov't gets serious about IT failures. I'm pretty enthusiastic when governments think IT is an important matter. But their actions (worldwide) seem to range from mere speech to strict costly compliance going through using IT as a fear-monger. I'm welcoming anyone with positive examples of government involvement in IT (I know there are, some).
• If you're managing networks, go read a statistic-rich, worldwide survey of SSL by Qualys.
• On SecurityRecruiter.com, they do care about how you write. I approve. Verbal and Written Communication Skills for Technology Professionals.
• The Guerilla CISO's troll excellent article about Thought-Terminating Cliches and Infosec.
• Seth Godin's "The fear tax" (reported by Bruce Schneier).
• Carlos Ghosn's quote, about his conduct of the Renault-Nissan merger: "When you need people to work together, the last thing you want is a legal structure that gets in the way." We're so often concentrating on building a better work system, when we'd better concentrate on the people who work... There's no point in building an ISO system with many PDCA wheels and numerous policies and charts if the people that should action those wheels are not on the move.
  

Fun Fact: Wrong Sense of Rotation for Deming's PDCA Wheel

Have you noticed how many times management consultants draw the PDCA wheel so that the way to climb up the hill is ACDP and not PDCA?

This picture from [GE] Paeger Consulting.

Enterprise-Size Authentication Is Not Just About Avoiding False Positives

When you're setting up an authentication method for access to an enterprise information system or to the enterprise premises, you don't want to just worry about false positives. You need to worry about the false negatives also.

Think about the logon screen of an application or website, asking for your username and password. The biggest worry of IT people behind that screen is to make sure the wrong people do not access the system. I think they should also care about the number of times the right people can't access the system either.

That's no big math, but suppose you would change a logon screen with 0.1% of false positives and 1% of false negatives (each losing the company 0.5$ because of the time lost for work) for a new logon screen with 0.01% of false positives and 3% of false negatives. Additionally, suppose the logon screen is used by 10,000 employees five times a day, 300 days a year.

The change would represent a loss of:
2% of additional false negatives
x 0.5$ each time
x 10,000 employees
x 300 days a year
x 5 times a day
which equals 150,000 $ per year.

It makes sense to acquire the new logon screen (let alone its own cost) if dividing by ten the losses due to intrusions in this system saves you more than 150,000 $ each year, that is, if the losses due to intrusions are above 170 000 $ per year, roughly.

Monthly ITsec Leadership Quotes and Articles: July 2010 (and June too)

Positive Leadership: Invest in People Building a Culture of Innovation.

Leadership Essay by former student Vince Fitzpatrick on the SANS Technology Institute's "Leadership Laboratory". The author comes back on the leadership he used when he was first appointed as CISO. It really reminds me of my own beginning.

Executives are Not Stupid on RiskAnalys.is, helpful to debug IT workers and ITsec workers when they think that everything is the management's fault.

Five reasons projects fail on Michael Krigsman's IT Project Failures.

'Wicked problems': collaboration, risk, and failure also on Michael Krigsman's IT Project Failures.

CISO and CSO Reporting Structures on the Security Recruiter Blog, on the shift of ITsec from defence to legal compliance.

Why "Doing ITIL" Doesn't Work (And How to Fix It): a direct, simple, summary of why ITIL is no silver bullet. Keep in bookmarks in order to cool down a manager, some day.

Can You Compete With the Next Generation of Security Leadership? (Yes, we can.)

Leadership learning 1

Wisdom being to recognize wisdom when you hear or see it, let me put it down what I heard from a management old-timer :

• When somebody asks you about the goals of a project, answer goals.
• When somebody asks you about the ethics of a project, answer ethics.
• When somebody asks you about the management of a project, answer management.
• When somebody asks you about the deadlines of a project, answer deadlines.
• When somebody asks you about the means or technology of a project, answer means or technology.