Security and Risk Management Strategies Blog

Beyond the Tipping Point: Responding to Operation Aurora

Blogger: Dan Blum

 

Hack attacks referred to as “Operation Aurora” by the multiple groups of Chinese hackers that reportedly perpetrated them from 2006 onwards hit at least 34 companies in the technology, financial and defense sectors.

 

Ladies and gentlemen of the jury, let me remind you that in this court of public opinion we do not have legal jurisdiction over the Government of China. We do not have to prove beyond reasonable doubt that said government is guilty of conducting a massive and continuing cyberwar linked in nefarious ways with an international world of cybercrime. Our life of information security is a civil life. Our response to Operation Aurora is a civil action.

 

So do not ask me, as someone did during my “Threat Assessment in Dangerous Times” telebriefing (client access required) yesterday whether I can “prove” China was behind Operation Aurora. To reach a verdict in the civil court of life we don’t have the same standard or proof you saw required at the OJ Simpson trial, for example. We only need a preponderance of the evidence. We only need to be 51% sure, not 100% sure. Myself, and a lot of people, are well past 99% sure. Hillary Clinton, who spoke for the U.S. in officially denouncing the attacks, would not do so lightly, and would probably agree with me.

 

Get past the confusion about how we prove origin of incidents that begin with a threat behind smokescreens of onion routers and proxies in uncooperative jurisdictions. That is not the issue. Individuals and organizations, cast off your paralysis. Respond to Operation Aurora.

 

But respond how? Google must have calculated it had less to lose in a China syndrome of continuing intellectual property theft and brand erosion. Google went public. But many other organizations export (or hope to export) to China. They fear the repercussions of standing up to China, even if they think (or know) that the government is perpetrating, supporting, or tolerating cyberattacks against them.

 

 

http://commons.wikimedia.org/wiki/File:IllegalFlowerTribute1.jpg  

 

Commercial organizations may be in a quandary, but their publics and their governments will respond. To paraphrase what one panelist from a leading threat intelligence company said during my telebriefing: “We’ve blown past the tipping point where traditional protection paradigms apply. We’re in the third wave of electronic information protection. From worms and cyber pranks beginning in the 1970s we escalated to widespread cybercrime beginning in the 1990s and recently to cyberwar. Just think about the Estonia, Georgia, and Operation Aurora incidents. Governments are responding. Massive amounts of money will be thrown at the problem and for the next few years no one will know who is in charge.”

 

Government response is necessary because no individual and few organizations can resist the related juggernauts of China cyberwar and worldwide cybercrime. But government response is also dangerous and could make cyberwar worse. In my opinion, however, that risk is less than the risk of not responding to an unacceptable status quo.

 

So my final editorial comment and advice is that if your organization thinks or knows it’s been attacked, try not to roll over and play dead. Go public like Google if you can or if you dare. The more companies and individuals speak out, the less any one of us will face repercussions, and the sooner we’ll see positive change.

 

But if you can’t go public, at least advocate among your peers for a discreet report of the incident either to law enforcement or to information sharing groups. Our public response to Operation Aurora and what will surely be ongoing problems of international cyberwar and cybercrime is going to require the best factual information about incidents, the best deliberations, and the best lobbying, diplomacy, legal, economic, and infrastructure responses possible.

Operation Aurora Points Out the Need for Better Threat Assessment Process

Blogger: Dan Blum

 

The debate is ongoing about whether the Chinese government is behind the Operation Aurora cyberattacks. Certainly Google believes China launched the Hydraq trojan used to breached its defenses and compromise intellectual property. And it was that determination, plus an apparently principled decision to resist Internet censorship, that motivated Google’s strong response, in which the company publicly threatened to quit China.

 

One can agree or disagree with this response. But let’s suppose the allegations are probably correct. If so, an attack by a nation state requires a different response than one by an external hacker, an insider, or other parties. And organizations with valuable intellectual property for the taking need to think about how they might deter, prevent, or respond to such attacks.

 

In my research on the threat landscape and threat assessment, I’ve found that security vendors and IT security staff spend too little time focusing on the “people” or “political” aspects of the threat. Threat reports from the vendors cover malware and vulnerabilities, but they don’t always discuss the threat’s capabilities and intents, nor why one type of organization is targeted and another goes free. Ignoring these factors may create a significant blind spot.

 

