The Oracle Cloud Cookbook
Copyright (C) 2014
All rights reserved.Distribution of the Oracle Cloud Cookbook or derivative of the work in any form is prohibited unless prior permission is obtained from the copyright holder.
OBJECTIVESAdvances in virtualization, hardware and storage technologies, along with Oracle licensing costs are driving Oracle customers to evaluate their virtualization options for Oracle to lower their total Oracle cost of ownership, and to improve their Oracle operational efficiency.The Oracle Cloud Cookbook intends to articulate the design considerations and validation efforts required to design, deploy and support private, public and hybrid Oracle clouds.
Oracle Cloud Reference Design
This guide presents Mokum's Oracle VM Private Cloud Reference Design. The Oracle VM Private Cloud Reference Design encompass the software, hardware, storage, network, and management components required to deploy a scalable, secure, and supportable Oracle VM 3.x private cloud.
The Mokum Oracle private cloud reference design is a field-tested best-practice standard, designed with simplicity, reproducibility, usability, scalability, supportability and security. The Mokum Oracle private cloud reference designs represent a complete Oracle Private Cloud standard that can be leveraged as a vanilla solution or modified to more accurately reflect organization-specific needs.
The Mokum Oracle private cloud reference design provides a well defined starting point for each Oracle private cloud implementation. It also serves as a baseline upon which all solution additions, revisions, and tools will be based. As such, there is an increasing value to Mokum Oracle private cloud reference design in keeping implementations as close to the reference design as possible.
Support is an integral part of any Oracle private cloud and includes a combination of Oracle support agreements and on-site and off-site support from the implementing party. Administrators will have several options for support, including live assistance, phone support, and web forums.
The following sections provides the decision matrices for the Mokum Oracle private cloud reference design. Implementers of the Mokum Oracle private cloud reference design can use the decision matrices as quick reference guide to identify settings and configuration decisions to be implemented in the environment.
The server hardware for your Oracle VM environment is a critical component in the success of your Oracle private cloud project. Oracle’s virtualization portfolio includes software only solutions that fall into the build your own option with Oracle VM for x86 software and OpenStack on commodity x86 hardware, and the buy option with select Oracle VM enabled Oracle engineered systems such as Oracle Exadata X5-2, Oracle Database Appliance, Oracle Exalogic, and the Oracle Private Cloud Appliance.
The first step in selecting an Oracle VM hardware platform is to size the server hardware, followed by calculating the total number of servers required to be in each Oracle VM server pool. The formula to calculate Oracle VM server sizing is: The total aggregate virtual machine CPU, RAM and Storage requirements plus your N+x availability requirements provides the total server count along with the server hardware and storage requirements.
Oracle VM uses the concept of a server pool to group together and centrally manage one or more server pools from one or more Oracle VM Managers. If more than one location exists, Oracle VM server pools may be dispersed to different locations and be managed via a local installation of Oracle VM Manager, or centrally managed from a single Oracle VM Manager.
The security controls used to secure Oracle VM are similar to the security controls used to protect your existing physical and virtual IT resources. As with physical and virtual IT resources, securing Oracle VM is dependent on the security posture of each of its components, from the design, hardware, hypervisor, network, and storage to the virtual machine operating systems and installed applications. In short, if the organization has a security policy for virtualization, networking, storage, operating systems and applications, the security policies could and should be applied to Oracle VM.
For decisions that rely on preexisting factors or specific organizational needs, the appropriate best practice will be discovered in the infrastructure assessment (IA) and gap analysis (GA). The best practices should be analyzed carefully and decisions should be made based on organizational needs, existing architecture, and budget resource availability.
A key component of a successful Oracle VM deployment is acquiring and vetting new releases, patches and updates for production systems. New Oracle VM releases, patches and updates must be researched to identify which release, patches and updates are applicable to your environment. Newly released versions, patches and updates should be vetted before being deployed into production.
This table outlines the decision points for the for virtual machine operating systems hosted on Oracle VM. For decisions that rely on preexisting factors or specific organizational needs, the appropriate best practice will be discovered in the infrastructure assessment (IA) and gap analysis (GA). The best practices should be analyzed carefully and decisions should be made based on organizational needs, existing architecture, and budget resource availability.
The best practices should be analyzed carefully and decisions should be made based on organizational needs, existing architecture, and budget resource availability.
This chapter of the
introduces the Oracle Private Cloud Security guide. This chapter applies to all Oracle technology products.
Table of Contents
The goal of this chapter of the Oracle Cloud Cookbook is to provide a broader understanding of how Oracle VM fits within an Enterprise Architecture. The chapter startes with a brief introduction of Enterprise Architecture to illustrate how Oracle VM fits within an Enterprise Architecture, followed by numerious example policies and standards.
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 in 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 t infrastructure and applications. The five domains are platform, network, software, data / information, and security.
Enterprise Architecture Scope
Infrastructure
Applications
Data/Information
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
Data/Information
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.
To gain a broader understanding of how Oracle VM fits within an Enterprise Architecture, the next sections will review tier 2 & 3 policies from the platform, network, software, data/information, and security domains.
The platform architecture domain defines the roles, policies, standards, and decision-making criteria for the acquisition and deployment of all computing and data storage hardware and operating systems for servers, desktops, and handheld devices. The platform architecture domain policies start with a definition of high level platform architecture requirements and cascade down to hardware standards and operating system installation and configuration. High level policies from the platform architecture domain include the Platform Architecture Policy and Platform Infrastructure Standard, which establish the foundation for lower layer policies.
List 1 shows a partial list of the layered policies within the platform architecture domain.
Platform Architecture Policy
Platform Infrastructure Standard
Server Standards
Server Virtualization Policy
Oracle VM Server Standards
Oracle VM Security Policy
Hardware and Software Sunset Policy
Note: An organization’s policy infrastructure directly reflects its unique mission and business objectives. The above list is for educational purposes only.
At the top of the platform architecture domain policy infrastructure sits the Platform Architecture Policy. The Platform Architecture Policy is a big picture tier 2, non vendor specific document, which establishes high level platform architecture requirements that define the acquisition and deployment of servers, end-user devices, and storage technologies. Lower level tier 3 policies define vendor specific technologies, outlining system-specific or procedural-specific standards and requirements.
Many of the lower level tier 3 policies define the controls that govern the acquisition and deployment of the hardware and operating system upon which Oracle VM and hosted workloads will run. They also define data storage and personal computing devices requirements. During the development and periodic review of platform architecture policies, virtualization platforms and supporting technologies must be carefully considered to ensure interoperability, integration, and security.
The next example is a platform architecture policy. The goal with this example is to illustrate the relationship between a high level tier 2 platform architecture policy and Oracle VM. This policy is intended for informational purposes only.
Purpose and Scope
The purpose of this policy is to establish platform architecture requirements which control the acquisition, use, and management of server, personal computing devices, and storage technologies. This policy provides controls that ensure Enterprise issues are considered along with business objectives when making computing platform related decisions. The scope of the platforms in this policy includes servers, personal computing devices and storage systems.
Platform Architecture policies, standards and guidelines will be used to acquire, design and implement servers, personal computing devices, and storage systems.
Responsibilities
The CEO and CIO ensure that policies are followed in order to establish contracts, review procurement requests and to develop and manage services.
Platform Architecture Goals
The goals to employ computing platform controls are to:
Ensure that platform devices support industry-wide open-standards and seamlessly interoperate with other platform devices, operating systems, storage technologies and embedded security.
Meet business objectives through greater efficiencies in the acquisition and use of computing platforms.
Ensure the availability of tools in order to meet business objectives, security, management and productivity requirements.
Platform Architecture Categories
Platform Architecture categories address servers, personal computing devices and storage technologies, including their hardware and operating systems. Platform Architecture categories include Servers, Personal Computing Devices, and Storage.
A server is a computer that provides services for other computers. Types of servers include:
High-end x86 servers
Mid-range to small x86 servers
Personal Computing Devices
Personal computing devices are desktop computers, laptops and handheld devices, including the operating systems and their hardware. Types of personal computing devices include:
Desktop personal computers
Handheld devices
Storage technologies address short term, long term and permanent storage of information and data. Types of storage technologies include:
Direct Attached Storage
Network Attached Storage
Storage Area Network
Assumptions and Expectations
Platform Architecture evaluates platform technologies in terms of flexibility, scalability, and interoperability with other platform technologies and operating systems. Each platform architecture category should have the following characteristics: Servers, Personal Computing Devices and Storage.
Have embedded security
Support industry-wide open-standards
Support centralized management
Support common management tools
Interoperate with other platform technologies
Personal Computing Devices
Have embedded security
Support industry-wide open-standards
Support centralized management
Support common management tools
Interoperate with other platform technologies
Have security
Support industry-wide open-standards
Support centralized storage
Support common management tools
Interoperate with other platform technologies
Compliance
All information technology investments will comply withexisting policies to ensure the integrity and interoperability of computing platforms.
Related Policies
Platform Infrastructure Standard
The example Platform Architecture Policy illustrates how a policy is used to define high level computing platform requirements, roles and responsibilities. The policy defines servers, personal computing devices and data storage computing platform requirements. Each individual computing platform must have seamless interoperability and integration with Oracle VM. During the development or review of platform architecture policy, Oracle VM and other computing platforms must be carefully considered to ensure interoperability, integration and security.
The following example Server Virtualization Policy defines an organization’s virtualization requirements. This policy is intended for informational purposes only.
The purpose of this policy is to establish server virtualization requirements that define the acquisition, use, and management of server virtualization technologies. This policy provides controls that ensure that Enterprise issues are considered along with business objectives when making server virtualization related decisions.
Platform Architecture policies, standards and guidelines will be used to acquire, design, implement and manage all server virtualization technologies.
The scope of this policy encompasses all new and existing workloads.
Responsibilities
The CEO and CIO ensure that policies are followed in order to establish contracts, review procurement requests and to develop and manage services.
&Company Name&’ legacy IT practice was to dedicate one physical server to a single workload.
The result of &Company Name&’ legacy IT practice was excessive server underutilization, an ever-expanding data center footprint and excessive data center power consumption.
Server virtualization software allows the consolidation of new and existing workloads onto high capacity x86 servers. Consolidating workloads onto high capacity x86 servers allows &Company Name& to reduce the x86 server inventory, which in turn decreases the data center footprint and data center power consumption.
&Company Name& will migrate all new and existing workloads from physical servers to virtual machines. All workloads that cannot be migrated to a virtual machine will be subject to &Company Name&’ Hardware and Software Sunset Policy.
Server Virtualization Software Requirements:
Support industry-wide open-standards
Embedded security
Single centralized management console
Support industry standard management tools
Support industry standard backup and recovery tools
Interoperate with other platform technologies
Support industry standard x86 hardware
Support industry standard storage
Support unmodified guest operating systems
Migrate running guests without interruption
Add disks to a running guest
Snapshot running guests
Revert to a previous snapshots on a running guest
Automatically detect a hardware failure and restart guests on another physical server
Functionality to configure role based access for the administrative console
Support LDAP for authentication and authorization for administrative console
Encrypt all intra host and administrative console traffic
Integrated graphical CPU, memory, disk and network performance monitoring, alerting, and historical reporting for hosts and guests.
Retain performance data for up to one (1) year
Functionality to manage host CPU, memory, storage and network resource allocation
Functionality to manage guest CPU, memory, disk and network resource allocation
Functionality to create, stop, start, pause, migrate, clone and provision guests
Functionality to automatically load balance guests across multiple hosts
Consolidated logging for hosts and guests that log date and time of all administrative user actions
Functionality to convert x86 physical servers to virtual machines
Encrypted remote administrative console access
Review Cycle
This policy is subject to annual review.
Compliance
All information technology investments shall conform to existing policies in order to ensure the integrity and interoperability of computing platforms.
Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
Related Policies
Platform Infrastructure Standard
Server Virtualization Standard
Server Virtualization Guidelines
Hardware and Software Sunset Policy
The following example Hardware and Software Sunset Policy defines an organization’s hardware and software sunset policy. This policy is intended for informational purposes only.
The purpose of this policy is to establish hardware and software sunset requirements. In an ongoing effort to meet business requirements, reduce IT costs and provide reliable, high-quality IT services, &Company Name& periodically sunsets (retires), old hardware and software. Once sunsetted, active support and all business services for the product are discontinued. Sunsetting older versions of hardware and software allows &Company Name& to focus resources on enhancing IT services, and providing support for more current, secure and stable products. In most cases, replacement costs for products identified for sunset are generally less than the expenses of continued support and maintenance. The Sunset policy will result in better customer service and reduced costs. This policy provides controls to ensure that Enterprise issues are considered along with business objectives when sunsetting hardware and software.
The scope of this policy encompasses server, desktop and network hardware platforms, operating systems and application software.
Products that have reached the end of their life cycle and are no longer supported by a vendor will be given a sunset date. The sunset date is when the product is scheduled to be removed from production. The sunset date will be set far enough in advance to give &Company Name& at least a budget cycle to fund and plan for the replacement. When a particular version of hardware or software is scheduled to be sunsetted, &Company Name& will provide the affected users with advance notice via email.
A Sunset list will be used to track all hardware and software sunset dates. In order to keep the sunset list up to date, &Company Name& will update the sunset list quarterly with hardware and software for review. Department managers with staff that use products on the sunset list will be notified quarterly via email regarding the sunset review process and sunset dates.
If you are currently using application software that has been designated sunset and would like to extent support, you will need to acquire a version that meets the current minimum standards as defined in &Company Name& Software Standards. If you are currently using hardware that has been designated sunset, any technical issues with the unit will trigger a replacement process with a unit that meets the current minimum standards as defined in &Company Name& Hardware Standards.
List 1 shows the sunset categories:
Hardware four years or older.
Operating systems that have reached their sunset date or are no longer supported by the vendor.
Proprietary application software that is no longer supported by the vendor.
Open Source application software that is no longer supported by the community.
Application software that does not support &Company Name& centralized authentication and authorization system.
Review Cycle
This policy is subject to annual review.
Compliance
All information technology investments shall conform to existing policies in order to ensure the integrity and interoperability of computing platforms. Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
Related Policies
Platform Infrastructure Standard
The platform architecture domain defines the roles, policies, standards and decision-making criteria for the acquisition and deployment of all computing and data storage hardware and operating systems for servers, desktops and handheld devices.
The network architecture domain defines the network infrastructure and explains how data flows between systems, computers and devices on a network. It defines the technologies used to enable reliable, secure communication on LAN, WAN and wireless networks. Architects that develop or review network architecture policies must understand Oracle VM architecture and end-user access requirements in order to ensure reliable and available network access to resources via Oracle VM.
List 2 shows a partial list of the layered policies within the network architecture domain.
Network Architecture Policy
Network Infrastructure Standard
Router and Switch Technology Standards
Network Security Standards
Note: The policy infrastructure of an organization directly reflects the unique mission and business objectives of the organization. The above list is for educational purposes only.
Network infrastructure enables reliable and secure communication between information systems and all related computing platforms. The network architecture domain with its layered policies takes into consideration Oracle VM architectural and supporting computing platforms to ensure reliable and secure communications over a wide variety of networks.
The next example is an abbreviated network architecture policy. The goal with this example is to illustrate the relationship between a high level network architecture policy and Oracle VM. This policy is intended for informational purposes only.
Purpose and Scope
The purpose of this policy is to establish network architecture requirements that describe how information processing resources are interconnected to topology standards, transport media, and protocols used to deliver converged services, including traditional data, voice, and video services. This policy provides controls that ensure Enterprise issues are considered along with business objectives when making network architecture related decisions. The scope of the architecture in this policy includes a network infrastructure to enable converged services, such as traditional data, voice and video services.
Responsibilities
The CEO and CIO ensure that policies are followed in order to establish contracts and procurement requests and to develop and manage services.
Network Architecture Goals
The goals to employ network architecture controls are:
Networks should be operational, reliable and available 24x7x365 to support mission-critical business operations and processes.
Networks should be designed for security, growth and adaptability.
Network architecture shall use proven open industry standards.
Network architecture will support converged services while accommodating traditional data, voice and video services.
Network Architecture Topology
Network architecture topology consists of the following:
Local Area Network (LAN): A local area network is a communications system that covers a small local area, like an office or building.
Wide Area Network (WAN): A wide area network is a communications system that spans a large geographical area.
Network architecture transport media include:
Wired (i.e. copper, fiber)
Wireless (i.e. 802.x, all EVDO)
Network Architecture protocols provide the rules that support network access and communication.
Assumptions and Expectations
Network Architecture evaluates network technologies in terms of flexibility, scalability, and interoperability with other technologies.
Compliance
All information technology investments shall conform to existing policies in order to ensure the integrity and interoperability of computing platforms.
Related Policies
Network Architecture Standard
Network Architecture Guideline
The example network architecture policy illustrates how a policy is used to define network architecture requirements and to describe how information processing resources are interconnected.
Unlike the platform architecture domain policies that govern Oracle VM, the network architecture domain establishes the foundation to plan, build, run and monitor the network infrastructure. Architects that oversee the development or review of network architecture policy must understand Oracle VM architecture and end-user access requirements to ensure reliable and available network access to resources via Oracle VM.
The next section will review the data and information architecture domain. We will also review a data classification and categorization standard which is used to define the classification and categorization of data/information and information systems hosted on Oracle VM.
The data/information architecture domain provides the layered policy infrastructure that describes business processes, data requirements of business systems and user data, and the classification and categorization of data/information and information systems. High level policies, such as the Data Architecture Policy, describe the requirements used to develop, acquire and implement technologies that collect, modify, store and report data/information. Other high level policies within the data and information architecture domain are the Data Modeling Standards, used to develop flow charts to understand business processes and data flow, and the Data/Information Classification and Categorization Standards, which are used as a framework to define data/information’s criticality and sensitivity levels, custodian responsibilities and accessibility.
List 3 shows a partial list of the layered policies within the data/information architecture domain.
Data Architecture Policy
Data Modeling Standards
Data/Information Classification and Categorization Standards
Database Systems Standards
Data Modeling Standards
Enterprise Document Management System Standards
Note: The policy infrastructure of an organization directly reflects the unique mission and business objectives of the organization. The above list is for educational purposes only.
Policies from the data and information architecture domain lay the foundation for information security by explaining business processes and how information flows between systems. The data and information architecture domain will also provide guidance for personnel on how to classify and maintain data. Data classification and maintenance policies allow organizations to implement the appropriate security controls based on the sensitivity and criticality of data/information.
Oracle VM is often used as the primary hosting platform for business applications, data and information. From a data/information security perspective, security controls will be implemented at multiple layers (defense in depth), starting with compartmentalization of data and systems along with administrative and technical security controls.
The next example is an abbreviated Data/Information Classification and Categorization Standard. This example shows how a standard allows an organization to define data/information classifications and security levels for both data/information and information systems. This standard is intended for informational purposes only.
Purpose and Scope
The purpose of this standard is to identify classifications and security levels for all forms of data/information and information systems across the Enterprise. It is intended to establish a “need to know” data/information classification methodology in order to protect &Company Name& data and information against unauthorized discloser, loss or misuse. This standard provides controls that ensure Enterprise issues are considered along with business objectives when making data/information classification decisions. The scope of the standard covers all forms of &Company Name& data/information throughout its entire life cycle, from its origination to its destruction.
Data Classification Standards Goals
The goals of this standard is to establish how data/information is classified according to its criticality and sensitivity and to ensure that &Company Name& data/information preserves its security classification as it traverses information systems or non-electronic boundaries.
Data Classifications
All &Company Name& information will be categorized into three main classifications:
Confidential
Table 1 provides examples of each classification and required security measure.
Data Classification
Confidential
Unauthorized disclosure would not considerably impact organization.
Unauthorized disclosure would result in considerable adverse impact, embarrassment or legal actions.
Examples include public web site, press releases, marketing brochures, annual reports, and public financial filings.
Examples include inter-office memoranda, internal correspond-dence, employee newsletters, internal directories, and internal policies.
Examples include employee records, department financial data, purchasing information, new product designs, strategic plans, marketing studies, vendor and customer contracts, confidential information of organizations customers, partners, and suppliers.
Accessibility
Available to the general public, can be distributed outside the organization.
Available for internal use. May be shared outside the organization to meet business objectives only when approved by a manager.
Access is limited to a “need to know” basis within the organization.
Document Label
“Internal”
“Confidential”
Data and information, regardless of its medium, will be:
Classified as either public, internal, or confidential.
Used in a manner equivalent with its classification.
Segregated by accessibility, file structure, or presentation.
Secured in accordance with applicable standards.
Disposed of in accordance with applicable standards.
Data and Information Custodians Responsibilities
Data/information custodians are responsible for the classification and execution of security controls of data they own, create or have become a delegate of. Data and information custodians retain their responsibility of data classification and execution of security controls for data and information within the organization, or for data/information that isshared with other organizations.
Security Categories for Data/Information and Information Systems
Source: FIPS PUB 199-final, Categorization of Information and Information Systems.
This section establishes security categories for both data/information and information systems. The security categories are based on the potential impact on an organization should certain events occur that jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions and protect individuals. Security categories are to be used in conjunction with vulnerability and threat information in assessing the risk to an organization.
Categorization of data/information and software application systems includes risk levels of confidentiality, integrity, and availability. Table 2 summarizes the security objectives and their risk levels.
POTENTIAL IMPACT
Security Objective
Confidentiality
Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
[44 U.S.C., SEC. 3542]
The unauthorized disclosure of information could be expected to have a limited adverse effect on organizational operations, organizational assets or individuals.
The unauthorized disclosure of information could be expected to have a serious adverse effect on organizational operations, organizational assets or individuals.
The unauthorized disclosure of information could be expected to have asevere or catastrophic adverse effect on organizational operations, organizational assets or individuals.
Guarding against improper
information modific includes ensuring information non-repudiation and authenticity.
[44 U.S.C., SEC. 3542]
The unauthorized modification or destruction of information could be expected to have a limited adverse effect on organizational operations, organizational assets or individuals.
The unauthorized modification or destruction of information could be expected to have a serious adverse effect on organizational operations, organizational assets or individuals.
The unauthorized modification or destruction of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets or individuals.
Availability
Ensuring timely and reliable access to and use of information.
[44 U.S.C., SEC. 3542]
The disruption of access to or use of information or an information system could be expected to have a limited adverse effect on organizational operations, organizational assets or individuals.
The disruption of access to or use of information or an information system could be expected to have a serious adverse effect on organizational operations, organizational assets or individuals.
The disruption of access to or use of information or an information system could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets or individuals.
The potential impact is LOW if the loss of confidentiality, integrity or availability could be expected to have a limited adverse effect on organizational operations, organizational assets or individuals.
The potential impact is MODERATE if the loss of confidentiality, integrity or availability could be expected to have a serious adverse effect on organizational operations, organizational assets or individuals.
The potential impact is HIGH if the loss of confidentiality, integrity or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets or individuals.
Compliance
All classification and security levels for data/information and information systems will conform to existing policies. Any employee found to have violated this standard may be subject to disciplinary action, up to and including termination of employment.
Related Policies
Data Architecture Policy
Data Modeling Standards
Data Security Policy
FIPS PUB 199-final
The example illustrates how a standard defines classifications and security levels for all forms of data/information and information systems across the Enterprise. The classification of data/information and information systems sets the stage for information security, allowing organizations to employ the appropriate security control based on the sensitivity or criticality of data and information systems.
The data and information architecture domain directly influences the design, support and auditing of an Oracle VM environment. Organizations implement administrative and technical controls to ensure the confidentiality, integrity and availability of sensitive data. From a design perspective, Oracle VM server pools can be leveraged to support access to different data security levels. One Oracle VM server pool with one set of security controls can be leveraged to access internal data, while other Oracle VM server pools with different security controls such as encryption and application access restrictions are used to access confidential data. Oracle VM server pools allow the appropriate security controls such as auditing and encryption to be implemented based on the sensitivity of the data or application accessed from a given Oracle VM server pool.
The software architecture domain defines the methodologies, tools and best practices to develop, acquire, deploy and retire software that automates and maintains business processes. It provides a framework to ensure the integrity, interoperability and integration of software and computing platforms. The software architecture domain policy infrastructure provides the framework to support the entire lifecycle of software, including desktop applications and management software installed and hosted on Oracle VM. Software architecture can consist of the following components:
Applications
Software designed to automate specific business processes, such as customer resource management, employee services, accounts payable, payroll, etc.
Programming Software
Enabling technologies used to develop software.
Database Software
Database management systems that enable organizations to store, modify and extract information from a database.
Productivity Software
Office productivity and collaborative software.
Management Software
Software used to maintain, monitor and audit network infrastructure and computing platforms.
An example of high level tier 2 policy in the software architecture domain is the Software Architecture Policy, which describes high level requirements to design, develop or acquire software. Another example high level policy is a tier 2 Applications and Software Standard that is used to describe high level application and software standards. Lower level tier 2 & 3 policies describe individual applications or application groups. An example would be the Productivity Application Standards, which isa tier 2 policy describing Enterprise-wide productivity application standards. Lower level tier 3 policies describe application A, B or C’s configuration and use.
List 4 shows a partial list of the layered policies within the software architecture domain.
Software Architecture Policy
Application and Software Standards
Productivity Application Standards
Application Development Standards
Load and Performance Testing Software Standards
Software Licensing Policy
Note: The policy infrastructure of an organization directly reflects the unique mission and business objectives of the organization. The above list is for educational purposes only.
The security architecture domain defines the roles, policies and process reviews to implement and monitor security across an Enterprise. The security architecture domain encompasses people, physical security and the technologies used for security management, such as surveillance, firewalls, intrusion detection, cryptography, public key infrastructure (PKI), authentication, authorization, remote access, virus detection, and so forth. It enables organizations to look at their entire technology portfolio as a single cohesive unit and apply the appropriate security controls in order to achieve business objectives without compromising user productivity.
An example of a high level policy in the security architecture domain is the Security Architecture Policy, which defines security and regulatory requirements used to establish a recommended minimum security architecture baseline. Another example of high level policy is the IT Risk Management Standard that defines a Risk Management process.
List 5 shows a partial list of the layered policies within the security architecture domain.
IT Risk Management Standard
Change Management Policy
Incident Response Policy
Encryption Standard
IT Disaster Recovery Planning Policy
IT Physical Security Standard
Note: The policy infrastructure of an organization directly reflects the unique mission and business objectives of the organization. The above list is for educational purposes only.
There are many policies within the security architecture domain that govern an Oracle VM environment. Security controls, such as physical and environmental policies, encryption standards, authentication, authorization, server hardening, and so forth, are applied to Oracle VM via the security architecture domain policy infrastructure.
The next examples introduce a tier 2 Change Management Policy. The example illustrate the relationship between the security architecture domain’s layered policy infrastructure and Oracle VM. This policy is intended for informational purposes only.
Changes require careful planning, testing and monitoring to reduce negative impact to user productivity. Change management exists to coordinate and inform personnel of all changes that impact any computing system or service. The purpose of change management is to insure that technical requirements are clearly defined, documented, scheduled and controlled throughout the product life cycle. The overriding goal is to provide a high level of availability and service.
Purpose and Scope
The purpose of this policy is to establish change management processes in order to manage changes to hardware, software, firmware and documentation in a coherent and predictable manner so personnel can plan accordingly. This policy provides controls that ensure Enterprise issues are considered along with business objectives when changing hardware, software, firmware and documentation. The scope of the policy includes all hardware, software, firmware and documentation. The Change Management Policy applies to all individuals who install, manage or maintain information resources.
Change Management procedures:
Any change to information resources will comply with the Change Management Policy and will follow the change management procedures.
A formal written change request will be submitted to the CIO before any change, either scheduled or unscheduled, containing the following information:
Change Description: A technical description of the change.
Change Purpose: A technical description of the purpose of the change.
Change Testing: List the completed QA testing.
Role-back Procedures: A technical description of the role-back procedures.
Timing: A detailed schedule when the change will take place.
Responsibilities: A list of the personnel, their responsibilities, and their contact information for those who are involved in the implementation of the change.
Impact Analysis: An impact analysis on change.
All changes will be maintained in a Change Management log that contains:
Date of change
Responsible parties contact information
Nature of the change
Indication of success or failure
Assumptions and Expectations
All information systems must comply with the change management policy and meet the procedures outlined above.
Compliance
Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
The example illustrates how a policy defines the change management procedures for an organizations hardware, software, firmware and documentation.
This section will introduce Enterprise Security Architecture (ESA), beginning with an introduction of Enterprise Security Architecture and Risk Management and a review of a Risk Assessment Policy, followed by an Enterprise Security Policy. Next we will highlight Enterprise Security Architecture infrastructure design concepts: defense in depth, the principle of least privilege, compartmentalization of information, and security domains. The chapter will conclude with one example Oracle hybrid cloud topology, highlighting the Enterprise Security Architecture infrastructure design concepts in this chapter. The goal of this chapter is to show how Enterprise Security Architecture design concepts with Oracle VM can be used to provide secure access to different classifications of data, applications and users.
Enterprise Security Architecture introduces Risk Management techniques, methodologies and practices used to secure today’s complex Enterprise. Enterprise Security Architecture is an integral component of an Enterprise Architecture and an information security program. Enterprise Architecture provides the foundation to develop and deploy technologies, while Enterprise Security Architecture is used as a guideline in making strategic, architectural security decisions.
Note: Because Enterprise Security Architecture and Risk Management are separate and distinct disciplines, a detailed discourse is beyond the scope of this book. I will, therefore, delve only into the details that are most relevant.
The goal of Risk Management is to protect the organization and its ability to achieve its mission. Risk Management is a process that provides a framework to enable people and organizations to assess risk and develop strategies to manage it. Risk Management strategies include transferring risk to others, risk avoidance, minimizing the negative effect of risk or accepting risk. A Risk Assessment is a step in the Risk Management process that can be used to assess a specific risk. An information security Risk Assessment is used to determine areas of vulnerability within the IT environment to initiate remediation.
Figure X shows the elements of a Risk Assessment.
In terms of information security, there are many advantages in using Risk Management and Risk Assessments. The advantages are the ability to identify, quantify and manage risk along with cost justification. Many IT organizations leverage Risk Assessments to educate management on security awareness and to justify spending to shore up the security posture of their environments.
Tip: In terms of assessing Information Technology risk, evaluate the NIST Special Publication 800-30, Risk Management Guide to Information Technology Systems. It is a detailed guide on how to conduct a Risk Assessment and determine suitable technical, management and operational security controls.
The following example is a Risk Assessment Policy from the SANS Policy Project. It is used to sanction InfoSec to perform periodic information security Risk Assessments (RAs) in order to determine areas of vulnerability, and when applicable, to initiate remediation. This policy is intended for informational purposes only.
To empower InfoSec to perform periodic information security risk assessments (RAs) for the purpose of determining areas of vulnerability and to initiate appropriate remediation.
Risk assessments can be conducted on any entity within &Company Name& or any outside entity that has signed a Third Party Agreement with &Company Name&. RAs can be conducted on any information system, to include applications, servers and networks, and any process or procedure by which these systems are administered and/or maintained.
The execution, development and implementation of remediation programs are the joint responsibility of InfoSec and the department responsible for the systems area being assessed. Employees are expected to cooperate fully with any RA being conducted on systems for which they are held accountable. Employees are further expected to work with the InfoSec Risk Assessment Team in the development of a remediation plan.
Compliance
Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
The proceeding Risk Assessment Policy was presented to demonstrate how organizations use policy to communicate management’s endorsement of InfoSec in order to perform a Risk Assessment. The policy states that InfoSec can conduct a Risk Assessment on any entity within the organization or on any outside entity that has signed a Third Party Agreement. The execution, development and implementation of remediation will be a joint engagement between InfoSec and the department responsible for the assessed systems.
The next section will review an Enterprise Security Policy. An Enterprise Security Policy is used to bridge the gap between technical and administrative security controls used together to instruct employees and business partners onhow to securely access systems and consume data securely.
An organization’s Enterprise Security Policy is an integral part of an information security program because it encompasses the human factor of information security. It provides organizations an effective way to educate employees on acceptable system usage, corporate conduct and overall information security. It is one of the first steps in enforcing
therefore, it istypically introduced to employees during new hire training. Most organizations require new employees to read and sign an Enterprise Security Policy before they are granted access to any corporate voice or data communication system.
The followingexample is an Enterprise security policy intended for employees and business partners. It illustrates how a security policy can communicate acceptable system usage while promoting information security. This security policy is intended for informational purposes only.
Purpose and Scope
The primary purpose of this Security Policy is to inform employees and non-employees working for or with &Company Name& assets of their shared responsibilities to insure the protection of &Company Name& systems and corporate data. InfoSec is responsible for auditing and maintaining policy compliance. Human Resources is responsible for ensuring that all employees and non-employees working for or with &Company Name& assets have read and signed this Security Policy before they gain access to any &Company Name& voice and data communication systems.
This Security Policy applies to all employees, and non-employees at &Company Name&. This policy applies to all equipment and assets that are owned or leased by &Company Name&.
Responsibilities
All voice and data communication systems and related transmitted information, including but not limited to computer equipment, software, operating systems, storage media, network accounts providing electronic mail, internet browsing and FTP, are the property of &Company Name&. &Company Name& has the right to monitor and review usage of all voice and data communication systems at any time. These systems are to be used for business purposes serving the interests of &Company Name&.
Human Resources
Human Resources’ purpose is to provide new hire training, to communicate a security awareness program, and to ensure that all employees and non-employees have read and signed this Security Policy before they gain assess to any &Company Name& systems. This department also ensures that up-to-date policies are easily available to employees.
Management
Management ensures that all personnel have reviewed this policy and are in compliance and are to contact InfoSec immediately if a policy violation is discovered.
InfoSec develops and maintains security policies, identifies and deploys automated security controls and audits for policy compliance.
An employee should review this policy and all referenced policies herewith to maintain compliance.
Related Policies
Acceptable Use Policy
Password Policy
Scheduled Review
Security Policy Table of Contents
Physical Security
Internet Usage
Messaging Systems and Email Access
Anti-virus
Unauthorized Networks (Wireless, Modems)
Remote Access
System Access Passwords
Enforcement
Employee Acknowledgement
Physical Security
Physical security is an essential part of &Company Name& information security program. Physical security forms the basis for all other security efforts, including data security. &Company Name& employs physical security controls for its employees and assets. These controls must be followed by all &Company Name& employees:
Wear your badge at all times while on company property.
Lock your office door or cubicle storage when you leave your area.
Lock your computer when stepping away from your work area.
Log off your workstation at the end of the working day.
Escort, observe and supervise guests for their entire visit.
Watch out for "tailgaters." Tailgaters wait for an authorized person to enter a controlled area (such as with a locked door) and then follow him or her through the door.
Shred or otherwise destroy all sensitive information and media when it isno longer necessary.
Do not allow anyone to add hardware or software to your computer without proper authorization.
Do notallow the removal of any corporate assets without ensuring that the person removing it has proper authorization.
Report suspicious activities to your manager.
Internet Usage
Internet usage is provided as a business service for the purpose of supporting &Company Name& business activities and occasional personal use as defined in the Acceptable Use Policy. Information found on the Internet may not be safe and should be considered suspect until confirmed by a reliable source. All Internet access is monitored and logged.
Messaging systems and Email Access
Corporate email access is provided as a business service for the purpose of supporting &Company Name& business activities as defined in the Acceptable Use Policy. Email is not a secure medium and care should be taken with regard to the information sent in email. Accessing personal email systems like Hotmail, Yahoo, or Gmail is prohibited.
Employees may have access to confidential information about the Company, our employees or clients. With approval of management, employees may use email to communicate confidential information to those with a need to know. Such email must be labeled "Confidential." When in doubt, do not use email to communicate confidential material. All email activity is monitored and logged.
Anti-virus
Viruses, worms and Trojan horses are examples of malware programs that can cause significant damage to &Company Name& data and resources. They can destroy, alter or disclose confidential information in a variety of ways and damage the reputation of &Company Name& as well as the reputation and credibility of &Company Name& employees. &Company Name& employs anti-virus controls for its computers and employees as defined in the Acceptable Use Policy.
These controls must be followed by all &Company Name& employees:
Ensure that the corporate standard anti-virus software is installed on desktop and laptop computers.
Employees will not use a computer without anti-virus software on &Company Name’s& network, nor will they disable the software.
Do not open any email attachments from an unknown, suspicious or untrustworthy source. Delete these attachments immediately. Then "double delete" them by emptying your Trash.
To avoid spreading a virus, do not create network file shares that allow the ‘everyone group’ to write to it, unless there is a business reason.
In the event of a virus, disconnect from the network and contact the Help Desk, InfoSec or your manager immediately.
Do not download files from questionable sources.
Unauthorized Networks
Wireless technology allows mobile access to &Company Name’s& internal network. Only wireless access points and modem connections installed and supported by &Company Name& IT personnel are permitted to connect to &Company Name& network. All other wireless access points and modems that connect to &Company Name& network are prohibited. Employees are prohibited from connecting modems or wireless access points on company property.
Remote Access
Remote Access is provided as a business service for the purpose of supporting &Company Name& business activities as defined in the Acceptable Use Policy. Access for remote users to the corporate network will be from an approved encrypted connection exclusively from corporate managed devices as described in the Acceptable Use Policy. &Company Name& will offer handheld devices for remote access to email.
System Access Passwords
Passwords are an important part of information security and are the primary control used to protect user accounts and sensitive corporate data. Intruders often gain access to a company's systems by stealing or cracking a password and account name and then posing as that user. Intruders often gain access by trying password combinations related to a person’s family, address or hobbies. As such, all employees and business partners with access to &Company Name& systems are responsible for selecting a strong password as defined in &Company Name& Password Policy.
Enforcement
Any employee found to have violated any part of this policy may be subject to disciplinary action, up to and including termination of employment.
Employee Acknowledgment
If you have questions or concerns about this policy, contact the Human Resources Department before signing this agreement.
I have read &Company Name’s& security policy and agree to abide by it. I understand violation of any of the above terms may result in discipline, up to and including my termination.
Employee Name: (Printed)
Employee Signature:
The example Enterprise Security Policy was provided to show how policy is used to reduce risk associated with user access to information systems. An Enterprise Security Policy educates employees and business partners on appropriate system usage and explains the consequences of policy violation. In many cases, this type of policy may be the only security education an employee or business partner receives. Compliance with an Enterprise Security Policy will shore up the overall security posture of the Enterprise and provide a secure foundation for a Oracle private cloud.
Network topographies and infrastructure design play an important role with an Enterprise Architecture. Enterprise Security Architecture introduces Risk Management methodologies along with infrastructure design concepts, such as defense in depth, principle of least privilege, compartmentalization of information, security domains, trust levels and tiered networks. Enterprise Security Architecture design concepts allow organizations to implement the appropriate security controls from an infrastructure design perspective based on the sensitivity and criticality of users, information, applications and business processes.
The next section reviews defense in depth, principle of least privilege, compartmentalization of information and security domains.
Defense in Depth (DiD) was originally a military strategy used to delay rather than prevent an attack by using multiple layers of protection. The defense in depth strategy has been widely adopted in non-military applications, such as Enterprise security, by implementing multiple layers of techniques and technologies to secure assets. An example of using defense in depth in IT security is to use administrative and technical security controls, each of which utilizes layers of techniques and technologies to provide security.
One important aspect of defense in depth is a balanced focus on three primary elements:
Technology
Operations
The people element of Defense in Depth focuses on the endorsement and understanding of the importance of information security by executive management and the value of an information security program. The technology element of Defense in Depth focuses on the technologies used to meet corporate security requirements. The operations element of Defense in Depth focuses on the processes used to ensure the security of information assets of the organization.Previous chapters have explained how Enterprise security starts with the commitment of executive management and is followed by the development of policies that define roles,
responsibilities and personal accountability. Enterprise Architecture and Enterprise Security Architecture used with a control framework encompass the people, technology and operations element of the defense in depth strategy by providing multiple layers of security techniques and technologies.
The principle of least privilege was originally described 30 years ago as a design principle in a paper named “The Protection of Information in Computer Systems” by Jerry Saltzer and Mike Schroeder:
“f) Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide "firewalls," the principle of lea}