Understanding the Enterprise

Advantages of Application
Containerization: Practitioner
Considerations
SECOND IN A WHITE PAPER SERIES FROM ISACA

ABSTRACT
Enterprises are rapidly adopting application containersand the reasons are clear.
Containers allow data centers to deploy business applications more rapidly, with reduced
development overhead, lower costs, more efficient use of resources and increased
business agility. However, potential risk areas also arise as a result of using containers
in certain scenarios. To make proper risk management decisions, practitioners must
evaluate business value and risk holistically, which includes understanding both the risk
and business value for application containerization. In the second installment in this white
paper series, we examine the issues for practitioners managing this innovation. In the
previous installment in this white paper series, we looked at the factors contributing
to the popularity of this innovation.

Understanding the Enterprise Advantages of Application Containerization: Practitioner Considerations

Like any technology, application containerization can present

challenges depending on the specifics of usage. Likewise,
new and unique business opportunities can be engendered
by the strategic use of containers. Therefore, practitioners
who are making risk decisions within their environment need
to understand both the risk side of the equation and the value
side to make the decision that is right for their business.
Moreover, the landscape is not static: because of the opensource context of application containerization, developers
are openly addressing these challenges and sharing their
discoveries, solutions and successes. A challenge that exists
today may not continue to exist tomorrow. This makes it even
more important that practitioners understand not only the risk
equation as it exists now, but also how it is likely to evolve
going forward to support the conclusions they draw.

As one might intuit given these adoption statistics, there is an

implicit business value proposition that makes the employment
of containers compelling. Potential risk areas also arise as a
result of using containers in certain scenarios: threat and risk
scenarios that either arise because of, or are facilitated by, the
adoption of containers.

This white paper is the second paper in the ISACA Application

Containerization Series of white papers. This paper focuses on
the benefits and challenges of application containers, including
risk and value impacts, and provides practical guidance to
enterprises on application containerization and its orchestration
technologies. This white paper is complemented by the
first white paper in the series, Understanding the Enterprise
Advantages of Application Containerization: An Overview,
which describes the technology, explains how application
containers and supporting tools work, and provides examples
of application containerization products that are available in
the market today.

Like other technologies, a near-infinite array of potential contextspecific scenarios exist, where containers can potentially
impact business processes. Making a determination about
these scenarios, though, is business-specific. To evaluate the
potential risk/value trade-off for a situation, practitioners need to
understand their own business well enough to understand value
generation in a given situation. They also need to understand
their enterprise threat context well enough to understand the
potential threats that might arise.

Note: Application containerization is very different from

mobile containerization, which places enterprise data that are
on a mobile device inside a container and applies security
policies to the container to keep enterprise data protected and
separate from the mobile device users data. This white paper
focuses on application containerization and does not discuss
mobile containerization.

BUSINESS IMPACT OF
CONTAINERIZATION
In many areas of business, enterprises are undergoing a
transformation as a result of container technology. The
adoption of containers is rapidly on the rise. For example, the
recent State of Containers and the Docker Ecosystem 2015
report from Ruxit and OReilly Media found that 93 percent of
respondents are already usingor plan to usecontainers for
development. Moreover, 53 percent of respondents plan to
adopt containers in production within the next year.

To make a risk management decision, practitioners must

evaluate both business value and risk holistically. Practitioners
must understand both the value proposition and the potential
gain that enterprises can accrue as a result of container use
and the potential risk/threat downside. This section discusses
some of the ways that value can be created and some of the
potential risk aspects.

Business Value

Because of this enterprise-specific contextual information,

to attempt to abstractly evaluate the many context-specific
examples of risk/value trade-offs that pertain to a specific
usage situation is not practicable. However, for the developer
and in the data center, containers can add value in the majority
of situations and for the majority of enterprises; these situations
and benefits are outlined in the following two sections.
DEVELOPER BENEFITS
From a development point of view, containers offer some
immediate benefits. First and foremost, from a security
standpoint, there is a possibility to enhance the security
profile of individual applications. Specifically, the platform
can be leveraged to allow more optimal and timely updating
of individual components upon which a given application
residesfor example, to patch or update support libraries or
middleware components. In a more monolithic environment,
this might present logistical challenges that are more readily
overcome in a containerized situation.
Moreover, the portability offered by containers can bring about
value to the developer. Specifically, because containers are
portable, developers can create a container for unit-testing
purposes and customize the container as they develop an
application, e.g., to add support libraries, middleware or