On February 17 at 2:00 ET and again on February 18 at 9:00 AM my “Threat Assessment in Dangerous Times” telebriefing will discuss my findings that organizations need to do a better job of assessing threats and developing defensive strategies. I’ll provide guidance on developing a threat assessment strategy and factoring threat intelligence into protection programs to avoid common mistakes and gain ground against adversaries.

 

I’ll also convene a small panel of experts to discuss threat assessment and the recent "Operation Aurora" attacks.

Not one cloud fits all

Blogger: Dan Blum

During the Catalyst conference, some of us Burton Group analysts covering cloud computing risks got the pushback that our positions are overly cautious. One has to be careful these days not to get caught up in the hype, or the fear. Because “cloud computing” is such a general term, any statement or position one takes gets applied to every type of service and vendor. Yet while many vendors and customers use or provide cloud computing, not all of them agree on what it means.

Burton Group categorizes clouds as internal, private (community), or public. When it comes to internal cloud, the organization runs its own virtualized and/or web-facing IT environment. The primary difference between internal cloud and dedicated IT facilities is architectural. Information protection can be accomplished through familiar internal processes, though details of the technologies change.

The strongest security concerns arise with public, multi-tenant cloud service providers that might process and store the organization’s sensitive data. We’ve expressed concerns about public cloud service providers in the posts Cloud Computing: Who is in Control? and To cloud computing vendors: Stop practicing security by obscurity!

Private (community) clouds fall in between internal cloud services and public cloud services. Some actually deliver software, hardware infrastructure, or both as a service but design and operate the service for customers in a particular vertical industry, such as aerospace, automotive, financial, or health. Some have been around for years and only recently jumped on the cloud computing bandwagon; others are still wondering whether to associate themselves with it. Covisint, Exostar, IntraLinks, SecuritiesHub, and Sentillion are just a few examples of service providers that seem to fit the private (community) mold.

The real question is not whether these and other service providers call themselves cloud, but what value do they deliver and how well do they protect customer interests? Some of them tailor their security measures, audit reports, and contracts to the needs of their vertical industry. A customer in their target industry may be better off with them than with public cloud vendors from a security perspective.

One must also attune security and compliance expectations for service providers to what you’re relying on them for. You have to get past the description of a service and analyze it based on the technical capabilities it’s actually providing. For example, multiple providers may claim to offer “secure collaboration,” but one may be an identity broker that sidesteps liability by not storing any customer data while another actually provides secure document storage. The technical security requirements for these two providers should be different.

The industry is clearly evolving toward a hybrid cloud environment where many different types of cloud offerings (both internal and external) will interact to provide different layers of service. As a customer, you can choose to keep some data and some layers of service under the wing of internal IT facilities; move commodity functions into low cost, public cloud services; or subscribe to vertical industry oriented community services. How you mix and max services and what you rely on them for in the hybrid cloud environment determines your risk and requirements. It’s not one cloud fits all.

And in that light, our guidance to “Be very cautious about putting sensitive data into the cloud” is still good. One needs to be very careful with sensitive data - wherever one puts it!

To cloud computing vendors: Stop practicing security by obscurity!

Blogger: Dan Blum

Does cloud computing security need to be “secret”? Google, Amazon, Salesforce, and other cloud computing vendors seem to think so.
 
Eric Maiwald (Research Director for Burton Group Security and Risk Management Service) made an excellent post on the risks associated with resource aggregation in the cloud. He used the recent Rackspace outage to make his point that customers had better know their providers environment before using their services. In fact, there is a whole cloud computing incidents database on Wikipedia. What this all shows is that cloud computing is subject to the same (in)security dynamics as the rest of IT.
 
Over the years, security professionals have learned that security by obscurity doesn’t work. There is a balance to be struck between opacity (to the attacker), transparency (to the customer), and disclosure (by the vulnerability researcher).

Concerning transparency, I quoted John Clippinger's “A Crowd of One” book in an internal Burton Group email:

