Epistemological Relativism

Whether you perform “threat modeling”, conduct “design reviews” or engage in “risk assessments” for the purpose of identifying and hopefully correcting design flaws in an application’s design there is always a lingering question of completeness and accuracy. I’ll try not to derail the conversation and talk about what you do with the flaws (ie, how you rate them, prioritize them and a method for correction) you’ve found even though I really want to.

So, what about completeness and accuracy? Many organizations now go about performing some sort of activity prior to the construction of their widgets. Most probably think they’re doing a decent job. But how do we know? Is it the volume of flaws that are discovered? This is more like a warning light on an automobile than a measurement of the completeness of the efforts. I know, our buddies Saltzer and Schroeder have spoken about proving a negative requirement and I agree with them. I tend to think that this notion of completeness and accuracy are rolled up into a more well-known concept of code coverage. No, it’s not perfect, but it does a decent job here. Of course there is no “code” to cover in the sort of per-construction activities we perform. We deal with the raw materials that will eventually materialize into code. We don’t have the luxury of measuring the scope of our activities based on properties of the code (the number of lines, critical regions, etc). So how do we measure coverage? Do we rely upon methodological adherence? That seems dangerous. What about the quality of the design artifacts? Do they have use cases? The sort of inspection that we can perform seems to be proportional to the amount of time one has taken to articulate the design. But that only makes it more probable that we will be more complete and accurate. We can’t use that to measure our coverage either.

There are two aspects that contribute to quality code coverage ; identification of security code paths (I know there is no code yet) and depth of analysis. The first is the process whereby all untrusted points of input and output in the design are discovered and validated. In my world very few points are trusted, but there are levels of trust. The next is depth of analysis. It is not enough to go through a series of binary questions like “do you authenticate this communication channel” even if there is a well-defined policy governing authentication requirements. It isn’t just the coarse-grained patterns we’re speaking of here. It is the *design* of those patterns that must be evaluated. This is, I think, where many security efforts go awry. They boil down analysis and expertise into questions and answers. Questions do not achieve the depth of analysis criteria for code coverage. Without a doubt if a design doesn’t answer yes to these fundamental questions you’re at a hard stop, but for those that can answer yes you must go deeper.

So, are you confused? “Code coverage” in pre-construction security efforts must consider the methods to identify (and validate) inputs and outputs and the degree of analysis performed upon that data. How do we do this? I don’t know. What we can do is use these two categories (there may be more) as controls points for the consistency and/or reliability of our data. For example, if we’ve simply reviewed available documents to discover the project’s design elements there is probably a greater margin for errors and omissions. It follows then that our code coverage will not be as complete as it could have been. Yes, I know, it is only probabilistic. But that may be the best we can do. I’ll leave it up to everyone (all two of you) else to consider whether what I’m saying is valid. Good luck.

On the Common Vulnerabilities and Exposures website there is a terminology page that presents two definitions; one for vulnerability and another for exposure. Having recently discussed and pondered the implications of broadly defining vulnerability, it was nice to see some precision. I’m surprised I hadn’t come across this before.

The challenge with one’s defintion of vulnerability surfaces when you attempt to calculate some form of probabilities or impact of a given vulnerability. Some “conditions” that are typically labeled as vulnerabilities by many tools are really nothing more than configuration errors or omissions. The CVE definitions make room for such errors and omissions by calling them exposures. The defining characteristic, in my estimation, is whether or not such a condition leads to the direct compromise. If it is direct, in most cases it is a vulnerability. If it is indirect or a “stepping stone” then it is an exposure.