2016 ISACA. All rights reserved.

Understanding the Enterprise Advantages of Application Containerization: Practitioner Considerations

configuration changes that are required for the application

to function appropriately. Granted, portability is not unique
to containers alone; for example, in a hypervisor context
(i.e., operating system [OS] virtualization), individual guest
OS instances might be portable to a degree (for example,
allowing migration of an instance between hypervisors in
different environments or between hypervisors of different
OSs); however, containerization has some advantages in
portability relative to OS virtualization. First, the efficiency of
a container results in a smaller package because a container
will not contain the full OS base installation. This allows
developers to quickly and easily configure their unit testing
environment, while allowing rapid migration quickly to
downstream environments, e.g., from a developers unit
testing environment or test harness, to integration or staging
environments, then to quality assurance (QA), and then,
potentially, into production. Moreover, there is a separation
created between the application and the constraints of the
underlying infrastructure upon which it runsthis means that
developers can spend less time focused on configuration of the
individual runtime and more focus on the implementation and
testing of the business logic the application demands.
From the point of view of the developer, this portability has a
few positive consequences. It streamlines and makes more
efficient the developers time. Specifically, container portability
helps to reduce the time that developers spend supporting
environmental customization, in preparation for a release to
production. Consider, for example, the typical amount of time
that a developer spends supporting configuration-related
issues in intermediate, i.e., non-production, environments.
In many cases, this time can be significant. By allowing
the developer to focus on the needs and configuration of
the application that he or she is developing (and view the
configuration of the host outside the container as a black
box), a developer can spend less time supporting the
environment (e.g., configuring middleware, installing code
libraries and deploying support components) and more time
authoring and refining business logic in the application itself.
Aside from these efficiency advantages, containers also enable
a reduced footprint of delivered applications. Specifically,
containers allow the creation of microservicessmaller
footprint services that, together, are used as building blocks
for larger applications. Microservices can help facilitate
reuse of already-developed software and components, and,
thereby, lead to additional development efficiencies. Note
that microservices are by no means unique to a containerized
environment; however, because they are facilitated by
containers, microservices can very realistically be factored

into the value proposition for containers.

DATA CENTER BENEFITS
Containers also offer efficiency advantages within the data
center. Consider a virtualized environment in most data
centers, for example. A typical virtual data center might
consist of rack upon rack of identically configured (or nearly
so) hypervisors, with each one running instances of virtualized
guest OS images that are also nearly identical. Any given
hypervisor within that environment might run multiple clones
of a given virtual machine (VM), might host multiple images
based on the same nearly-identical OS configuration, etc.
In short, there is often tremendous redundancy from a
storage point of view and multiple CPU cycles that are
spent executing redundant or non-business-relevant tasks.
To see this in action, consider the amount of software in the
full application stack that is identical between two virtual
images running the Linux + Apache + MySQL + PHP (LAMP)
stack: the kernel is the same; the core OS binaries (e.g.,
bash, sed and chmod) are the same; the higher level software
in the stack (e.g., the Apache daemon) is the same. What is
different between these virtual images? In many cases, the
only differences are the specific configuration adjustments,
middleware, supporting libraries and application code that is
required to support the applications that are fielded into that
environment. By sharing the underlying levels of the stack,
drawing the segmentation demarcation point closer to the
application and creating a package that targets specifically
the delta that is required by the application to run, the amount
of redundancy decreases.
Imagine the resultant impact of this increase in efficiency on
the storage, memory, network and computational efficiency
of the environment in aggregate. Instead of storing thousands
(or more) of fully configured Linux hosts, with all the required
dependencies, containers store only a handful. Rather than
spending millions of cycles running a common binary image
(e.g., cron or syslog) across every VM, a container runs only a
handful of times because its services are centralized and shared.
In addition to efficiency advantages, operational advantages
are associated with the use of containers. By reducing the
surface area of redundant software within the application stack,
containers can also reduce the management overhead that is
required with supporting that configuration base. For example,
with the historically challenging maintenance task of patching OS
and application software, the less OS software to maintain, the
more that burdensome task is potentially reduced.

2016 ISACA. All rights reserved.

