Mycurial gave an overview of High-Frequency Trading systems in the next talk. These are the systems by which computers trade stocks and other investments with other computers, as a form of arbitrage — they offer things for sale to fulfill trades before they actually have the items in question, then quickly buy them. It’s a speed game, with latency measured in nanoseconds, such that distance between the trader and the exchange matters (light can only go 11 feet per nanosecond, after all, so a few hundred yards might put you behind another trader, resulting in a loss.) As a result, conventional security measures are practically nonexistent. Networks run on custom, non-standards-compliant TCP/IP and Ethernet stacks. Firewalls and IDSs, which can add latency in microseconds, are absolutely prohibitively slow. These networks are “dedicated,” but these days no network connections are truly dedicated — leased lines are still packet switched and trunked. If someone managed to find their way into one of these networks they could do a lot of damage. For that matter, who’s to say the traders aren’t subtly attacking each other? We still don’t know for sure what caused the May 6th Flash Crash.

I did not manage to catch Richard Thieme’s Staring Into The Abyss at either BlackHat or DefCon, which is unfortunate; many attendees said it was the best talk of the conference. This will be another one to catch on video.

I went to a talk on the Metasploit vSploit Modules, which are modules intended to test IDSs, WAFs, and other network monitoring and filtering technology. Pretty neat code, but not really relevant to my interests.

Gus Fritchie’s Getting Fucked On The River explored vulnerabilities in online poker servers, and the arms race between cheaters and the poker sites’ attempts to stop them. There have been a host of exploits, from a predictable random number generator (if you seed your card-shuffling algorithm with a 32-bit number, there are only 4 billion possible decks of cards, which means someone can essentially build a deck rainbow table and predict draws with great accuracy), to back-door “cheat detection” code that actually leaked hole cards to an insider, to poker bots that play well enough to beat average players (and can beat even skilled players if many of them collude together, or be used to launder money.)

A talk called VoIP Hopping The Hotel was one of the very few technical exploit talks I saw at DefCon this year. Luxury hotels are starting to put VoIP phones in rooms, using the same Ethernet lines as the in-room Internet. If you plug into the phone’s port, though, you see nothing on the network, and can’t get an IP — 802.1q VLAN trunking is used so the phones exist on a different virtual network than the Internet connections, and only the phones can see it. Now, properly used, 802.1q trunking is secure… but “properly used” means never allowing an untrusted user access to a “trunk port” (a single port which hosts multiple VLANs.) Since the hotel port does just this — both the VoIP VLAN and the Internet VLAN — it’s possible to use some tools demonstrated in this talk to gain access to the VoIP VLAN with a computer, puzzling out the VLAN ID for the VoIP VLAN and cloning the phone’s MAC and IP addresses. It takes some skill — send one wrong packet on the VoIP VLAN and you’ll trigger port security and get the whole connection shut down at the switch — but with proper tools isn’t very hard. So why would you want to be on the VoIP VLAN? Well, network designers tend to be lazy… and that VLAN tends to be the hotel’s internal network.

Finally, This is REALLY Not The Droid You’re Looking For was another good exploit talk. On Android devices, it’s possible to craft an application that uses only common permissions (“Read Phone State”) and uses only “safe” APIs (meaning automatic approval for publication in the Android Market) that spawns a service that watches for a specified list of apps, and (upon seeing one) foregrounds itself silently over the app in question. So someone can make a game which, after you have played it once, silently lies in wait and when I load up Facebook, or my bank’s app, or my password manager, pops up a fake login screen over the real one and intercepts the password. As a user, there is no defense and no detection; there may be no fix for this short of a significant overhaul of Android’s UI APIs and permissions.

Also back this year (for the first time in many years) was DefCon TV — the talks were broadcast over the hotel’s internal cable system to all the rooms. So when a talk filled up, you could just go back to your room and watch it there if you were staying in the Rio. It was quite convenient, though in some rooms (including mine) not all 5 tracks were available. Still, according to the DefCon Goons this helped a lot with crowding, since many people would watch talks from their rooms and only come down to the conference floor for more social activities.

For the evening, I met up with the DC206 group again, ate over at the Gold Coast hotel, and then dropped into the IOActive Freakshow (yet another pool party), followed by the DC303 party (featuring Dual Core and C64, playing a mostly drum-and-bass set in lieu of the usual nerdcore, albeit still with some rapping) and finally the DefCon White Ball (with Miss Jackalope playing more drum-and-bass.) There was a lot of dancing and not a small amount of drinking, with the usual discussion of hacking, infosec, and reasons to make a Tesla coil out of DefCon badges. All in all, it was another good night.

I started the first day with 1o57′s talk on the new DefCon badge. This year’s badges were non-electronic (for the first time in several years) — they were antiqued titanium discs with the Eye of Ra and various codes inscribed in them with a water knife. Apparently making the 10,000 DefCon badges actually used the entire supply of sheet titanium in the United States at the time. Bright side of them being non-electronic: they actually had them before the con started! There has been a history of the badges getting hung up in customs on the way from China, but the non-electronic badges were produced in the USA. 1o57 designed an elaborate puzzle contest around the badges, but I can’t say much about it as I didn’t participate this year. There was, however, a very nice-looking code wheel on the floor of the Rio convention center rotunda that was key to the game and gave the room a nice DefCon look, so it was appreciated even by non-participants.

I spent the next couple of hours exploring the non-talk aspects of DefCon (none of the sessions in those slots were particularly interesting to me) and bought up some DefCon shirts and a couple of 2600 Hacker Calendars. I also donated $170 to the Electronic Frontier Foundation in my name and my wife’s, though I didn’t actually end up going to the party to which that entitled me admission (the donation and not the party was the primary purpose anyway.)

I dropped into Mark Weber Tobias’s physical security talk, called Insecurity: An Analysis Of Current Commercial And Government Security Lock Designs, which involved some hilarious attacks on “high-security” physical locks. You know those locks with 5 vertically-arranged pushbuttons you see in every airport or government building? They pop right open if you stick a neodymium-iron-boron magnet on the side. A keycard/keypad electronic lock with a USB port on the bottom for reprogramming is impervious to electronic attacks… but opens if you shove a paperclip to the back of the USB port. This sort of attack was ubiquitous — simple modifications that made sophisticated electronic locks open in purely mechanical ways. The overall point is that to get through a door, you do not have to open the lock — you have to actuate the mechanism that the lock actuates. Sometimes this is really easy.

The next talk was entitled Why Airport Security Can’t Be Done FAST, about the TSA’s Future Attribute Screening Technology. This project intends to detect malicious intent, based on biometrics and facial cues, kind of like an electronic Cal Lightman. The problem, in short, is the standard Bayesian statistical issues that always come up when trying to detect something vanishingly rare like terrorism. The top 10 airlines in the world carry a billion passengers per year — the top 5 US carriers alone carry 500 million per year. How many of these are terrorists who actually intend to blow up a plane that flight? Let’s be very conservative and pretend 100 people try to board an American plane with the intent to blow it up every year (probably an enormous overestimate.) Now let’s imagine my FAST system is 99.9% accurate at detecting terrorists — sounds great, doesn’t it? Let’s get that into our airports immediately! But wait… 99.9% accurate means it will probably catch all 100 terrorists. It’ll also catch 500,000 innocent people — 0.1% of the 500 million passengers. So if FAST points you out as a terrorist, there’s a 0.0002% chance it’s right! Due to the base rate fallacy, a 99.9% accurate terrorist detector’s alarms are false positives 99.9998% of the time. Oops.

What do you bet the real FAST isn’t 99.9% accurate, either?

I next attended the EFF Year in Civil Liberties panel for a summary of legal issues in information security, privacy, and free speech. This was followed by the Hackerspace Panel, about hackerspaces and DefCon groups around the country and what they do to encourage innovation and bring hackers, makers, and other interested people together. Both panels went very well, especially given that the Q&A nature of panels often makes them hit-or-miss.

Friday night at DefCon is surprisingly free of events — about all that’s going on is the Black Ball and the DefCon Pool Party. I met up with the DC206 group again, had some dinner, and mostly hung out at the pool party for the evening and discussed the day’s events and other topics in hackerdom. Frankly, talking about interesting topics (in a hot tub outside with DJs spinning techno in the background, no less) beats most parties anyway.

Next I went to Chris Paget’s overview of the Final Security Review for Windows Vista. Since I’m someone who’s actually done Final Security Reviews for Microsoft and is part of the team that owns the Security Development Lifecycle, there was nothing here I didn’t know. However, Chris gave a very favorable review of Microsoft, and it was clear that she really appreciated the work Microsoft does in securing their products. For all the bad press Microsoft used to get in security, Microsoft has the most mature and complete security processes in the industry, and this is a remarkable turnaround when you look at where they were in 2001. It’s good to know that even on the much-maligned Vista they gave Chris and her team full access to everything and everyone remotely relevant, and got a very good return on investment in terms of security bugs fixed.

I missed the next session to pick up my DefCon badge. In my five years of attending DefCon, they have run out of badges every time, thanks to DT underestimating attendance (each DefCon has been much bigger than the last, recessions notwithstanding.) As a result, everyone queues up early to get one, making for hours-long lines. Though this year they went for a non-electronic badge, and thus at least had them on time, they did still run out by midday Saturday. Lines were about an hour at BlackHat, and apparently ran to over two at the Rio.

In the afternoon, I dropped into Moxie Marlinspike’s SSL and the Future of Authenticity. Moxie is worried about the constant compromises of SSL Certificate Authorities — many have had bugs in them that made it possible to get real, valid certificates issued to you for other people’s domains (e.g. google.com, or your bank), thus making it possible to eavesdrop on SSL communications in a man-in-the-middle scenario. One of the most-public breaches was the attack on Comodo that resulted in many false certificates being generated for some of the most important sites on the Web. But what happened to Comodo? Nothing! The CA system has no ability to change. Browsers trust Comodo, and even if we don’t like the idea of trusting them anymore — when they have been proven untrustworthy — there’s nothing to do about it. If browser vendors dropped Comodo, 20-25% of all secure sites on the Web would stop working. Moxie proposed a new system (he demonstrated it with a Firefox plugin called Convergence) wherein the user selects trustworthy parties, called notaries, which verify certificates for him. The notary system will prevent a man-in-the-middle attack just as well as the CA system does, and if you distrust a notary you can just switch to others, and nothing breaks. The user chooses who to trust. On one hand, this does give trust agility — the ability to change who you trust — which Moxie highly values, and it does prevent man-in-the-middle attacks unless the attacker is very close (from a network-topology standpoint) to the destination host (which is unusual — in most MitM attacks, the attacker is very close to the source host, not the destination.) On the other hand, I’m not quite convinced — the system does not prove authenticity, only that no MitM is present, so it doesn’t really substitute for the CAs. However, I’d say my friends and I spent more time discussing this talk than any other at BlackHat or DefCon, so right or wrong he got us thinking, which can only be good in the long run. The CA system really is broken, and it’s untenably fragile — if one CA has its private key widely distributed, everyone will be able to make fake SSL certificates forever. And there are thousands of CAs.

I went up to IOActive’s IOAsis suite at the top of the Forum Tower in lieu of the next BlackHat session. I’m not sure what actually happened between BlackHat and IOActive this year, but for the first time since I’ve attended the conference, IOActive had no official presence at the conference (whereas before they’ve been one of the top-tier sponsors) and ran their own parallel events at Caesars instead. I had a pass to IOActive’s events as well — spend five years in infosec in the Seattle industry and it’s hard not to know half of IOActive, particularly their CEO who seems to have the remarkable ability to remember everyone she meets, instantly and forever. I went to a talk they hosted about malware tools like Spy Eye and Zeus. Overall, they’re remarkable professionally-developed tools, with high-quality tutorials and documentation. They really make being a criminal easy, and if you happen to live in a non-extradition country like Russia, it turns out crime does pay.

Finally, I went to a talk about the latest Chip & PIN exploits. I have to admit, as an American, Chip & PIN exploits always seem kind of lame. They boil down to “with this amazing exploit, we can make European credit cards almost as insecure as American ones are all the time!” The fact that if you steal a credit card you can, you know, buy stuff with it until the cardholder notices it’s gone and calls the bank just doesn’t seem like a revelation. This said, it is interesting to see some of the dubious security decisions made in this “secure” payment system, and Chip & PIN will be coming to the U.S. in the near future. The worst threat here is not technical but legal — in most European countries, the fact that a transaction happened via Chip & PIN is considered prima facie proof that you authorized the transaction and are fully liable — either that, or you were negligent with your PIN and still fully liable. The fact that it’s possible to make these transactions without a PIN makes this dangerous.

At this point, BlackHat USA 2011 was over. I headed back up to IOActive’s IOAsis suite for their post-conference reception. I not only met up with several people from IOActive, but I also happened to strike up a conversation with someone who informed me that she was with the DC206 group — the local DefCon club here in Seattle that meets at The Black Lodge about 10 miles from here. We quickly found we had several friends in common, and she introduced me to the other DC206/Black Lodge people at the party. This worked out very well, as I ended up hanging out with them for the next three days of DefCon, and had a lot of great conversations with a very interesting mix of security pros, makers, and hackers as a result. Though I’ve been by the Black Lodge and DC206 events before, I plan to make an effort to be present for more of them in the future.

We went to the Microsoft party at the Haze nightclub in Aria, primarily because given the youth of the Aria property, none of us had ever seen it before. The party itself wasn’t bad — quite good compared to last year’s event — and they had a nerdcore rapper performing (I honestly don’t remember if it was DualCore or MC Frontalot, having encountered both of them multiple times during the week.) However, we stayed only briefly then moved to the Rio, where we hung out with other DefCon attendees at the pool. The Rio was kind enough to keep the pool open until 1am (much later than normal) for DefCon attendees, and even until 2am on subsequent nights, which was quite appreciated.

Apple doesn’t want you to run anything on your phone that they didn’t approve. But of course, customers want to run whatever they want on the phone they bought, regardless of if Apple likes it. This creates end-user demand for jailbreaks — software that attacks their phone’s OS to remove Apple’s restrictions. Whenever one is discovered, Apple patches it, but another one is always discovered soon afterwards.

