D-kriptik Blog

And, here is part three. I’d wager that our feed readership has dropped from ~40 people daily to ~5. To those ~5, well, enjoy!

-

Where was I? Oh yeah, rambling about security and the human factor.

There is this big word we have all said before, trust. Trust can mean lots of things, but, at its heart, trust implies risk or vulnerability. Trust is about having faith that someone or something will act a certain way when it counts. While you may be able to influence that someone or something to act that certain way, in the end, the actions are out of your total control.

Trust is often at the root of an attack. For example, we trust that piece of software by running it on our system. That software could, in reality, be a trojan. Or, it could have a buffer overflow that results in an attacker gaining full access to our system. Or, it could just eat CPU cycles and do nothing in return.

Social engineering is often tied to trust. You get people’s trust, and then you exploit that trust. This involves overcoming people’s fears and concerns over assuming risks and exposing vulnerabilities. Sometimes overcoming such things is easy, sometimes not. Responsibility is often a key factor in determining the difficulty involved.

(Interestingly, I recently observed someone use a different tactic for social engineering. Rather than trying to gain trust, they took the approach of being underestimated. With their motives and capabilities completely underestimated by their target, their target deemed them harmless. I watched this person use such techniques to glean a ton of information from an unsuspecting individual.

What really caught my attention about this was the question of whether such an attack relies on trust. Instead of trying to overcome concerns about assuming risk, this person bypassed the whole issue by not being a risk at all. No need to trust someone when they pose no threat. And, no, this is not simply a terminology discussion. Under certain circumstances, I think the effort expended using an underestimation technique may be less than trying to build trust in more explicit ways.)

So, what are we to do about all this?

First off, we need a threat model. We need to figure out what we want to protect, its value, the potential attacks, the likelihood of those attacks, and the potential damage of those attacks. Determine the risks, and then mitigate them. Very important here is figuring out who needs to be held responsible for what mitigations and countermeasures. And, this threat model has to be reviewed periodically to keep it up to date. The assets that need to be protected change, the way business is done changes, the risks change, the mitigations change. Security is not static.

With that (and building that is certainly not trivial), we have these people, you, me, our parents, that are part of this threat model. They pose risks, and they help to mitigate risks. We need to minimize the former and maximize the latter. To do this right, I think we need people to feel responsible for security. To build this sense of responsibility, we need these security responsibilities audited and we need effective training to convey and reinforce these responsibilities – the combination of these two may be a linchpin to people security.

So, we talk to people about our threat model. Not only do we teach it, but we get feedback on it. And, we make sure everyone understands that threat model, and their place in it. To do this, we bring vivid examples from security audits into our security education, which help to build security training programs that provide exactly that which we learn the most from, experience.

What exactly should these examples be?

Well, lets look at a bad example you may have considered at some point. As part of your security presentation on passwords, an IT person runs a crackers against people’s password hashes and shows how trivial it is to crack weak passwords. Is this effective? Well, I tried it at one point, and, no, it failed. One reason was that people felt I already had access to their passwords, which made the whole thing silly to begin with. This was the stuff I had to deal with, not them. Another reason was that password hashes, dictionary attacks, and cracking in general really have no meaning to most people. Which meant, this demonstration was not about the people being trained, it was about me, and so it did not hit home, it could not serve as real life experience.

Now, lets look at a much better example. In preparation for security training, you have someone sit outside your organization auditing whether people were taking off their ID badges before leaving work, as was mandatory. As part of this audit, the auditor photographs the ID badge of someone leaving the offices still still wearing their ID badge. The next day, that person comes to work to find you sitting at their desk wearing an ID badge with their name but your face. Now, that would make an impact.

Keeping with this scenario, lets say you use that photo to create a fake ID, and then try to get through security with that ID. Say you make it through security. Well, now the security staff becomes part of the demonstration. And, say, sitting at this employees desk, no one stops you to question why you are there. Or, perhaps they do stop and talk to you, and you talk you way out of their questioning. Well, more for the demonstration. And, lets say you are caught at some point during this process. Great, more for the demonstration. I didn’t say the failures were necessary, just that we needed real world experiences to which people could relate.

