A long time ago, when distributed computing was in its infancy, and the promise of new technology made early adopters of us all, a fellow named Peter Deutsche found himself pulling out his hair. There was, he reasoned, an unimaginable amount of positivity about this new “distributed” technology. Accordingly, Deutsche decided to record the “Fallacies of distributed computing” for posterity. Almost twenty years later, I think there’s still a lot of learning to be done.

At Cigital, I lead the mobile and wireless practice, and I often find myself in the same position as Mr. Deutsche. As I’ve watched the mobile industry grow over the years, I’ve seen a huge amount of optimism placed on the hardware and software that we’ve all come to find indispensable in our modern lives — the cell phone.

While I still remain optimistic, I’ve decided to pen my own “Fallacies of Mobile & Wireless” list, to spark some discussion and to get the industry rolling on some positive (and sometimes painful) changes.

The list goes something like this:

1. The (network|handset) is reliable
2. The (network|handset) is secure
3. Bandwidth is infinite
4. Users will accept buggy software
5. Handsets are homogeneous
6. CPU is unlimited
7. Users understand the risks to their privacy and data
8. Everyone has the latest hardware

Before you judge me curmudgeonly, let me say this: I have nothing but the greatest optimism for mobile and wireless technology; the benefits I’ve seen far outweigh the costs. However, I feel that it’s time to really set the record straight on some of the awful compromises that have been made. This is the beginning of an 8-part blog where we’ll explore each one of these fallacies, and tease out some of the group think that’s led us to the situation we’re in today, as well as some of the concrete actions we can take to improve the lot of mobile and wireless from the security, privacy, and, dare I say, reliability perspectives.

Let’s dissect the first idea briefly.

“The network or device is reliable”

The idea that we can make phone calls, browse the web, read our email, or watch YouTube has become a cornerstone of our mobile lives. Most of the time, things work pretty well. The nasty thing is, we predicate all of these things on a mish-mash of software and hardware over which we have little control. Application developers all over the world have been counting on the fact that network connections can be made, SMS messages will arrive safely, and that, in general, there will be few or no errors to deal with in the field. While this approach works well for media consumption (a la YouTube), we’re moving into dangerous territory as we begin to have ubiquitous banking, social networking, and other privacy-laden applications show up.

My hat is off to the wireless providers the world over, as they have generally been doing a great job of connecting us to each other for more than a decade. The biggest trick is that our general use of mobile devices has been undergoing a gradual but ever-accelerating change. We’ve gone from simple voice calls to short messages, and from short messages to multimedia messages, and from there… Well, we’re very close to having a highly-converged IP-based backbone with mixed traffic and an even larger universe of devices which can access it.

Does this worry anyone else? I don’t normally find myself sleepless over technology-related issues, but I do wonder how well both wireless carriers and mobile phones will cope with this eventual evolution. From network issues in large urban environments (Apple iPhone in Manhattan, anyone?) to guaranteed connectivity in rural areas , we have a lot of work to do to catch up to the needs of subscribers and the businesses who publish mobile applications.

The idea that mobile and wireless applications can simply abdicate their responsibility for error handling is quickly coming to an end. I hope that we’re ready for the tidal shift that will require us to learn our lessons all over again.

My Saturday US Mail delivery (so sad if it goes the way of the dodo bird) arrived with several notifications of class action lawsuits for companies in which I’ve held equity positions. As I walked back from the mailbox, I had the thought:

HIPAA and PCI protect the consumer, but who/what is protecting the business that must comply?

I was thinking about all of the audit controls that get put in place to comply with these regulations. The controls are generating data that is going to be used to in one of these lawsuits someday. How is this going to look to a judge?

I suspect that there are fair number of judges that can figure out that any digital asset can be tampered with. Today, they can look at the people in an organization that have access to the data to determine the validity of the data. That may pass muster with today’s judges, but what happens when judges (in their youth) have doctored photos in Photoshop? Will such judges be willing accept that people working for a company didn’t tamper with the digital asset? Somehow, I don’t think Log4J is going to cut it.

And what happens when we factor in all of this cloud computing stuff? Where’s the chain of custody then?

At some point, the audit logs from IT are going to be presented as evidence and some judge is point out that there is reason to doubt their authenticity. At that point, I suspect that corporate attorneys are going to want to focus on meeting the letter of the regulation and also ensure that all of the work done to comply is admissible in a court of law.

