By Michael Salsburg, chief architect, Cloud Solutions, Unisys

Although we often talk about “the cloud” as if it were a homogenous entity, private cloud computing is very different from public cloud. 

As such, an enterprise that has chosen to implement a private cloud has chosen that model because it has very specific service and compliance objectives that cannot be addressed by a public cloud. 

Most private clouds are good at spinning up virtual machines in a “cup dispenser” style. You can get cups in various sizes and colors, but the focus is on standardization and automation of the basic infrastructure. However, a lot of organizations don’t realize that most private clouds aren’t necessarily architected to address key application requirements or manage critical governance, risk and compliance issues. 

In most cases, many of the unique attributes needed to support an enterprise-class deployment are not available from the “standard” cloud management environment. This is due to the fact that cloud computing is still in a nascent state. For example, Amazon’s Elastic Compute Cloud (EC2) went into full production in October 2008. Back then, watching someone demo infrastructure-as-a-service was like watching a parlor trick:

Demonstrator: “Please tell the audience – have I ever met you before?”

Spectator: “No, you have not.”

Demonstrator: “OK – please select a service – any service – from the catalog and tell me what it is.”

Spectator: “It’s a Windows 2008 server.”

Demonstrator: “OK – now watch that my fingers do not leave my hand.”

<Relatively short pause>

Demonstrator: “… and here’s a lovely VM for the pretty lady.”

<Demonstrator exits stage left to thunderous applause>

Sound familiar? 

A few years later, we moved past the initial awe of the cloud and recognized its game-changing implications within the enterprise. Although “Utility Computing” sounded like a good idea, it required a service-oriented approach as well as the proof point (provided by Amazon) to appeal to the stakeholders who, up until 2008, insisted they had to hug their servers for dear life. Around 2010, savvy CIOs were “kicking the tires” by using cloud computing to automate a particularly operational-intensive part of their workloads – test, development and demonstrations.  

But now, the industry is moving beyond the “kicking the tires” stage and stepping up to critical enterprise applications. We have moved beyond merely supporting test, development and demonstration workloads and into supporting production and mission-critical workloads. Just as our effort to standardize and virtualize the previous workloads was non-trivial, neither is this next step.

 

Enterprise applications are, for the most part, sponsored by “Application Owners” within business units. In cloud terminology, we define a “tenant” in a cloud as the owner of a specific partition of the cloud that is dedicated to that owner. Each of these tenants has very specific governance, risk and compliance objectives. For example, compliance with minimal response times may be a requirement to reduce the risk of impacting the corporate image. High availability may be required to avoid the risk of non-compliance regarding the delivery of services to customers. Security compliance may be an issue for an application owner who is required to protect sensitive, regulated information. 

 

Certainly, a separate cloud could be created for each application owner, but then we would be right back where we started, with dedicated, underutilized resources, a lack of standardization, and escalating administrative expenses. Instead, a robust private cloud solution is capable of providing disparate service and compliance objectives for the various applications within a single, automated environment.

I’ve always said that discussions between business and IT people at the planning stage of IT projects are critical to success. However, the fundamental difficulty is that IT and business people do not understand each other well enough – they do not speak the same language. Let’s consider the business implications and suggest how the two parties can bridge the gap.

‘Discussion’ is a conversation: two or more parties exchange views and ideas, arguing about them, trying to reach common ground and a conclusion. The absence of a common language means that there are parallel monologues rather than an exchange. There is no communication and hence no common ground or conclusion. This is obvious in the case of natural languages, but equally a problem with specialist vocabularies, such as IT’s.

If the business and IT people do not communicate, the business may view the IT organization as unresponsive, slow and expensive, holding the business back while being a drain on resources. On the other hand, IT comes to see the business as overly demanding, with unrealistic expectations – especially because, in IT’s opinion, it is too tight with money. 

These problems are not universal but occur frequently enough to be a source of concern.

And the gap in understanding can and does have serious consequences. Projects significantly underachieve and ill-considered, large-scale projects start for no good reason. 

The following case from the public sector illustrates my point.

The British politician Jack Straw was Home Secretary for a time during the UK’s 1997-2010 Labour governments. When he took over the Home Office, he encountered an IT project experiencing major problems with highly visible external consequences.

In his memoirs (Last Man Standing, MacMillan, 2012, p 295), Mr. Straw quotes the chairman of the Public Accounts Committee (a parliamentary watchdog) as saying that in this case and in many others there had been a “horrible interface” between civil servants who “understand all there is to know about, for example, the National Insurance system but know little of how a computer works, and the technicians who know just the reverse. They don’t spend enough time at the start of a project explaining where they are both coming from.”

