That's ASCII, not hex: An article on wardriving raises security hackles by repeating some slightly overheated statements about Wi-Fi security. The article opens with a 63-character ASCII WPA passphrase, which is later described as "hex." (ASCII passphrases in WPA can be up to 63 "printable" characters - ASCII 32 to 127 - while a hex version of a 256-bit TKIP or AES password is 64 hexadecimal digits long.) The article tries to conflate Wi-Fi attacks that led to the largest set of breaches in retail credit-card systems and wardriving, a hobbyist activity that's never been looked on very favorably by law enforcement. The sense of ennui of wardriving pioneers is pretty clear; when Wi-Fi is everywhere and generally secured, it's far less interesting. The wardriver in the article convinced the reporter that a maximum-length WPA passphrase stored on a USB drive for automatic use was the best way to go. But, really, 20 characters containing letters and punctuation and no words found in a dictionary along with changing your network's SSID (network name) provides all the security you'll ever need for a home or small business. (If you need more, deploy WPA/WPA2 Personal.)

Green Wi-Fi's Senegal efforts hit snags: The folks at Green Wi-Fi are well motivated, and they're running up against all forms of security theater and bureaucracy both here and in Senegal, where they have an active project. The San Francisco Chronicle notes the group's effort to build solar-powered, self-sustaining Internet access via mesh networked nodes. Getting devices out of the country, clearing customs in Senegal, and hooking up their solar system all hit problems they're working through. As with the One Laptop Per Child program, I see a "build it and they will come" mentality in Green Wi-Fi's mission statement: the notion that providing computing power and Internet access will result in good things, rather than an effort to figure out what good things need to be achieved, and whether computers and the Internet will assist.

• Which problems will be solved and forgotten?
• Which ones will simply go away?
• Which ones will persist and in fact increase?
• Finally, which new ones might emerge?

First, let me bet my ass that "Not knowing what to log" problem will be licked in 18-24 months; at least as far as major regulations go, people will have a pretty good idea a) what  the auditors want them to log (and review!) b) what they need to log for solving their problems. Now, for esoteric log sources (and custom applications) might still present a challenge from that point of view, but for basic "staples" (firewall, network gear, major OS) the mystery will be over (again, see "Tell me EXACTLY what to log for PCI?"  for reference)

Next, the problem of "Log volume" will  definitely get worse, much worse.  One might think that 100,000 each second is a lot of log - but there WILL BE more at many companies! Big application log explosion is coming, fueled by the need to address logging in areas where such motivation was lacking before (basically, custom and vertical applications) as well as harness the power of "uncommon" logs for such tasks as fraud analysis or SOA monitoring. Keep in mind that even though in some areas logging is NOT a preferred way of monitoring and auditing activities (see this discussion on database logs here), application logging will still explode on us...

The problem of "Log diversity" (the fact that most logs all look different in format and meaning) will get worse before it will get better - and better it WILL (!!!) get since standards are being developed. We will see people struggling with all sorts bizarro log data in the coming years. Virtualization, web services and SOA, various ERP applications and even cloud services will increase the diversity of logging in the coming years.

Similar to the above, a problem of "Bad logs" (ones that are subjective, miss key information, require groping for a crystal ball to understand, turn log analysis into dark voodooistic experience or are useless in some other way) will also follow the pattern of the above log diversity problems - it will get worse before it gets better (via the CEE standard effort that now covers the OpenXDAS effort as well!) I noticed that people started asked me questions about "how to do application logging right?" and "what to tell application developers about logging?" which almost never happened in the past. BTW, watch my blog for some uber-fun info on that!

"Getting the logs"  has gotten much easier in recent years; agentless collectors like Project Lasso (which, BTW, just got updated) and grabbing  files remotely via secure protocols made application log collection easier (syslog-NG with TCP transfer and buffering also helped). Next, Windows 2008 will make it MUCH easier for the whole Windows kingdom due to their use of web services (thanks Eric!). However, in the future it might resurface as we try to collect logs from "weird" places, again, clouds come to mind as well as virtual environments (e.g. how do you get logs off a dormant VM?). What's the next frontier in this area? Log discovery - automatic finding and identifying log files on systems in order to analyze and retain them (Yo, my t-shirt-making colleagues... :-))

All this, however, pales in comparison with my favorite "uber-challenge", "Making sense of logs in  an automated fashion" - this baby is definitely not going away in 2-3 years. Much more research is needed to make that "log->conclusion" jump automatically without head-scratching, invoking ancient deities and cursing under ones's breath. Only then we can attempt to reliable handle "proactive logging" (i.e. analyzing various failure or compromise precursors in logs and then predicting the future based on them), another Holy Grail of logging domain.

Anything new will emerge? Yes, I think awareness of the "Logging Gap" problem will grow. "Logging gap" happens when you combine "a need to log" with utter "inability to do so."  For example, this will happen when people will know that they HAVE TO log, say, for compliance, but will have no way of doing it due to application or platform limitations. This will become one of the challenges and special "logging add-ons" will appear to close the logging gap and create additional logs where activity audit is desperately needed, but native logging is not helping to achieve it.

Also, I think people will finally wake up to "Log security" challenges - i.e. producing for use as evidence, compliance attestations, etc. Log security is not getting the attention it deserves, but I think this challenge will finally emerge in full force in the next 2-3 years. My next poll will address that :-)

Anything else I missed? Share away!

Related posts:

• Ideal Tool to Solve Real Problems ... of the Near Future?

• Ideal Log Management Tool?

Automated passenger profiling is rubbish, the Home Office has conceded in an amusing -- and we presume inadvertent -- blurt. "Attempts at automated profiling have been used in trial operations [at UK ports of entry] and has proved [sic] that the systems and technology available are of limited use," says home secretary Jacqui Smith in her response to Lord Carlile's latest terror legislation review.

The Justice Department is considering letting the FBI investigate Americans without any evidence of wrongdoing, relying instead on a terrorist profile that could single out Muslims, Arabs or other racial or ethnic groups.