Application Container IS Audit/Assurance Program

Application Container Audit/Assurance Program

Column Name Description Instructions
Process Sub-area An activity within an overall process influenced by the enterprise's policies and To make the audit program manageable, it is recommended to break out the scope of the audit into sub-areas. The auditor can
procedures that takes inputs from a number of sources, manipulates the inputs and modify this field to entity-specific names and terms. ISACA has used the most commonly used terms as the basis to develop this
produces outputs audit program.
Ref. Risk Specifies the risk this control is intended to address This field can be used to input a reference/link to risk described in the entity's risk register or enterprise risk management (ERM)
system or to input a description of the risk a particular control is intended to address.
Control Objectives A statement of the desired result or purpose that must be in place to address the This field should describe the behaviors, technologies, documents or processes expected to be in place to address the inherent
inherent risk in the review areas within scope risk that is part of the audit scope.

An IS audit manager can review this information to determine whether the review will meet the audit objectives based on the
risk and control objectives included in the audit program.

Controls The means of managing risk, including policies, procedures, guidelines, practices or This field should describe in detail the control activities expected to be in place to meet the control objective. Control activities
organizational structures, which can be of an administrative, technical, can be in roles and responsibilities, documentation, forms, reports, system configuration, segregation of duties, approval
management or legal nature matrices, etc.

An IS audit manager performing a quality control review must decide whether an auditor has planned to identify enough controls
on which to base an assessment and whether the planned evidence is sufficiently objective.

Control Type Controls can be automated (technical), manual (administrative) or physical. Specify whether the control under review is automated, manual, physical or a combination. This information is useful in
determining the testing steps necessary to obtain assessment evidence.
Automated/technical controls are things managed or performed by computer
systems.
Manual/administrative controls are usually things that employees can or cannot do.
Physical controls include locks, fences, mantraps and even geographic specific
controls.

Control Classification Another way to classify controls is by the way they address a risk exposure. Specify whether the control under review is preventive, detective, corrective or compensating. This information will be helpful
when defining testing steps and requesting evidence.
Preventive controls should stop an event from happening.
Detective controls should identify an event when it is happening and generate an
alert that prompts a corrective control to act.
Corrective controls should limit the impact of an event and help resume normal
operations within a reasonable time frame.
Compensating controls are alternate controls designed to accomplish the intent of
the original controls as closely as possible when the originally designed controls
cannot be used due to limitations of the environment.

Control Frequency Control activities can occur in real-time, daily, weekly, monthly, annually, etc. Specify whether the control under review occurs in real-time, daily, weekly, monthly, annually, etc. This information will be
helpful when defining testing steps and requesting evidence.

Copyright 2018 ISACA Page 1 of 6

Application Container IS Audit/Assurance Program

Application Container Audit/Assurance Program

Column Name Description Instructions
Testing Step Identifies the steps being tested to evaluate the effectiveness of the control under This field should describe in detail the steps necessary to test control activities and collect supporting documentation. The auditor
review can modify this field to meet entity-specific needs. ISACA has used a set of generic steps to develop this audit program.

An IS audit manager may determine if the proposed steps are adequate to review a particular control.

Ref. Framework/Standards Specifies frameworks and/or standards that relate to the control under review (e.g., Input references to other frameworks used by the entity as part of their compliance program.
NIST, HIPAA, SOX, ISO)
Ref. Workpaper The evidence column usually contains a reference to other documents that contain Specify the location of supporting documentation detailing the audit steps and evidence obtained.
the evidence supporting the pass/fail mark for the audit step.
An IS audit manager performing a quality control review must decide whether an auditor has tested enough controls on which to
base an assessment and whether the obtained evidence is sufficiently objective to support a pass or fail conclusion.

Pass/Fail Document preliminary conclusions regarding the effectiveness of controls. Specify whether the overall control is effective (Pass) or not effective (Fail) based on the results of the testing.
Comments Free format field Document any notes related to the review of this Process Sub-area or specific control activities.

Copyright 2018 ISACA Page 2 of 6

Application Container IS Audit/Assurance Program

Application Container Audit/Assurance Program

Planning
Process Ref. Control Control Ref. Framework/ Ref.
Sub-area Risk Control Objectives Controls Control Type Classification Frequency Testing Step Standards Workpaper Pass/Fail Comments
Risk associated with containerization is A security review of 1. Interview security team members and/or review artifacts of risk identified during prior security reviews.
commensurate with enterprise risk tolerance. containerization is performed 2. Ensure that security reviews are performed on the schedule identified by the enterprise.
Risk Analysis and

