You are here

Oracle Private Cloud Security

This chapter of the Oracle Cloud Cookbook introduces the Oracle Private Cloud Security guide. This chapter applies to all Oracle technology products.
Download PDF Now!

Table of Contents

The Oracle Private Cloud Security Policy Project Introduction
Enterprise Architecture Introduction
Platform Architecture Domain
Platform Architecture Policy
Server Virtualization Policy
Hardware and Software Sunset Policy
Network Architecture Domain
Network Architecture Policy
Data/ Information Architecture Domain
Data/Information Classification and Categorization Standard
Software Architecture Domain
Security Architecture Domain
Change Management Policy
Enterprise Security Architecture
Risk Management & Risk Assessments
Risk Assessment Policy
Enterprise Security Policy
Defense in Depth
Principle of Least Privilege
Compartmentalization of Information
Security Domains
Physical and Environmental Security
IT Server Room Security Policy
Log Management Introduction
Log Generation, Analysis, Transmission, Storage, Retention & Disposal
Log Management Policy
Incident Response
Incident Response Policy
Audit Vulnerability Assessments
Audit Vulnerability Scan Policy

The Oracle Private Cloud Security Policy Project Introduction

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.

 

Enterprise Architecture Introduction

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.
 
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.
 

Platform Architecture Domain

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.
 

Platform Architecture Policy 

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.
 
Servers
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
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
  • Tape
 
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.
 
Servers
  • 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
 
Storage
  • 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.
 

Server Virtualization Policy

Purpose
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.
 
Scope
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.
 
Policy
<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.
 

Hardware and Software Sunset Policy

Purpose
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.

Scope
The scope of this policy encompasses server, desktop and network hardware platforms, operating systems and application software.

Policy
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

 
Summary
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.
 

Network Architecture Policy

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.
 
Summary
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.
 

Data/ Information Architecture Domain

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:
  • Public
  • Internal
  • Confidential
Table 1 provides examples of each classification and required security measure.
Security
Objective
Data Classification
 
Public
Internal
Confidential
Criteria 
 
Unauthorized disclosure would not considerably impact organization.
Unauthorized disclosure would result in considerable adverse impact, embarrassment or legal actions.
Examples
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
None
“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
LOW
MODERATE
HIGH
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.
Integrity
Guarding against improper
information modification or destruction; 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
 
Reference
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.
 
Summary
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:
 
  1. Applications
    • Software designed to automate specific business processes, such as customer resource management, employee services, accounts payable, payroll, etc.
  2. Programming Software
    • Enabling technologies used to develop software.
  3. Database Software
    • Database management systems that enable organizations to store, modify and extract information from a database.
  4. Productivity Software
    • Office productivity and collaborative software.
  5. 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.
 

Security Architecture Domain

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.
 
Overview
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.  A formal written change request will be submitted to the CIO before any change, either scheduled or unscheduled, containing the following information:
  1. Change Description: A technical description of the change.
  2. Change Purpose: A technical description of the purpose of the change.
  3. Change Testing: List the completed QA testing.
  4. Role-back Procedures: A technical description of the role-back procedures.
  5. Timing: A detailed schedule when the change will take place.
  6. Responsibilities: A list of the personnel, their responsibilities, and their contact information for those who are involved in the implementation of the change.
  7. Impact Analysis: An impact analysis on change.
B.  All changes will be maintained in a Change Management log that contains:
  1. Date of change
  2. Responsible parties contact information
  3. Nature of the change
  4. 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.
 

Risk Management & Risk Assessments

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.
 

Risk Assessment Policy

Purpose
To empower InfoSec to perform periodic information security risk assessments (RAs) for the purpose of determining areas of vulnerability and to initiate appropriate remediation.
 
Scope
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.
 
Policy
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.
 
Summary
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 information security; 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.


Enterprise Security Policy

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
InfoSec develops and maintains security policies, identifies and deploys automated security controls and audits for policy compliance.
 
Employee
An employee should review this policy and all referenced policies herewith to maintain compliance.
 
Related Policies
Acceptable Use Policy
Password Policy
 
Scheduled Review
Annually
 
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:
 
Date:
 
Summary
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

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:
  • People
  • 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.

 
Principle of Least Privilege

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 least privilege provides a rationale for where to install the firewalls. The military security rule of "need-to-know" is an example of this principle.”
 
