Schneier on Security

Clive Robinson • January 3, 2009 12:22 PM

@ Myoukochou,

“Clive Robinson: Please show how blocking https: provides any meaningful security benefit in a corporate environment.”

First off it’s not just HTTPS it’s all encrypted traffic.

Secondly it’s not a mater of trust in employees, it never was and it never will be (it is they that think it is an issue of trust).

However as a passing note about 0.1% of the population in the UK is currently under lock and key (it’s the maximum capacity we have and it’s full all the time). Further the “criminal population” ie those with a conviction or arrest is something like 30 times bigger than this. So on the law of averages 1 person in 30 has had their collar felt. When you then go on and consider that this represents only a small number of those breaking the law (say 10%) you suddenly find yourself at 1 in 3 people has done something illegal at some point.

So the oportunity for blackmail is there as is possibly the inclination to commit a crime if the odds are favourable.

It is a well known senario of the sales person changing jobs with the customer list and only slightly less of the customer list being made available to the competition.

Then there is user issues, just how many people’s identity details have been lost or compramised via data that has gone missing?

The known figuers for last year in the UK suggest it’s around 10% of the population per year (I personaly have had my medical records lost three times in two years).

So on balance there realy is no sensible way you can trust the employees in an organisation is there?

But to get back to the real issues.

I’m not sure which part of the world you are in, but in some places there is a minor problem of the law be it civil or criminal, of which civil is by far the most hurtfull to an organisation.

Most organisations “need” (or feel they need) to be connected to the internet these days and malware is an everyday (minute?) occurance as is insecure applications. A lot of malware uses non plaintext to send out information usually on a recognised port (HTTPS etc) to reduce the probability of detection

My vote is plaintext only across the chokepoint to the outside wall unless there is a clear business case, which is accompanied by an appropriate way to lock it down.

Internal “sensitive” data is encrypted but also contains plain text “canary data”
Set your IDS to look for all non recognised protocols and data formats as well as the canary data on outbound traffic and record everything.

If the IDS trips shut the data stream down and investigate.

Any other viewpoint is going to get an organisation into problems such is the way judges are interpreting legislation.

My viewpoint may seem draconian and I don’t always get my way. But hey I don’t like having legal people crawling up my a** nor do the company directors now it’s happened to them.

Oh and ask any IT Admin who has had to go through a full electronic “discovery process” including cross examination, what it’s like then have a think about it, before you suggest trust and openness as a security measure where unlimited liability is involved.

Clive Robinson • January 3, 2009 5:35 PM

@ Myoukochou,

“Security (in my opinion) is about appropriate, economical spending of resources to defend against probable threats; including the proper management of trust (or lack thereof).”

How do you define “appropriate” or “economical”?

Esspecialy when it comes to the legal proffession second guessing you?

Likewise the “proper management of trust”, when the two definitions of trust are effectivly the oposits of each other (personal trust -v- trusted systems)?

Both “appropriate” and “economical” are expressions without measurand and are only relative to perspective which changes constantly.

Take for instance the business measures relating to accounting and electronic data prior and post Sarbanes-Oxley. What was appropriate and economical prior was most certainly not post, your definition of security does not take this change into account except vaugly in passing (probable threats).

And as you should be aware there is a whole host of other legislation you need to take into account depending not only on your jurisdiction but also on who you do business with and their jurisdiction (the UK has amongst others the ECA and RIPA).

Your view of security appears from what you have said to be a “technical one” not one of “liability minimisation”. And from the technical perspective a “plaintext only” policy or ideal does not make that much sense (and I could probably give you a run for your money on arguments from that angle 8)

However the changes in legislation and the fact that the legal profession in the US are now using discovery as a very effective way to enrich themselves makes a technical view point considerably less important than spiking the guns of a team of high paid legal talent using every trick they can to put your organisation on the wrong foot.

With regards your comment,

“cite your sources”

With regards to what and in what form?

On a technical issue you say in your prior post,

“They’re your computers; install (and disclose the installation of) monitoring software. Endpoint attack -> Game over.”

Unfortunatly as you will find the “concept” of an “endpoint that can be monitored” is just that on a modern PC when it comes to malware it is not an “actuality”.

Even Microsoft cannot tell you what is happening within their operating system (Unix is a lot better from this perspective but still nowhere close) which is why root kits are so effective.

Effectivly the monitoring software will only report what it “is told” at the “points it monitors”. For instance if there is malware that has effected the appropriate system dlls then your monitoring software will not only not see it’s activities it will not even be looking for it.
You simply cannot monitor each and every point the resource usage would be disproportianate (think of the effect anti-virus software has and multiply by the number of monitoring points). All you can do is “black box” the PC and monitor (some of) the inputs and outputs (VM software is a definate plus for this).

The “No encryption across the choke point” is a policy not a port blocking activity as “effect” is not “cause”. Like all policies it has mandated exceptions that are known and alowed.

With regards your point,

“Your threat model regarding data leaks is more likely USB keys, laptops, iPods and phones walking right out of your front door, as widely publicised last year; proper use of encryption could have mitigated much of that.”

As you say thats the “threat model” of “last year” this is in addition to that.

Data for internal organisational use is as I indicated encrypted. Plain text versions have “canary data”. Neither should be crossing the choke point under ordinary circumstances except where alowed by policy.

Unknown exceptions are an indicator that something is wrong and needs to be investigated. Causes could be amongst others,

1, Malweare activity.
2, Inapropriate user activity.
3, Incorect policy rules or implementaion.

Detecting and shutting exception data streams is a pragmatic response (damage limitation).

What you regard as “false positives” indicates that there is an activity that needs to be accounted for by a user or process. If it cannot be accounted for then there is a problem. If it can legitimatly be acounted for then the policy rules need appropriate modification.

Your “false negatives” are in fact “covert channels” which are a sub class of “side channels” which are in turn a sub class of EmSec.

Side chanels are either deliberate (covert) or a consiquence of the system behaviour. Strange as it might seem they are actualy not an issue as such currently.

Either they become apparent from a side effect at a later stage or they do not. If they do not have side effects then there is nothing to investigate, if they do then the storage of all traffic gives an oportunity for such “side channels” to be identified. But you have to be aware you may embarque on a “ghost hunt”.

Having a working knowledge of side channels I’m more than aware that there is little or nothing you can do to stop them as they exist as a consiquence of the uncertainty in general purpose computing.