One interesting outcome is that the insecure wireless WEP protocol will be banned…but not until June 2010. Says Ars Technica:

Although TJX has become the poster-child for consumer data theft over WiFi, it is (by far) not the only company to use insecure wireless technologies. Wireless security manufacturer AirDefense released a report in late 2007 saying that a quarter of the 4,748 retail access points it surveyed across the US had no security whatsoever, while another quarter only used WEP, “one of the weakest protocols for wireless data encryption.” Just under half (49 percent) of the surveyed hotspots used WiFi Protected Access (WPA) or WPA 2—much stronger encryption protocols than WEP.

If you’re wondering about what other impacts will have, you might want to read through the PCI site or sign up for the SecureWorks webcast on October 14th to learn more.

• Good news: router is now officially a firewall (it has been for a while, but many people are still stuck in "security device" vs "network device" cloud) - see Req 1
• From the "WTH dept": anti-virus is a MUST on ALL platforms - Req 5. Please ship me some of the stuff they are smoking; I want it! BTW, I am going to Amsterdam soon :-)
• WAF or code review for web application security is still a stupid "OR" - Req 6.6. OMG, please, software security folks, teach them the truth.
• Can we kill "plain text passwords" once and for all? Req 8 tries to achieve that noble goal (good thing!)
• Visit your offsite data storage - good (if costly) idea - added to Req 9. Requirements to secure electronic AND  paper media  are solid too.
• Love it, love it! Req 10 explains that logs needs to be actually available: 'three months of audit trail history must be “immediately available for analysis” or quickly accessible' (bye-bye, silly log dumps...)
• Some vulnerability stuff clarified in Req 11, mostly about ASVs and pentesting.
• Scope of security policy is expanded to "employee-facing technologies" (what a term!) - Req 12
• All over: more references to wireless  (WEP, access points, hidden SSIDs, etc) - indeed, recent data losses are often due to insecure wireless.

Overall, a minor change that, sadly, doesn't touch a few KEY areas, such as virtualization, for one.

Apple splits its 802.1X support into two pieces. There's basic support built into the iPhone 2.0 software, found in the Settings application's Wi-Fi section. Click Other. Click the None label next to Security, and the WPA Enterprise and WPA2Enterprise options appear. Select either, and the main login screen lets you enter the network's name (SSID), a user name, and a password. This basic method is limited to WPA Enterprise and WPA2 Enterprise, the two most common (and most secure) forms of 802.1X.

Most enterprises will want much more control over this process, and Apple provides the iPhone Configuration Utility, currently available in its most complete form only as a Mac OS X application, and in more limited forms as Web 2.0 applications for Windows and Mac OS X.

The utility serves two purposes: creating configuration profiles, including for multiple Wi-Fi networks and VPN connections; and allowing iPhones in an enterprise to run internally developed iPhone software. The Wi-Fi profiles allow you to create WEP or WPA/WPA2 802.1X configurations, and include support for choosing allowed EAP messaging types, configuring authentication elements associated with a given EAP type, and adding server certificates and names for better authentication control.

Once created, these profiles can be distributed throughout a company via email or as a direct download to the iPhone via an intranet Web server. Apple chose not to encrypt them, which means that certain information that's not secured--such as the shared secret for certain VPN connections--could be disclosed to someone who had access to the profile or could download it off the local network.

• Architectural/Design Defects
• Implementation Defects

Microsoft has been releasing security bulletins since 1999. Based on some informal analysis that members of our organization have done, we believe well over 50% of *all* security bulletins have resulted from implementation vulnerabilities and by some estimates as high as 70-80%. (Some cases are questionable and we debate if they are truly “implementation issues” vs. “design issues” – hence this metric isn’t precise, but still useful). I have also heard similar ratios described in casual discussions with other software developers.

I know, I know- it’s late- but better late than never, right?

I really tried my best to take photos as much as possible. A quick note on the photography- because of the size of the rooms, it didn’t make sense to have the flash on, unfortunately it slowed the shutter speed, making some images blurry (sorry).

So Day 2 already felt like day 5 somehow. I had flown in early to be a tourist for a day or so but caught up with partners and other event-goers early, making it an especially long week. Wednesday was an eventful day. I have a great  Sins of Our Fathers session to share with you, a day with the Enigmas, and the Security Bloggers Party.

The highlight of the day’s sessions had to be the ‘Sins of Our Fathers’ breakout with an amazingly hilarious geek-filled panel including Daniel Houser, Ben Jun and Hugh Thompson. (Hugh unquestionably won the Most Entertaining Geek Award for the day). I was tweeting live from the session and took some photos of the interactive polls they intertwined in the discussion. They drew some interesting correlations between current security issues, such as SQL injections an ‘previous sins’, likening it to phone whistling. There were random notes about the inherent security risk of mixing data and coding together. View photos from session.

Then they talked about using good technology in a way that made it vulnerable. Examples, the Enigma code machines from WWII. (It was actually broken by the known plain-text gathered from repetition in contact initiation, and the mis-use of one-time-pads). They drew the line from Enigma to WEP and other algorithms that were okay, but mis-implemented.

There were a variety of other anecdotes, accompanied by audience-wide snickers, snorts and laughter. One story of tape backups, encrypted, with the key dutifully stick-noted to the case. Another of the secretary who type-writered all the 5.25” floppies. The story of the unmanned Predator aircraft flying unattended for about 5 minutes during a PC reboot. They were all tied into the topic nicely, and the guys did an outstanding job interacting and playing off one another.

