Security News

Last year I attended The Best Single Day Class Ever, taught by Prof. Tufte. He changed my outlook on PowerPoint for ever. Today in FCW magazine I found a pointer to 8 PowerPoint Train Wrecks, like the slide Bill Gates is presenting at left. While following some of the linked presentations, I came across this line from the shmula blog:

While at Amazon, we were all told by Divine Fiat that ALL presentations — regardless of kind, cannot ever be on Powerpoint. Period. Bezos prefers prose and actual thoughts slapped in a report — an actual paper report with paragraphs, charts, sentences, an executive summary, introduction of problem, research approach and findings (body of paper), conclusions and recommendations — not choppy, half-thoughts on a gazillion slides.

Thank goodness. I am not crazy after all.

That same blog post makes other good points, and links to an imagined Barack Obama “Yes We Can” PowerPoint deck. Hilarious.

Copyright 2003-2009 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)

Ties between the US government and digital security are all over the news right now. We have the Director of National Intelligence supporting greater NSA involvement in defending cyberspace, which prompts the (now former) Director of the National Cyber Security Center (NCSC) to resign in protest.

We have the chief security officer of Oracle calling for a Monroe Doctrine for cyberspace while the former director of the National Cyber Security Division says (paraphrasing his speech) security resources are often misaligned and misallocated because organizations are driven to present number-driven metrics based on some combination of threats, vulnerabilities and asset value to management — and that doesn’t work.

There is talk of creating a Cyberspace Combatant Command, to stand alongside other Unified Combatant Commands. (Thanks to Greg Conti for the link.) I think a Cyber COCOM would be a great step forward, since Combatant Commands, not the individual services, are the entities which fight the nation’s wars,

On a related note, I attended part of the latest Software Assurance Forum sponsored by DHS. Presentations by Mischel Kwon, director of US-CERT, and Tony Sager, chief of the Vulnerability Analysis and Operations (VAO) Group in NSA, were the most interesting to me. I’d reproduce a few noteworthy items.

Mischel Kwon said or mentioned:

• “Legacy systems are not an excuse. They are a flaw.” In other words, you can’t make excuses for operating indefensible networks.
• US-CERT is building its own incident management and ticketing system. This was interesting to me because incident management is a massive headache.
• US-CERT is looking at using Security Content Automation Protocol as a detection tool, to identify when system configurations change. (SCAP is a protocol, not a tool; but the tools using SCAP can watch for changes.)

Tony Sager said or mentioned:

• “We can’t just fix software to ’solve’ security problems because vulnerability is everywhere.” Wow, amen. Someone else believes we live in a world of vulnerabilities. Tony may displace one of my Three Wise Men!
• “No single group of security practitioners is big enough to develop and maintain its own security configuration guides.” Therefore, the FDCC was developed. Seriously, if you have to run Windows, why not start with the FDCC as your core image and make changes to FDCC? Don’t waste time trying to figure out what a security system looks like. Make use of the government’s collective work, applied to millions of computers, and adjust to suit your needs.
• “DoD cannot afford to maintain separate IT… DoD doesn’t improve unless everyone else improves. Tony said that modern network security relies on everyone improving their status, even if that means knowledge to improve security is used by the adversary.
• “VAO doesn’t brief 90% of our constituents.” In other words, VAO publishes Security Configuration Guides, which its world-wide constituency consumes. “VAO briefings” refer to NSA’s red team presenting its findings to DoD customers following an adversary simulation activity. Red and blue teaming used to be the primary means that customers would learn how to improve their networks. Now, VAO’s expertise is delivered much more often in the form of written reports. The written word scales.
• “Even if a single tool could manage all DoD vulnerabilities, DoD wouldn’t want to rely on only one tool.” That places too much trust and power in the hands of a single vendor. Instead, DoD (and others) should rely on common protocols to describe vulnerabilities, like SCAP, and then ensure the wiude variety of tools DoD uses can speak that common language.
• “Every human is a sensor.” Advanced intruders are likely to evade technical detection. People are often the best, and only, way to identify advanced intrusions.