Understanding the Enterprise Advantages of Application Containerization: Practitioner Considerations

Moreover, because of the portability associated with

containers, it can bring about a shift in the mentality that
is associated with supporting the production environment.
This shift can bring with it operational advantages within
the data center, depending on context. An example of how
containerization enables operational advantages is software
patching. Historically, the most efficient path to patching (in
either a physical or virtualized infrastructure) was to patch
an image or host in the production environment, leveraging
rollback capability, or redundant hosts in the case of physical
infrastructure, or snapshot/cloning capability in a virtualized
case. By contrast, leveraging a containerized environment
can allow alternative strategies to be employed, such as
apply application patches to the container in a different
(non-production) environment and only push the content to
production (blowing away the existing containers that are
running the non-patched code) after the patch has been
fully tested and vetted.

Potential Risk Areas

In addition to their potential value-adding opportunities,
containerslike any new or unfamiliar technologycan also
have some areas of risk that may not be immediately intuitive
to the practitioner.
ISOLATION
At the individual container level, OS virtualization and
containers are not the same thing from a risk model
perspective. For example, the isolation mechanisms that are
used by containerization platforms are differentand have
differing propertiesfrom the isolation mechanisms that a
hypervisor employs. One might, for example, reasonably make
the assumption that execution of code within a guest OS in a
virtualization contexteven privileged (i.e., root) execution
cannot, under normal circumstances, be used to subvert the
hypervisor itself or used as a vector to attack other images
that are running on that same hypervisor. Although there
have been some well-publicized attacks against the isolation
methodologies (e.g., VENOM) in use by hypervisors, these
attacks are rare and generally rapidly addressed by hypervisor
vendors as a security-impacting issue.
In a containerized situation, though, a process inside a
container is already (because of its execution) interfacing
directly with the kernel of the underlying host.1 Subversion
of the isolation mechanism (regardless of how it occurs)
potentially impacts the underlying OS and other containers

that are on the same host. For example, a root-level process

that is inside a container that directly accesses a device
structure, like /dev/mem, can allow the isolation mechanism
to be circumvented;2 the isolation mechanism is not currently
built to prevent this situation from occurring. Instead, it is
assumed that practitioners will understand the security model
and employ usage that is appropriate to how that model
works. This understanding can impact the type and content
of containers that practitioners feel are appropriate for a
multitenant situation, it can bring about additional questions
or scrutiny about the need for and use of elevated privilege
within individual containers, or it can cause practitioners to
question or limit execution of untrusted containers or those
for which they do not have full understanding of provenance.
ISSUES AT SCALE
In addition to changes in the risk model at the level of the
individual container, practitioners should keep in mind the
following considerations at scale:
SprawlMuch like in a virtualized environment, users,
developers and administrators sometimes have a tendency
to request the fielding of a container for which they do not
have a robust plan to eventually decommission. Although
some environments may have fielded controls already to
help mitigate sprawl in the virtual side of the house, those
mechanisms may not have visibility into the containerized
side of the ecosystem.
Asset ManagementAlthough the major container
environments in the field today natively maintain a registry
of fielded containers, the information contained therein
may not always be sufficient to accomplish certain critical
tasks. For example, in the case of incident response, it is
often beneficial to have easy access to information about
business contacts for specific applications, information
about processes that are supported by an application, etc.
Unless action is taken to incorporate this information into
the asset management process, this information may be
challenging to locate in real time during an incident.
Stale/Unmaintained ContainersThe ease by which
containers can be created and fielded can sometimes lead
developers to fire and forget, i.e., field an application for
which there is no support or maintenance plan.

1 Walsh, Daniel J.; Are Docker containers really secure?, 22 July 2014, https://opensource.com/business/14/7/docker-security-selinux
2 Ibid.

2016 ISACA. All rights reserved.

Understanding the Enterprise Advantages of Application Containerization: Practitioner Considerations

