The cutover to the new server seems to have gone smoothly. Looking at the server logs on the old server this morning, I saw that the only traffic I’ve had on the old server was the AskJeeves crawler.

Which is a good thing since it seems to not have come back from rebooting after I installed an updated kernel earlier this morning.

I’ll have more Risk Management thinking goodness in the week ahead, but it’s tough to say exactly when it will appear due to a some unexpeted upheavals in my schedule. I’m not complaining since it’s all Good Stuff, but it would have been nicer if I were leaving Chicago during winter to do it, rather than now when the weather is getting really good.

Oh, well. As I always say when I conclude my whining, “There are worse problems to have.”

I finally got around to moving this blog off of the old, failure-prone server at my house into a proper hosting environment. If you’re reading this, then you’re seeing the new server.

This should resolve the intermittent connection issues and outages that have been plaguing me for the past couple of months. If you have any problems with the new server, let me know at cubicle at halfcat dot org.

In addition to the traditional methods of authentcation (”something you know, something you have, something you are), we should add the one aspect of authentication that we almost always forget about: “Somewhere you are.”

Consider methods of authenticating yourself for access to your Local Area Network:

• VPN Access: Generally two Factors, something you know (username/password) + something you have (number-generating key or client certificate, usually on some sort of mobile device*)
• Remote Business Partner: Either VPN Access; Private line connection (somewhere you are); or LAN-to-LAN tunnel: When built with client certificates, becomes the preshared secret (something you know) + somewhere you are (a specific remote IP address or subnet at the far end of the tunnel).
• 802.1x: Take your pick of smart cards, crypto certificates, PKI, one-time passwords, usually associated with a specific device. Becomes a mix of something you know munged into something you have*
• Walk up to a port and plug in: The only thing you need to be is in (or, in the case of unsecured wireless, near) the building (somewhere you are). This may or may not involve some level of pre-authentication (i.e presenting a keycard to a guard and/or electronic reader), depending on time-of-day, physical structure of the network, diligence (or lack of) regarding physical security measures, etc. This probably describes 99.9%+ of the network access security in use in the corporate world today.
• Dial-back modems: Most have either forgotten about them or never used one, but once upon a time, I could only get remote network access by dialing into a modem bank, authenticating myself (something I knew), then hanging up and the system would call me back at a pre-determined number (Somewhere I was). That number could only be changed by going to the security department in person, and filling out a form, which they would then process. That place was pretty paranoid, but it was not without reason–there was a lot of really valuable intellectual property contained there and lot of people actually trying to get their hands on it.

Just something to think about…

* We tend to rationalize cryptographic certificates as “something you have,” but it’s really a “something you know” which is too hard to remember so the device it’s stored on becomes its proxy and thus “something you have.”

Wired has an article describing a researcher’s efforts to implement fingerprint-locked DRM for DVD’s.

This may be one of the dumber ideas I’ve heard yet. Why? Two words: movie rentals.

The studios make tons of money off of their agreements with Blockbuster, netflix, etc. They would have to provide unlocked DVD’s to those entities. And since most of the people I know who rip lots of DVD’s use Netflix to supply them with the movies they copy (for personal use or piracy is irrelevant here), this makes no sense whatsoever.

At best, it’s a solution in search of a problem. Encryption doesn’t stop piracy–pirates either make bitwise copies of the movies or run a “second shift” in the same factories and using the same masters as the legitimate copies. Cracking CSS was about providing a software player for Linux. The pirates never cared.

In reality, this is the sort of DRM that becomes so restrictive as to pretty much ensure that even the most law-abiding citizen is going to become a pirate out of sheer necessity.

Going back to the old adage that security is the tradeoff of effectiveness versus convenience, with the correct point on that continuum being the one where the risk of people creating bypass mechanisms is greater than the risk from the threat the countermeasure is intending to mitigate.