Regulatory compliance, such as HIPAA and PCI, are strong business drivers for improving software security for many of our clients. The focus for most groups is to meet some audit deadline. Getting passed the auditors to ensure compliance is the first hurdle, providing audit logs that can pass legal muster can’t be far off.

I had the opportunity to address a group of electrical cooperatives at a recent conference in sunny Atlanta, which was actually snowy. I always welcome the challenge of bringing technical security concepts to a new audience and this was an excellent crowd. The ensuing Q&A showed the broad range of concerns from these small electrical cooperatives that are beginning to deal with a tidal wave of new statutory, regulatory, security, privacy, and technology requirements, along with things yet unimagined. Although the vast majority of these organizations are very small, I was very impressed by their willingness to understand and work toward meeting the new requirements.

I did have a case of the “ummmmmm”s while speaking.

Here is video of my opening segment and the first question of the Q&A. To see the full session, you can view it from the NRECA conference Keynote Speakers page.

I recently had the pleasure of giving a keynote at the NRECA annual conference in Atlanta. The conference brings together senior management and Board members from rural electric cooperatives throughout the country. Some coops are large in terms of the number of subscribers, and some are large in terms of geographic area covered (those numbers often run opposite to each other). My job as keynoter was to introduce some thinking about computer security to business people who operate power grids for a living. This is a big challenge for a geek like me.

Of course I ended up touching on software security, especially the fact that power meters for the “smart grid” are little IP-enabled computers hung on the outside of your house. Given known attacks against this new breed of meters, the question is how many rooted smart grid meters in a botnet could cause a really serious problem?

Here is my talk in its entirety. Your feedback is welcome.

Download audio [mp3]
Download presentation [pdf]

I’m pleased that Cigital is directly involved in working to make smart grid security a reality. We’re working directly with NRECA to bring electric cooperatives up to speed with cyber risk management.

I don’t often make the time to write up some of the more interesting aspects of work we do for clients, but I was forced to make some time to do so last week (well perhaps encouraged is a more polite way to put it) . The effort culminated in a webcast with MSDN and covers some work we did integrating Microsoft SDL, Architectural Risk Analysis (ARA) and Service Architecture and Engineering (SAE). The SAE methodology is a SOA methodology from Everware-CBDI. The work of integrating these three techniques is an extension of our SDL case study.

You can reply the webcast and get copies of the slides here.

The jist of the presentation is that SOA Security often gets equated to WS-Security (or perhaps devolves into WS-Security). The problem with WS-Security is that it’s often applied at the wrong level, so there needs to be a better architectural approach to addressing security within an SOA. By combining SDL, ARA and SAE, we’ve found that it’s possible to look at a layered approach to security based on trust zones and SOA governance tooling.

I’ve been continuing to work on documenting the details of the SDL, ARA and SAE integration with John Butler from Everware-CBDI. We’ll be doing something more formal when we have something that can be published.

BSIMM2 is the 30 firm version of BSIMM. I wrote up an article with Brian Chess and Sammy Migues (my BSIMM co-creators) called “Software [In]security: What Works in Software Security — Fifteen Common Activities from BSIMM2.” In addition to highlighting the fifteen most common BSIMM activities, the article also provides the 30 firm data for all 110 activities in public for the first time.

We’re unveiling some statistical results at RSA this week that will enhance and expand the dataset published in the article. We’ll do an official BSIMM2 launch within the next couple of months.

I read a question on one of the cloud mailing lists asking which of the federated authentication protocols (SAML, OpenID, Oauth, WRAP, etc) would win. My initial reaction was to reply, “Isn’t the question which ones won’t lose?” Okay, that’s snarky and perhaps a double negative, but I find it a rather dubious notion to think that there will be one winner. Aren’t authentication protocols like camera lens mounts? There are several types and all that’s important is that you can share lenses with the people you hang with? Why does there have to be a winner?

If you’re consuming a SaaS, it would seem like the service will support N protocols and you can either support one of those N. It seems like the big SaaS vendors will have some set of standards in place and it will take a couple of big customers to get them to expand that set. What’s it going to take for Force.com to implement something other than SAML?

For PaaS and SaaS, your organization is in control of the application, so you can handle authentication by whatever scheme you choose. If you’re working with some business partners, then you implement whatever protocol you both can agree to.

The protocols/mechanisms so far is only for user authentication. What would be helpful is if there were some way to enable authentication to include the cloud service itself. Cloud services all require some form of account information to do anything. If it’s a service like Amazon, there are also the private keys that have to be maintained, managed and passed to just gain access to the infrastructure. What all of the different delivery models have in common is the problem of authenticating to the cloud service. Is this a problem for identity management or just a (not so) simple credential management problem?