One a more serious note- well, sorta- Hugh showed a clip from his participation in the documentary “Hacking Democracy” about the lack of security of electronic voting.

Here was something amusing… Their crypto list of
If you hear any of these, RUN!

1. Cryptography is expensive.
2. We have this guy that’s reallllly smart…
3. Wired EQUIVALENT encryption… . 
4. It’s “proprietary” security
5. It’s revolutionary NEW cryptography technology!
6. It uses DES- so its FIPS 140 compliant 

Some of the sins from the session…

• Engineering, Development & Management sins
• Using a good technology in a bad implementation
• Lack of metrics to indicate misuse
• Feature/mission creep - using item A for solution B
• Not teaching people how to use security
• Teaching them, but teaching bad habits
• Normalization of deviancy

I’ve spent long enough on that, there’s plenty more to share, but that session was so good, I thought it deserved some special attention. I did stay for the Cyber Storm II Panel, but that left more than ‘a little’ to be desired. I would have liked more anecdotal stories and a little more personality. The panel participants were knowledgeable, and I’m sure they were doing what they had been told, but it made for a very dry session, little content of interest, and much repetition. There’s a little live Tweeting from that session too.

Playing with the Enigma
At the Sins of Our Fathers sessions, I believe it was Ben that mentioned we had at our disposal not one- but TWO Enigma machines on the expo floor here are RSA. And BOTH were for our playing! They had it set so we could set the key and encode a message at the NSA booth, then take the encrypted message to the Cryptographic Research booth and use that Enigma to decypher the message. HOLY COW!!!!!! If their session hadn’t been so great I would have left right then. The only time I’ve seen these beautiful little pieces of crypto history, they’ve been fully encased in glass, and not for the touching. They actually let you set the rotors and punch the code in yourself so my buddy Eric and I ran right over to take full geek advantage of the situation. 

YES, that’s me with an Enigma, and I have more photos of the two Engimas.

The big highlight of the evening? The Security Bloggers Party of course! You get a whole post just for this topic, so stay tuned for that. I didn’t take photos here, because I felt pretty sure someone would be walking around with a camera. I need to find @ajolly (Apneet Jolly) and see if he has any- he’s usually fully equipped with a very nice camera…

# # #

Folks, there are fundamental differences between names, which are public claims of identities, and authenticators, which are secrets used to prove identities, and I've written extensively about this before. An SSID is a network name, not -- I repeat, not -- a password. A wireless network has an SSID to distinguish it from other wireless networks in the vicinity. The SSID was never designed to be hidden, and therefore won't provide your network with any kind of protection if you try to hide it. It's a violation of the 802.11 specification to keep your SSID hidden; the 802.11i specification amendment (which defines WPA2, discussed later) even states that a computer can refuse to communicate with an access point that doesn't broadcast its SSID. And, even if you think your SSID is hidden, it really isn't. Let me explain.

All 802.11 wireless networks, regardless of the kind of operating system or encryption you might use, also emit unencrypted frames at times. One kind of unencrypted frame is an association frame. This is what a client computer, or "supplicant" in the 802.11 protocol vernacular, emits when it wants to join a wireless network. Contained within the frame, in clear text of course (since the frame is unencrypted), is the SSID of the network the supplicant wants to join.

Both Windows XP and Vista work best when your access points broadcast their SSIDs. XP really doesn't behave well at all with nonbroadcasting SSIDs. Vista has some added smarts to improve this a bit. Normally, Vista continually sends probe requests for nonbroadcasting networks. These probes are similar to unencrypted 802.11 association frames, and will generate clear-text responses from the access points if a nonbroadcasting network is present. You can reduce, but not entirely eliminate, these probes by configuring the wireless client to probe only for automatically-connected nonbroadcasting networks.

Both these behaviors make it very easy for an attacker to discover your SSID. The bad guy, perhaps a contractor or a guest in your facility, could run one of many wireless sniffer programs and simply capture the hundreds of association frames or probes that litter your air. No amount of "hiding" configured in your access points can prevent this kind of traffic interception.

So there you have it, simple SSID discovery. The old axiom remains true: security by obscurity is no security at all. Hiding an SSID will not hide a wireless network, so ignore any such advice -- and it's amazing how often I continue to see this. By the way, also ignore any advice that says to use MAC address filtering. It's amazingly trivial to spoof the MAC address of an allowed supplicant -- simply sniff the traffic, look at the MAC addresses, and use the neat little SMAC utility to change your MAC to one that's permitted.

Nonbroadcasting networks are not secure networks. The right way to secure a wireless network is to use protocols that are designed specifically to address wireless network threats. If you're still using WEP, either static or dynamic, I encourage you to move to WPA2 as soon as possible. For those of you at home running XP and have kept it updated, or if you're running Vista, then, you simply need to enable WPA2. We've got some additional guidance for home/small offices and for enterprise networks with certificate services or without. If you have hardware that's more than two years old and you can't upgrade it, check to see whether it supports WPA (an interim specification released before WPA2 was ratified). Both WPA and WPA2 are built on sound cryptographic principles, they're proven in the field, and they'll keep the bad guys out -- even when you're broadcasting your SSID to the world.