Monthly Archives: February 2009

A whole lot of I don’t understand it

Newsfactor.com is running the scary headline of the day:

Social Networking Linked To ‘Infantilized Lifestyle’

The gist of the article is that social networking will make us “infantilized” or “autistic” or “something”:

In case you’ve run out of things to worry about, a British scientist has raised concerns about whether social-networking sites could be harmful to your social health. But other reports indicate new ways that social networking can expand relationships.

Oxford University neuroscientist Susan Greenfield, in a debate in the House of Lords, asked if such pastimes are changing the way brains function, shortening attention spans, and possibly even contributing to the rise of autism. Greenfield is a member of the House of Lords, where she holds the title of baroness.

I suppose pointing out that serious autism is diagnosed before age 5 would have any impact on the thinking here would be too much to hope for.

But perhaps the Baroness of Scary Headlines has a mountain of hard scientific research to back this up. Not so much:

“Perhaps given the brain is so impressionable,” Greenfield said, it’s possible that “screen life” is creating a more “infantilized lifestyle,” adding that Facebook and similar sites might create short attention spans. She acknowledged, however, that she did not possess any scientific research to back up her musings, and that it was “based on a little bit of neuroscience, observations, a bit of clinical evidence.”

Greenfield noted that “there is no one single or conclusive killer fact,” although she did report that a teacher acquaintance has noticed a decline in her students’ ability to relate to others.

In other words a little bit of pseudo science, a little bit of folklore, a pinch of something a friend told her, and a whole lot of I don’t understand this whole social networking thing.

Update – from an EA spokesman:

Electronic Arts, the major video game maker, says it has heard arguments like Ms. Greenfield’s before. “It seems like a new entertainment medium hasn’t really arrived until a scientist jumps up and says it’s making us all crazy. Balancing this are studies from equally credentialed researchers that show media like videogames actually enhance problem solving and other complex brain activity,” said spokesman Jeff Brown.

He added: “I’ll wait to read her study on her Facebook page.”

Advertisements

Being Minkowed

This is fascinating. Here is an interesting way for an aspect of your identity to be your undoing:

One of the most embarrassing ways for a key executive to be removed from office is to be Minkowed.

Getting Minkowed begins when you learn that a guy named Barry Minkow has just shorted your stock, betting that information he has just uncovered can make it go down.

Then you learn that Minkow has discovered those lies that you put on your resume.

Sure, you did it many years ago, just to get hired. But you’ve had to maintain these mischaracterizations ever since, just to remain employed.

Now, your board has to face investors who are asking “Gee, if there’s lie on the resume, are there lies on the books, too?”

Your immediate removal is the only good answer to this question.

You’ve just been Minkowed.

It’s hard for me to feel much sympathy for the executives that get “Minkowed”. Of all the things you can try to get away with, claiming degrees you didn’t earn has got to be one of the stupidest. It’s so easy to get caught one wonders why anyone would try it. I also don’t feel sorry for the companies that get shorted for doing such poor due diligence on prospective executive hires.

If companies were smart they would get ahead of this and do that due diligence now. Any executive found wanting could be given a quiet exit “to spend more time with his family”.

It’s not always about you

Pat Patterson points out that the Liberty ID-WSF protocol is a nice fit for Federated Provisioning:

Now, in my Liberty-tinged version, when sending a new user to Omega, Acme includes a reference to their Employee Profile (EP) service – essentially the service’s endpoint URL – in the SAML assertion. This endpoint reference serves as both a description of where to find the service and permission for Omega (when sent as part of the signed SAML assertion) to invoke that service.

On receiving the assertion, Omega send a signed request to the EP service, the request containing the SAML assertion it just received. Now, the EP service knows that Omega is entitled to access that employee’s data, since it has a signed SAML assertion, issued by Acme itself, that says exactly that (via the presence of the EP endpoint reference). The EP can return exactly the data required (this will have been configured according to the underlying contract between Acme and Omega).

Now there is absolutely nothing wrong with this scenario. SAML in conjunction with ID-WSF is a very reasonable way for information about You (the person needing to be provisioned) to be conveyed to the service provider. For You, all the bases are covered.