In terms of IT security, the principle of least privilege applies to users, applications and systems. Users should be granted the least privilege required to accomplish their jobs.
 
Applications should be granted the least privilege needed to perform their functions, and systems should be granted the least privilege necessary to fulfill their role in a larger network. The principle of least privilege is important for meeting integrity objectives. In spy and war movies, following the principle of least privilege is equivalent to operating on a “need to know” basis.


Compartmentalization of Information

Compartmentalization of information is actually a subset of the principle of least privilege that focuses on information. Compartmentalization of information limits access to information to people with the “need to know” in order to perform certain tasks. With regard to infrastructure design with Oracle private clouds, compartmentalization of information is used to compartmentalize users, applications, data and information based on its sensitivity and criticality.
 
The principle of least privilege and compartmentalization of information are security controls that are used together with infrastructure design and Oracle VM to control access to applications, data and information based on its sensitivity, criticality and value.
 

Security Domains

Security domains allow organizations to segment their Enterprise network into discrete units. Each security domain will have its own policies that apply security controls based on the sensitivity, criticality and value of the information and systems in a security domain. Policies within the data/information architecture domain, specifically the Data/information Classification and Categorization Policy, can provide guidance to determine the placement of systems, information and data into their respected security domain.
 
Tip: FIPS PUB 199, which is the “Standards for Security Categorization of Federal Information and Information Systems,” provides a formula to determine the security category of systems and can be used to determine within which security domain systems should reside.
 
Security Domain Classifications:
The classification of security domains is very similar to data classifications. Each infrastructure component will be classified and placed in its respective security domain. The majority of Enterprise networks can be separated into the following four security domains:
  • Controlled: A controlled security domain is used to restrict access between security domains. A controlled security domain could contain groups of users with their network equipment or a demilitarized zone (DMZ) with a VPN, proxy and web servers.
  • Uncontrolled: An uncontrolled security domain refers to any network not in control of an organization, such as the Internet.
  • Restricted: A restricted security domain can represent an organization’s production network. Access is restricted to authorized personnel, and there is no direct access from the Internet.
  • Secured: A secured security domain is a network that isonly accessible to a small group of highly trusted users, such as administrators and auditors.

Physical and Environmental Security

This section introduces physical and environmental security. As discussed previously, an Enterprise Architecture provides policies that encompass physical and environmental security. This section builds on what we learned from previous sections by providing a brief explanation of physical and environmental security as an introduction to the physical and environmental security controls used to protect a private Oracle cloud. The discussion evolves to physical and environmental security in terms of Oracle VM and regulatory compliance by introducing an example tier 2 IT Server Room Policy. This section illustrates the importance of physical and environmental security, provides additional references, and explains why systems must be protected in a secure location against unauthorized access, environmental threats and manmade disasters.
 
The overwhelming consensuses inall walks of security professionals is that if an attacker gains physical access to an environment, all existing security controls are pointless. Once an organization’s physical security has been compromised, even the most hardened server is at risk to a variety of threats.
 
Physical and environmental security is not the most popular topic of discussion among IT professionals because the controls rarely involve the hardware, software and firmware technologists support. The NIST Special Publication 800-33 describes physical security as a “non-computing security method.”
 
Physical and environmental security addresses the threats, vulnerabilities and countermeasures used to secure an organization’s assets. Physical and environmental security encompasses people, facilities, data, equipment, media and supplies. Physical and environmental security includes administrative controls, physical access controls and environmental protection controls. An example of administrative controls is visitor registration. Physical access controls can be as simple as a locked door or as elaborate as biometric access controls behind multiple guard posts. Environmental protection can be as simple as surge protection and a fire extinguisher or as elaborate as full scale climate control, conditioned power or emergency power sources with an automated fire protection system. In terms of Oracle VM, physical and environmental security provides the security controls that ensure against unauthorized access, environmental threats and manmade disasters.
 
Table 3 introduces physical access controls and environmental protection considerations.
Physical Access Controls
Environmental Protection
Guards
Power Protection and Conditioning
Fences
HVAC
Barriers
Water Protection
Lighting
Fire Detection
Keys and Locks
Fire Suppression
Badges
Evacuation
Escorts
Environmental Monitoring
Monitoring and Detection Systems
Environmental Detection
 