Of course, that may be considered an elaborate setup, and maybe it goes beyond your threat model. Maybe you want to keep it very simple. Perhaps a bit of dumpster diving could be used. Or, maybe have a stranger walk into the office building and wander around. Did they get through security? Did anyone stop them? Did they talk their way out of it?

Now, pull the results of these attacks into your security training. Will there be an impact?

Well, I think so. You don’t quickly forget seeing yourself and/or those around you up in lights, as it were, and the attacks can certainly be used to increase the sense of responsibility felt by every employee. The demonstrations hit home because they can be related to – the attacks happened to you, your neighbors, your community. Whether the attacks succeed or fail, they amount to a shared experience for the organization, and teach people their importance to the security of their organization.

I think people would feel like their security responsibilities are not just words but actual obligations which have real consequences to the security of an organization. The threat model lays this out, but the experience drives it home. Also, people would be aware that their organization takes security seriously and is willing to proactively audit that security. And, those audits involve real life employees, doing the right thing and maybe even the wrong thing. It lets people know that they are at the root of security.

Anyway, this ramble seems like a good research area these days, and I think there is a lot to (re)learn about security from these vantage points, at least, for me. It’s vintage, sure, but, hey, I know lots of people that wear vintage. And it looks good.

And, that is where this ramble ends.

I guess it is time to pick up with part 2 of this ramble, since some have asked. I may be playing with the concepts from the ramble, but I was actually planning on letting the ramble itself die without posting parts two and three.

-

I once shared an office with a great Windows developer for short duration a few years back. During this period, I had some free time, and I wanted to learn how buffer overflows worked from more than just a theoretical perspective. So, I started playing around with stack-based and then heap-based buffer overflows. I eventually managed (using other peoples’ shellcode) to exploit test code, then real world code (using already well-know bugs), and then I stopped. I stopped because I felt knowing the basics was enough for my purposes. The attacks were all essentially the same, regardless of the complications one had to go through to get their shellcode in well-layed-out memory and then executed. At least a couple of years before I did this, I was able to use stack-based buffer overflow exploits, although I only had a theoretical notion of why they worked.

Which is to make two points – 1. Technology is a tool, and 2. People don’t have to understand that tool in order to use it. (I guess a third point is that many exploit authors understand points one and two.) Let me harp on this a bit because, well, I say it all the time and love to say it. Technology is a means, not an end. When a technology stops being useful, when the burden of a technology outweighs its benefits as a tool, the technology will not be used. Technology for technology’s sake is just ridiculous. Which is where I think security technology, and the broader IT security arena, sometimes hit a wall. Then throw people into the mix, and the products (and processes) fail to even provide the protections intended. Perhaps the technology is so burdensome people find ways around it or just avoid it (e.g., DRM). Or perhaps it cannot be understood so they just ignore it (e.g., browser SSL warning dialogs).

Unfortunately, I have heard a few IT security people complain about people, but I think that completely misses the point. People make the world of people go around – security itself is about protecting people and their property. If your security mechanisms can’t work with actual people, then such mechanisms are often worthless by design.

Speaking of people, I sometimes hear talk about new attacks, which, when you look at the attacks, are really just the oldest of attacks, exploits of the people factor. Take phishing – this is a new variant of an old attack, as many a con has been based on just looking the part. This is where I think security people need to step back and just look at people. How do people think? How do they make decisions? Etc. And think about the old school based people attacks. How do they work? How might they work in this day and age? Etc. A little history may go a long way.

Anyway, lets involve those squishy targets, people. Technology too, perhaps, but people more so. Lets be a little classic, by ripping through some common scenarios security people throw out there.

For example, we have all thought about utilizing maintenance or cleaning staff as an attack point, as it is a common thought point in office security discussions. Think of shared office space – getting access to the phone closet is often just a mater of notifying the building management that you have someone coming from the telco that day. Or, how difficult do you think it would be to get the night cleaning staff to give you access to a particular office space? Looking the part, uh oh, it could be game over. (If nothing else, you could end up in the dumpster after the cleaning staff leaves.). Or just spoof being maintenance staff yourself.

