In a recent article iPhone shell code hits the web HD Moore, creator of the Metasploit Framework describes how combining members of a set of implementation bugs in applications on Apple’s iPhone with a design flaw results in a ripe opportunity for landing shell code or otherwise controlling the phone’s various hardware goodies (camera, mic, speaker, etc.) remotely.

As you read the above article, note the classic vulnerability-types mentioned. The iPhone suffers from a design flaw: all apps running as root. Moore also mentions some of the simplest kinds of buffer problems (such as the stack-based buffer overflow).

These bugs, this flaw represent a low-level of organizational maturity in security. It almost seems a throw-back to any 90’s era code assessment I’d done. We’ve understood the stack-based buffer overflow well for years-upon-years and even rudimentary static analysis tools catch it. Threat modeling or simple architectural analysis should have dissuaded architects from moving forward design intact, bearing so fundamentally “risk amplifying” a flaw as “run as root”.

Make no mistake: Apple represents a company leveraging security by obscurity. I cringed when Apple used its then largely untarnished record as a marketing ploy, (from what I understand) without listening to what’s been said about the actual resistance of his products to attack.

While aspects of their desktop OS were truly “designed with security in mind??? and represent solidly secure OS technology, it’s clear to me that Apple does not address software security programmatically to what I consider an acceptable level.

When Apple created an asset of reasonable enough value and appeal, threats easily broke a shoddy system by retraining their attention on the protective mechanisms shielding that asset.

While a lot of our customers have adopted software security early, and have committed to addressing it in all phases of their software’s lifecycle, in all appropriate organizations touching software, others have not. If, reading this, you look at the well-covered transition from Microsoft to Apple as the vulnerability target and think by analog, “this stuff is happening to my competitor, but can’t happen to me”, or perhaps feel invulnerable because, “No one would figure these vulns. out.” or, “We’re not on people’s radar.” BEWARE. One ostrich is having to pull its head out of the sand and peck at crow… and this is sad because, with the exception of my Crackberry, I largely believe in and purchase from Apple.

A final thought: Regardless of the actual security in OS X, what chance does Apple have of touting Leopard’s security over Vista in the market place after these events?

As I get back into the risk management arena after a sojourn in knowledge management (mainly designing knowledge-driven offerings and monetizing the associated intellectual property), I find yet another example of “the more things change, the more they stay the same.” I think the executive view of information security risk management techniques as viable decision support tools has come a long way, but the complaint I hear from most executives is that even the simplest risk modeling appears to take a very long time.

I find that information security risk management still has the unfortunate combination of being a lightning rod for snake oil in the marketplace, being a real polarizing and dogmatic topic that often defies reasoned discourse, and being something that the average person handles by gut and not by numbers. Practitioners, academics, and managers alike bemoan the scarcity of actuarial data on which to base decisions. And, just to round out the issues list, any given group of people will quickly fall into its own set of terms and meanings, making it very difficult for any two groups to have short, interesting arguments that actually advance the knowledge base.

In my recent reviews of what’s going on in the world, risk modeling exercises related to application security seem to stretch on for two primary reasons:

1. An obsession with knowing every “threat”
2. Not having a good rule for deciding when a threat-vulnerability-control coupling deserves no more scrutiny

What I’ve evolved over the past couple of decades to reduce this work is something I’ve called “Looking for zeros” and “Looking for ones.”

In my experience, knowing the exact threat (i.e., combination of attacker, attack, attack path, resources, and some intangible things such as motive) is often irrelevant. I call this “Looking for ones.” For example, if a particular attack always works (e.g., cross-site scripting in a particular web form), then it likely matters not whether the attacker is a national government, a terrorist, a criminal, a script kiddie, or someone who accidentally pastes HTML into the field — the “success value” for this attack-vulnerability tuple will always be ‘1′. Knowledge of the attacker might give us a bit more information about what he or she might be ultimately trying to accomplish, but the decision to fix the problem should already have been made.

Similarly, this is why we decompose threat, vulnerability, assets, and other things into constituent components. I call this part “Looking for zeros” and it works really well. As soon we find a ‘0′ for a material aspect of attacker, attack, attack path, resources, motivation, threat frequency, feasibility, accessibility, susceptibility, vulnerability prevalence, asset value, event cost, downside, caring, and so on for the various dimensions of “bad stuff happens,” then that scenario is over and we can move on. Again, even given a national government with lots of resources and a zero-day electronic attack that really works, we just don’t care if the attack works only on WebServerA and we’ve deployed WebServerB, or if the attack path required (e.g., site must be using JSessionID), or whatever else, simply doesn’t apply to us.