Organizations that must comply with regulatory mandates, such as Sarbanes-Oxley, Health Insurance Portability, and so forth, must undergo regular audits to ensure compliance. There are a number of widely adopted control frameworks and guidelines that can be used to help implement and audit physical and environmental security.
 
Table 4 lists additional resources.
Name
Explanation
Section
FIPS PUB 31
U.S. Department of Commerce / National Bureau of Standards, Federal Information Processing Standards (FIPS) Guidelines for automatic data processing physical security and Risk Management.
This document is outdated, although it is still considered a good informational resource.
Entire document is dedicated to physical and environmental security. 
ISO IEC 17799 2005
The purpose of ISO/IEC 17799 is to provide recommendations for information security management to those responsible for initiating, implementing or maintaining security in their organization.
Section 9.
NIST Special Publication 800-12
An Introduction to Computer Security: The NIST Handbook
Chapter 15.
CobIT 4.0
CobIT is a framework for information IT management risks, or more formally, a "framework and supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks" (ref: ISACA).
CobIT is typically associated with Sarbanes-Oxley compliance. 
·         PO4.8 Responsibility for Risk, Security and Compliance.
·         DS12 Manage the Physical Environment.
·         DS12.2 Physical Security Measures.

After physical and environmental security has been compromised, even the most hardened server is at risk to a wide range of threats, such as theft, tampering, accidental interference, lose of power, surges or spikes, flood, fire, earthquake, overheating, and so forth. From a server perspective, as soon as physical security is compromised, theft or tampering is a serious concern. Many popular tools are available on the Internet that can be used to reset the local or domain administrator’s password by booting a server from a floppy or CDROM. Once an intruder has the administrator’s password, it is possible to install root kits or roam the network with immunity. An example of environmental risks includes power irregularities or failure, heat, floods, fire, earthquake, and so forth.
 
The following example is an IT server Room Security Policy which highlights the security controls employed to protect a server room against unauthorized access, environmental threats and manmade disasters. This policy is intended for informational purposes only.
 

IT Server Room Security Policy

Purpose and Scope
The purpose of this policy is to ensure that a minimum level of physical and environmental security is maintained in IT Server Rooms. The following policy is applicable to all of <Company Name> IT Server Rooms, employees and visitors who access any IT Server Rooms.
 
Roles and Responsibilities
 
Director of IT
In order to ensure compliance with this policy, the Director of IT is responsible for distributing this policy to all employees who access IT server rooms.
 
All Employees
All employees shall read this policy before accessing IT server rooms. It is the responsibility of <Company Name> employees to ensure that they carry out their duties in a professional manner while working in IT Server Rooms.
 
Visitors
All visitors shall be accompanied by a member of the IT staff at all times while in an IT server room. It is the responsibility of the <Company Name> IT staff accompanying the visitor to ensure they carry out their duties in a professional manner while working in IT Server Rooms.
 
Policy

  • The primary security control used to access the IT server rooms is a digital door lock.
  • Only authorized personnel shall be allowed access to the server room area, including those persons needed to operate, supervise or provide maintenance to the area and its equipment.
  • Personnel shall wear their identification badge at all times while in an IT server room.
  • All visitors must wear visitors’ passes while in an IT server room.
  • All visitors must be accompanied by <Company Name> IT staff at all times while in an IT server room.
  • Tailgating other staff members in order to enter an IT server room is not permitted.
  • Food and drink shall not be taken into the IT server rooms.
  • The server room must have clean, conditioned power.
  • A primary and back-up uninterrupted power system (UPS) is required to prevent data loss if the main power should fail.
  • The server room must have a primary and backup climate control system.
  • Database and file backups will be kept as current as is reasonable. All backup tapes must be stored in a secured off-site location.
 
Policy Review
This policy will be reviewed annually.
 
Compliance
Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

The proceeding policy shows which security controls organizations employ to protect their information systems including Oracle VM from unauthorized access, environmental threats and manmade disasters.
 

Log Management Introduction

