Home > Blogs > VMware Operations Transformation Services > Monthly Archives: November 2015

Monthly Archives: November 2015

Organization Transformation for Network Function Virtualization Infrastructure-as-a-Service

Enrico MontarioloBy Enrico Montariolo

Network Function VirtualizationThe evolution of technology can have significant influence on the future success, or failure, of companies that operate within an industry. Traditional communications service providers face this challenge today. The technologies driving this transformation are Cloud, Network Function Virtualization (NFV) and Software Defined Networking (SDN). Communications service providers (CSPs) look at the NFV model and see new ways to accelerate innovation, create competitive advantages, reduce cost and drive new business models.

Successful transformation requires that CSPs also evolve their operating model: evolving related roles, organizational structure, skill sets, processes and culture to reflect the reorientation of the company. We strongly believe that the “As-a-Service” cloud-based operating model is the right operating model to achieve the full benefits of agility, operational efficiency, faster time-to-market and cost reduction, as successfully demonstrated by early adopters like Google, Facebook and Amazon. These early movers are at a tremendous advantage. CSPs may be at risk if they don’t aggressively embrace As-a-Service capabilities.

Read this white paper for a thorough examination of the impact Network Function Virtualization will have on organizational structure and guidance on operating model transformation to NFV Infrastructure as-a-Service.

========

Enrico Montariolo is an Operations Architect with the VMware Global Professional Services and is based in Milan, Italy.

IT Transformation and Organizational Process Maturity

John WorthingtonBy John Worthington

Regardless of what process framework you use, and especially if you’ve done some ‘adaptation’ of processes, building process capability over the long haul goes hand-in-hand with building the organization’s process maturity.

Having thought about my comment, ‘so go ahead, adopt and adapt’, in one of my previous posts I thought further discussion might be in order.

Measuring Organizational Process Maturity

Based on the ISO standard[i], an organization’s process maturity is measured by establishing base and extended process sets at each stage of maturity. These base and extended process sets are tailored based on the domain and scope of the assessment and/or client-specific requirements.

For example, if a company decided that process A, B and C are critical to achieving organizational objectives they may determine that these represent the base process set. They could not achieve a process maturity of Level 1 (Basic) unless process A, B and C all met a Level 1 process maturity.

At Level 2, the organization may determine that there are additional processes that must be established. These would represent the ‘extended process set’ at a Level 2. To reach an organizational maturity of Level 2 (Managed), both the base and extended process sets would need to achieve Level 2 process maturity. Additional extended process sets might be added at higher levels of maturity as shown in the figure below.

Process Maturity

Process Capability versus Maturity

Capability