When we bring into the mix controls (for which we reason about preventive, detective, corrective, and deterrent values), then we try to kill off entire attacks (e.g., timeouts that prevents script kiddies doing half-open TCP stuff), attack paths (e.g., Internet routers that allow incoming packets with RFC 1918 addresses), motivations (e.g., dye packs that render stolen cash unspendable), and so on all at once; seldom should the IT or software development world try to work off “threats,” and specifically threat agents (attackers), one at a time. That just takes too long.

A comprehensive and holistic view of what makes “risk” happen will always make risk management much more efficient and make the results of risk management much more usable in day-to-day decision support.

Technorati Tags: risk management, threat modeling

In the past few weeks I have started work on a major software development effort. It is a very complex bit of software for capturing images from high-performance cameras and reducing them mathematically to functions used in high-end digital rendering. The process is very complicated mathematically and computationally intense, in some cases requiring as much as eight hours of processing.

One of the first questions I wrestled with was which language to use for the development. I was surprised at the answer.

I started my career in IT more than 30 years ago developing mathematical code for scientific applications, and as I sat down to make the decision I felt like I was in a time warp. When I was growing up, savings accounts were common. You made small deposits which were recorded in ink in a small paper book about the size of passport. Over time the pass book took on a comfortable worn look that was a source of pride, reminding you of your thrift, as my worn passport reminds me fondly of my travels. Once a quarter the bank totaled your balance and added a bit of interest. The rates were terrible, — 2 or 3 percent at best, but were made worse because of the infrequent compounding. One reason banks didn’t compound interest often was that the market didn’t demand it, but another reason was that it wasn’t easy to do. The rudimentary computing equipment and software of the time meant the interest was literally added to an account with an “interest??? program that took hours to run for all of the bank’s many accounts.

The biggest bank in town was innovative and moved quickly to automate with Burroughs banking equipment, and with their added computing power began to offer some impressive new services. The early investment in high-end computers paid off, and the bank eventually grew into a major service provider to other banks, and provided me with my first professional IT job. The immediate application of the technology, though, was to provide current (daily) account information to multiple branches in the form of huge, green-bar reports, to print deposits in the bank books rather than writing by hand (wow, did that look high-tech) and, my favorite part, to compound interest every month.

They advertised this widely, with a cheesy jingle typical of the era. My father was good friends with the executives of the competing bank (which was literally across the street) and they took the escalation seriously. They responded by buying the latest and greatest from IBM (a 1620) and after a few intense months, proudly announced weekly compounding. The war escalated, and Burroughs crowd announced daily compounding. The IBM camp then launched the nuclear option – continuous compounding. The executives from the Burroughs bank stepped up and said “Oh, yeah, we can do that too???.

Oops – there’s a problem. Continuous compounding is done in a completely different way from periodic compounding. In the old days you ran an interest program – once a quarter, month, or whatever. As the interest rate war progressed the banks just bought newer, bigger, faster computers so that they could run the program more quickly. With continuous compounding, however, you only calculated the interest when there was an event – a deposit, withdrawal or statement, and then you had to do exponentiation. Unfortunately, the Burroughs COBOL of the day did not have a built-in function for exponentiation.

That omission got me my first professional gig. The bank came to the local college and asked for someone who could write code to implement this one function. I got the task and dispatched it in short order. I wrote it in Burroughs Algorithmic Language (which hasn’t been seen in the wild since 1977 and is presumed extinct).

So how have things changed? My recent experience suggests that things might not have changed as much as I thought. First, in recruiting for coders, I found that there were a huge number of people who were skilled at building web and data applications, but the folks who know how to make machines do math fast are rare birds, indeed, just as it was 35 years ago.

This didn’t surprise me too much, as the market for business applications is vastly larger than the market for scientific applications. What did surprise me, was the way the old languages are still competitive. The test I devised was to write an equation solver (using the Newton Raphson method) in several languages and trying several different compilers. I constructed a problem where the root was exactly pi, so I could check the answer against published values to very high precision.

I tested Fortran, C, C#, and J# . The results were completely clear – the object oriented languages were crushed. The simple old procedural languages really are faster for the mathematical heavy lifting. It was close between the two C compliers I tried and the three Fortran’s, but the Intel Fortran compiler seems to be king of the hill. It was fast, and the results were spot on to 32 decimal places.

It may not be sexy or look very modern, but if you have to do serious math on 16 mega pixel images, plain old Fortran is still the way to go. Certainly the vast bulk of the new company’s code is going to be written in something more current – their web site, e-commerce site, and internal system, for example, but the hard core, the nut that will make or break the company is going to be in Fortran. Now I’m back where my bank employers were in 1970 – looking for some math stud at the local college.

Technorati Tags: software security, banking, Fortran