Much simpler, gleaning sensitive information from someone you meet in a bar. Get them talking about that new project they are working on, or those lovely holes within the security at their company, or what have you. People love to talk. Throw in alcohol, and they may talk even more. (Now, just get good at picking out the truth from the bravado.) Using this approach, I sometimes wonder how hard password cracking would be. You can talk about job, family, kids, age, birthdays, background, maiden names, pets, crazy people that celebrate pet birthdays, etc. Build a relation, and gather lots of information that we openly discuss in social settings, some of which is used as secrets in other settings (remember my rant?). Perhaps then we can talk about online banking, or where we like to shop online. Perhaps we can talk about the nonsense security at work, such as me complaining about the ten passwords I have to remember at work. Oh, wait, lets talk about passwords and what I have seen, since you now know I work in computer security. I wonder if, say, I start bringing up weak passwords like a pets name, whether the person I am speaking to would reveal, through body language, at least, whether that was similar to their password. My guess, you could walk away with a good idea of some people’s passwords just through such a conversation.

And, how hard is it to get an image of someone’s ID badge? A cell phone camera in a bar might get enough detail at a close distance. You might even be able to swipe the magstripe. Even at a distance, quality cameras should be able to provide a clear enough image. From there, generating a reasonable reproduction should not be rocket science. How well are IDs checked at most organizations? I know many a shared office space that requires ID for admittance, but these IDs often receive a cursory glance by a rotating security staff.

Or go for laptops. Or hit people at hotels and conferences. I wonder how hard it would have been to steal a specific laptop at a conference like RSA. Better yet, steal it, rip its memory, and then return it. Maybe we could even just hook into the firewire port. Some blatant social engineers might be of use here – they appear to be quite effective.

Maybe you could just try walking into a large office looking like you belonged there. Will anyone notice? Could you provide a plausible reason for being there, if needed? Perhaps an outside consultant. Or, someone from IT checking up on suspicious behavior coming from a particular machine. Pop a few keyboard sniffers here, rip a few hard drives there. Not too shabby. (Here, beauty might be a drawback, as it is conspicuous. Then again, it might be an advantage, as it could reduce a security audit of that new face to little more than a friendly conversation.)

The attacks are endless, and we have all thought about many of them before. Nevertheless, I’d wager that they are still effective. And, that is what I am getting at.

It’s funny too. Extending our base programming, experience is what trains us to make the decision we most often make. When to cross the road, how best to put out a fire, what is causing that network issue, is that bug exploitable. Life moves too fast and is too complicated to create a list of options, research and rank them, and then choose the best. Instead, the best option just surfaces based on previous experience. For example, if we are used to strangers being in the office all the time, then we will probably tend to ignore strangers in the office from a security perspective. If someone is wearing a uniform, then they are most likely what that uniform implies (e.g., a security guard, maintenance staff).

So, I think about least privilege. I think about dividing privilege amongst many people, to make my attack against any one person quite difficult. But, I wonder how well this works. A distributed attack could leverage this separation. It reminds me of the classified world. Any piece of information by itself might be unclassified, but puts those pieces together and you suddenly have classified information. Use multiple targets, piece together information, and, well, there you go. From this perspective, it seems like distributed privilege may actually benefit an attacker. People are less likely to feel that their minimal access is worth anything, as other pieces of minimal access are necessary for privileged access. That flies out the window when we are actively targeting accumulation of all those pieces.

Ok, so we need logging. We need communications archived. We need actions recorded. We need logs/archives/records audited. Great, now we may know that something bad has happened. In fact, we may know exactly what that bad thing was. We may even be able to trace it back to someone, whether that someone is really the culprit or not. Those are important features. But, building a picture of what may have happened is quite different from stopping the attacks from happening in the first place. It helps the next time around, not this time. And, it only helps if we can build the right picture and learn the right things. And, you know, for all the logs/archives/records in the world, knowing that someone told me something they shouldn’t have in a bar in the LES is not likely to be traceable (to me, at least). Knowing who ripped information off that laptop, who planted that rogue wireless device, who copied your companies’ hard drives, is not necessarily going to be stored anywhere. Part of the point of using people is to find the ways to bypass security mechanisms, not fall for them.

The thing is, all our base programming and all our experience can be used against us. From the power of beauty to inaccurate perceptions of risk, it could be that security mechanisms fail to meet their objectives because, well, real people are involved. When security does not hit upon how real people act out there in the real world, it seems to miss a big chunk of risk.