The private sector is equally guilty, but much better at hiding the consequences.

So what can be done?

Like many real problems, there is no quick fix available, but that does not mean that we can’t do anything. It is essential to recognize that the problem of mutual miscommunication based on misunderstanding is a real one. Each side can then make determined efforts to find out more about the other. For example, the business should come to view IT as a significant player in the enterprise, ideally with board-level representation.

One clear starting point for resolving the issue is engaging an advisory service, which brings together representatives from the business and IT to review the current state of the IT environment and the desired future state to meet evolving business needs. 

In these mediated discussions, both business and IT groups often realize where and why each views thing differently, reach a common understanding based on reasonable accommodations, and improve future communication as a result.

So while IT and business people may never speak exactly the same language, they can definitely work to create a common set of assumptions. That common vocabulary can enable each side to consistently understand the other’s position and achieve mutually satisfactory and beneficial business outcomes from strategically important IT projects.

 

Multiple choice: Exfiltrate is . . .

1. What’s left over after your filter removes harmful substances. “Harry, I think you better change the water filter. The exfiltrate looks cloudy.”

2. Removal of a layer of carbon atoms. “Professor, was it hard for those Nobel Prize winners to exfiltrate the graphite to get graphene?”

3. To leave a locale to escape prosecution. “Rocky, me and the boys gotta exfiltrate ‘cause things are heating up here.”

4. Someone wanted for crimes in another country. “Canadian officials arrested three exfiltrates and returned them to the United States.”

5. To observe from the outside. “We couldn’t infiltrate the organization, but with modern surveillance equipment we can exfiltrate them.”

6. To obscure classified information. “We finally got a letter from Johnny, but it was so heavily exfiltrated that there weren’t any complete sentences.”

If you selected (1) through (6), you’re just guessing. Although there are other definitions of exfiltrate—some similar to the foils above—the one we’re interested in today is “(7) to take sensitive data out of a victim’s environment.”

Here’s the way Symantec describes it in their white paper, Anatomy of a Data Breach: Why Breaches Happen and What to Do About It :

Exfiltration can be done at the hands of an insider—perhaps a dishonest employee or a well-meaning but poorly trained worker tricked into sending data that should remain confidential—but for this article I’d like to concentrate on exfiltration resulting from outside attacks.

Well-organized criminal enterprises store large amounts of captured data on exfiltration servers, where it is picked up later by retrieval agents. These servers could be systems outside the targeted enterprise, accumulating the smaller packets, or they could be compromised servers within the victim’s enterprise. The data could be escaping disguised as email, PDF files, .doc, .xls, CAD, graphics files or other common types with hidden payloads.

It starts with attackers getting into a company’s systems. Stolen login credentials and spyware such as keystroke loggers are two of the most common incursion methods.

Next, the attacker or software operating on his behalf sniffs around electronically to locate valuable confidential data. Then, the information is typically copied to exfiltration servers. The final step is retrieval of the information by the attackers, who are now poised to sell it to the highest bidder or to use it themselves.

Start by taking steps to prevent the initial incursion. For example,

• Establish and enforce policies for secure storage and handling of confidential data.

• Train your staff on basic security procedures.

• Use hacker frustration features and other techniques offered by many software providers to make it harder for an attacker to gain system access.

• Deploy malware prevention software on your Internet-facing systems.

Also make sure your important data is protected. For example,

• Use Guard Files and Automatic Content Recognition tools to restrict access to the data.

• Encrypt the data so that if it is exfiltrated without the encryption keys, the attackers will not be able to read it.

Then, monitor for suspicious activity and be prepared to take quick action. For example,

• Monitor outbound traffic. You don’t have any clients in the Far East, but you see data periodically going there from your networks? Hmm.

• Identify suspicious data on your servers. What about those RAR files (an archive format developed in Russia and popular there) that appeared a couple of weeks ago and seem to be growing in size? Hmm, again.

• Identify suspicious system behavior. Network traffic peaked at 3:00 a.m., when nothing significant is running on the system? Hmm, once again.

Of course, if the attackers have gotten into your servers, you might figure that the game is up and you’ve lost all your proprietary information. But that’s not always the case. Sometimes attackers don’t immediately find and exfiltrate the data they want. Verizon’s 2012 Data Breach Investigations Report  includes this somewhat encouraging statistic:

Furthermore, the types of attacks known as Advanced Persistent Threat involve malware agents that remain on your servers and continue to steal your data over a period of weeks, months, and longer.

So even though competitors halfway around the world might be looking over your plans for the Model One Outboard Turfenfoil today, you still can thwart their attempts to learn about the Model Two if you apply diligent security measures that prevent further exfiltration.

 

