Twistlock: 7 Experts on Cloud-Native Security

Experts on
Cloud-Native
Security
Expert Advice on Transitioning from a
Traditional Security Approach to a Modern,
Cloud-Native Security Approach
7
Sponsored by®

FOREWORD
2
Regards,
Ben Bernstein
CEO, Twistlock
With the adage “software is eating the world” becoming truer everyday, it’s more
important than ever that companies deliver software to their customers at speed and
scale. Unfortunately, speed and scale are two things cybersecurity hasn’t done well
in the past. This is because traditional cybersecurity begins after applications are
deployed, relying on manual policies and constantly outdated blacklists to deliver
protection. Cloud native cybersecurity flips this approach on its head, and utilizes
machine learning to provide fully-automated, whitelist based protection for software
applications.
Twistlock’s mission is to provide a complete, enterprise-grade security platform for
the cloud native ecosystem, so organizations can securely adopt and maximize the
benefits of containers, microservices, and serverless across the entire production
environment — thereby securing today’s applications from tomorrow’s threats.
Twistlock is the leading provider
of container and cloud native
cybersecurity solutions for
the modern enterprise. From
precise, actionable vulnerability
management to automatically
deployed runtime protection
and firewalls, Twistlock protects
applications across the
development lifecycle and into
production. Purpose built for
containers, serverless, and other
leading technologies - Twistlock
gives developers the speed they
want, and CISOs the control they
need.
THE MODERN ENTERPRISE REQUIRES CLOUD
NATIVE CYBERSECURITY
Sponsored by

TABLE OF CONTENTS
3
WILLIAM CABAN
NUWAN BANDARA LEVI BLACKSTONE DAN BOWDEN DANIEL NEWSOME
MARCELO GREBOIS KEVIN PRICE
DEVOPS TECHNICAL SOLUTIONS
ARCHITECT
WORLD WIDE TECHNOLOGY
DIRECTOR, SOLUTIONS ARCHITECTURE
WSO2
SENIOR SOFTWARE ENGINEER
RACKSPACE
VP & CISO
SENTARA HEALTHCARE
TECHNICAL ARCHITECT
ZONAR SYSTEMS
CLOUD INFRASTRUCTURE ARCHITECT
LARGE MULTINATIONAL AUTOMOTIVE
CORPORATION
PRINCIPAL INFRASTRUCTURE
ENGINEER, INFORMATION SECURITY
GE APPLIANCES, A HAIER COMPANY
Cloud Native Requires
Rethinking Traditional App
Development: P5
When Architecting a Cloud
Native App, Think about End-
to-End Security: P14
A Cloud Native Environment
Enables More Granular
Defense in Depth: P17
Bake as Much into the DevOps
Process as Possible: P20
Work Incrementally, and
Take Full Advantage of Cloud
Native Tools: P23
Developers Need to Learn
More about Security: P8
Select Security Tools that
Work in an Automated
DevOps Workflow: P11
Sponsored by

WILLIAM CABAN
William Caban has more than 20 years
of experience architecting, designing,
and delivering advanced solutions in
multiple fields across enterprises and
service providers. Today, he supports
organizations with strategies, designs,
and integrations of cloud native
platforms and modern paradigms
supporting microservices architectures
and DevOps methodologies. His
passion is to enable business
transformation through technology,
changing the world one “bit” at a time.
DevOps Technical
Solutions Architect
World Wide Technology
Twitter | LinkedIn
W
illiam Caban, DevOps technical solutions architect for World Wide Technology,
recognizes that moving to a cloud native approach can be difficult. There’s a steep
learning curve for some organizations because of the way they have to re-architect
their applications, and even re-architect the way their processes work. “But in the end, all
that pays off,” Caban says. “There is a possibility to achieve the theoretical 100% availability
because of the way cloud native platforms work. They provide self-healing and auto-scaling
capabilities, geo-distribution, not just around multiple data centers, but across clouds. It’s
become a multi-cloud, multi-data center world. All these capabilities are intrinsic to the
applications architected as cloud native applications.”
One of the aspects developers and architects need to rethink involves how to implement
security controls in a cloud native environment. This relates to how cloud native applications
are built and delivered, the nature of containers used to run the microservices that make up
those applications, and the cloud environments themselves.
Another area of change, for example, is where security happens in the app development
process. In a traditional app development model, developers create the app, do unit,
integration, and quality-assurance testing, and then build a release candidate that goes
through a security check.
It’s become a multi-cloud, multi-data center world.
All these capabilities are intrinsic to the applications
architected as cloud native applications.
4
CLOUD NATIVE REQUIRES RETHINKING TRADITIONAL APP DEVELOPMENT
Sponsored by

