Schneier on Security

John Pepper • April 16, 2015 4:54 PM

To keep a focus on the primary question:

“the question of whether patching matters, a question that just will not go away”

Patching does matter. If you are aware of a security issue in a piece of software and someone malicious uses that issue to hack it, you have some responsibility there. You could have told them about it and had them fix the issue.

There is a ‘third way’. That way is to absolutely, positively detect an exploit against that vulnerability. But this means you are using corporations and other organizations as, effectively, honeypots.

Security issues are rated in terms of their criticality, that is, the potential damage they can cause. And they are cross rated with other factors. For this discussion, a key factor is ‘how difficult is it to find the vulnerability’.

For example, the DREAD model: http://en.wikipedia.org/wiki/DREAD:_Risk_assessment_model

For government hacking purposes you want bugs of a critical rating which are exceedingly difficult to find.

Security issues of a critical rating which are easy to find — you can guarantee others will find them, and they probably even found them before you did.

How can this be proven? Use popular vendor DAST and SAST tools and perform a cross analysis. The conclusion there will be results will be very similar.

In terms of statistics, bug density and fix rates do matter. They are important to be aware of if you are the application owner, or if you are engaging in an offensive action.

In terms of “hack value”, the DREAD sort of model can be expanded on, and at least, ad hoc is and has been for years:

How critical is the system the application runs on?
How critical is the application its’ self in terms of functionality?
How critical is the application its’ self in terms of privilege level?
How many users have the application?
How dense is the security vulnerabilities in the application?

How dense the security vulnerabilities are in the system – again, which modern SAST and DAST systems cross comparison can answer to a decent degree – is another useful question in terms of ‘the value of the security vulnerability’.

If all other factors did not apply… A security vulnerability found in an application with a very low security bug density is more valuable then a security vulnerability in a system with a very high security bug density.

As for statistics, a question which is also covered in this paper, several firms are gathering these statistics via ‘anonymized data’. And they have, for years, been working hard at ‘making sense of that data’, as well as expanding on the collection of it. This is provided to users of their products and services.

VeraCode is one of those companies, and I would be surprised if Mr Geer has not sat down with them on this very issue.

I am unaware of any major research project aimed at performing a similar analysis on ‘full disclosure’ vulnerabilities and applications relying on that public source data. But that will be done eventually. There are many interesting questions which can be found there. Considering the value of the potential data and the ease of obtaining the data, like with rating a security vulnerability, one can well predict that someone is probably already doing this, or has done it, or most certainly will do it in the future.

Lastly, a more interesting question arises about utilizing zero day for both offensive purposes and defensive purposes at the same time.

A few notes on this.

Zero day detection systems are weak, it can be very difficult to predict a ‘very hard to find’ critical vulnerability. If one is found it is very valuable for governments in terms of utilizing a possible signature for that attack in a covert, wide reaching IPS type system. A central problem here is that the government also would not want to tell anyone about such an system and this has a high cost in terms of confidence for their people. People having confidence in your capabilities matter, funding depends on this, as well as authority and power.

A secondary problem with this is that signatures of vulnerabilities which are known are very far more accurate then for signatures for vulnerabilities which are unknown, however there is still going to be some manner of failure rate which can span from ‘low’ to ‘very high’ depending on the sort of vulnerability it is.

Disclosure and patching, therefore, is the cheapest route. Yes, it could mean a sort of disarmament policy. But the fact is code is constantly be written and with it new security bugs. No one is anywhere near the place where it can be said ‘no one can hack it’, and that with almost any application. Besides this, there is always the social engineering angle.

Disclaimer: I am neither condoning nor condemning, but merely commenting on some ‘ins’ and ‘outs’ of these matters from a technical perspective.

John Pepper • April 16, 2015 5:32 PM

@David Leppik

The equivalent of capture-and-release in software is finding bugs and not reporting them. If you don’t release your frogs, you’ve lowered the number of frogs in the pond. If you report a security flaw, not only do you (potentially) get that flaw fixed, you draw attention to that piece of code– possibly leading to the discovery of even more flaws.

His version of capture-and-release works best if you have no interest in fixing the security flaws.

That actually raises a good point, that returning the security vulnerability to the vendor, who ultimately releases it, can raise the possibility of more bugs found in that area of code, and, as well, of that type of bug being found elsewhere in the code. From that, one might argue there is a detrimental effect to reporting security vulnerabilities.

There is some truth to that. Anytime a flaw is discovered, that knowledge is shared with everyone and anyone. While the method used to find the flaw is not usually disclosed, the source is.

That both instances are true can be well confirmed by looking at the history of publicly disclosed bugs. The source can be major or minor. For instance, if one starts at the first discoveries of types of vulnerabilities, and major variants of security vulnerabilities, it is easy to see how people do work off of these disclosures.

Had no one ever discovered buffer overflows can be exploited, would someone have discovered this in the future? Or if someone discovered that buffer overflows can be reported and did not disclose this, would not someone else have found it and reported it inevitably? And probably there can be some analysis there with some degree of meaning. How difficult was it to find the first buffer overflow and exploit it? Or the first SQL Injection? The first blind SQL Injection? The first error based SQL Injection exploitation method? And so on.

