This is a big day for Aircell, which spent tens of millions to acquire the exclusive spectrum license that allows them to shoot Mbps to and from planes. My big question will be whether coverage remains seamless across an entire flight--how often one has to reconnect their VPN would be a big issue. If Aircell has architected the network correctly, passengers should never be reassigned an IP address, and connections shouldn't be dropped even if there's a hiccup in air-to-ground communication.

I've covered in-flight broadband for several years, and I've been wondering lately whether we'd be waiting until 2009 to see real production service. American is calling this a 3-to-6 month pilot to see what their passengers think. Just yesterday, I wrote up veteran travel writer Joe Brancatelli's frustration with the lack of information and some misinformation about in-flight broadband.

You can read more background on American's plans and Aircell's technology in a post I wrote for BoingBoing on 24-June-2008.

Boston ferries gain Wi-Fi: The MTBA has put Internet access on its 11 commuter boats that serve 4,500 daily riders. Ridership is way up this year.

Bangkok builds slow Wi-Fi network, free for first year: The details are a bit sketchy, but the government has built a 15,000-hotspot network that offer 64 Kbps connections, and will be free (with an access card) for the first year. The government is handing out 500,000 such cards at shopping malls before this week's launch.

I can completely see why Microsoft is taking this approach - although I think people who aren’t used to IE7.0 will revolt until they get used to it. But if you think about it from their biggest customer’s perspective - they want their users to stop getting exploited. It’s bad for business, it’s bad for security and it’s bad for public relations. So for all of you who had come to know and love IE6.0, you might as well go download it now and beat the curve. Resistance is futile! Although there are instructions on how to stop the upgrade if you really need swim upstream.

So, one liner summary of status of my 2007 predictions: they were too wimpy. In more detail ...

PI. Platforms: Vista will have no impact on the overall risk level of most organizations out there. Yes, some holes will certainly be plugged (and I even agree that "Vista is the most secure version ever", just like every single one of its predecessors was - in its time), but others - possibly of types we don't even know about - will crop up. Sorry, but secure platform =/= secure Internet (kinda like you wearing a Kevlar vest doesn't lower crime in the neighborhood).

Status Check 1:  This is correct, for sure. In fact, Windows Vista made no impact on security not because it has security flaws (and it does), but because nobody really adopted it. Calls to "upgrade Vista to XP" are heard loud and clear ...

PII. New technologies: no credible technology that can alone "solve" the problem of insider threat will emerge (many will try); the insider threat problem is just too broad, diverse and rich to be solved by a single technology or even a single vendor (corollary: if somebody is trying to sell you such a technology that claims to do exactly that on its own, then - well, you know what to do ...)

Status Check II: This one was kind of a no-brainer and way too safe a prediction. Of course, it didn't emerge! It is impossible to have one technology (or even: only technology) to stop a dedicated insider. However, log management helps since it allows you to know what they actually did and how they stole all your secrets :-( with painful level of details (if you have logging enabled, that is)

PIII. Security market: we will see more than a few firesales and possibly total and miserable security vendor failures (wonna bet which legacy SIEM vendor will die first? :-)) There are way too many companies who sell some random and often irrelevant "protection" which sometimes doesn't even work ... at their own demo ... when their CTO demos it ... the third time ...

Status Check III: This is kinda true (here, here, here), but not to the extent I suspected. Some of the walking dead are still, well, walking. And no less dead :-( In 2008?

PIV. Risk management: a confusion about what is "risk management" will not subside this year. Business risk? Information risk? Risk as threat x vulnerability x asset? Risk as probability of loss? Arrrghh! - It goes on and on and on. No standard accepted definition of risk management in the field of infosec will emerge.

Status Check IV: This is also a wimpy prediction, since it is so obviously true. The concept of risk is still a mystery to many in security (e.g  see this survey) and it will likely remain so for a while. Puleeease! :-)

PV. NAC: of course, no list of 2007 prediction is valid without mentioning knack :-) And you know what? NAC will shrink, NOT grow in importance this year! This is where the rubber meets the road and fish start to swim upstream :-) - this prediction started from me reading Richard's piece "NAC is Fighting the Last War" which struck me like a Strength 15 Lighting Bolt. Indeed, narrowly defined NAC largely targets worm infections (and will thus lose relevance) while broadly defined NAC starts to sound like having a well-run network (which is as relevant today as it was in 1992 and probably 2012 as well). The Planet NAC is about to experience a premature eclipse :-)