Because of the way
containers are spun
and destroyed,
traditional vulnerability
scanning tools do not
work for cloud native
applications.
But with cloud native applications relying on microservices that run in
standalone containers, and when those microservices are released
incrementally and continuously, the traditional model no longer works,
it becomes a bottleneck and security issues are detected too late in the
process. “That cannot be the model anymore,” Caban says. “Security
must now be embedded in the very first stages of the CI/CD pipeline.”
Scanning and patching also need to be reconsidered. “Because of
the way containers are spun and destroyed, traditional vulnerability
scanning tools do not work for cloud native applications,” notes Caban.
“Patching [also] does not exist in the traditional sense. With cloud native
applications you do not patch. You replace by deploying a new version
of the container supporting the microservice.”
Caban advises that before building a cloud native application, you must
thoroughly understand the host cloud environment. “When we start using
cloud providers, we need tools that understand the security models in
those cloud platforms. The first step to understanding what policies we
need to enforce in an application is knowing what is not covered by
the cloud platform. In building a cloud native app, we are not replacing
platform controls. We are augmenting them,” he says.
5Sponsored by

Before building a cloud native application, you must
thoroughly understand the host cloud environment so
you can augment its security controls at the app level.
With microservices running in standalone containers
that are released incrementally and continuously, secu-
rity must be embedded in the very first stages of the CI/
CD pipeline.
1 2
KEY POINTS
6
He also recommends applying a zero-trust model at the infrastructure level. “With the zero-trust model, basically
nothing happens unless you explicitly allow it,” Caban explains. “It’s a first level of security, but it’s important because
an infrastructure can extend across data centers and across the cloud. If something is compromised in any of those
locations, it can compromise the whole organization.”
Caban believes that cloud native applications are inherently more secure than traditional on-premises applications.
“If we follow the best practices for cloud native development and a zero trust model, if we’re using containers that are
immutable, read-only objects providing the services, there’s almost nothing to attack. There is a minimal attack surface”
he says. “Even if there is an attack, it cannot change the code.”
Sponsored by

MARCELO GREBOIS
Marcelo Grebois excelled at coding
at a young age, participating in
several competitions during his high-
school years. He holds two bachelor
degrees, in Physics and Computer
Science, from the University of
Buenos Aires, as well as two
postgraduate degrees in Security
and Informatics Forensics from the
University of Technology, Argentina.
Grebois’s career began as a system
administrator, focusing on automation
and data-center infrastructure. Today,
he is a key contributor to several
open source-projects, and takes
pride in designing high-availability
systems.
Cloud Infrastructure
Architect
Large Multinational
Automotive Corporation
Twitter | LinkedIn
A
s a cloud-infrastructure architect, Marcelo Grebois sees many security
advantages in developing and deploying cloud native applications. He
also emphasizes that even if you need to look at security in new ways, the
fundamentals of data security remain the same. “You have to do authentication,
authorization, and accounting,” Grebois says. “You have to segregate permissions,
and scan everything that is going to production, and disable everything that you are
not using to reduce attack surface area. All this is the same as it has been since the
beginning of time in IT. What’s new in cloud native applications is that the measures
taken to ensure these good practices are ubiquitous. It’s much easier to embrace
security best practices now with cloud native applications.”
At the heart of cloud native security is the container itself, which gives the app
developer fine-grained control over security policies and the ability to test during
development. This makes it possible to architect more secure applications. “One
major change is that cloud native pushes everyone into a microservices mentality,
and microservices are a way of segregating permissions,” Grebois explains. “Even
if you fail to address security in one microservice, that doesn’t mean you have a
big vulnerability. The fact that the application is containerized is a huge security
improvement over conventional apps, because the container itself is exactly that,
a container. It’s unlikely to get privilege escalations within the container, if the
underneath infrastructure is well designed.”
It’s much easier to embrace security best
practices now with cloud native applications.
7
DEVELOPERS NEED TO LEARN MORE ABOUT SECURITY
Sponsored by