Finally, I’d like to briefly mention commentary by two other speakers. Curt Barker from NIST listed two “leap-ahead” initiatives at NIST, namely asymmetric algorithms for the quantum computing environment (in 20-25 years) and very large scale key management. I wonder how long those with quantum computers will be active before new algorithms that resist quantum computer cryptography breaking are widely deployed?

Jason Providakes from MITRE described the potential for the government to build a core capability with known pedigree, augmented by open and commercial software. I found this interesting, because it’s possibly 5 to 10 years out of date. In other words, the problems we often see these days involve applications, not the operating system (if that’s the “core capability” mentioned).

Copyright 2003-2009 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)

I’ve been working on upgrading ISA 2004 to ISA 2006 (on new hardware as well). We use SecurID authentication at ISA, and then Forms Based Authentication on the Front End OWA server. While this had worked fine with ISA 2004, it didn’t work at all under 2006.

A quick Google found one post on a Microsoft forum with the same problem. Their conclusion was that this was not possible. The poster cited a ISA 2006 book as saying it was an either/or situation. “You can’t do Forms Based Authentication on both ISA and OWA.”

Fortunately, I searched a bit more and found a solution. http://support.microsoft.com/kb/935206

I found I already had files newer than those in the referenced patch. By running the script and configuring OWA publishing as a regular web publishing object, I was able to get it to work.

You should already know this but Adobe released the 9.1 update. This patch needs to be deployed ASAP. Updates for 8 are expected by March 18th. I’m not sure if updates for 7 will come out then or later.

I checked SMS and found that around 10% of our systems have Adobe Reader 9. Our standard is 8.1.3. After I packaged 9 for deployment, I was told that Adobe Reader 9 has a conflict with another application we use. So I’m a bit surprised that this many systems would have 9.

So it looks like I’m going to have to deploy Adobe Reader 8 and 9 updates. For Reader, Adobe didn’t release a MSP, so its a full upgrade.

Adobe does release a MSP for Acrobat, the update is only a single increment. So to upgrade from 8.0.0, several patches must be applied. I hadn’t realized that until this week. We’ve been giving users some bad instructions.

Is the corporate environment transforming to accommodate the newest forms of communication to which their young employees are accustomed? Should long-standing authoritative attitudes – “do it because I say to do it” – change to take advantage of the energy and comfort with multitasking that fresh employees bring to the workplace?

Experts: U.S. needs to defend its “cyber turf”

There’s a lot in the news today about control of content in blogs, multimedia, and Internet use in general.

First, it looks like Google has been taking down content from Blogger users, whenever there is a question of whether the content is copyright protected or legal. Even when an artist seemingly gives permission, the situation gets complicated because international rights holders and others can claim they have not given permission. Google plays it safe by taking content down and asking questions later – if the takedown notice doesn’t get lost in the tubes, that is. And then, questions may be fruitless.

A related problem is facing YouTube users in the UK, where royalty holders are preventing YouTube from allowing premium content.

It seems that whenever you put up a resource on a third party site, a lot of liability starts flying around. It’s understandable that Google doesn’t want to be at risk of lawsuits because of its Blogger or YouTube services; however, it’s hard to tell what’s fair and who’s getting the short end of the deal, when it becomes impossible to track down the source of the problem.

In related news, Time-Warner is exercising rights that resemble a version of net neutrality—metering the bandwidth used by consumers, and charging for surplus usage. Allegedly, says the Consumerist, this blocks users from accessing streaming media like Hulu, Netflix or others, some of which you have to pay for anyway.

Internet users get the short end of the stick, it seems, when the big companies they look to for services are more concerned with liability and costs than service.

Yet there is another way than the one we know too well. In Norway, a public broadcasting service whose aim is to serve content, not make a profit, is offering a free BitTorrent distribution experiment. It’s a way for the relatively small country to get its works distributed and promoted. I guess it’s not surprising that TimeWarner and Google are less enthusiastic about free and available.