But there is one big problem here. It’s not always about You.

Think about any enterprise application that You use. How much data concerns You and how much data concerns Somebody Else? I am talking about data such as contact lists, workflow approvers, roles, responsibilities, etc. How does all this data about Somebody Else get synchronized in a timely enough fashion to useful to You?

For instance if John is an approver in a workflow in a hosted application, and John is laid off, how does John get removed as a approver? How does Mary get added in his place? Do all the requests that John need to approve sit in limbo until an administrator manually makes the change? Sadly that’s how it usually handled now.

The SAML/ID-WSF solution is fine for many applications. It just isn’t sufficient for moving many of today’s enterprise applications to a SaaS model.

Whiskey for my men, beer for my horses

A virtual posse is forming to go after the author of a recent worm:

Beset by malicious worms after failing to convince enough server administrators to take its out-of-band Security Bulletin, MS08-067, seriously, Microsoft (NSDQ: MSFT) is taking computer security to the streets: It has formed a cybersecurity posse to dismantle the Conficker/Downadup worm’s infrastructure and has offered a $250,000 reward for information leading to the arrest and conviction of those responsible for the outbreak.

Microsoft warned last October that a vulnerability in its Server service could be exploited by a worm. Cybercriminals heard that warning and made the threat real, infecting as many as 9 million computers by mid-January. At that time, Qualys CTO Wolfgang Kandek estimated that between 25% and 30% of vulnerable systems remained unpatched.

So it is that on Thursday, Microsoft announced a partnership with technology companies, academic organizations, and Internet infrastructure companies to fight the worm in the wild. Its partners in this worm hunt include ICANN, Neustar, VeriSign, CNNIC, Afilias, Public Internet Registry, Global Domains International, M1D Global, AOL, Symantec, F-Secure, ISC, researchers from Georgia Tech, Shadowserver Foundation, Arbor Networks, and Support Intelligence.

Together, the coalition is working to seize Internet domains associated with the worm.

It will be interesting to see what comes out of this effort. If this effort is successful it could become a new model for the big vendors to become more proactive in battling malware authors.

A really bad idea but an interesting benchmark

Gerry Beuchelt has this to say about a privacy disaster being considered by the state of Massachusetts:

However, one suggestion Mr. Patrick made yesterday immediately got my attention: there are apparently plans on the table to introduce a “chip” in the state’s vehicle inspection stickers, so that cars can be tracked as they use the Commonwealth’s highway system. What might seem like a prudent idea to shift the cost of the transportation infrastructure to those that are causing them, is in reality an attempt to introduce an Orwellian surveillance system of European proportions.

I love the term “Orwellian surveillance system of European proportions”. How bad has the situation gotten in Europe that it is now the benchmark by which other privacy destroying initiatives are ridiculed? Not gloating from me, however. The US seems determined to catch up to Europe in the race to surrender every last shred of dignity and privacy in the most feckless manner possible.

Gerry goes on to say this about the proposal:

The potential for abuse is scary:

  • With location data, one can attempt to create a political profile by tracking conventions, conferences, and events a person goes to. I am not a lawyer, but this seems to be getting rather close to infringing a couple of First Amendment rights.
  • The collected data can be subpoena in all kinds of litigations, including sensitive things like divorce proceedings or insurance disputes.
  • If the database is ever breached, the hacker could have a field day, exposing location profiles of individuals. Depending on whose data is stolen, this could actually result in increased personal risk for exposed persons.

Gerry is absolutely right. I have previously blogged here about the second bullet point in reference to toll road transponders. That data has already been abused and that is only used by a small portion of the driving population.

Risk, liability, and clouds

I had discussed the issue of software vendor liability here and made the point that no software vendor (now or in the near future) is going to assume the liability for the cost to your business if there are defects in the software. Recently Ed Cone listened to some Cloud vendors talk about security and had this to say about it:

The security model is so immature right now that it is clear that most of the assurances cloud vendors offer are around infrastructure and covering their own respective risks. Most cloud vendors will tell you outright that it is up to the customers to individually secure their own applications and data in the cloud, for example, by controlling which ports are open and closed into the customer’s virtualized instance within the cloud.

