DevSecOps and Zero Trust Architecture (ZTA) 

For Multi-Cloud Environments 

Welcome to the second 

NIST-Tetrate Conference! 

By Varun Talwar 

Co-founder of Tetrate, 

Co-creator of gRPC and Istio projects 
 

 

 

90% of web-enabled applications will be more exposed to 

attack by API weaknesses than via the user interface. 

According to Gartner, by 2022, API abuses will be the 

most-frequent attack vector for enterprise web 

applications data breaches. 

| 

Source: https://www.zdnet.com/article/top-8-trends-shaping-digital-transformation-in-2021/ 
 More burden on DevSecOps != Developers 

| 
 

 

 

 

 

 

 

 

 

Eric Brewer, 

VP Infrastructure, Google 

at Service mesh day run by Tetrate: 

March 2019 

When developers 

are writing a 

service, they worry 

a lot about the API, 

what are the 

methods, how does 

it work? 

Dev 

| 
 

 

 

 

 

 

 

 

 

 

 

 

 

When developers 

are writing a 

service, they worry 

a lot about the API, 

what are the 

methods, how does 

it work? 

But when you’re deploying microservices, then 

you start need to think about other questions: 

What are the policies that are calling this service? 

Does it have a quota? 

Does it have a denial of service? 

How does it get authenticated? 

How is it secured? 

Deploy 

Dev 

| 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

When developers 

are writing a 

service, they worry 

a lot about the API, 

what are the 

methods, how does 

it work? 

But when you’re deploying microservices, then 

you start need to think about other questions: 

What are the policies that are calling this service? 

Does it have a quota? 

Does it have a denial of service? 

How does it get authenticated? 

How is it secured? 

All of these questions are not about what the API 

does, but are operations pieces. 

Deploy 

Dev 

| 
 

 

 

 

 

 

 

| 

Why should the 

devs be burdened 

with implementing 

security? 

Can the app runtime 

provide guarantee 

that a developer will 

never get security 

wrong? 

Can we make 

“secured by default” -

the norm? 

or be concerned with 

defining security 

policies? 
 

 

 

 

 

 

 

 

or be conc

defining secur

policies?

| 

Why should the 

devs be burdened 

with implementing 

security? 

Can the app runtime 

provide guarantee 

that a developer can 

never get security 

wrong? 

Can we make 

“secured by default” -

the norm? 

erned with 

ity 

Istio at its core 

decouples 

developers from 

operations 
Can the app runtime 

provide guarantee 

that a developer can 

never get security 

wrong? 

Can we make 

“secured by default” -

the norm? 

or be concerned with 

defining security 

policies? 

 

 

 

 

 

 

 

 

 

 

Why sho

devs be burde

with implementi

security?

uld the 

ned 

ng 

Istio at its core 

decouples 

developers from 

operations 

| 

A Policy Enforcement Point (PEP) 

separately deployable and controllable 

from the application — the service mesh’s 

sidecar proxies 

an authenticatable runtime 

identity for services 

the ability to authenticate 

application (user) credentials 

encryption in transit of 

communication between services 

And logs and metrics for 

monitoring policy enforcement 

NIST IR 8313 – Attribute-based Access 

Control for Microservices-based 

Applications using Service Mesh 

Enforce policies consistently across 

diverse protocols 

Authentication & Authorization 

Encryption of service 

communication at scale 

Service communications are 

secured by default 

Istio’s core security features 
Application level Security OR Zero Trust 

| 
Thank you for tuning in! 

Enjoy the conference 

|