One major change
is that cloud native
pushes everyone into a
microservices mentality,
and microservices are
a way of segregating
permissions.
With all these advantages, Grebois says there are things you
should do to make sure your cloud native apps are secure and
compliant. For instance, container auditing is a good idea, and
he recommends encrypting communication between containers
when you are dealing with highly sensitive data.
Grebois also advises caution when using serverless applications,
which are small apps that run as functions in a container
provided by a cloud service provider rather than one you
configure and test yourself. Serverless apps are great for simple
functions, because you don’t have to configure or test anything.
You just write the code and submit it to the serverless app utility.
It becomes incredibly easy to deploy new code in a serverless
architecture. The risk comes from having less control over
the attack surface of a serverless environment. When using
serverless functions, it’s important to use tools that provide
visibility into the serverless environment so that you can see
dependencies and potential vulnerabilities.
8Sponsored by

The fact that the application is containerized is a huge
security improvement over conventional apps. It’s very
unlikely to get privilege escalations within the contain-
er, if the underlying infrastructure is well designed.
A lot of security testing can be automated in cloud
native app development, but developers need to learn
more about security, and security people still need to
be involved.
1 2
KEY POINTS
9
A lot of security testing can be automated in cloud native app development, but developers need to learn
more about security, and security people still need to be involved. “There are two parts to this,” says
Grebois. “The company needs to be responsible for training developers how to enforce security, because
you cannot expect a developer to automatically know how to do these things. And then you should also
have a security audit or security officer checking that requirements are being met.”
Sponsored by

KEVIN PRICE
Kevin Price is an information
technology professional with more
than a decade of experience in
software design, architecture, project
and resource management, security,
and software development. He is
passionate about security through
automation (DevSecOps), operational
consistency, technology trends, best
practice, and cloud enablement.
Principal Infrastructure
Engineer, Information Security
GE Appliances, a Haier
Company
Twitter | LinkedIn | Website
I
n helping transition the organization’s IT strategy from cloud first to cloud only,
Kevin Price’s first security challenge was a cultural one. “The biggest challenge
out of the gate was that cloud had a bad name. People didn’t understand it,
so automatically if it’s not secure we can’t go there,” he says. But overcoming
that challenge led to another, which was finding a way to assure security in an
automated, DevOps environment where the old tools no longer worked. “We
worked in that traditional way where at the end of a project you run your security
components manually and provide the results,” Price explains. “We had a lot of
tools that didn’t enable us to automate. There was no way to trigger a security scan
automatically. There was no API access or interface. We really had to shift the tools
we were using in order to accomplish our goals.”
As the team began building its DevOps workflow, the process itself opened the
door to new and better ways to build security into applications. “The architecture
we put in place was designed around component-based solutions that bolted into
our continuous deployment process. So when we started to evaluate the security
requirements we needed, it was really straightforward to add in all the necessary
components automatically,” Price says.
We had a lot of tools that didn’t enable us to
automate. We really had to shift the tools we
were using in order to accomplish our goals.
10
SELECT SECURITY TOOLS THAT WORK IN AN AUTOMATED DEVOPS WORKFLOW
Sponsored by

We’ve seen application
teams take machine
learning algorithms and in
a matter of days provide
business value that would
have taken us months.
For Price, the DevOps workflow necessitates leveraging the
cloud infrastructure as code. He doesn’t want developers logging
into a console and manually creating cloud infrastructure. He
wants developers to take the time to code the infrastructure
through tools so they can automate the creation of stacks
across the business. “Once we started going with that strategy
and making sure that we had a good deployment process,
then we could start integrating our security solutions as part
of that process,” he says. “We evaluate our applications as
they run through the pipeline. This ensures all infrastructure
and application components are built to align with our security
standards and strategic architecture while providing complete
transparency to development teams.”
Price believes this approach can make apps stronger and
more secure if it is done the right way. “If you have smaller
applications, you have a better understanding of the code
running in them. But sometimes you see people developing these
small micro services, which is great, and then putting them in a
very large image that contains security vulnerabilities. Make sure
you have the smallest image possible,” he says.
11Sponsored by