Process capability is focused on the ability of the process to achieve its desired outcomes based on business objectives. The process ‘base’ practices are directly related to the process objectives; which means the base practice attributes of a process are different for each process. So rating the degree to which each process expected outcome is met (or not) is a quick way to provide insight to its capability, which may (or may not) be adequate for a given organization’s business objectives. An example for Incident Management is given below. (Note: A formal process assessment will also review the process inputs/outputs, supporting people/technology and other evidence

Process Maturity

Process Capability Attribute  – Incident Management
(i.e., objectives/process desired outcomes)
Rating
An incident and service request management strategy is defined and implemented
Incidents are reported, prioritized, analyzed for business impact, classified, resolved and closed
Customers are kept informed of the status and progress of their incidents or service requests
Management of potential service level breaches are communicated to and agreed with the customer
Incidents which are not progressed according to agreed service levels are escalated by customers

If all the objectives of the process are either Largely or Fully achieved, the process will meet Level 1 (performed) requirements.

Maturity

Process maturity attributes apply to all processes, and are considered ‘generic’ attributes. These ratings are usually taken across a group of processes (such as the base and extended process set). Each level of process maturity builds on the next:

  • Level 1 – Performed (Process Performance)
  • Level 2 – Managed (Process Performance Management, Work Product management)
  • Level 3 – Established (Process Definition, Process Deployment)
  • Level 4 – Predictable (Process Measurement, Process Control)
  • Level 5 – Optimizing (Process Innovation, Process Optimization)

How mature are your processes?

Download this simple exercise using the ISO standard generic process attributes. Identify what you feel would be your ‘base process set’, and if you want a ‘extended process set’ as well. Then answer these questions for each process.

Organizational Process Maturity and ITaaS Transformation

Each organization has different starting points, different goals and objectives, and different levels of capability/maturity. So while we can effectively leverage our extensive experience with ITaaS transformations, each transformation path will be unique.

As processes are adapted along an ITaaS transformation path, changes in process boundaries, roles, controls and supporting technology can dilute organizational process maturity. This is another reason why ‘slow and steady’ may win the IT transformation race; frantic attempts to speed up the hill (again and again) increase the costs associated with the transformation effort an ultimately exhaust IT staff.

So go ahead, ‘adopt and adapt’, but be careful to maintain your hard-earned gains in organizational process maturity.

[i] ISO15504 – http://www.iso.org/iso/catalogue_detail.htm?csnumber=54175

=====================

John Worthington is a VMware transformation consultant and is based in New Jersey. Follow @jMarcusWorthy and@VMwareCloudOps on Twitter.

5 Steps to Build a Security Strategy for the Digital Enterprise

From team bonding to micro-segmentation: a 5-step journey to develop a proactive security mindset in your cloud organization.

Pierre Moncassin-cropBy Pierre Moncassin

Only a few years ago security was at best an afterthought for some cloud teams., Everyone in the team thought that security was someone else’ s problem. For some less-fortunate organizations, this mindset did not change until a major security breach occurred with resulting financial losses, reputational damage not to mention job cuts. By that point security did becomes everyone’s problem – but that realization happened far too late.

To avoid this sort of less-than-optimal scenario, let me share here what I see as some key steps to develop security mindset right at the core of your cloud organization

First, why is security in the cloud specifically challenging?

IT security risks have of course existed well before the cloud era. However cloud technologies have brought along a new dimension to the risk. Reasons include:

  • Due to unprecedented ease and speed to provision infrastructure, a new population of business users have become able to provision their own cloud infrastructure. They may not all be fully aware of the corporate IT security guidelines (or may not feel bound to follow them strictly).
  • Fast provisioning in the cloud has often led to a proliferation of “temporary” workloads – many of which are not rigorously controlled.
  • Data in the cloud can be stored anywhere. Users are usually not aware of where their data is located physically, or have no control over that location. Therefore protecting confidential data becomes an additional challenge. Some country legislation, for example, mandate that confidential data from their nationals must remain within designated geographies.

Step 1: Build a broad awareness and knowledge base.

All cloud team members need to understand the basics of security for their cloud platform. That includes not only the enterprise security policy, but also a broad awareness of relevant laws (e.g. data protection) and compliance requirements (e.g. PCI, Sarbanes Oxley).  It also helps to build some basic awareness of common security breaches. In order to incentivise this learning, consider including security training in personal objectives (also known as ’MBO’); include security awareness in new hire onboarding and individual training plans.

Step 2: Break down technical silos

As I explained in on my recent blogs, technical silos occur quite naturally as specialists organize themselves along groups of expertise (networks and servers, operating systems and hardware). However entrenched silos can easily cause gaps in security coverage. This is because hackers are experts at finding fault lines between silos – those tiny gaps or fault lines from which they can launch an intrusion.  They will look for the ‘weakest link’ wherever it might be found (e.g. access password too simple, un-patched operating system patch, lax email security, defective firewall  – the list of risks is long).

Instead of relying on a silo mentality, the team needs to consider security end-to-end, and assume that breaches can occur in any layer of the infrastructure. In the same way as cloud services need to be designed end-to-end across silos, teams need to work together to manage security risks.

Step 3: Involve the business stakeholders

Part of setting up a cloud organization with VMware’s model, involves building close working relationships with business stakeholders. Specific roles within VMware’s cloud organization model will be in place to liaise with the business (eg Service Owner, Customer Relationship Manager).  And security is a key part of this cooperation. Some key aspects are:

  • Establish clearly responsibilities (e.g., who patches the workloads? who checks compliance?)
  • Document the responsibilities and expectations e.g. within the service level agreements;
  • Ensure regular communications about security between business users and cloud team (e.g. are there security-critical applications? Confidential data? What level of confidentiality?)

Step 4: Automate day-to-day security & compliance checks.

As part of operating a VMware cloud, the team will most likely be using tools such as VMware’s vRealize Automation and vRealize Operations Manager. These tools can be configured and leveraged to enhance some of your security and compliance procedures – adding much-needed automation to routine, day-to-day activities that otherwise consume effort and attention. Here are some examples of steps your teams can take to leverage these tools for security & compliance.

  • Ensure that provisioning blueprints are up-to-date with the latest security policy (e.g. patch levels).
  • Configure vRealize Operations Manager’ dashboards to display an aggregate view of compliance risk across your virtual infrastructure. For example, vRealize Operations Manager can be configured with extensions and third party integrations that allow to extend its analytical capabilities across a broad variety of sources including VMware Cloud Air, VMware NSX, Amazon AWS, NetApp Storage (for further details check out: http://www.vmware.com/files/pdf/vrealize/vmware-vrealize-operations-management-packs-wp-en.pdf).
  • Leverage vRealize Operations Manager’ ability to automate and report on compliance checks (the technical capabilities are described in more detail in this VMware blog: https://blogs.vmware.com/management/2015/03/compliance-in-vrealize-operations-6.html).
  • Leverage the potential of automated integration with your support desk. Once detected, compliance or risk issues must be acted upon. These events can be automatically associated to the creation of an incident ticket. I have outline the potential of such integrations in an earlier blog  https://blogs.vmware.com/cloudops/2015/09/cloud-itsm-integration.html
  • From an organizational point of view, what we want is to automate as far as possible the bulk of routine compliance checks and security monitoring, so that the teams can focus on the ‘big picture’ work pro-actively to identify emerging security threats

Step 5: Shift paradigm on network security with micro segmentation.

Whilst the expression “paradigm shift” has been much over-used, it still fits perfectly to describe the evolution from traditional network security to micro-segmentation.

The traditional approach to securing a private cloud’s network is to setup strong security (firewalls) at the perimeter. This is the fortress model of security – highly protected boundaries (perimeter) and a gate to control traffic at the entrance.

The downside is that all “fortresses” share a weakness by construct. To understand why, let’s consider the typical stages of a data breach:

  • Intrusion: attacker finds a breach in the perimeter
  • Lateral Movement: the intrusion is expanded for example, by compromising neighboring workloads or applications.
  • Extraction: potentially sensitive data from the compromised systems.
  • Cleanup/deletion: the intruder attempts to remove traces of the intrusion (deleting log files etc.).

Security Data BreachIn the event where an intruder manages to pass through the security gate, moving from room to room within the fortress becomes relatively easy. In IT terms, once a network’s perimeter is breached and a first workload is compromised, the intruder can often move “laterally” to compromise other workloads with little or challenge, then locate potentially sensitive data to retrieve (‘Exfiltrate’).  There may be other lines of defense within the fortress (traditional network) – but these tend to be static, and once broken the same problem of “lateral mobility” occurs again.

Micro-segmentation allows fine-grained network security that can prevent not only the initial intrusion, but challenge attempts the other stages i.e. Lateral Movement Exfiltration, Cleanup.  The reason is that each ‘room’ (or workload) can be isolated from the other. We could compare this new model to the layout of submarine where each section of the ship is partitioned by watertight doors. Each compartment  (micro-segment) can contain an intrusion. The would-be intruder is just as challenged to move from one compartment to the other, as getting past the entrance door in the first place.

However micro-segmentation means more than fine-grained network isolation. It offers the possibility to tailor security policies down to the workload level, therefore increasing to a new level the control over cloud security.

For example, network security rules can be associated to logical objects like a workload. When the workload is moved from a network location to another, the security rules are maintained – they ‘follow’ the workload rather than being attached to a fixed network address.

Security Rules

Leveraging that potential requires a new mindset – shifting from a static security model to dynamic, fine-grained security. It also requires the cloud team to develop new skills. For example to replace routine configuration skills with automation, traditional network skills need to be complemented with design and programming skills.

Key take aways:

  • Think of security as by essence, teamwork. Encourage your team to coordinate security across silos – users, cloud engineers, security teams.
  • Leverage your automation tools such as VMware vRealize Automation and vRealize Operations Manager – they will help automate some of your security and compliance procedures.
  • Transform your team’s perspective on network security by leveraging micro-segmentation, moving from the traditional ‘fortress’ security model to a dynamic, fine-grained approach.

—-
Pierre Moncassin is an operations architect with the VMware Operations Transformation global practice and is based in the UK.