So, this post is motivated by a couple of recent threads on FIPS 140. I have noticed that whenever FIPS 140 becomes a topic of a mailing list, blog post, or some other such forum, the discussion is generally one (or a combo) of the following. (It has been a long day, so hopefully this post is coherent enough.)

1. A vendor has been put at a competitive disadvantage because they do not have FIPS 140 validation. Perhaps their competitors have it. Perhaps a bid requires it. Whatever the case may be, they don’t have it, so now they want to tear it down.

   Also found here are people that just dislike FIPS 140 or, perhaps, standards in general.

2. A vendor has gone through the process, and it was quite painful. So, now they vent about all the changes they had to make, how silly particular requirements were, how incompetent the lab staff was, etc.
3. An expert tells stories of how the requirements are ambiguous and the labs all vary in how they interpret the requirements.

   Also found here (and often quite different from the previously described expert) are people that have run into FIPS a number of times over the years, which has caused them exposure to differing requirements without having seen the evolution of those changes.

So, I was thinking about what triggers these three bullets. What are some causes of excessive pain in going through a FIPS 140 validation? How ambiguous are the FIPS 140 requirements? Do the labs really vary much? My focus is bullet two, but lets discuss one and three first.

• I think one mainly stems from a vendor that is not willing, or just unable, to go through the FIPS process. Since FIPS 140-2 validation is ruled out by such a vendor, the only course of action is to question FIPS 140. Unfortunately for such vendors, attacking FIPS 140 does not change the fact these requirements are what the US government wants to see in cryptographic products it uses in sensitive but unclassified environments.

  As I wrote recently outside of public view,

  I assumed this as a given (in both the metzdowd crypto and dailydave threads), but perhaps it should be noted that FIPS 140-2 provides a baseline set of requirements for a cryptographic module to be used by the US government in sensitive but unclassified (SBU) environments. If a US government agency finds that it needs to secure information using cryptographic measures in an SBU environment, then it uses a product that meets this baseline to provide these cryptographic services.

  (Of course, others are free to adopt (portions of) these requirements as well, such as the financial or media communities. This sometimes happens outside of the US, but the cryptographic algorithms permitted are changed and perhaps things like FCC testing are omitted.)

  And, yes, the number one push for vendors to go through a FIPS 140-2 validation effort is a desire to sell to the US government. If you want your crypto product used in an SBU environment, then you have to meet the baseline security mandated for such an environment. Lots of people seem to complain about this, but it makes sense to me.

Moving along,

• I think three is mainly a means of spreading disinformation in order to drum up work for the author. There is not much else to say about that.

  However, three can also result from someone having seen smatterings of FIPS 140 over the years but not having the full picture of the evolution of FIPS 140, which I think includes many people that have a large amount of applied crypto experience. This may be an example of that.

  In addition I’ve heard of evaluations where the generator is required to use a monotonically increasing counter (clock value) as the seed, so you can’t just use the PRNG as a postprocessor for an entropy polling mechanism. Then again I know of some that have used it as exactly that without any problems.

  Breaking this short paragraph down in terms of FIPS 140 is not quite trivial, so lets take a look…

  • Under FIPS 140-1, IIRC (and it has been 6 or so years since I last looked at it), there were no explicit requirements around PRNG seeding. So, one could get away with using a clock as the seed to the PRNG. Most often, labs would point this out as a problem, but, without FIPS teeth, they could just recommend that a vendor change it, not require that they change it. While I have never heard of a lab recommending that a vendor use the system clock alone to seed the PRNG, it was possible under 140-1 for that to happen. (Requiring it, well, no.)
  • Under FIPS 140-2, this hole in the standard was fixed. Sure, it took interpretation of the key management requirements to translate to all FIPS-approved PRNGs that seed themselves internally having a seed that meets a baseline strength requirement, and that baseline seed strength requirement had to be translated into a set of entropy gathering techniques that the labs thought reasonable, but, that happened fairly quickly after the release of FIPS 140-2, and there are now standard techniques that all labs smile upon at this point. (And, no, the labs (and NIST/CSE) do not accept solely the system clock being used to seed a PRNG.)

  As you can see, two different versions of the FIPS 140 standard as well as many years of time were covered in the quoted couple of sentences.