But it gives a roadmap for small, start-up companies looking to get their content available or distributed freely—don’t use big services or a third party platform to do it for you, or you never know when something could get blocked or pulled. Outsourcing can be a great money-saver, but if it’s at the cost of your promotions or content security, it may not be worth it. Host your own blog, find new ways to distribute your own content, and you won’t have the headache of dealing with a big company who’s more concerned with their own liability than your interests.

I’ve been interested in extending HTTP security out to our remote users. When users are in the office their HTTP traffic is antivirus scanned and URL filtered. When remote, they only have desktop antivirus to protect them. As more and more users are mobile, I think it is important to address this.

BlueCoat offers a ProxyClient that can provide traffic acceleration and URL filtering. The URL filtering occurs the same was as with K9 or with a Phishing filter. The URL is sent to their servers and categorized then allowed or blocked accordingly.

Location based rules are created so that acceleration or URL filtering is enabled as appropriate.

I quickly found that the release notes weren’t kidding. SMB signing is incompatible with CIFS acceleration. I was hoping that the traffic would still be accelerated through compression and byte caching. My tests seemed to show that traffic was a bit slower when acceleration was enabled.

Most IT professionals know that firewalls and anti-virus solutions aren’t the only technologies needed to address the PCI Council’s mandates.

If you’ve been watching the digital security scene for a while, you’ll notice trends. Certain classes of attack rise and fall. Perceptions of risks from insiders vs outsiders change. I think it is important to realize, however, that globally, security vulnerabilities and exposures are persistent. By that I mean that if we forget or neglect problems from the past (or even present) and focus only the future, we will lost.

For example, the three big themes you’ll see in many IT and security discussions are the following.

1. Web apps
2. Virtualization
3. Cloud

If you’re not dealing with those three areas, you’re a dinosaur, man! Forget all that other stuff you’ve learned!

The problem with that attitude is that it sees the world through a tunnel of shiny newness.

Consider the following list of recent security issues and see how many of them deal with those three hot topics.

• CPU-level attacks (e.g., Attacking Intel® Trusted Execution Technology)
• MPLS attacks (e.g., All Your Packets Are Belong to Us – Attacking Backbone Technologies)
• BGP attacks (e.g., Defending Against BGP Man-In-the-Middle Attacks
• IPv6 security (e.g., Attacking IPv6)
• Anti-forensics (e.g., SQL Server Anti-Forensics)
• Various nontraditional rootkits (e.g., .NET Framework Rootkits)
• Attacks on cryptography (e.g., MD5 considered harmful today: Creating a rogue CA certificate)
• DNS attacks (e.g., DNS 2008 and the New (old) Nature of Critical Infrastructure)
• Router attacks (e.g., multiple presentations on exploiting Cisco IOS at Black Hat US 2008)

I could continue. The point is there’s a lot more to our security problems than Web, VM, and Cloud. It might be simpler to think of only those three problems, but there are at least a dozen more that require attention. This problem makes our security lives more difficult, but also more interesting.

Copyright 2003-2009 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)

Gary McGraw was kind enough to share a draft of his new Building Security In Maturity Model. I’m not a “software security” guy but I found that the Governance and Intelligence components of the Software Security Framework apply almost exactly to anyone trying to build a detection and response, or “security operations”, center. Consider:

• Governance
• Strategy and Metrics
• Compliance and Policy
• Training

• Intelligence
• Attack Models
• Security Features and Design
• Standards and Requirements

I think the whole document is just what the software security world needs, but the two sections should apply equally well, and almost without any modification, to someone trying to build a detection and response operation or at least trying to assess the maturity of their operation.

Copyright 2003-2009 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)

I think the next generation of IT and digital security professionals will find limited opportunities in the “traditional” non-IT/security companies of today. I wrote about this last year in Reactions to Latest Schneier Thoughts on Security Industry when I said this, specifically about the security field:

