The views expressed in this entry, as in all entries on my website, represent my personal views alone. They do not necessarily represent the views, policies or standards of my current or any previous employers. No content on my website is promoted or endorsed by my employers. I am a free man, and my thoughts are my own. In a few weeks both Def Con and Blackhat will be going on, and there’s going to be a lot of media scrutiny for them due to the recent NSA leaks, Snowden and the Aaron Swartz incident. All of that along with the usual announcements of new security tools, exploits, and other goodies. Not to mention the increasing frequency of people at IT conferences sexually harassing and assaulting other people.[…]
Hi there. Yes, I know, it’s been 2 years since I last posted something on my website. Mea Culpa, I installed Joomla, I’m not much for website design, been busy, that sort of thing.
So how’s the spouse and kids? Really?! Well congrats, I’m glad to hear that. Except for the part about the restraining order, that’s a shame.
But hey the real reason why I’m here is to talk about an idea that popped into my head while I was zoning out along I-85 when heading back from a conference earlier this week. Being a responsible adult and all I tried to keep it down to only the “prayer for judgment” speeds and not “Judge Dredd” speeds. This is easy enough with cruise-control until you suddenly realize there’s a car ahead of you or behind you and you’re not sure if it’s a cop or not. And you don’t have radar detectors because you’re a law abiding citizen, damn it!
It occurred to me that we have all the technology to build an open source surveillance system for tracking and identifying police cars on the road. Now doing something like this of course requires making sure everything is done legally, and that has to account for differing laws between states and counties. But let’s push that down further into the article and jump into a technical outline of how to do this.
(And yes, this is a way to turn universal surveillance by law enforcement back on them).
To start with the idea of a Collaborative Cop Identifier System (CCIS) requires servers and software to be able to pull in data from many contributors, process it and produce useful output. The CCIS would likely use a typical virtual hosting platform with servers for databases, webservers to handle automated and human requests, and app servers to run data processing tasks that are computationally intensive. Let’s assume relatively unlimited financial resources for this project, so everything can be hosted in a nice redundant datacenter (*cough*), we have paid coders to do dev work and sysadmins to keep everything running and monitor for outages.
CCIS would primarily be used by people driving cars, so it’d have to be optimized for use over WiFi/Cell networks. We’d need support for speech input and output, and a robust API so a lot of client platforms can be supported (cellphones, tablets, etc).
The core model would be individual users equipping their cars with a set of sensors, running a CCIS client application on an appropriate mobile device, pairing all this to an account on the CCIS backend systems and then just driving like they would normally. Data would be gathered by the client system and sent to CCIS servers for processing, and real-time feedback would be fed back in the form of voice commands, audio signals and/or visual cues.
The biggest failure in information security is actually a failure in information technology implementation.
For many, many decades the operating systems and applications that have been made for computers have come with built-in security features. The very idea of a username and password to log into a computer pre-dates home computers by at least a decade, with Multics back in 1964. And it wasn’t the first.
But what has happened over this time is the old “arms race” where the so-called bad guy finds a way around the restrictions put in place, so newer and more elaborate restrictions are put-up. More elaborate and complex security systems require more time to set-up, more knowledge to implement and a generally higher degree of intelligence.
In the business world, there is little tolerance or interest in the needs of Information Technology, but an excruitiatingly large demand. Most IT departments run on very tight budgets with minimal personel, the majority of funding going to hardware and obscenely expensive software licensing. If you don’t offer very high pay and very good benefits, you can’t really attract the very best IT employees.
WebApp Scanning Throwdown!
Starring: Nexpose Enterprise, Nessus 4.2 Professional Feed and Core Impact v10
The Victim: http://demo.testfire.net/ (Sorry IBM… not!)
I have to apologize for errors in my original article. I missed a few findings in some of the reports, and mis-read a few items. Just to make this absolutely clear, errors in analysis of the results are my own fault, not a reflection of the products. And as stated, the configurations used were not ideal.
Please visit the downloads section for a spreadsheet providing the vulnerabilities in a matrix format and which tools identified them. Ultimately, there’s not a lot of difference though Nexpose did manage to get a couple that Nessus missed. All three tools missed quite a few more subtle vulnerabilities in the test site, however.
I feel the most important conclusions that can be drawn from this comparison are:
- You can’t rely on one tool to find all your issues
- You need to make sure your tools are properly configured for maximum results
- No tool will find everything, but it will be a good indicator you may need to take something apart to look at it more closely