Make sure you have the smallest images possible.
Avoid staging small microservices in a large container
image that may have vulnerabilities.
Create a mission statement around your DevSecOps
organization and security, and then pick the tools that
align with that mission statement.
1 2
KEY POINTS
12
One of the great benefits Price’s organization has seen from its cloud native strategy comes from the
speed at which it is able to develop and deploy new functionality. “We’ve seen application teams within our
business take machine learning algorithms and in a matter of days provide business value that would have
taken us months in previous years,” he says.
To build secure cloud native apps, Price recommends having a mission statement around your DevSecOps
organization and security, and then picking the tools that align with that mission statement. He also believes
the key is knowing how to code. “Take software engineering and development expertise, and make them
security experts as well,” he says.
Sponsored by

NUWAN BANDARA
Nuwan Bandara has more than
10 years of industry experience,
with particular expertise across the
e-government, finance, education,
and healthcare verticals. He also has
research and development experience
in several European Union software
research projects, which he gained
during his time at Cirquent GmbH/NTT
Data (Munich, Germany). Previously,
Bandara served in multiple roles in
the WSO2 engineering team, ranging
from software engineering, technical
leadership, product management, and
architecture.
Director, Solutions Architecture
WSO2
Twitter | LinkedIn | Website | Blog
N
uwan Bandara, director of solutions architecture at WSO2, notes that
when securing cloud native applications, one must think differently about
implementing security. “When you talk about cloud native security, it’s not
enough to only talk about applying security to cloud native infrastructure,” he says.
Cloud platforms already comes with built-in tools for securing the network and the
underline infrastructure. “They provide secure proxies, load balancers, firewalls and
VPC/CPNs. But what you have to really think about is application level security,”
says Bandara.
Ensuring application level security in a traditional deployment is not straightforward.
In a traditional environment this could mean multiple things; application server
security hardening, the JVM or the runtime hardening, application of security patches
for middleware, static code analysis for secure code; testing all these scenarios and
combinations take resources, VM spin ups and individual network configurations.
These activities delay releases impacting the business. But with cloud native
computing these activities have become checkpoints in a continuous integration
pipeline. Today you don’t have to wait for a patching window to apply a patch to a
deployment, the code analysis is automated with every deployment cycle and your
new secure application version can be deployed to a new container cluster with a
blue/green deployment strategy.
In a cloud native environment, as soon as you see
a security bulletin for the middleware or learn of an
exploit, you can apply the available patches then and
there, rather than waiting for the next patch window
and and testing your luck.
13
WHEN ARCHITECTING A CLOUD NATIVE APP, THINK ABOUT END-TO-END SECURITY
Sponsored by

The only thing you
can control is your
code. If you have solid
security architecture and
proactively test the code
with your security test
cases, that will give you
an edge.
For an enterprise, this ultimately means that they can be more
proactive. “You can keep your platform up to date with the latest
stable rather than waiting for next year for a major upgrade
investment. You can apply patches and update certificates in daily
rolling deployments in a more resilient manner,” Bandara says. He
also points out this makes you more adaptive to change. “You can
get faster feedback. You can test something very quickly and then
roll out those changes,” he notes.
When focusing on application layer security, Bandara says
the fundamentals of security do not change. “Of course you
should leverage the platform level security provided by many
cloud platforms like AWS, Google Cloud, Azure or the private
deployments based out of Kubernetes, Cloud Foundry etc. But
you have to always focus extra on end-to-end security.” He further
explains, “in a cloud environments there are many hops, there are
proxies, load balancers, api gateway and service meshes; with
platform level security what you get is point-to-point. But when
you are developing a cloud native application what you can really
control is only your application, your code.
14Sponsored by