KERNEL EXPLOITS
Unlike in a VM, the kernel is shared among all containers and
the host, magnifying the importance of any vulnerability that is
present in the kernel. If a container causes a kernel panic, it will
take down the whole host. In VMs, the situation is much better:
an attacker would have to route an attack through both the VM
kernel and the hypervisor before being able to touch the host
kernel. For example, rootkits3 that operate at the kernel level
can pose a critical threat.
CONTAINER BREAKOUTS
An attacker who gains access to a container should not
be able to gain access to other containers or the host. It is
imperative that end users understand the security model of the
environment they are working within; they should, for example,
consider potential privilege escalation attacksfor example, a
bug in application code running with root privileges. For most
organizations, the software running within the container will be
code written by them; however, in a multitenant environment,
or in the situation where an organization is running software
not directly created by them, they should be alert to potential
attacks against the isolation features and plan accordingly.

evaluate them in light of changes toor adoption ofnew

technologies like containers.

PRACTITIONER
CONSIDERATIONS
For practitioners in the field, some by-discipline considerations
that are associated with the use of containers are important to
consider. This section outlines some of the considerations for
the security, assurance and governance disciplines.

Security
From a security point of view, the use of containers can be
a valuable tool in the practitioners toolbox and/or a potential
source of risk.
Potential positive security benefit can be associated with the
adoption of containers. There are a few ways in which this is
possible; notably:
Immutability of infrastructure
Application hardening

COMPROMISING SECRETS
When a container accesses a database or service, it will
likely require a secret, such as an API key or username and
password. An attacker who can get access to this secret
also has access to the service. This problem becomes more
acute in a microservice architecture in which containers
are constantly stopping and starting, as compared to an
architecture with small numbers of long-lived VMs.
MULTITENANCY ISSUES
Hosting multiple tenants on the same host creates data
confidentiality issues. The implementation of security
models, such as the Brewer and Nash model and the
Chinese Wall model,4 are more important in the context
of application containerization than in the context of the
application virtualization.
Note that the risk areas presented here are not an exhaustive
list. Like the value side of the risk/value trade-off, specific risk
considerations can and will vary according to enterprise usage,
threat model, business, industry and numerous other factors.
Therefore, it is imperative that enterprises understand the risk
dynamics for their particular organization and systematically

Streamlined patching
Automation of security controls
The first point, immutability points to the notion that the
production software that we field persists in a knownreliable state throughout its lifespan.5 Consider a
production environment in a traditional (non-containerized)
infrastructure; production support of that environment
might include numerous modifications: installation of
new packages, upgrading of packages, modification of
source or configuration files, etc. Over time, these one-off
tweaks, modifications, changes, manual steps, etc. can
lead to differences between nodes; these differences can,
in turn, lead to unexpected application behavior, including
security issues as well as other potential complexities. Use
of containers can facilitate instead an immutable server
approachthis is an approach that minimizes the manual
modification of the node and instead draws upon automated
techniques to rapidly rebuild and re-field an application
into production. This can minimize individual idiosyncrasies
between nodes and offer a more stable (over time) platform
upon which the application runs.

3 A rootkit is a software suite designed to aid an intruder in gaining unauthorized administrative access to a computer system.
4 For information about the Brewer and Nash model and the Chinese Wall model, see Kelley Sobel, Ann E.; Jim Alves-Foss, A Trace-Based Model of the Chinese Wall Security Policy, proceedings paper
from the 22nd National Information Systems Security Conference, October 18-21, 1999, National Institute of Standards and Technology (NIST) and National Computer Security Center of the National
Security Agency, http://csrc.nist.gov/nissc/1999/proceeding/papers/p9.pdf
5 Petazzoni, Immutable Infrastructure with Docker and Containers, GlueCon 2015, www.slideshare.net/jpetazzo/immutable-infrastructure-with-docker-and-containers-gluecon-2015

2016 ISACA. All rights reserved.

Understanding the Enterprise Advantages of Application Containerization: Practitioner Considerations

Secondly, containers can facilitate the hardening of