“Trust…can only exist as a consequence of mutual expectations being fulfilled. Trust requires measurement, feedback, and accountability. In most social networks, the consequences of low trust are high transaction costs, that is, constant monitoring, negotiation, bickering, and dispute resolution…The ability to build and leverage trust among members of a group builds social capital and significantly reduces transaction costs.”

That really got some discussion going! Research Director Drue Reeves blogged on Cloud Infrastructure Secrecy: Competitive Advantage or Disadvantage…

And Jamie Lewis, Burton Group CEO makes a great post within a post, here:

“Lack of cloud computing vendor transparency reflects the immaturity of the marketplace. If vendors think security is a competitive advantage, then they are sadly mistaken. And they will have to go through a painful cycle to learn that lesson.
 
At Catalyst 2008, George Sherman of Morgan Stanley gave a fantastic keynote for the IdPS track. At the end of the presentation, he said that anyone should feel free to come up to him in the hall and ask questions because, at Morgan Stanley, they don’t see security is as a competitive advantage. He pointed out how the financial services industry as a whole relies on confidence and trust to operate smoothly, which makes sharing information in everyone's best interests. If one bank’s security fails in public and horrible fashion, all banks suffer a loss in confidence. (Our current crisis shows just how true this is.)
 
Is it not fair to say that the same dynamic applies to cloud service providers? If one or more providers suffers the breach/disclosure/PR/investigations/fines cycle from hell, does it not harm all service providers? Isn’t this even more true when said “other” providers refuse to disclose (even to us) enough details on the security posture to allow a reasonable assessment of that posture?
 
It’s not just that they have to get used to being in the spotlight. It’s that they have to completely get over the notion that security is a competitive advantage. No one will believe them if “trust me” is their only answer. The “cloud industry” needs to understand that it’s in all of their collective best interests for the buyer to have a reasonably good feeling about the security of ALL providers in order for any one provider to be able to sell successfully on the real competitive advantages: service levels, price, performance, and ability to support business needs.”

And Research Director Bob Blakley concludes:

“I’ve got a really simple response to anyone who wants me to buy a security and availability pig-in-a-poke.  It’s this:

You don’t want to give me details of how you handle security or what your availability numbers & history are. That’s fine, I understand. You obviously understand that I have to manage my risks, and without these numbers I can’t assess risk or buy insurance. So here’s the deal. We have three options:

• You tell me what I want to know, or
• You accept unlimited liability for breach or outage in our contract, or
• I take my business somewhere else”

That's really telling 'em!

Cloud Computing: Who is in Control?

As with real cirrus, stratus, and cumulus clouds IT’s cloud computing services come in various types and often combine with each other to make strange formations. An exposed hiker in the open might ask: "Is that but a fair weather cumulus cloud, or an ominous storm cloud?”

In the world of IT security, we call that risk assessment.

When it comes to putting your IT resources and – perhaps – even slightly sensitive data such as personal names, addresses, and phone numbers into the cloud one might start with these three questions:

• Who is in control?
• Do they provide assurances?
• Can we trust them?

In traditional IT environments, organizations generally share control over the network with service providers, but for the most part control their applications, servers, and storage infrastructure. In an internal cloud environment, the architecture changes, but not the complexion of control. As shown in the figure, however, the control architecture changes profoundly for public cloud offerings such as Amazon EC2, Google Apps, or Salesforce.

As we move from left to right in the diagram and put more and more control in the hands of the service providers, the outlook shifts from fair weather green to ominous red.

Assuming we trust our IT department to give the necessary assurances and do their jobs well, the “dedicated IT” stack is green but for its use of the Internet, which is yellow.

With server hosting providers or “colo” data center facilities we still retain substantial control, perhaps relying on the service provider only for rack space, power, and cooling. In these simple arrangements, the service hosting providers will typically provide assurances, or service level agreements (SLAs). They may help us build trust by offering site tours, audits, and track records. We may feel we can fully understand their operations and residual risks. We may feel comfortable sharing control of the server, storage, and network functions with hosting providers. Yellow is mellow.

In the world of cloud computing, everything changes. As we move from

