[MUSIC PLAYING]
MATT BLUMBERG: My
name is Matt Blumberg.
I'm a product manager on
the cloud team focused
on API security, and
I'll be joined today
by Joel D'sa, who's a security
tech lead on the API security
team at Apigee as well.
And we're here to
talk about APIs
and how to design the
right architecture
to ensure that your data
and users' information
can remain secure.
So I'm going to start with an
overview of the power of APIs,
what impact it's
had on businesses
to date, a little bit
of the history there.
I'll explain why visibility
of your APIs is important
and what can happen if you
don't have that visibility.
And then Joel's going
to cover everything
from the most common
threats that we are seeing
in this space today, how
architecture needs to evolve
from how it was in the past to
how it currently is shifting
with microservices and
current future trends,
and best practices on
how to secure your APIs.
If you have the
Cloud Next app you
can submit some questions
there, and we're
happy to answer them at
the end if we have time.
It's a very tight
schedule today.
You also can step up to
the mic and ask questions,
so either works.
You can also come up to us
after the session, no problem.
So APIs are powering innovation.
And just to start with a little
bit of the history there,
APIs have been around
for about 20 years
and they were created
out of a need.
In the early 2000s,
APIs were first
used by companies
like Amazon and eBay,
who were noticing unofficial
usage of their services
and data.
These companies needed a
way to provide structure
to their developers, their
partners, and their customers
in a secure way
and scalable way.
And now, APIs are
everywhere and they're
a key enabler to
innovation because they're
facilitating new ways for
customers and partners
to interact with each other.
They're also enabling
new use cases
by connecting legacy
infrastructure to modern web
apps and mobile apps.
APIs can also enable use cases.
So there's voice
ordering from a phone
to connecting brick
and mortar companies,
moving them into an
e-commerce future,
and connecting
partners and services.
So an example here about--
I'll talk about
Walgreens for a minute.
They have thousands of locations
and they're leveraging-- just
to mention a couple
of their APIs--
they have a store locator API.
And Fitbit is actually using
that to enable Fitbit customers
to easily locate a
Walgreens location
and use Fitbit Pay to
actually pay in the stores.
So there's a couple of
different APIs being used there.
They also have a
photo printing API,
and this enables
third-party apps
to print to a Walgreens
location and pick up
photos in the store.
So this is driving customers
and traffic to a retail location
and enabling third-party
app developers
to have a rev share
model with Walgreens.
So it's a good win-win
situation there,
but driving more
customers to the stores.
If we take a look
at Magazine Luiza--
this is one of Brazil's
largest retailers--
they've been around
for more than 60 years.
They realize that it's not only
about physical brick and mortar
anymore.
They wanted to move into
the e-commerce space,
and APIs have enabled them to
scale to thousands of delivery
partners and increase
their product
catalog going from
50,000 products
to 1.5 million products.
So they had a 30x increase
in the number of products
by enabling 2,000 merchants to
support and sell their products
on their e-commerce platform.
As you can see here,
the financial impact
has been incredible.
So we're seeing trends from
customers and in many cases,
security is an afterthought.
It's how do we design the--
what are the problems
we want to solve,
what's the customer
requirements,
and how do we build that?
And security is one more
thing they need to deal with.
And in many cases, it's
an afterthought and that
puts user and data at risk.
So a lot of the data
that's exposed today,
we're talking payment
information, PII, PHI banking
information.
If you don't have the proper
visibility into what is exposed
and how it's exposed,
you're creating
a lot of risk and liability.
And this is why having a
full lifecycle API management
solution is really
needed to enable
the way-- a secure
way of enabling
the exposure of
this information.
So just to give a
high-level overview of what
Apigee's offering, Apigee is an
API management platform and it
offers--
breaks into three
components here.
From a developer/management
perspective,
we're providing a secure
way for developers
to scale their APIs
to a larger audience
and consume the information
in a managed way.
We're offering API
analytics, which
gives you clear
insights to measure,
tune, and monitor
your API program.
And I'll dive in a little bit
more about the API monitoring
in a few minutes.
And API services give
you complete control
by allowing you to manage the
connection between the API
consumer and the back end
infrastructure and service,
so you can have complete
control over the request
and the response.
So just to give an
example from Google Maps,
if you search for a
hotel for this week,
you can now choose dates that
you want to check into a room.
You see the availability
of that room,
and you can actually get live
pricing data in Google Maps
because this is being powered by
APIs from these third parties.
And this now allows
you to book directly
in the mobile app
or the web app,
or through thousands
of travel partners.
So Zen Hotels, Kayak,
all of these guys
have a relationship
with the St. Regis.
So this is just a quick
example of how powerful APIs
can be as opposed to the old
world of manually updating
pricing across different
sites, and when
something is sold
out, the time it
takes to remove those listings.
So this has been very powerful
in Google Maps and Search.
But discussing Walgreen's,
Magazine Luiza,
and Google Maps, these
are a few examples
where APIs have been
powering business innovation
and disruption in
different markets.
But in some cases, disruption
is not always a good thing.
And when security's
an afterthought,
sometimes enterprises don't
take the right precautions
before exposing their
APIs and services.
And in many cases,
it's simply a lack
of awareness of what's exposed,
what controls are in place,
and what is actually
happening with the data.
So just to talk a
minute about the USPS,
and there's no shortage
of these examples,
so I'm just going to
highlight this one.
They offer a new service
for their customers
called Informed
Visibility, and this
allows businesses and users
to gain the ability to track--
near real-time tracking
for mail campaigns.
So the issue they had really
breaks into two parts.
They misconfigured their API
and allowed wild card input.
Joel will talk a little bit
more about input validation,
but that was not the
right way to do it.
And they also had no visibility
into what data was exposed
or who's accessing that data.
So the configuration
that they deployed
allowed any user
to view or change
any other user's information,
such as the email address,
phone number, and other PII.
And this is far more harmful
than a single user's account
being compromised.
If someone hacks into a
single user's account,
they have all of their
data, and that's obviously
not a good thing.
But, in this case, 60
million users' data
was exposed for several months.
And this could have
been avoided if they
used proper [INAUDIBLE] scopes
and simply didn't allow access
to other users' data.
Or, as Joel will talk about
later, input validation,
where they simply should
not have allowed wild card
input to prevent multiple
records from being extracted.
And you won't always be able to
prevent every misconfiguration.
People are human.
But there are a lot of
processes and methods
you can take in an
approach to ensure
that these kinds of
things don't happen.
And again, Joel's going to talk
a little bit more about that.
But this is another
example of why
having visibility into
who's accessing your data
is extremely important.
So it's just
happening too often.
So there's an article
from "Dark Reading."
In the first nine
months of last year,
there were 3,600
reported breaches.
So this isn't just about
the postal service.
And the fourth-largest data
breach of the 21st century
was due to an API vulnerability.
Gartner's estimating by 2022--
so this is only a
couple of years out--
API abuse will be the
most frequent attack
vector resulting in data
breaches for enterprise web
applications.
So with thousands of
breaches last year--
and keep in mind, outside
of the EU, with GDPR,
they're actually required
to report these breaches.
But in most of the
rest of the world,
they're not actually required
to report these on their own.
So the number is likely an order
of magnitude higher than this.
So it really boils
down to the fact
that you can't secure
what you can't see.
So let's just take a quick poll.
Raise your hand.
How many people are using APIs
in their environment today?
OK, everybody.
So keep your hands up.
How many are using an
API management platform?
About half of those.
And how many feel like they
have the proper visibility
into their APIs?
Three, four, OK.
So we did a poll on
this a couple weeks ago
and an overwhelming majority
felt like they did not
have the proper visibility.
And having visibility
into what risk exists
and what has changed
is the first step.
And generally, how well your
service is performing and what
threats exist-- what
insider threats exists,
what anomalies are you
seeing in your traffic--
these are all critical aspects
to a successful API program.
And every API doesn't
face the same challenges,
but having that visibility into
rates of attacks, and latency
of responses, understanding how
your back end infrastructure's
architected to better educate
teams on how to respond
will put you in
a better position
if something does
happen in the future.
So Apigee is taking a
two-pronged approach
to visibility.
We're offering insights to meet
the needs of both operations
and security teams.
So today users are
expecting 100% availability.
We talk about five nines.
The expectation is 100%.
And Google research
from a couple of years
ago, more than 53% of users
will close a mobile app
or leave a web page if it
takes more than three seconds
to load, so the
bar is quite high.
And you need to be
able to identify issues
before your customers do.
And as you can see, Apigee
is offering clear insights
into where requests
are coming from,
what latency exists by region.
You can generate custom reports.
And it's always better
to be alerted of issues
before your customers alert you.
So you don't want to learn
about something saying,
hey, why did the app
installs drop this week,
or web traffic drop, or why is
support having more customer
escalations?
You want to be
notified before that.
And for many of our
customers, security issues
are initially detected
as operational issues.
So maybe a large spike in
traffic is a good thing.
Maybe tickets for an
event went on sale,
or it's a flash sale
or something like that.
But if it isn't, this is
likely of concern and something
you should know about.
Apigee gives you the
ability to take action
based on contextual alerts
before your customers are
impacted.
So by having access to this
data and leveraging Apigee fault
codes, you can easily
isolate problems and speed up
the diagnosis quickly.
So from an API security
reporting perspective,
Apigee has all of the data
that security admins need
across various parts
of our platform.
And we've been seeing
an increasing trend
of collaboration between
ops and security teams
working together to investigate
and track down issues.
So we wanted to make this
information easily accessible
with an at-a-glance
view, so you can quickly
know if there's something
to be concerned about.
And we announced
this on Tuesday,
but we are excited that we are
now offering the API security
reporting in both a
dashboard and an API,
so you can easily integrate with
existing [? Sim ?] tools that
you're using today-- existing
processes that you already have
in place--
or in the Apigee Edge console
as a security dashboard.
And this is going to
give you everything
from changes in traffic
day-to-day, week over week.
You can break this down
in different time periods,
get information about change
management and governance data,
certificate information,
policy configuration data
on a per-API, per-proxy
basis, information
about your policies.
So there is more
than 50 elements
that are going to be included
as part of this dashboard.
And this is now
available in Alpha
today, and will be
available more broadly
later this quarter.
So if we look back at
all the recent data
breaches I mentioned, if these
organizations had a clear view
into this data--
security and ops
data-- there would
be many red flags that
would have jumped out long
before an external
researcher discovered that.
So I'm going to hand things
off to Joel and he's going
to talk more about how API--
how the security of
your infrastructure
is mission critical
to your APIs.
Thank you.
JOEL D'SA: Thanks, Matt.
And thank you all for coming.
It's really early and this
is a wonderful conference.
I hope you're having fun.
So many great sessions and
we're really glad that you chose
to come and hang out with us.
We hope you'll find
this content useful.
Just by way of introduction,
my name is Joel D'sa.
I've been working for
the last 12-plus years
on enterprise security
problems, and APIs
are a key part of your
enterprises' IT infrastructure.
And I thought I'd spend
some time providing
a perspective of where
API security is today
and, perhaps, provide
some guidance for where
the future is headed.
Now, security is a
very broad field.
There are lots of
things to consider,
many things to think about.
And you could try to
wrestle with all of them
at the same time, but
it's pretty difficult.
So what we have
found is that if you
use data and analytics to
understand the threats that
are unique to your APIs
and to your environment,
this will give you
more control and you
will be in a better
position to tailor responses
to those threats.
And once you have all the
data and metrics laid out,
you will find that
APIs face threats
that are very similar to
typical software applications,
as well as web apps.
So you will find everything
from basic software issues.
Things like
authorization problems
that were faced by
Equifax and USPS,
or maybe something
like a random number
generator in your
environment that
is not really random, or perhaps
improper password storage.
This is something that
LinkedIn faced in the past,
and more recently, Facebook.
In addition, just like
traditional web applications,
APIs are also subject
to injection threats
like cross-site scripting,
SQL injection, remote code
execution, and a
whole host of others.
Then there are service
availability issues.
These are denial
of service issues.
These can be caused by malicious
actors or just some new release
of an app that's
spiking your traffic.
But it could cause a
service availability
problem for your APIs.
And then there's a growing
risk from insiders.
A ton of banks, technology
companies, payment gateways,
insurance providers have been
compromised by insider threats,
and so we'll talk a little
bit about them today.
And last, but not
least, spam and abuse.
Now, if you're following
social networks recently
and the security issues
that they're facing,
they're facing a ton
of spam and abuse,
and you will see the same
thing with APIs today.
And we'll cover some of that.
Now, the first thing
you want to get right
is your basic
software architecture.
And this is something
no one wants
to address because
it's difficult,
but it's actually very important
and key to your enterprise
security.
So things like good code, code
reviews, having good tests,
this will allow you to
reproduce security issues
in your environment,
fix them, and roll them
into production quickly.
Then we found security
reviews to be helpful.
Just having a review ensures
that security defects found
in one part of your API program
don't surface in another part
your API program.
And now a lot of
developers today--
unlike a few years earlier,
you just had Java and C Sharp.
Today, there's a whole host of
software development stacks.
You can do use Node and
Rails and Go and Rust.
And you should use
the tool that's
best suited for your
problem, but you
must go in with your eyes open.
Every stack has its own
unique security challenges,
its own third-party
vulnerability
management process, the
dependencies differ.
And so you must go in
with your eyes open.
Be prepared to address
the security threats
that your stack poses to you,
and be aware that they exist,
and be prepared to roll them
into production quickly.
Now, a lot of security defects
are found by well-meaning users
and customers of your APIs,
so have a place for them
to reach out to you, to send
you an email about the problem
they're seeing.
Build a process
to ensure that you
are able to triage these
issues, fix them, roll them
into production, and then get
back to the original person who
filed it so that they
can try it out again
and make sure that the
problem is truly fixed.
Also, engaging a
third-party penetration test
is actually very
useful, and that
will help you illuminate
any blind spots in your API
security posture.
And last, but not least, another
thing that developers hate
is a change management
process, ensuring
that you have clear visibility
into the changes happening
into your software
infrastructure.
Who's making them?
Why are they making them?
What is the real change?
And who approved it?
Is someone even
looking into this
or is this random
change just happening?
It's also really important.
All of us have to deal with
legacy software and tools,
and so what I've found useful--
and you can use that too--
is to draw a threat model,
something like the picture here.
You could use a
sophisticated tool to do this
or you could just
draw a simple block
diagram of your infrastructure,
lay out the different pieces,
and just draw out the
different dependencies.
And this will allow you to do
an analysis of what exactly
exists in your infrastructure.
Where are the real
vulnerabilities?
It allows you to
measure every component
on each of these parameters
and stack rank them
so you can get a handle on
this aspect of your security.
Now, all of this information--
or at least some parts of it--
will be available in
the security dashboard
that Matt talked about.
And so you can start from there
and continue to build this out.
One of the most
commonly overlooked,
but easy-to-implement
changes, is actually
just input validation.
Input validation is one of the
best defenses against injection
attacks, like SQL injection,
cross-site scripting,
remote code execution, and
it's very easy to build.
Now, APIs, unlike
traditional web applications,
have an open API specification
or a Swagger spec,
so there's well-defined
input and output.
So it's very easy to
identify all these inputs,
categorize them, and just
deploy uniform input validation.
Now, there are two
things to think about.
One is consistency and two is
the use of shared libraries.
I'll just talk about
them with an example.
Take a look at this hotel.
There are all these
rooms and all these rooms
have the same-looking door.
Now, suppose the
doors were different.
Some of them had
these push handles,
and other handles were
these rotating types,
and then there was
another handle that you
could open the door with.
And an attacker walked
in and they would
look at all these differences.
The first thing they would do
is go and try every single door
to try and find
any inconsistency
that they could break through.
So having a consistent
input validation and layer
in front of your APIs is
actually very powerful,
and we're seeing this
with our APIs as well.
Apigee hosts enterprise
APIs for a ton of customers,
and the customers that have
inconsistent input validation
or respond slightly differently
every single time actually get
scammed the most.
Now, one of the ways
to achieve consistency
is to deploy shared libraries.
So take a look at this example
in this specification here.
Name, tag, and status
are all strings.
So explore the
opportunity to see
if you can use the same regular
expression, and maybe even
the same length just
to achieve consistency.
Use a shared library.
If you use a shared library--
sometimes regular expressions
are hard to write.
If you fix it in one place, your
entire platform will benefit.
So it is something you
should at least check out.
Try it out.
And we've used it successfully.
API management
vendors like Apigee
provide a whole host of policies
that allow you to easily deploy
input validation.
Now, if someone is scanning your
API and these policies trip,
all that information will show
up on the security dashboard,
so you can get a
clear understanding
of who is attacking your API.
Working mobile apps and
well-meaning partners
don't trip your input
validation policy.
It's the rest of the people
trying to actually break in.
So you'll get a better
idea of what's going on.
Now, one of the most
common questions
that we get from
customers is, how do you
deal with service availability
issues or DDoS-type situations?
These are very easy to create.
APIs are out there.
The specification is known.
So anybody can try to
maybe cause a brownout.
It could also be caused by buggy
clients or maybe partners that
have misconfigured
their applications
and are causing
availability threats.
And the best way to defend
against API availability
issues and DDoS-type situations
is to actually scale out.
And the reason
that is the case is
that if your infrastructure
is able to successfully defend
against a
denial-of-service attack,
all the attacker needs to
do is ramp up the traffic,
so you need to scale out.
Now, this problem is
not new for Google.
Google has been defending
its infrastructure
for years against
denial-of-service attacks.
So there are a whole
host of tools that Google
offers that you can use.
If you use Google's
cloud load balancers,
these are the same load
balancers that protect Gmail.
They scale very
effectively and are
able to defend against layer
three and below type attacks.
In addition, you will
find that Google's network
is one seamless global network.
It scales to handle
all of Google's traffic
and can handle yours as well.
It is equipped with multiple
layers of load balancers
that are all
denial-of-service aware.
So if an incoming
denial-of-service attack
is sensed, these load
balancers can drop traffic
before it hits your back end.
And the goal of any successful
denial-of-service attack
is to actually
protect the back end.
Make sure that your
API back end does not
have to deal with any
junk or unwanted traffic.
Now, to deal with API-level
availability issues,
you can deploy some
policies from Apigee.
Apigee's API management provides
policies like API rate limits.
This will allow you to smooth
any spikes in your traffic.
In addition, if you deploy
Apigee's globally distributed
and encrypted caches, these
will help save your API back end
by serving up responses
to frequent requests.
And in addition, if you
use resource quotas,
this will allow you
to deploy quotas
on an app or client
or partner base.
And so you can, on a
resource-by-resource level,
defend your APIs
against too much use.
Now, the next thing
I wanted to point out
is that any of these
threats that face your APIs
will show up in your
security dashboard,
so you can get a
better understanding
of which APIs are subject
to such kinds of threats.
But one of the most
important things
that you could do to defend your
APIs against security threats
is actually to protect
the user of those APIs.
And sometimes, this
is a hard thing to do
and many people get it wrong.
And I was hoping to spend
some time on this topic,
starting with a history,
because the space has
undergone a series of changes.
I thought I'd take you through
a history of those changes,
give you a perspective of
where I was coming from,
and then provide some direction
for where the future is headed.
So let's start
from the mid-1990s.
Most websites, in the
beginning of the internet,
were really simple.
And even today, most
government websites
that just provide
information-- if any of you
filed your taxes recently
and went to the IRS website,
you'll find something like this.
It's a rather
monolithic website.
Most of the content is served
from a content management
system or a simple database,
and all of its infrastructure
and code is protected
using a network perimeter.
So it's very simple.
But as the internet
became more complicated
and websites started
getting more complex,
multiple websites were
deployed to the same container.
And data tiers were
deployed to these containers
that allowed these websites
to accept user input.
And the first user
input, obviously,
was user credentials.
Usernames and passwords
were exchanged for cookies.
And again, an
infrastructure like this
was protected using
a network perimeter.
Now, as these got
even more complicated,
reusable data components
started getting
deployed to the same container.
And in order for this
infrastructure to scale,
multiple ports of the
same kind of layout
were deployed on
a worldwide basis.
And there was a concept
of sticky sessions.
They're still available today.
Sticky sessions ensure
that once you authenticate
to a single part of
the infrastructure,
load balancers will make sure
that all subsequent traffic
from your browser will hit that
same port of infrastructure.
And then, those of you who
have worked on WebSphere
and WebLogic will recognize
this, where session EJBs were
deployed to application servers,
and that allowed the data tier
to scale independently
of the web tier.
Now, mobile apps and
stateless UIs using Ajax--
I don't know if
you remember that.
That is when things started
to shift a little bit.
So if you went to an airline
website in the mid-2000s
and they were rolling
out a mobile interface,
you would see this shift.
When you went to
book a flight, you
would see this wonderful,
fluid experience.
You would see all the
prices laid out dynamically
in a table.
You could select
the dates and you'd
book a flight and
everything was great.
And then you went to
check flight status
and that was another experience.
You'd try to hit Next,
and it was rather painful.
And this was the transition
everyone was making.
But one aspect was the
jarring customer experience.
What was even more jarring
was the authentication
and authorization
infrastructure deployed
to support such
a kind of an app.
So modern stateless UIs,
including mobile apps,
use API gateways, APIs,
tokens, whereas traditional web
applications continue
to use cookies.
And this difference is
what I wanted to call out.
Now, what you'll notice is
throughout this evolution,
the underlying security
model hadn't really changed.
All the data and logic required
to make security decisions
was constrained to that
same network perimeter.
In many cases, it never
even left the JVM.
And this is starting to shift.
This sort of an architecture
no longer makes sense.
There was a reliance on
that network perimeter,
and perimeters are good.
They give you peace of mind.
If you look at this castle
here, it looks great.
I would stay in a
castle like that.
You'd be very secure.
It gives you total
peace of mind.
It enforces consistency.
It limits the
damage of a breach.
If that castle was to blow
up, none of the town around it
would ever even feel it.
And it limits the
number of attacks
because it looks secure.
So there's nothing
wrong with this,
but there are a few things you
want to notice about this now.
50% of our customers are
moving to using microservices.
One thing you want to
notice about microservices
is that, in traditional
web applications,
the applications were deployed
to application servers.
But with microservices-- and
especially if you use something
like Spring Boot--
it's the server that's
deployed to the application.
So it's actually the
other way around.
So whereas, in an earlier
architecture, if you
used an application server,
the application server
handled authentication,
authorization, session
management, with microservices,
there is a need for consistency
because it is now the
role of each microservice
to take on that load.
And if you have thousands
of microservices
all deployed to
Kubernetes clusters
on a worldwide basis
to multiple clouds,
how do you even
draw a perimeter?
And this is a really
big challenge.
So what you want to do
is to use an API gateway
to limit the aperture
of what you are exposing
and pair it with an
identity management solution
to use identity to
manage the relationships
between internal service
producers and external service
consumers.
You might also choose to
deploy a service mesh that
will allow you to
compose applications
off your different
microservices.
And as I said earlier,
deploy an API gateway
to expose only what's required.
You also want to pair this
with a highly scalable, highly
secure identity
management solution.
Now, if you choose to use
Google's identity management
platform, this will
allow you to deploy
a standard consistent
authentication
and authorization layer.
It will use standards-based
frameworks like OAuth 2,
and it will also
prevent fraud and abuse
because this is the
same infrastructure that
defends Google.
The systems will
detect users that
are malicious, that
are trying to break in,
that are trying to do credential
stuffing by reusing passwords,
and will defend against
a whole host of attacks.
In addition-- and you should
notice the trend now--
the metrics generated
by this will tell you
who is attacking your
platform and what
are your users
actually trying to do.
Are they legitimate or not?
So this is something we
highly recommend everybody do.
Now, let me talk
about another remnant
of the old cookie-based design.
So it was a design
that looked like this.
A client would typically
take user credentials
and forward them
on to a service.
The service would
then forward them
on to an authentication server
to check if the user was valid.
It would then check with
an authorization server
to ensure that the user really
had the right level of access.
It's a very common design
pattern, nothing wrong with it.
But as these services
start to grow,
you will see increasing
load on the authentication
and authorization servers.
Even the slightest
latency at that layer
will present a huge
latency problem
for your entire infrastructure.
In addition, they're
single points of failure.
And one breach,
say, in service one,
will actually compromise
your entire infrastructure
because the system
does not allow
for time-bound,
delegated access to data.
So service one has access
to all the credentials.
If that is compromised
and that service is hosed,
the entire
infrastructure is gone.
So what we would recommend is
that everyone move to something
that looks like this.
It's very similar, but there
is more onus put on the client.
So your client will now
exchange credentials
for an OpenID Connect identity
token with an OpenID Connect
server.
So the OpenID Connect server
will authenticate the user,
then it will exchange
the identity token
for an access token.
And the access token, if you
use something like OAuth 2,
will give you time-bound,
delegated access only
to service one.
Now, if you use a JAR token--
JAR tokens are very
common nowadays,
but they're basically
just [INAUDIBLE]
encoded blobs of data that
are assigned by the server.
So all the service needs to
do is just open up the token
and validate the signature.
And now, in every request,
you have all the information
required, from a
security perspective,
to complete the request.
So the service does not have to
make any outbound calls to do
anything.
So JAR tokens will help
your service scale better.
OAuth 2 will give you a
consistent authentication
and authorization experience,
and will provide you
a framework to implement
time-bound, delegated access
to data that will
limit the breaches.
And then, from a traditional
architecture point of view,
this is what is
called Zero Trust.
Authenticate everyone,
every time, all the time.
So that's what you might
hear commonly as Zero Trust.
So it is a way forward
to implement a Zero Trust
architecture.
Now, one of the things
a lot of security folks
have to pay attention to
is the user experience
because that's where
everything will break.
So if you deploy this
wonderful security
and you mess up the
user experience,
that's where you'll
see a breach.
So this is an example.
We're working with
a retail customer.
So retailers have a
whole host of partners
that they work with
to be successful.
And in this particular case,
the partner reached out
to the API team and said, hey,
I want to access this API.
And the API team
was super excited,
and so they contacted
the security team
to get a key issued.
And now the security team does
not have any context on this,
so they're trying to figure
out the right scope of access.
So they tried to
create the right rules,
and they made the key,
and they hope it's right.
And now they have to
send the key over.
So they would encrypt
it using their PGP key,
and then send it to a manager
who would do the same thing.
And they would transfer that
to the app developer, who
would then use an
out-of-bound channel,
maybe call them up and
figure out what the key was.
And then, finally, it would
work until it was time
to change the scope of access.
And then the entire process
would have to be re-roled,
or they had to unload the
partner, revoke their access,
and then, again,
there was a mess.
So a lot of our
customers use what's
called a developer portal.
A developer border
gives API consumers
a self-service experience so
that they can go and check out
the APIs, understand what
is available for access
and what is not so that they
don't request the wrong access.
In this case,
Mercedes-Benz-- you
should check out their
developer portal.
They've done a fantastic job.
So the developer portal
explains all the APIs
that are available,
what they can do,
allows the developer
to try it out,
and then allows the user
to register for a key.
And you can then build
an approval workflow
on the back end that will
allow the right people to look
at the request, make
sure it's valid,
and have a key automated
securely delivered
to the API team.
Now, again, one more thing
you want to call out here
is that all the information
from this developer portal
will be made available in
the security dashboard.
And so you can get a better idea
of who is accessing your API.
Is it valid or invalid?
Is it malicious or not?
Is someone poking around
your developer portal
just for the fun of it?
Has that same user breached
another part of your website?
So it's actually a great
way to get awareness
into what's happening
with your API program.
Great.
Can I have a show of hands for
how many of you are concerned
about insider threats?
Wow.
We did the session
on Tuesday and this
is a much bigger audience and
a much better show of hands.
Insider threats are actually
a commonly overlooked problem,
but a huge problem for
a lot of enterprises.
There are a ton of
privileged users
that have access to lots of data
and maybe they shouldn't have.
If they do, maybe they
shouldn't use it unilaterally.
They should have someone
else provide some approval.
And they're an
increasing problem
for enterprise security.
Time-bound, delegated
access does not only
apply to API authentication.
It also applies
to your employees
and their contractors,
and anyone with access
to your API program.
So what you want to do
is-- the first thing
is integrate your API
management solution,
as well as your Google Cloud
Platform with your enterprise's
single sign on infrastructure.
And that's a great first start.
It allows you to
provide a consistent way
of looking at who is doing
what in your infrastructure.
What are they trying to do?
Are they doing
something malicious
or are they poking around
where they shouldn't be?
Things of that nature.
And then the same things
you use to protect your web
mail, like two-factor
authentication
or what have you-- risk-based
authentication-- you
can use the same way to
protect your API platform.
Now, the second
thing you want to do
is to deploy change management.
That is, to understand
who is making
what changes to your APIs.
What are the changes?
Why are they being made?
Is there some sort of a design?
Is there some sort
of an approval?
So there's some governance
and visibility into what's
happening to your API program.
And again, we hope to provide
some of this information
in the security dashboard.
It will give you a good view
of the changes happening
to your APIs so you
can get a better
idea-- when you integrate
it with your other tools,
you will get a holistic view
of the changes happening
to your infrastructure
and whether there
is some visibility into it.
And last, but not
least, I wanted
to talk about spam and abuse.
Now, again, we host a
ton of enterprise APIs.
Many of our retailers
are very, very concerned
about Black Friday.
And we see a lot
of spam and abuse,
especially on
high-traffic events.
And this is everything from
credential stuffing, people
just trying to brute force the
API, or just content scraping.
For a retailer, price
matching is a very big deal,
so you might just
want to content scrape
to figure out what's going on.
And so there are a whole
host of automated actors
who are trying to
break open the API.
There are automated bots
that are constantly scanning
these APIs for any changes.
And obviously, abuse and
bots and denial-of-service
are not new problems
to Google, and we
are bringing the best of Google
to help you deal with this.
So there are two broad solutions
to spam and abuse defense.
One is a prevention system
that you can deploy,
and the other is a
visibility system
that will allow you to get
better visibility into APIs.
So from a prevention
point of view,
your goal is to put
maximum onus on the client
to prove who they say they are.
One of the best ways,
again, is to authenticate
the users and the clients.
But we recognize
that a lot of APIs
today don't need to
be authenticated,
or maybe authentication
is too high of a barrier.
So what you can do is deploy
a system like reCAPTCHA.
ReCAPTCHA-- I don't
know if you've
noticed it on many websites.
It's a simple box
with a checkbox
and then it shows
up a challenge.
And the challenge then
slows down the user.
They have to actually
do something.
And so it slows down the
rate of spam and abuse
because automated bots
can't solve that challenge,
in many cases.
But last year, if you don't want
that kind of a disruptive user
experience-- pick out
a goat from this map--
you might want to
deploy version 3, which
was launched last year.
You should definitely
check it out.
Version 3 gives you
a reputation score,
and that will allow you to
make a ton of access decisions
based on their reputation score.
And yesterday, that
same team launched
what's called reCAPTCHA
Enterprise with a whole host
of enterprise-ready features.
And this, if you deploy, will
give you a much better idea
into spam and abuse and allow
you to take control of it.
Now, the second thing you
want to do is gain visibility.
Google has a product
called Cloud Armor.
If you deploy this in
front of your APIs,
you will get a better view
into the metadata surrounding
your API accesses.
What are the IP addresses?
Where are they coming from?
What locations?
Can they be blocked?
Do they have other histories?
So you'll get a better
idea of what is actually
hitting your API endpoints.
In addition, Apigee
has a product
called Apigee Sense that
does analytics on your APIs
that will allow you to tell
whether this is a credential
stuffing attack, someone
trying to brute force,
or content scrape,
and will classify
the different kinds of attacks.
You can get a better
idea of what's going on.
So we covered a lot
of content today.
I hope it was useful.
So I hope it is also
clear that using
a data and
metrics-driven approach
is actually mission critical
to improving your API security.
And in addition, with
the ever-expanding world
of microservices,
APIs, mobile apps,
your architecture really
needs to change in order
to improve your security and
keep your users and data safe.
Thank you very much.
[APPLAUSE]
[MUSIC PLAYING]