In a cloud native environment, you can patch a
container image and then with the click of a button,
automatically test it and immediately spin up hundreds
of new instances.
KEY POINTS
15
So in that sense you should think about end-to-end security. This can mean if you need confidentiality, you
have to encrypt your messages until it reaches your application, if you need non-repudiation, you have to
validate message signatures. So sticking to basics of security really pays off.”
Building end-to-end security requires looking into the application or into the containerized microservice with
security in mind, and asking how data flowing through in the form of messages is being secured throughout
the process and the life cycle. “In a cloud native platform the only thing you can really control is your code.
If you have a solid security architecture and if you proactively test the code with your security test cases,
that will give you an edge in the cloud native world,” concludes Bandara.
Sponsored by
1 Building end-to-end security requires looking into the
containerized microservices with security in mind,
and asking how data is being secured throughout the
process and life cycle.
1 2

LEVI BLACKSTONE
Levi Blackstone is an engineer with a
passion for turning ideas into practical
solutions. His past projects have
included embedded systems, real-time
image processing, augmented reality,
sensor fusion, advanced malware
detection, and container platform
security. He is currently working to
bring Kubernetes to the enterprise on
Rackspace Private Cloud. Levi lives
in Sandy, Utah, with his wife and two
children, and enjoys skiing and hiking
in the Wasatch mountains.
Senior Software Engineer
Rackspace
Twitter | LinkedIn | Website
F
rom his perspective as a senior software engineer in the managed Kubernetes
service at Rackspace, Levi Blackstone sees a number of security advantages
in cloud native applications. One of the most important is the ability to
configure applications for much greater defense in depth. This is an advantage over
traditional applications that run many process together in the same virtual machine.
“With a cloud native setup, you have more granularity where you can potentially run
individual processes with their own sandbox,” Blackstone explains. “You can limit the
permissions of a particular piece of code. For example, you can isolate a database
so it runs by itself without any external facing networking code. Then you can have
front-end code running in a separate container and have a different set of security
policies there.”
Containers, which are fixed images that execute application services, provide an
immutable application infrastructure. Rather than having a long-running VM that
people log into and upgrade over time, you deploy a container image every time a
particular application service is needed. If you need to make a change, you update
the image and deploy a new container. “It’s easy to know exactly what the code
looks like at any given time,” says Blackstone.
With a cloud native setup, you have
more granularity where you can limit the
permissions of a particular piece of code.
16
A CLOUD NATIVE ENVIRONMENT ENABLES MORE GRANULAR DEFENSE IN DEPTH
Sponsored by

Just by looking at what
you have deployed, you
have the audit trail of all
the software running in
your environment. That
can be important from a
compliance perspective.
Knowing exactly what the code looks like changes how scanning
is done, which now becomes part of the CI/CD pipeline.
“Traditionally, you can scan processes that are running in a
VM, but it’s hard to tell what state the code is in,” Blackstone
explains. “With the immutable infrastructure, you can scan
the actual container image because you know exactly what is
installed there. You can tell just by looking at the image whether
or not there are known vulnerabilities. Then you can fix it and
in a matter of seconds tear down the old container and set up
a new one. There’s a lot more agility compared to services in
a long running VM.” In a cloud native environment, you can
make changes to containerized microservices without service
interruptions.
Blackstone also points out that containerized applications enable
more granular auditing. “You can have an audit trail of everything
that’s installed in the container. That’s baked into the image
itself, so just by looking at what you have deployed, you have the
audit trail of all the software running in your environment. That
can be important from a compliance perspective.”
17Sponsored by

If you need to make a change, you update the image
and deploy a new container. You can make changes to
containerized microservices without service interrup-
tions.
Moving to a cloud native approach requires new knowl-
edge about tools and workflows.1 2
KEY POINTS
18
Moving to a cloud native approach requires new knowledge about tools and workflows. “One of the biggest
challenges is knowing what security tools are available. If you know the tools and how to configure them,
you can set them up without much trouble. If you’re not familiar with the space, it’s going be a steeper
learning curve.”
Sponsored by