This solution skews so far in the wrong direction that it’s surprising that it’s even being taken seriously. I mean, consider the holes in this approach that come to mind as fast as I can type: How many fingerprints would be “too many?” If I buy the DVD, would that mean my wife couldn’t authenticate to the DVD player? What about my daughter? How would COPA affect gathering her biometric information? How about the babysitter? What about existing laws regarding fair use?

The list goes on and on. My point is made. When it comes to DRM, I think Forest Gump said it best, “Stupid is as stupid does.”

(Thanks to blog-on-nymity for slipping this into my world via the miracle of rss)

An interesting thing is happening right now with VOIP and e911 service. The FCC has mandated that VOIP phones must support e911 which means that the VOIP companies must be able to tell emergency services personnel where any given VOIP phone is at any given point in time, including “soft” phones (software VOIP implementations running on laptops, PDA’s, etc).

When I set up my VOIP service, they asked me what address I wanted to use for e911. I gave them my home address since that’s the “default” location for my usage. I also asked about a softphone client for my laptop and if it would support e911. They told me that it would be able to call 911 but would not be able to report my location for me. “I’ll accept that risk,” I told them.

This is not rocket science, but it is allowing me as a consumer to make a risk decision that was traditionally made on my behalf by the FCC: Should my phone be able to tell 911 dispatchers my physical location? If I’m not okay with that, then maybe a soft phone isn’t the right choice for me. But if I’m technically astute enough to ask for a softphone, then odds are that I’m probably capable of understanding that e911 is based on delivering information from a database which maps phone numbers to addresses rather than magic.

Now the funny thing about this is that the FCC mandated similar requirements for 911 capabilities for cell phones a few years back. But according to Consumer Reports:

One in three people who own a cell phone say they bought it mainly for safety–to have if they need to call 911 from the side of the road or a dark street at night. And at least one-third of all 911 calls are now made on cell phones–just under 57 million calls in 2001, according to the Cellular Telecommunications & Internet Association (CTIA), a trade group.

…

All the phones we used in the tests have analog and digital capability. According to FCC registration data, only one of the phones we used was made before the 911 calling regulation took effect. The manufacturers certified that the phones meet all applicable FCC rules.

In Steuben County, we made 14 test calls on 12 different phones with accounts from Sprint and Verizon. In Sullivan County, we made 7 test calls on 6 phones with accounts from AT&T and Cingular. Overall, of the 18 phone-and-service combinations tested, 9 calls failed to connect to 911. In every instance, there was a strong signal from another carrier the phones could have used.

So while 1/3 of all 911 calls are being made from cell phones, 50% of the calls made by consumer reports failed to go through. Elsewhere in the story, they mention that in a statistically valid survery, 12-15% of 911 calls had failed at least once and 4% were never able to get through.

I think that the FCC has some explaining to do if they’ve got time to worry about VOIP’s effectiveness at supporting e911 address information when the systems that produce 1/3 of all 911 calls have a 15% failure rate on connecting at all.

So I have three theories on how this decree came into being. Any or all of them may be correct–it’s not an either/or problem.

Theory #1: The FCC is concerned that it may suddenly find itself irrelevant if it doesn’t assert firm control of VOIP before it becomes too big to move via administrative decree. This may be true, but I don’t see this as being the sole reason they are making this move now.

Theory #2: The FCC is genuinely concerned that widespread VOIP adoption as a PSTN alternative is impacting the effectiveness of 911 service. There were anecdotal tales of inadequate integration of VOIP service with 911 call centers but much of this seemed to lie with the ILEC’s (Incumbent Local Exchange Carriers, such as SBC or Verizon) refusing to allow the VOIP providers to integrate into the e911 gateways that they provide to municipal emergency service centers.

If theory #2 is correct, then I would have expected to see the FCC address the integration problem by mandating that the ILEC’s work and play well with VOIP providers when it comes to e911. The fact that there seems to be no mandate to do so makes me wonder how realistic this theory really is, which leads me down my usual cynical path to #3…