The caveat sprinkled throughout the page makes it clear that there is some form of “reasonable security policy” by which to measure. This policy should not be confused with an organizations over-arching security policy, but those characteristics that are expected of a given product/application. This works nicely I think. It gets interesting in organizations whose core business is not the distribution of software. Why is this the case? Some environments having varying degrees of “reasonable security policies” when it comes to applications. Most of the time it is in the form of, at best, non-functional requirements or, at worst, some language thrown together ad-hoc from vague high-level security policies. The further away an organization is from this policy the more the notions of vulnerability and exposure merge together. This is only difficult when, as I mentioned early, one tries to measure probability and impact. A true exposure does not have the same measurable characteristics that a vulnerability does. For instance, vulnerabilities have properties like exploitability and reproducibility. These properties do not measure at all with exposures. Or if they do, they do not accurately communicate risk. The nature of a vulnerability is its ability to directly compromise. The measurement is an attempt to reflect the probability of that direct compromise. Exposures typically do not have that sort of capability . To measure them in such a way artificially inflates the inherent risks of exposures.

Are you still with my meandering? Good, because now we get back to the non-software selling organizations. In order to make these distinctions meaningful and the rating useful there must be an effort to create this sort of reasonable security policy (the kind mentioned above). Without such a standard things inevitably gravitate to the vulnerability class in order to rate it and have some corrective action performed. When this happens our measurements of risk behave in strange ways. For organizations in this situation it seems that the easiest way out is to create a minimal set of security requirements that directly address these exposures.

There is this idea driven by the combination of regulatory compliance requirements and money-hungry vendors well-intentioned solution providers that there is a malicious database administrator operating within most organizations. This database administrator is likely a part of a large network of information traders attempting to fence their ill-gotten goods to the highest bidder. They can strike at any time and are, most likely, deciding which other choice pieces of information in your organization will subsidize the purchase of their fourth Murciélago. There is no question that this scenario makes for a great (read: terrible) Hollywood film premise. Presently, however, this is nothing more than a work of fiction.

Whatever the intentions of those that are propagating this myth of the malicious DBA, the current data available does not tell us such a story. Even a cursory glance at this data paints a completely different picture. Feel free to explore the data yourself. In the chart below you can see that a malicious DBA was responsible for 3% of data-related breaches. You should also know that I was being generous with the descriptions. It was most likely *not* a DBA, but then perhaps you’d think *I* was making this up if there were no DBA-related activity.

For all this breach data there still are companies out there that tell you that their state of the art encryption technology will help you defend your organization from the malicious DBA threat. It seems odd to spend so much on the “Malicious DBA” threat when it accounts for probably less than 5% of the overall threats to confidential data. I think these product vendors know this. This is why they attempt to tell you that their database encryption products “protects the data within the DBMS and also protects against a wide range of threats, including storage media theft, well known storage attacks, database-level attacks, and malicious DBAs.”

Database encryption won’t help you with the laptop problem, it won’t help you with the paper problem, it won’t help you with process problems and it won’t help you with the hacker problem. It helps you, if you want to make the stretch (and to be charitable I will), with the tape problem (assuming your undefined processes backup data that is still important to bad guys, but is not required to be protected according to regulatory requirements), it will help you, maybe, with the disk-in-server-gone-missing problem, and it may help you with the malicious DBA problem. But, wait, there isn’t a malicious DBA problem. So what does database encryption do again?

References:

http://www.privacyrights.org/ar/ChronDataBreaches.htm#Total

http://www.ingrian.com/resources/sol_briefs/implementation-sb.pdf

For all of the “growing up” that the security industry has done in recent years it is amazing that proper distinctions are not being made when it comes to testing. No, not that testing, security testing. See, it demonstrates the point. When I say security testing all sorts of concepts are cognitively connected in that moment. Unfortunately, these connections are different for each of us. When some hear security testing they may think of using a new and improved fantastic commercial tool that produces beautiful output. Others think of an uber hacker sitting in a dimly lit room reading the network-byte-ordered data from some super secret application protocol. Yet others have never heard of the term security testing. Instead, they think you’re talking about pen-testing which, for the purposes of this discussion, is a fine synonym. The challenge is not with the definitions per se, but with the perceived effectiveness.