• Infrastructure-as-a-Service (IaaS) with its line of demarcation in the server where the silicon stops, to
• Platform-as-a-Service (PaaS) where you cross the line after your code and applications are integrated with outside components, to
• Software-as-a-Service (SaaS) where you abandon all control when you hand over your data

I paint the functions these services control an alarming red. To see why, we must ask: Do they provide assurances?

No. The major public cloud computing providers generally offer no SLAs at all. They accept little or no liability even for the security measures their own advertising claims to provide.

Can we trust them? The short answer is no. Their actual security measures are obscure, vulnerabilities undisclosed, and audits unimpressive.

But each situation is unique and everything relative in risk management. With a water tight raincoat as counter-measure, the hiker need fear no rain. Lightning may be the only residual risk, and that may be acceptable. There is much more to be said about the risks of cloud computing and how one might ride this red tiger with a yellow whip; controlling enough of the data, applications, or virtual machines to accept some residual risks. Another option might be to consider internal clouds or private (community) cloud arrangements that give customers more say.

We’ll say all this at Catalyst North America and more. In our “Flying into the Cloud: Executive Perspectives on Externalized IT” track, we’ll cover practical perspectives on leveraging public clouds. We’ll cover internal or hybrid cloud strategies that maximize our control as we reap the benefits of the industry’s “big switch” to cloud’s elastic, on-demand architectures. And in “Cloud Now: Usage, Practices, and Rewards” I’ll go much more in-depth with “Security Strategies for Cloud Computing.”

Cloud Computing Security and Identity Management SIG Coming Soon

Blogger: Dan Blum

Good morning! I want to announce our plans for a super meeting, and hope that lots of you enterprise security architects and strategists will be able to attend.

EVENT: Catalyst Cloud Computing Security and Identity Management SIG

LOCATION: San Diego

SPEAKERS: Dan Blum, Burton Group; Cloud Security Alliance (TBA)

DATE: July 28, 2009 8:00 AM

Cloud computing alters business risk and limits organizations’ ability to control, monitor, and audit access to their data. The cloud computing security SIG will bring Burton Group analysts, Cloud Security Alliance (CSA) representatives, end user organizations, and leading edge solution providers to discuss identity management and other issues in the rapidly emerging cloud computing security space. It will provide an opportunity for attendees to come up to speed on issues such as:

• How is cloud computing transforming enterprise security programs and approaches?
• How can identity and access management help to enable cloud adoption and enforce policies on usage and administration?
• What architectures and tools work best to project identity to and from the cloud?
• How should organizations integrate cloud and on-premise IdM and security systems and processes?

Locked down desktops

Had a customer inquiry on what my recommendation was for Windows administrative rights on desktops.

My recommendation, and Microsoft’s recommendation is for enterprises to set up managed Windows workstations (i.e. organization-owned and controlled) in the “standard user” configuration.

The pre-requisite for this policy is an IT support infrastructure capable of pushing software and/or configuration changes out to client workstations, either through a tool such as Symantec/Altiris or Microsoft System Management Center, or through remote installations by IT staff depending on the situation and the number of users requiring the changes.

Standard user configuration may need to be tweaked for different types of users, for example, mobile users requiring wireless access or the ability to change time zones. Vista and Windows 7 offer more flexibility than XP; often with XP it has been necessary for administrators to unduly weaken the standard user configuration for “power users.”

There are a few cases where exceptions generally must be made:

1) Client-side application developers or testers that need to frequently adjust operating system settings, and install/reinstall software
2) Knowledge workers or market researchers that can justify a legitimate business need to frequently need to install/reinstall software
3) Users that do not have access to IT support infrastructure

If the IT support infrastructure is lacking or the policy is not strongly enforced, categories (2) and (3) can grow fairly large.

All that said, it may be that the locked down desktop will fall into the minority of what enterprises have to deal with as trends such as telecommuting, partnering, outsourcing, crowdsourcing, and consumerization gather force.

In the coming months, I'll be researching a topic along the lines of "Endpoint Virtualization to the Rescue: Protecting Against Unmanaged Desktops and Mitigating Information Sprawl."

Virtualization Security

Topic: Virtualization Security

Bloggers: Dan Blum, Eric Maiwald, and Drue Reeves

