Opinions and views from expert CIOZone members.
Tag >> Unisys
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>
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.
-Peter Bye, IT Consultant with Unisys
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.”
“Exfiltration. Confidential data is sent back to the hacker team either in the clear (by Web mail, for example), wrapped in encrypted packets or zipped files with password protection.”
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.
How does this happen?
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.
What can you do about it?
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:
“In over 40% of incidents we investigated, it took attackers a day or more to locate and exfiltrate data. This gives some hope that reasonable time exists for more than one shot at detecting/stopping the incident before data is completely removed from a victim’s control.”
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
Posted by PeterBye in Unisys, IT
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!
-Peter Bye, IT Consultant with Unisys
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.
- Organization and People: This pillar focuses on the culture of an agency and openness of employees to change. For example, it wouldn’t have been unusual for some federal employees in the 1980s to spend 70% of their time in the field, interfacing with clients. With the advent of computers, these same employees became dramatically more office bound – in the field only 30% of the time. This required a culture change at many agencies as employees gradually moved to this new office-based way of conducting government business.Now, utilizing a mobility program, an agency’s goal could be to return those employees to the field by giving them useful mobile devices that allow them to enter data and share information remotely. Focusing on “on the spot,“ “in the field” and “in real time” greatly enhances the time employees need to interact face-to-face with citizens that rely on their government services. But it also requires a culture that accepts new ways of doing business.
- Policies and Governance: This pillar concentrates on what is necessary to move the organization away from outdated and restrictive models, who has the responsibilities of leading that move, and how the changes will be managed through deployment and operations. In some cases, outdated policies that inhibit useful adoption of mobility must be changed. These policies might include: not allowing employees to use their own devices, requiring employees to report to the office every day, requirements to record vast amounts of data regularly, or a policy that forbids Wi-Fi in an office. All these policies need to be addressed thoroughly before a mobility model can be considered. From a governance perspective, the entire enterprise must be invested in the strategy, with a set of leaders who understand the importance of mobility and know what levels of funding and resources are needed to deliver a successful program.
- Business Processes: If an organization’s goal is to move employees to the customer site, processes associated with being “at the right location” and “in real time” must be leveraged. For example, I’m reminded a recent experience when my car was damaged in hail storm. I saw firsthand how my insurance company had dramatically maximized the efficiency of claim agents in the field by using a mobile strategy. My insurance adjuster came to my home with a mobile device, which he used to take multiple pictures of my damaged car and measure the damage. The information was then transmitted to the company’s data processing system, which soon came back with a printout on how much they would pay to repair the car. I signed the printout on the spot, and a check was immediately generated for the body shop. By reengineering its business processes to take advantage of mobile technology, the insurance company improved my customer experience and made its agent more efficient. There’s no reason this can’t be applied to government operations.
- Technology: The focus here is to ensure the organization has the appropriate hardware, software and support services in place. Agencies need to address questions such as: -How do you engage business and IT to deliver a “ship ready” mobile app in 4-16 weeks?-How do you deliver a drop-box tool efficiently, securely and cost-effectively? -How do you implement strong authentication, single sign-on and access controls?-How do you start improving your critical infrastructure when funds for this may not exist?
- Performance Management: A holistic, enterprise-wide goal focusing on “are we making progress?” also is essential. How do you know that on day one, day 90 and at your project’s end that your mobility goals are being achieved? Key performance indicators must be established for areas such as customer satisfaction, employee productivity, cost reduction per service and other metrics.
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.
-Owen Unangst, Director of Enterprise Mobile Computing, Unisys
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:
- Organization & People: Do you have a culture in your enterprise with the willingness and the flexibility to accommodate the change to a mobile workplace?
- Policies & Governance: Do the organization’s policies support the mobility strategy, and are leaders invested in its success?
- Business Processes: To what extent do you need to reengineer your business processes to leverage the benefits of the mobility strategy?
- Technology: How will you ensure that you can provide, operate and maintain the technology needed to achieve your mobility goals?
- Performance: How will you measure the success of your mobility program and keep things on track?
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.
-Owen Unangst, Director of Enterprise Mobile Computing, Unisys
<< Start < Previous 1 2 Next > End >>