application software compared to a bare metal installation.
Keep in mind that applications in a containerized environment
are isolatedboth from each other and from the underlying
OS. Should an application be compromised, these isolation
features can potentially mitigate the damage that can be
effected by an attacker against other applications on the
same host or the underlying OS itself.6
Thirdly, as noted previously, some areas of historical
operational challenge can be partially mitigated through
the use of containers. First and foremost, containers can
potentially help to streamline, simplify, and make faster the
patching process. An enterprise that is challenged today with
keeping the production environment fully patched and vetted
can potentially help to streamline the patching process by
leveraging containers as a portable way to transplant tested/
vetted applications from a staging environment to production.
And lastly, automation of certain security controls can be
facilitated through the use of containers. For example,
dynamic web application security testing techniques can
be leveraged to help ensure that fielded applications are
appropriately hardened and resilient against attack. From
an asset management standpoint, practitioners should keep
in mind that leveraging the container repository can assist
with creation and maintenance of an accurate inventory of
applications, which can be challenging to effect in either a
physical or virtual infrastructure context.
The risk areas in the previous section also represent potential
areas that security practitioners may wish to keep in mind from
a countermeasure deployment standpoint. It is imperative that
security practitioners understand the security model used, they
understand (at a technical level) the operation of the tools in
scope and they consider the available countermeasures to help
mitigate issues. For example, regarding the potential impacts
that are associated with root privilege, practitioners may wish
to consider tools or techniques that limit that accesslikewise,
practitioners may wish to examine products in the marketplace
(e.g., Docker Security Scanning Aqua and Twistlock) that
are designed specifically to enforce security policy in a
containerization context.

Assurance
For the auditor, containers can likewise affect their workflow
in potentially positive and negative ways. In terms of potential
positive benefit, there are two main areas to note:
Streamlined OS and configuration review
Supply chain analysis benefits
First and foremost, the reduction in footprint that is
associated with use of containers within the data center can
have a direct benefit in the amount of time and attention that
is required by auditors to sample and vet OS images. For
example, because the application is packaged and fielded
as a unit in a container situation, the requirement to ensure
that the OS on which the application runs may decrease
in scale and thereby complexity. Unlike OS virtualization,
there is no guest OS of which to systematically test the
hardening, configuration and maintenance. Auditors who
are seeking to ensure that their efforts are as useful and
practical to the enterprise as possible can potentially spend
less time focused on vetting the underlying OSs and more
time focused on activities that directly impact the application,
such as application configuration, the business logic that the
application implements and the processes that it supports.
With that potential advantage also comes a change in
the mechanics of how an auditor needs to approach the
environment so that his or her activities remain relevant. For
example, given the complexities in the isolation mechanisms
employed (outlined previously), an auditor may wish to
spend more time investigating privileged account use
within the container and how container configuration is
effected (including the processes that enforce appropriate
segmentation of duties). At a minimum, the auditor needs to
understand the containerization technology that is employed,
the isolation methodology by which it operates and any
constraints (particularly legacy constraints) that may impact the
appropriate operation of the model in the enterprise usage.
Secondly, the analysis of the supply chain for applications
can be simplified from an assurance standpoint. Consider
a deployment scenario for a traditional application. There
may be multiple internal groups such as build teams and
operations groups, third parties such as business partners
or vendors, and numerous other participants that might have
a hand in fielding a given application. From an auditor point
of view, this means numerous places in the delivery chain
that an auditor must evaluate to ensure that the end result
is reliable. Containers can help mitigate this. Specifically, it
is possible to watermark a container to detect tampering.

6 McCauley, Nathan, Your Software Is Safer In Docker Containers, Docker, 23 August 2016, https://blog.docker.com/2016/08/software-security-docker-containers

2016 ISACA. All rights reserved.

Understanding the Enterprise Advantages of Application Containerization: Practitioner Considerations

Docker, for example, supports application signinga feature

that allows images to be cryptographically signed by a
publisher and verified prior to execution. This allows the user
of that image to verify prior to execution that the resultant
image has not been modified during storage or in transit.7
While not every containerization platform natively supports
this, ancillary controls could be implemented to provide
similar functionality (for example, file integrity monitoring tools
could be employed as an add-on control to similar effect.)
This could provide assurance to the assessor about the
integrity of the fielded application.
In addition to these possible benefits, containers change
the game in a few other ways from the auditor point of view.
Specifically, it can change the focus of the auditor as they
approach an assessment of a containerized environment.
As audit plans are typically prepared a year in advance
and containers may be new technology for some auditors,
additional work spent preplanningin preparing audit
methodologies to address containerization and potentially
adapting methodologies/techniques to container usage
situationscan occur.

