There has been much criticism of risk assessment and analysis over the past few years that amount to much ado about nothing. Why is it much ado about nothing? Well, because, quite simply, people oftentimes don’t understand what it is they’re criticizing, especially in the case of quantified risk analysis methods.

Before we get into risk measurement, let’s first make one thing clear: risk analysis is nothing more than a decision-analysis (or decision-support) tool. It helps provide reasonably accurate data points that decision-makers can use when make decisions. It is not a panacea for all things risk or infosec, nor is it some sort of special magic-sauce voodoo with no grounding in reality (at least not in terms of well-considered quant methods). Clear? Crystal, I’m sure.

When performing a risk analysis, we need to start with the basics. Here at Gemini we subscribe to the Factor Analysis of Information Risk (FAIR) methodology for performing quantified risk analysis. FAIR defines risk as “the probable frequency and probable magnitude of future loss.” What this means in real terms is that FAIR reduces “risk” into two main components: Loss Event Frequency and Loss Magnitude. Both are estimates that are created using Douglas Hubbard’s calibration technique, as advocated in his book How to Measure Anything.

Read the rest of this entry »

Recently, Vinay Deolalikar self-published a proof that P is not equal to NP. So what does that mean exactly?

P is short for Polynomial, and NP is short for Non-deterministic Polynomial. To understand the exact difference requires you to understand Turing machines (usually a senior level CS class). P is the class of problems that can be solved in polynomial time on a deterministic Turing machine in polynomial time, and NP is the class that can be solved on a non-deterministic Turing machine in polynomial time. Here’s the catch: so far, no non-deterministic Turing machines exist. There’s speculation that quantum computers are non-deterministic Turing machines, but not a proof that I know of.

Another way of thinking about P and NP problems is how long it takes for a computer to solve the problems – is it “easy” (P) or “hard” (NP). Most classic computer science problems are NP – the traveling salesman, factoring integers… The computer can verify the answer in P time, so the current approach is to make a best guess, verify it, then make another guess.

What does this mean for most people? Most people have never heard of P or NP – heck, a lot of computer/IT people probably haven’t unless they’ve studied theoretical computer science – and even most of us who’ve heard of it would rather forget it. But it really does matter for security. One of the NP problems is factoring integers – what public key cryptography is based on. There is an assumption – based on years of practice, but no proofs – that NP is not equal to P. If NP were ever shown to be equivalent to P, then our current asymmetric cryptography solutions would be blown out of the water and we’d all have to find new algorithms to use. If NP were proved to be not equal to P, we’ve got some more time

So far, the reviews I’ve heard of Deolalikar’s paper is that it’s a great start, but it has a few flaws, so we still don’t know if P is or is not equal to NP.

Researchers have developed a method (pdf) by which they are able to record the sound of a dot matrix printer in operation and recreate the information that was printed based on the audio data. Data leakage from electronic devices isn’t new (TEMPEST comes to mind). However, it seems like the higher-profile methods tend to encompass electromagnetic properties rather than mechanical properties.

Read the rest of this entry »

MD5 is a hashing algorithm created in 1991 and still used by many applications for certain features. But MD5 is no longer recommended for many cases due to weaknesses discovered in the last few years, opening up some scary possibilities. At the end of this year, NIST standards for cryptography used by the federal government will no longer permit 160-bit SHA1 hashes or 1024-bit RSA signature keys, since concerns over the long-term security of these technologies are rising.

With cryptographers constantly working on new algorithms and breaking old algorithms, one may get nervous about whether the foundations of today’s secure transactions are really that secure. But despite the occasional ominous forecast of a cryptographic meltdown, you can remain fairly confident in encryption technology.

Just as we’re constantly finding new weaknesses in various approaches, we’re constantly finding new approaches that overcome various weaknesses. For instance, scientists are working to develop “quantum computers” that perform calculations in a completely different way than today’s electronics. These new machines would be powerful enough to crack several of the strongest algorithms currently in wide use. But just this week, several researchers demonstrated that a 30-year-old algorithm, using a different type of mathematical basis, would foil any known quantum attack. This approach has not been widely used due to large key sizes that would hinder performance, but computers are getting faster every year.

Cryptographers also work to maintain a gap between theoretical attacks and practical compromises. NIST does not wait for programs that can crack any key within seconds before deprecating an algorithm. Researchers are constantly working to build stronger systems, and often start recommending replacements when only the slightest cracks begin to show for a particular approach. Also, one type of weakness does not necessarily ruin every possible use of a given encryption method.

But while the mathematics behind today’s systems may be sound for the near future, strong encryption alone does not guarantee you security. In fact, most security problems come through either insecure implementations of a given approach or bad security practices built on top of strong algorithms. Keeping current with effective cryptography is important, but it’s only one part of an effective security strategy.

According to an article published last week, it is apparently possible to construct a signed PDF that can have its underlying data changed such that the signature is still valid, but the presentation of the data is changed.  It’s a neat trick, but there are a few things that mitigate the risk inherent in the vulnerability:

1. The signature has to be applied to a carefully crafted PDF file.   A PDF file that you create and sign is unaffected by this attack;  if you examine the data within the file, the presentation data for both the “recommendation” and “order” documents is present in both.  Obviously, you will not be adding rogue data into your own PDFs before signing them.
2. As stated in the article, it’s not really clear that the PDFs used in the proof of concept are syntactically valid PDF files.  However, Acrobat does open and display them as the attack intends, so that may be irrelevant.  Although, an Acrobat security update could fix the issue if this is the case.
3. It appears as though, by looking at the proof of concept documents, that the special construction of the PDF requires precise byte positioning in the file for the various objects used in the attack.  It is not mentioned in the article, but it may not be true that such a document can be constructed with a blank signature field that can be signed in Acrobat and subsequently attacked using this method.