What does this mean for security professionals? I think it means we will end up working for more service providers (like Bruce with Counterpane at BT) and fewer “normal” companies.

[S]ecurity companies will end up part of Cisco, Microsoft, Google, IBM, or a telecom. I doubt we will have large “security vendors” in the future.

I’d like to extend this prediction (which is not unique to me, of course, but writing it here means I’m planning for the change) from security to IT in general. I re-examined my stance on this issue after reading GE CIO Gets His Head in the Cloud for New SaaS Supply Chain App. The fact that the article talks about GE isn’t the specific point (disclaimer: my employer). It’s another reminder that IT and security are not the end goal for most organizations: they are means to an end. The only exceptions are companies whose products and services are IT and/or security, e.g., Cisco, Microsoft, Google, IBM, telecoms, etc.

This doesn’t mean that “IT [or security] doesn’t matter.” On the contrary, both are crucial, but history has shown a relentless drive to focus the business on core competencies and away from non-core functions. The definition of core competencies is what matters.

Businesses are spread across a large spectrum. One end might have a (largely theoretical) fully-closed organization that could generate its own electricity, mine its own raw materials, design its own products, staff every seat with employees, design/build/run/defend its own information assets, and run its own sales, distribution, and customer service functions. At the extreme opposite is a firm that does nothing but buy patented ideas and sell licenses, with minimum staff and every other function outsourced.

The history of capitalism has demonstrated the power of comparative advantage, specialization, and division of labor. Businesses continue to migrate away from the do-it-yourself model to the outsourced model, with labor, legal, and security concerns as a few sources of friction.

If you look around your own enterprise you’ll see signs that this migration is happening. I’d like to know which of you manage a 3G network? Chances are if you answer yes, you work for a telecoms provider. How many of you keep the operating system on your Blackberry or iPhone patched? If you answer yes you work for a telecoms provider or Apple.

It’s entirely within the realm of possibility to imagine enterprise users operating personally-owned assets, with network connectivity supplied by a 3G network, accessing software-as-a-service Web apps hosted by a cloud provider. Oh wait, that is already happening. Anyone who wants to see what the “consumerization of IT” looks like should visit a university campus and see how students learn in the 21st century.

This doesn’t mean that universities and other organizations who are embracing this model have zero IT and security staff. Rather, I think it is important to imagine where we (or our kids) could be working in 20 years, if we want to stay in the IT and/or security fields. Many more jobs, percentage-wise, are going to be with providers and vendors, not customers. Consider how many companies maintain their own electricians, phone technicians, and so on. There are plenty of those roles in the modern economy, but they tend not to work for non-electrical, non-phone companies.

Copyright 2003-2009 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)

During a recent customer meeting, I was asked to highlight key capabilities necessary to satisfy PCI’s Security Information and Event Management (SEIM) requirements.  I explained to the customer that if their goal was merely to meet PCI Requirement 10, the solution used here – either purchased, outsourced or home grown – must posses a modest set of baseline capabilities.  Some of these include enabling audit trails, reconstructing simple events, and securely storing audit trails for at least a year.

Click to Download/Listen (7:23)

The week’s Speaking of Security podcast discusses the release of RSA enVision 4.0, the premier platform for Secuity Information and Event Management/Log Management.

Last year I posted Defensible Network Architecture 2.0, consisting of 8 (originally 7, plus 1 great idea from a comment) characteristics of an enterprise that give it the best chance to resist an intrusion.

In this post I’d like to define some specifics for the first of the 8 characteristics: monitored. At some point in the future it would probably make sense to think of these characteristics in terms of a capability maturity model. Right now I’d like to capture some thoughts for use in later work. I will approach the requirements from a moderate point of view, meaning I will try to stay between what I would expect from a low-capability operation and a high-capability operation.

Like my related posts, this is a work in progress and I appreciate feedback.

A Defensible Network Architecture is an information architecture that is:

