June 16, 2025 • 40 mins
Cybersecurity vulnerabilities continue to emerge in unexpected places, as evidenced by the recent Iranian-backed attacks on U.S. water treatment facilities through poorly secured Unitronics PLCs. This alarming development sets the stage for our deep dive into API security - a critical yet often overlooked aspect of modern cybersecurity strategy.
APIs form the connective tissue of our digital world, enabling seamless communication between different software systems. However, this interconnectivity creates numerous potential entry points for attackers. From RESTful APIs with their statelessness to enterprise-focused SOAP protocols and the newer GraphQL systems, each implementation brings unique security challenges that must be addressed proactively.
We explore the most common API security threats facing organizations today: injection attacks that exploit poorly coded interfaces, broken authentication mechanisms that enable unauthorized access, sensitive data exposure through improper configurations, and man-in-the-middle attacks that intercept communications. Understanding these threats is just the beginning - implementing robust countermeasures is where real security happens.
Authentication and access controls form the foundation of API security. OAuth, OpenID Connect, and token-based authentication systems provide powerful protection when implemented correctly. However, token management practices - including secure storage, proper revocation procedures, and regular refreshing - are equally critical yet frequently overlooked components of a comprehensive security strategy.
API gateways emerge as perhaps the most valuable security control in your arsenal. Acting as centralized checkpoints, they provide enhanced visibility, consistent authentication enforcement, traffic throttling capabilities, and simplified management across numerous API connections. Cloud-based API gateways from major providers offer scalability and robust features that on-premises solutions struggle to match.
Beyond the technical controls, we discuss the human element of API security. The most secure implementations balance protection with functionality while fostering collaboration between security professionals and developers. As I emphasize throughout the episode, effective security isn't about forcing compliance - it's about building bridges of understanding between teams with different expertise.
Ready to strengthen your API security posture or prepare for your CISSP exam? Visit cisspcybertraining.com for free questions, comprehensive courseware, and a proven blueprint for certification success.
Gain exclusive access to 360 FREE CISSP Practice Questions delivered directly to your inbox! Sign up at FreeCISSPQuestions.com and receive 30 expertly crafted practice questions every 15 days for the next 6 months—completely free! Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success. Join now and start your journey toward CISSP mastery today!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Welcome to the CISSP Cyber Training Podcast, where we
provide you the training andtools you need to pass the CISSP
exam the first time.
Hi, my name is Sean Gerber andI'm your host for this
action-packed, informativepodcast.
Join me each week as I providethe information you need to pass
the CISSP exam and grow yourcybersecurity knowledge.
(00:20):
All right, let's get started.
Let's go.
Cybersecurity knowledge Allright, let's get started.
Hey, all, it's Sean Gerber withCISSP Cyber Training, and I
hope you all are having ablessed day, this beautiful day
here.
I mean things here in Kansasare doing very, very well.
We're pretty excited about theweather.
The weather's been absolutelyamazing and now we have
(00:42):
Christmas, holidays are shortlycoming and my new grand little
granddaughter's heading intotown, so we're excited about
that.
It's very fun to have her hereand the the energy that comes
with a little two and a halfthree year old.
So we are pretty fired up aboutthat piece, uh.
But we're more fired up aboutgetting into.
(01:02):
What you guys are listening foris the CISSP training and we're
going to be getting into as itrelates to API security today.
Today, as you all know, is aMonday, and Monday the training
comes out for the specific topicand then on Thursday you get a
CISSP questions that aretypically not all the time but
(01:23):
in many cases are associatedwith the overall training that
occurs on Monday.
But before we do one thing, Iwanted to bring up a little bit
of news article that I saw today.
Well, actually, I saw it acouple of weeks ago, and that
was as relates to the.
Some various hackers have beenhacking the industrial control
systems at United States waterfacilities.
They have brought this up.
(01:44):
There was an authority ofEquipa, equipa Pennsylvania, and
they had been hacked recently,and this is the second time that
I've seen something.
Well, actually, it's probablylike the third where there have
been attackers that have goneafter water treatment facilities
.
Now, this treatment facilityserves about 6,600 customers, so
it's about the size of the townI live in and they, as you and
(02:07):
my friends that are in India,there are laughing 6,600 people.
They don't even have that.
They have that on a block inIndia.
But, that being set aside,there's about 6,000 people and
there were some folks thatactually hacked into this water
treatment facility and theybelieve they were Iranian-based
activists that were going afterthat facility.
As a result, there was a plcthat's tied to it called
(02:30):
unitronics.
It's unitronics.
This system was one thatallowed them the foothold into
that environment, and sisa cameout with a article that is
around the exploitation of thisUnitronics PLCs and their
recommendations on how to fixthem.
So if you're listening to thisand if you're in the United
(02:53):
States, it really doesn't matterwhere you're at.
If they're having a watertreatment facility that deals
with your Unitronics PLCs, youmay want to get with them and
ask them about how to upgradethose systems.
I've talked to my local townand I'm in the process of
talking to a couple little townsthat are outside of where I
(03:13):
live, just to make sure thatthey have the same understanding
around the hack that's there.
I think it's important that you, as cybersecurity professionals
, do everything in your power tohelp individuals within your
community to understand thesecurity risks that they might
be incurring within theircommunity.
So it's an interesting read.
(03:35):
There are one that's on CISA,has it?
That's the CISAgov and it's theUnitronics.
It's U-N-I-T-R-O-N-I-C-S.
I know that's like the alphabet, but you can Google it.
Unitronics PLCs with water andwastewater systems.
Yeah, check it out, because oneof the things that's come out
of it is there's the.
(03:56):
I guess I'm looking at thearticle from CISA there's the
password is 111.
I mean, these people are justfools.
I'm sorry, but when yourmanufacturers make these things,
I cannot believe they allowthis to continue, require
multi-factor, and then theyobviously want you to disconnect
the PLC from the open internet.
Bottom line is you want to havea segregated network when
(04:18):
you're dealing with anything inthe manufacturing or, in this
case, safety.
You really want to avoid havingit on a business network and
then to have passwords that arebasically four ones.
It's just foolishness.
So I highly recommend that youtalk to people in your local
community about how you can beof assistance to help them.
We need you out there doingthat.
(04:39):
Okay, so now we're going to rollinto understanding API
securities and what are somethings you need to be aware of
as a security professional.
Now I'm going to go into thiswith a disclaimer.
Obviously, that's usually whensomeone comes up with a
disclaimer says they don't knowanything, and that's probably
true.
I know enough in API securityto be dangerous and enough to
teach you and help you pass theCISSP course.
(05:01):
But I am not a developer and Iwould highly recommend if you
really like APIs, then you get alittle bit smarter on it and
teach the hive, the collective,because the bottom line is that
this is an area that iscontinually growing.
I was just on a phone callyesterday dealing with API
security and it was interestingbecause it was coming out of a
(05:23):
large company that was sendingdata using SFTP, which isn't bad
, but we were able to get themon an API connection through an
API gateway and that was a greatoption to help them.
And a lot of that comes down towhat knowledge I have around
APIs is very useful, but whenyou get into the specifics,
that's where you really want toget in a developer to help you
(05:44):
understand the overall API as awhole, and your goal as a CISSP
is to basically be the one thatcan communicate with other
individuals around differentsecurity topics.
You do not have to be theexpert on everything.
You have to understand itenough that you can converse and
then find the right answer.
But in reality, there's so muchinformation nobody can be an
(06:06):
expert on everything.
So when you're dealing withAPIs, you want to allow.
These are basically allowingdifferent secure or different
software programs to communicateand protocols to communicate
with each other.
So, like a way to think of itis as a framework.
So if you have a, you have onepiece of software wants to talk
to another piece of software.
In the past you had to haveboth languages talk to each
(06:30):
other using the same language oryou had to have a program in
the middle that would thenbasically convert one language
into another language.
But what api's are?
They're like a standard,they're like a framework that if
you follow this framework andyou follow the standard, then it
will communicate between oneprogram and another program and
it allows you to have seamlessconnectivity with them.
So you know, if you're a web,if you're a developer and you
(06:52):
create a program with an output,if your output meets the level
of what this framework for, thisAPI, and then you're another
developer of another programthat takes an input, and you
allow, build your anotherprogram that takes an input and
you build your other programthat is taking that input, based
on the standard, then the datacoming from one program to
another program can work welland it allows this communication
(07:16):
path between the two and itworks amazingly well into the
fact that almost everything outthere in today's world is using
APIs.
Now I will tell you that the onething that concerns me as a
security professional is the useof APIs.
Why?
Because there's so many of them.
In the past, we knew the exitsand entrances into a network.
(07:36):
Once you start connecting abunch of APIs together, that
visibility can go away and youdon't have the same level of
understanding of network of dataleaving and coming into and
leaving your network as you usedto have.
So what are some types of APIsthat you're going to deal with
and I'm just going to go into acouple that you will be aware of
that you may see on your CISSPexam.
(07:57):
One is REST.
Now that's the representationalstate transfer.
Now this is the most commontype of an API and it really is
known because it's simplicityand it's statefulness, which
basically means it's alwayslistening.
It's a.
It's a very I need.
My developers used to use therest API all the time and it's
(08:17):
just basically listening all thetime so that information can
come and go.
It's typically used within HTTPand HTTPS protocols and you
will see a lot of people talkabout REST APIs.
Now you have SOAP.
Now SOAP is a simple objectaccess protocol and this is a
protocol based on APIs known forits high security and
(08:38):
extensibility, which basicallymeans it can really be used in
many different ways.
It is typically used within anenterprise solutions and I will
say I've seen it in enterprise.
But I also see a lot of RESTAPIs set up within the
enterprises as well, but SOAP isprobably one that's more common
within a large organization.
You have GraphQL, which is inlike QuickLima, I guess what you
(09:02):
would call it.
This is a newer type of APIthat allows clients to request
only the data they need.
Now, that is a nice aspect tothe API.
In many cases, the APIs are setup just to kind of work as a
fire hose and they just shoveldata to and from.
If you can have it set up whereit's only taking the
information that is necessaryand needed, that is a great way
(09:24):
in reducing the overall datatransfer.
It also helps with bandwidthand, in my case of security.
I like that because I don'twant it to have all kinds of
information sent, because whatI've learned is developers will
send data that they don'tnecessarily always need to have
sent.
They'll just turn it on and letthe fire hose go.
So you need to consider each ofthese different APIs and how do
(09:47):
you want to secure them,because they each have different
kinds of ways of doing so.
Now, there's some common APIsecurity threats that you need
to understand, one, and we'llget into just a few of these,
but there's really four mainones to kind of consider
Injection attacks, brokenauthentication, sensitive data
exposure and thenman-in-the-middle attacks.
(10:07):
Now, your injection attack istypically what we've always
dealt with is.
An injection attack is wheremalicious code is injected into
the API right and that by doingso, you could potentially have
that code run as it's based onwhat the API is just going to
run that actual code itself.
The other one is brokenauthentication.
(10:27):
This occurs when theauthentication mechanisms that
you're set up for your API arebroken.
They're not allowed, but yetthe process is still allowed to
work.
This is where you can get intopotential accidental exposure of
data which could be sensitivein nature.
And then that comes intoanother.
Sensitive data exposure is whenyou do have this through APIs
(10:51):
is that now you have tounderstand what occurred and
then you have to have the levelof exposure data that was
exposed and how are theprotection measures that you
want to implement within them.
And then, lastly, we're going todeal with man-in-the-middle
attacks.
This is where the attackerintercepts the communication
path between the client and theAPI server and they're able to
listen to the information thatgoes in.
(11:11):
Now think of it another way iswe have to deal with secure
communication protocols.
One of the big things that wedeal with is as it relates to
IPsec tunnels, and when you havean IPsec tunnel, it's an
encrypted tunnel.
Well, these API connections,these are not encrypted unless
you incorporate additionalsecurity layers within these
(11:33):
APIs to be able to do that.
So just kind of keep in mindthat it's just a better way of
doing an IPsec tunnel betweentwo locations.
So when you're dealing withsecure APIs, one of the
considerations you need to thinkabout is how do you ensure that
you have robust authenticationenabled?
So you have to have some levelof strong authentication to have
(11:54):
all of these work in a way thatis beneficial for you and for
your company.
And if you don't understand theAPI connections and how they're
authenticated, it's animportant factor for you to kind
of delve deeper into it.
So it's the first thing youshould see when you're dealing
with APIs is how do I understandthe authentication behind it?
And then how am I ensuring thatit is properly protected?
(12:15):
Now, using OAuth or OpenIDConnect?
You need to understand that isa widely adopted standard when
you're dealing with OAuth, andit does.
It provides a secure, delegatedaccess that do allow the
applications to act on behalf ofa specific user, whereas OpenID
Connect is an authenticationlayer on top of OAuth 2.0, which
(12:36):
adds the identity.
So a key thing to remember whenyou're dealing with test
questions also is OAuth providesyou the authorization to have
this occur, which adds theidentity.
So a key thing to remember whenyou're dealing with test
questions also is OAuth providesyou the authorization to have
this occur, whereas the OpenIDprovides the authentication
layer on top of OAuth 2.0.
And we've talked about this ina couple other podcasts, but you
need to keep that in mind is,again, those are some key
(12:56):
differences to understandbetween them.
Now, token-based authenticationthis is used to access tokens
for maintaining a session state.
So these, basically, if youwant to keep your state enabled,
such as an IPsec tunnel, wherethe tunnel is up and operational
, that session is there andavailable for you, and so this
token-based authentication canbe set up to allow that to
(13:19):
happen.
It allows for more scalability,allows you to broaden that out
and flexibility, and it does addfor a level of security to
ensure that that session isstill up and operational.
Now, when we're dealing withaccess controls we've talked
about these in the past is rolebased access.
Attribute based access are twokey factors when you're dealing
(13:39):
with APIs.
Now, role-based access this isyou understand is based on the
individuals, based on your role.
It could be within a user,could be within a manager.
It's just based on specificallywhat your role is within that
organization, and that would bethe setup for the API.
When you're dealing withattributes-based controls, this
(14:00):
is where dynamic access is setup.
Basically, that evaluates theattributes of the overall
position or overall connection,and this would be the user, the
resources, their environment.
This is much more flexible andcontext-aware than the
role-based access controls.
(14:23):
Role-based access controls Now,because it is much more ability
for you to be able to manage ita little bit better.
The interesting part, though,is it does take a lot more, I'd
say, management of it, and I'veused management a couple of
times in that sentence, but youhave to.
I'm trying to use a goodexample of.
In the role-based access, I canclick it on and say Sean's got
access, but when you're dealingwith attributes, then I'm
specifically picking out whatattribute does Sean have access
(14:44):
to, which can add to thecomplexity, which, in turn,
because it's more complex, willcause issues with if you're
trying to troubleshoot and findout why your access isn't
working.
If you get into attribute-basedaccess, you run in the risk of
making it so granular that youend up breaking things, and then
people get frustrated and so,rather than doing the granular
(15:07):
security controls in which theywant to do, they'll just open it
all up just so that everybodyhas access to it.
So that's where, when you getinto role-based access, it can
cause you some challenges.
So another thing to consider istoken management.
Now, when you're going to dealwith each of these API
connections, they have a tokenand you want to have this token.
Just think of it as a way.
Is your security mechanism foryour overall API connection?
(15:30):
Now, when you're dealing withthese tokens, transmitting them
and storing them is a veryimportant factor in your overall
protection of your APIconnection.
And so what you'll do is isthat I've seen it where people
have automatically built it,where the token, more or less
the password, is built into theAPI connection.
And that's a bad idea, right?
(15:51):
Because now you have thisstatic password, the static
authentication mechanism that issitting inside your API
connection.
So it's real easy for it atsome point to be compromised and
now someone could connect intoyour environment with that API
connection, with that token, andyou would not know that it's a
bad girl or bad guy doing that.
(16:12):
So it's important that you havea good way to securely store
those tokens and that they'reonly fetched when actually
needed.
You also need to have some sortof revocation around these
tokens to ensure that when theydo password rotations, you will
then expire these tokens andthen reissue new ones.
If you don't have a way tomanage those, then, like I said
(16:34):
before, the token will neverexpire, and if the token never
expires, the password basicallynever expires, and so then you
get into a situation where, ifI'm a bad guy or gal, I take
advantage of that token and nowI can have unfettered access
into your environment.
So it's important that you havea plan on how to one store them
(16:54):
, two, revocate them, and thenthe third thing is is refresh
them and get you new ones.
Basically, do a password reseton those, because they do have.
You want to limit the lifespanof these tokens so that they're
not available indefinitely.
So api key security you want tounderstand that the fact,
similar to the tokens, you wantto have a way in which they're
(17:15):
properly protected.
Now api keys can be embeddedwithin the api just simpler as
similar as a token, and thisobviously makes it in a
situation where it's much lesssecure than if you actually
would have them in a repositorywhere they're fetched when
needed.
So you need to make sure thatyou understand how do you store
your API keys.
This also can get verychallenging when you're dealing
(17:37):
with microservices and there'ssome challenges that get into
the microservices architecturewhere you're dealing with the
storage of these keys as well.
So you want to always belooking for as you're monitoring
how your APIs are being used.
One question that I've seen isI've seen where folks have,
especially GitLab or those typesof code repositories where
(17:59):
there's an API keys that arestored in the code repositories.
So someone may have an API thatthey've created and they store
it out there in a repository.
Inside it they have left thekey or maybe a token
authentication token that is setup with inside that API key or
API that they created and it'sjust sitting out there in that
(18:19):
repository.
Well, it's sitting out therejust waiting for somebody to
come along and grab it.
So it's important that you aremonitoring both the API and your
code repositories and librariesto ensure that there aren't
those secrets stored out there.
Now I know I think GitLab hasgot a new product out that you
will actually go out and scanyour code repositories looking
(18:41):
for secrets, and it's a greatthing to do and be able to use
if it's possible.
So I know that they're lookingat new items for APIs and some
new trends that are kind ofcoming into that whole space.
One is biometric authentication.
They're using that in relationto facial recognition and
fingerprints as it relates toAPIs, especially in very
sensitive locations.
(19:02):
I think the only time you wouldhave that is if you were
pulling information from aserver.
This probably isn't the onlytime.
I'm sure there's other placesyou would use this, but you're
pulling information from aserver.
You want access to theinformation.
Then you have to do a fingerscan to be able to get access to
that information.
That would be one potential usecase.
They also have decentralizedidentity models.
(19:24):
This is where they're usingblockchain and other types of
technology out there to helpwith API authentication.
And again, it's a differentkind of look at things
Blockchain.
Obviously you'll know of thatas it relates to the Bitcoin
kind of world, but blockchaindoes have provide a lot of great
methods inside of it forallowing you to be able to use,
(19:46):
especially in authenticationpieces.
That is unique and different,and I think it's pretty amazing
how the blockchain piece canwork.
We've used it.
I've used it and seen it usedin various areas within
companies that I've dealt with,and it's been very positive.
The downside of it is it can bevery clunky and kludgy to work
with, especially since it's allbrand new and it's kind of like
(20:09):
a technology trying to find aplace to work, a place to home,
and it's a bit of a challenge.
But there is possibilities thatit could be used within your
environment if you really likethat and you want to give that a
shot.
Another option is machinelearning in authentication.
This is where machine learningalgorithms are being integrated
into the authentication processto help detect if there's any
(20:30):
anomalies that are occurring.
I haven't seen this myself, butI've heard rumblings of it.
It would be interesting to seehow it plays out, but it's
pretty cool if it can happen.
So now we're going to get intowhat we call an API gateway and
what understanding what theprocess is around a gateway.
So this API gateway isbasically a management tool that
sits between the client and thecollection of back end services
(20:53):
.
So, as an example, just thinkof it as a entry point into your
environment.
So if you have APIs, so you caneither have an API that
connects directly from theclient to your server and you
now have, let's say, a thousanddifferent people and a thousand
people set up API connections,and so now you have a thousand
different connections into yourenvironment.
That's really hard to manage.
(21:14):
Honestly, it's darn nearimpossible.
So, rather than having that,what you would do is you'd have
your employees or whoever'ssetting up these API connections
, send them to what they call anAPI gateway, and this gateway
acts as an intermediary, and nowall the information goes
through the gateway, from onelocation to the gateway and then
to another location.
(21:34):
So it's just right.
That's that stopping off point.
The great point about a gatewayis it allows you to do a lot of
different things.
One it gives you visibilityinto what is actually occurring
within your environment.
How many api's do you haveconnected?
Second thing is it also allowsyou to ensure that you have
authentication that is enabled,so that you can't just have
(21:55):
anybody set up an API connectionand they connect into your
environment.
So it's an important factor tojust force people down through
this and, being a farm boy, thischute where you'd send the cows
and the pigs, you'd push themthrough a center place is that
you would run them through thischute, and that's the same thing
that the API is that you'repushing people through this API
(22:18):
or through this gateway toensure that they come into your
environment in a way that is upto your security expectations.
The other thing that you can dois you can also throttle the
connections that are coming in.
So, like anything, if you havea connection coming into your
environment, it takes bandwidth.
Well, if it goes through agateway, you can control the
amount of data that's coming inand coming out, how fast it's
(22:39):
coming in, and it allows you togive you some level.
I'm not going to go down thepath of saying it provides DDoS
protection not DDoS, but DDoSprotection, denial of service
protection but it can give youthe ability to reduce that input
.
So if there is a lot of datacoming in from your API
connections, you can throttlethat in a more or less rate
(23:01):
limited.
So there's a lot of benefitsaround that.
Specifically, it also doessimplify the API management,
where you're not having tomanage a thousand different
connections and it can be veryproblematic.
Now, one thing I want to warnyou is that if you have a cloud
infrastructure in place, onething is if those cloud servers
(23:23):
are exposed to the internet,anybody can set up an API
connection, in most cases, tothose servers.
So you're going to want toreally watch from a security
perspective.
How is the cloud connectingyour cloud infrastructure?
How are you allowing it accessto the internet?
If you're allowing itunfettered access, then you may
have a bigger problem that youdon't even know about and that
(23:43):
it might not be more than justthe APIs.
But if you're allowing APIconnections and individuals to
set up those connections tothese systems, you may have a
serious problem.
So definitely keep an eye onwhat is your overall policy
around allowing people to useAPIs within your environment.
So, when we're going to dealwith rate limiting one thing
around it, we talked about theaspects of the denial of service
(24:06):
attacks and that this will helpwith that.
Now, to be honest, one of thethings I've seen I've seen API
security folks talk about.
Well, it will protect youagainst denial of service
attacks, and it may.
I mean, I'm not the expert andthere's other people that are
the experts in their specifictools.
The thing with denial ofservice attacks is you have to
(24:27):
have a way to dump the traffic.
Now, if it's only limiting thetraffic, the traffic that's
coming in, and it's onlyrestricting it, it may not
totally be stopping a denial ofservice attack.
It may be stopping it insideyour network, but at the gateway
you're still getting denied theservice because there's just so
much data that's coming in.
You have to have a way to shuntit or send the data to a place
(24:49):
where it's basically droppedinto a bucket that's never seen
again.
If it has that ability to dothat, then you would have some
level of denial of serviceprotection against it.
So when you're looking atevaluating API gateways, that's
something to consider.
The other thing around ratelimiting that can happen is is
it what it does?
Is it allows the differentrequests per second or per
(25:11):
minute that are happening and itlimits those to specific users
or specific IP addresses?
So it will help that, inregards to what's coming in, to
mitigate it or to shunt it.
Again, if you're looking at agood product out there to help
you.
You want to make sure that itdoes exactly as it says, because
a lot of people say a lot ofthings but the technology may
(25:32):
not actually do what you'reasking for.
And what you could do even isset it up so that they can
demonstrate to you how thatdenial of service would
potentially occur and then howtheir product would mitigate it.
Another thing you're dealingwith when you're talking about
gateways is there's IPwhitelisting and IP blacklisting
.
So basically it comes down tois if there's an IP address that
(25:54):
you want to allow no matterwhat to in your environment, you
would put an IP whitelistwithin your API gateway.
And the same goes for ifthere's an IP address that you
do not want any access to cominginto your environment, you
would put a blacklist in place.
Now the blacklist can get veryproblematic just because of the
fact that you are specifying aspecific IP address that you are
(26:17):
not gonna allow to communicate.
Well, as we all know, ipaddresses can change.
The other thing is that whenyou're coming in from different
locations, if the IP addresschanges and you're trying to,
you can't figure out why theconnection is not occurring.
It could be because of the factthat that IP was actually
blacklisted.
So most people will say don'tblacklist unless you absolutely
(26:40):
have to.
Now whitelisting, on the otherhand, can get out of hand,
because let's just say, forexample, I'm going to use the
URL, but let's just go googlecom.
Right?
So googlecom has its IP addressof xxx, whatever that number is
and you go I'm going towhitelist googlecom.
Well, you whitelist it and it'sallowed into your environment.
(27:01):
Google's probably not the rightword.
Let's go sneakerstorecom.
You allow this sneaker storeinto your environment, but then
all of a sudden, the sneakerstore is you know, wouldn't pay
as much attention to it, and itgets hacked.
Well, you've whitelisted thesneaker store and the sneak that
individual is now has accessdirectly into your environment,
(27:22):
that company, because youwhitelisted them and you don't
even know that you did thatbecause it happened like three
years ago.
So IP whitelisting is a usefultool, but you need to manage it
on a yearly basis and go throughand make sure that these IP
addresses that you had beforeare the same IP addresses that
you still want to continue goingforward with.
(27:43):
So again, it's really importantto do that Now.
The blacklisting works well whenyou're trying to deal with
malicious sites, but we all knowthose IP addresses do change
and unless you're really gettinginto a lot of challenges around
that, where that site is justconstantly hitting you, then
you're going to want to.
You can blacklist it, but mostpeople use the blacklisting with
(28:05):
a little bit of caution.
They just don't do it a lot, atleast from my experience.
Now that may be in other placesthat may not be the case.
They may use it a lot.
So one thing that happens a lotwith APIs is the use in the
microservices architecture,which is your cloud architecture
, and using the cloud-based APIgateways is a really good way
for you to be able to funnel allthis traffic in through an AWS
(28:27):
or Azure or Google Cloudplatform.
We've seen them.
They're able to scale.
You can put them on loadbalancers so they can spread out
the load.
So they're a really good way ofdoing that, and I would highly
recommend, if you're going tohave APIs, that would be a way
to go about and and push theminto an actual cloud platform.
You can have an on-premenvironment where but yet you
(28:50):
have an api cloud or an apigateway in the cloud so all of
your apis can go out to thatgateway.
They then can be shunted backinto or sent back into your
environment through thatspecific gateway.
They work really really welland they're just.
That's all I've ever seen.
I'm sure you can do it in anon-prem version of that, but all
(29:13):
I've ever dealt with arecloud-based API gateways.
Now they do have analytics thatwill help you with usage, that
will help you performance andalso any security incidents that
occur.
This comes down to logging andmonitoring as well.
I've kind of mentioned itbefore.
I would highly recommend thatyou turn on some level of
logging and monitoring withinyour API environment.
(29:33):
You need to decide how muchlogs you want to keep, just like
everything else.
The more logs you keep, themore you have to filter through.
But with an API connectionbeing that it's coming from the
outside, being the fact thatthere's thousands of them and
you really don't have a goodgrasp of sometimes what are all
those connections, logging andmonitoring on your gateway is
(29:53):
really an important part, andthen ensuring that you have
proper protections around thoselogs that they're not tampered
with in the event something badwould happen.
Now there's various machinelearning, or I should say
machine learning capabilitiesare out of artificial
intelligence capabilities thatare being utilized within API
gateways to help mitigate someof the security risks that are
(30:15):
associated with them.
I haven't dealt with thempersonally myself, but I've read
of them and heard of them, sothere's different aspects you
could potentially use, and Ifeel the use of AI within
security is going to be veryrevolutionary in the future.
It's going to get to the pointwhere, with as many jobs that
are missing that we can't fillwithin the security spaces, ai
(30:36):
is going to have to fill thatgap, just because, one, it can
do a much better job than ahuman sorting through logs, but,
two, with the gap that we havein security, there's just no way
you can fill it with people.
They just can't train them fastenough.
So the use of AI would be avery valuable tool in that.
So when we're dealing withlogging, we're going to talk
(30:57):
about some of the error handlingthat goes into that, and one of
the things that you can dealwith is I would recommend having
a security audit done routinelyof these logs, and I would say
routinely in the fact thatprobably about once a year, I
would have that occur and Iwould do an audit of the logs
just to see what is actuallyoccurring.
Now you could have a thirdparty do that, or you could have
(31:18):
your own security team do this,and you could look at what are
the connections, how are theconnections enabled, how are the
authentication mechanismsenabled, and then you can also
be able to dig into the logs tofind out if the tokens are
actually in the API connectionsthemselves.
And I would highly recommendyou look at all of the different
analytics that go along withthe various API gateways that
(31:40):
you have within your environment, and so it's probably good to
do this at least once a year toensure that you understand all
these various connections.
Another thing you can do is useautomated or manual testing
practices as well, and they havethese automated tools that are
like a dynamic applicationsecurity testing tools or static
application security testingtools that you can give to your
(32:02):
developers to have them runthrough your code.
So if they're creating an APIconnection, you can have this,
these tools available.
You have a developer and say,okay, what I want you to do is
run your API through this tool.
It'll run it through the tool,it will test it and then it will
come back and tell you what aresome of the potential errors
that it may have when it doesthat.
(32:23):
If it finds gaps, then what youwant it to do.
These are the processes inwhich you're going to fix them,
and in many cases I've seen timeand again is that the
developers will embed the keysor the authentication tokens
into the overall API connection,and so you're going to have to
have a method to teach them hownot to do that and what does
good look like.
So you want to have to have amethod to teach them how not to
do that and what does good looklike.
(32:44):
So you want to have that as apotential testing platform for
them.
You could have manual testingsas well that are set up that you
could have a concept where,instead of having these tools,
these are the various testingplatforms you can use, and from
a manual standpoint, I'm notsure how you would do that other
than going through the APIconnection specifically one by
(33:05):
one.
One option is, from a manualtesting point of view, is having
it given to another developerand having them run your code
and doing a code review on yourAPI.
By doing that, they may catchthings that you would have
missed.
Apis typically their code, isvery small.
It's very lightweight.
There isn't a lot to it.
So, unless you are specificallynot paying a lot of attention,
(33:30):
you would be able to see if thetokens or the keys are stored
within the actual API codeitself.
But bottom line is having acode review done is probably a
good idea.
If you do not have these accessto these automated tools to help
you with that, the other thingis through the use of a
continuous integration andcontinuous deployment pipeline.
(33:51):
I know GitLab has thesepipelines and I would highly
recommend that you use them.
So they call them a CICDpipeline.
But bottom line is you putsomething in this pipeline, it
goes through it and then itcomes out the other end and it
will tell you where there'serrors within your code.
If you have any sort ofdevelopment shop out there, cicd
pipelines are a very importanttool that they do use when they
(34:12):
are in their development work.
So if you don't know, I wouldhighly recommend you talk to
your development team and seewhat they have in place and then
see how you can embed yourselffrom just maybe from an
influence standpoint within yourdevelopment team on how to
ensure that they have propercoding practices.
That relates to both the APIsand to any sort of development
(34:34):
work that they're doing.
You have to.
As a security professional,it's important that you stay
really connected to these folks.
I have found more and moreissues with my development guys
and gals, not because they don'twant to do it good, they do.
They want to develop reallygood code.
They take pride in developingvery good, very clean, very it's
(34:54):
almost like an art form verypretty code, but they don't
understand the security nuancesaround that and it's important
that you help transport that ortranspose that information to
them.
So just kind of keep that inmind as you're looking to help
develop your security team andto help influence others within
(35:14):
your organization.
Last thing I want to bring up isjust some of the challenges and
best practices you want to dealas it relates to APIs.
One you want to keep up with isevolving threat.
It's constantly changing.
It will not, you will not beable to stop it.
It's going to continue tochange and so therefore, you, as
a security professional, needto change as well and you need
to stay abreast of thesetechnology changes.
(35:36):
So I will tell you that, like Imentioned before, apis and
development is not my strongsuit, because that really just I
learned more in will tell youthat, like I mentioned before,
apis and development is not mystrong suit, because that really
just I learned more in theinfrastructure space, but I've
learned a lot.
Having a development team workfor me.
I learned a lot about howdevelopment actually works.
I am by no means an expert indevelopment, and there's a lot
of people out there that are waysmarter, way smarter, and so
(35:59):
therefore, you need to lean onthose individuals when you are
in the security space of how canthey help teach you what you
don't know.
So you need to keep up on anyevolving threats as it relates
to the development world.
You also need to balancesecurity with functionality.
So we talk about this a lot,that a system may be super
(36:19):
secure but it is not functional.
If people can't use it, it's ofno good to the company.
So you need to allow it to befunctional, but just secure
enough that it protects thecompany from risks.
Now you have to, as a securityprofessional, have to ask
yourself is it protecting mefrom all the risks or some of
the risks?
And then you have to be able tocommunicate those risks to the
(36:40):
stakeholders.
So your senior leaders of goingyes, this is the risk you're
incurring by doing this.
As long as you're okay withthat level of risk and what
could potentially happen to you,then let's move forward.
We've put security mechanismsin place to mitigate everything
else, but these are the risksyou're going to have to either
live with or I can add even moreadditional security, but it
(37:01):
will cut down on thefunctionality, and then that's
where the stakeholders have tomake the decision which way to
go.
So you have to balance that outbetween security and
functionality.
And the last thing is trainingand awareness.
You need to teach people how tomake this work.
It isn't intuitive.
They're not IT.
They don't understand it.
And even if you have folks thatare IT individuals that are
(37:24):
doing API development, they maynot understand it, but always
assume goes to the lowest commondenominator.
Do not think of them as how tostump the dummy, how to teach
the idiot.
We don't talk in those termsbecause in reality, they're very
smart in what they do.
They just do somethingdifferent.
And I learned that when it cameto the finance space.
(37:44):
I had an individual setting upAPI connections and he's in
finance okay one.
He didn't understand the API,so we had to walk through that
and I also brought in somebodywho was an API expert to talk to
him about that.
The other thing is, though, heunderstands finance really well
way better than I could everdream of understanding finance
and so it was a really goodmarriage between the two of us,
(38:06):
so that we could learn somethingabout finance and how they
wanted to use the API connection.
He, in turn, was able to learnhow to better secure it and how
an API connection actually works.
So it's important that youdon't go into the assumption
that these people just aren'tvery smart, and I know that my
listening audience they're notthinking that way, but I've seen
IT individuals think that theuser just isn't very smart.
(38:28):
Well, they're not very smart inmany cases around IT, but
they're really intelligent inareas that are outside of IT.
So if you go in with thatattitude, you will have much
higher success when working withthe actual customer, which is
what our ultimate goal is.
All right, that's all I havetoday for API security and API
(38:49):
protections.
So again, today is Monday, soyou get the training around the
APIs Thursday.
Make sure you tune in.
On Thursday, you will have thequestions that are gonna be
associated with today's training.
All right, I hope you guys havea wonderful day.
You can catch me out atcisspcybertrainingcom.
Cisspcybertrainingcom.
There's some great content.
(39:10):
All this content is out thereand available for you.
It's going to be.
You can just go out there andyou can get it.
There's a lot of free CISSPquestions that are available to
you on CISSP Cyber Training, aswell as courseware to help you
pass the CISSP exam.
The ultimate goal is I've gotmore students that are passing
the CISSP, and the trainingthat's provided through these
(39:32):
podcasts and through othertraining that I have out there
has been invaluable to help thempass the exam.
I have a blueprint that walksyou through, step by step by
step, on what you need to do tostudy for it.
I'm developing anaccountability program that will
help keep you accountable, andthen there's also some new
training that's coming out andsome new interactions one-on-one
with me that you can get accessto as well.
(39:54):
Other than that, that's allI've got.
I hope you all have a wonderfulday and we will catch you all
on the flip side, see ya.
Welcome to the CISSP Cyber Training Podcast, where we
provide you the training andtools you need to pass the CISSP
exam the first time.
Hi, my name is Sean Gerber andI'm your host for this
action-packed, informativepodcast.
Join me each week as I providethe information you need to pass
the CISSP exam and grow yourcybersecurity knowledge.
(00:20):
All right, let's get started.
Let's go.
Cybersecurity knowledge Allright, let's get started.
Hey, all, it's Sean Gerber withCISSP Cyber Training, and I
hope you all are having ablessed day, this beautiful day
here.
I mean things here in Kansasare doing very, very well.
We're pretty excited about theweather.
The weather's been absolutelyamazing and now we have
(00:42):
Christmas, holidays are shortlycoming and my new grand little
granddaughter's heading intotown, so we're excited about
that.
It's very fun to have her hereand the the energy that comes
with a little two and a halfthree year old.
So we are pretty fired up aboutthat piece, uh.
But we're more fired up aboutgetting into.
(01:02):
What you guys are listening foris the CISSP training and we're
going to be getting into as itrelates to API security today.
Today, as you all know, is aMonday, and Monday the training
comes out for the specific topicand then on Thursday you get a
CISSP questions that aretypically not all the time but
(01:23):
in many cases are associatedwith the overall training that
occurs on Monday.
But before we do one thing, Iwanted to bring up a little bit
of news article that I saw today.
Well, actually, I saw it acouple of weeks ago, and that
was as relates to the.
Some various hackers have beenhacking the industrial control
systems at United States waterfacilities.
They have brought this up.
(01:44):
There was an authority ofEquipa, equipa Pennsylvania, and
they had been hacked recently,and this is the second time that
I've seen something.
Well, actually, it's probablylike the third where there have
been attackers that have goneafter water treatment facilities
.
Now, this treatment facilityserves about 6,600 customers, so
it's about the size of the townI live in and they, as you and
(02:07):
my friends that are in India,there are laughing 6,600 people.
They don't even have that.
They have that on a block inIndia.
But, that being set aside,there's about 6,000 people and
there were some folks thatactually hacked into this water
treatment facility and theybelieve they were Iranian-based
activists that were going afterthat facility.
As a result, there was a plcthat's tied to it called
(02:30):
unitronics.
It's unitronics.
This system was one thatallowed them the foothold into
that environment, and sisa cameout with a article that is
around the exploitation of thisUnitronics PLCs and their
recommendations on how to fixthem.
So if you're listening to thisand if you're in the United
(02:53):
States, it really doesn't matterwhere you're at.
If they're having a watertreatment facility that deals
with your Unitronics PLCs, youmay want to get with them and
ask them about how to upgradethose systems.
I've talked to my local townand I'm in the process of
talking to a couple little townsthat are outside of where I
(03:13):
live, just to make sure thatthey have the same understanding
around the hack that's there.
I think it's important that you, as cybersecurity professionals
, do everything in your power tohelp individuals within your
community to understand thesecurity risks that they might
be incurring within theircommunity.
So it's an interesting read.
(03:35):
There are one that's on CISA,has it?
That's the CISAgov and it's theUnitronics.
It's U-N-I-T-R-O-N-I-C-S.
I know that's like the alphabet, but you can Google it.
Unitronics PLCs with water andwastewater systems.
Yeah, check it out, because oneof the things that's come out
of it is there's the.
(03:56):
I guess I'm looking at thearticle from CISA there's the
password is 111.
I mean, these people are justfools.
I'm sorry, but when yourmanufacturers make these things,
I cannot believe they allowthis to continue, require
multi-factor, and then theyobviously want you to disconnect
the PLC from the open internet.
Bottom line is you want to havea segregated network when
(04:18):
you're dealing with anything inthe manufacturing or, in this
case, safety.
You really want to avoid havingit on a business network and
then to have passwords that arebasically four ones.
It's just foolishness.
So I highly recommend that youtalk to people in your local
community about how you can beof assistance to help them.
We need you out there doingthat.
(04:39):
Okay, so now we're going to rollinto understanding API
securities and what are somethings you need to be aware of
as a security professional.
Now I'm going to go into thiswith a disclaimer.
Obviously, that's usually whensomeone comes up with a
disclaimer says they don't knowanything, and that's probably
true.
I know enough in API securityto be dangerous and enough to
teach you and help you pass theCISSP course.
(05:01):
But I am not a developer and Iwould highly recommend if you
really like APIs, then you get alittle bit smarter on it and
teach the hive, the collective,because the bottom line is that
this is an area that iscontinually growing.
I was just on a phone callyesterday dealing with API
security and it was interestingbecause it was coming out of a
(05:23):
large company that was sendingdata using SFTP, which isn't bad
, but we were able to get themon an API connection through an
API gateway and that was a greatoption to help them.
And a lot of that comes down towhat knowledge I have around
APIs is very useful, but whenyou get into the specifics,
that's where you really want toget in a developer to help you
(05:44):
understand the overall API as awhole, and your goal as a CISSP
is to basically be the one thatcan communicate with other
individuals around differentsecurity topics.
You do not have to be theexpert on everything.
You have to understand itenough that you can converse and
then find the right answer.
But in reality, there's so muchinformation nobody can be an
(06:06):
expert on everything.
So when you're dealing withAPIs, you want to allow.
These are basically allowingdifferent secure or different
software programs to communicateand protocols to communicate
with each other.
So, like a way to think of itis as a framework.
So if you have a, you have onepiece of software wants to talk
to another piece of software.
In the past you had to haveboth languages talk to each
(06:30):
other using the same language oryou had to have a program in
the middle that would thenbasically convert one language
into another language.
But what api's are?
They're like a standard,they're like a framework that if
you follow this framework andyou follow the standard, then it
will communicate between oneprogram and another program and
it allows you to have seamlessconnectivity with them.
So you know, if you're a web,if you're a developer and you
(06:52):
create a program with an output,if your output meets the level
of what this framework for, thisAPI, and then you're another
developer of another programthat takes an input, and you
allow, build your anotherprogram that takes an input and
you build your other programthat is taking that input, based
on the standard, then the datacoming from one program to
another program can work welland it allows this communication
(07:16):
path between the two and itworks amazingly well into the
fact that almost everything outthere in today's world is using
APIs.
Now I will tell you that the onething that concerns me as a
security professional is the useof APIs.
Why?
Because there's so many of them.
In the past, we knew the exitsand entrances into a network.
(07:36):
Once you start connecting abunch of APIs together, that
visibility can go away and youdon't have the same level of
understanding of network of dataleaving and coming into and
leaving your network as you usedto have.
So what are some types of APIsthat you're going to deal with
and I'm just going to go into acouple that you will be aware of
that you may see on your CISSPexam.
(07:57):
One is REST.
Now that's the representationalstate transfer.
Now this is the most commontype of an API and it really is
known because it's simplicityand it's statefulness, which
basically means it's alwayslistening.
It's a.
It's a very I need.
My developers used to use therest API all the time and it's
(08:17):
just basically listening all thetime so that information can
come and go.
It's typically used within HTTPand HTTPS protocols and you
will see a lot of people talkabout REST APIs.
Now you have SOAP.
Now SOAP is a simple objectaccess protocol and this is a
protocol based on APIs known forits high security and
(08:38):
extensibility, which basicallymeans it can really be used in
many different ways.
It is typically used within anenterprise solutions and I will
say I've seen it in enterprise.
But I also see a lot of RESTAPIs set up within the
enterprises as well, but SOAP isprobably one that's more common
within a large organization.
You have GraphQL, which is inlike QuickLima, I guess what you
(09:02):
would call it.
This is a newer type of APIthat allows clients to request
only the data they need.
Now, that is a nice aspect tothe API.
In many cases, the APIs are setup just to kind of work as a
fire hose and they just shoveldata to and from.
If you can have it set up whereit's only taking the
information that is necessaryand needed, that is a great way
(09:24):
in reducing the overall datatransfer.
It also helps with bandwidthand, in my case of security.
I like that because I don'twant it to have all kinds of
information sent, because whatI've learned is developers will
send data that they don'tnecessarily always need to have
sent.
They'll just turn it on and letthe fire hose go.
So you need to consider each ofthese different APIs and how do
(09:47):
you want to secure them,because they each have different
kinds of ways of doing so.
Now, there's some common APIsecurity threats that you need
to understand, one, and we'llget into just a few of these,
but there's really four mainones to kind of consider
Injection attacks, brokenauthentication, sensitive data
exposure and thenman-in-the-middle attacks.
(10:07):
Now, your injection attack istypically what we've always
dealt with is.
An injection attack is wheremalicious code is injected into
the API right and that by doingso, you could potentially have
that code run as it's based onwhat the API is just going to
run that actual code itself.
The other one is brokenauthentication.
(10:27):
This occurs when theauthentication mechanisms that
you're set up for your API arebroken.
They're not allowed, but yetthe process is still allowed to
work.
This is where you can get intopotential accidental exposure of
data which could be sensitivein nature.
And then that comes intoanother.
Sensitive data exposure is whenyou do have this through APIs
(10:51):
is that now you have tounderstand what occurred and
then you have to have the levelof exposure data that was
exposed and how are theprotection measures that you
want to implement within them.
And then, lastly, we're going todeal with man-in-the-middle
attacks.
This is where the attackerintercepts the communication
path between the client and theAPI server and they're able to
listen to the information thatgoes in.
(11:11):
Now think of it another way iswe have to deal with secure
communication protocols.
One of the big things that wedeal with is as it relates to
IPsec tunnels, and when you havean IPsec tunnel, it's an
encrypted tunnel.
Well, these API connections,these are not encrypted unless
you incorporate additionalsecurity layers within these
(11:33):
APIs to be able to do that.
So just kind of keep in mindthat it's just a better way of
doing an IPsec tunnel betweentwo locations.
So when you're dealing withsecure APIs, one of the
considerations you need to thinkabout is how do you ensure that
you have robust authenticationenabled?
So you have to have some levelof strong authentication to have
(11:54):
all of these work in a way thatis beneficial for you and for
your company.
And if you don't understand theAPI connections and how they're
authenticated, it's animportant factor for you to kind
of delve deeper into it.
So it's the first thing youshould see when you're dealing
with APIs is how do I understandthe authentication behind it?
And then how am I ensuring thatit is properly protected?
(12:15):
Now, using OAuth or OpenIDConnect?
You need to understand that isa widely adopted standard when
you're dealing with OAuth, andit does.
It provides a secure, delegatedaccess that do allow the
applications to act on behalf ofa specific user, whereas OpenID
Connect is an authenticationlayer on top of OAuth 2.0, which
(12:36):
adds the identity.
So a key thing to remember whenyou're dealing with test
questions also is OAuth providesyou the authorization to have
this occur, which adds theidentity.
So a key thing to remember whenyou're dealing with test
questions also is OAuth providesyou the authorization to have
this occur, whereas the OpenIDprovides the authentication
layer on top of OAuth 2.0.
And we've talked about this ina couple other podcasts, but you
need to keep that in mind is,again, those are some key
(12:56):
differences to understandbetween them.
Now, token-based authenticationthis is used to access tokens
for maintaining a session state.
So these, basically, if youwant to keep your state enabled,
such as an IPsec tunnel, wherethe tunnel is up and operational
, that session is there andavailable for you, and so this
token-based authentication canbe set up to allow that to
(13:19):
happen.
It allows for more scalability,allows you to broaden that out
and flexibility, and it does addfor a level of security to
ensure that that session isstill up and operational.
Now, when we're dealing withaccess controls we've talked
about these in the past is rolebased access.
Attribute based access are twokey factors when you're dealing
(13:39):
with APIs.
Now, role-based access this isyou understand is based on the
individuals, based on your role.
It could be within a user,could be within a manager.
It's just based on specificallywhat your role is within that
organization, and that would bethe setup for the API.
When you're dealing withattributes-based controls, this
(14:00):
is where dynamic access is setup.
Basically, that evaluates theattributes of the overall
position or overall connection,and this would be the user, the
resources, their environment.
This is much more flexible andcontext-aware than the
role-based access controls.
(14:23):
Role-based access controls Now,because it is much more ability
for you to be able to manage ita little bit better.
The interesting part, though,is it does take a lot more, I'd
say, management of it, and I'veused management a couple of
times in that sentence, but youhave to.
I'm trying to use a goodexample of.
In the role-based access, I canclick it on and say Sean's got
access, but when you're dealingwith attributes, then I'm
specifically picking out whatattribute does Sean have access
(14:44):
to, which can add to thecomplexity, which, in turn,
because it's more complex, willcause issues with if you're
trying to troubleshoot and findout why your access isn't
working.
If you get into attribute-basedaccess, you run in the risk of
making it so granular that youend up breaking things, and then
people get frustrated and so,rather than doing the granular
(15:07):
security controls in which theywant to do, they'll just open it
all up just so that everybodyhas access to it.
So that's where, when you getinto role-based access, it can
cause you some challenges.
So another thing to consider istoken management.
Now, when you're going to dealwith each of these API
connections, they have a tokenand you want to have this token.
Just think of it as a way.
Is your security mechanism foryour overall API connection?
(15:30):
Now, when you're dealing withthese tokens, transmitting them
and storing them is a veryimportant factor in your overall
protection of your APIconnection.
And so what you'll do is isthat I've seen it where people
have automatically built it,where the token, more or less
the password, is built into theAPI connection.
And that's a bad idea, right?
(15:51):
Because now you have thisstatic password, the static
authentication mechanism that issitting inside your API
connection.
So it's real easy for it atsome point to be compromised and
now someone could connect intoyour environment with that API
connection, with that token, andyou would not know that it's a
bad girl or bad guy doing that.
(16:12):
So it's important that you havea good way to securely store
those tokens and that they'reonly fetched when actually
needed.
You also need to have some sortof revocation around these
tokens to ensure that when theydo password rotations, you will
then expire these tokens andthen reissue new ones.
If you don't have a way tomanage those, then, like I said
(16:34):
before, the token will neverexpire, and if the token never
expires, the password basicallynever expires, and so then you
get into a situation where, ifI'm a bad guy or gal, I take
advantage of that token and nowI can have unfettered access
into your environment.
So it's important that you havea plan on how to one store them
(16:54):
, two, revocate them, and thenthe third thing is is refresh
them and get you new ones.
Basically, do a password reseton those, because they do have.
You want to limit the lifespanof these tokens so that they're
not available indefinitely.
So api key security you want tounderstand that the fact,
similar to the tokens, you wantto have a way in which they're
(17:15):
properly protected.
Now api keys can be embeddedwithin the api just simpler as
similar as a token, and thisobviously makes it in a
situation where it's much lesssecure than if you actually
would have them in a repositorywhere they're fetched when
needed.
So you need to make sure thatyou understand how do you store
your API keys.
This also can get verychallenging when you're dealing
(17:37):
with microservices and there'ssome challenges that get into
the microservices architecturewhere you're dealing with the
storage of these keys as well.
So you want to always belooking for as you're monitoring
how your APIs are being used.
One question that I've seen isI've seen where folks have,
especially GitLab or those typesof code repositories where
(17:59):
there's an API keys that arestored in the code repositories.
So someone may have an API thatthey've created and they store
it out there in a repository.
Inside it they have left thekey or maybe a token
authentication token that is setup with inside that API key or
API that they created and it'sjust sitting out there in that
(18:19):
repository.
Well, it's sitting out therejust waiting for somebody to
come along and grab it.
So it's important that you aremonitoring both the API and your
code repositories and librariesto ensure that there aren't
those secrets stored out there.
Now I know I think GitLab hasgot a new product out that you
will actually go out and scanyour code repositories looking
(18:41):
for secrets, and it's a greatthing to do and be able to use
if it's possible.
So I know that they're lookingat new items for APIs and some
new trends that are kind ofcoming into that whole space.
One is biometric authentication.
They're using that in relationto facial recognition and
fingerprints as it relates toAPIs, especially in very
sensitive locations.
(19:02):
I think the only time you wouldhave that is if you were
pulling information from aserver.
This probably isn't the onlytime.
I'm sure there's other placesyou would use this, but you're
pulling information from aserver.
You want access to theinformation.
Then you have to do a fingerscan to be able to get access to
that information.
That would be one potential usecase.
They also have decentralizedidentity models.
(19:24):
This is where they're usingblockchain and other types of
technology out there to helpwith API authentication.
And again, it's a differentkind of look at things
Blockchain.
Obviously you'll know of thatas it relates to the Bitcoin
kind of world, but blockchaindoes have provide a lot of great
methods inside of it forallowing you to be able to use,
(19:46):
especially in authenticationpieces.
That is unique and different,and I think it's pretty amazing
how the blockchain piece canwork.
We've used it.
I've used it and seen it usedin various areas within
companies that I've dealt with,and it's been very positive.
The downside of it is it can bevery clunky and kludgy to work
with, especially since it's allbrand new and it's kind of like
(20:09):
a technology trying to find aplace to work, a place to home,
and it's a bit of a challenge.
But there is possibilities thatit could be used within your
environment if you really likethat and you want to give that a
shot.
Another option is machinelearning in authentication.
This is where machine learningalgorithms are being integrated
into the authentication processto help detect if there's any
(20:30):
anomalies that are occurring.
I haven't seen this myself, butI've heard rumblings of it.
It would be interesting to seehow it plays out, but it's
pretty cool if it can happen.
So now we're going to get intowhat we call an API gateway and
what understanding what theprocess is around a gateway.
So this API gateway isbasically a management tool that
sits between the client and thecollection of back end services
(20:53):
.
So, as an example, just thinkof it as a entry point into your
environment.
So if you have APIs, so you caneither have an API that
connects directly from theclient to your server and you
now have, let's say, a thousanddifferent people and a thousand
people set up API connections,and so now you have a thousand
different connections into yourenvironment.
That's really hard to manage.
(21:14):
Honestly, it's darn nearimpossible.
So, rather than having that,what you would do is you'd have
your employees or whoever'ssetting up these API connections
, send them to what they call anAPI gateway, and this gateway
acts as an intermediary, and nowall the information goes
through the gateway, from onelocation to the gateway and then
to another location.
(21:34):
So it's just right.
That's that stopping off point.
The great point about a gatewayis it allows you to do a lot of
different things.
One it gives you visibilityinto what is actually occurring
within your environment.
How many api's do you haveconnected?
Second thing is it also allowsyou to ensure that you have
authentication that is enabled,so that you can't just have
(21:55):
anybody set up an API connectionand they connect into your
environment.
So it's an important factor tojust force people down through
this and, being a farm boy, thischute where you'd send the cows
and the pigs, you'd push themthrough a center place is that
you would run them through thischute, and that's the same thing
that the API is that you'repushing people through this API
(22:18):
or through this gateway toensure that they come into your
environment in a way that is upto your security expectations.
The other thing that you can dois you can also throttle the
connections that are coming in.
So, like anything, if you havea connection coming into your
environment, it takes bandwidth.
Well, if it goes through agateway, you can control the
amount of data that's coming inand coming out, how fast it's
(22:39):
coming in, and it allows you togive you some level.
I'm not going to go down thepath of saying it provides DDoS
protection not DDoS, but DDoSprotection, denial of service
protection but it can give youthe ability to reduce that input
.
So if there is a lot of datacoming in from your API
connections, you can throttlethat in a more or less rate
(23:01):
limited.
So there's a lot of benefitsaround that.
Specifically, it also doessimplify the API management,
where you're not having tomanage a thousand different
connections and it can be veryproblematic.
Now, one thing I want to warnyou is that if you have a cloud
infrastructure in place, onething is if those cloud servers
(23:23):
are exposed to the internet,anybody can set up an API
connection, in most cases, tothose servers.
So you're going to want toreally watch from a security
perspective.
How is the cloud connectingyour cloud infrastructure?
How are you allowing it accessto the internet?
If you're allowing itunfettered access, then you may
have a bigger problem that youdon't even know about and that
(23:43):
it might not be more than justthe APIs.
But if you're allowing APIconnections and individuals to
set up those connections tothese systems, you may have a
serious problem.
So definitely keep an eye onwhat is your overall policy
around allowing people to useAPIs within your environment.
So, when we're going to dealwith rate limiting one thing
around it, we talked about theaspects of the denial of service
(24:06):
attacks and that this will helpwith that.
Now, to be honest, one of thethings I've seen I've seen API
security folks talk about.
Well, it will protect youagainst denial of service
attacks, and it may.
I mean, I'm not the expert andthere's other people that are
the experts in their specifictools.
The thing with denial ofservice attacks is you have to
(24:27):
have a way to dump the traffic.
Now, if it's only limiting thetraffic, the traffic that's
coming in, and it's onlyrestricting it, it may not
totally be stopping a denial ofservice attack.
It may be stopping it insideyour network, but at the gateway
you're still getting denied theservice because there's just so
much data that's coming in.
You have to have a way to shuntit or send the data to a place
(24:49):
where it's basically droppedinto a bucket that's never seen
again.
If it has that ability to dothat, then you would have some
level of denial of serviceprotection against it.
So when you're looking atevaluating API gateways, that's
something to consider.
The other thing around ratelimiting that can happen is is
it what it does?
Is it allows the differentrequests per second or per
(25:11):
minute that are happening and itlimits those to specific users
or specific IP addresses?
So it will help that, inregards to what's coming in, to
mitigate it or to shunt it.
Again, if you're looking at agood product out there to help
you.
You want to make sure that itdoes exactly as it says, because
a lot of people say a lot ofthings but the technology may
(25:32):
not actually do what you'reasking for.
And what you could do even isset it up so that they can
demonstrate to you how thatdenial of service would
potentially occur and then howtheir product would mitigate it.
Another thing you're dealingwith when you're talking about
gateways is there's IPwhitelisting and IP blacklisting
.
So basically it comes down tois if there's an IP address that
(25:54):
you want to allow no matterwhat to in your environment, you
would put an IP whitelistwithin your API gateway.
And the same goes for ifthere's an IP address that you
do not want any access to cominginto your environment, you
would put a blacklist in place.
Now the blacklist can get veryproblematic just because of the
fact that you are specifying aspecific IP address that you are
(26:17):
not gonna allow to communicate.
Well, as we all know, ipaddresses can change.
The other thing is that whenyou're coming in from different
locations, if the IP addresschanges and you're trying to,
you can't figure out why theconnection is not occurring.
It could be because of the factthat that IP was actually
blacklisted.
So most people will say don'tblacklist unless you absolutely
(26:40):
have to.
Now whitelisting, on the otherhand, can get out of hand,
because let's just say, forexample, I'm going to use the
URL, but let's just go googlecom.
Right?
So googlecom has its IP addressof xxx, whatever that number is
and you go I'm going towhitelist googlecom.
Well, you whitelist it and it'sallowed into your environment.
(27:01):
Google's probably not the rightword.
Let's go sneakerstorecom.
You allow this sneaker storeinto your environment, but then
all of a sudden, the sneakerstore is you know, wouldn't pay
as much attention to it, and itgets hacked.
Well, you've whitelisted thesneaker store and the sneak that
individual is now has accessdirectly into your environment,
(27:22):
that company, because youwhitelisted them and you don't
even know that you did thatbecause it happened like three
years ago.
So IP whitelisting is a usefultool, but you need to manage it
on a yearly basis and go throughand make sure that these IP
addresses that you had beforeare the same IP addresses that
you still want to continue goingforward with.
(27:43):
So again, it's really importantto do that Now.
The blacklisting works well whenyou're trying to deal with
malicious sites, but we all knowthose IP addresses do change
and unless you're really gettinginto a lot of challenges around
that, where that site is justconstantly hitting you, then
you're going to want to.
You can blacklist it, but mostpeople use the blacklisting with
(28:05):
a little bit of caution.
They just don't do it a lot, atleast from my experience.
Now that may be in other placesthat may not be the case.
They may use it a lot.
So one thing that happens a lotwith APIs is the use in the
microservices architecture,which is your cloud architecture
, and using the cloud-based APIgateways is a really good way
for you to be able to funnel allthis traffic in through an AWS
(28:27):
or Azure or Google Cloudplatform.
We've seen them.
They're able to scale.
You can put them on loadbalancers so they can spread out
the load.
So they're a really good way ofdoing that, and I would highly
recommend, if you're going tohave APIs, that would be a way
to go about and and push theminto an actual cloud platform.
You can have an on-premenvironment where but yet you
(28:50):
have an api cloud or an apigateway in the cloud so all of
your apis can go out to thatgateway.
They then can be shunted backinto or sent back into your
environment through thatspecific gateway.
They work really really welland they're just.
That's all I've ever seen.
I'm sure you can do it in anon-prem version of that, but all
(29:13):
I've ever dealt with arecloud-based API gateways.
Now they do have analytics thatwill help you with usage, that
will help you performance andalso any security incidents that
occur.
This comes down to logging andmonitoring as well.
I've kind of mentioned itbefore.
I would highly recommend thatyou turn on some level of
logging and monitoring withinyour API environment.
(29:33):
You need to decide how muchlogs you want to keep, just like
everything else.
The more logs you keep, themore you have to filter through.
But with an API connectionbeing that it's coming from the
outside, being the fact thatthere's thousands of them and
you really don't have a goodgrasp of sometimes what are all
those connections, logging andmonitoring on your gateway is
(29:53):
really an important part, andthen ensuring that you have
proper protections around thoselogs that they're not tampered
with in the event something badwould happen.
Now there's various machinelearning, or I should say
machine learning capabilitiesare out of artificial
intelligence capabilities thatare being utilized within API
gateways to help mitigate someof the security risks that are
(30:15):
associated with them.
I haven't dealt with thempersonally myself, but I've read
of them and heard of them, sothere's different aspects you
could potentially use, and Ifeel the use of AI within
security is going to be veryrevolutionary in the future.
It's going to get to the pointwhere, with as many jobs that
are missing that we can't fillwithin the security spaces, ai
(30:36):
is going to have to fill thatgap, just because, one, it can
do a much better job than ahuman sorting through logs, but,
two, with the gap that we havein security, there's just no way
you can fill it with people.
They just can't train them fastenough.
So the use of AI would be avery valuable tool in that.
So when we're dealing withlogging, we're going to talk
(30:57):
about some of the error handlingthat goes into that, and one of
the things that you can dealwith is I would recommend having
a security audit done routinelyof these logs, and I would say
routinely in the fact thatprobably about once a year, I
would have that occur and Iwould do an audit of the logs
just to see what is actuallyoccurring.
Now you could have a thirdparty do that, or you could have
(31:18):
your own security team do this,and you could look at what are
the connections, how are theconnections enabled, how are the
authentication mechanismsenabled, and then you can also
be able to dig into the logs tofind out if the tokens are
actually in the API connectionsthemselves.
And I would highly recommendyou look at all of the different
analytics that go along withthe various API gateways that
(31:40):
you have within your environment, and so it's probably good to
do this at least once a year toensure that you understand all
these various connections.
Another thing you can do is useautomated or manual testing
practices as well, and they havethese automated tools that are
like a dynamic applicationsecurity testing tools or static
application security testingtools that you can give to your
(32:02):
developers to have them runthrough your code.
So if they're creating an APIconnection, you can have this,
these tools available.
You have a developer and say,okay, what I want you to do is
run your API through this tool.
It'll run it through the tool,it will test it and then it will
come back and tell you what aresome of the potential errors
that it may have when it doesthat.
(32:23):
If it finds gaps, then what youwant it to do.
These are the processes inwhich you're going to fix them,
and in many cases I've seen timeand again is that the
developers will embed the keysor the authentication tokens
into the overall API connection,and so you're going to have to
have a method to teach them hownot to do that and what does
good look like.
So you want to have to have amethod to teach them how not to
do that and what does good looklike.
(32:44):
So you want to have that as apotential testing platform for
them.
You could have manual testingsas well that are set up that you
could have a concept where,instead of having these tools,
these are the various testingplatforms you can use, and from
a manual standpoint, I'm notsure how you would do that other
than going through the APIconnection specifically one by
(33:05):
one.
One option is, from a manualtesting point of view, is having
it given to another developerand having them run your code
and doing a code review on yourAPI.
By doing that, they may catchthings that you would have
missed.
Apis typically their code, isvery small.
It's very lightweight.
There isn't a lot to it.
So, unless you are specificallynot paying a lot of attention,
(33:30):
you would be able to see if thetokens or the keys are stored
within the actual API codeitself.
But bottom line is having acode review done is probably a
good idea.
If you do not have these accessto these automated tools to help
you with that, the other thingis through the use of a
continuous integration andcontinuous deployment pipeline.
(33:51):
I know GitLab has thesepipelines and I would highly
recommend that you use them.
So they call them a CICDpipeline.
But bottom line is you putsomething in this pipeline, it
goes through it and then itcomes out the other end and it
will tell you where there'serrors within your code.
If you have any sort ofdevelopment shop out there, cicd
pipelines are a very importanttool that they do use when they
(34:12):
are in their development work.
So if you don't know, I wouldhighly recommend you talk to
your development team and seewhat they have in place and then
see how you can embed yourselffrom just maybe from an
influence standpoint within yourdevelopment team on how to
ensure that they have propercoding practices.
That relates to both the APIsand to any sort of development
(34:34):
work that they're doing.
You have to.
As a security professional,it's important that you stay
really connected to these folks.
I have found more and moreissues with my development guys
and gals, not because they don'twant to do it good, they do.
They want to develop reallygood code.
They take pride in developingvery good, very clean, very it's
(34:54):
almost like an art form verypretty code, but they don't
understand the security nuancesaround that and it's important
that you help transport that ortranspose that information to
them.
So just kind of keep that inmind as you're looking to help
develop your security team andto help influence others within
(35:14):
your organization.
Last thing I want to bring up isjust some of the challenges and
best practices you want to dealas it relates to APIs.
One you want to keep up with isevolving threat.
It's constantly changing.
It will not, you will not beable to stop it.
It's going to continue tochange and so therefore, you, as
a security professional, needto change as well and you need
to stay abreast of thesetechnology changes.
(35:36):
So I will tell you that, like Imentioned before, apis and
development is not my strongsuit, because that really just I
learned more in will tell youthat, like I mentioned before,
apis and development is not mystrong suit, because that really
just I learned more in theinfrastructure space, but I've
learned a lot.
Having a development team workfor me.
I learned a lot about howdevelopment actually works.
I am by no means an expert indevelopment, and there's a lot
of people out there that are waysmarter, way smarter, and so
(35:59):
therefore, you need to lean onthose individuals when you are
in the security space of how canthey help teach you what you
don't know.
So you need to keep up on anyevolving threats as it relates
to the development world.
You also need to balancesecurity with functionality.
So we talk about this a lot,that a system may be super
(36:19):
secure but it is not functional.
If people can't use it, it's ofno good to the company.
So you need to allow it to befunctional, but just secure
enough that it protects thecompany from risks.
Now you have to, as a securityprofessional, have to ask
yourself is it protecting mefrom all the risks or some of
the risks?
And then you have to be able tocommunicate those risks to the
(36:40):
stakeholders.
So your senior leaders of goingyes, this is the risk you're
incurring by doing this.
As long as you're okay withthat level of risk and what
could potentially happen to you,then let's move forward.
We've put security mechanismsin place to mitigate everything
else, but these are the risksyou're going to have to either
live with or I can add even moreadditional security, but it
(37:01):
will cut down on thefunctionality, and then that's
where the stakeholders have tomake the decision which way to
go.
So you have to balance that outbetween security and
functionality.
And the last thing is trainingand awareness.
You need to teach people how tomake this work.
It isn't intuitive.
They're not IT.
They don't understand it.
And even if you have folks thatare IT individuals that are
(37:24):
doing API development, they maynot understand it, but always
assume goes to the lowest commondenominator.
Do not think of them as how tostump the dummy, how to teach
the idiot.
We don't talk in those termsbecause in reality, they're very
smart in what they do.
They just do somethingdifferent.
And I learned that when it cameto the finance space.
(37:44):
I had an individual setting upAPI connections and he's in
finance okay one.
He didn't understand the API,so we had to walk through that
and I also brought in somebodywho was an API expert to talk to
him about that.
The other thing is, though, heunderstands finance really well
way better than I could everdream of understanding finance
and so it was a really goodmarriage between the two of us,
(38:06):
so that we could learn somethingabout finance and how they
wanted to use the API connection.
He, in turn, was able to learnhow to better secure it and how
an API connection actually works.
So it's important that youdon't go into the assumption
that these people just aren'tvery smart, and I know that my
listening audience they're notthinking that way, but I've seen
IT individuals think that theuser just isn't very smart.
(38:28):
Well, they're not very smart inmany cases around IT, but
they're really intelligent inareas that are outside of IT.
So if you go in with thatattitude, you will have much
higher success when working withthe actual customer, which is
what our ultimate goal is.
All right, that's all I havetoday for API security and API
(38:49):
protections.
So again, today is Monday, soyou get the training around the
APIs Thursday.
Make sure you tune in.
On Thursday, you will have thequestions that are gonna be
associated with today's training.
All right, I hope you guys havea wonderful day.
You can catch me out atcisspcybertrainingcom.
Cisspcybertrainingcom.
There's some great content.
(39:10):
All this content is out thereand available for you.
It's going to be.
You can just go out there andyou can get it.
There's a lot of free CISSPquestions that are available to
you on CISSP Cyber Training, aswell as courseware to help you
pass the CISSP exam.
The ultimate goal is I've gotmore students that are passing
the CISSP, and the trainingthat's provided through these
(39:32):
podcasts and through othertraining that I have out there
has been invaluable to help thempass the exam.
I have a blueprint that walksyou through, step by step by
step, on what you need to do tostudy for it.
I'm developing anaccountability program that will
help keep you accountable, andthen there's also some new
training that's coming out andsome new interactions one-on-one
with me that you can get accessto as well.
(39:54):
Other than that, that's allI've got.
I hope you all have a wonderfulday and we will catch you all
on the flip side, see ya.
Popular Podcasts
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.