on a periodic basis.
Management

The enterprise's IT risk and governance A container vulnerability 1. Obtain an understanding of the enterprise's container vulnerability assessment/remediation program.
program addresses containers. assessment/remediation 2. Confirm that all container application program elements are being performed and that any deficiencies noted have been remediated.
program has been designed Program elements may include, but are not limited to:
and implemented. • Formal deployment strategies with guidance on issue severity and corresponding remediation timeframes
• Security scans that identify issues as well as monitor system performance (as an indicator of variance from baseline)

Roles and responsibilities have been clearly Information security roles of IT 1. Obtain the enterprise's policies and procedures related to application containerization. These may include, but are not limited to, the
defined so that organizational goals well as IT Operations and of Developers information security policy, application development policy, software development security policy and secure coding policy.
objectives are met. have been defined and 2. Review the policies/procedures to confirm that the roles of both IT operations and development have been defined.
communicated. 3. Interview the appropriate personnel to determine how the enterprise communicates policy expectations.
Note: Compared to the traditional application 4. Confirm that for applicable policies, the enterprise's communication protocol was followed.
model, developers play a larger role in 5. If the enterprise has a policy acknowledgment process, confirm that IT operations and development personnel have active policy
security in the application container acknowledgments on file.
environment. For example, because
developers create images upon which
containers are built, developers may perform
patching, a function performed by IT
Operations under a traditional application
model.

Data integrity is preserved through all phases Segregation of duties has been 1. Obtain an understanding of the enterprise's strategy to ensure segregation of duties.
of application containerization (planning, created and is maintained in 2. Assess the adequacy of the strategy. Depending on the enterprise's application container environment (manual or automated), include the
Security Awareness and Training

development, deployment, maintenance and the application container following points in the assessment.
destruction). environment.
Manual Environment
1. Interview appropriate personnel to obtain an understanding of IT operations and development responsibilities.
2. Identify any potential lack of segregation in which one individual's access permissions are not limited based on the ability to perform multiple
phases of a process; evaluate the potential risk.

Automated Environment
1. Determine who has repository access to store images and who can download images. In Docker®, for example, this access is reflected in the
Docker trusted registry (DTR).
2. If defaults have been changed so that users can see containers other than their own, identify what user teams or groups have been created
and the levels of control they have been assigned (e.g., read only or full control). Determine what resources the users have control over. In
CoreOS rkt® (or Rocket®) for example, reliance is on the Linux control group feature for organizing processes into hierarchical groups and
applying limits to the groups.

Roles and responsibilities have been clearly Developers are educated Interview appropriate training personnel (or the chief information officer or chief information security officer) to identify application security
defined so that organizational goals well as IT about their roles related to training opportunities within the most recent twelve months.
objectives are met. application security and are
provided with training on Internal Training
security best practices. • Review security awareness training materials and ensure that the training includes containers.
• If the training is mandatory, confirm that IT operations and development staff have completed the training.
• If the training is not mandatory, determine how IT operations and development staff obtain and maintain awareness of the enterprise's
security best practices and expectations.

External Training
Confirm that any relevant external training is also reported by personnel to the enterprise (under professional development).

Copyright 2018 ISACA Page 3 of 6

Application Container IS Audit/Assurance Program

Application Container Audit/Assurance Program

Development & Deployment
Process Ref. Control Control Ref. Framework/ Ref.
Sub-area Risk Control Objectives Controls Control Type Classification Frequency Testing Step Standards Workpaper Pass/Fail Comments
The principle of least privilege is applied to Formal access management protocols 1. Obtain the enterprise's access management policy and review the portions related to application containers.
ensure that users do not have access (including but not limited to least 2. Obtain a list of people who were hired, transitioned from DevOps, or separated from the enterprise within the most recent
beyond what is required to perform their privilege) exist and are enforced. twelve months.
responsibilities. 3. From the population obtained above, make a selection of new hires, position transfers, and recent terminations. Confirm that
access was granted/modified/revoked for new hires, position transfers and recent terminations respectively in a timely manner.
For the sample of new hires and transfers, determine whether the access in place aligns with the access approved.
4. In assessing the appropriateness of access, confirm that users cannot log on directly to the host without authentication to an
orchestration layer.
Host Operating System

Note: Namespace can also provide information about users and groups and the resources to which they have access.