Status Check V:  Yes, bingo!!! I am proud of this one, since it was pretty contrarian: NAC didn't become much clear and adoption reportedly slowed down. Small vendors scatter, larger ones repurposed NAC tools.  NAC - in whatever shape or form - will become more common, but only after it sinks into the "trough of disillusionment", pardon my Gartnerese :-)

PVI. 0-days: 2006 was the year when this previously obscure term fell victim to malignant marketeers. 2007 will see more of the same, no doubt. But what about the real 0-day-wielding attackers, poking jokes at the above "oh-day defenders"? Security research into new types of vulnerabilities will certainly continue and more types of previously "safe" (rather, "erroneously thought of as safe") types of content will be used to attack applications. MPG with 0day? AVI with 0day? And, our old friends doc, xls, ppt and now PDF. On the other hand, a major 0-day worm still won't happen.

Status Check VI: Correct, but then again - it was a little on the soft side as well. No 0-days worms. PDF hacking - check. And, in fact, less noise about "we protect against 0-days" (because they likely don't). However, I should have added that technologies that only protect against a few known "baddies" will experience reduction of efficiency ...

PVII. IP and ID theft, data loss: at the risk of sounding hilariously obvious, I would state that such incidents of ID theft (phishing, etc), broader intellectual property (IP) theft and loss will continue largely unabated. Will we, the security community, try to stop it? Of course, but nowhere near hard enough ...

Status Check VII: This has definitely gotten worse, as predicted. TJX? VA? UK events? Many others? And yes, it was hilariously obvious to say this :-)

PVIII. Compliance: but of course! Did you think I'd miss this bad boy? Mandatory regulatory initiatives that pack a bite or a punch, such as PCI, will continue to spread and thus grow in importance, while jokes like HIPAA will continue to languish, helping my # VII prediction come true with a bang ... At the same time, I am undecided on the voluntary frameworks that you can choose to comply with (ISO17799/270001, COBIT, ITIL, etc) - will they take off like a rocketship or remain steadily interesting to some? Only time will tell.

Status Check VIII: PCI DSS continued to rage (despite TJX and other faux pas :-)), even some retailer backlash was seen. On the voluntary side, some say ITIL is emerging, other swear by ISO27xx1 series, but I still don't see the rush to adopt the frameworks en masse, at least not in the US.

PIX. Security awareness: well, security awareness will ... ah, come on, just laugh: bua-ha-ha-ha-haaa :-)

Status Check IX:  No comment! Actually one: malware zipped with a password which requires the user to enter it and unzip it. Stuuuuuuuuupid! And, do remember the "WSJ saga" , which probably blew away years worth of your awareness efforts ...

PX. Finally, I would like to reiterate a few of the last year's predictions that will still ring true this year. Client-side and application-level (especially, web application) vulnerabilities will still be outrunning the server-side and platform-level ones. Major wireless attacks and malware will still not destroy the world.

Status Check X: Yes, client-sides beat server-side vulnerabilities. Yes, app vulns beat platform vulns. Come on, what else is new? :-)

Stand by for my 2008 predictions! All Hail Futurism! :-)

All past predictions from various people and groups for 2007 that I've seen are tagged here. A fun read now!

All future predictions from various people and groups predictions for 2008 that I've seen are tagged here. A fun read a year from now? :-)

• Injection Flaws
• Again, I think the metric posited in the paper is too tilted towards incident discovery rather than prevention. Just like the XSS metric I added - OutputValidation , this is really the key to prevention here. Most static analysis tools can detect tainted input and have a set of untrusted input functions (things that read from sockets, stdin, etc). It should be relatively straightforward to model our own application-specific output functions to detect where we're handing unchecked/unfiltered input to an output routine, potentially those across a trust boundary. If we can model these, we can at least make sure we have good sanitization coverage for each output type. We'll want to have this type of output filtering anyway, we might as well combine metrics from our XSS example.
• Improper Error Handling
• I think the metric posed in the paper - counting unchecked returns is a pretty good idea. This isn't going to catch web-server layer errors unfortunately, and won't necessarily detect errors in things like app servers, db-layers, etc. We can test for these, but the best metrics might be those related to following secure configuration guidance such as the CIS guide for individual web servers and/or app servers. The CIS benchmark for example requires a compliant configuration to handle standard web errors (4xx and 5xx) through rewrites and/or custom handlers. There are cases (SOAP comes to mind) where we need to throw a 5xx error back to a client, but this is the exception rather than the norm. Configuring application and web servers to minimize this sort of data disclosure is certainly a good thing, and in this sense we can check for compliance at this layer as almost a binary config - you pass the CIS guidance or you don't.
  