Right now, there’s a website, jailbreakme.com, that offers the easiest, most convenient jailbreak yet. You browse to the site on your iPhone, iPad, or iPod Touch, and suddenly it’s jailbroken and the non-Apple application stores like Cydia are available. It’s very slick, and much easier than any previous jailbreak, many of which required modifying OS images, caching key signatures from Apple, and other tasks that required at least some moderate technical savvy. People really like jailbreakme.com — it makes taking ownership of your own phone quick and easy!

How does it work? Well, it’s a combination of two exploits. When you visit the site, it loads a PDF that exploits a bug in Apple’s font rendering (iPhones render PDFs themselves, using Apple code — Adobe’s reader is not even involved) to load and run arbitrary code. Then that code exploits another vulnerability, in the iOS kernel, to run code as root, outside the app sandbox. This third piece of code jailbreaks the phone and installs the necessary backdoors to wrest control away from Apple and give it to the user.

But… there’s a problem here. The fact that this works means that there’s an unpatched remote root exploit on every iOS device. That is, on an iPhone, iPad, or iPod Touch, any website you visit or any email you receive can silently load and run arbitrary code on your device, which will then reside there permanently and do whatever the attacker wants. How do you know this hasn’t already happened to your phone, and your location isn’t being tracked, your calls tapped, your SMS messages and web passwords forwarded to some Russian crime syndicate? You don’t. There’s no way to know, because there’s no anti-malware software for iOS — Apple would never approve it anyway, since you’re not “supposed” to be able to run anything but Apple-approved apps anyway.

In a normal, open ecosystem, like that on PCs, this problem would be less likely to happen. If a security researcher discovered remote exploits like this, they would often follow responsible disclosure practices, and contact the vendor and let them know about the problem so it could be fixed. But they’re not willing to do this for Apple — because they need the remote exploit to have unfettered access to their own phones!

Apple has created a situation where someone acting in good faith to help iPhone users use their own devices has to keep security flaws away from Apple, so that they can also be used by malicious attackers. Apple and Apple’s users are on opposing sides — helping Apple hurts legitimate users, yet helping users jailbreak also means helping attackers exploit them.

What’s more, when Apple releases a patch to iOS to make it no longer vulnerable to these attacks, they will undoubtedly reverse the jailbreaks in the same patch. Thus, users will not want to install the patch, since it will kill functionality that they want on their phones! In the IT world, it’s hard enough to get people to patch even when there’s no downside, and Apple’s creating customers who deliberately avoid patches and updates, since most of Apple’s “security fixes” are aimed at protecting Apple from customers, not protecting customers from harm.

Come on, Apple, would a settings checkbox marked “Allow execution of unsigned code” be so bad? You could even pop up a warning that turning it on makes you ineligible for Apple support. Is it really better to force your userbase to help hackers?

This year, BlackHat had an entire Cloud Computing track, running all day on Thursday, of which I attended a great deal. Part of my job involves protecting cloud computing services, so it seemed very relevant, and it’s certainly a hot topic in the industry right now. It began with Alex Stamos, Nathan Wilcox, and Andrew Becherer presenting a lecture on cloud computing models and vulnerabilities.

They defined cloud computing as not just virtualization, but including general-purpose hosts, central management, application mobility, distributed data, low-touch provisioning, and soft failover. They looked at three different cloud models: Software as a Service, Platform as a Service, and Infrastructure as a Service, and the differences & vulnerabilities in each.

The Software as a Service (SaaS) model is to outsource everything. From a security perspective it’s not necessarily a bad idea — the cloud provider probably has a lot more security people than the average company. On the other hand, you also outsource all your data — the recent Twitter “breach” via somebody logging into Twitter’s Google Docs account shows the risks this can entail. You lose the perimeter, endpoint management, the ability to use better authentication than simple passwords, credential quality controls, password reset processes, and realtime anomaly detection (though you hope the cloud provider has some of these things.) It puts all your eggs in one basket — if someone can read your email, they can access all your data. SaaS products include Office Live, Google Apps, and Salesforce.com. None of these have decent audit & rollback capability; Google Apps at least provides login history (though you have to write code & call an API to get at it) but still no read/write level auditing. Salesforce.com offers some write logging. However, the biggest flaw with SaaS models may well be authentication — all your security relies on a password, with all the vulnerability that entails, and you can’t even set a strong password policy (for all the good it would do you.) Google Apps actually lets you use a SAML-based SSO system; with other SaaS apps the best you can do is set a strong password policy via employee education.

Another issue with SaaS providers is the legal concerns — the cloud service EULAs tend to promise basically nothing and disclaim all liability. Also, they forbid malicious traffic — even pentesting your own app. There’s also decreased protection from search and subpoena. Since the data is stored with someone else, there’s no Constitutional protection from search, and even statutory protection is usually only for “communication.” Are Google Docs communication? Courts haven’t really defined this yet. The net result of this is that there’s no need for a warrant, probable cause, or even notice of a search — you can’t fight a seizure before it happens, but only after the fact.

Platform as a Service (PaaS) is the model of having a common development platform provided, yet allowing people to customize their applications. This is the model of Google AppEngine, Force.com, and (maybe) Windows Azure. (Azure is a unique case, kind of halfway between PaaS and IaaS; I’ll come back to this.) This section of the presentation was rather odd, as they really looked at the common web vulnerabilities (CSRF, XSS, SQL injection) and investigated how the platform protected you from them. In short, the answer is that they don’t. Some of the platforms have some inherent protection available (e.g. Windows Azure apps are typically ASP.NET, which has some built-in XSRF protection via ViewStateUserKey, XSS protection via encoders, and SQL injection via LINQ), but it’s up to the developer to actually use them. I found this section somewhat lacking, because it wasn’t really about the cloud platforms at all, but rather the common web technologies sitting on them.

The Infrastructure as a Service (IaaS) model is that taken by Amazon EC2 and similar services. It provides virtual machines with short-lived instances, non-persistent local storage, and available helper services. Though the presenters thought of Azure as very much a PaaS model, I think it’s a little fuzzier here — while Azure does not allow you to choose an operating system (the Windows Azure OS runs on every VM), it does not constrain you to anywhere near the degree of Google AppEngine or Force.com, as you can run arbitrary native code on it. It would be impossible to use AppEngine or Force.com to run anything but a web site; Azure is like EC2 in that it could be used for any flexible computing task, not just web sites.

The problems with IaaS services are usually hypervisor flaws or problems in the helper services. However, they brought up something very new here that I don’t think any of the current cloud providers consider — lack of entropy. Virtual hardware has mostly deterministic timings — input events don’t exist and block device events are abstracted. Thus, entropy is generated very slowly if at all. What’s more, in the case of Amazon EC2, since OS images are available to everyone, an attacker can get a copy of the stored entropy pool you’re using (which will never update after the image is originally created, thus depriving the system of another source of entropy) and eliminate it as well. The net result of this is that pseudo-random number generators — even cryptographically strong ones — are unreliable and may be predictable. This attack may or may not be practical given the specifics of the system in question, but for now you may not want to build your online casino or public key infrastructure in an IaaS environment! Cloud providers may actually have to have random number generation as a helper service as well, supported by quantum hardware.

Next, Jeremiah Grossman and Trey Ford presented a sequel to last year’s talk on “making money the black hat way.” Essentially, it was a survey of interesting hacks-for-profit that have been carried out recently. They noted that hacking activity is up this year (layoffs create more hackers?) and that 69% of attacks are discovered only because a 3rd party tells the company it’s been hacked.

Some of the interesting ones: eBay gave away 1000 items for $1 in a “Holiday Doorbusters” promotion. However, almost 100% of them were bought by bots, which was evident because the items were purchased before the item description page was even viewed. StrongWebmail.com had a contest to give $10,000 to whoever could hack into the CEO’s webmail account; rather than attacking the servers, the winners of the contest sent the CEO phishing mail with an XSRF in it that stole the contents of the account. (Amusingly, they got him to open the mail by labeling it “I think I won.”) Grossman & Ford also brought up cookie-stuffing, a type of affiliate fraud that’s been around for many years; it’s a well-known technique in the affiliate marketing world (basically you spoof the referrer while iframing the advertiser’s site on your site, then drive traffic to your site in ways that would not please the advertiser if they knew about it) but was apparently new to most of the BlackHat audience. They also brought up the technique of using embedded site search to fake authority links, another well-known “black hat” SEO technique. Marketers have apparently also begun spamming Google Maps with fake businesses, so as to come up first in “local searches” with their web-based and not-remotely-local businesses. A man in Britain used Google Earth to find all the lead roofs in London, then steal the lead tile in the middle of the night.

Some of the more ambitious hacks were more intriguing, though. One man discovered that you could order “advance replacements” for broken iPods from Apple just by giving them a credit card number as collateral; he used low-balance anonymous Visa gift cards to get 9,000 iPods. Another group put their garage band music in the Amazon and iTunes stores using Tunecore, then bought hundreds of downloads of their own album with stolen credit cards (thus getting a big check from Tunecore.) One thing to note is that these people got caught only because they weren’t trying not to. The iPod guy shipped all 9,000 to his home address; the Tunecore fraud was so blatant as to get this garage band’s album onto Amazon and iTunes top-10 bestsellers.

Finally, in South America, the system for getting logging permits for the Amazon rain forest was put online. An investigation discovered that 107 different logging companies had hired hackers to compromise the site, which was full of common web vulnerabilities. All told, 1.7 million cubic feet of lumber were smuggled out of the country. Scary permit systems in the United States that are now protected only by a web site: entrance visas, hazardous material transport, and open burning permits.