1. Monitored. Monitored can be described using the following categories, which collectively can be considered intrusion detection operations. (Add in Response or Resolution, depending on your IRT’s mandate, and you have the CAER model for security operations.)
• Collection. The following technical data is collected and available to the security operations team.
• Network Security Monitoring (NSM) data from passive sensors; note the NSM data must depict true source IP and true destination IP (i.e., monitoring traffic between a NAT gateway and a proxy means seeing only the source IP of the NAT gateway and the destination IP of the proxy, radically decreasing the value of the observed traffic)
• Alert data from devices making judgements while inspecting network traffic
• Statistical data summarizing network traffic
• Session data describing conversations in network traffic
• Full content data providing traffic headers and payloads

• Infrastructure Security Monitoring data from routers, firewalls, switches, so-called intrusion prevention systems, and other network infrastructure that actively manipulates network traffic, or provides fundamental network services; by “fundamental services” I mean services that, without which, nothing much else works, e.g., DHCP, DNS, BGP
• Access Control logs that report on allowed and denied traffic
• Infrastructure logs that report DHCP address assignments, DNS queries and responses, BGP routing tables, etc.

• Platform Security Monitoring data from nodes (laptops, desktops, non-infrastructure servers, etc.)
• Operating system security logs, like Windows Event Logs
• Application logs, like Web server logs, Web application logs, etc.
• Platform memory, preferably exposing memory segments as needed (think retrieving a live system registry) or the entire memory (think ManTech DD plus Volatility)

• Analysis.
• A dedicated team analyzes technical data collected in the previous stage.
• The team has access to subject matter experts who can answer questions on the nature of threats, vulnerabilities, and assets in order to better understand the risk posed by monitored activity.
• Analysis is understood and supported by management as a creative task that cannot be “automated away.” If automation were possible for detecting intrusions, the same automation could be applied to preventing them. (“If you can detect it, why not prevent it?”) Assuming everything detectable is preventable, by definition the analysis team is left to identify activity which is most likely not easily detectable, or at least not easily validated as being malicious.

• Escalation.
• The team has defined categories to identify the nature of intrusions and non-intrusions.
• The team has defined severity levels describing the impact of various types of intrusions.
• The team has an escalation matrix summarizing the stes to be taken given an intrusion of a specific category and severity.

You should monitor at trust boundaries, to the extent you perceive risk and have the technical and legal resources to do so. (For more on trust boundaries with respect to monitoring please see NSM vs Encrypted Traffic, Plus Virtualization and NSM vs Encrypted Traffic Revisited.

I will stop here, but continue with Inventoried when I have time.

Copyright 2003-2009 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)

This should not be a surprise to people who use forensic tools on a daily basis, but it is a good reminder. I just noticed two great posts, Dumping Memory to extract Password Hashes Part 1 and Dumping Memory to extract Password Hashes Part 2, on the Attack Research blog. They show how to exploit a system with Metasploit, upload the Meterpreter, upload Mantech’s MDD memory dumper, dump memory, download it to an attacker’s system, and then follow instructions from Forensiczone to use Moyix’s volreg extensions to the Volatility Framework to extract passwords.

I would be curious to see if intruders are really using methodologies like this. One way to identify such activity would be to watch for files being exfiltrated from the enterprise that match common memory sizes, such as 512 MB, 1 GB, 2 GB, 4 GB, and so on.

Copyright 2003-2009 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)

Last year I outlined my Defensible Network Architecture 2.0, consisting of 8 (originally 7, plus 1 great idea from a comment) characteristics of an enterprise that give it the best chance to resist an intrusion.

I’d like to step into the post-intrusion phase to discuss Recoverable Network Architecture (RNA, goes well with DNA, right?), a set of characteristics for an enterprise that give it the best chance to recover from an intrusion. This list is much rougher than the previous DNA list, and I appreciate feedback. The idea is that without these characteristics, you are not likely to be able to resume operations following an incident.