Within Burton Group some industry conversation will often spark an exchange of ideas that span traditional research specialty areas. In this case the hot topic du jour is virtualization security and its impact on data center and security architecture. I’ve captured the essential elements of this conversation in the following series of comments.

Dan Blum, Burton Group principal analyst in security and risk management, kicked off the conversation with:

Interesting discussion with VMWare today. It occurs to me that what VMWare is trying to do with virtualization security is a critical part of architecture for the dynamic data center. Virtualization security is also essential to cloud architecture for most or all layers of the cloud stack.

I’ll replay the discussion for you a bit.

As you know, in our security architecture we rate air gap as the highest surety separator, followed by the dedicated network firewall. Any  “virtual” (VM, VLAN) or other separation mechanism is in a lower class of surety.

For an organization’s private data center it may be wise from a surety perspective to separate/isolate the credit card database (or other high value resource) onto its own dedicated server(s) behind a dedicated network firewall.

For a cloud service provider, however, separating dedicated networks and servers breaks the multi-tenant economies of scale; virtualization is usually the way to go. On the other hand, VMWare argues that maybe private data center = dynamic data center = internal cloud.
I’m skeptical that the virtualization economics are as compelling for a internal cloud = dynamic data center as they are for a public cloud (you should be able to afford more dedication/surety).
However, there could be applications where separating/isolating the high value part demands not just one dedicated server, but many, creating a stronger economic argument to trump surety. Anyway, we agree that it is for the good of the industry to “raise the bar” for surety of virtual network and virtual server separation.

“Raising the bar” for virtual separation is much more than just deploying a virtual firewall. That’s just the start. The “secure cloud strength” or “dynamic data center strength” virtual security architecture would need:

Controlled data center network with outer perimeter and IDS
Physical and virtual server operations and configuration standards, hardening, integrity monitoring
Asset management such that virtual workloads are identified, tracked, managed and protected offline
Distributed policy infrastructure (correct policies maintained by vetted personnel in a framework of role-based administration with separation of duty)
Virtual firewalls on each server enforce the distributed policy, correctly identifying the policy that goes with each workload
Audit to ensure standards maintained

Burton Group’s research director for Data Center Strategies, Drue Reeves responds with:

VMware’s primary cloud architecture focus is at the Infrastructure as a Service (IaaS) layer, so it’s understandable for them to talk about internal clouds. (BTW – Internal/private clouds do exist, if not only for the reason of being able to easily move things to a public cloud. However, Bechtel found it cost-effective to move to an internal cloud model).The rest of the cloud (Platform as a Service -- PaaS, Software as a Service -- SaaS) has a larger architecture in terms of usage and consumption models.

Burton Group’s research director for Security and Risk Management, Eric Maiwald also adds his comments to Dan’s initial thought provoking post:

Keep in mind that the necessary security may involve more than one security objective (confidentiality, integrity, availability, use control, and accountability). The objectives may conflict.

The reason I bring this up is because confidentiality and integrity objectives may push an enterprise toward separation. However, availability objectives may push the enterprise toward distributed, highly connected systems. The use of virtualization may help with availability while negatively impacting confidentiality and integrity.

Dan responds to Drue’s post:

When complex virtual zoning schemes (with all the moving parts I indicated in the previous message) are implemented in a large dynamic data center, integrity and confidentiality may be improved. However, glitches in the complex configuration will hurt all the objectives from time to time and raise costs all the time.

Much easier if there’s no need for security. I know – let’s just pretend to have virtualization security!

Drue responds to Eric’s post:

It’s all about risk management, right? We highlight the advantages and risks, then let IT organizations make the business call.

Actually, I think cloud computing may help in some ways (and hurt in others). Data centers will be transformed into critical applications kept internally, while less critical apps are moved to the cloud.

Eric responds to Drue:

Overall, I think cloud will probably help with availability – providing redundancy and alternative sites (not to mention the better availability within a first class data center) that enterprises don’t want to pay for.

Confidentiality, integrity, use control, and accountability are a harder sell. In the macro sense, these are all degraded initially as you have more people who you may not know with potential access to the data. Assuming that the cloud vendors take appropriate steps to keep the external bad guys at bay, you still have to worry about these insiders. Different vendors may do things to control these insiders but it is still something external to the enterprise that “owns” the data.