Next, Haroon Meer, Nick Arvanitis, and Marco Slaviero presented a talk on “Clobbering the Cloud.” This SensePost talk covered much of the same material as the iSec Partners talk earlier in the day. Their primary risk factors for cloud computing were as follows: lack of transparency from cloud providers (opaque EULAs), people don’t want to store regulated data in the cloud, vendor lock-in especially if the vendor goes out of business or stops offering the service, availability concerns (not just servers being down, but also things like password lockout from DoS attacks), monoculture issues (worms and cascading compromise are a big concern when you have thousands of perfectly-identical boxes), and trust in the cloud provider — you have to trust your cloud provider implicitly not to lose your data or have system failures. In addition, there’s the problem that the cloud is available to the bad guys, too — cloud boxes can be used for click fraud, DoS, or spamming (for a short time Amazon EC2 was the net’s #1 spammer.) Finally, the security of your environment is all in the hands of the account owner, who authenticates with nothing more than a password, and is (in most companies) probably a non-technical executive. Breaking into the CIO’s email now makes you the global administrator of the company’s entire infrastructure.

The presenters then went into more detail about attacks on Amazon Web Services (EC2, S3, SQS, and DevPay) in particular. I can understand why they chose AWS; due to its flexibility, it’s certainly the most fun of the cloud services for a hacker to play with (though Windows Azure is getting there, too.) EC2 is based on a modified Xen hypervisor, and supports running any OS you want that can run in that environment. Amazon provides 47 OS images, but users have contributed over 72,000 more, and an EC2 user can choose to boot any of them. Sometimes user images have interesting things in them, like other user’s EC2 credentials, for example.

Scanning EC2 is prohibited, but you can start up one of the images and scan it yourself via an SSH tunnel (or even have the machine scan itself.) They found 646 Nessus critical vulns in Amazon’s public images; you can also steal Amazon’s own Windows activation keys off their images. The DevPay system is interesting; it’s supposed to allow a user to make an image then charge other users for its use (e.g. to resell an application on EC2.) However, the presenters found you could get a DevPay image and modify its ancestor info (stored in the image itself) so as to credit use of it to you rather than the original author, then reregister it for others to use.

Simply putting up pre-owned (pun intended) images for others’ use can be an attack on AWS. If you prop up a box with a good name (e.g. “Ubuntu 9.04 Standard Image, All Patches”) and a low-numbered ID (so it shows up at the top of the list), and people will use your image to host their apps! You can get a low-numbered ID simply by registering repeatedly; since it’s a hash, eventually you’ll get lucky and have one start with zero. You can only have 20 images per account, but you can create 20 accounts in 3 minutes, so there’s no effective limit.

After that talk, I went over to the mobile track to hear Jesse Burns talk about Android. Android interests me because I’d really like a phone that behaves like a computer (i.e. a device I own) rather than like a toy the phone company is reluctantly allowing me to touch, and Android’s open-source nature has real potential to give me that. It’s not that I trust Google any more than any other wireless provider, just that the platform seems much more hackable and thus inherently harder to control.

Android has a dual security model — Android permissions on various privileges, plus Linux permissions on the filesystem. Applications have their own UIDs/GIDs and are thus somewhat isolated from each other. A package (application) is made up of Activities (GUIs,) Services (background tasks,) Broadcast Receivers (event handlers,) Content Providers (databases,) and Instrumentations (used for testing.) For interprocess communication, there are Intents, which are sets of name-value pairs with routing information. Applications are written in Java, but they’re not applets (i.e. no Java sandbox.)

Available attack surfaces for a malicious app include other apps, system services under privileged accounts (like the clipboard or the surfaceflinger, which draws the UI and owns the screen,) the binder (the inter-process communication system, similar to domain sockets,) and anonymous shared memory. There are a variety of tools available — one can just install a bash shell on Android (either interactively or over the wire or network,) use logcat to look at logs, view Android system properties, check the /proc and /sys filesystems, run dmesg to get kernel output, and all the usual Linux attacks. There’s also a file in /data/system/packages.xml that contains data about every installed app, including the location of the app and its manifest. /proc/binder contains a transaction log of the inter-process communication, and /proc/binder/proc contains data of all the processes themselves.

Another interesting detail about Android is the “secret code” handler. When you dial *#*#somenumber#*#*, this triggers the secret code handler for that number, which can do pretty much whatever an app wants it to do. The only secret codes on “stock” Android are 8351 and 8350, which turn voice dialer logging on and off, respectively. However, wireless providers may add additional codes — the presenter found some in T-Mobile’s MyFaves app, for example. Finally, the presenter had a series of Android hacking apps he’d developed — Manifest Explorer (to view the system manifest and the manifest of each app, such as to see what events they react to,) Package Play (to see the parts of a package or to directly activate Activities,) Intent Sniffer (to view Intents as they’re routed at runtime,) and Ill Intent (an Intent fuzzer.)

The last presentation of the day was Bruce Schneier, whose talk was entitled Reconceptualizing Security. Mostly, he gave the same speech he always does, about fear, psychology, security vs. security theater, why we mis-estimate risk, etc.; pick up a copy of Beyond Fear or Secrets and Lies if you want the details. However, during Q&A he did also talk about the attack on AES-256 that was just demonstrated. It’s a feasible attack on 10 rounds of AES-256 (out of 14,) in 2⁴² time. It’s a related-key attack that works only on 256-bit keys (not on shorter ones,) so there’s no reason to panic right now, but it does show that the margin of safety on AES is smaller than we thought. There may need to be a Double-AES in the same way Triple-DES was devised as a stopgap until a new cryptosystem is developed. Alternately, the standard could be changed to increase the number of rounds, but that would require replacing or updating all the AES-based crypto hardware out there.

And that wrapped up BlackHat 2009. Overall, there was nothing as Earth-shattering as last year’s DNS exploit, though it turns out that the SSL issues are pretty nasty. After BlackHat, I hit the Microsoft Security Researcher Appreciation Party at Christian Audigier, which was actually a pretty good party this year without any of the problems of previous years. It’s only drawback was that it only ran two hours. However, at this point DefCon festivities had begun, so there was still plenty going on; my next post will get into DefCon 17.

The Wednesday keynote was presented by Douglas Merrill, the COO of EMI Records, formerly of Google, RAND Corporation, and several other places. He spoke on a popular topic for security conference keynotes — risk assessment and innovation. 80% of CEOs believe they’ve had a data breach, even though the statistics show that it’s basically impossible for the actual rate to be that high. And most of the breaches that do happen are trivial — looking at Privacy Watch’s statistics, 16% are lost laptops, 11% are paper that’s thrown away, etc. Actual hacker activity accounts for only a small percentage of the breaches — certainly not enough to justify what we spend on security. We constantly try as an industry to come up with “security ROI” metrics to show execs, but most of them are just nonsense; we make up numbers, then multiply them by numbers we also made up, and that’s how much you saved in the security breaches that didn’t happen but might have.

The #1 driver of security for CEOs is BCP (business continuity planning) — they just want to make sure things keep running no matter what. For security people, the #1 driver tends to be compliance — because it’s a stick with which we can make executives spend money even when they don’t want to. Due to the huge downside of a breach for us (since our job is preventing them, having one happen looks really bad), we overinvest in prevention.

Merrill’s point was that this overinvestment in security can stifle innovation, especially when perimeters (my favorite thing to hate, I know) are involved. People use consumer tools because the enterprise tools restrict them too much. Giving people control of their machines promotes innovation, and companies where people are free to innovate are more profitable — but giving people control makes endpoint security impossible, and reduces control by security and IT. We risk our jobs by doing the right thing for the company, and so we continue to do the “safe” thing even when it doesn’t make sense. Overall, it was a pretty good keynote — nothing revolutionary in it, but certainly food for thought for an audience of security professionals.

The second talk I attended to was three “mini-talks” about new Metasploit functionality, presented by Dino Dai Zovi, Mike Kershaw, and Chris Gates.

Dai Zovi adapted Meterpreter for the Mac. He created a Mach-O function resolver, and found one in the OS that wasn’t covered by the library randomization. His payload injects a remote execution loop, creates a bundle in RAM, then loads and executes it (neat trick, very hard to do in Windows but apparently easy on a Mac.) This can be used to load either Dai Zovi’s CocoaSequenceGrabber payload (which forces the webcam to take photos and send them to the hacker), or Macterpreter, a Meterpreter port by Charlie Miller. Pretty much all of Meterpreter works except process migration (processes owned by the same user can’t write to each other on Macs), so it should be good for all your Mac-hacking needs. He’s also added 4 exploits from the Mac Hacker’s Handbook to Metasploit.

Kershaw sought to adapt all the old shared-media attacks (i.e. what we did in the 80′s and 90′s on hub-based Ethernet) to WiFi. His LORCON2 library translates between 802.11 (WiFi) and 802.3 (Ethernet), so you can spoof ARP, DNS, even TCP connections. This gives you the airpwn attack in Metasploit — you can spoof, say, urchin.js or other common embedded JS files, give them a cache lifetime of a decade, and have someone’s browser calling home for a good long time even when they move off the unsafe network. Open and WEP networks literally can’t be secured against this, since you can spoof the AP to the client (so no AP-based defenses can be effective — the AP doesn’t even see the attack.) If you have the key, you can even do this on WPA-PSK (by forcing deauths and spoofing the AP.)

Gates essentially ported every Oracle attack of the last 10 years to Metasploit (all 11 of ‘em.) Since Oracle charges for updates, there are tons of vulnerable servers out there (albeit not usually on the Internet.) There’s a TNS mixin, and an Oracle DB access plugin that executes queries via Oracle Instant Client (on Linux and Mac OS only, though Chris offered a reward to anyone who would port it to Windows this weekend.) It can grab the SID from the server on Oracle 9, or brute-force it on Oracle 10 (or sometimes grab it, depending on what Oracle modules are loaded.) All of these exploits were old, but they’re now really easy to perform.

David Lindsey and Eduardo Vela gave a talk on bypassing XSS filters. They weren’t looking at escaping/sanitizing functions, but rather HTTP IDS and other external anti-XSS measures.

They went through a long list of HTML tricks that can be done to evade these filters. Omitting whitespace, using / for spaces (did you know <img/src=”file.gif”alt=”text”> — no spaces — is treated as valid HTML by most browsers?), roundabout parameters (using separate<param> tags for everything even when you don’t have to), using data= rather than src= in tags that support it, embedding JavaScript in weird tags like <isindex>, prepending useless namespaces on tags (e.g. <x:script xmlns x=….>), using alternate syntax (why say “document.cookie” when “document[cookie]” or “with(document)alert(cookie)” will do), etc.

They even went into truly strange things, like using the ternary operator to make strings that were valid as both HTML and JavaScript but had different meanings in each, or using deprecated or broken syntaxes (which tends to be browser-specific.) Adding multiple parameters with the same name has undefined behavior, but works in some browsers. With Unicode, you can pad small (one-byte) characters out to extra bytes, which shouldn’t work but is accepted by some Unicode implementations (including Java and PHP.)

Perhaps most interestingly, filters could often be bypassed by ridiculous measures — such as using prompt() instead of alert() when testing for XSS, or using ‘ or ’2′=’2′ instead of ‘ or ’1′=’1′ to test for SQL injection, or /etc/x/../passwd instead of /etc/passwd. Some badly implemented filters just look for specific attacks, not general patterns.

Dan Kaminsky had managed to keep his talk secret this year, so we went into it knowing nothing but that it was “something about network security.” His talk was entitled “Black Ops of PKI,” and covered some vulnerabilities involving X.509 certificates (a theme I’ll revisit a lot when I do my DefCon writeup.) 60% of data breaches are not due to vulnerabilities, but just bad password handling — and PKI, based on X.509 certs, was supposed to fix all that. Of course, what’s actually been implemented is not really what most of us mean by PKI — the universal directory of distinguished names was never built — but certificates are everywhere now.

For those of you not familiar with them, X.509 certs are the basis of SSL/TLS and many other encrypted protocols. A certificate is supposed to indicate that the entity presenting it really is the entity named in the certificate. These are signed by various Certificate Authorities, which all themselves have certificates signed by other authorities, chaining all the way to the Root CAs, which have their certificates just built in to your browser & other software. As long as you trust the root CAs to validate other CAs, and trust those CAs to only sign legitimate certs, the system should work. But… that’s a lot of trust.

The problem is, X.509 can’t exclude — every CA can issue certs for every name. It’s too hard to interoperate with private CAs, so companies promise to behave and root CAs like VeriSign give them a signed intermediate certificate, allowing them to give out valid certs for anyone. What’s more, these certificates depend on various hashing algorithms for their security (since the hashes are what gets signed.) RapidSSL used MD5 for its signatures, and last year some security researchers took advantage of known issues in MD5 to create their own intermediate cert that was “signed” by RapidSSL’s signature. Luckily, that group had no intent to abuse the cert, so RapidSSL moved to a better hash and all was well.

Kaminsky discovered that one of VeriSign’s own certs is self-signed with MD2. There’s not even any good reason to self-sign a root cert, but they always do (because people — and programs — just expect a cert to be signed.) MD2, like MD5, has known vulnerabilities — it’s subject to a preimage attack that will eventually let someone create their own root cert that VeriSign’s self-signature works on. The complexity of this attack is outside our capabilities right now (2⁷³), but won’t be for much longer. This certificate was replaced by VeriSign (with one signed in SHA-1), but it will still probably be a long time before every client gets it off the list.

Much more interesting, though, were attacks on CAs themselves via PKCS#10 (the protocol by which you request a certificate to be issued to you.) When you request a certificate, you provide a “distinguished name”, part of which is the “common name” (domain name, in the case of SSL certs), as a specially-formatted string (it’s fixed-length, not null-terminated), in a binary package. Originally, requesting a cert was a manual process with lots of in-depth verification, but now it’s all automated. Kaminsky asked… what happens if you have multiple common names in one distinguished name? (Undefined; different CAs and clients do different things.) The identifier for common name is 2.5.4.3… what if you provide 2.5.4.03? Is that the same? The strange binary protocol means it may be, and 2.5.4.2⁶⁴+3 might be, too. What if there’s a null in the name? Since the protocol uses Pascal strings (length specified) rather than C strings (null-terminated), nulls in the name are valid, but practically every SSL client there is blows up at them.

And that was about it. Kaminsky ended with a recommendation that we embrace DNSSEC, so we can put certificate hashes in DNS. Unlike X.509, DNSSEC can exclude — we can ensure that only the authorized owner of a domain can provide its certificate, as well as make it possible for domains with EV certificates to exclude normal certificates for that domain. After what Dan presented the previous two years, this one seemed kind of disappointing — an MD2 cert and some parsing flaws in CAs? That’s it?

Actually, it turns out that these are devastating, and essentially render SSL unable to protect communications on untrusted networks (you know, precisely the places where you want SSL to protect you.) Smart hackers will be picking up wildcard certificates while they can, as CAs will be scrambling to fix this. As to why, I’ll explain that during my DefCon Day 1 writeup — Moxie Marlinspike and Mike Zusman presented research (apparently done at the same time as Kaminsky’s) that actually exploits this stuff.

The last presentation I went to on Day 1 was Riley Hassell‘s talk on “Exploiting Rich Content.” The description made this sound like it was about attacking web sites that use rich content (e.g. Flash, Java, Media Player, QuickTime, etc.), but it was actually about attacking the content engines themselves (e.g. making Flash malware), which, to me, is a much less interesting space. But then, my job is protecting web sites & services from attack, not being Adobe.

Hassell demonstrated how, using a fault injection fuzzer called FlashFire, he found 23 vulnerabilities in Flash on 785 codepaths, most of them being read-beyond-bounds issues. Normally those aren’t considered terribly serious, but since Flash runs in a browser, they can be. Essentially, it’s possible to write a Flash component on one web page that steals all the information in your browser’s memory space. If you have your bank’s website open in another tab, that could obviously be a bad thing. It’s quite the scalable bug, considering as Flash is installed on 99% of browsers, and the bug works on all platforms.

And that was it for Day 1. I went to an IOActive reception at Spago, met some interesting people (most of them from IOActive), and called it a night — most of the BlackHat nightlife seems to be on Day 2. I’ll update this post with links to the presentation decks and/or videos when they become available online (decks will probably be relatively soon, but BlackHat does not usually post videos until months after the conference since they are sold for a pretty hefty fee at first.)

A privately-run alternative to the TSA’s Registered Traveller program, Clear started out with what seemed like a good idea — allow frequent travelers to undergo a thorough background check to make sure they weren’t terrorists or criminals in lieu of screening them every time they went to the airport.  For someone who travels by air every week or even every day, the long-run time savings would be worth a fortune.  The TSA was all for this idea, since their goal is to prevent hijackings, not just have people take off their shoes for fun.  So Clear (originally called Verified Identity Pass) was started — and frequent travellers could pay $200 per year, have a background check performed on them, and get a nifty-looking smart card that they could use at any of a dozen major airports to skip to the front of the security screening line.

Wait a minute… skip to the front of the security screening line?  Yep, somewhere along the line some government bureaucrat changed the rules such that Clear and Registered Traveller-certified people still have to undergo the screening, they just get to go to the front of the line.  I can easily see their motivation for doing so.  Imagine being an assistant director at the TSA in charge of such a program: “So, what happens if, God forbid, someone with a Clear card blows up a plane?  What would we say to the public?  ’Yeah, he had a bomb on him, but we didn’t search him, because he’d undergone a background check a couple years ago.  You see, he’d never blown up any aircraft before, so we had no idea this would happen.’”  It would go even worse for the TSA if said terrorist were a member of a group that the public would consider an “obvious” terrorist suspect (e.g. a Muslim of Arabic descent) and would pretty certainly end the careers of everyone involed in the program, if not end the TSA itself.

So the Clear card was changed to only allow you to skip the line, while still undergoing the full security screening.  What no one seems to have thought of, though, is… why bother with the background check?  If you still have to be screened at the airport, what’s the point of having to be investigated to get the card?  In what way does the screening line contribute to security?  Many of these same airports let members of airlines’ top-tier frequent flyer clubs skip the line, too, and they’re not required to have background checks.  Essentially, Clear and Registered Traveller simply morphed into HOT lanes — pay a fee, and you get to go faster than people who don’t pay a fee.  It’s not “trusted” status, it’s “VIP” status. A smart card with associated fingerprint and iris scans seems kind of excessive for jumping a line.

Also, Bruce Schneier brings up an interesting point — now that Clear is out of business and having all its assets transferred to creditors, what happens to all the personal data in the background checks?  Who gets that asset?

It may seem silly to use two-factor auth for a video game.  However, with 12 million players, World of Warcraft is a big business, and stolen accounts are worth money.  Logging into someone else’s account, looting it for virtual money and supplies, then selling them on the open market can easily net $50 per account, more for particularly lucrative ones.  What’s more, the account itself can be sold to offshore “gold farmers” who have a constant need for accounts as Blizzard revokes theirs for Terms of Service violations.  Considering that a stolen credit card number is usually worth only about $10, WoW accounts are actually pretty good targets for theft.

People steal these accounts via installing old-fashioned key loggers — Trojan Horses attached to downloaded software that monitor the user and steal their password when they log into WoW.  Generally these keyloggers are attached to fake WoW cheat programs with names like “WoW stat changer“, or modern recreations of some early real cheats that no longer work (the “speed hack” and “teleport hack.”)  Aspiring cheaters download and install these applications and are disappointed to find they don’t work, but don’t realize that their account has been stolen when the app was run.

The best mitigation to this would, of course, be not to download dubious cheat programs for World of Warcraft.  However, since downloading and installing UI add-ons is a normal activity by WoW players, it is perhaps a bit much to expect players to know the difference between a safe UI add-on (written in Blizzard’s LUA scripting language) and an unsafe one (with real executable code.)  So Blizzard offers a two-factor token, which renders a stolen password useless — since the dynamic passwords change every minute and are not reusable, keyloggers can no longer steal accounts.  If you’re a World of Warcraft player who downloads & runs a lot of not-very-trustworthy Internet software, $6.50 is a small price to pay for security.

The ironic thing about this is that most banks won’t offer this level of security to their customers.  The loss of my World of Warcraft account would be a minor inconvenience (Blizzard keeps backups, after all, and can “roll back” a player’s account to a previous state upon request), while the theft of bank accounts and credit cards would be much more serious.  Yet my bank offers only passwords for protection, and other banks’ “two-factor authentication” isn’t really (“something you know” and “something else you know” is not two factors, it’s one factor repeated twice.)  Banks usually cite cost as the reason, and at the $90 for an RSA token, that sounds reasonable — but if Blizzard can put out their own tokens at $6.50, banks could, too.  The real reason is that the banks do not want to inconvenience their customers by making them carry around an additional object for access to their accounts.  For the most part, customers care more about convenience than security, and many customers would be locked of their accounts by losing a token than would be saved from theft.  (For that matter, customers don’t even know it when their bank account isn’t stolen because of a security measure, so they have no perceived benefit at all.)

Blizzard’s answer to the convenience/security tradeoff is to give customers the option — you can get an Authenticator if you want one, or just use passwords otherwise.  Banks don’t want to do this, though, because it would make password-only customers feel insecure.  The availability of a token might make them realize how unsafe a password alone is, and they might decide to forgo online banking altogether.  This is the last thing banks want — online banking is much cheaper than tellers.

That’s a lot of money.  More importantly, it’s a lot more money than most managers think we’re spending on security.

Now, the accuracy of these statistics is obviously dubious — even a respected and experienced person’s ad hoc estimate is still just an ad hoc estimate.  But it’s worth thinking about this for your company.  How much time and effort gets spent on problems that are, if not strictly security problems, problems you wouldn’t have were it not for malicious users?  This includes not just the things you do to defend your sites (firewalls, IDS, code reviews, etc.), incident response, and responding to subpoenas.  It also includes having to carefully write & test your emails to make sure they don’t get caught in spam filters, and setting up logging & auditing on your sites so you’ll be capable of responding to a subpoena if you get one in the future, and planning for regulatory compliance, and some of your disaster recovery & backup costs.  Consider not just purchases of security hardware & software and the hours of work by the security team, but also all the time consumed by product development and IT teams planning for or responding to security threats.

This “black hat tax” is your real security budget.  And importantly for security managers, this is a genuine, demonstrated cost, as opposed to the “risk” we spend most of our time talking about.  It’s one thing to say the company might suffer a $10 million loss in the case of a data breach, so we need to spend more on security.  Managers can go on believing that “it won’t happen to us.”  It’s quite another to say that the company already does lose $500,000 every year due to the cost of dealing with malicious users, and that we should spend that same money proactively, on planned security measures, rather than spending it reactively.  Don’t just think of your security budget as simply mitigating risk — think about what your company is already spending, just not on the security team.  Can you prevent some of that cost from being incurred?  Can you centralize some of these effors?  Security spending as a way to reduce cost, rather than as a cost center, may be a lot more appealing to your CIO.

RFID devices are becoming more and more common, and this trend will continue — they’re too convenient for many purposes for the security risks around them to stop them. You may not want every consumer good you buy to be tagged with an ID that lets people watch your shopping from 100 yards away, but the scenario of being able to check out at the grocery store by instantaneously scanning every item in your cart simultaneously is too compelling for people to resist.

Bruce Schneier has a post on the ineffectiveness of security cameras, but while calling them ineffective it does note that criminals moved their crimes to somewhere the cameras couldn’t see. This may be “ineffective” for a government camera system designed to deter crime, but it’s precisely what privately-owned security cameras are meant to do — make a target unappealing so criminals go elsewhere. This actually shows that cameras do deter crime… but only where they can see it.

However, both of these technologies can have pernicious effects, too. The HexView article points out that you could use the RFID tire monitors to commit murder — set a bomb with a radio trigger that goes off when the “right” car drives over it. It would also be just as useful to private investigators spying on citizens as it is to law enforcement chasing down criminals. And speaking of law enforcement, these cameras create a dangerous imbalance in their favor — the camera evidence is all under their control, and thus can come up when needed to prove a perpetrator’s guilt yet be conveniently lost in cases of police brutality, abuse of power, corruption etc.

This is an interesting time for surveillance — police and government surveillance ability is skyrocketing (London is practically blanketed in cameras at this point, as the British seem much less uncomfortable with them than Americans are) but it is still largely in the hands of authority figures. This is dangerous because of how fast the change is coming — our criminal laws and sentencing structures are based on the principle that most criminals get away with it. A $75 fine for speeding seems pretty reasonable, but what if that fine were levied every time a car hit 1 mph over the speed limit? Most of us would get fined a dozen times a day, every day, despite not even meaning to speed, because our behaviors are based on the idea that we probably won’t get caught and that even if we are police are unlikely to punish us for very minor transgressions. If people were caught for speeding every time, and fined every time, a $75 fine would be absurd — the fine could probably be under $1 and still bring in a few hundred dollars a month from every citizen. What is the right legal structure here? I can see two possibilities:

• Raise the speed limits to the speeds we really think no one should exceed, and continue to fine every time.  Maybe you should get charged every time you exceed, say, 85 on a highway or 55 on a city street.  Set them high enough that there’s no leeway required.
• Leave the speed limits where they are but set the fine really low, say a $0.25 per minute of speeding.  This makes speeding discretionary — you can obey the law, or not, but if you choose not to you pay a penalty.  This is a fundamental change in the whole idea of crime and punishment, and itself has some pernicious consequences — it means that a certain income level can render you “above the law,” which is not a good thing.  Obviously some crimes (such as murder) should not be treated as discretionary, but for traffic violations it could make sense.

It’s not just traffic laws that are like this; consider the War on Drugs.  If every person who ever smoked marijuana went to prison, we would have a nation of felons — there’d be few people left who could vote, get security clearances, hold most jobs, etc.  The RIAA lawsuits against file-sharers are a good example of what happens when technology that catches everyone gets used to enforce laws designed under the assumption that only the worst and most flagrant criminals will be caught — people being hit by millions of dollars in fines for using technology to do something that wouldn’t even raise an eyelash if done by old, physical means (e.g. posting a song on BitTorrent vs. handing it to a friend on a cassette tape.)

A surveillance society needs a different kind of jurisprudence — one that sets punishments that fit the crime even if applied every time.  On the bright side, actually doing this would lower crime rates tremendously due to the psychology of criminals.  Escalating punishments does little to deter crime because criminals are risk-seekers — they do not expect to get caught.   Even a small punishment can be a strong deterrent if applied every time — if criminals are usually caught, such that all criminals have some first-hand experience with being caught and punished, it would break this idea.  On the not so bright side, a surveillance society must have very liberal laws to avoid being a police state — our current legal system, applied to everyone every time, would result in tyranny.  We all break 10 laws a day, it’s only sloppy enforcement that allows us to live our lives.  Unfortunately, the technology for ubiquitous enforcement will come well before the legal system changes to make it livable do.

What’s interesting to me is what will happen when surveillance becomes even more common: that is, when it is no longer monopolized by authority.  This has already started with cellular phones.   Almost everyone carries around a device which, while primarily for communication, contains a camera and often a voice recorder and videocamera as well.  Everyone is equipped to carry out impromptu surveillance at any time.  Devices like these glasses from ThinkGeek (found via BoingBoing) coupled with the rapidly falling cost of storage capacity will change this to everyone actually carrying out impromptu surveillance all the time.  This will have a chilling effect on human behavior at first — would you act differently if you knew everyone around you was videotaping everything you did?  Everything you say will, indeed, be able to be used against you, and not just in a court of law.  However, look at what young people put on MySpace and Facebook these days — the next generation does not have the assumption of privacy.  They’ve grown up in a world where they know everything goes on a permanent record, and have simply accepted it.  Sure, they’ll be occasionally shocked by it (e.g. the first time their party photos on MySpace disqualify them from a job), but the knowledge of permanence has not stopped them from sharing themselves, and eventually the rest of us will adjust, too.

Consider what the democratization of surveillance does to government power.  When we’re all recording, someone is watching the watchers.  Corruption, abuse of power, etc. all rely on the fact that authority figures can get away with crimes because they are more reliable witnesses in court than their victims are.  When everything is on the record — and not just the official record, but everyone’s record — police and government officials become compelled to act within the law.  While this may not be much of an impediment in truly totalitarian societies like China where the courts are as corrupt as everyone else, it’s a very strong bulwark of freedom in any society with an independent judiciary and a liberal tradition like the Untied States and Europe.  This is the next generation of surveillance — everyone sucking in light and sound from their glasses, or lapel pens, or even contact lenses, recording every moment of their lives on multi-terabyte devices that fit in their pockets.  It’s probably only 5-7 years away, and it washes away the current problems of a surveillance society and replaces them with new ones.

I think this cycle will continue for some time.  After all, once we’re past the era of democratized surveillance, computer graphics and artificial intelligence technology will improve to the point that ordinary people can modify their recordings to create perfect video of events that never happened, indistinguishable from the real thing.  What happens to recordings in law courts then, when they cease to be reliable evidence and become hearsay?  Tapes will become the new eyewitnesses, known to be unreliable and requiring corroboration from others.  When it becomes truly easy to make forged video, perhaps we will have emerged from the surveillance society from the other side — why bother to record anything when there’s no way to tell if it’s real?  Sometimes the only way out is through.

“It’s safe to go on the subway,” Skenazy replied. “It’s safe to be a kid. It’s safe to ride your bike on the streets. We’re brainwashed because of all the stories we hear that it isn’t safe. But those are the exceptions. That’s why they make it to the news. This is like, ‘Boy boils egg.’ He did something that any 9-year-old could do.”

She’s right. Most of us in our 30′s today remember growing up in the 1980′s — and it involved riding your bike across town, visiting neighbors, and being unattended for relatively long periods of time. Of course there were unsafe areas – there were parts of cities where people alone really aren’t safe — but these are the exceptions rather than the rule. Today, most parents seem to live in fear, convinced that there are criminals lying in wait to abduct children everywhere. It simply isn’t the case — it never has been, and crime rates are lower today than they were in the 80′s! We have not gotten any less safe, we have simply become so afraid that we think we’re less safe. And this culture of fear is damaging and contagious:

“Half the people I’ve told this episode to now want to turn me in for child abuse. As if keeping kids under lock and key and helmet and cell phone and nanny and surveillance is the right way to rear kids. It’s not. It’s debilitating — for us and for them.”

There are a variety of reasons that people believe that their children are under constant threat. Among them are:

• Vividness criterion: shocking anecdotes stick in our memory more than statistics, and they attract our attention. This is both why the media reports on every bad thing happening to a child, and why we remember them.
• Availability bias: when determining how frequently something happens, rather than turning to statistics we turn to how many cases of it we can remember. Since the news reports on every plane crash, but almost no auto accidents, we think of air travel as riskier even though we know the statistics show differently. Since in this age of pervasive news reporting we hear about crime more often, crime must be more common, even though the statistics show differently.
• Fundamental attribution error: when something happens, we tend to overestimate behavioral causes. So when a child is hurt, we assume the parents did something wrong, even if the event is random and exceedingly rare.
• We overestimate risks from intentional causes and underestimate risks from natural causes. This is probably related to the vividness criterion — someone deliberately hurting a child is more shocking than the child being hurt in a bike accident. The result is that we expect people to be malicious a lot more often than they are, and we think children are more likely to be hurt by criminals than by illness or car accident, once again despite statistics showing otherwise.

In truth, the violent crime rate today in the United States is less than half of what it was in the 1980′s! Most of our burgeoning prison population consists of nonviolent drug offenders, and most violent crime occurs in geographically delimited areas. Skenazy is right — the streets and subways of New York City are as safe as they were in 1963. Crime against children is even lower — the simple fact is that the overwhelming majority of humanity doesn’t want to hurt kids and is inclined to help and protect them.

It’s sad how many normal childhood experiences have been lost to this obsession with safety from small risks — just try to buy a chemistry set today even as an adult and compare it with what was available to young children 20 years ago (or to what’s in The Golden Book of Chemistry Experiments, now available pretty much only via BitTorrent, which begins by teaching children to use an alcohol burner to shape glass tubing. Today, a children’s chemistry set would never be allowed to contain an alcohol burner… or glass tubing.)

The key is this:

‘The statistics show that this is an incredibly rare event, and you can’t protect people from very rare events. It would be like trying to create a shield against being struck by lightning.’ ”

She said that people ask her how she would feel if one of those terrible and rare events happened to her son. “It would be horrible,” she said. “But you can’t live your life that way; you could slip in the shower.”

When faced by extremely low risks, the rational response is sometimes to disregard them. Sometimes the response to fear of something is, in aggregate, worse than the thing itself. We of course do the same thing with terrorism, and these same biases cause us to misallocate security dollars in industry, too (how many companies have tens of thousands of dollars in firewall and IDS hardware, but no disaster recovery plan?)

For all that we in the security industry picture threats coming at our companies from without, sometimes the greatest threats lie within. No external hacker has ever done the kind of damage that rogue insiders like Kerviel and Leeson are capable of, yet we focus on putting firewalls around our companies, rooting out worms and viruses, and securing our websites. While these are undoubtedly important, it is equally important to protect against internal adversaries — and often much more difficult.

The Problem of Trust

Companies must trust their employees — without the employees, there is no company. Accountants and traders are trusted with financial records, system administrators and information security personnel are trusted with access to critical files, physical and cleaning personnel are trusted with physical access to the facilities, and managers are trusted with company secrets, strategy, and intentions.

IT employees and developers are specialists.  As systems increase in complexity, those trusted with building and maintaining those systems are required to obtain knowledge further and further from most people’s understanding. Often, knowledge of how to build and maintain these systems also involves the knowledge of how to subvert them. IT engineers and developers know how their systems break down — they know their weak points, where they’re being watched and monitored, and where no one is looking. This problem isn’t unique to information technology — an aircraft mechanic probably knows how to sabotage a plane without leaving a trace, and members of police and military bomb squads are experts on explosives and what cannot be detected or tracked. And as recent news has demonstrated, traders in brokerages and banks know how the internal controls of their corporations work, and where they break down. Internal attackers are thus the most dangerous of all — they are already equipped with the kind of domain knowledge that an external attacker might need to spend weeks or months gathering.

Although we cannot entirely abandon trust in a company’s employees, we should consider where this trust comes from and whether or not it is warranted. Many companies sharply divide the level of trust and privilege given to employees vs. that given to contractors and vendors within their IT and development departments. The theory is that employees are allied to the company for the long term, and compensated with long-term benefits like retirement plans and vacation time that they will be unwilling to risk for short-term gain while vendors and contractors have less loyalty since they come and go as needed. However, in today’s IT world, is this really the case? I do not doubt that the contractors feel little loyalty for the company, but it is increasingly doubtful that the employees do, either. The average IT employee’s tenure at a corporation is now under 18 months — and thus they place little value on long-term benefits. Books like Corporate Confidential advise employees to view their employment relationship as, if not outright adversarial, at least mutually exploitative, to be dropped by either party as soon as it becomes in their interest to do so. Employees see that corporations no longer feel loyalty to them — the days of the job for life are over — and so loyalty to the corporation has gone as well.

Of course, lacking a strong sense of corporate loyalty does not lead most employees to embark on rogue-trading schemes, steal from their employers, commit electronic sabotage, etc. And even in the 1950s heyday of the organization man and the corporate family, some people took advantage of their employees and ran off with stolen fortunes. Some people are thieves and will steal given the opportunity no matter how well-treated they may be. Others are incorruptible, bound by their own moral code that would prevent them from stealing regardless of opportunity.  The vast bulk of humanity, though, is somewhere in between.

These employees are not likely to become attackers, and trusting them is a necessary part of doing business. However, this trust need not be absolute — we can trust, but verify. While we may not be able to prevent every internal attack, we can deter them, and make them less likely to occur. Steps can be taken to help keep most people honest, reducing both the incentive and the opportunity for theft.

Building Employee Loyalty

The days of the job for life and absolute loyalty to the corporation are probably over for good, inasmuch as they ever existed at all. However, the fact remains that internal attacks, particularly those not motivated by theft but rather simple vandalism, are much more likely to be carried out by disgruntled and angry employees than by content ones.

IT employees and developers are sometimes a strange breed — the sort of person that chooses to spend their time with technology is often different from the sort of person who chooses to be a manager.  So if it’s not a good retirement plan, an increase in vacation time after 5 years, and a promise of stability and long-term employment, what does build loyalty and goodwill with technical employees?

(Of course, any generalization about a type of person is going to be more accurate for some people than others, but I’ve found these to be useful rules of thumb for dealing with technology employees.)

• Autonomy. Figuring out how to do things is precisely what geeks enjoy about work — tell them what you want, not how you want them to achieve it.
• Isolation. Technologists, all told, are not very social. They do their best work when left alone. The cubicle is a horrible environment, giving you all the obstacles to collaboration of offices but without any of the privacy. Offices are ideal for most development work, the only exception being the early stages wherein there’s a lot more collaboration and brainstorming than actual coding.
• Technology. People who love technology want to be on the cutting edge. Using current technology makes them more invested in their jobs. In addition, it’s worth investing in the technology they’ll use every day — their workstations, displays, etc.

These are important, but will not, of course, make every employee perfectly happy. There are some things that technical employees have no patience for at all:

• Arbitrary or emotionally-driven decisions.  Using an older, inferior, or simply less appropriate tool (e.g. programming language, web framework) because “the boss likes it,” “we’ve always done it that way,” or “we’re a [insert product here] shop” really upsets them.  They need real-world reasons for using a technology, like technical benefits or budgetary limitations.
• Anything perceived as unfair. If employees feel they’re paid less than market value, or that someone else who’s not as good as they are is paid more, this breeds resentment. Trying to keep salaries secret helps not at all — today’s employees, especially younger ones, for the most part don’t understand why salaries should be kept secret, and thus will totally disregard any order to do so. It is important that technical employees see cause and effect in review processes, compensation, etc. and have a clear idea of how their performance is being assessed.
• Internal politics.  Engineers want to get things done, and they don’t care overmuch who does them — when engineering solutions, they’ll totally ignore interdepartmental boundaries. Having to worry about some manager’s fiefdom-building gets in the way of technical work and is relatively incomprehensible to them.

When it comes to performance management, technical employees need to be told, directly and clearly, how they’re doing and what needs improvement (if anything. ) Not being people-oriented, they often can’t read you. They don’t know if you’re happy with them or not unless you tell them, and they’re certainly not going to ask. While they deal extremely well with technical ambiguity — they love to solve problems, so an incoherent mess from a technical perspective is just a challenge to overcome — they don’t deal well at all with ambiguity in other contexts. Clear expectations and consistent feedback make their job simply another a problem to be solved, which makes it much more satisfying to them.  Without this feedback,

For many managers, these may seem like obvious guidelines — but they’re often problems in companies, particularly in IT and development departments of nontechnical companies. These factors mean a lot to many technical employees — often a lot more than traditional compensation. The best prevention against malicious insiders is to keep the insiders from becoming malicious in the first place by ensuring that the company earns their trust and respect.

Reducing Opportunity for Attack

Unfortunately, no matter what your company does, some people aren’t going to love their jobs. In addition, presented with the opportunity to steal, people are going to be tempted — and the greater the opportunity, the greater the temptation. Thus, it is important to reduce the opportunity for theft.

The traditional information security controls are often useless against insiders. The firewall provides no protection at all against someone already inside. Anti-virus and anti-malware systems matter not at all to someone who doesn’t need to gain access to a PC on the network, as they already have access legitimately. Network access controls are impotent against the domain administrator, who has the authority to alter access control lists at will. Obfuscation and hiding secret data provides no defense against the developer tasked with performing the obfuscation and hiding.

Fundamentally, a system designed to provide security always involves an implied question — secure from what? The vault door in a bank secures against burglars coming in in the night — not against the bank manager turning rogue. Alarms secure against armed robbers, not against tellers sneaking cash out of the drawer. Security cameras watch the tellers, but do no good against computer hackers or fraudsters. Reducing the opportunity for insiders to attack the company means considering how insiders differ from outsiders, and what security measures may be employed against them.

The primary advantages of an insider are twofold: knowledge and authorization. They have knowledge of the defenses — Jérôme Kerviel had worked in Société Générale’s internal audit and control department, so he knew exactly how they searched for and detected rogue trades. And they have authorization in that an internal attack often does not involve any sort of elevation of privilege — only an employee misusing their legitimate authority. Even the right to be inside the building, rather than having to break in through a firewall, is a measure of authority an outsider lacks.

However, insiders also have a disadvantage as compared to outsiders: proximity. It is often much easier to verify a suspicion that someone has committed a crime than it is to find the culprit to begin with. As is often depicted in crime dramas and classic mystery plots, investigators have a much easier time finding out who committed a crime when they have specific suspects to question and investigate than when a crime is committed by a random stranger with no known connection with the victim. Fingerprints and DNA evidence do little good if you have no suspect to compare them to. The same goes for electronic forensics — a hacker will often leave plenty of evidence of their activity on their own computer, and a monitoring device at their ISP would likely detect their activities. However, if the hacker is external, or even in a foreign country, as a security professional you’re unlikely to have any idea where their computer is, let alone have access to it. When an insider attacks, on the other hand, the traces can be very obvious. Attacks come from IPs within your perimeter, and your own monitoring equipment might have seen the entire attack end-to-end. The simple fact that there are only so many people inside the company capable of mounting an electronic attack limits the suspects and allows each to be investigated.

Smart insiders know this. While an outsider may believe he is able to hide from detection simply by being a needle in a haystack (how many companies really inspect all their edge firewall logs, even with an automated process?), an insider knows that he’s under observation and has a substantial chance of getting caught. Thus, he will almost always take steps to cover their tracks — steps an outsider would take, too, but the insider has the advantage of legitimate authorization to bolster his abilities.

Deterring internal attackers, then, involves neutralizing their advantages while maximizing their disadvantages. There is little to be done about their first advantage (knowledge of internal procedures), but actions can be taken to mitigate the power of legitimate authorization and to maximize the disadvantage of proximity.

Preventing Abuse of Legitimate Authority

Developers can modify the source code of your product — that’s what developers do. System administrators can change permissions on files and access secured areas — that’s their job. However, no one person should have the ability to do everything — this is the principle behind separation of duties.

Separation of duties enables legitimate tasks to be carried out while making it more difficult for these same powers to be abused. There are three basic controls that can be placed on a power to help prevent abuse:

• Authorization: determines if a person has the right to perform a task
• Recording: keeps a record of when, how, and by whom the task has been performed
• Custody: actually carries out the task

For example, imagine your company needs to deploy new code to a server in a datacenter. The person responsible for the authorization function sets the access control policies on the various machines to determine who has access. The person or system responsible for the recording function makes entries in change-control logs so that it is clear what has been done. The person with custody of the system actually places the new files on the server. In a small company — or one with poor internal controls — these could all be the same person.

If these tasks are all handled by the same person, the potential for abuse is very high. If this person wants to propagate malicious code to the servers that monitors transactions or even steals money from accounts, he can do so. He can authorize himself or another (possibly even a fake account) to make any change desired, carry out the task, and then erase or suspend the logs or records of not only the action but also the authorization changes.

On the other hand, if separate people are responsible for each of these tasks, none of them is capable of perpetrating a fraud on their own. This process could be organized as follows:

• A product team or business owner is responsible for developing the system and determines who can modify the code.
• A division of the IT department is responsible for all audit logging throughout the environment, regardless of who owns the particular servers.
• An operations engineer is responsible for actually placing code on the servers; the developers never have access directly to the production datacenter.

This makes fraud much harder. A member of the product team can tamper with the code, but has no way to actually get it into the datacenter. An operations engineer can access the datacenter, but lacks access to the code. And either one making a change leaves a trail — since audit logging is controlled by another team within IT, neither are able to turn auditing off or simply overlook suspicious entries.

Maximizing the Chance of Detection

Separation of duties limits the ability of a person with legitimate authority to abuse it. However, the is another thing that can be done to those people with the ability to abuse their authority from actually doing so — cause them to believe they are likely to be caught. Internal attackers know what audit and logging systems are being used within an environment, and they know where the “blind spots” in those systems are. Many criminals commit a crime only when the opportunity presents itself.  By eliminating failures in monitoring, we eliminate temptation as well as improving our forensic abilities.

Most of the systems used in a modern IT environment have extensive auditing capabilities. (Note that I am using the word “auditing” in the sense of creating an audit trail, not in the sense of some external consultant or accountant reviewing that trail.) Windows machines create an event log of almost everything that happens on them; in an ActiveDirectory domain, security events are also logged on the domain controller. UNIX/Linux/Solaris machines create various system logs, and have the ability to send them to remote machines as they occur. Databases like Oracle and SQL Server have fine-grained audit capabilities and are able to record every access to sensitive data and even detect potential data aggregation attacks. Web servers record every access, as do keycard-based entry control systems, VPN concentrators, firewalls, and a variety of network devices. An attacker, even an internal one, leaves a bewildering array of changes, alerts, and traces every time he does anything.

However, this does little good if no one notices the tracks! In addition, they are often ephemeral — a Windows Security Event Log will grow too large and begin overwriting itself in a matter of hours in a large corporation. If the logs are not available to investigate an incident, they might as well not exist at all.

One of the most powerful ways a company can prevent internal attacks is with the implementation of a Security Information and Event Management product. There are several of these on the market (I have experience implementing the SenSage event data warehouse, but ArcSight, Symantec, IntelliTactics, Computer Associates, and others have competing products,) but the idea behind all of them is to gather event data from a variety of sources and aggregate it in one place. This has two major advantages:

• The data is centrally managed by a separate custodian than the one that controls the various systems it came from, thus providing separation of duties.  The system administrators of the systems creating the logs cannot tamper with the logs.
• Data from disparate sources is correlated together, thus detecting attacks in progress and tracing attacks back to their source during an investigation.  Forensics is made easier and more effective.

Different SIEM systems have different advantages, and while all will provide separation of duties, some are better at handling massive data volumes than others. Likewise, the data mining involved in event correlation is still a black art in many cases, so different systems have different capabilities in that regard. However, just knowing that a SIEM exists, is monitored, and is out of reach for would-be fraudsters to tamper with can be a powerful deterrent against rogue employees.

Conclusion

The possibility of internal attacks is an unfortunate consequence of the specialization of modern society — those with the capability to build and maintain complex systems are often those best able to compromise and abuse them. However, good design of internal controls centered around separation of duties combined with judicious use of technical information-management solutions greatly reduces the opportunity for insiders to turn against a company’s infrastructure.

It turns out that I had nothing to worry about. Despite its title, there are only four paragraphs about resilience in the 41-paragraph article, and even those are wrong.

So what does Giuliani think must be done to defend a society from terrorism? Primarily a command-and-control response process combined with offensive attacks on the sources of terrorism.

With regard to prevention, Giuliani favors deployment of massive detection nets to fight against the attacks we’ve already faced — radiation and biohazard detectors at every port and point of entry. The cost-benefit ratio of this would be astronomically poor; as a free society with mostly open borders, there are a phenomenal number of entry points to the United States, and only very rarely (possibly never, so far, though the government would not be likely to tell us if it did happen) does anyone try to smuggle weapons-grade nuclear material or biological weapons through it. This isn’t to say that these measures would do no good, but they protect only against specific attacks and are obvious. They signal to terrorists “you can’t bring a nuclear or biological weapon through a shipping container in a port,” thus letting them know they should instead a.) use conventional weapons, b.) acquire nuclear/biological materials already inside the United States, or c.) enter via uncontrolled border space. If I, in three minutes, can think of three easy ways around a measure that will take billions of dollars to implement, it’s not very cost-effective.