Theory #3: The ILEC’s see this as a point of weakness in the VOIP business model which they both control through their contracts to provide e911 services and which plays well in Peoria: “If you have VOIP, you can’t call 911! Ooooooh! Scary!” As such, I can see the telecomm lobbyists deciding this is a good point to call in a favor or two over at the FCC to create a little favorable Adminstrative Law.

Once upon a time, these same discussions were had regarding location awareness and 911 support through cell phones. When that happened, I don’t recall the ILEC’s–who by and large are now also the wireless carriers, at least in the US–being nearly as concerned that American’s phones should be able tell the 911 operator their location. Given that their actions would seem to indicate that they don’t care if the call even gets through–a huge assumption of risk on their part since the opportunity for lawsuits is so ripe when someone winds up seriously harmed or dead because they couldn’t call 911 on their cell phone.

Whichever it is, all the mailing list chatter discussing the feasability and risks of making DHCP location-aware is completely missing the point–making softphones location-aware is not the solution. Educating people about the risk management decisions that are being made by the FCC, ILEC’s, wireless and VOIP carriers on their behalf may lead to a viable solution, however.

In closing, let me suggest my personal solution: Don’t go mucking about with DHCP or other existing protocols existing potential privacy invasion holes. Instead, define a separate Web Service which provides local address information for a network. This could be built into personal firewall/NAT devices, run as a service on DHCP servers, etc. If you want to provide accurate information, then you’ll get accurate e911 support. If you don’t then you assume the risk of having the police show up at 1060 West Addison when you dial 911, but the choice is now up to you.

So long as it was easily available to the softphone, this would provide the same level and quality of e911 support as we get from corporate PBX’s today. If the FCC mandated that the ILEC work and play well on e911 integration. Heck, it could query the PBX if that’s how you wanted to architect it–that would seamlessly integrate it into our existing e911 architecture here. If I dial 911 from my desk phone, they get the address of the building but they also get my facility’s global security office number so they can coordinate with our local responders.

From the summary of
this account of soldiers deploying to Iraq…

Like I said, I do like rules, rules that make sense. But this is a form of institutional insanity, and someone needs to do an intervention. When a soldier in full uniform, in the company of nothing but other soldiers, is allowed to retain the bayonet for his M-16 and his M-16, yet has to give up his nose hair clippers, we’ve moved into the realm of scenarios that even the writers of Saturday Night Live would reject as way too lame.

Yet we accept it as government policy, in the name of “security.”

Did they give an intelligence test at the TSA and everyone who passed was shown the door?

Context is everything. If you don’t believe me, try this exercise. First, go watch the movie “Red Dawn.” Heroic American insurgents battle oppressive Russian and Nicaraguan foreigners. Powerful visual imagery, craptastic action sequences, and stars you had forgotten were ever that young. If you remember life during the Cold War, it’ll almost make you long for the simplicity of hostile superpowers (Other than the threat of nuclear annihilation, of course). And if you feel guilty spending two of your life on it, rationalize it as Risk Management Research.

Now, compare that to the current US Occupation of Iraq. Who’s the hero and who’s the oppressive foreigner now? It’s amazing how such seemingly-simple concepts as Good and Bad can can completely change depending on the context.

Strangely enough, nCircle’s blog just tackled this issue as well, although more from the angle of evaluating results:

Why do I worry so much about the context of everything? Was it nature or nurture that brought me this hyper-curiosity? The educational system that I experienced and for that matter, the one that my children experience does not make it a priority to question everything. The teach-to-test attitude just makes me want to vomit-the-lunch. My child is being presented history in the context of what point of view? What questions should I ask about what I am learning? How should I explore the spatial and temporal relationships? Enough of this education vendor bashing, what am I going to do about it?

I asked my kid, if I tell you that tomorrow, you will have a headache, is that a positive or a negative thing for you? He says “Dude, that would suck, totally negative dad, Duh!” I replied “You have much to learn my young Padawan” in my best Yoda voice. The problem I explained is that you don’t know the context of this headache. You may be experiencing a headache as a result of regaining consciousness after a really bad spill on your skateboard. Realizing that anything north of a coma was a good thing I now earned enough of his attention to give him a few other examples for him to chew on.