RNA does not mean your enterprise will be intruder-free, just as DNA didn’t mean you would be intrusion free. Rather, if you do not operate a Recoverable Network Architecture you have very little chance of returning at least the system of interest to a trustworthy state. (Please remember the difference between trusted and trustworthy!)

1. The recoverable network must be defensible. Being defensible not only helps with resisting intrusions; it helps recovery too. For example, the network must already be:
• Monitored: Monitoring helps determine incident scope before recovery and remediation effectiveness after recovery.
• Inventoried: Inventories help incident responders understand the range of potential victims in an incident before recovery and help ensure no unrecognized victims are left behind after recovery.
• Controlled: Control helps implement short term incident containment, if appropriate, before recovery, and enforces better resistance after recovery.
• Claimed: Because an asset is claimed, incident responders know which asset owners to contact.
• Minimized: Assets that retain security exposures following recovery are subject to easy compromise again.
• Assessed: Assessment validates that monitoring works (can we see the assessment?), that inventories are accurate (is the system where it should be?), that controls work (did we need an exception to scan the target, or could we sail through?), and that minimization/keeping current worked (are easy holes present?)
• Current: Assets that retain security vulnerabilities following recovery are subject to easy compromise again.
• Measured: Measurement helps justify various recovery actions, e.g. showing that so-called “cleaning” is less effective and costs more than complete system rebuilds.

2. Assets in a recoverable network must be capable of being replaced — fast. IT shops are slowly waking up to the fact that “cleaning” does not work, is too expensive, and should be standard for any disaster recovery/business process continuity activity anyway. Complete rebuilds are becoming the only semi-effective remedy. (I say semi-effective because even complete rebuilds can preserve BIOS-level and other persistent, extra-OS rootkits.)
3. Incident responders in a recoverable network must be authorized and empowered to collect evidence, analyze leads, escalate findings, and guide remediation. An IRT that is asked to assist with an incident, but that is not allowed or able to collect information from a victim, is basically helpless. An IRT that must wait for other parties to provide information is ineffective, and likely to find the “data” provided by the other party to be of decreasing value as time passes and asset owners trounce host-based evidence.
4. A recoverable network is supported by an organization that has planned for intrusions. The IR plan must engage a variety of parties, contain realistic scenarios, and actually be followed. IR plans help increase the likelihood of incident recovery because time is not wasted on phone calls asking “what do we do now?”
5. A recoverable network is supported by an organization that has exercised the IR plan. Drills find weaknesses in plans that will hamper recovery.
6. A recoverable network is supported by an IRT that is appropriately segmented. By that I mean that the IRT’s infrastructure is not hosted or maintained by the same infrastructure the IRT is trying to recover. In other words, the IRT should not depend on equipment administered by the same people who suffered a loss of their credentials, or be part of the same Windows domain, and so on. If the IRT does share infrastructure with the victim, then the IRT can no longer trust its own systems and must first restore the trustworthiness of its own gear before turning to the organization.
7. A recoverable network is supported by an IRT that is also connected. The team can communicate in degraded situations, with itself and with outside parties. The IRT will definitely have requirements that exceed the end user community, and almost certainly even the IT shop.

What do you think of these requirements? I may try expanding on each of the DNA items with examples at some point. If that works well I will apply the same to RNA.

Copyright 2003-2009 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)

