Virtualization Policy Project Introduction

Author: Roddy Rodstein, CISSP

Copyright © 2008 - 2012 Roddy Rodstein. All rights reserved.

 

This publication contains information protected by copyright. This publication may not be duplicated in any way without the express written consent of the publisher, except in the form of brief excerpts or quotations for the purpose of review. The information contained herein is for the personal use of the reader and may not be incorporated in any commercial programs, other books, databases, or any kind of software without the written consent of the publisher. Making copies of this book or any portion, for any purpose other than your own, is a violation of United States copyright laws.

 

Every effort has been made to make this publication as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an "as is" basis. The authors and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this publication.

 

The information found in this publication was gathered from many different sources in the computing world. It is provided for informational purposes only. Use common sense in applying these concepts and tips. Screen shots may vary from environment to environment.  Please verify correctness and applicability in a test environment first and then deploy to your production environment(s).

 

 

The Virtualization Policy Project begins with a high level overview of Enterprise Architecture (EA) and concludes with example IT policies. Because Enterprise Architecture is a field unto itself, a detailed review of its principles, processes, and approach is beyond the scope of this publication. The goal of this publication is to explain how virtualization technologies fit within an Enterprise Architecture.

 

The purpose of Enterprise Architecture is to establish an Enterprise wide blueprint used to achieve business objectives while maximizing the business value of information technology. An Enterprise Architecture is a “blueprint” that describes an organization’s strategic direction, security and regulatory requirements, information technology portfolio and their inter-dependencies, baseline and target architectures, and the processes to implement technologies. In business terms, Enterprise Architecture is accomplished by efficiently achieving an organization’s mission with minimal investment in information technology; and in technical terms, by optimizing business operations, effective information technology planning, information technology budgeting, information technology acquisition, human resource utilization, and the implementation of security controls.

 

After the goals and stakeholders of an Enterprise Architecture project have been identified, a framework is selected to help implement and support the Enterprise Architecture through its entire life cycle. There are a number of frameworks, such as Cobit, ISO/IEC 17799, ITIL, and many others that represents a variety of methodologies and toolsets to fulfill the requirements of any size or type of organization. Frameworks provide methodologies, standards, guidelines, and formats that can be used as is or adapted to meet specific requirements. Because organizations have different missions and business objectives, no single framework will be right for each situation. Organizations typically select a framework or a mixture of frameworks to meet their requirements.

 

Enterprise Architecture has well defined principles and processes, along withan approach that generates a comprehensive layered policy infrastructure used to communicate management’s goals, principles, instructions, procedures, and response to laws and regulatory mandates. A policy infrastructure consists of tier 1, tier 2 and tier 3 policies that encompass people, systems, data, and information. A policy infrastructure consists of policies, standards, procedures, baselines, and guidelines.

 

Tier 1 policies are at the top layer of the policy infrastructure and address broad organizational issues, vision and direction. Most organizations will develop and support up to a dozen tier 1 policies. An example tier 1 policy is an Employee Practices Policy or a Conflict of Interest Policy. Global in scope, Tier 1 policies are high level documents that define vision and direction.

 

Tier 2 policies are topic specific, and tier 3 policies are application or system specific. Standards are tier 2 policies that describe system design concepts, implementation steps, and detailed configurations. Procedures are tier 2 & 3 policies that provide step by step compulsory measures, communicating best practices in using information systems and organizational data/information. Baselines are tier 3 policies that are application or system specific and describe step by step instructions to implement technologies. Guidelines are tier 3 documents, offering application, system, or procedural specific best practices. Guidelines are recommendations unlike policies, standards, procedures, and baselines, which are compulsory.

 

Figure 1 shows the organization of Enterprise Architecture’s layered policy infrastructure.

 

 

Figure 1 represents Enterprise Architecture’s layered policy infrastructure, starting with tier 1 policies which address broad organizational issues, vision, and direction. The next layer, General Organizational Policy, consists of tier 1 policies in which management makes security statements, explains roles and responsibilities, and defines which assets are considered valuable. The following layer, Practical Implementation Policies, contains tier 2 and 3 policies which are topic, application, and system specific and are used to enforce upper layer policies. The lower layer consists of tier 2 and 3 policies which are topic and technology specific and are used to enforce higher layer policies.

 

Figure 2 shows the work flow of a policy infrastructure.

 

 

A policy infrastructure contains confidential information relating to running a business and the publication, distribution and storage of that information should be strictly monitored. Many organizations leverage the human resource department and secured intranet solutions to distribute and control access to policies.

 

An Enterprise Architecture groups together infrastructure components within topic specific domains. An example of Enterprise Architecture domains are infrastructure, applications, network, and security. After an organization has defined its Enterprise Architecture domains, all infrastructure components are grouped within their corresponding domain and reviewed individually and as a single cohesive unit. Layered policies are developed for each domain and each individual technology within a domain.

 

Table 1 shows the Enterprise Architecture domain structure that will be used throughout this publication. The example encompasses five domains split between two high level groups; infrastructure and applications. The five domains are platform, network, software, data / information, and security.

Enterprise Architecture Scope
Infrastructure	Applications
Platform	Software
Network	Data/Information
Security

An organization’s mission and business objectives drive its Enterprise Architecture domain structure. As we have all learned, there is no ‘one size fits all’ with information technology, and Enterprise Architecture is no exception. Enterprise Architecture is flexible and can be molded to suit any organization’s mission and business objectives.

 

Table 2 shows a variation of the above Enterprise Architecture domain structure.

Enterprise Architecture Scope

Platform

Network

Software

Data/Information

Security

Access Domain

Integration Domain

Privacy Domain

Project Management Domain

Systems Management Domain

Each of the domains within an Enterprise Architecture will have its corresponding layered policy infrastructure, with tier 1 & 2 policies, tier 2 & 3 standards, procedures, baselines, and guidelines.