Logs are records of events that occur within the information systems of an organization. Virtually every system, service, application and device in the Enterprise has built in logging capabilities. Originally log data was used to troubleshoot systems; but as systems and business requirements evolved, so did logging capabilities and log analysis. In today’s Enterprise, logs are an invaluable resource used to optimize systems and networks, establish baselines, perform audits and assist with regulatory compliance. From a security perspective, log data along with intrusion detection systems (IDS) provides a wealth of information to identify security events, detect an attack in progress and analyze the results of security events.
 
System logs for operating systems and services, such as authentication, ssh, DNS, sendmail, and so forth, generate detailed information about their activity. Application logs have the ability to generate an audit trail of past transactions with time stamps, user names and object access details. Most network gear, such as firewalls, routers, switches, and so forth, have the ability to generate log data about their activity. Change management logs document all changes made to technologies within the Enterprise. Other types of logs, such as surveillance or physical access logs, provide detailed physical access audit trails. Each of these logs sources are an integral part of their respective administrators’ jobs because the collection and analysis of the log data is one of their responsibilities.
 
In conjunction with the appropriate tools and procedures, audit trails can validate individual accountability, a way to reconstruct events, detect intrusions, identify problems and demonstrate regulatory compliance. The need to audit individual accountability, reconstruct events, detect intrusions, identify problems and demonstrate regulatory compliance emphasizes the need for organizations to develop an effective log management strategy to generate, analyze, store and dispose of log data.
 
To establish an effective log management strategy, organizations develop log management practices. Policies are used to define log management activities that support business objectives and regulatory mandates that cover log generation, analysis, transmission, storage, retention and disposal. A log management infrastructure provides Enterprise wide management of log records.
 
List 6 shows the scope of a log management infrastructure:
  • Define a method to move logs into the infrastructure.
  • Define a secure storage format for logs.
  • Define log retention policies.
  • Define approved access methods to logs.
  • Define analysis tools to enable analysis among multiple log sources.
  • Define processes to use log data as evidence in legal proceedings.

 
Log Generation, Analysis, Transmission, Storage, Retention & Disposal

One of the keys to effective log generation is to ensure that log data is indeed reported in event logs. To ensure effective log generation, organizations must carefully evaluate each system, application and device within the Enterprise to ensure that they are properly configured to generate log data.
 
In terms of log analysis, processes should be in place to define the frequency and who analyzes the log data. Periodic analysis of log data will assist to identify and troubleshoot operational issues and security events. Countless commercial and Open Source tools are available to help to analyze log data. Organizations need to review their unique security and log analysis requirements to select a solution that meets their objects.
 
Log transmission, storage and disposal are important considerations for a log management infrastructure to protect the confidentiality, integrity and availability of logs. Some logs are created for local storage or put in a file that isintended to be transmitted to another system for processing. Logs will inevitably be transmitted over the network from the host to the log infrastructure for processing, storage and disposal. Business and regulatory requirements will help determine log transmission, storage and disposal requirements.
 
Finally, log retention periods are a serious consideration that depends on each organization’s individual requirements. If the log infrastructure is designed for troubleshooting and short-term reporting, a short retention period of one or two months may suffice. However, if the goal is regulatory compliance and/or legal obligations, log data may need to be stored for a number of years for auditing purposes. Incidentally, seven years is becoming a generally accepted timeframe for log data retention.
 
Tip: NIST Special Publication 800-92, entitled “Guide to Computer Security Log Management” is a 72-paged publication intended to assist organizations in understanding the need for sound computer security log management. It isconsidered a core resource for developing a log management infrastructure. Also the NIST Handbook’s Chapter 18 offers guidance with audit trails.
Security Event Log Monitoring & Oracle VM
 
Investigating security events within an Oracle VM environment can be a very challenging task because by default Oracle VM logs all events locally. Logging events locally makes troubleshooting Oracle VM server pool issues a challenge, because different log information is being echoed to different local log files. When a security event occurs, many times there is simply too many local log files to review to make sense of what happened. Organizations turn to Intrusion Detection Systems to monitor network traffic for suspicious activity and security information and event management systems (SIEM) to manage their log infrastructure. Security information event management systems, and log management tools offer centralization, sorting and parsing of log file data. Countless commercial and Open Source solutions are available to meet any organization’s requirements. Regardless of which solution(s) an organization uses, security log management analysis practices are identical, such as the ability to identify, contain and respond quickly to security events in the network.
 
