Over the past several weeks a colleague and I have embarked on a mission that is probably akin to finding a sea route to the Indies in the 15th century. We call it a security ontology. I think this is a decent label. Since we’ve been trying to redefine and/or correct some of the old-school security maxims and practices for the past 4 years or so we thought that what better way than to revisit terminology. We could place that terminology within its semantic domain and, most importantly, map the relationships between these terms. In the end, we could all speak a similar language and sort of create or own linguistic community. It’s almost an experiment in more ways than one. Security terminology has always been an organic evolution. Hutton and Mortman would call this anarchy. I don’t know if I’d go *that* far, but it does catch the eye. So far, this project has gotten us through an information system model (necessary since that is usually an object of desire in most cases), typical vulnerability, adversary and attack language and now we’re right in the middle of everyone’s favorite, risk. Hopefully we’re not stuck in the Bermuda Triangle for too long. One of the primary epistemological measurements (or epistemic justification) that we’ll be using to determine if it “works” is coherence, or, how well do the individual pieces connect together to form a system of knowledge. Yes, it has it’s flaws, but I think this is a good first step. Anyone else working on something like this?
Security
Philosophy, Security
So, I’ve written some Ruby classes that interact with a web application that provides web service-like functions. One of the “interesting” features it provides is authentication. Having created the Ruby API to authenticate users I now want to try to use timing attacks to enumerate valid usernames. Unfortunately, I have not been able to find anything that fills this role. There is Benchmark, but it is more focused on CPU-like measurements. I’d like a tool that is focused on measuring time between HTTP requests and responses and makes adjustments for any overhead associated with Ruby itself.
Security
Timing Attacks, Tools
Since I don’t blog nearly enough, I figured I’d at least use this as a dumping ground for all the lame ideas I have for tools that would have made my life easier. The first tool, or the most recent tool that would have saved some time, is the ssl-cert-spoofer-helper. Can you see that I’m not very creative? In my experience, especially with the iPhone you not only need a trusted CA certificate on your iPhone, but a server certificate that looks *almost* like what the iPhone application is expecting. Specifically, the CN has to match the original. So, rather than go through the trouble of grabbing the “real” server certificate, examining it, and using openssl to generate my CA and fake certificate, I would like a tool that does it all for me. I started working on one in Ruby, but it isn’t terribly interesting OR fun….at all.
Security
SSL Certificate
The classic CIA Triad (Confidentiality, Integrity and Availability) as it is affectionately called has been used for decades as a means to coarsely outline certain security/assurance expectations of a system. It has lasted this long because who can forget a TLA? Sadly, it is too general to be used effectively in most application security endeavors. There have been many who have attempted to elaborate on the triad to make it more useful. Microsoft’s Security Frame was a great effort. It identified the important and relevant categories that were hidden away within the triad. However, going from a TLA to a set of ten concepts or IAACSSCEA isn’t exactly easy to recall. Yes, I know, this should be documented as part of a defined process chock full of cheat sheets, tips and lists. Well, in an effort to align these concepts with my view of security functions and properties I created a set of six concepts that are derived from CIA, but that add more precision. You’ll probably recognize some of these labels. Yes, some of them made sense to retain from Microsoft’s Frame, others were useful labels gathered from the Common Criteria (oh no! not that!?). So, I managed to trim a few items by merging them with a more common categrory. Let’s see if an uninformed reader can make sense of these:
- Accountability and Event Reconstruction
- Data Protection
- Identity and Access Management
- Exception Management and Availability
- Management and Configuration
- Survivability
Identity and Access Management is perhaps the most intuitive category. In encompasses authentication, authorization and other concepts related to access control. Accountability is also fairly straight forward. What is your take on the others?
Security
Application Security
Today I had an interesting discussion with a colleague who will remain nameless. The subject was one of my favorites: attacks and countermeasures. One of the methods that we employ to evaluate new, existing or emerging technologies is to run it through the attack tree gauntlet. When the gauntlet is run we are left with a variety of attacks that range from the real to the completely theoretical. Following this and other bits to be discussed later we try to discover countermeasures for each of the attacks. The countermeasures range from factoring out the exposures or adding compensators to reduce the as yet unquantified risk.
Here is where the fun started. I am of the opinion that there has to be some method for quantifying the effectiveness of the countermeasures. In other words, if I deploy one of the discovered countermeasures how much does it really help? We have a bad habit of listing countermeasures and taking the all-or-nothing approach. I happen to think we can use an informal qualitative method of communicating effectiveness. What does such a method look like? Well, a rough percentage works for me. Some complain that it is too “gut-check” oriented. They’d be right. However, I’d have to argue that the very method for discovering countermeasures themselves is a gut-check. “Say it ain’t so!”, you claim. Sorry, it is. If we can’t say a thing about how effective a countermeasure is then how can we claim it can do anything at all? The fact is that we use intuition, reflection or what some would call our experience to make a universal claim. Induction anyone? If we can use experience to discover the countermeasures themselves then why can’t we also use the same set of collective experiences to estimate the effectiveness (Induction again..) “Yes, but what numbers are you going to use?”, you may ask. You can use any range, scheme, etc that works for you. I use percentage in increments of 10. I like this because it is easy to reason with it. “80 times out of 100 AV is effective against non-0day malware delivered via E-mail.”, seems to work for me. Is it too detailed? I don’t think so. I think a broader range is better for the types of estimates we’re dealing with. If we use high, medium or low we run the risk of grossly over/under estimating. The bottom line is that we have to provide information to make informed decisions. We don’t get this right very often. By exposing our assumptions and methods we can move away from the “black magic” of the security practice. Being fearful that our methods are not “scientific” is a lame excuse for not trying in my opinion.
Security
Over the past several weeks I have had the pleasure of reading through a large stack of academic papers (that I could retrieve without cost) on security requirements. As I suspected going into this task there were as many opinions on the proper way to elicit, describe, generate and document such things as there are tastes in chocolate. That said, there were some gems that I found scattered throughout. It may be that I consider them gems because they happen to agree with my thinking on the subject, but I digress. Why did I go to all of the trouble? In my almost insane quest for continually improving the state and practice of security I knew that there had to be a better way of “doing requirements” and introducing this part of security into a lifecycle (however broken it might be). I’ve seen bizarre checklists, a ream of non-functional requirements appended to a project with almost no budget or critical regions of functionality and unintelligible policy-laden statements trying to masquerade as requirements for engineers and designers. It is a mess. It gets worse. Most of the time requirements of the security variety, in whatever form they appear, may be all that a project team ever sees prior to construction of their widgets. Not only is their an interpretative barrier at times, but the fact that we’ve left requirements at the door without venturing further into the various stages of a life cycle guarantees that things will break.
It really doesn’t end after requirements. Well, it may if your requirements look anything like what I’ve discussed above. After requirements someone has to come along and take that information and turn it into some form of design. It seems to me that security requirements are for the most part existential statements about security *functions*. That’s where some security folks go wrong. We think that requirements are really just a synonym for policies and procedures. Sorry, they’re not. They should be something closer to prescribed functions of a system or constraints on functions dictated by business requirements. A simple example is authorization. We can make some general statements about the existence of an authorization component. Something should be there to grant the appropriate entitlements to a user. This make sense right? What sometimes happens though is that we load in all sorts of other implementation or design requirements into the cart. When we do this we run into all sorts of problems like traceability, complexity and adoption. Should statements about least privilege, compartmentalization or filesystem access control lists be included in requirements? I don’t think so. Those states are either design principles and constraints or implementation details. Maybe if we can think about security expectations more broadly we will realize that those expectations can be articulated in a more contextually useful manner. Here is a very coarse taxonomy of what I’m talking about.
- Goals
- Non-Functional Requirements (Security Functions, Attack Resistant Qualities)
- Design Constraints/Principles
- Implementation Guidance
Each one of these categories depends in some part on its predecessor. You can see the process here. We’re moving from the general to the specific. What security people typically do is something like this:
- Requirements = Policies, Standards, Attack Language, Security Functions, Design Statements
It is a wonder that any of this makes its way into a final product. There could be information in that bundle of joy for developers, architects, requirements engineers, business analysts and others. To make things work we have to do a better job of understanding the who consumes our documented expectations. We can’t use the kitchen sink of requirements if we really want our applications to be “secure”.
Security, Thoughts
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.
Security
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.
Security
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
Security
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.
Security