And now the one I really wanted to discuss,

• I think two is the result of number of components, some of which break down as follows.
  1. Vendor misunderstanding of the FIPS 140 requirements and terminology.

     The FIPS 140-2 standard itself is fairly vague, but the language of the standard has been translated into a set of vendor requirements and testing requirements in a document known as the Derived Test Requirements (DTRs). If a vendor does not know about this document, they can make up all sorts of ways to meet the wording of the FIPS 140-2 standard that having nothing to do with the intent of the standard. Even using the DTRs, vendors can sometimes make mistakes. And, once a misunderstanding is made, the vendor may implement things that were not required by FIPS 140 and may even miss things that were.

     Also here are misunderstandings of terminology, which can quickly lead to things like the lab digging into parts of a product that normally would not need deep examination because the vendor implied FIPS 140 relevance through improper terminology. These misunderstandings can be damaging both in terms of inaccurate documentation as well as ineffective lab interactions.

  2. Vendor misinterpretation of lab (or NIST/CSE) questions and issues.

     I think that vendors often do not know what the lab is trying to get at when asking questions and can make changes that have nothing to do with the issue the lab is really trying to have addressed. This can lead to chains of events, such as, the lab raises an issue, the vendor makes a change, the lab riases the same issue, the vendor makes another change, the lab raises the same issue, the vendor makes another change, and the lab is finally happy. The vendor then feels that all those changes were required by FIPS, when perhaps just the last change was necessary to resolve the issue.

     Also here are difficulties that arise when a vendor says the wrong thing to the lab, tries to figured out what the lab is getting at and answer that instead of the lab’s question, or just writes long winded responses to lab questions/issues. You can easily say the wrong thing, and that will result in far more digging by the lab, even though it would not be warranted if the vendor response was more accurate in FIPS 140 terms.

  3. Labs can, and do, make requests and recommendations.

     Such suggested changes are not required by FIPS 140, but the labs feels they would be good for some other reason, such as security or usability. Sometimes vendors misinterpret these requests as required changes.

  4. New labs, new lab staff, new technologies, and new revisions of FIPS 140 (and related) standards can make for created requirements. (This is where you can find the most variation among labs.)

     A new lab or new lab staff might create issues that don’t really exist under the FIPS 140 requirements, as they themselves do not have much experience with FIPS 140. For example, software validations are the most common area of difficulty for new labs or lab staff. Software does not fit well into FIPS 140-2, and so you can hear ridiculous requests from new FIPS 140 people in this regard.

     New technologies and new FIPS 140 (and related) standards often require work to figure just how the FIPS 140 requirements are to be met. This results in quite difficult validations, and there really is not much to be done here except to grind through it. (With FIPS 140-3 coming down the pipe, this should be kept in mind.) For example, when FIPS 140-2 first came out, no one knew exactly how all of the new requirements were to be interpreted. Those first few validation were painful, drawn out, and basically test cases to solidify the standard. Another example, when IPsec VPNs first came out, FIPS 140-1 interpretations had to be established to meet bypass mode requirements. FIPS 140-2 did its best to pull these interpretations into FIPS 140, although this is one of the more ambiguous parts of 140-2.

All this can add up to extra work, more money, lots of frustration, and perhaps even tears. So, what can you do to avoid an agonizing FIPS 140-2 validation? It really boils down to knowing the requirements and the process.

If you are willing to bring in an outside FIPS 140 expert or have internal FIPS 140 expertise, then that is the best way to get through a validation. Experts know the requirements and the process, and can make validation as painless as it can be.

Without expertise, you can get started by building up a basic understanding of the FIPS 140-2 terminology, process, and requirements. The Cryptographic Module Validation Program (CMVP) website is the place to begin such research. Besides the FIPS 140-2 standard and, more importantly, the DTRs, there are documents like the annexes (A, B, C, D), implementation guidance (IGs), and frequently ask questions (FAQs) available. More so, there are lots of examples of Security Policies out there to help you see how other vendors navigated the requirements (at a high level, at least).

Your thoughts?