One of the primary goals of security log monitoring is to detect suspicious activity and audit systems for compliance. Within an Oracle VM environment, log data can be leveraged to detect a wide variety of suspicious activity such as: brute force attacks, authentication failures, account lockouts, successful and unsuccessful file access attempts, unexpected system shutdowns and attempts to tamper with event logs.
 
Note: When processing any log files to ensure the credibility of the log files, it isimportant to work on copies of the logs to preserve the integrity of the original files.
 
The following tier 2 Log Management Policy defines an organization’s requirements in term of log management. The example policy starts with a Purpose and Scope statement and then proceeds with the policy. This policy is intended for informational purposes only.
 

Log Management Policy

Purpose
This purpose of this policy is to define <Company Name>’s log management practices and requirements in terms of log generation, log formats, log storage, log transmission, log access, log analysis, log retention and log disposal.
 
Scope
This policy applies to all <Company Name>’s Application Logs, System Logs, Network Logs, Change Management Logs, Physical Access Logs and Surveillance Logs.
 
Policy
<Company Name>’s log management practice encompasses the following:
Defines log generation requirements.
Defines log format requirements.
Defines log transport requirements.
Defines log storage requirements.
Defines log access requirements.
Defines log analysis tool requirements.
Defines log retention requirements.
Defines log disposal requirements.
 
Log Generation Requirements
Application Logs
  • Applications should have the capability to record their activity to support business processes and regulatory mandates.
System Logs
  • System logs are generated from a wide variety of sources. Example sources of system logs are operating systems, authentication servers, database servers, web servers, print servers, file servers, DHCP servers, DNS and email servers. System logs should be capable of recording the following:
  • Record requested operations.
  • Record whether the request was accepted or denied.
  • Record the time and date the operation was performed.
  • Record who and/or what system initiated the operation.
  • Record system and network resources used.
Network Logs
  • Network logs are generated from a wide variety of sources. Example sources of network logs are routers, switches, intrusion detection and prevention systems, wireless access points, network based firewalls, host based firewalls and telephone switches. Network logs should record the following:
  • Record the IP addresses or telephone numbers of the end points.
  • Record the port numbers for each of the end points.
  • Record whether connections where accepted or denied.
  • Record the date, time and duration of connections.
  • Record the number of packets and bytes of traffic.
Change Management Logs
  • Change Management Logs are governed by the Change Management Policy.
Physical and Surveillance Access Logs
  • Physical and Surveillance Access Logs are governed by the Environmental Controls Policy.

Log Format Requirements
  • Logs will be archived in a standard format.
 
Log Transport Requirements
  • Logs will traverse the network in encrypted format.
 
Log Storage Requirements
  • Logs will be stored in a secured centralized repository.
 
Log Access Requirements
  • Logs will be view exclusively by approved personnel.
 
Log Analysis Requirements
  • Logs analysis tools will parse records from multiple sources and protect the original log data in the event log records are used in legal proceedings.
 
Log Retention Requirements
  • Log retention requirements are governed by the Record Retention Policy.
 
Log Disposal Requirements
  • Log Disposal requirements are governed by the Media Sanitization Policy.
 
Policy Review
This policy will be reviewed annually.
 
Compliance
Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
 
Related Policies
Change Management Policy
Environmental Controls Policy
Record Retention Policy
Media Sanitization Policy
 

Incident Response

This section reviews incident response capabilities and introduces an example Incident Response Policy. The section begins with a brief overview of incident response capabilities and an introduction to NIST Special Publication 800-61 and concludes with an example Incident Response Policy. Incident Response is a field unto itself and a detailed review of its principles, processes, and approach is beyond the scope of this book. This section shows the importance of incident response capabilities, introduces additional references and shows how Incident Response relates to an ORacle private cloud.
 
Even with the most sophisticated, state of the art security systems and effective policies, security incidents will occur. The most common security incidents are viruses, malware, laptop theft and employee network abuse. Less common security events are denial of service attacks, sabotage, intellectual proprietary theft, fraud and system penetration from external sources. Sooner or later, every organization will need to respond to a security incident. A quick, well orchestrated response will minimize loss and damage; in contrast, a poor response could result in financial, legal, and public relations problems.
 