He discusses the difficulties in information sharing between law enforcement and military agencies, clearly seeing these as an unalloyed negative. He’s right that there have been clear communications breakdowns, where these organizations had information that they were legally free to share, but chose not to out of myopia or the desire to preserve the institutional sovereignty of their silo. Despite the Central Intelligence Agency being founded to ensure all military and civilian intelligence agencies share information, it has in many cases become the most isolated hoarder of information of them all, and this is a problem. However, in other cases the obstacles to information-sharing are the civil liberties guaranteed by the Constitution. Giuliani has no issue with sweeping these away — this is, after all, the person who claims “Freedom is about authority. Freedom is about the willingness of every single human being to cede to lawful authority a great deal of discretion about what you do. You have free speech so I can be heard.” (That quote is not taken out of context in any way. He did not, however, go on to add “War is Peace. Freedom is Slavery. Ignorance is Strength.”)

Judicial oversight is not inimical to detecting and stopping international terrorism. Judges do not want terrorist attacks to happen, either; these protections exist to ensure that normal people are able to live their lives without constant monitoring. Surveillance is not unintrusive. Comamnd-and-control executives like Giuliani think that it does not matter if people are being watched, as only the “bad guys” will be prosecuted, but this simply isn’t true. First of all, people change their behavior when they know they’re being watched. It has a chilling effect not just on actually criminal behavior, but also on any behavior that people consider “socially unacceptable.” Surveillance drives everyone toward the mainstream center of society, homogenizing them; it creates the very opposite of a free society. (For a chilling illustration of this, I highly recommend Charles Stross’s sci-fi novel Glasshouse, one of the best and most terrifying books I’ve ever read, though it requires a high tolerance for transhumanist concepts.) Second, who watches the watchers? Even if Giuliani’s motives are pure (they’re not), and he wants to use these tools of warrantless surveillance, imprisonment without trial, etc. only against international terrorists, no one can possibly believe the entire law enforcement apparatus of a 300-million-person nation is entirely free of corruption and petty tyranny. Security has a cost — Giuliani looks only at how these measures benefit security, ignoring their unintended consequences. Security is of limited value — a terrorist attack is tragic but it does not end the world. We must not embrace “security at any cost” — instead we must consider security at a cost that we can bear, and most importantly, not allow the cost of security to exceed the cost of terrorism.