The attack surface of the host OS is Unnecessary services are deactivated 1. Through discussion with administrators, obtain an understanding of the enterprise's strategy for reducing the host OS's
minimized by deactivation of unnecessary or a lightweight distribution is used to attack surface.
services. minimize the OS attack surface. 2. Confirm that the host OS runs only those services identified in the strategy.

Risk of using a shared kernel, which is Note: Options for managing the host OS may include use of lightweight Linux® distribution or designation of a specific build for
inherent in the application container container hosting. Docker® and Rancher® OS are examples of specific builds. Specific OSs can contribute to a reduced attack
infrastructure, is mitigated by reduction in surface by not having components such as libraries.
the attack surface.

The network type selected by the Network traffic between containers 1. Determine the type of network. In Docker®, for example, run the command to view existing container networks on the
enterprise supports the enterprise's on the same host is restricted. current Docker host. The command is docker network ls. Docker will return the network ID and the network type, host,
strategic objectives while ensuring bridge, overlay, or underlay. Network types include:
confidentiality of network traffic.
• None—This type features a network stack, with no external network interface, but includes a loopback interface.
• Bridge—This type has a namespace for each container provisioned inside a bridge. The bridge is provisioned on each host.
Iptables with network address translation (NAT) map between each private container and the host’s public interface.
• Overlay—This type features a distributed network that covers (i.e., "overlays") host-specific networks.
Networking

• Underlay—This type features hosts that interface directly with containers.

2. After determining the type of network, consider the enterprise’s operations to assess any risk associated with the network
type. For example, if container services need to be exposed to outside users, a bridge network is likely not the best choice.

Compromise of container runtime is The enterprise mitigates container 1. Confirm that the default setting (which would allow individual containers to access each other and the host over the
Container Runtime

mitigated to prevent exploitation of runtime risk at launch and monitors network) has been changed.
runtime software, which may allow a risk on an ongoing basis. 2. Identify the process that the enterprise uses to validate input. This process may reflect a manual procedure or an automated
malicious actor to monitor container to tool to ensure that inputs align with the enterprise's standard for acceptable input. Note that in addition to other inputs, the
container communications or even access validation inputs may include configuration files, credentials and scripts during the build phase.
the containers themselves. 3. Determine whether the enterprise has adopted best practices related to container runtime as outlined by the Open
Container Initiative® (OCI®).