Governance
From a governance standpoint, it is important to recognize
that a shift from a non-containerized to a containerized
usage scenario can impact existing governance structures
and artifacts. Governance practitioners may wish to revisit
existing policy to ensure continued appropriateness in light of
a containerization effort. They may wish to examine the people
and their skill sets to ensure that they have the staff with the
right skills who are equipped to maximize value and minimize
risk. Governance practitioners may also want to ensure that
critical goalslike segregation of duties, asset management
and risk managementcontinue to operate appropriately in
light of the shift to containerization.

CONCLUSION
Containerization is an important and potentially gamechanging technology for developers and data centers that
deploys business applications more rapidly, with reduced
development overhead, lower costs, more efficient use of
resources and increased business agility. New and unique
business opportunities can be engendered by the strategic use
of containers.
Like most new technologies, application containerization
presents some challengesparticularly, emergent behaviors
at scale, possible new risk that is not present until containers
start moving into the production environment and threat
scenarios that are unique to the usage. Practitioners need
to consider potential assurance, security and governance
impacts along with the potential risk and value factors. To
make a holistic risk decision, practitioners must evaluate
these potential impactson the risk side and the value side
and make a determination for their environment based on
their enterprises set of requirements, the nuances of their
particular business, and in light of their enterprises usage.
The technology and management practices of application
containers will continue to mature over time in much the same
way that the VM space developed and maturated. Remaining
abreast of these changes and reevaluating decisions in
light of these changes will continue to be necessary for the
foreseeable future.

7 Docker, Securing The Enterprise Software Supply Chain Using Docker, Docker, 23 August 2016, https://blog.docker.com/2016/08/securing-enterprise-software-supply-chain-using-docker

2016 ISACA. All rights reserved.

Understanding the Enterprise Advantages of Application Containerization: Practitioner Considerations

APPENDIX: SUGGESTED CONTROLS

FOR CONTAINERIZATION
Containers can impact the enterprise significantly, regardless
of the specific discipline/role within which practitioners operate.
Practitioners have a number of factors to consider, only a few
of which are discussed in this white paper. To help practitioners
prepare for container usage, the following table outlines several
suggested controls that practitioners may wish to consider for

CONTROL

Configuration
management

Vulnerability
assessment and
penetration testing

Application
security process
management

Application security
testing/scanning

their own use. Note that this is not intended to be an exhaustive

list, and not every control will be appropriate for every
enterprise or situation. As always, practitioners should evaluate
the specifics of control usage and implement controls based
on their enterprise risk profile and unique factors.

PURPOSE

IMPLEMENTATION

ASSURANCE STEPS

Ensure containers are kept in

a hardened state and known
configuration.

Establish a known-good
configuration for containers and
relevant infrastructure. Leverage
technical measures to ensure that
this configuration is enforced.

Observe configuration
management system and
interview administrator
personnel to ensure technical
settings are appropriate
to ensure known-good
configuration.

Ensure that containerrelevant infrastructure is

appropriately patched.

Leverage vulnerability scanning

tools to locate vulnerabilities in
critical devices and applications
to ensure that issues are identified
and appropriately remediated.

Review the results of

vulnerability assessment
and/or penetration testing
activities. Ensure that testing
is conducted periodically
and that issues identified are
addressed.

Ensure that applications are

robust and hardened.

Utilize a robust application

development process and/or
application security development
approaches that engender
secure development (e.g., threat
modeling).

Interview software
development staff and/or
review process documentation
for any in-house developed
software to ensure that
software is developed using
a robust process with a focus
on building security into the
process.

Ensure that applications are

robust and hardened.

Utilize application security

scanning software (i.e., dynamic
or static testing tools) or employ
application-focused security
testing to ensure that applications
are secured.

Review the output of a sample

of application scanning results
and/or testing reports. Ensure
that artifacts examined are
timely and reflect ongoing/
periodic use, and that identified
issues are addressed.

2016 ISACA. All rights reserved.

Understanding the Enterprise Advantages of Application Containerization: Practitioner Considerations

continued
CONTROL

PURPOSE

IMPLEMENTATION

ASSURANCE STEPS

Risk analysis

Ensure that container usage,

including associated risk,
is commensurate with
organizational risk tolerances.

Conduct a security review of

containerization in use. Implement
compensating controls as
needed.

Interview security team

members and/or review
artifacts of risk analysis.
Ensure that risk analysis was
performed.

Security
awareness training

Ensure developers and

administrators are aware of
container-specific security
issues.

Integrate containers into

employee security awareness
training where applicable.