Giuliani also wants a “good Samaritan” law for people who report suspicious activity, protecting them from lawsuits. This is a terrible idea. Lawsuits are there to provide a cost for making a false of frivolous report — people will still report the man walking down the street with a pile of dynamite, but they think twice about reporting possibly-suspicious but almost certainly innocuous activity, like speaking Arabic in an airport, or loitering in a parking lot. Making reporting costless means you’ll get an inevitable excess of it, resulting in both the chilling effect of universal surveillance and a waste of law enforcement’s time. When people are encouraged to report everything unusual, you drown in reports and make people paranoid. This teaches people to react to the unknown with fear — that is, it accomplishes precisely what terrorists aim to accomplish. People reporting suspected terrorist activities should not be immune from lawsuits; rather, courts should decide whether the report was reasonable and take appropriate action. Often the reporters should be held blameless, having had a reasonable reaction that turned out to be incorrect, but doing so automatically makes filing false reports a simple way for private citizens to use the nation’s law enforcement apparatus as a means for private revenge.

Giuliani also calls for “tamper-proof biometric ID cards” for all non-citizens. As a security professional I can’t help but chuckle when anyone uses the word “tamper-proof.” But there’s nothing terribly wrong with this… except that it doesn’t do any good. We already know when people enter the country legally, and we identify them then; if they sneak in, they’re not going to have a “tamper-proof biometric ID card” any more than they have a regular ID card now. In addition, identity alone does not provide security. The fact that you know who someone is does you little to no good if he does not have a background in committing terrorist acts. And if he has a background in committing terrorist acts, why would you hand him a “tamper-proof biometric ID card?” Just deport him!