Security metrics are very difficult to do well, and easy to do poorly. For example, take a look at the recent Secunia “2008 Report” (http://secunia.com/gfx/Secunia2008Report.pdf). It tries to break down vulnerabilities reported by browser, and specifically states:

31 vulnerabilities were reported for Internet Explorer (IE 5.x, 6.x, and 7), including those
publicly disclosed prior to vendor patch as well as those included in Microsoft Security
Bulletins.

Safari and Opera each had 32 and 30 vulnerabilities, whereas 115 vulnerabilities were registered for Firefox in 2008.

From a quick read it appears as though Firefox had almost 4 times as many security issues as IE or Safari! Like, OMG! However, that conclusion would be painfully incorrect. Mozilla discloses and releases bulletins for all security issues fixed in Firefox, regardless of how they were discovered. Unlike other vendors that only disclose issues reported by external independent parties, but not by internal developers, QA or security contractors.

So presenting those numbers as comparable is worse than useless, it is in fact very misleading. It’s like comparing traffic accident rates for two cities of equal size, but one only reports accidents that make the news while the other reports all traffic accidents. Directly comparing such numbers is meaningless.

Some vendors make the point that the number of internally found issues is small and not meaningful. That would unfortunately imply their internal testing and security processes are incapable of finding security issues, and rely entirely on the generosity of random strangers (security researchers). I would find that pretty scary.

Fortunately, having worked in-house and consulted to a number of large software vendors, I can assure you that is not true. In fact they generally have very capable security teams and QA processes, which are so good at finding security issues that they usually find far more internally than they ever disclose to the public.

The Secunia report is deeply disappointing on a number of levels. Frankly, it’s disappointing that security researchers aren’t taking the “research” part of their jobs as seriously as they once did. It’s also disappointing that Secunia would publish something like this as one really expects better from them. This sort of reporting only encourages companies to hide as many security issues and fixes as possible, which moves the state of security backwards. And this is perhaps the most disappointing thing of all.

Lucas Adamski
Director of Security Engineering

On-Demand > Watch it now!SPONSORED BY: NortelWatch this FREE on-demand webinar to get a smart and simple step-by-step approach to Unified Communications.Learn to streamline your mulitiple devices a…

It’s seductive to think that we could imbue robots with human emotions, but so far our attempts have been anything but endearing.

[edit: this story is a joke, but it's still not too far off from the crazy things we humans do. the image shown on many of the stories is of a real japanese medical robot. more info]

In the newest robot escapade, a Japanese bot programmed to love and care for the elderly developed a sort of stalkerly crush on a female intern that spent a few hours programming him each day. One day he blocked her exit from the lab, while repeatedly hugging her, until she called for help de-activating the bot.

Attempts to stabilize the robot’s systems since that incident have been unsuccessful. The robot first learned to form attachments by bonding with a doll and cuddling it for hours; and now, the bot tries to rush to hug the first technician that tries turning it on:

Ever since that incident, each time Kenji is re-activated, he instantaneously bonds with the first technician to meet his gaze and rushes to embrace them with his two 100kg hydraulic arms. It doesn’t help that Kenji uses only pre-recorded dog and cat noises to communicate and is able to vocalize his love through a 20 watt speaker in his chest.

While that description is in part absolutely hilarious, it’s also terribly frightening, and not just because the robot’s response is dangerous. I’m more put off by the scientists’ inability to understand and therefore reproduce emotions. How on earth could scientists think that imbuing a robot with the capability to hug and form attachments could be some kind of substitute for love and caring? Secondly, they overlooked the most essential part of human emotions: having feelings makes creatures more needy than giving. If they want a robot to care selflessly for the elderly, it seems counter-intuitive to imbue it with a needy self.

Human and animal emotions are dangerous; we need the complex and subtle rules of social norms and boundaries to help keep them in check and turn them into positive forces; we need a complex consciousness of the rules of cause and effect to understand how our actions affect others. Dogs and humans too are confined by the need for approval of the pack. A creature with attachments and desires, that doesn’t have those capabilities, can be a dangerous foe with even the best of intentions.

We’re far from developing Battlestar-style Cylon technology, in which robots are indistinguishable from humans. We’d be better off making robots that just do what they’re told—but even our basic computer systems can’t do that much of the time. Think of that next time your computer crashes, or you’re faced with the blue screen of death. Those crashes and inevitable reboots show just how far we are from creating creature-like computers.

Or if you’re a mac user like me, it’s likely to happen anytime you try installing a new scanner or printer driver, like I did last week…that wasn’t fun, but it was better than if the machine had tried to hug me repeatedly…