Or you might be experiencing the headache as a result of a really excellent night of partying, in which case it might be small price to pay. To add another variable to the situation though, throw in a four-year-old roaming into your bedroom at first light to drag your hungover butt down to the kitchen to make her some pancakes. Is the headache too high a price to pay for that partying now? It’s all about…drum roll, please…the context.

Next, consider the number 100,000. By itself, it’s meaningless. But start to add context and it can suddenly become very significant. Give it units, say US Dollars.

This is data. It’s not yet information, however. It’s an amount and a unit of measure. All this means is that it can be compared to other amounts of USD or are measured in some other unit which can be translated into USD, say GBP (British Pounds Sterling).

Now let’s put it in context. To me, $100,000 is a large-but-comprehensible amount of money. To a rural Chinese farmer, it’s over ten times his expected lifetime earnings. To Bill Gates, it’s not worth his time to stoop down and pick it up off the sidewalk on his way to work.

Next time you’re asked to estimate risk, don’t forget that there’s a lot more to be considered than the data. So many analyses of risk examine just on the Usual Suspects from some checklist, best practices guide or standards list and then stop. They ignore the unique context that is their business and the accuracy and cost-effectiveness of the solution suffer accordingly.

For some reason, I seem have forgotten to publish it when I first wrote it . Financial Cryptography had a similar posting last week, to which I had my own comments over there.

Right now, I think that there are real risks related to Voice-Data convergence, but they generally fall into one of two categories. First, there is the extension of network threats to IP-Enabled Voice devices. Yawn. That’s not to say that the point doesn’t need to be made since the people running the PBX often aren’t aware of IP Networking risks. But to hype them as somehow new or different only adds to the noise, not the signal.

Then there are the “new” threats. These usually consist of taking a threat we all know and love, such as dDOS or spam and figuring out how it would be different in the VOIP or converged environments. Sure it’s fun to sit around abusing coffee and coming up with snazzy “new” acronyms concepts like SPIT (Spam Over Internet Telephony) envisioning pharming-type attacks which redirect VOIP call center traffic to a competitor, but you could do that today, possibly with even less effort and certainly with lower chances of getting caught with a foothold in the Black Box known as the PSTN. You can already spam the PSTN with nothing but a voice T-1 or two and a 1-U server, and you’d still need to do it that way so long as the phone number is king.

Maybe there will come a time when we’ve achieved enough voice-data convergence that this becomes a real threat, but other than Skype I’m not seeing any sort of world-changing convergence anywhere over the horizon. And to have integrated voice, data, IM, and presence I’d be willing to live with SPIT just like I’ve learned to live with SPAM. And if it really becomes a problem, look to cryptography to provide us some options for filtering out the crap.

This PC World story (courtesy of Yahoo) has lots of fun promises that Bad Things are going to happen to VOIP now that it’s becoming popular. Why? Because Bad Things happen to every new technology, and this is New Technology.

As a general rule of themb, if you need something scary about a technology, just go ask someone whose job is dependent on that technology being scary. Not so scary that people actually believe him and walk away, mind you, but scary enough to pay him money to keep worrying about it or trying to fix it. Lucky for the intrepid PCWeek reporter, there’s David Endler. Endler used to work for iDefense, a company that has know no end of controversy in its own right but who produce and buy some pretty good vulnerability research and (at least when I dealt with them) threw some damn good parties.

Getting back to PCWeek…

Some computer security experts say that, just as with wireless networking, VoIP’s rapid-fire adoption will be closely followed by revelations of security vulnerabilities and electronic attacks.

“As VoIP is rolled out en masse, we’re going to see an increased number of subscribers and also an increased number of attackers,” says David Endler, chairman of the VoIP Security Alliance VOIPSA, a recently formed industry group studying VoIP security.