Giuliani supports fences around borders and stepping up guards, but claims to want to avoid turning the nation into a “fortress” in order to “deepen the connections between America and the Islamic world that will prove essential in prevailing over radical Islamic extremism.” On one hand, he’s on to something there — the only way to truly prevent terrorism is to eliminate the motivation for terrorism. Otherwise, 100% prevention is impossible — total prevention requires that you succeed every time, while the villains only have to succeed once. On the other hand, he simultaneously advocates precisely the foreign policy that creates that motivation — worldwide interventionism and American control and support of often-corrupt foreign governments. Now, the fact that a given policy makes people want to kill you doesn’t necessarily mean that that policy is wrong – but it is a cost of that policy that must be taken into account, and to claim that it will not have this effect is disingenuous.

Stepping up epidemiological surveillance and data gathering is the one good idea Giuliani has. Not only would it be helpful to detect bioterror attacks, but more importantly, it can help detect and contain natural pandemics. The emergence of a serious disease threat at some point in the future is a certainty, and unlike surveillance of people’s activities, this sort of surveillance has very little civil liberties cost.

Giuliani is obvious very proud of New York’s CompStat method of crime detection and prevention, given his desire to apply the same methodology to everything. For terrorism and border control, it makes some sense, as these are essentially law enforcement problems with a lot of parallels. However, for emergency preparedness it does not. Dividing up funding based on “need” determined by a statistical formula is absolutely certain to result in “gaming the system.” Emergency preparedness must be decentralized; there is no way for the Federal government to take care of it on a nationwide basis, or even to effectively coordinate and monitor it. Fundamentally, preparedness requires having appropriate materials on site and appropriate plans made, and no one can make those plans from afar.

Finally, Giuliani gets to the putative subject of the essay, resilience. He says, rightly, “Government should harness the inherent strength of the American people and the private sector in order to build a society that may bend—but not break—if catastrophe does strike.” It is somewhat ironic to hear this from Giuliani, who has just spent the preceding 30 paragraphs calling for increased central control of everything. His entire resilience proposal is as follows:

• Create government-organized response teams of private citizens who have been trained and equipped by government to respond to disaster,
• Pass a law shielding people from lawsuits if they are trying to help in disaster response, and
• Set government standards for how businesses, citizens, and charitable organizations should respond to disasters.

Ah, for every problem a government solution. This is precisely what resilience isn’t. A resilient society is one that responds to and recovers from disaster on its own — one that is not broken by disaster but continues to function mostly unchanged. The model of a resilient society is England during the IRA period: terrorist attacks happened, and life went on largely unchanged.

Western society is still phenomenally resilient, but not as much as it once was. You cannot build a resilient society using only government. A resilient society comes from a variety of factors, and these can do more to protect against the impact of terrorism than any technological or centralized security measure. They include:

• A culture of hope. People have to believe that every terrorist attack is an abberation, and that life will return to normal. This is what prevents a localized disaster from having repercussions on an entire nation for years to come; without this, with a culture of fear instead, the damage of a terrorist attack is multiplied a hundredfold.
• A citizenry that trusts itself. People must believe they are competent to solve their own problems, so the first reaction to a disaster is not “how will I get help,” but rather “what do I need to do?” Government cannot save everyone; if the able-bodied and passably intelligent people save themselves, government is freed up to help those who genuinely need it, and not simply those who abrogated their responsibility to plan.
• A populace that cares for others while still expecting them to take care of themselves. When disasters like Hurricane Katrina or 9/11 occur, there is an outpouring of charity from the populace to help. It doesn’t take government to solicit this; general benevolence will do, the desire to help anyone hurt by a disaster rather than using disaster as am impetus to hoard more for yourself and your tribe. However, people also must recognize the limits of charity, and be willing to go back to their own lives as time passes.

All of these are cultural shifts; we can’t impose them, and as Giuliani is running for head of government, it makes sense for him to talk about government actions. However, the statements he’s making are precisely what damages resilience. When all we hear from government is how they are expecting impending doom, and how government will save us when it happens, it does not teach us to have hope, trust ourselves, and help others! It teaches us to always anticipate disaster, do nothing and wait for help when it happens, and expect the government to do all the helping. Regardless of what the government does, this rhetoric from our politicians itself reduces the resilience of our society.

This is not an uncommon perception.  Many people who think nothing of handing over their credit card or writing a check when at a store or restaurant hesitate to use the same card online, regardless of communication protections (e.g. SSL/HTTPS), third-party assurances like the preposterously-named HackerSafe, or the size and stability of the vendor.  After all, it’s the Internet, there are bad people out there.

However, the perception just isn’t true.  There are two ways in which the Internet particularly helps thieves, though:

1. Once they’ve stolen an identity or credit card number, thieves often use the card online, as they don’t have to present themselves (and thus show up to witnesses and potentially security cameras) to use the card.  This is actually probably what the credit card company in my experience meant — not that the transactions are more dangerous, but that fraudsters often use stolen cards online.
2. Hackers stealing credit card information online often steal entire databases.  They don’t steal your credit card while you’re buying something online — they break into the online store and steal everybody’s card.

However, they could just as easily have broken into the servers of a brick-and-mortar store — it’s not the fact that you used the card online that makes it possible for them to steal it, it would have been just as at risk handing it to a cashier.

In many ways, it’s a lot more risky to make non-cash payments in person!  When you hand your credit card to a waiter or clerk or cashier, they could easily copy the number, expiration date, and CCv2 code (the three-digit code on the back than an online site often won’t even get.)  With a debit card, they have the opportunity to watch PINs being typed.  Whereas in an online store, only relatively few, well-paid professionals will have access to your data (system administrators, etc.), every $7 per hour sales clerk can see a hundred card numbers per day, and probably has significantly more financial motivation to steal them (although in my experience, the fact that someone doesn’t need money won’t stop them from stealing it if they’re the type to steal — just look at Michael Milken, who defrauded people out of hundreds of millions of dollars at the same time he was making hundreds of millions legitimately.)

Some people — usually those of us who remember the days before debit cards — eschew all these fancy online and electronic forms of payment and instead stick to good old fashioned checks.  After all, no one can possibly steal those!  They’re paper, and have your signature on them.  This is the ultimate in perception differing from reality — it’s hard to imagine a less secure way to make a payment than a paper check.

First of all, there’s the ease of committing fraud with checks.  A thief with a stolen check (or deposit slip) has all they need to take money from your account — the routing number and account number (found at the bottom of the check in MICR letters.)  Note that the thief doesn’t need any kind of ID… or a PIN… or a physical card… or a CCv2 code… or even to know your name.  No, the numbers will do.  What can they do with a stolen check?  There are three basic things:

• Order up a whole book of checks with your information and account numbers on them.  No ID is required to order checkbooks online.  They can then spend these checks anywhere, and the bank will process them — you probably won’t find out until your account is empty and you start getting NSF notices.
• Remove the amount and recipient from the check and write it out to themselves instead.  This is a bigger problem for institutional checks, which are often printed on a laser printer.  It’s really easy to remove laser-printed text from an offset-printed check — just lay some Scotch tape over the laser text, rub it hard with your fingernail, and peel the text off.  Then you can print out a new amount and recipient with your own laser printer, and it looks just like the real thing.  Chemical agents (“check washing”) can do this with ball-point pen ink, too, though it’s not so easy.
• Issue a demand draft (“paperless check.”)  This is what happens when you pay by phone with your checking account number, or use an automated bill pay service, or send money via PayPal.  Using your routing number and account number, money is simply removed from your account and put into someone else’s.  No authorization or authentication is used, your name is not even required.  Yes, really.  Anyone can do this from any account to any other account.  For a while, you used to be able to do this from a web site.

Second, there’s the difficulty in getting your money back or even stopping the fraud!  With a credit card (and to a lesser extent, a debit card), it’s pretty simple — you call the bank, say you did not authorize a charge, and the credit card company removes the charge.  It is then up to them to prove you did make the charge, such as by getting a signed receipt from the merchant and matching your signature.  So long as you report the fraud within 30 days, you are not liable — the worst the card company can do to you is to cancel your card (but you still don’t have to pay for the charge you didn’t make.)  In theory, you’re liable for up to $50, but almost no card issuers really charge this since it’s terrible customer service (“Sorry you were stolen from!  Give us $50!”)