An Incident Response Policy is used to define how an organization responds to security incidents. It is an action oriented policy that isused to provide guidance to quickly detect security incidents, minimize loss, mitigate exploited weaknesses and rapidly restore services. The majority of the Enterprise Architecture policies reviewed in this book have been passive policies that provide guidance with appropriate systems usage, technology standards, system design, system configurations and auditing. An Incident Response Policy is an action oriented policy that requires quick and efficient execution in order to protect an organization’s assets.
 
In regards to Oracle VM, security incidents can occur at the hypervisor and virtual machine layers. An example of some of the incidents that originate from the hypervisor and virtual machine layers are malware infection, network abuse, sabotage, intellectual proprietary theft and fraud. These types of security incidents are typically discovered by technical or administrative security controls, an audit or an employee. When one of these security incidents is detected, an Incident Response Policy is the primary administrative control used to mitigate the damage.
 
Organizations that must comply with regulatory mandates must undergo regular audits to validate incident response capabilities. A number of widely adopted guidelines can be used to assist organizations in understanding how to implement incident response capabilities. Two examples ofguidelines are ISO/IEC 17799 section 13 and NIST Special Publication 800-61.
 
The NIST Special Publication 800-61 is a free, 148-paged Computer Security Incident Handling Guide which containseight chapters and ten appendixes. The goal of NIST Special Publication 800-61 is to assist organizations to establish computer security incident response capabilities. It is an in-depth document that is widely adopted and used in both the public and private sectors to implement incident response capabilities.
 
List 7 shows NIST Special Publication 800-61 areas of focus:
  • Organizing a computer security incident response capability.
  • Establishing incident response policies and procedures.
  • Structuring an incident response team.
  • Handling incidents from initial preparation through the post-incident lessons learned phase.
  • Handling specific types of incidents.
 
The following Incident Response Policy defines how an organization responds to security incidents. The example policy starts with a Purpose and Scope statement and then proceeds with the policy. This policy is intended for informational purposes only.

Incident Response Policy

Purpose
This purpose of this policy is to define a formal reporting and response procedure to be followed when responding to security incidents. Implementing formal reporting and response procedures ensures that information security events are communicated in a manner allowing timely corrective action to be made while applying a consistent approach to the management of information security incidents.
 
Scope
This policy applies to all employees and non-employees working for or with <Company Name>.
 
Policy
A security incident is described as one or more of the following conditions:
  • Any potential violation of Federal law, State law, or <Company Name> policy involving an Information Technology (IT) asset.
  • A breach, attempted breach or other unauthorized access to <Company Name’s> IT asset.
  • Any Internet worm, virus, Denial of Service (DoS) attack or related incident.
  • Any change in a computer system that disables or defeats security precautions.
  • Any failure in network or computer systems that disrupts IT services.
  • Any employee or non-employee who violates policy.
 
Reporting a Security Incident
Employees and non-employees working for or with <Company Name> will immediately report the following:
  • A security incident that involves unauthorized physical access to a building or secure location, physical threat, imminent danger or personal safety issue.
  • An actual or suspected security incident that involves unauthorized access to information systems.

Excluding the steps outlined below, it is essential that all investigative or corrective action be taken only by InfoSec personnel. When faced with a potential security incident, employees and non-employees should do the following if the incident involves a compromised computer system:
  • Do not alter the state of the computer system.
  • The computer system should remain on and all currently running computer programs should be left as is.
  • Do not shutdown or restart the computer.
  • Immediately disconnect the computer from the network by removing the cable from the back of the computer.
  • Report the security incident to InfoSec.
 
InfoSec Contacts:
<Names and Phone Numbers>
 
Response
InfoSec staff will first determine if the Security Incident justifies a formal incident response. In cases where a Security Incident does not require an incident response, the situation will be forwarded to the appropriate area of operations to ensure that all technology support services required are rendered.
 
An incident response may range from getting a critical system back online, gathering evidence, taking appropriate legal action against individual(s), or in some cases notifying appropriate ISP's or other third parties of inappropriate activity originating from their network.
 
Any contacts or attempted contacts from the media regarding an incident should be redirected to the marketing/communication department.
 
Policy Review
This policy will be reviewed annually.
 
Compliance
Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
 
The example Incident Response Policy shows how a policy is used to define how an organization responds to security incidents.
 

Audit Vulnerability Assessments