But, still, the DREAD sort of model works here as well. Rating by ‘difficulty to find’, while not entirely scientific, is not much of a ‘big question’ anyone is asking. Time allotted, sophistication of the exploitation, and many other factors give a strong degree of confidence that a security issue can be rated in terms of ‘difficulty to find’ with accuracy.

IMNSHO it all comes back to: ‘what if a major hack happens where you knew the hack was possible’. What is the possible cost there if the worst case scenario happens? There are related factors to estimate the risk, such as, ‘how often is the system being targeted now’.But, ultimately, criticality of the security vulnerability is the major factor. eBay or Google are attacked all the time, while a critical SCADA system may rarely be attacked. But, if just one attack happens successfully against that SCADA system, what is the potential damage? That is where cost analysis should be, just as people do in physical security.

John Pepper • April 17, 2015 12:45 PM

@65535

Other points.

I once read where Windows 2000 Pro was shown to work with about 480,000 different applications [please don’t hold me to those numbers because it was a long time ago]. Also, I don’t know exactly out of the 0.5 million applications usable on Windows 2000 Pro which ones were viruses or root kits.

One problem is any security vulnerability of a critical impact could potentially be intentional and so a plausibly deniable backdoor. And it could come from anywhere in the world, not just the US Government or a rogue developer. Companies hire people from around the world, and beyond that, working for a software company is vastly different then working for the FBI or CIA. Software developers and management did not sign up for that. They could easily be paid by a foreign country to put in backdoors, and maybe even indirectly. They could be told that their modification was for their favorite political cause, or maybe some innocuous group or individual claiming to be just interested in some profit. Or some other innocuous pitch that would appeal to the target’s preferences.

This is yet another reason why governments should do all they can to report found security vulnerabilities. This is especially pertinent with security vulnerabilities that are specifically ‘hard to find’. That they appear to be innocent mistakes means nothing.

You may think this is something “they” are very aware of, but it is not going to be the case. There is severe compartmentalization, which is one component of that. But a very major component which applies to all fields, is it is not their area to think in this way. They are not trained there and they do not have experience there. It may seem common sense, but like any field these things are not common sense. Part of the reason is because while you can give someone the correct information about another field, even one which is related to them in someway, they do not know how to properly weigh that information. So it gets lost in intentional and unintentional disinformation. (The vast majority of disinformation is, of course, unintentional. Consciously, at least.)

For instance, because someone is a brain surgeon specialist does not mean they are also a heart surgeon specialist. Or a network security person is not also an application security person. Outsiders may view them both as ‘knowing everything’ about computer security. They may themselves overestimate their own knowledge levels in related fields they have no experience in. But, experience and training matter.

While NSA code auditors and defense oriented auditors may have some grasp of these problems, they are not even knowledgable about exact attribution. They may be generally aware of the possibility, at best. Much moreso, technical organizations focused on technical offensive projects should not be expected to be experts at defensive requirements. And while it is sage advice to have many counselors of many viewpoints, this is sage advice for the very reason it is so rarely done!

Again, not my area, and not much interest for me specifically. Generally, I deal with these sorts of problems in my own area, that is on matters I give a f** about. Technically, in general, I suppose my conclusion is close to ‘they should focus on defense, not offense’. One problem is that they can not process wide sweep dragnet information, and they are continuing to affirm that they can by continuing these programs. This affirmation supports and builds deepening confidence in a dangerous delusion.

But building deeper confidence into a dangerous delusion is just what nations and peoples do.

And there is a bigger meaning to that, eventually.

John Pepper • April 17, 2015 2:10 PM

@Nick P

Excellent analysis of Microsoft’s transformation. Only a minor gripe: DREAD is so dead I haven’t heard the word in years. Microsoft ditched it many years ago. It just led to arguments over specifics of the categorization. The current approach is to collect lists of bugs, prioritize severe ones, and fix as many as possible given a certain budget. This was a good change given one could often fix the code as fast as doing a full DREAD analysis of the bug.

Thanks!

The article does stated that MS ditched it, but that sort of model was already well in use by vendors. Microsoft simply clarified it, and branded it. A similar model remains in use in both patch management systems and application security systems. (Be they internal organizations, consultants, or vendor products.) Many of these groups refer to the model by name and use it specifically and explicitly, even if MS did themselves abandon it for their now more accurate version.

eg, https://www.owasp.org/index.php/Threat_Risk_Modeling

When they make those lists, they use some form of modelling not too dissimilar to the DREAD model. It does not take much work and typically can be performed initially “at a glance” by analysts or developers and product managers. From there, when it gets to bug fixing, developers and product managers may argue that a security vulnerability is too highly rated or too low rated.

Usually, they just try and fix the bug, but sometimes it is worth their while to lower a criticality rating as higher criticality ratings demand more resources and shorter allowance time for fixing (which, ultimately, means ‘more resources’.)

There are purely automated security vulnerability finding systems, however none of these are strong enough to take the results at face value. They will have high false positive rates, in general. This is much more true with code review scanning systems then dynamic ‘black box’ scanners, but it remains true with the later category as well.

