Epistemological Relativism

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.

Security

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?

Security

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.

Security

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.

Security

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.

Security

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.

Security

There is a rant over at Observations. In it the author rightly points out that user training is ineffective when you do not have a minimum set of security measures in place. For those not in the inner sanctum, we’re talking about information security. Basically, the rant is communicating that we have to pick and choose our battles. I’m totally on board here. In fact, I spoke about that here. The challenge is that everyone’s bare bones security measures are very different. In fact, over at Observations he practically throws in the kitchen sink! Don’t get me wrong, all of the measures are great, but integrating all systems into AD, starting a threat modeling effort and NAC are definitely not bare bones. Not even close. Now, I know this was a rant so I won’t be too critical here, but you can’t put everything in the bare bones category. It tends to lose meaning that way. Instead, after the author calms down, another attempt should be made to prioritize these efforts. Yes, you must prioritize. Especially in the security space where there is always work to be done, we have to select those efforts that will produce the greatest positive outcome. I know, great is vague and nebulous, but you know what I mean. Check out the laundry list, it is nice, a little idealistic, but nice nonetheless.

Security

The taosecurity blog has an interesting post regarding application instrumentation. In it author Ricard Bejtlich argues that all applications should be able to defend themselves. This defense, according to Bejtlich, is defined as the ability to tell us “when they are abused, subverted, or breached”. Now I wouldn’t call this defense per se, but the I understand where he is coming from. Visibility into an application’s behavior or misbehavior is essential to properly respond to each situation. So, we’re all in agreement here, almost. Bejtlich writes:

I would like to see the next innovation be security application instrumentation, where you devise your application to report not only performance and fault logging, but also security and compliance logging. Ideally the application will be self-defending as well, perhaps offering less vulnerability exposure as attacks increase (being aware of DoS conditions of course).

While this is excellent, I think it fails to recognize one of the fundamental barriers to implementing such a system. The idea that an application has the ability to report information about security events, violations or what-have-you is great. The problem, however, is that because this functionality is found within the application’s runtime we may have some integrity issues. If that application is attacked and ultimately compromised the ability for that application to effectively communicate security event data with any sort of integrity is quite low. So low, in fact, that that function is useless. And this is exactly when we don’t want it to be.

This particular problem isn’t that new. The reference monitor, while not quite analogous, does provide some insightful parallels. In a nutshell, we cannot place the reference monitor-like functionality within the application’s runtime environment. If we do this, we seriously limit the effectiveness of its primary function. Now, the reference monitor concept isn’t a silver-bullet either, but the decoupling of that function from that of the application provides some compartmentalization and some level of non-bypassability (you can’t bypass the reference monitor by attack the application itself). Yes, you can attack the reference monitor and then attack the application, but you must do so in two discreet steps. This sounds strangely like an IDS doesn’t it?

So, I agree, we need the information, but is building it into every application the most effective way to do this? I don’t think it is.

Security

While chatting with a friend yesterday about approaches to integrating security into a system or software development life cycle I mentioned something that bears repeating. There must be an overall strategy to a companies information security program. And strategy does not mean a list of projects to do for a given timeframe. Seriously though, I’ve seen a lot of companies approach the security game (yes, it is a game, didn’t you know?) with what I think is a reactive/product-based approach. I don’t really even think “approach” is the proper word here. Sure, there are some “no-brainer” products that most organizations need, but understanding what that need is and successfully implementing and managing these things are not at all the same. The product approach leads to great products that are poorly implemented, improperly managed and ultimately do not provide the value they are intended to deliver. This is because they can only deliver when surrounded by a coherent, realistic and repeatable process. But even this isn’t, in my opinion, the root cause. The root cause is the lack of an overall strategy, approach, plan or whatever you want to call it to the various facets of an information security program. Instead isolated islands of projects pop up without any sense of the big picture.

Now, back to my discussion. My advice was to loosely model the CMM. I say loosely because we only need the general concepts (with some modification) to steer us in the right direction. The CMM is focused on levels of maturity. As you progress upward in the CMM things become more defined, repeatable, measurable and optimal. First thing to do is to map out the various security products, processes, initiatives and what-not to the levels of the CMM. Of course I bastardized the CMM, because I made the point to say that things like security in the SDLC come after other more pressing issues get to level 2. It wouldn’t make sense to begin a full scale SDLC project when antivirus, patching and firewall management processes are not working at all. The ideas of the CMM is to allow you to take the various categories/tasks of information security and see where your gaps are and to plan more strategically to address them. The ad-hoc, on-demand approach can work, but you get stuck in that cycle.

I’m not saying that processes, strategies and plans are the keys to a successful program. What I am saying is that these are usually conducive to creating discussions that address the appropriate problems, allowing people to stop and think about what they are or are not doing and, ultimately to develop some achievable and realistic goals. Many times, unfortunately, organizations are stuck in the producto-reactive cycle.

Security

I just noticed (yes, I’m a bit slow) that about six months ago the OWASP project put up a page on risk rating. I’ve reviewed it and find it quiet usable for many organizations. Of course, it requires some customization, but it is much more applicable to corporate application environments that what is currently available.

In early 2006 while at my previous employer we spent many long hours attempting to create a somewhat more realistic approach to communicating risk. Many (read: most) of the methods available at the time were vendor-centric. They were not usable in corporate environments without a great deal of tweaking and by that time it didn’t look at all like the original method. The problem was that the metrics used by many of these methods artificially inflated the results. Everything turned out to be a high risk. Yes, some things were high risk, but not everything. The reality is that you have to have a sane risk rating system so that the truly high risks actually get fixed. If everything is high risk, then nothing is high risk and no real work will get done.

Anyways, we came up with something a bit similar to what OWASP has done. We took it a bit further and developed about nine, I think, characteristics of a vulnerability that could each receive a rating of 1, 2 or 3. We struggled with the subjectivity of Risk = Likelihood x Impact. To curb the subjectivity we had to identify what elements contributed to making a vulnerability more likely to be exploited. Before this method, it was simply an educated guess that produced a number usually between 1 and 10. While each of the characteristics are still determined by this educated guess, the collection of metrics provides a more balanced result. Breaking the vulnerability’s likelihood into discrete characteristics allows the guesser to treat the elements uniquely and realistically. During our QA sessions with the method we saw many high risk vulnerabilities move to medium risk. The simplistic, single number metric of the old method loads in too many assumptions to be useful.

During the development of our method we found that in a corporate environment there were enough differences between off-the-shelf applications and in-house applications that some of the characteristics did not make sense in both contexts. Having a sane risk rating process is nice too, because developers and architects can also play the game too. Since the characteristics are mostly intelligible it is easy to sit in a room with the project team and rate the identified vulnerabilities together. So, in short, if you don’t have the time like we were fortunate enough to have, use what the OWASP project has provide. If you do have time, trust me here, use the OWASP project’s work and build from there.

Security