(emphasis mine)

I’ve ready NIST 800-58, the document that this story makes so much of, and it contained nothing new or revolutionary. It warns that VOIP systems are not immune from the risks which can affect any network-connected device. It gives learned opinions as to which annexes of H323 are good and which are crap. It points out that H323 may be one of the more firewall-unfriendly protocols ever designed. It makes lots of predictions about how hard it was to keep latency under acceptable levels in 2001 when most of the core research seems to have been done. It treats insomniacs who don’t respond to strong drugs. But it doesn’t identify any risks which don’t exist or can’t be mitigated with existing network security technologies.

The risk-specific sections, however, could be applied to Windows, Linux, Apache, SQL Listeners, PBX’es with Network Management interfaces, etc., etc., etc. Moving the phones onto IP is different, sure, but not new and different.

On the Internet I have an identity as the author of this Blog. I also have an identity as an online gamer (and a damn good one, if I may say so). And as a Security Manager for a major corporation. I also have identities as my Parents’ child and my wife’s husband out in meatspace. The list goes on and on.

While some of these identities overlap, I prefer that some of them stay separate. My mom doesn’t need to know everything about me that my wife does. While I’m careful what I say here, it’s probably also best if my employer doesn’t know about my Blog.

How carefully I maintain the separation of those identities should be up to me. I don’t have any Deep Dark Secrets that I’m aware of, but if I did, you damn well better believe that I’d want to keep them separate from my various public personae. Just ask the Mayor of Spokane about that one.

Sometimes, the government decides that certain identities cannot be kept separate, such as criminal history and firearm ownership. In other cases like the Fair Credit Report Act, the government mandates that personal identity must be kept separate from financial identity for non-discrimination purposes.

So how hard is it to keep those identities separate? Probably damn near impossible, according to this New York Times article:

Senator Ted Stevens wanted to know just how much the Internet had turned private lives into open books. So the senator, a Republican from Alaska and the chairman of the Senate Commerce Committee, instructed his staff to steal his identity.

“I regret to say they were successful,” the senator reported at a hearing he held last week on data theft.

His staff, Mr. Stevens reported, had come back not just with digital breadcrumbs on the senator, but also with insights on his daughter’s rental property and some of the comings and goings of his son, a student in California. “For $65 they were told they could get my Social Security number,” he said.

That would not surprise 41 graduate students in a computer security course at Johns Hopkins University. With less money than that, they became mini-data-brokers themselves over the last semester.

Working with a strict requirement to use only legal, public sources of information, groups of three to four students set out to vacuum up not just tidbits on citizens of Baltimore, but whole databases: death records, property tax information, campaign donations, occupational license registries. They then cleaned and linked the databases they had collected, making it possible to enter a single name and generate multiple layers of information on individuals. Each group could spend no more than $50.

Several groups managed to gather well over a million records, with hundreds of thousands of individuals represented in each database.

“Imagine what they could do if they had money and unlimited time,” Dr. Rubin said.

Read the article for more information on how easy this was for them to accomplish. And remember, these guys were unfunded amateurs.

Over at Educated Guessword, Eric points to the MPAA’s new effort to Revive the Broadcast Flag.

Basically, the courts ruled that the FCC lacked the power to mandate the Broadcast Flag. In response, the MPAA is now lobbying for legislation which would explicitly grant the FCC, whom they’ve bought and paid for, the power to do their bidding on this issue.

Call it the Aggregation of Duties Attack (tm, which is to say, Your search - “aggregation of duties attack” - did not match any documents. ): An attack which functions by altering the structural relationships between organizational entities to create a channel for a breach. This is somewhat different from a Separation of Duties Breakdown for a couple of reasons. First, it attacks the controls themselves, rather than attempting to bypass them; and second, it implies a deliberate circumvention of those controls.

I see these all the time, but I never really considered that they might be a class of security breach unto themselves.

(Thanks to Emergent Chaos for paying better attention to the blogosphere than I have of late)