Drue closes out this discussion with:

Completely agree.

That’s why it looks like internal clouds will keep critical apps, and non-critical apps are candidates to move externally…thereby creating that “air gap” we talk about.

Interesting.

Stay tuned as we continue this discussion at Burton Group’s Catalyst conference in San Diego, July 27-31, 2009. 

Still Can’t Win the Core Wars: A Report from Black Hat

Blogger: Dan Blum

At Black Hat DC 2009 Rafal Wojtczuk and Joanna Rutkowska of Invisible Things Lab (ITL) presented “Attacking Intel Trusted Execution Technology (TXT).”  The authors claim to have:

• Imperiled the notion that Xen hypervisor (or any program) can bootstrap itself securely on a already-running computer by establishing a dynamic root of trust measurement (DRTM) using the Trusted Platform Module (TPM)
• Hacked the BIOS System Management Mode (SMM), demonstrating that attackers are just as capable of moving “down the stack” as “up the stack”
• Left Intel and/or other vendors with a major homework assignment to overcome design problems in the TXT

If valid, the Wojtczuk and Rutkowska exploits once again demonstrate the fallibility of software-on-software defenses, concerning which I previously posted Can’t Win the Core Wars. That post was about Black Hat 2008 exploits that demonstrate limitations in Data Execution Prevention (DEP) and related protections. This week’s new Black Hat exploits deal additional blows to the defensive team.
ITL’s presentation gave some background on what parts of the TXT are broken, how it was done, and what remains intact. First of all, understand that the TPM has a set of PCR registers that can hold hash values of critical system software modules. As the computer boots, first the BIOS ROM, then the BIOS PCI FLASH, OS boot loaders, and OS kernel load up in succession; the hash of each component’s in-memory bits is checked against the PCR values before continuing to the next. At the end of the process, if each component checks out, you have what’s called a static root of trust measurement (SRTM).

The good news is that ITL’s exploits do not affect SRTM. The bad news is that SRTM isn’t very scalable.  It takes a lot of software to get a general purpose computer going, and even more if one wants to initialize a hypervisor on top of the OS and then yet another OS inside of a virtual machine. SRTM requires initializaing PCR registers with the information to measure every possible piece of code that might be executed since the system boot.

To address SRTM’s scalability issues, Intel’s TXT includes a dynamic root of trust (DRTM) capability. DRTM uses an instruction called “SENTER” (AMD has a similar one called “SKINIT”) to extend a PCR register with the hash of a program to be loaded after the computer has booted.  For example, an initialization program could issue SENTER with the hash of a virtual machine monitor (VMM), load the VMM, and only activate it after the PCR attestation checks out. DRTM is also called “late launch,” and it is intended to transfer a system from an unknown/untrusted state to a known/measured or trusted state. This is a wonderful widget to have for dealing with unmanaged computers belonging to home users, consultants, customers, etc.

But DRTM can be attacked through the System Management Mode (SMM) code, which as part of BIOS is more privileged than OS kernels (ring 0) and hypervisors (ring -1). Think of the SMM as “ring -2.” SMM is loaded before late launch. It can, so to speak, eat your launch, heh. TXT does not repeat the SMM attestation after boot time, and ITL’s research suggests that attestation of running code is not reliable in any case.

Wojtczuk and Rutkowska went on with an entertaining description of their dialogue with Intel. Intel claims that exploiting SMM is hard, but ITL makes it look easy.  Apparently, ITL has broken SMM with multiple attacks, including one with a soldering iron to replace a chip on the motherboard. But the software attacks are easier, and there are multiple SMM bugs. Intel has been informed of these bugs and patched them, but then ITL found new bugs.

Apparently, SMM is large and complex because it must interact with many complex computer components. It must be tuned to each new motherboard and changes often. As such, SMM is a difficult program to harden, validate, and trust. When I asked an Intel representative about the SMM hack, he called it an “industry-wide problem” and said Intel had reached out to CERT to help coordinate repairs.
ITL says Intel’s solution to the DRTM TXT attack will be an SMM Transfer Monitor (STM). As best as I can understand it, STM will virtualize the BIOS so that it can be rebooted during a late launch. ITL said Intel argued persuasively that it could do a better job of protecting STM because it would be smaller and simpler than SMM. But STM does not exist yet, so we must stay tuned.