Review security awareness

training materials. Ensure
that training addresses
containers.

2016 ISACA. All rights reserved.

10

Understanding the Enterprise Advantages of Application Containerization: Practitioner Considerations

3701 Algonquin Road, Suite 1010

Rolling Meadows, IL 60008 USA

ISACA

Phone: +1.847.253.1545

ISACA (isaca.org) helps global professionals lead, adapt and assure trust in an evolving

Fax: +1.847.253.1443

digital world by offering innovative and world-class knowledge, standards, networking,

Email: info@isaca.org

credentialing and career development. Established in 1969, ISACA is a global nonprofit

Web site: www.isaca.org

association of 140,000 professionals in 180 countries. ISACA also offers the Cybersecurity
Nexus (CSX), a holistic cybersecurity resource, and COBIT, a business framework to

Provide feedback:
www.isaca.org/containerization

govern enterprise technology.

Participate in the ISACA

Knowledge Center:
www.isaca.org/knowledge-center

Disclaimer

Follow ISACA on Twitter:

https://twitter.com/ISACANews
Join ISACA on LinkedIn:
ISACA (Official),
http://linkd.in/ISACAOfficial

This is an educational resource and is not inclusive of all information that may be needed to assure a successful outcome.
Readers should apply their own professional judgment to their specific circumstances.

Reservation of Rights
2016 ISACA. All rights reserved.

Like ISACA on Facebook:

www.facebook.com/ISACAHQ

2016 ISACA. All rights reserved.

Understanding the Enterprise Advantages of Application Containerization: Practitioner Considerations

11

ACKNOWLEDGMENTS
ISACA wishes to recognize:
Expert Reviewers

Board of Directors

Madhav Chablan

Christos K. Dimitriadis

CISA, CISM, India,

TippingEdge Consulting Pvt. Ltd. (India)

Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece, Chair

Anuj Jain

CISM, RAK Ceramics P.S.C., UAE

CISA, CGEIT, CRISC, CIA, CGAP, CGMA, CPA, U.S. House

of Representatives, USA, Vice-chair

Shruti Shrikant Kulkarni

Robert Clyde

CISA, CRISC, CISSP, CCSK, CPISI, ITILv3 Expert,

LA - ISO27001, Monitise Group Ltd, UK

Michael R. Lawrence

CISSP, Hewlett Packard Enterprise, USA

Nathan McCauley
Docker, USA

Sergiu Sechel

CISA, CISM, CRISC, CSSLP, CEH,

Ernst & Young, Romania

Dan Walsh

Red Hat, USA

Theresa Grafenstine

CISM, Clyde Consulting LLC, USA, Director

Leonard Ong

CISA, CISM, CGEIT, CRISC, CPP, CFE, PMP, CIPM, CIPT,

CISSP ISSMP-ISSAP, CSSLP, CITBCM, GCIA, GCIH,
GSNA, GCFA, Merck, Singapore, Director

Andre Pitkowski

CGEIT, CRISC, OCTAVE, CRMA, ISO27kLA, ISO31kLA,

APIT Consultoria de Informatica Ltd., Brazil, Director

Eddie Schwartz

CISA, CISM, CISSP-ISSEP, PMP, WhiteOps, USA, Director

Jo Stewart-Rattray

CISA, CISM, CGEIT, CRISC, FACS CP, BRM Holdich,

Australia, Director

Tichaona Zororo

CISA, CISM, CGEIT, CRISC, CIA, CRMA, EGIT | Enterprise

Governance (Pty) Ltd., South Africa, Director

Zubin Chagpar

CISA, CISM, PMP, Amazon Web Services, UK, Director

Rajaramiyer Venketaramani Raghu

CISA, CRISC, Versatilist Consulting India Pvt. Ltd.,

India, Director

Jeff Spivey

CRISC, CPP, Security Risk Management, Inc., USA, Director

Robert E Stroud

CGEIT, CRISC, Forrester Research, USA, Past Chair

Tony Hayes

CGEIT, AFCHSE, CHE, FACS, FCPA, FIIA, Queensland

Government, Australia, Past Chair

Greg Grocholski

CISA, SABIC, Saudi Arabia, Past Chair

Matt Loeb

CGEIT, FASAE, CAE, ISACA, USA, Director

2016 ISACA. All rights reserved.