-Glen Newton, Security Architect, Unisys  

The success of IT projects is commonly measured by three metrics: did the project deliver on time, within budget and do what it was asked to do? Although there is some controversy over the scale of the problem, there is little doubt that significant underachievement in one or more of the three metrics wastes vast amounts of money. A glance at some of the high profile examples reported in the press shows just how much.

As might be expected, much effort is spent in trying to identify the root causes of partial or complete failure. It appears that there is no single dominant cause. Factors such as unclear and changing requirements, lack of management commitment, selection of the wrong technology and plain incompetence are variously thought to be the culprits.

However, there is one factor, IT procurement, which may lie behind a number of apparently different causes of problems. Procurement processes include formal procedures to be followed in procuring products and services. Other factors, to do with attitudes and ways of doing things, also influence procurement decisions.

I suggest that although procurement processes are almost always established with the best of intentions – primarily getting value for money – they may perversely achieve the opposite. In particular, I believe they often have negative results because they obstruct essential discussion at project inception, and so compromise the entire project. I’ll try to explain why.

IT projects today can be quite complex, involving new developments and integration with existing systems, both within an organisation and externally. The requirements may not be clear. This is not necessarily anyone’s fault; there may just be uncertainty about what can be done with the technology and budget available.

All this points to a need for extensive discussion early on, before procurement decisions are finally made. People who understand the business requirements and the technology available have to get together to decide the best possible approach. Small proof-of-concept projects may be required to test ideas and gather information, for example to explore what can be done with new technologies.

Procurement processes can make these discussions next to impossible. Invitations to tender may require sealed bids. Questions may have to be posed in writing or in vendor conferences, with the answers made available to all bidders. All this is done in the interest of fairness, to avoid bias.

The result is that procurement decisions may be made without a basis of adequate understanding. In an effort to win business in difficult times, vendors keep prices low in spite of the uncertainty, with a hope of renegotiation later. The result is all too likely to be significant underachievement in one or more of our metrics.

It need not be like this. Here are some suggestions to improve the situation.

First, the need for upfront discussion and experiment is critical. It could at least in part be built into the procurement process, before a contract is awarded, perhaps paying the costs of losing bidders. This is expensive but could ultimately save costs by increasing the success rates of projects. The approach is in fact adopted in some cases, for example for large defence projects.

A second option is to allow greater flexibility at the start of a project, so that the necessary discussion and proof-of-concept projects can take place. An initial fixed price impossible, but subsequent implementation projects could be done at a fixed price. Again, the likelihood of greater success rates, with fewer overruns of cost and time, would make it worthwhile.

But perhaps the fundamental difficulty is that IT and business people do not understand each other well enough – they do not speak the same language. That’s a subject for another time!

 

 

In my previous post, I briefly outlined my “five pillars” underlying a successful mobility strategy. I wrote that organizations must address the following five areas as a foundation of their mobility program: organization & people; policies & governance; business processes; technology; and performance management.

In this post, I would like to go into more depth on each of these five areas.

 

Most experts agree that mobile devices and applications present a goldmine of opportunity for organizations to make their employees more productive and their clients happier. By focusing on these five pillars, enterprises can help to ensure that their mobility strategies are well-defined and likely to achieve their goals.

 

 

 

 

As Unisys’ third annual Consumerization of IT research study indicates, the growth of mobile device use in government and the private sector continues, with 44% of workers now using smartphones at work – a 300% increase from three years ago, according to Forrester Consulting, which conducted the study for Unisys. Tablets, which were rarely used at all two years ago, are now used by 15% of the global workforce.

Driven by this evolution of end-user mobile devices, information workers (iWorkers) are driving their organizations efforts to create new ways of conducting business. The new wave of productivity isn’t just driven by devices, either:  tech-savvy are also using a broad range of consumer technologies, including self-procured application tools to get things done in the workplace. These consumer technologies are fast becoming iWorkers’ primary means of staying informed, connected and productive, both professionally and personally.

As a result, organizations must embrace this new world. In doing so, they can mobilize their businesses, transform their operations and modernize their technical infrastructures.

Establishing an effective vision, building a lean strategy and achieving objectives that benefit the organization’s mission, however, are often elusive tasks.  To achieve these goals, organizations need to have a mobile business enablement strategy that focuses on five key “pillars of success.”  These are represented in the following graphic:

 

In order to take a holistic approach to implementing a mobility strategy, organizations should assess their readiness to align each of these five pillars to the objectives of their mobile business model:

These five pillars are interrelated and sometimes overlap, but they are all essential aspects of a mobility strategy. In subsequent posts, I will dive deeper into each of these five areas.