This section begins with an overview of a Vulnerability Assessment, followed by an example tier 2 Audit Vulnerability Scan Policy. Vulnerability Assessments are an essential tool for determining the security posture of an Enterprise and arean integral part of a security program. Vulnerability Assessments can be performed in house or by an independent 3rd party. Many organizations choose to use both in order to gain a broader perspective of their security posture.  
 
Please Note: Never perform a Vulnerability Assessment without explicit and preferably written permission from your employer. Network and security administrators with the best intentions have been fired for performing Vulnerability Assessment without proper authority to do so.  
 
A Vulnerability Assessment is a technique of evaluating the security posture of an Enterprise or network using passive and active analysis of the target systems for known weaknesses, technical flaws, or vulnerabilities. Vulnerability Assessments provides a level of assurance that script kiddies, skilled intruders and malicious users cannot compromise an organization’s systems. Vulnerability Assessments should be performed on all supporting computers and networking gear that touch the Terminal Server environment. It is not uncommon for organizations to perform a Vulnerability Assessment monthly or immediately after vulnerabilities are discovered or become publicized on the Internet. For example, if there is a mis-configured Oracle VM environment, it could be compromised by a well known vulnerability and used as a hacking vector to other systems behind thefirewall.  
 
The Vulnerability Assessment process involves passive and active analysis of the target systems for known weaknesses, technical flaws or vulnerabilities. All of the discovered security issues will be presented to the system owners, together with a detailed assessment of the impact and a proposal for mitigation.
 
Vulnerability Assessments follows the typical pattern that an intruder or malicious user would use to gain information about a target host or network. This first step starts with reconnaissance. Reconnaissance can be a quick ping sweep to see what IP addresses on the network respond; searching newsgroups on the Internet looking for ill-advised employees divulging useful information; or it can be dumpster diving to find useful information like passwords, employee names and contacts.
 
Basic reconnaissance can be performed by visiting a vendor' website looking for customer references (targets), an organization’s website and gathering as much information as possible about the company. Public websites generally yield a wide variety of information that could be used to exploit systems and trick employees. For example, many organizations list the names of their management team on their public website. This information can be used for a social engineering attack, allowing an attacker to call or email employees using the names of the management staff to trick an employee into giving the attacker valuable information.
 