As Maiwald puts it, enterprises need to be aware of this distinction. Security in the cloud means different things to those offering cloud services and those using cloud services. Even if you’re working with the most open and forthright vendors who are willing to show you every facet of their SAS 70 audit paperwork and provide some level of recompense for security glitches on their end, they’re most certainly not assuming your risks. For example, if Amazon Web Services screws up and your applications are down for half a day, it’ll credit you for 110 percent of the fees charged for that amount of time but you’re still soaked for any of the associated losses and costs that come as a result of the downtime.

As organizations weigh the risks against the financial benefits of cloud computing, Maiwald believes they must keep in mind that , “There is risk that is not being transferred with that (cloud services) contract.”

There are several important points here; first outsourcing a service doesn’t mean outsourcing the risk. Likewise purchasing software isn’t the same as buying insurance either. Customers of both cloud services and on premise software need to understand this.

Second, when evaluating the risk of moving to a cloud based service you have to compare it against the risk of NOT moving to a cloud based service. There is the risk that your service provider could be compromised. But that has to be weighed against the risk that your own IT systems will be compromised. Likewise the risk of a service provider outage must be weighed against the risk on an internal system outage. Both will impact your business.

Third, you should also factor in opportunity risks. If you choose not to do something that reduces cost you take the risk of losing an opportunity that may have been available by dedicating those resources elsewhere.

Janus versus Vulcan in Federated Provisioning

I always thought the Roman God Janus should be the patron deity of security professionals. From the Wiki page on Janus:

In Roman mythology, Janus (or Ianus) was the god of gates, doors, doorways, beginnings and endings. His most prominent remnants in modern culture are his namesakes: the month of January, which begins the new year, and the janitor, who is a caretaker of doors and halls.

Likewise I see Vulcan as the symbol of those toiling in the system integration and provisioning fields. Crafting unsexy and necessary technologies that make disparate IT systems work together. From the Wiki page on Vulcan:

The Romans identified Vulcan with the Greek smith-god Hephaestus, and he became associated like his Greek counterpart with the constructive use of fire in metalworking.

This comparison came to me as I was reading the recent flurry of posts about Federated Provisioning. You can go here to read the latest from Dave Kearns, Pamela Dingle, Ian Glazer, and Nishant Kaushik. These are some really smart people who make some good points, but they are mostly talking past each other. This is a Mars versus Venus kind of debate, only it’s really Janus versus Vulcan.

The federation (Janus) side of the federated provisioning discussion tends to favor the just-in-time-provisioning, minimal disclosure, and privacy aspects of federation. The provisioning (Vulcan) side of the federated provisioning focuses on the total life-cycle of the identities known to both the service provider and consumer.

That’s not to say either is right or wrong. Both have good points. But there are serious holes in the just-in-time provision approach and Pamela’s just-on-usage deprovisioning suggestion. Let me give you an example to illustrate.

Suppose ACME is outsourcing one of its sales application. Now support the SaaS application has a feature that lets you (as a sales manager) assign a sales lead to one of your salesmen. Right off the bat you should see the first problem. How do you get the salesman’s information into the system if he has never performed the federated authentication step (I am intentionally being protocol agnostic here). Clearly ACME must have bulk provisioned all the salesmen to the application when setting up the service.

But what happens when a new salesman is hired? A provisioning process should be in place to provisioning the new salesman to all the SaaS services that need to know about him. But what happens if the new salesman doesn’t work out and is let go? Cleary ACME doesn’t want to him to still show up in the list of people that sales leads could get assigned to. Just-in-time-provisioning and deprovisioning just won’t be sufficient for many applications because the identity information needs to be synchronized before the user performs his first authentication. This can be true of any application where the users interact with each other.

In addition to the data synchronization problems in Federated Provisioning, there is also the auditing issue. How does ACME audit what its salesmen did in the application? Right now there isn’t a standard that covers “Federated Auditing”, but I predict that it is something customers are going to start asking for if the truly embrace SaaS.

I guess you could say I am more Vulcan than Janus.