To be honest, it isn’t really the perceived effectiveness. Well it is, but let me elaborate. The challenge lies in the way in which we swap the effectiveness. Somehow we’ve managed to equate the ability of the uber hacker to find implementation bugs with that of a tool. We’ve given the tool the title of uber hacker. A title that, despite all of its merits, it cannot bear because it cannot deliver the goods. This does not mean that tools are not an expedient way to identify and respond to low-hanging fruits. They are great for that. But, sometimes it is thought that either low-hanging fruit represents the greatest risks or that this low-hanging fruit is really all the fruit there is on the tree. I don’t think this is the case and this is the problem. We cannot presume that what a tool can identify is all that there is and that what it can identify is all the low-hanging fruit there is. In the context of the tool it may be all there is, but in the context of an uber hacker or even a not-so-uber hacker it may not.

An example may help clarify what I am talking about. In a previous life we were testing an online application that was responsible for delivering sensitive documents to users with accounts. This was a manual, exploratory type of test because there were no real design documents that described the behavior. We immediately created an account and after some time visited the ‘I forgot my password screen’. The email we received looked odd. To make an exceedingly long story short, we discovered that the application was generating a pseudo-hash as the means of authenticating the user. This hash, if you can call it that, was really a simplistic Vignere cipher using the username as the key material. Of course you can imagine what happens next.

Running the variety of commercial tools out there could not find the flaw mentioned above, but we knew this. This was why we performed this ‘other’ kind of pen/security testing. Was this flaw easy to find? It was and tools were not equipped to find it. The fact is if we continue to label automated tools as uber-hackers-in-a-box, then we may be in for quite a surprise. This is why distinctions, especially with regards to pen/security testing are important. We have to be aware of how we are testing not simply that we are testing. And even with all that we have to remember that in the end test results without any identified vulnerabilities only tell us that we were unable to find any and not that they do not exist.

I was reading some of the SAML specification the other day (yes, I read those) and I found something particularly interesting in the Technical Overview.

In the HTTP message, the artifact carried (either as a query variable or as a control in a POST body). The artifact is a base-64 encoded string. It consists of a unique identity of the Identity Provider and a unique reference to the assertion (called the AssertionHandle). The artifact therefore enables the Service Provider to reference an assertion on the Identity Provider.

I am always the skeptic, especially when it comes to using words like unique. Is there really enough entropy in this AssertionHandle to guarantee its uniqueness? I decided to dig a bit deeper. Oh, just in case you can’t read my mind, this is important because a predictable AssertionHandle allows you impersonate an authenticated user on any system that uses the broken identity provider. Nice, isn’t it?

In section 3.6.4 contains the information I was looking for, I think.

With respect to this binding, an artifact is a short, opaque string. Different types can be defined and used without affecting the binding. The important characteristics are the ability of an artifact receiver to identify the issuer of the artifact, resistance to tampering and forgery, uniqueness, and compactness.

I mentioned AssertionHandle and the above citation uses artifact. An artifact is the collection of three pieces of information [Section 3.6.4.2]: TypeCode (determines the type of artifact), SourceID and MessageHandle. An AssertionHandle is a type of MessageHandle. The generalized requirements are decent, but please tell me there is a bit more direction.

The notation B64(TypeCode EndpointIndex RemainingArtifact) stands for the application of the base64 [RFC2045] transformation to the catenation of the TypeCode, EndpointIndex, and RemainingArtifact.

The following practices are RECOMMENDED for the creation of SAML artifacts:

• Each issuer is assigned an identifying URI, also known as the issuer’s entity (or provider) ID. See section 8.3.6 of [SAMLCore] for a discussion of this kind of identifier.

• The issuer constructs the SourceID component of the artifact by taking the SHA-1 hash of the identification URL. The hash value is NOT encoded into hexadecimal.

• The MessageHandle value is constructed from a cryptographically strong random or pseudorandom number sequence [RFC1750] generated by the issuer. The sequence consists of values of at least 16 bytes in size. These values should be padded as needed to a total length of 20 bytes .

The MessageHandle/AssertionHandle is important. The minimum length of this sequence is required to be 16 bytes, which contains roughly 128 bits of entropy. This is similar to the output produced by MD5. The artifact structure requires the MessageHandle to be 20 bytes in length so padding is used if the 16 byte minimum is used. Why the specification does not require 160 bits of entropy (20 bytes) instead is a mystery.