With checks, the money is already gone.  If you report a check as fraudulent, there is no federal law saying the bank is liable — it’s up to the bank’s own policies and in some cases a hodgepodge of state laws whether they have to help you at all.  The bank may get back to you in 60 to 90 days (during which you don’t have the money, even if it was the entire contents of your checking account.)  You have to report the fraud on a paper letter, with a notarized signature, usually by certified mail.  What’s more, you have to prove that the checks were not authorized — the burden of proof is on you, not the bank or merchant — and you have to do it to each party from which you’re trying to reclaim money.  If a thief wrote bad checks in 20 different jurisdictions, you may be dealing with this for years.

Worse yet, you can’t stop the fraud from taking place.  The thief can keep writing checks on your account even after you’ve started reporting them as fraud, and even after you’ve closed the account.  Every time the thief writes a bad check on a closed account (the classic practice known as “paperhanging”, a favorite of Frank Abagnale during his criminal youth), your bank will reopen the account and send you an NSF notice.  You have to dispute all of these, too.  And finally, your account (and possibly your name) will go into ChexSystems (the equivalent of the credit bureaus used to check people’s checking account history) as fraudulent, which will make it difficult or impossible to get new checking accounts for many years.  On the bright side, it will make it harder for the thief to open accounts in your name, but that’s little consolation since he can keep using the closed one he already has.

From a security perspective, checking accounts are horrid.  They come from a day when authentication and authorization were unheard-of, and security came mainly from the idea that no one would figure out how to subvert the system.

What can you do to protect yourself?

• Don’t use checks.  If any method of payment is offered aside from checks, use that.
• Don’t use demand drafts, either — they’re checks.  Don’t pay by phone using a checking account number — use a credit/debit card.
• If you must write paper checks, use them only to pay bills, dealing with relatively trusted merchants.  It doesn’t make you totally safe, of course, but it helps some.  Use gel ink to write checks (it’s harder to wash), or a dot-matrix printer to print them (the impact-printed ink is nigh-impossible to remove.)  According to Abagnale’s The Art of the Steal, this makes check-washing nearly impossible (though ordering up new checks in your name still works.)  Incidentally, The Art of the Steal is a fantastic (and very short) book, and I highly recommend it to anyone interested in security — it gives a great view into the security mindset, looking at all parts of a system and seeing how it can be subverted.
• Don’t store any more money in your checking account than you have to.  You’ll still have to fight every fraudulent transaction to stop the bank trying to collect it from you, but at least you’ll still have your money while you’re doing it.

The sooner we move on from this antiquated and unsafe payment system, the better.

<cross-domain-policy>
<allow-access-from domain=”www.domain1.com”>
<allow-access-from domain=”www.domain2.com”>
</cross-domain-policy>

With this code present on a site, that site becomes accessible to any Flash application on domain1.com or domain2.com. Wildcards are allowed, including putting in the domain “*”, which means any site on the Internet can script against it. This is a legitimate thing to do if your site is a public API without authentication (e.g. Google Maps.)

However, it’s quite dangerous to do to a site that isn’t fully trusted. It is critical that crossdomain.xml not allow any more sites than necessary, because of the risk that relaxing the same-origin policy entails. If, say, an online bank were foolish enough to allow “*” or some easily-manipulated domain (i.e. one with a lot of user-uploaded content, like a social network or a forum), then anyone able to add content to that domain could upload a Flash applet that would connect to the bank as the user, using the user’s cookies, and perform whatever tasks it wanted — invisibly, with no sign to the user anything is going on. (Just because Flash apps usually have an appearance onscreen and are used to render graphics doesn’t mean they have to be; a Flash app is just a program.)

However, there are two serious problems with this method of relaxing the same-origin policy — and either of these can allow a malicious website to “relax” the policy of another site against its will. In each case, it involves combining another well-known attack (cross-site scripting in one case, DNS rebinding in the other) with the Flash security model to produce a vulnerability.

Cross-site scripting is the term for any vulnerability where user input is echoed back to the user (either the same user or a different user) from the site without proper sanitization. For instance, if I ask the user for his name, and he answers “<script language=”JavaScript”>alert(“Hello!”);</script>”, and from this I create a web page that says “Hello (name)” to him, he’ll get a pop-up on screen, because the “name” is actually code that, when it comes from the web server, is executed. This is a problem for the same-site rule because that code comes from the web server — instead of just popping up a dialog, it could have manipulated the web site and performed tasks on the user’s behalf! According to the same-origin policy, it’s “safe.” Now, in this scenario this sounds pretty harmless — after all, he’s attacking himself — but what if another page on the site allows any user to see a list of everyone’s name? Or what if it’s a forum and the user’s name is displayed on every post? Now that attacker’s code is running for everyone, in each case as themselves and able to take actions on their behalf.

How does this relate to Flash? Well, the crossdomain.xml file can be located anywhere on the server — the Flash applet chooses where to load it from. So if I can use a cross-site scripting attack to make a file on the web server that looks kind of like a crossdomain.xml file, I can tell my malicious Flash applet to load and apply that policy. (The filename doesn’t have to be crossdomain.xml — it can be kittens.jpg if I want. As long as it’s on that server, it can grant access to that server if the Flash applet knows where to find it.) There’s a good illustration of this attack on the Hardened PHP Project.

The other, and far scarier, attack is to use DNS Rebinding. The same-origin policy means you can only load from the site with the same domain name, like perimetergrid.com. But pages really load from IP addresses, not names. The DNS system translates names to addresses. However, the DNS system is federated — there’s no one master library of all DNS names. When you try to go to a site, your computer asks your ISP’s DNS server for its IP address, and the request is forwarded to the authoritative DNS server for that name. That DNS server then replies with the IP. If I wanted to (I don’t), I could set up my own DNS server that I control, have the root DNS point perimetergrid.com there, and then have my DNS server respond to any lookup up my site with any IP I wanted. The web browser would then load that page, and proudly display it as “perimetergrid.com,” because it trusts DNS.

Malicious DNS servers can do many horrible things. Imagine this process:

1. I load up a web forum. Someone has made a post with an embedded Flash applet.
2. The Flash applet loads from evil.com, and then it gets a crossdomain policy from evil.com (IP 6.6.6.6. Note that I don’t mean the real web site “evil.com”, but am just using the name to stand in for some malicious site.)
3. Evil.com, which is a malicious site with a malicious DNS server, responds with a crossdomain.xml that allows script from “*”. Now my Flash applet is allowed to script against evil.com.
4. The Flash applet now tries to load a web page from evil.com again. However, the malicious DNS server instead returns the IP address of your mail server, or your bank, or somesuch.
5. The Flash applet on your computer loads the page right up and can script against it. After all, it’s just evil.com, which it knows from step 3 is safe for scripting. It gets the data it wants, using your credentials, without your knowledge.
6. The Flash applet sends the data back to evil.com — which this time returned its real IP address so it could receive the communication.

This is really hard to defend against. We assume that DNS can be trusted, but DNS was not designed with security in mind and will never be secure. Evil.com could even have returned IP addresses inside your local network, behind your firewall and the browser and Flash applet would dutifully access them.

There are some techniques called “DNS pinning” that help mitigate this, by not allowing the DNS to return different IPs in rapid succession. The problem is that they break load-balancing — when you access a major online property with hundreds of servers, your request probably really is handled by many servers, all of which have the same name. Breaking this attack also breaks Google and Microsoft and Facebook.

Luckily, Adobe is aware of the issues and in Flash 9 has some mitigations proposed, including forcing socket access to get cross-domain policy by IP rather than by name. There’s a full whitepaper about it on Adobe’s site that’s a good read; Adobe is quite security conscious and has a mature security model for Flash, it’s just very hard to stop these sorts of design flaws in the web. Restricting socket access will help a lot — at least a malicious app won’t be able to port-scan behind your firewall and perform network attacks, though it could still browse web pages. This is an arms race between attackers and software companies that will continue quite a while.

1.) Wireless Networks Use Shared Media

Back in the 80′s and 90′s, most wired Ethernet networks were based on shared media topologies. In principle, when you plugged into an Ethernet network and sent a packet, the packet on the wire (the actual electrical impulses) went to every other machine on the network. Hubs were simple repeaters, broadcasting everything they received. Only when your signals reached the router at the Internet edge were they actually intelligently processed. Thus, every computer on the LAN got every packet – the network cards just threw away any packets whose destination address specified another computer. However, a hacker wanting to eavesdrop on others had an easy job – just toggle the network card into “promiscuous mode” (a hard task on some network cards and OSs, but completely trivial on others) and it will receive every packet, giving you a god’s-eye view into the network. Protocols were mostly unencrypted then, too – so you saw everyone’s email, their paswords as they logged into Telnet or IMAP, etc. You could also spoof traffic – since you saw the packets sent by others, you could simply send responses back claiming to be the recipient. So long as your response arrived before the real one, yours would be accepted and the actual response discarded as out of sequence. It was the golden age of network-protocol hacking. Such easy access to passwords made other types of hacking easy, too – once you had the password to someone’s UNIX account or email box, there was a very good chance it would work on all their other accounts, too.

Then it all changed. Shared media has significant disadvantages as it scales – since everyone is dumping packets onto what essentially amounts to a single wire, collisions occur when two systems transmit simultaneously. Both then have to back off, slow down, and retransmit their garbled packets. The packets are tiny (Ethernet frames are normally restricted to 1500 bytes or less), but if you have 100 systems communicating at once, collisions can become quite frequent. Plus, even in the late 90′s people were not totally unaware of the security risks – the fact that any student could read all the network traffic of everyone else in their dorm was not considered desirable by universities, for instance. Thus, Ethernet was converted over to switched media. Switches, unlike hubs, do not treat all ports as equal. Instead, they remember which ports they have received traffic from an address on, and only forward traffic to an address to those ports. Traffic is only broadcast to all ports when a switch has no idea for which port it is intended, or when a packet is actually marked as a broadcast. Now, when you put your Ethernet card in promiscuous mode, all you hear is traffic meant for you – everything else has been blocked by the switch. Suddenly, packet sniffers went dead – there was nothing to see anymore. Ethernet became a lot more secure.

But wireless changes things again. Wireless networks are shared media, and they are shared inherently, in a way that cannot be changed. Radio waves fly in all directions. There is no way for your laptop to transmit only to another laptop or an access point – all radio is broadcast. Thus, when you sit down in a coffee shop and turn on wireless, you begin broadcasting everything to everyone within range (about a mile, for attackers who have good antennas and high-power network cards.) The shared media nature can be mitigated somewhat via cryptography – if all the traffic to the access point is encrypted, it hardly matters if someone can eavesdrop since they can’t understand it anyway. But open access points are, by their nature, open – they’re either not encrypted at all, or they’re encrypted in such a way that everyone is using the same key. Once the hacker has the key (either by cracking it, which is not hard on most Wi-Fi networks, or by simply paying as a legitimate user of the wireless hotspot), they can read all the traffic just like in the hub-based glory days of old.

There are solid wireless encryption systems. A network based on WPA2 with a strong passcode is quite secure, about as good as a wired connection (keeping in mind that “as good as a wired connection” is not an absolute guarantee of safety, either.) Modern encryption systems like AES coupled with 802.1x certificate-based authentication can make a well-engineered corporate wireless LAN quite safe.

But hackers don’t love well-engineered corporate wireless LANs. They love the terrible ones in coffee shops and bookstores and your house. On these networks, they can listen to all traffic, they can spoof traffic, and they can even kick people off and hijack their connections, or edit their connections on the fly. The “airpwn” attack from a DefCon 2-4 years ago was particularly amusing; using two wireless cards, it would sniff everyone’s HTTP traffic on one connection, then on the other card spoof responses to all requests for images, substituting other images (such as the hacker group’s logo, or more unsavory fare like the infamous goatse.cx site; that is not a hyperlink on purpose, do not navigate to that URL as it is not safe for work or, indeed, for anywhere else.) The result was that one laptop at a security conference was able to dynamically edit the HTTP streams of everyone else there – hundreds of people. That’s the kind of power a hacker can have on a shared-media network. In addition, on these sorts of networks, it’s trivially easy to hijack sessions. This means that on any site that uses HTTPS for authentication only, but then HTTP for the actual service (a category that includes all of the Google apps like GMail, as well as all the Yahoo! and Windows Live services), a hacker gains full access to your account if they overhear any of your wireless traffic.

The only truly safe way to use a public wireless hotspot is to use it only to VPN to a network you trust. Anything else is dangerous.

2.) Wireless Networks Provide Plausible Deniability

The legal system is not terribly friendly to hackers. Even innocuous and non-destructive activity, when applied to networks you don’t own, is often illegal. Now, for the most part hackers don’t worry overmuch about getting caught – if you don’t cause more than $5,000 in damages, the FBI won’t get involved, and the average local police department is about as capable of investigating sorcery as computer crime. However, when a hacker does worry about legal prosecution, a public wireless network is the next best thing to Siberia for where to commit a crime from.

When you do anything on the Internet, a host of servers are recording your activity based on your IP address. IP address, however, is not necessarily long-lived. Depending on how you access the Internet, your IP address might change every time you plug your computer in, or reboot, or move from building to building. Thus, investigators must be able to tie the IP address they know committed a crime to a specific, physical person.

With wireless, this is a problem. All the sites being attacked don’t see the IP address of the hacker – they see the IP address of the wireless access point. Thus, they have to subpoena the owner of the access point and demand to know who was using it. In the case of a well-designed corporate wireless LAN, they can check their logs to see which 802.1x certificate was using that IP at that time, and uniquely identify you. But in the case of a public hotspot, there probably aren’t any logs at all! They’re completely incapable of giving you up. And even should someone who was there say “I saw a shifty guy in the corner using a laptop!” to the police, that’s not going to be enough evidence. And if there are logs, they will tie your traffic to your MAC address, a unique code assigned to your network card at the factory.

Most people think MAC addresses cannot be changed, so it uniquely identifies your network card. If the police get a hold of your network card, they’ve caught you. This is actually totally untrue. Many network cards will allow you to change the MAC address to whatever you want (in Windows, it’s on Connection Properties -> Configure -> Advanced -> Physical Address), though this is entirely up to the network driver. Many Windows drivers block this functionality, thinking that users don’t need it. On Linux, however, the network drivers have been written by geeks, who operate under the impression that users need everything. Thus, on Linux systems changing your MAC address is as simple as typing one command (“macchanger eth0 00:11:22:33:44:55″), and you can even configure the network stack to give you a new, random MAC address every time you connect to a network.

