I'll say up front, I love GISkismet for interpreting kismet .netxml output for sending to Google Earth. However, I find that sending the .nextml output to Sqlite3 also gives me plenty of options for reporting on issues as well!
In many cases when I do assessments, I won't have GPS location available; I'm walking around inside of the assessment environment without a clear view of the sky. In this case, this gives me the ability to see the environment just like the clients see it, often times revealing some risk that is oft forgotten about.
Based on the information that I won't always have information about GPS based location I need to import ALL of the collected AP information into the Sqlite3 database. We can accomplish this with the --ignore-gps option which will add all of the APs even though no location information was found in the .netxml
$ ./giskismet -x somefile.netxml --ignore-gps --database nogps.dbl
In this case, I've chosen to output the contents to the Sqlite3 database named nogps.dbl.
Great! Now, I understand that I can use GISkismet to run SQL queries against the database, but why not enhance my skill set and learn how to use Sqlite3 to do those same queries? Once Sqlite3 is installed (with say "sudo apt-get install sqlite3") let's get it to start an interactive shell with our new database:
$ sqlite3 nogps.dbl
Let's also be sure there's stuff in there. Show us all of the wireless networks my good man!
sqlite> select ESSID from wireless;
How 'bout we show the encryption type with that too?
sqlite> select ESSID, Encryption from wireless ORDER BY ESSID;
That was easy, wasn't it? Yeah, now here's where the "hard work" comes in...
One of the things that I like to point out during an assessment from within the environment is open access points that are likely not associated with the customer. Why? If the customer allows end users to configure new wireless network connections on their devices, this can be an issue. Let's say the customer does the best they can securing their wireless networks, and when client machines are connected to gain access to internal resources, they are also prevented by policy from gaining access to some websites, say Facebook, Twitter, etc. What happens when the users MUST get on Facebook? Thy go join the open network next door, get on Facebook, get compromised, and then come back to the corporate network because they can't access their e-mail...now the customer has "pre-pwned" machines on their network...
Let's get a list of the open APs, shall we?
sqlite> select ESSID from wireless where Encryption = 'None';
...or to eliminate duplicates:
sqlite> select DISTINCT(ESSID) from wireless where Encryption = 'None';
The other use case that I like to point out is when cloaked or hidden wireless networks are discovered. Again, you ask, why? The hiding of networks can be argued to introduce more risks in some scenarios, ultimately when a wireless device travels outside of the environment into a public one, where tools such as Karma, Karmetasploit or the WiFi Pineapple some into play.
Let's get us a list of cloaked networks:
sqlite> select DISTINCT(ESSID) from wireless where Cloaked = 'true';
Now based on these two scenarios, we can us the info from GISkismet for more than just mapping.