It will be interesting to see what, if any, response Adobe has to this publication.  I know my way around the PDF standard (as it pertains to digital signatures) fairly well, but I’m by no means an expert.  It seems to me, though, that this attack requires several things, including the execution of the initial digital signature, to be performed in a precise way, which may mitigate the risk of the attack working in a real-world scenario.

So you’ve been hearing lately about how some Android applications are going rogue and being used to steal users’ data and infiltrate their phones, to sit idly by only to wreak havoc when the user least expects it (ok, so maybe I exaggerated a little there). But there has been a lot of buzz lately about certain apps not playing by the rules, or including certain calls to leach user information. A lot of this buzz has been spun as backlash against Google for allowing these types of applications to exist (instead of having some asininely draconian filtering process like some ‘other’ phone provider).

Well, to help defend Google (which they’ve done a decent job of doing themselves), this one falls back on the users. If you’re an Android user, you’ve most definitely seen a screen similar to this.

This screen tells you exactly (mostly) [kinda] what the application you’re installing has access to, and how far it can reach. It’s your (the user’s) obligation to agree with this and install, or not agree, and cancel out. See those two buttons at the bottom? If you don’t agree and see something that has “Cost Money” in this section and you presumed it was a completely free (as in beer) app, then you’d better click the right (Cancel) button.

Read the rest of this entry »

Risk assessment gets a bad rap these days, thanks in large part to a checkered past colored by qualitative analyses. Historically, risk assessments have been fuzzy, at best, and down-right inaccurate and misleading at worst. You know the ones I’m talking about: some hot shot consultant comes in, pokes around, maybe runs a couple scans, and then churns out a report with a bunch of High, Medium, and Low findings. However, as you dig into the results – particularly the so-called “High Risk” findings – you start finding extreme squishiness with no connection to reality, rational thought, or logic. And this is what we’re supposed to use to “better manage” security? Don’t think so…

Enter Factor Analysis of Information Risk (FAIR), a different sort of beast altogether, created by Jack Jones of Risk Management Insight (RMI). FAIR is a decision support tool that provides a means for performing a quantitative risk analysis around a given scenario. It allows you to conduct deep analysis into given asset+threat scenarios, digging into the business to arrive at accurate estimates (via ranges) for probabilities and expected losses. Loss events are divided between primary and secondary, wherein primary losses are often fairly well known (e.g. how much it costs to replace a server), whereas secondary losses can vary widely.

For an excellent introduction to FAIR, the RMI white paper “An Introduction to Factor Analysis of Information Risk (FAIR)” is highly recommended. In it, you’ll start to see the breakdown of FAIR into its component pieces. Overall, within the context of FAIR we define risk as a derived value measuring “the probable frequency and probable magnitude of future loss.” There is much that can be said about this definition and overall approach, but I’ll leave that for another day. In the meantime, I encourage anybody with an interest in risk analysis to take a deeper look at FAIR.

With a new version of Backtrack around, many people may be ready to take the plunge into learning it. This is a little late for those of you who decided to try it at Blackhat/Defcon, but ShmooCon will be coming up in a few months…

Apt is the debian packaging system. It’s found in all debian based Linux distros – like K/Ubuntu and Backtrack. If you’re going to be at a hacker conference, the least you can do is update your system before you go! Packages are generally GPG signed by the maintainer, and debian keeps a list of trusted GPG keys updated on your system (debian-keyring debian-archive-keyring are the debian specific packages). Apt checks these signatures to help ensure that you’re not downloading rogue signatures.

Apt has two configuration files. For the most part, you’ll only use one: /etc/apt/sources.list The other (/etc/apt/apt.conf) is used in specific instances – such as with a proxy server.

sources.list has a list of all of the sources (repositories) you’d like to look through for packages. The default list is generally OK for non-desktop (i.e. server) users. If you’d like to install various media players and other non-GPL licensed packages, you’ll have to add to this file. The general format is
type baseuri distribution [component comp2 ...]
Where type is *generally* deb – sometimes deb-src indicating that the repository contains .deb files that are either pre-complied (deb) or are source packages (deb-src).

Make sure you know what the repositories are before you add them! If you add a rogue repository, signatures are not going to help you – they’ll all verify!

Once your sources.list is updated, you can generally leave it alone unless you want to switch to a new version of debian/ubuntu/etc.

On a regular basis, you need to run “apt-get update” with root privileges. This will update the list of packages that have been updated on the repositories. “apt-get upgrade” will just go ahead and upgrade everything for you – which is the easiest option, but sometimes, not what you want. “apt-get upgrade -u -s” will tell you what’s going to be upgraded, but not actually do anything. If you want to upgrade some things, but not others, you’re kinda stuck using “apt-get install package-name” for each individual package. It’s not the best solution, but you can hold a package with dpkg: “echo package-name hold | dpkg –set-selections” and it will *never* be updated.

In general, “apt-get update” followed by an “apt-get upgrade” will get you updated to the latest packages and, hopefully, less vulnerable to attacks and exploits.

This past week at Defcon the social engineering capture the flag competition was hotter and more controversial than ever. Contestants were given their target company two weeks in advance for research purposes. During the actual competition contestants called employees at the target companies to gain sensitive information. The overall result: A big fat fail for the human element.

As more companies begin to take security seriously budgeting for pen tests, equipment, etc. often the human element of security falls through the cracks. As shown at the Defcon competition, all the locks, both physical and network based, can’t stop an attacker if an employee ushers her through the door.

The Social Engineering Competition was put on by Social-Engineer.org which is an excellent place to learn more about social engineering. Don’t let a lack of employee awareness of social engineering attack vectors undermine your security program.