Compliance at Launch: Pre-Assessed Web Applications

Most companies are required to certify that their applications meet common international standards for security, such as ISO 27001, AICPA SOC-2, or the PCI-DSS. In order to streamline the process of obtaining that certification when deploying on OCI; we have created a reference architecture that meets all three of these standards – and had it pre-assessed by Schellman & Co – one of the premier certification firms.

If you have workloads that store, process or transmit credit card information, then you need to secure your systems and design the data security policies in a Payment Card Industry (PCI) compliant way. You can use Oracle's PCI-compliant Cloud Infrastructure services to launch your web application.
By following the recommendations in this Reference Architecture, you can maintain and manage your Payment Card Industry Data Security Standard (PCI-DSS) compliance for those applications and workloads that you use on the cloud.

In addition to PCI, if your workloads rely on the effectiveness of controls relevant to the security, availability, or processing integrity of the system used to process clients' information, or the confidentiality or privacy of that information; then you need to secure your systems and design the data security policies in an ISO 27001 and SOC-2 compliant manner. You can use Oracle's ISO 27001 and SOC-2 compliant Cloud Infrastructure services to launch your web application; and by following the recommendations in this Reference Architecture, you can maintain and manage your ISO 27001 and SOC compliance with respect to applications and workloads that you use on the cloud.

A Readiness Assessment of a deployment of this reference architecture was performed by Schellman & Company, LLC: an independent Certified Public Accounting (CPA) firm, a globally licensed PCI Qualified Security Assessor, and ISO Certification Body.

PCI Compliance

Their PCI Readiness report, validates that deploying this architecture as configured meets the requirements of PCI-DSS, SOC-2, and ISO 27001. A Roles and Responsibility Matrix outlining the additional recommended steps is also available in GitHub.

ISO 27001 Compliance

Their ISO Readiness report, validates that deploying this architecture as configured meets the control requirements defined in ISO 27001 Annex A, as well as to identify user entity (customer) responsibilities for implementing certain aspects of each control activity to achieve alignment with ISO 27001 Annex A.

SOC 2 Compliance

Their SOC 2 readiness report, validates that deploying this architecture as configured meets the suitability of the design of the controls to achieve a user entity’s (customers) service commitments and system requirements based on the criteria for the security, availability, and confidentiality categories set forth in the 2017 TSP section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (AICPA, Trust Services Criteria) (the “applicable trust services criteria”), as well as to identify user entity (customer) responsibilities for implementing certain aspects of each control activity to achieve alignment with the AICPA SOC 2 Trust Services Criteria.

You must assess and configure your environment for PCI, ISO 27001, and SOC-compliance and complete the certification audit of your production system.

Architecture

This reference architecture illustrates how organizations can enhance the security of their data on OCI by setting up a PCI, ISO 27001 and SOC compliant web application using PCI, ISO 27001 and SOC compliant Chef compatible cookbooks and Terraform modules.

The following diagram illustrates this reference architecture.Description of launch_pci_webapp_on_oci.png follows
Description of the illustration launch_pci_webapp_on_oci.png

This architecture contains a load balancer and a NAT gateway to provide secure access to the internet. The load balancer, application tier with Apache Tomcat, and database tier with Oracle Autonomous Transaction Processing are in different subnets. These subnets can be accessed through a bastion host. The traffic between the internet and the bastion host is through an internet gateway. Customers can access instances in the private subnet through the OCI Web Application Firewall and load balancer via an internet gateway. The Network Address Translation (NAT) gateway enables application and Wazuh instances that are attached to private subnets in the VCN to access the public internet. Connections through the NAT gateway can be initiated from the resources within the VCN, and not from the public internet.