Many public websites provide hints as to the type of systems an organization uses, which can be used to craft an attack against known vulnerabilities. Other reconnaissance techniques include using publicly available tools, such as InterNIC (http://www.internic.net/) and ARIN (http://www.arin.net/), to collect additional information about the domain registrations. Reconnaissance can also include theft, deception, tapping phones and networks, impersonations, or even leveraging falsified relationships to gather data about a target. The search for information is only limited by the extremes an attacker is willing to go.
 
Note: Social engineering is a method used to obtain confidential information by manipulation and deception.
 
After an intruder has collected enough information, the next step is to scan the target organization’s external facing systems or network for open ports and services. The scanning process can yield important information, such as ports open through the router and firewall, available services and applications on hosts’ or network appliances, and possibly the version of the operation system or application. After an intruder has mapped out available hosts, ports, applications and services, the next step is to test for known vulnerabilities that might exist on a host or network. When vulnerabilities are discovered, attacks are crafted and launched against systems. If attackers are able to compromise a system and gain access, they do their thing (whatever that is), and then they try to cover their tracks and leave a back door.
 
List 8 shows the pattern an attacker usesto penetrate systems:
  • Reconnaissance
  • Scanning
  • Craft an attack
  • Cover their tracks
There are many reasons why an organization would choose to perform a Vulnerability Assessment.
 
List 9 highlights some of the reasons:
  • Identify threats facing an organization’s information assets so they can be quantified to produce a risk analysis.
  • Provide an organization with assurances that they have a thorough and comprehensive assessment of their organizational security policies.
  • Gain and maintain certification to industry regulations (BS7799, Sarbanes-Oxley, HIPAAA, etc).
  • Adopt best practice by conforming to legal and industry regulations.
 
A Vulnerability Assessment involves the systematic analysis of an organization’s IT portfolio. It is crucial to set expectations, scope the project and have the explicit permission from management to perform the Vulnerability Assessment. The exact requirements should be agreed upon in a formal document or Statement of Work (SOW) prior to starting the project.
 
The real value of a Vulnerability Assessment is in the final report and executive summaries that are delivered to management and system owners. The deliverables need to be clear and easy to understand. The reports and executive summaries should be broken into sections that specifically target their intended audience, i.e. management, system owners, and so forth. Non-technical stakeholders will need the risks and possible solutions clearly described in layman's terms; technical managers need a broad overview of the situation without being confused with too much detail; and system administrators need a host-by-host list of technical vulnerabilities to address.
 
List 10 shows the minimum deliverables of a Vulnerability Assessment:
  • Executive summary.
  • Detailed results of the testing performed.
  • What the results indicate.
  • Recommendations on types of corrective actions suggested.
 
The next example shows an Audit Vulnerability Scan Policy from the SANS Policy Project that defines the agreement to perform network security scanning. The example policy starts with a Purpose and Scope statement and then proceeds with the Policy. This policy is intended for informational purposes only.


Audit Vulnerability Scan Policy

Purpose
The purpose of this agreement is to set forth our agreement regarding network security scanning offered by the <Internal or External Audit Name> to the <Company Name>.   <Internal or External Audit Name> shall utilize <Approved Name of Software> to perform electronic scans of Client’s networks and/or firewalls or on any system at <Company Name>.
 
Audits may be conducted to:
Ensure integrity, confidentiality and availability of information and resources.
Investigate possible security incidents ensure conformance to <Company Name> security policies.
Monitor user or system activity where appropriate.
Scope
This policy covers all computer and communication devices owned or operated by <Company Name>. This policy also covers any computer and communications device that are presently on <Company Name> premises, but which may not be owned or operated by <Company Name>.   The <Internal or External Audit Name> will not perform Denial of Service activities.
 
Policy
When requested, and for the purpose of performing an audit, consent to access needed will be provided to members of <Internal or External Audit Name>. <Company Name> hereby provides its consent to allow <Internal or External Audit Name> to access its networks and/or firewalls to the extent necessary to allow [Audit organization] to perform the scans authorized in this agreement. <Company Name> shall provide protocols, addressing information and network connections sufficient for <Internal or External Audit Name> to utilize the software to perform network scanning.
 
This access may include:
  • User level and/or system level access to any computing or communications device.
  • Access to information (electronic, hardcopy, etc.) that may be produced, transmitted or stored on <Company Name> equipment or premises.
  • Access to work areas (labs, offices, cubicles, storage areas, etc.).
  • Access to interactively monitor and log traffic on <Company Name> networks.

Network Control
If Client does not control their network and/or Internet service is provided via a second or third party, these parties are required to approve scanning in writing if scanning is to occur outside of the <Company Name’s> LAN. By signing this agreement, all involved parties acknowledge that they authorize <Internal or External Audit Name> to use their service networks as a gateway for the conduct of these tests during the dates and times specified.
 
Service Degradation and/or Interruption
Network performance and/or availability may be affected by the network scanning.   <Company Name> releases <Internal or External Audit Name> of any and all liability for damages that may arise from network availability restrictions caused by the network scanning, unless such damages are the result of <Internal or External Audit Name>’s gross negligence or intentional misconduct.
 
Client Point of Contact during the Scanning Period
<Company Name> shall identify in writing a person to be available if the <Internal or External Audit Name> Scanning Team has questions regarding data discovered or requires assistance.
 
Scanning period
<Company Name> and <Internal or External Audit Name> Scanning Team shall identify in writing the allowable dates for the scan to take place.
 
Compliance
Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
 
The above Audit Vulnerability Scan Policy example shows how a policy can provide an organization with a strategy to engage in network security scanning.
 
Resources:
Federal CIO Council Website:  https://cio.gov/resources/document-library/
Commonwealth of Pennsylvania, Office of Administration: http://www.oit.state.pa.us/
Texas Department of Information Resources: http://www.dir.state.tx.us.
FIPS PUB 31
ISO IEC 17799 2005
NIST Special Publication 800-12
NIST Handbook Chapter 15
NIST Special Publication 800-92
NIST Handbook Chapter 18
ISO/IEC 17799 Section 10
NIST Special Publication 800-61
NIST Handbook Chapter 12
ISO/IEC 17799 section 13
 
Document Created:  01/03/2014
Last Update: 01/03/14
 
Copyright © 2015 Mokum Solutions, Inc. 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.