DAN BOWDEN
Dan Bowden is the CISO for Sentara
Healthcare, an integrated delivery
system and health plan—the largest
health system in Virginia. He has
been at Sentara since September
2016. He was previously CISO at
University of Utah Healthcare and
the University of Utah for more than
three years. Bowden has worked
in cybersecurity and technology
in healthcare, higher education,
banking, retail, and the military for
the past 25 years.
VP & CISO
Sentara Healthcare
Twitter | LinkedIn
E
very industry has its own IT challenges. For healthcare, one major challenge
comes from the fact that the many areas of healthcare—whether imaging,
lab, cardio, clinical functions, electronic medical records, and other
systems—have all grown up around their own sets of IT and security standards.
“This has made it difficult to manage the technology and difficult to manage
security,” says Dan Bowden, vice president and chief information security officer
(CISO) at Sentra Healthcare. Now, as his cloud team works to build a new, cloud
native patient-engagement platform, he sees a key benefit. “A really simple benefit
of cloud native security is a chance for a do-over, because now we get to redefine
our standards,” says Bowden.
From Bowden’s perspective, they are building a new platform using a common
set of modern tools for a modern ecosystem, allowing them to reset technology
standards. “Good technology standards always make it easier to apply better
security,” he says.
When I think about the security side of things,
I ask what can I bake into a template that can
be automated into that DevOps flow?
19
BAKE AS MUCH INTO THE DEVOPS PROCESS AS POSSIBLE
Sponsored by

To me, the most
important thing is
finding the smartest
people you can who’ve
already done it, and then
listening to them.
Part of this comes from the host cloud itself, but it also comes
from the containerized approach to application functions and
services, which enables more granular security controls at the
microservices level. It’s necessary to architect these controls
and specify everything in an application template so that DevOps
knows exactly what they have to build and how the DevOps
workflow will go. “When I think about the security side of things,
I ask what can I bake into a template that can be automated into
that DevOps flow?” he says. This includes looking at security
controls that come with the host environment, looking at what
additional services are needed, deciding what cloud native
tools and services to purchase, and what functions to build into
containers—even making decisions about the type and cadence
of testing.
“Ideally, you put as much as you can into the template. We also
talk about where there are process dependencies for security,”
Bowden says. “When you’re provisioning and de-provisioning
access to a data set, you need to know how that happens.”
20Sponsored by

One benefit of a cloud native project is the change it
gives you to redefine your technical and security stan-
dards.
Anyone entering into a cloud native project should
seek out people who have already done it.1 2
KEY POINTS
21
Because so much happens early in the process, teams that build cloud native apps are likely to be different
than traditional app development teams. “If you think about hardcore DevSecOps, defining what teams are
and what they do, and defining their skill makeup is completely different,” he explains. “The cloud team is a
lot of people who have a very diverse set of backgrounds.”
Bowden recommends that anyone entering into a cloud native project seek out people who have already
done it. “There aren’t a lot out there that have really done it,” he says. “I went on a serious hunting trip for
people who have. To me, the most important thing is finding the smartest people you can who’ve already
done it, and then listening to them.”
Sponsored by

DANIEL NEWSOME
Daniel Newsome has 23 years of
experience in enterprise technology
development. He is currently a senior
technical architect in the logistics and
telematics industry. He is a father, an
avid social dancer, runner, amateur
photographer, and foodie who lives in
the Pacific Northwest with his family.
Technical Architect
Zonar Systems
Blog | LinkedIn
D
aniel Newsome’s transition of key on-premises systems to fully cloud native
applications has involved moving one piece at a time. “One of our first steps
was moving our identity into the cloud as identity-as-a-service,” he says. “That
became the center of everything, allowing us to move pieces into the cloud and still
have them communicate with pieces running on our on-prem hardware. We didn’t
have to do everything all at once.”
Part of this involved putting APIs into containers and orchestrating everything
in a Kubernetes environment. “We were able to secure our APIs by building
security definitions right into the API specifications,” Newsome says. In making this
transition, Newsome’s team has discovered other security advantages. “With on-
prem hardware, essentially every port under a thousand is open,” he says. “The nice
thing about the container model is that containers only expose the ports that you
explicitly ask them to. It’s more like a whitelist than the blacklist philosophy we had
before.”
The nice thing about the container model is that
containers only expose the ports that you explicitly
ask them to. It’s more like a whitelist than a blacklist
philosophy.
22
WORK INCREMENTALLY, AND TAKE FULL ADVANTAGE OF CLOUD NATIVE TOOLS
Sponsored by