Whether someone is a consultant or internal analyst or a solutions vendor, they all have a very vested interest in accuracy, so they are well served to rely on a systematic approach. The more seasoned professional ones are strident in their attempt at accuracy in rating vulnerabilities. Failing to do so hurts them in terms of confidence with the people they report these findings to.

John Pepper • April 17, 2015 7:04 PM

@JohnP

<>

Vulnerabilities are, very much, software bugs and are classified and treated as such in bug tracking systems. They tend to be of a much higher criticality then ordinary bugs, but this is not always the case.

For instance, in software that powers mission critical hardware where a bug may mean human life loss, that bug is, obviously, very critical. If the error condition the bug raises can be triggered by an outside human, that already very critical bug becomes even more critical. Depending on such factors as context. Like would someone ever want to do that, plausibly. If so, then it is even more critical. If not, less critical then if so. And so on.

The real issue underlying this article is that software vulnerabilities have become a form of fungible assets worth considerable value to parties that have considerable value to part and considerable demand for them.

They use them to obtain high value information, and this high value information, in turn, provides them additional confidence with higher ups in power and authority. Additional confidence translates to the responsible parties more power and authority their own selves.

[Sidenote: “Power” often used in these contexts is in abuse of power. But, abuse of power is just a different aspect and an error condition of its’ own. Do people find substance in having power and authority and maintaining it, even growing it? Absolutely they do. Problem with abuse of power, like taking meth for happiness, is it reduces the chance of longevity of that power and authority. eg, sooner or later you are going to caught, go to jail, etc. In the meantime, the abuse of power and authority is like printing your own money. It throws the entire system to hell.]

Problem is that value of vulnerabilities is that they have two major possible uses. One, is for defensive purposes. The other is for offensive purposes. Largely, these purposes must be “either or”. Not “and”. Which is an ironic and interesting situation.

On ‘code written yesterday’ versus ‘code written today’, I am not entirely sure of the patterns there. High density of normal bugs does tend to relate to the corresponding density of security bugs, however. But the two systems of detection have matured at different paces.

One thing is probably sure: you have much more code landscape due, at least, to memory availability skyrocketing. Which also means you have a much more complex system grown to fit that increased landscape. So, there you have one major factor for why there will be more bugs in today’s code. The complexity has significantly increased.

John Pepper • April 18, 2015 1:11 PM

@65535

Some parts of my comment were Tongue-in-cheek.

I take my comedy very seriously.

Bill Murray and John Cleese are my ideals.

Though I can take a joke way, way too far.

I think around the introduction of AD or their version of the LDAP directory they became security aware. There products were so successful that they became the de facto target for hackers of all kinds.

Not much value in finding vulnerabilities in applications which do not matter. They were also early in the market, and retained legacy code. Google products were mostly written from the ground up with security in mind, as a contrast. And they were able to hire people who actually had years of experience by then. Because the field had existed for a few years.

(Yes, NSA has been doing security code audits for many years, and you can find Air Force papers back to the early seventies on code security. But, that was a very small, specialized pool.)

The gigantic power of the US government cannot be overcome by one single company. Further, I suspect many people including developers really did not know the enormous powers of the NSA/DEA/CIA until the recent disclosures. The developers were not prepared to properly harden their code.

On the other hand is doesn’t help to get in bed with the Monster. For example Skype should still be a private platform with little or no government back-doors. By happenstance, cough… it is a pipeline to the NSA.

Well, the US is not the only player in the game. It is all ultimately about the economics of information. If there is demand, and if there are capabilities, there will be a game. It can also be said to be about proper threat analysis.

Skype was always a MITM affair. It was not stated as being end to end encryption. For most people, that does not matter much. For others it did, and they were cognizant of that.

Unless the technical details made the information sufficiently unknown to them by obscurity.

Probably developers are much more concerned about their personal risk. If a severe security vulnerability is found in code and makes the front pages, that is a bad situation for a person to find themselves in. If government (note no “us” preface there) finds and uses a security vulnerability in their code, likely no one will ever hear of it.

Unfortunately, this is a double edge sword. In any of those hundreds of thousands of applications could be a number of bugs or outright back-doors.

‘Tis true.

I was working on a paper the other night, however, on the modern landscape, and ended up realizing in a lot of ways there are more reasons today for people not to ‘give a f**’ then there were five, ten years ago.

Adware is a bitch. But the big hacks are happening at the server level. Mass transfer of privileged information in one pull at a time. Personal focused attacks typically are impersonal in that they are not interested in ‘you’, but your organization.

Many of those who want to attack someone just do it against their static online presence.

Smartphones are the major personal system vector, and they are deeply secured. There are attacks possible, and many applications are poorly tested. I am not saying otherwise. But getting to root is much more difficult then with a Windows system or Linux or Mac system. The telco is in strong control of what apps can be put on there and obtain high privileges. Government strongly regulates telco security because they are the infrastructure of all communications, including their own.

This is not to say strong attack vectors, even for malicious spreading viral attacks is impossible. It definitely is. And wifi, like the way the cell network connections are made, are weak. With wifi being significantly weaker. Not everyone can build their own stingray.

But it is not that expensive.