We get the requirement that the MessageHandle needs to be random. We even get the reference to RFC 1750. So far, so good. Then I remember the ‘RECOMMENDED’ at the beginning of the section. RFC 2119 says that when something is a recommendation that it can be ignored. Of course, it says it much nicer and with a few qualifications attached, but it can still be ignored. This, I’m sure, isn’t something to lose too much sleep over.

So, if the developer decides to implement the recommendations, utilize the advice in RFC 1750, uses a reliable PRNG source, reads the Security and Privacy Considerations, uses defensive programming techniques and does not produce any implementation bugs in the code that implements the artifact generation and validation then I think we’re okay.

I don’t mean to sound alarmist, because I’m sure there are some implementations that get it right (intentionally or unintentionally). I’d even say that if one used MD5, in all its broken glory, to generate the requisite random bits that it wouldn’t be the end of the world. This is especially so if artifact timing is used according to the recommendations in the Security and Privacy Considerations. What is worrisome is the distributed nature of SAMLs use. If a collection of systems use a Identity Provider that does not provide a unique MessageHandle then all systems are at risk. The increase of federation and identity services increases the impact of such an event. As a general principle this type of concentration should be given an extra measure of scrutiny. I will be snooping around the various implementations in the coming weeks and will hopefully document my findings.

There is an article over at Dark Reading that discusses the challenges of vulnerability management and the slow integration of disparate products to produce a more comprehensive platform for such initiatives. Many are familiar with the pain of managing the variety of automated and manual tasks to measure compliance. Especially fun is the prioritization of the torrent of findings produced by these tasks.

Enterprises also must consider risk from the business perspective rather than just go about wielding a patch checklist. “If a system has limited business value, it’s less important than a vulnerability in a server that holds our credit card numbers,” Maiwald says.

I agree a hundred percent with the first sentence and disagree 100 percent with the latter. That last statement is so filled with assumptions that it is hard to take it seriously. It is an exceedingly dangerous generalization. It takes a systems involvement in storing sensitive information as the primary metric in prioritization. Now, I know that it was only an example in the article, but it was a bad one. This is because there are many, many more factors that should be considered when prioritizing remediation. A quick shotgun list would include things like position in the network (it is not a binary internal/external game), the relationship (logical and physical) between a system and other identified critical systems, the characteristics of the identified vulnerability and the types and roles of users on the vulnerable system. I think it is time to handle prioritization in a way that isn’t a binary comparison between things like internal/external or sensitive/public, don’t you?

I spoke about vulnerability and threat ratings here a couple of weeks ago. What I didn’t really give enough attention to was the testing of this rating system. In short, once you’ve identified a vulnerability you have to somehow communicate the overall risk. This is typically done with assigning some value to impact and likelihood. You read more in my previous post. I think most of us forget a critical component in the development of these systems. We forget to test them.

Come on, we’re experts right? Do we really need to test? What is the value of the test? Well, if we are committed to delivering accurate and realistic information about identified vulnerabilities we must demonstrate that our system can provide that. A good way to provide this proof is to play test. I know, we all think we’ve created the silver-bullet so it feels wrong. Trust me though. If you do not test your new-fangled system the second it gets in the hands of a developer or infrastructure group (or even your own localized security group) and produces different results than what you came up with you will be in trouble.

One of the primary properties of such a rating system is reproducibility (the other, of course, is accuracy). A given vulnerability in the hands of a couple of knowledgeable people should roughly give similar results. If it does not, this should raise some sort of alarm bells. If you are in fact trying to create s system that is coherent and reproducible you you have to make sure it passes the litmus test. In rating systems it is imperative that you attempt to minimize subjectivity and increase reproducibility in the results. The problem of subjectivity is challenging because everyone has their own experiences that affect the process. Add to that the fact that some are limited by what they can conceptualize and results become amazingly erratic. As a good example, a system with a single dimension each for likelihood and probability is nearly impossible to deal with. This is because, and I’ve talked about this before, that there is too much information loaded into a single dimension. It is difficult to justify, for example, a particular value for likelihood. There are too many categories of information loaded into the concept. A simple test of your system will help determine if your rating elements are suffering from category overload. In the end if you approach your system with the goal of objectivity and reproducibility and add in testing at the end I think you’ll have a system that delivers, as much as possible, realistic and accurate information.