The architecture has the following components:

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Availability domains

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Fault domains

    A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.

  • Virtual cloud network (VCN) and subnets

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Security lists

    For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.

  • Bastion host

    The bastion host is a compute instance that serves as a secure, controlled entry point to the topology from outside the cloud. The bastion host is provisioned typically in a demilitarized zone (DMZ). It enables you to protect sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. The topology has a single, known entry point that you can monitor and audit regularly. So, you can avoid exposing the more sensitive components of the topology without compromising access to them.

  • Tomcat Server

    Apache Tomcat® is an open source Java application server. It implements the Java Servlet, JavaServer Pages, Java Expression Language and Java WebSocket technologies. The web application exists in this layer.

  • Autonomous Transaction Processing

    Oracle Autonomous Transaction Processing is a self-driving, self-securing, self-repairing database service that is optimized for transaction processing workloads. You do not need to configure or manage any hardware, or install any software. Oracle Cloud Infrastructure handles creating the database, as well as backing up, patching, upgrading, and tuning the database.

  • Wazuh Server
    Wazuh is a free, open source and enterprise-ready security monitoring solution for threat detection, integrity monitoring, incident response and compliance providing.
    • Host-based Intrusion Detection

      Wazuh agent runs at a host-level, combining anomaly and signature based technologies to detect intrusions or software misuse. It can also be used to monitor user activities, assess system configuration and detect vulnerabilities.

    • Comprehensive SIEM Solution

      Wazuh is used to collect, analyze and correlate data, with the ability to deliver threat detection, compliance management and incident response capabilities. It can be deployed on-premises or in hybrid and cloud environments.

  • Object storage

    Object storage provides quick access to large amounts of structured and unstructured data of any content type, including database backups, analytic data, and rich content such as images and videos. Use standard storage for "hot" storage that you need to access quickly, immediately, and frequently. Use archive storage for "cold" storage that you retain for long periods of time and seldom or rarely access.

  • Vault

    Oracle Cloud Infrastructure Vault enables you to centrally manage the encryption keys that protect your data and the secret credentials that you use to secure access to your resources in the cloud.

  • Web Application Firewall

    Oracle Cloud Infrastructure Web Application Firewall (WAF) is a cloud-based, payment card industry (PCI) compliant, global security service that protects applications from malicious and unwanted internet traffic. WAF can protect any internet-facing endpoint, providing consistent rule enforcement across a customer's applications.

  • DNS

    The Oracle Cloud Infrastructure Domain Name System (DNS) service lets you create and manage your DNS zones. You can create zones, add records to zones, and allow Oracle Cloud Infrastructure's edge network to handle your domain's DNS queries.

  • SSL Certificates

    SSL certificates are created using Let’s Encrypt, and deployed to the Web Application Firewall.

Recommendations

Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.
  • VCN

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

    After you create a VCN, you can change, add, and remove its CIDR blocks.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

  • Network Connectivity

    To enable your administrators to manage the environment, you can connect the cloud topology to your existing on-premises infrastructure by using site-to-site IPSec VPN connections or dedicated FastConnect circuits.

    If the cloud topology needs to be isolated from the on-premises infrastructure, you can deploy a bastion host to secure management access to the resources in the private subnets.

Considerations

Consider the following points when deploying this reference architecture.

  • Performance

    This Reference Architecture initially deploys a single Virtual Machine running Apache Tomcat. Based on your application’s requirements, you should modify the autoscaling rules to spin up additional hosts based on appropriate load metrics.

  • Security

    Use policies to restrict who can access the Oracle Cloud Infrastructure resources that your company has and how. For Object Storage, encryption is enabled by default and can’t be turned off.

    Except for the bastion host (if you have one in your architecture) and load balancers, all the components should be placed in private subnets.

  • Manageability

    A Terraform script deploys a pre-configured tenancy. You can use it as a template to manage this infrastructure as code in your own code repository.

  • Availability

    This reference architecture may leverage services and configurations that are not available in regions within the Government Cloud realm.

Deploy

The Terraform code for this reference architecture is available on GitHub. You can download the code from GitHub to your computer, customize the code, and deploy the architecture by using the Terraform CLI.

  1. Go to GitHub.
  2. Clone or download the repository to your local computer.
  3. Follow the instructions in the README document.