Epistemological Relativism

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

Many times in my religious experience I’ve had a desire to throw the baby out with the bath water because of the sheer stupidity of the present. I’m sure I’m not alone there either. For example, when reading about early church history and practices I would imperiously declare that the Greco-Roman Gentile converts-turned-leaders had gotten it all wrong. It was because of this confusion that Christendom was in such a sorry state today or so I thought. Naturally, the only real alternative was to throw everything out and start from the beginning. It took quite some time to realize that this beginning-ness had problems of its own. Where was the beginning? This jettisoning of tradition (whatever was left to begin with), the community of faith (past and present) and the general attitude of mistrust, however, made it nearly impossible to recover any sort of religious bearings. Barth is amazing because he manages to understand this dilemma and chart a course that avoids the problems that come from this type reaction and yet remain fluid enough to introduce needed corrections to the community. Barth will not allow everything to be discarded. He may give away too much in assuming that the community of faith did not go critically awry in the not-so-distant past, but he does not create an ivory tower out of this community of the past that is hitherto immutable.

Certainly, the assumption behind all this will be that the community itself may have been on the right track in the recent or remote past, or at any rate on a not altogether crooked path. Consequently, fundamental trust instead of mistrust will be the initial attitude of theology toward the tradition which determines the present-day Church. And any questions and proposals which theology has to direct to the tradition will definitely not be forced on the community like a decree; any such findings will be presented for consideration only as well-weighed suggestions. Nevertheless, no ecclesiastical authority should be allowed by theology to hinder it from honestly pursuing its critical task, and the same applies to any frightened voices from the midst of the rest of the congregation. The task of theology is to discuss freely the reservations as well as the proposals for improvement which occur to it in reflection on the inherited witness of the community.

– Karl Barth, Evangelical Theology (Eerdmans, 1963) 43.

–Update: Did anyone notice that I used the word ‘hitherto’?

Theology, Thoughts

As a parent who is always proud of my children’s successes, their best efforts despite failure and the ability to laugh at a moments notice, I have to say that I was particularly impressed this afternoon. I was reading my new copy The Dangerous Book for Boys (more on that in another post) when I turned to a page with a picture of Gaius Julius Caesar. I had been showing my children page after page of all the cool things in this book. I asked my seven-year-old daughter who she thought the person in the picture might be. She nonchalantly replied that it was Julius Caesar. Now, I don’t know about you and maybe I don’t get out enough, but I sure didn’t know who Julius Caesar was when I was in 2nd grade. Another proud moment for a parent.

General, Homeschool

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

Somewhat related to my ‘A Variety of Lenses‘ post, Barth in Evangelical Theology has some interesting things to say.

The remarkable assumption behind this project [the exegetical-theological task], however, seems to be that the content, meaning and point of biblical assertions are relatively easy to ascertain and may afterward be presupposed as self-evident…The truth of the matter, however, is that the central affirmations of the Bible are not self-evident; the Word of God itself, as witnessed to in the Bible, is not immediately obvious in any of its chapters and verses. On the contrary, the truth of the Word must be sought precisely, in order to be understood in its deep simplicity.

– Karl Barth, Evangelical Theology (Eerdmans, 1963) 35.

Theology

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

I was writing a bit off-blog about how different people approach the Protestant Bible. I thought it was interesting so I brought it into the blog to share. For a bit of context, I was speaking with a friend where I was mostly listening to him explain why his informed views of the meaning of the biblical text are to be preferred. Of course, like many people, his explanation was nothing more than an appeal to, “It is so clear, how can you *not* see it my way”. What he did not understand and, at first, acknowledge was the critical role that assumptions play in this process of understanding. Some people call them assumptions, others call them axioms and still others call them facts. The truth of the matter is that these assumptions, the lense by which we view the biblical text, are not themselves built into the text. They are part of our overall approach to reading texts like this. The challenge is that not everyone has the same set of lenses and yet many feel there particular brand of spectacles are the only ones authorized for this use.

These lenses control and in some ways determine how we understand biblical texts. This can be good and bad. If our lenses do not include the consideration of the cultural and historical context of the text things can get dicey. These considerations should constrain the possible meanings. Yes, you heard it right, we may receive the text in a particular way, but that is something entirely different than what the author intended and the first recipients may have understood . Many presume that our twentieth century lenses our the ultimate instrument to see the real meaning of a text. Unfortunately, this includes many, many people. We have to ask though, whether it is appropriate to view a text in a way that is disconnected from its temporal-spatial origin.

It sounds like I’m placing ancient texts in a vault and giving the key to a select few. Perhaps, this is the result and maybe that isn’t a terrible thing. In fact, in evangelical circles, this is the de facto standard anyways. Actually, this is the reason why I am blogging about this to begin with. Many people listen to those in authority who, with mostly good intentions, communicate the meaning of texts without communicating the method and built-in assumptions. I think the quote below from Frank Beckwith, a recent convert to Catholicism, summarizes the dilemma that most simply ignore.

In fact, it was just such reasoning that pushed me toward Catholicism. I thought to myself that if sola scriptura can result in everything from the philosophical theology of Calvinism to the Open View of God, from Nicean Trinitarianism to social trinitarianism to Oneness Pentecostalism’s rehabilitation of Sabellianism to 19^th-century Unitarianism, then sola scriptura is not a sufficient bulwark for sustaining Christian orthodoxy.

Philosophy, Theology, Thoughts

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