As a result, a trail that leads to a wireless hotspot is basically a dead end for investigators. They get nothing but a fake MAC address that could correspond to any computer within a 1-mile radius – the hacker might not have even been in the building. Hard to get “beyond a reasonable doubt” out of that.

And those are why hackers love wireless networking. It’s like the 80′s phone networks, where a hacker can be a ghost in the machine, undetectable, and with tremendous power. It’s a dangerous place.

You might wonder, if wireless networks are so anonymous, how hackers ever get caught. Actually, there are three main ways:

1. They get stupid, and brag about what they did.
2. They get stupid, and while performing their illegal activities they also do something that identifies them, like log into their email account.
3. Investigators follow the money. We don’t catch you breaking into the bank, we see where you sent the money to. We don’t catch you stealing credit card numbers, we catch you using them.

Luckily for those of us in the business of investigating and preventing computer crime, wireless networks won’t save criminals from their own stupidity, and you can’t send cash through the airwaves.

This sort of security flaw is a major problem with copy-protection drivers like SafeDisc; this is also the same basic issue as caused all the controversy over the “Sony Rootkit” of 2005.  Fundamentally, the purpose of any copy-protection or DRM system is to protect data from the user.  Thus, it is attempting to create a security boundary where none exists — to prevent the user, possibly a user with administrative privileges, from performing certain manipulations of data entirely under his control while allowing other manipulations (e.g. watching a film, playing a game, listening to a CD) to continue unhindered.  The problem is that it’s just data — what copy-protection and DRM vendors are doing is the equivalent to my trying to write a book, with normal ink on normal paper, that you can read but not copy, even by hand.  It can’t be done; there is no inherent difference between reading-to-read and reading-to-copy.

So instead, DRM and copy-protection vendors, like Macrovision, create a system that runs at a level of privilege above what the user can normally achieve — on a Windows machine, at least NT AUTHORITY\SYSTEM privileges, but often kernel mode drivers.   This driver then sits, Big Brother-like, above the user, watching his activities, and preventing “illicit” operations.  Meanwhile, while being immune to manipulations by the user, this supervisor must take orders from data — that is, Macrovision SafeDisc must be told by a game that it should check for copy protection and stop the game if it fails, while the Sony “rootkit” must be told by a CD that it should allow playing but stop copying.

Thus, the user’s computer is put into a rather odd state — the user doesn’t control it, a piece of supervisory code does.  And if that piece of code is flawed (as it was in both the Macrovision and Sony cases), attackers can write malware that issues instructions to that supervisory code, imitating “protected” media.

If you’re a non-Administrative user (such as almost all Vista or UNIX/Linux users, but only a few Windows XP-and-before users), you are protected from running code that does certain potentially-harmful things to your system.  You can’t write to the Windows directory, or modify installed programs, or register a driver.  However, these copy-protection drivers supply an end-run around this protection — you can supply data to the copy-protection driver (after all, you have to be able to tell it to check up on you), which means that any malware you run can also supply data to the copy-protection driver.  And since it runs with greater privilege than you, it can do all the harmful things you supposedly can’t.  Copy-protection drivers, to make content more secure for the copyright-holder, make your computer less secure for you.

From a theory perspective, the problem here is that there is no security boundary (a line which code and data cannot cross without being subjected to a security policy), on a general-purpose computer, between an administrative user and all the data on the system.  This is what the copyright-holders want, but it’s not really possible for them to get it.  All of these systems can be circumvented by simply placing a new supervisor above the one added by the copyright holder (e.g. run the system in a virtual machine, or with a kernel debugger attached, or in the most extreme scenario, just walk through the code execution by hand, choosing to ignore instructions you don’t like until you get a fully unprotected data stream.)  Thus, they fake it, in ways that make the system less secure, simply to make it more difficult for a nontechnical user to get the unencrypted stream.  The result is a simple arms race between copyright-holders and hackers, which has a side effect of harming innocent users by making them increasingly vulnerable to malware.

If a skilled attacker has unrestricted physical access to a machine, they can acquire all the data on the machine.  Database encryption can help quite a bit — unless they also get the system that contains the key to your database.  Since in many cases the database server sits in the server room right next to the middle-tier server that encrypts it, this is not necessarily much of a protection against true physical access.

To most people, it seems like it would be difficult to simply talk your way into a private facility and get left alone with the mission-critical servers, but really, I’m not surprised that TraceSecurity reports no difficulty getting abandoned anywhere short of a bank vault.  Daily life is based on trust — we assume that people are what they say they are and appear to be, because life is is impossible otherwise.  In addition, we encounter legitimate people so much more often than criminals that in a sense a criminal is a surprise every time.

Anyone who’s worked in a corporate office with badge-based security knows how easy tailgating is.  Wait for someone to swipe their badge and walk in right behind him — your chances of being challenged are very low, since people do it all the time and even people who originally challenged tailgaters have usually gotten tired of it within a few months (since it’s basically always just someone too lazy to get their badge out.)  What TraceSecurity does is pretty similar, with a dose of social engineering — just dress up as someone who belongs there, pretend to be someone who belongs there, and walk right in.

They tend to prefer pest-control services or fire marshals for their disguises (though they have to jump through a few legal hoops to dress up as a federal agent without committing a crime), though other penetration testers I’ve encountered favor telecom vendors.  If a company’s ISP is Verizon, they will think little of a Verizon technician showing up, and probably happily let him into a wiring closet or server room.

The bigger difficulty than getting in is getting left alone.  This is one area where simple surreptitious entry, like tailgating, is better than dressing as someone like a pest inspector or fire marshal who, in their normal jobs, you would not likely leave alone anyway.  Still, people at corporate offices are busy.  If one is following you around, dawdle long enough in non-sensitive areas and I’m not terribly surprised they get tired of wasting their day escorting you.  By the time you get to the server room, they swipe you in and get back to work.

This sort of penetration test makes the news, though, because it’s interesting and unusual.  Even TraceSecurity, which the article makes sound like specializes in this sort of assessment, offers a wide array of other security services.  A career exclusively performing on-site physical/social penetration tests may be limited to characters in Sneakers.  The main reason, though, is the perception of risk.

People see the security measures around physical intrusion.  The servers are in a locked room, in their locked building, surrounded by people who know each other, so getting in must be difficult.  On the other hand, most people have no idea how to hack into a server from the Internet, and thus have no way to gauge the risk other than the availability heuristic — and we hear about online break-ins and data leaks in the news all the time, so it must be easy.  This makes people inclined to overestimate the risk from network attacks (though, honestly, the risk is pretty high) as compared to from physical intrusion.

This said, another thing preventing physical attacks on servers is not the difficulty of the attack, but the simple dearth of people willing to carry it out.  Breaking into a building to steal something “feels” like crime, while just typing code into your keyboard is probably more easily rationalized — it’s the same reason why people who would never shoplift a CD happily copy music, despite the acts being legally similar.  Of course, there’s probably also a higher likelihood of getting caught in the physical intrusion — people have seen you.  This is a case where prevention is very hard but detection is less difficult.  It takes a special sort of person to be caught red-handed trespassing in a server room and still keep their cool well enough to get out of the situation without arrest.  Admittedly, this lowers the actual risk of attack — it reduces the threat, despite the presence of the vulnerability.

The usual solution posited to this sort of attack is user education — just teach people to be vigilant, ask to see badges of people they don’t recognize, verify the identity of service providers, call the fire department and ask if the fire marshal should really be here, etc.  However, in truth, this just won’t work.  TraceSecurity couldn’t get the bank manager to leave them alone in the vault — because people standing in a vault think about security, and know that a normal person might be tempted to steal when surrounded by cash.  But in a server room, where the potential theft may actually be much greater, it’s not what’s on their minds, and simple user education isn’t likely to change that.  Human beings trust each other, and criminals learn how to cultivate and play on that trust — a security awareness program isn’t going to change human nature.  What is necessary here is to worry less about prevention and more about detection and response.

When data is extremely valuable — say, personally identifiable information with credit card numbers, in bulk (20,000 records or more) — it shouldn’t be stored in a corporate office server room anyway.  You wouldn’t store $200,000 in cash in a closet in your office building, so don’t store something of equivalent value and easier to carry there, either.   Colocate the server in a secure datacenter, where it’s surrounded by people who are aware of security and under guard and camera.

However, for less-valuable data, instead of thinking about how to keep people out — a task that may be impossible — think about how to know they’re there and recover from the breach.  Methods like camera surveillance deter crime by making intruders believe themselves (rightly) more likely to be caught.  Use monitoring tools on computers to be able to determine if someone has gained physical access to them (an action which tends to result in the server going down for a short time) and investigate such alerts immediately.  Even procedural efforts like requiring people to sign in and out of server rooms can be helpful — if the sysadmin has to write down that he admitted three people to the server room and left them there, he’s more inclined to have security come to mind, and more likely to speak up later when you realize a theft has occurred.  In addition, do use encryption on valuable data — this ensures that if an intruder does walk off with the database file (or the hard drive it’s on), they’re less likely to be able to make use of it.  It may not be enough in the case of someone who breaks into your building and has all night to figure out where the key is, but it may be enough for the person who has 5 minutes to copy everything they can to a thumb drive before you come back with their cup of coffee.

Of course, there’s not much motivation for government to reduce these overzealous “awareness” programs, either.  A paranoid populace is always supportive of more government intervention to “protect” them, and making everyone into a criminal makes social control quite easy, since there is no one not subject to arrest, only the people you haven’t chosen to arrest yet.

Terrorism can never be absolutely prevented because terrorism is easy — it is a sad fact of chemistry that many things explode, and there are many ways of being dead.  A free society can only prevent crime because criminals have something to lose — people acting in self-interest do not want to die or go to prison, and a free society must fight crime via punishing criminals after the crime has been committed.  Since terrorists of the current radical Islamic model aren’t deterred in this way, we are deprived of our normal security responses and forced to try to fight with prevention only, rather than the standard responses of detection & punishment.  To truly eliminate this sort of terrorism requires changing the culture from which it emerges — removing the “feed stock” of terrorist organizations by giving people something to live for.  This is not a short-term project.
The proper response of a free society to terrorism is not “prevention at all costs,” but rather prevention where the cost is justified and resilience where it is not.  Western society is distributed, and has a phenomenal depth of resources that is absent in many other societies — our culture is, in short, extremely hard to destroy.  As catastrophic as the September 11th attacks were, your chances of dying in a terrorist attack remain smaller than your chances of dying of heatstroke, inhalation of a foreign object, or drowning in a swimming pool; our society is threatened not by the direction damage of terrorist attacks but by the response those attacks cause in us.  Some threats are direct and obvious enough that mitigates them makes sense, but for many threats the rational response is to accept the risk; that is, recognize that the risk is there, understand that the chances of it affecting you, personally, are nearly nil, and that absolute safety does not exist.  We need to go on about our lives, and work to recover from attacks in the same way that we recover from natural disasters.  When a disaster happens, we mourn, we help the people affected, we rebuild the damage — but we do not change our way of life because of them.  Somehow, we think that human-caused disasters should be entirely different, but this is not necessarily the case.

When measuring the error of a detection process, there are three pertinent statistics — Type I error (false positive, detecting something that isn’t really there,) Type II error (false negative, missing something that is there,) and crossover error rate (the error rate at which the rates of Type I and Type II error are equal — essentially, the minimum error of the process.) We normally think of trying to minimize the crossover error rate — after all, we want detection processes that are as accurate as possible — but sometimes one sort of error is objectively worse than the other, so we will choose, say, to minimize false negatives even if this leads to more false positives being detected.

For instance, it is very annoying if the fingerprint scanner used to log onto your laptop fails to recognize you routinely, requiring you to use the reader repeatedly. Thus, too many false negatives annoy the user. Of course, if it let everyone in, that would be even worse, but we’re willing to run the risk that somebody with fingerprints sort of similar to yours might be able to get in if it makes the thing work better. On the other hand, if the fingerprint scanner is on the vault with the nuclear weapons in it, false positives are very bad, while a false negative is really not too terrible — you probably don’t need to access the nuclear weapons very often, so if you need to swipe your finger four times to get in, that’s okay. In this process, you’ll optimize to minimize Type I error, even if this raises your rate of Type II error and your crossover error rate.

However, what people often fail to recognize is that error rates become very oddly skewed when the thing to be detected is exceedingly rare. For instance, we currently have many processes in the country designed, ultimately, to detect terrorists — border guards, profiling, no-fly lists, etc. These all have error rates — sometimes, they would miss a real terrorist, and to the dismay of civil libertarians and air travelers everywhere, sometimes they “catch” innocent people.

A Type I error rate of 0.001% sounds pretty good. Imagine you have a terrorist detector with a Type II error rate of zero — it always detects real terrorists. And its Type I rate is only 0.001% — it generates false alarms only one time in 10,000. Sounds great, doesn’t it? We should make use of them immediately! If this thing points out a terrorist, you’ve got the right guy. The government can proudly advertise that their detector is 99.999% accurate.

But wait… there are 280 million people in the United States. How many are actual terrorists? I hope not very many, but let’s be paranoid and imagine there are 1,000 lying in wait (though I’d wager if there were, we might have seen at least one terrorist attack on U.S. soil sometime within the last 5 years.) This means that we’ll be scanning a real terrorist — and set off the alarm, since our terrorist detector has a false negative rate of zero — 0.000036% of the time. Our false positive rate is 0.001% is actually more than the rate of real terrorists in the population. In fact, while a negative from our terrorist detector is right every time, a positive from it is wrong 97% of the time. In other words, if the alarm goes off, you can be 3% sure that you’ve got the right guy!

Doesn’t sound so good put that way. When the alarm goes off, you can be almost certain (97% certain, at least) that you’ve got an innocent man. The problem of detecting a rare thing without false positives is actually quite difficult.