Introduction of vulnerabilities (e.g., The enterprise designs and ` 1. Obtain information regarding the enterprise's strategy and protocols for trusted images. The enterprise's approach may
untrusted software or malware) via image implements a process around trusted include, but not be limited to, a central repository of trusted images, as well as control points within the development and
downloading is minimized. images. deployment phases that ensure only trusted images are used.
2. Confirm that DOCKER_CONTENT_TRUST environment variable has been enabled so that only signed images can be used.
Images

Copyright 2018 ISACA Page 4 of 6

Application Container IS Audit/Assurance Program

Introduction of vulnerabilities (e.g.,

untrusted software or malware) via image Application Container Audit/Assurance Program
downloading is minimized.
Development & Deployment
Process Ref. Control Control Ref. Framework/ Ref.
Sub-area Risk Control Objectives Controls Control Type Classification Frequency Testing Step Standards Workpaper Pass/Fail Comments
Sources of third-party images are For a sample of recently downloaded images, confirm that verification took place prior to download.
verified prior to download and before • For enterprises using Docker®, confirm that Docker® Content Trust is enabled. This feature supports whitelisting of
use by the enterprise. repositories from authorized/trusted third parties.
• For enterprises using rkt® (CoreOS Rocket®) or application container platforms, confirm that image scanning procedures are
in place.
Note: In addition to third-party container security solutions, there are open source solutions as well.
Images

• Determine if the enterprise has adopted best practices related to container images as outlined by the Open Container
Initiative® (OCI®).
Note: Malware detection should occur for images in registries as well as on the host.

Security risk is minimized through the As part of risk analysis, the enterprise 1. Obtain documentation of the enterprise's image configuration protocol.
design and implementation of image identifies image configuration 2. Identify tools used by the enterprise to enforce its protocol.
configuration protocols. protocols that align with the 3. Interview appropriate personnel regarding compliance with the enterprise's image configuration protocol. Through these
enterprise's risk tolerance. interviews, as well as review of documentation, confirm that alignment of configuration practices with protocol is assessed and
ensure that any variances identified are resolved.
4. Confirm that digital signatures are verified prior to a container being placed in production.

Confidentiality and security of images are The enterprise ensures that its Observe settings and interview administrators to confirm that development tools, container runtime and orchestrators support
maintained. registries are conducted over a secure encrypted channels for registries.
channel.

The enterprise uses tags on images to 1. Obtain information regarding how the enterprise identifies images that may need to be pruned because they have never
Registry

support identification and removal of been used or for other reasons. For example, enterprises that use Docker® may use the command of docker image
outdated images. prune to remove unused images.
2. Use the docker image inspect command to get detailed information on images.
3. Review the image information to determine if any images selected for testing are outdated according to the enterprise's
criteria.

Data confidentiality and security are The principle of least privilege is 1. From the list of users obtained in host OS testing above, select a sample or users/groups and identify the access that
maintained at the orchestrator level. applied to ensure that access is users/groups have to certain containers, the host and images.
tailored to certain actions on certain 2. Given the roles of the users/groups, assess whether access is appropriate given the users'/groups' roles.
Orchestrator

containers. Note that in its support of 3. Identify whether any users/groups have access to production.
multiple applications, a single
orchestrator can involve different
teams with different levels of
sensitivity.

Applications are less susceptible to The enterprise employs a robust 1. Interview software development staff and/or review process documentation for any in-house developed software to ensure
During Development
Application Security

exploitation. application development process that software is developed using a robust process with a focus on building security into the process.
and/or application security 2. Confirm that patching is done in accordance with an enterprise wide accepted patching protocol or program. This
development approach that confirmation should include review of patching for virtualization libraries (e.g., libcontainer, libvirt). Note that unlike traditional
adequately secures development application models where patching is performed by IT operations, application container patching is part of the application build.
(e.g., threat modeling).

Copyright 2018 ISACA Page 5 of 6

Application Container IS Audit/Assurance Program

Application Container Audit/Assurance Program

Maintenance
Process Ref. Control Control Ref. Framework/ Ref.
Sub-area Risk Control Objectives Controls Control Type Classification Frequency Testing Step Standards Workpaper Pass/Fail Comments
Sensitive data related to secure connections The enterprise uses its own sensitive data Confirm that sensitive data related to secure connections are stored outside of images.
Connections

between application container components management system or an orchestration

(e.g., user name and password) are not platform (e.g., Docker®, Swarm® or
Secure

compromised while stored in the image. Kubernetes®) for sensitive data

management (i.e., secrets management).

A formal hardening program minimizes The hardening program has a scanning 1. Review the results of the most recent vulnerability assessment and/or penetration testing activities.
security risk. component that supports identification of 2. Ensure that testing is conducted periodically and that identified issues are addressed in a timely manner.
vulnerabilities in critical devices and
applications.

The hardening program incorporates 1. Obtain a sample of recent application scanning results and/or testing results.
application security scanning software 2. Review the results and ensure that artifacts are timely and reflect ongoing/periodic use; confirm that any identified issues are
(i.e., dynamic or static testing tools) or addressed.
employs application-focused security
testing to ensure that applications are
Hardening

secure.

Changes in container runtime are minimized Immutable containers are used to prevent Review the environment to ensure that containers as well as container elements are immutable.
so that changes take place during build shell access to container images, which
rather than in production. mitigates possible creation of a
vulnerability.

Built-in security is leveraged in order to Linux® features, such as Security 1. Determine the status of SELinux via the UNIX®/LINUX getenforce command.
reduce the node attack surface. Enhanced Linux (SELinux) and Secure The getenforce command results indicate whether SELinux is enabled and whether its mode is enforcing or permissive.
Computing Mode (Seccomp), are used. Please note that if hardened, the mode will be enforcing.
2. Determine if Seccomp is enabled by using the command:
$ grep CONFIG_SECCOMP=/boot/config-$(uname-r)CONFIG_SECCOMP=y

Integrity is maintained throughout the life The enterprise mitigates risk associated 1. Obtain an understanding of the enterprise's policy/protocol related to the end of life of application containers. The
Container Destruction

cycle of containers. with containers remaining active beyond policy/protocol should include, but not be limited to, requests and approvals to destroy a container.
their useful life (for example, a better 2. Because all data created over the container's lifetime are deleted when the container is destroyed, confirm how the
program has been created). enterprise ensures no data retention requirements are adversely affected (e.g., requirements related to compliance or
electronic discovery).
3. If the enterprise uses Docker, determine which method of destruction is used:
• docker rm—final destruction
• docker export—archives the container's file system
• docker import—retains the option of creating another container using the destroyed container

Copyright 2018 ISACA Page 6 of 6