Archive for February, 2009

Putting Together a Wireless Security Toolkit for the Android OS

Wednesday, February 25th, 2009

I’ve had the first commercially available Android mobile phone, the T-Mobile G1, since the platform launched last fall, and have been really happy with it so far.  As the platform is getting more mature, we are now starting to see a lot of new and useful applications out there – especially some useful for security!  Here’s a quick rundown of some of the tools that I’ve found and am using:

WifiScan – a great wireless discovery application for the platform.  It’s a powerful wireless audit tool that will log all of the discovered networks in range, and plot them to a KML file for visualization in Google Earth.  This application records information such as BSSID, Channel, Security Type, SSID, etc.  Tremendously useful for a discrete wireless network audit!

PortScandroid – a very basic port scanning application for the platform.  It’s not terribly useful for use over the cellular data network due to the filtering applied by T-Mobile, but when using 802.11, it gets the job done.  Doesn’t do any correlation of services to ports, but it performs the basic functions.

ConnectBot – this is a full-functioned SSH client for the platform.  Handy.

androidVNC – a VNC viewer for the Android platform that’s been forked from the tightVNC viewer development project.  Also a handy tool.  This is still in the beta phases and hasn’t been added to the Market yet, but it’s downloadable from the project page.  Easiest way to install it is to navigate to the project page within the phone’s browser and just download the APK package.

I am going to conduct a WarDriving contest between my little Android and a full-fledged laptop running Kismet and an external Wifi antenna to see how the signal discovery compares, but initial tests show the G1 to have a pretty remarkable Wifi range.  I’ll post a followup after I conduct the test.

The Android platform is showing a lot of promise, and for use on a pen-test, these tools could prove to be useful additions to your arsenal – and are certainly more discrete than using a laptop with a big ol’ antenna!

Thanks syn for inspiring me to investigate this – his post about the iPhone wireless toolkit made me wish we had these tools on the Android, and lo-and-behold – we do!

HIPAA – Technical Safeguards

Tuesday, February 17th, 2009

A large part of my job requires me to dig into security standards to help figure out how to create consulting services to assist customers with achieving compliance. One standard I’ve never looked into before is HIPAA (Health Insurance Portability and Accountability Act of 1996). HIPAA is not a security standard per-se, but rather a set of administrative rules established by the US Department of Health and Human Services to govern how health information is accurately and securely exchanged between medical institutions and other institutions that have a legal need to access patient medical data.

HIPAA is encoded in the US Code of Federal Regulations, Title 45, Parts 160, 162 and 164 (see here for the CFR). Section 164 is the most interesting section for a security professional, as this section describes the security and privacy requirements that must be satisfied by organizations that must comply to HIPAA regulations (these entities are called ‘covered entities’). Unfortunately, Part 164 is further divided into 31 subsections that define the actual security requirements. Rather than digging into each of these sub-sections, I’m going to focus on sub-section 312 which defines the technical safeguards that must be implemented by covered entities. Subsection 312 specifies 5 standard safeguards: access control, audit controls, integrity, person or entity authentication, and transmission security. The code further specifies implementation requirements for each standard. The following mindmap graphically illustrates Subsection 312.

Mindmap of CFR 164, Section 312

Mindmap of CFR 164, Section 312

As far as legislation goes, the HIPAA Technical Safeguards are fairly well written in terms of striking a good balance between actionable requirements with room for interpretation to make the standard independent of changes in technology (for example, the Encryption safeguards do not name specific encryption algorithms that need to be used). However, the Safeguards are too vague to use alone. Therefore, NIST prepared a Special Publication, SP800-66 Rev1 (found here), that can be used to help interpret the safeguards by mapping them to specific controls described in NIST documentation. In a future post, I’ll further examine NIST SP800-66 and attempt to summarize some of the specific security controls to implement the HIPAA Technical Safeguards.