Editor comment: Don’t you love it when the vendor’s fix to an exploit adds another layer of complexity? They always seem to make software more complex, and then tell us it’s more secure. But at least most of the time, it’s not.

On to the bottom line: Very few, if any, organizations  are using DRTM in any way, shape, or form. However, system management mode (SMM) and BIOS are ubiquitous and exploits against them open a worrisome new front for rootkits and weaken the value proposition for hypervisors. ITL is giving Intel more time for patches before releasing the actual exploits, so it’s too early to tell how effective the countermeasures will be and how many rootkits will crop up in the wild. In the short term, make sure you’re prepared to patch SMM on existing systems and that anti-rootkit defenses cover SMM. In the long term, take vendor claims of DRTM with a large grain of salt.

Consumerization, the White House, and Rockin’ IT

Blogger: Dan Blum

Obama’s White House staff is the latest poster child for consumerization. As described in the Washington Post article Staff Finds White House in the Technological Dark Ages, Obama officials fresh from a campaign of “relentless social networking” finally arrived at the White House, only to “encounter a jumble of disconnected phone lines, old computer software, and security regulations forbidding outside e-mail accounts.”

Consumerization may be a new buzzword, but it’s a well-established phenomena. The “PC revolution” and the “Internet revolution” both rocked IT in the 1980s and 1990s respectively. Many organizations with their heads in the sand suffered badly. Organizations that hampered deployment lost the initial opportunities to fully leverage these productivity-enhancing tools. Organizations that failed to proactively direct deployment ended up with an unmanageable, insecure mess.

Because the consumer market is now much larger than the enterprise market, consumerization will only increase. We’re headed back to the future with:

• Consumer applications such as social networks and other “Web 2.0” technologies
• Consumer smartphones such as iPhone
• User-procured and user-managed computers

It’s time for IT to ride this tiger. Let the Obamas in your organizations use smartphones, let the David Plouffes find fans on Facebook, consider useful apps like Salesforce and all the rest, BUT YOU MUST MANAGE IT. The following are some things to look out for.

As I wrote in iPhone and iTunes: The Thin Edge of Consumerization’s Wedge, consumer applications are not designed for enterprise class security and manageability. They may have vulnerabilities that put the organization’s data at risk. Organizations need to do risk analysis to determine how to manage these vulnerabilities, and push the vendors to cover or eliminate them. It’s also important to develop policy on use control and promote user awareness of the policy.  This can be a cultural issue for users of social networks like Facebook and MySpace that promote a great deal of personal openness that may or may not be appropriate for organizational purposes.

Archival is one of the more difficult deficits of consumer applications and smartphones. Vendors are getting better at helping organizations archive organizational email, but not web mail, text messages, Facebook posts, etc.  Even Obama’s BlackBerry – generally speaking, an enterprise-class device - may not comply off the shelf with laws requiring archival of all White House communications.

User-procured and user-managed computers, however, pose the most difficult consumerization dilemna. Just as de-perimeterization forces IT to shift security features from the network to the endpoint, the business takes control of the endpoint away...

Promoted in the name of cost savings, the idea of user-owned and managed PCs seem like a really bad one from the security perspective. But is it really? IT was already granting access to all kinds of contractors, outsourcers and external partners with unmanaged PCs. “Externalization” is what they’re calling that now, but its been going on for years. Whether we externalize for employees’ or for partners’ sake, we have to manage the risk of unmanaged PCs. Typically this means that other IT assets must be hardened and able to defend themselves. It’s a tricky thing. Security architectures may shift some security features from the network to the endpoint, but application and data architectures must trust the endpoint less.

My Shifting Defenses: Security Futures for Networks, Applications, and Data report considers unmanaged computers and other implications of de-perimeterization and externalization. This document is available to our subscribers or to anyone who registers at the guest link here. And, at the 2009 Catalyst Conference, we’ll be covering topics like desktop virtualization and other technologies that are gradually maturing to the point where they can really make your IT department rock.