• Insecure Storage
• I don't think the metric of percent encrypted hard drives is really a meaningful metric in this context. If we look at typical web attacks that fall into this category we'd be looking at exploits that leak things like passwords, CC-data, etc. that is stored in an improper manner on the webserver. Some of this is going to be related to the implementation in the code, and so our best bet is probably a detailed audit of each piece of information that falls into this criticality range to confirm that it is being handled in an appropriate manner. I struggle to find a concrete metric that helps to measure this however. PercentCriticalDataCovered for proper encryption/hashing technique? Still not a very convincing metric unfortunately.
• Application Denial of Service
• Two metrics spring to mind here:
• Memory/Resource Allocations Before Authentication
• Memory Leaks
• Both of these are a lot more likely to lead to application denial of service than any other errors I can think of. Both of these should be minimized. Tracking them and having the absolute fewest of them is probably a good bet. That doesn't mean we're not going to have a DoS issue, but these are at least 2 places to look.
  
• Insecure Configuration Management
• This item probably goes back to the same metrics I posited for Improper Error Handling. Things like the CIS benchmarks for OS, webserver, and appserver are our first pass candidates for measuring this.

• Software is brittle, it fails catastrophically
• Unlike other engineering disciplines, we don't know how to get to certainty about the strength of a piece of software.

1. Design
2. Deployment
3. Runtime
   

• Unvalidated Input
• I actually like the metric from the paper. Measuring input validation schemes against the percent of input they cover is a pretty good metric for this. Don't forget that web applications can have inputs other than html forms, etc. Make sure that any/all user input (cookies, http headers, etc.) are covered.
• Broken Access Control
• Unfortunately this one is a tricky metric to get our hands around. Ideally we'd like to be able to say that our data model has proper object ownership and we could simply validate that we call our model appropriately for each access attempt. This is unlikely to be the case in most web applications.
• I'd really break this metric down into Application-Feature and Data access control. For Application-Feature access control I'd make sure that I have a well-defined authorization framework that maps users and their permissions or roles to application features, and then measure coverage the same way I would for input filtering.
• For Data access control, I unfortunately don't have a good model right now to create a design-time metric, or any metric for that matter.
• Broken Authentication and Session Management
• For a general application I again come back to use of frameworks to handle these common chores. I'd want to make sure that I have a proper authentication and session management scheme/framework that is resistant to all of the threats I think are important. The important metric is coverage of all application entry points against this framework. When implemented at the infrastructure level using a package such as Siteminder or Sun Access Manager, auditing configuration files for protected URLs ought to get me good coverage.
  
• From a testing perspective I can also spider the application and/or review my webserver logs and compare accesses URLs against the authentication definition and make sure everything is covered appropriately.
• Cross-Site-Scripting
• From a design perspective there are two things that matter for XSS vulnerability.
• Input Filtering
• Output Filtering
• The best metrics therefore for measuring XSS vulnerability is a combination of the InputValidation Metric and an equivalent OutputValidation metric.
• Buffer Overflow
• In general buffer overflows are the result of improperly handled user input. Within a web application we ought to be able to handle most of these issues with our InputValidation metrics, but there are going to be cases where downstream we handle the data in an unsafe way. Unfortunately our best techniques for detecting and eradicating them are going to be either dynamic languages where we don't get buffer overflows, or lots of static analysis and strict code reviews of all places we handle static-sized buffers. One partial solution is to simply use an environment that isn't itself to buffer overflows. This makes analyzing the web application for buffer overflows pretty easy.
• For those who insist on writing web applications in languages such as C/C++ our best defense is to avoid the use of static buffers and strictly code-review those places where we do use static buffers to analyze inputs for proper bounds checking. One useful measure would be PercentBoundsCheckedInput which we can theoretically catch with a static analyzer. They are pretty decent currently at finding these.
• One problem with the metric from the paper was a focus not on the web application itself but on its platform. I'm not sure that we're working at the right level when we start considering OS vulnerabilities when reviewing web applications. They are certainly however part of the picture and a meaningful vulnerability.