There is no question that software reliability is a requirement of most software development projects. Reliability, however, is often very narrowly defined. In the security world reliability is great label to describe how a system (application or otherwise) handles a variety of unexpected conditions that are not at all driven by normal use cases. There is a laundry list of useful techniques to measure a system’s reliability from the context of security. These are almost the complete opposite of how a normal QA cycle is run. Yes, there are performance testing aspects in the overall cycle, but these are still focused on the narrow definition of reliability

This narrow definition of reliability is focused on what I call positive availability. It takes the known and valid operations of a system as defined by the use cases and attempts to find situations where that system’s implementation deviates from what is expected. You’ll notice the change from reliability to availability. This is intentional because software reliability is so narrowly defined in this context that it appears to be nothing more than ensuring the availability of the system and its information through this sort of examination. I know I shouldn’t have to say this, but I’m not saying that this process is bad or not useful. It is useful. What it isn’t, though, is comprehensive.

This gets even more interesting because many times reliability is not viewed as a security concern. To some, security is the management of identities, assertion of these identities and the entitlements that these entities should receive. This is a grave mistake. Reliability is at the very core of security. Measuring how software protects confidentiality, maintains integrity and provides availability is the the primary task of security. Just as the process of “positive availability” is limited so too is the idea that security is only about managing and enforcing entitlements. And so, because of this, we have this chasm. The software process stops at positive availability and labels a project reliable. The security process stops at entitlements and labels the same project secure.

To provide the most utility the reliability that is measured by development projects should include negative availability. As for security, it needs to expand to meet the needs of not only who gets to what, but also how the application is structured and implemented with this same negative availability in view. I use the term negative availability to describe that vague process of examination where standard use cases are twisted and bent. Instead of trying to find if an application breaks through standard usage this process tries all forms of manipulation that are not defined in requirements and designs to find defects. The aim of this type of defect hunting is to find a failure in confidentiality, integrity and availability mechanism of software. Because standard use cases attempt to communicate how software should operate this sort of negative availability uses that source material to see if the software has protected itself when things do not go as expected. Typically software is not constructed with this in mind.

We quickly see that my negative availability moniker isn’t inclusive enough. Once a flaw is found in software through this sort of testing it isn’t always the loss of availability that is the result or even the goal. The fact remains, however, that this sort of testing and examination is crucial to understanding how reliable an application really is. It is dangerous to presume that software is reliable when it does not focus on this negative availability. It is as dangerous, if not more so, to presume that an application is secure because identities and entitlements are managed properly when no review of the software’s construction and operation is performed.

In the information security world nothing is more fun than using confusing terms. This isn’t done intentionally of course, but it happens. It happens often, I might add. In fact, one set of ideas that is constantly subject to debate is the notion of risk and threats. This isn’t because people enjoy arguing, but it is due to the context from which various people are approaching the subject. Who would have though that information security could be so post-modern? The variety of experiences lead many to define terms quite differently. I try to approach these individual elements not as linguistic islands, but as part of a system that must be coherent. If it does not pass this test, then I’ve gone wrong somewhere. So, I will now present my version. Keep in mind this is probably too specific for physical/environmental risks. It can still be mapped to these definitions, but there will be duplication. You’ll see what I’m talking about. I will try to avoid formalized dictionary definitions. Hopefully that will help.

Risk: This is an abstract concept or placeholder for some loss, damage or event that would adversely affect information.

Threat: This is where the wheels usually fall off so let’s see how we do. A threat is a concrete instance of a risk. For those OO programmers out there, think of this as an instance of the Risk class with the relevant instance variables that uniquely identify it. This is different than those with a military background where a threat is more like an entity, actor or agent that bears some responsibility for an event. I’ll talk more about this in a minute.