Don’t be afraid to dive in
and get started. I’d say
it’s important to start
quickly, and iterate.
Newsome sees other security advantages in the cloud
native approach. In addition to the fact that you can limit
exposure of code in the containers and that it’s easy
to change an image if you find a vulnerability, the host
environment also offers protection. “The host environment
has on-board security built into the platform, which is a
big step up from what we were running,” he says. “We
have assurances that containers meet certain tests and
standards for the latest OS images, and I know those are
patched. I don’t have hard numbers, but I think we’re way
better off than we were six months ago.”
In getting started, Newsome recommends an incremental
approach, but he also says not to be afraid. “One good
thing about the cloud is you can delete things and start
again. Don’t be afraid to dive in and get started. I’d say
it’s important to start quickly, and iterate.” He points out
that there’s a lot to learn, so you should take advantage of
cloud platform tools. “A lot of what used to be a DevOps
person’s job now becomes a programmer’s job, and
they’re using a CI/CD pipeline in setting up those things.
There’s a learning curve. I think the biggest mistake I
see people making is trying to move everything at once,
instead of just a little bit at a time,” he says.
23Sponsored by

Containers offer security by limiting exposure of code
and being easily changeable to fix vulnerabilities, but
the host environment also offers protections.
Transitioning to cloud native gives you an opportunity
to rethink your entire platform and eliminate bad prac-
tices.
1 2
KEY POINTS
24
Transitioning to cloud native has given Newsome’s team an opportunity to take a fresh look at everything
they do. “We’ve been able to rethink our entire platform and eliminate bad habits,” he says. “It’s been a
journey, but it’s ongoing. We keep iterating every single day, always learning new things so we can adjust
and get better.”
Sponsored by

ABOUT THIS BOOK
Organizations moving their software assets into the cloud are discovering that when it
comes to IT security, they have entered an alternate universe. It’s a place where security
objectives have not changed, but the way to achieve them is completely different. Is this
a safe place? How are people managing their cloud native security?
With the generous support of Twistlock, we decided to find out by asking seven cloud
native security experts the following question:
What are the biggest benefits you’ve seen in transitioning to cloud
native security, and what advice would you offer to peers who are
interested in leading the transition within their own organizations?
The real challenge is that cloud native security goes hand in hand with cloud native app
development. It is a work in progress with new technologies and approaches emerging
as fast as CICD pipelines can deliver them. Although there is a consensus that cloud
native applications provide an unprecedented opportunity to secure data and processes
at a granular level, deciding how best to apply that capability depends on many factors.
These essays contain insightful perspectives on the advantages of cloud native security,
as well as advice on where to begin. I’m sure anyone who is building or thinking about
building cloud native apps will be able to learn from what these experts have to say
about their own cloud native adventures.
© 2018 Mighty Guides, Inc. I 62 Nassau Drive I Great Neck, NY 11021 I 516-360-2622 I www.mightyguides.com
Mighty Guides make you stronger.
These authoritative and diverse
guides provide a full view of a topic.
They help you explore, compare, and
contrast a variety of viewpoints so
that you can determine what will work
best for you. Reading a Mighty Guide
is kind of like having your own team
of experts. Each heartfelt and sincere
piece of advice in this guide sits
right next to the contributor’s name,
biography, and links so that you can
learn more about their work. This
background information gives you
the proper context for each expert’s
independent perspective.
Credible advice from top experts
helps you make strong decisions.
Strong decisions make you mighty.
25
All the best,
David Rogelberg
Mighty Guides, Inc.
Publisher
Sponsored by
®

Cloud native cybersecurity
for the modern enterprise
Vulnerability Management
Precise controls to detect and
prevent vulnerabilities before
they reach production
Runtime Defense
Automated, scalable active
threat protection
Cloud Native Firewalls
Protect your network from
modern threats with layer 3
and layer 7 firewalls
CI Integration
Plugins and direct integration
for leading tools your dev teams
are already using
Compliance
Extend and enforce
compliance across your
container environment
Serverless Security
In-depth visibility to secure AWS
Lambda, Google Cloud Functions,
and Azure Functions
Learn more at Twistlock.com

Twistlock: 7 Experts on Cloud-Native Security

More Related Content

What's hot (20)

Similar to Twistlock: 7 Experts on Cloud-Native Security (20)

More from Mighty Guides, Inc. (20)

Recently uploaded (20)

Twistlock: 7 Experts on Cloud-Native Security