So, the question is not which one protocol wins, but which ones lose since you can only hurt yourself by implementing something that dies off. Then you can turn your attention to the problem of securing the authentication to the cloud service itself.

Apparently the time has come to re-release the SANS/CWE 25 — something that we can expect annually. The good news is that exercises like this do plenty to hype up software security and its importance. In fact, in many ways the target of these lists is “the reporters who cover software security.” So hype = good.

So why am I not a big fan of these lists? Well, I wrote that down a year ago and what I said then still applies. Sure would be nice to see a reasoned response to my criticisms instead of repetition of the same tired ideas. If you haven’t had a chance yet, go read my January 2009 informIT column “Top 11 Reasons Why Top 10 (or Top 25) Lists Don’t Work.”

There are some important improvements in this year’s top25 list that have been discussed on sc-l. But there is also a problem that really bothers me. The SANS guys are trying to tie the top25 list to software liability (?!) and apparently think they can hold developers accountable for their bugs..well, 25 of them at least. I think this is a wrongheaded approach to software security. I would much rather talk about the real progress the field has made than to hype up yet another list and make the list a critical aspect of software contracts?! Can you imagine what such a move (if it succeeded) would do to the price of software and to the hourly rates of developers? Developers would be compensated like lawyers!

Top-n lists do have their place. In the BSIMM we note 10 firms (of 30) who follow activity [CR1.1]. Here is the activity cut from the BSIMM:

Create a top N bugs list (real data preferred). The SSG maintains a list of the most important kinds of bugs that need to be eliminated from the organization’s code. The list helps focus the organization’s attention on the bugs that matter most. A generic list could be culled from public sources, but a list is much more valuable if it is specific to the organization and built from real data gathered from code review, testing, and actual incidents. The SSG can periodically update the list and publish a “most wanted” report. (For another way to use the list, see [T2.2] Create/ use material specific to company history.)

In my view, a tailored top-n bugs list is way more useful than a generic “world list” like the SANS/CWE25. To think about why this is, consider the differences between code bases from Intel, Microsoft, Symantec, and Nokia (not to mention Wells Fargo)…all BSIMM participants. Whose bugs do you want to eradicate? Yours? Or your neighbors?

Press coverage of the “controversy”:

• SANS Institute, MITRE release new top 25 dangerous coding errors list, TechTarget.
• Top 25 Programming Errors: Should Software Developers be Liable?, Bank Info Security.
• Hold vendors liable for buggy software, group says, ComputerWorld.
• 25 ways to better secure software from cyber attacks, Scientific American Observations.
• Security agencies release Top 25 programming errors, Washington Technology.
• Proposal Would Hold Software Developers Accountable For Security Bugs, Dark Reading.
• Group Proposes Suits Over Faulty Code, Gov Info Security.

I had been reading about Gartner’s prediction that 1 out of every 5 businesses were going to dump all of their physical IT infrastructure when Sammy Migues sent me a thread from LinkedIn about it. The thread contained many of the common sense views about Cloud Computing that you’d expect: IT should be based on strategic value and should outsource the commodity pieces. That day, I was also reading about the Forrester survey that states that 43% of their respondants said that they had no interest in cloud storage and another 43% (perhaps the same 43%) had no plans adopt it.

Some of the difference in these two reports has to do with hype versus reality. I recall in “the naughts” that SOA was touted as a way for IT to bring business agility. Then all of the vendors got on the SOA band-wagon. Now it seems like Cloud has taken up where SOA left off in terms of hype. On the reality side, I wish I could tell whether the lag is because of people’s increased awareness of security (the optimist) or whether it’s a reflection of the sorry state of storage implementations (the pessimist).

The BSIMM study data set has more than tripled in size and now includes data from 30 firms. We are busy working with Betsy Nichols to crunch the numbers now that we have a statistically significant data set. The plan is to announce our results at RSA.

One question that comes up in the BSIMM work fairly consistency is the difference between BSIMM and other maturity models for software security. To answer that question, I wrote an article for informIT entitled “Cargo Cult Computer Security: Why we need more description and less prescription.”

Download audio [mp3]

David Rice, the author of Geekonomics (as well as the 46th Silver Bullet Security podcast victim), and I discuss the BSIMM in a webcast about the upcoming SANS software security event in San Francisco.

The time for science is upon us. And the first step in any scientific approach is measurement.