Vulnerability: This is a weakness that allows a threat to be realized. This weakness could be missing controls, implementation errors or a variety of conditions that make a threat move from possible, but not realizable to possible AND realizable however difficult it may in fact be.

Attack: This is the mechanism by which a vulnerability is exploited or used. There is usually some activity that must be performed to do something with a vulnerability. A vulnerability must be exploited by an attack. Without the attack component a vulnerability just remains a weakness of some sort. No event (see risk) has occurred until an attack is launched against vulnerability.

Threat Agent: This is the entity that is ultimately responsible in any measure for the realization of a threat. I would say particular threat, but threats are already particular, but I digress.

Now, these are working definitions, but let’s see how they all fit together:

A threat agent uses an attack to exploit a vulnerability in order to realize a threat.

This seems to work. But where does risk fit into all of this? Our above definition does not cohere with the rest of the system. I think we need to revise this a bit. Risk in this situation is particular and not abstract. It is concerned with communicating the impact and possibility of the above systematic statement mapped to a specific instance (I know it sounds funny to me too). Risk then must be anchored in some way to a particular. In order to communicate impact and likelihood you must be acquainted with the threat agents, attacks, vulnerabilities and threats. If you skimp on any of these you have not accurately measured risk. So, a risk assessment is concerned with understanding these particular threats and how they can be realized. I think this works.

In a bit I will break it out even more and show how the various components can be manipulated, measured and rated (and the challenges with each). Again, once we do this, we have to see if the system is still coherent when taken together to ensure we’re getting everything right.

UPDATE: In my haste I seem to have forgotten the most important element of all. I completely omitted assets. Assets are the objects that are threatened. Without them, all the other concepts seem to float around. An asset-centric approach is necessary to give realism to the risk analysis process. This keeps one from dreaming up threats and/or vulnerabilities that cannot be tied back to an asset.

Developing a coherent security strategy that focuses on real risks as opposed to the perceived risks in an environment is a notorious challenge. In most cases organizations rely on an ad-hoc approach that is informed by industry experts. Of course there is nothing wrong with this because in some cases these experts get it right. But trends in the industry, however reliable, should not be the primary justification for integrating these recommendations into an organization’s overall strategy. What I’ve been playing with for the past several months is a way to graphically represent the primary components of information systems.

This somewhat abstract representation provides, I think, a method for appropriately mapping the variety of security related concepts onto these primary components. It allows you to see the logical relationships between these primary components. This mapping and relationship allows you to “see” all the security-related practices, controls and technologies as a large story. It presents it as the forest rather than isolated collections of trees to use the “forest in the trees” analogy. I know, it sounds rather obvious doesn’t it? Sadly, there are not many working on this forest view. Sure there are some attempts being made and while they are still useful they have a hard time showing the relationships between the categories. Understanding this interaction is necessary in order to identify and understand real risk.

After many, many sketches, some thinking, research and more sketching I’ve come up with four large abstract classes in this taxonomy. They are not so large as to lose meaning and not small that they become too specific. The real challenge to this is graphically representing these classes while still maintaining their relationship to one another. It is easy to draw a pretty set of circles with data in the innermost circle and the relevant classes of security controls, but such a picture does not accurately communicate the common relational qualities of the individual classes and this is what we are trying to achieve in order to see the risks and develop a practical strategy.

Application - All services, components and applications that are not a required part of an operating system

Platform - The combination of the instruction set architecture and operating system

Persistence - The location and mechanism used to maintain data at rest

Data - The elements that are Created, Read, Updated and Deleted (Yes, this is also an abstraction)

Yes, that really is it. Using logical (for network-based) and physical access methods gives the classes the necessary linkage to one another. Adding actors, entities or whatever term you’d like to use to identify a thing responsible for accessing systems allows you to map the end-to-end relationship of generic (or specific if you’d like) information flow. Before I completely define what these classes are and explain why something like ‘network’ is conspicuously absent I’ll let you think about it for a bit. Oh, I almost forgot. There is a another taxonomy of people, process and technology elements that you can use to “inspect” these other classes to determine what level of security maturity they possess. I’ll give you some ideas on what those are in a later post.