Join host Jeremy Snyder as he digs into the fascinating world of AWS and cybersecurity with none other than Ian McKay, a distinguished AWS Community Hero and Cloud Principal at Kablamo. From the dynamic intersection of cloud infrastructure, cybersecurity, and API protection, this episode covers the latest trends, innovative tools, and groundbreaking research reshaping the future of cloud security.
Join host Jeremy Snyder as he digs into the fascinating world of AWS and cybersecurity with none other than Ian McKay, a distinguished AWS Community Hero and Cloud Principal at Kablamo. From the dynamic intersection of cloud infrastructure, cybersecurity, and API protection, this episode covers the latest trends, innovative tools, and groundbreaking research reshaping the future of cloud security.
About Ian McKay
Ian McKay is not only a revered AWS Community Hero but also serves as a Cloud Principal at Kablamo, where he leads the charge in driving cloud transformation and security initiatives. With years of hands-on experience and a passion for innovation, Ian is on a mission to revolutionize the cybersecurity landscape. As the mastermind behind Forma 2, IAM Live, Permissions Cloud, and IAM Dataset, Ian's groundbreaking open-source projects are setting new standards in cloud security. Stay connected with Ian on social media and explore his thought-provoking research on his blog.
Connect with Ian:Twitter: https://twitter.com/IANN0036
LinkedIn: https://www.linkedin.com/in/ian-mckay-431408156/
GitHub: https://github.com/IANN0036
Explore Ian's Research:
Blog: https://onecloudplease.com/
About Jeremy Snyder
Jeremy is the founder and CEO of FireTail.io, an end-to-end API security startup. Prior to FireTail, Jeremy worked in M&A at Rapid7, a global cyber leader, where he worked on the acquisitions of 3 companies during the pandemic. Jeremy previously led sales at DivvyCloud, one of the earliest cloud security posture management companies, and also led AWS sales in southeast Asia. Jeremy started his career with 13 years in cyber and IT operations.
Tune in now to gain invaluable insights from Ian's expertise as a Cloud Principal at Kablamo and unlock the secrets to fortifying your digital infrastructure against evolving threats. Don't miss out on this enlightening conversation shaping the future of cloud security!
0:00
[Music]
0:09
all right welcome to another episode of the modern cyber podcast we are again coming to you from Down Under this week
0:15
and I am thrilled to be joined by Ian McKay who is joining us Ian is a cloud
0:21
principal sorry the cloud principal at kblo which is a cloud product development and data consultancy
0:26
specializing in building applications native to the cloud he's usually focused on cloud architecture cicd and security
0:32
but is always trying out the latest cloud services between helping clients he loves the chance to build open source
0:38
projects we're going to talk about a couple of his open source projects um but his projects have a heavy focus on cloud Automation and tooling Ian also
0:45
enjoys speaking at meetups co-hosting podcasts engaging with the community on slack and posting his latest experiences
0:50
within the cloud on his blog couple of the projects that you may know Ian from our console recorder former 2 I am live
0:58
which I assume is related to I am we'll come to that in a little bit uh permissions. cloud and I am data set Ian
1:04
is also an AWS Ambassador in community hero I'm not sure where you find the time for all of that end but I do
1:09
appreciate you taking the time to join us today thank you so much for having me Jeremy awesome awesome well I've got a
1:15
bunch of things that I want to get into today and definitely want to talk about some of your open source projects but
1:21
before we get into that I know one of the questions that I've had a chance to chat with you offline a little bit about
1:26
is building Secure Solutions for customers with strong Regulatory Compliance requirements and I'm curious
1:32
you know as you you've been doing this for a number of number of years I wonder if there's any kind of main lessons that
1:38
you've learned over the years around kind of let's say like walking the fine line of moving quickly in the cloud but
1:45
then staying compliant what what are some of the things you've learned yeah I think for me one of the main lessons
1:51
I've learned as a consultant is that every customer has very different needs very different requirements and levels
1:57
of like technical competence a lot of customers are really far along on their Cloud journey and experiencing
2:04
a lot of different new ideas and a lot of them are really just coming out of on pram and doing just the Bare Basics to
2:12
get them through so it's about uh I sometimes have to change the way I talk
2:17
to uh my customers to figure out you know what what would best suit them in
2:23
in their specific use case so you know not to kind of oversimplify it but is it
2:28
fair to say that you know got some customers who have let's say maybe just executed the lift and shift and haven't
2:34
really embraced Cloud Ops as we might think about it today and those that are Al then at the other end of the spectrum
2:40
and so then as a result of that how you figure out your approach like really has to vary widely yeah that's exactly right
2:48
there's a lot of customers that have still in that server full mindset of uh having their pets in the cloud and
2:55
things like that and not embracing uh immutable infrastructure things like that and there's some customers that are
3:01
really at the bleeding edge and doing some really interesting uh Cloud native style
3:07
applications well I'm curious for those that are at that bleeding edge and building kind of cloud native and you
3:13
know that was one of the things in the intro that we talked about is you've been doing Cloud NATA for a long time and so for those that are at that end of
3:20
the of the spectrum how do you talk to them about balancing speed and
3:26
compliance because they're probably because they are at that know Edge they're probably used to moving really
3:32
quickly yeah usually it's really about uh having a discussion with them
3:38
about their risk tolerances so I always find it really helpful to go through that uh standard
3:45
risk Matrix about what is the likelihood of a specific uh risk or incident
3:50
happening versus the impact that it has and that really helps me understand how
3:55
fast are they willing to move versus uh how bad would it be if they move too fast and broke things a lot of customers
4:03
are very happy to even have you know production downtime or things like that
4:08
and a lot of customers will spend uh six months testing a uh a deployment just to
4:13
make sure it's exactly right so there's a lot of differences in those in that space and uh I generally find that uh
4:21
establishing the boundaries within the cloud environment between your different environments helps them achieve some
4:27
sort of a balance between their and their stable stability um so having
4:33
lower environments having being a little bit more agile maybe allowing more permissions to do to interact with those
4:39
sort of environments and then taking a hands-off approach in those higher style
4:44
environments and in along those lines do you find that there is a firm
4:49
understanding about where security and compliance overlap versus where they diverge or do you feel like that
4:55
conversation gets like gets pretty blurry for customers that are like moving quickly but do have strong
5:02
regulatory requirements yeah so there's there's always this I guess conflict about what
5:08
they have to do for their Regulatory and compliance programs uh things like ISO
5:14
27 K1 sof 2 Etc and uh even even their own internal programs uh versus what
5:20
they uh can achieve I feel like both program both uh the companies and the
5:27
compliance programs are really doing very good job at covering off all the major areas and especially with the idea
5:34
of regular enforcement so making sure that not only are their controls in place but they're being tested and
5:40
they're going through it all the time what I find uh they sometimes fall down
5:46
uh on is practicality so okay having Auditors come in and not really caring
5:52
about how controls are met or when controls are met in a non-standard way
5:57
uh and they sometimes get confused or or disagree that specific needs are met despite the organization really doing
6:04
the leg work and saying no yes we've done we've done all this uh work to make
6:10
sure that this is uh covered off um so it's a little bit of inconsistency with
6:16
uh their application of rules and things like that yeah and and you know there's a lot that comes to mind as you talk
6:22
about that inconsistency I mean first of all kind of the graduated scale of risk
6:29
tolerance for different environments right so if we think about to your example you know tolerating a a somewhat
6:35
higher level of risk in let's say Dev test or even in staging environments where we might not have customer data we
6:42
shouldn't have customer data right and we also um probably have some kind of
6:47
network uh Network layer controls that maybe don't make those environments public they're only for internal usage
6:53
they're only for internal testing Etc maybe staging has some external exposure
6:58
to kind of simulate what public uh attacks against an environment might mean from a security perspective but one
7:05
of the things that I found in a lot of the work that I've done is that turning that off as you get higher and higher up
7:13
the stack into production environments can lead to a somewhat disjointed experience where you know you have it
7:20
where customers come to expect a certain level of access in an environment and then as you get stricter and stricter
7:26
that can be hard for them to internalize in their operation you must have gone through a similar
7:32
Journey with certain customers how did you explain to them like no no no the controls are this for Dev this for prod
7:39
and here's why I think the way that I I tend to pitch this is about their own
7:45
protection and always working within uh their guidelines and their requirements to get as
7:51
much uh understanding and access that they can achieve without then compromising them so I'll always ask
7:59
what is the main pain points for your developers or what what are you seeing
8:05
that is is causing costing you a lot of time and we'll try and work around those things with various different tricks and
8:11
hacks but uh a lot of the time it's just simply a conversation of look you don't want this you don't want this level of
8:17
access because then you're liable for this um and sometimes that's a hard
8:23
conversation to have but it's a conversation that we need to do yeah and do you find that you've been able to
8:28
develop some of a templated approach to this over the years where you can maybe like go into a customer you know have a
8:34
conversation with them to assess what the risk tolerance level are is assess what their um regulatory requirements
8:41
are and then maybe come out with something of a blueprint for oh okay you need Landing zones that look like this
8:48
you need an AWS org that looks like this with these service control policies and maybe control tower to deploy this set
8:54
of accounts with these governance rules and so on or do you find that it's still you know is pretty uh bespoke for each
9:01
customer engagement that you go into yeah so we definitely have a lot of uh
9:07
bootstrap templates and things like that uh a lot of that vary in complexity based on the customer we
9:14
technically or we usually know the level of competence with a customer kind of walking in the door so we can start the
9:22
conversation pretty well on there um as we start and then manipulate that from there
9:30
um but yes absolutely we have a number of different approaches um that we take internally and that's good for our own
9:36
standardization as well so when we're handing off to support teams and things like that if we're supporting a customer
9:44
post production then everyone knows what it kind of looks like everyone sees the same patterns the same places to look
9:50
and so it's a lot easier to triage and debug issues and do you find I mean one
9:55
of the things that I've always found working with customers over the year on security is it's like it's a lot easier
10:01
or it can be a lot easier to actually start from zero even if a customer has gone down you know let's say gone 50 60
10:08
70% of the way down what you might think of as a cloud Journey path and they're 2third to all the way migrated to the
10:16
cloud if they haven't baked security into let's say the designs of their account structures or their uh
10:23
permissions boundaries or things like that it can often be easier to you know kind of start fresh with a new
10:29
organizational structure and again the service control policies and whatnot that we talked about and then actually do a cloud to Cloud
10:36
migration is that something that you run across a lot or you find that now most of the time for customers if they've
10:41
kind of started that migration Journey they really want to kind of retrofit clean up the environments that they're
10:46
working in already usually we would get to that point where it's already that
10:51
far gone so if we can usually retrofit an existing architecture Within you know
11:00
reasonable uh means to to get it to where it needs to be uh we did this a
11:05
lot when uh Ed control tower came out and that had a bunch of standardized
11:11
practices and now we had to figure out what is the customer actually doing versus what is the service providing and
11:17
then uh kind of retrofitting that in which is uh its own set of challenges but
11:23
usually the types of customers that we speak to are usually engaging in either green projects or don't have the
11:31
technical level of Competency that they want to have any say in it whatsoever so you will usually come in and dictate to
11:38
them this is your ground workor layer these are your guard rails Etc uh and they're they're very happy
11:44
with that because they're taking that subject matter expertise from us um to
11:49
make sure that they are secure in the way they work yeah this is one of the things that we found pretty consistently
11:55
over the last I guess eight years or so that I've been working on cloud security is that
12:00
very often customers don't know what they don't know and so a lot of the times to your point they're very happy
12:07
for somebody to come in and help kind of dictate uh require to them because it
12:12
can be very informative right if especially if they're coming out of let's say Legacy data center type of
12:17
architectures um they may often have a strong focus on let's say perimeter oriented security and monitoring as you
12:25
know the the next kind of pillar of of a security strategy and monitoring can be
12:32
particularly challenging in very ephemeral environments where things are changing on a regular basis you know
12:37
installing the agent or even if you're not using um an agent full service but
12:42
you're using an agent list service um assigning the ephemeral infrastructure
12:48
to the workload so that you can have a consistent level of monitoring over time all of that can be very challenging if
12:54
you don't know what you're what you're kind of doing and how to do that and it really leads into to one of the next
12:59
topics I want to talk to you about is infrastructure as code because I think the only way to really manage that effectively is with infrastructure as
13:06
code especially if you are doing a lot of ephemeral things um with agentless architectures so um you I guess built
13:15
and maintain I don't know if you're one of the only Builders or you're the only Builder um but former two I kind of came
13:21
across as one of your open source projects I mean talk to us a little bit about it what was the origin story what
13:26
problem did you set out to solve sure so I guess forward to is the second in a
13:32
line of products that uh I've primarily built and maintain uh the first of which
13:37
is called console recorder for EDS uh that that first one console
13:42
recorder for EDS was actually built out of my own frustration of uh I can actually tell you the exact call it was
13:49
medialized create channel call which if you look at the Botto docs for like six pages long or something like that just
13:55
massive amount of parameters and things like that that I needed for that and I found myself uh going into the network
14:02
tab of the console to trying to figure out what exactly are these parameters and figuring out how my console actions
14:08
are mapped to uh what these AI calls needed to do and so I took that as an
14:14
idea and made uh with the F the first uh product called console recorder for ads
14:19
which is a browser extension which records the actions you take within the Eds console and then converts that to uh
14:27
Botto 3 or cloud or terraform and things like that and so I wanted to generate
14:32
these um uh infrastructure as code or even just scripts so I could so I can
14:38
understand what the console is actually doing uh and that turned out to be very popular but the common ask I got from
14:45
that was well I've already had uh my employee over there create this infrastructure or I forgot to PR press
14:51
record because it's a very live thing yeah what about my existing resources and that's why I've moved from that
14:59
project into Forma 2 which I currently maintain today and Forma 2 basically does a scan of your account so that's
15:05
the list and get calls this is done entirely locally so there's no server that I manage or anything else like that
15:11
it's just um it's a your your PC to EDS endpoints and basically again through a
15:18
browser Plugin or it's basically just through a website so you can just view a
15:24
website as a static website uh and you can see the calls that going out to uh
15:30
the ads website to the ads end points you provide credentials and things like that and it'll okay go and pull in that
15:36
data and it takes those list and get calls and then converts that again to your infrastructure as code your Cloud
15:41
information terraform uh palumi cdk things like that so that you can figure
15:47
out what you've created in the uh EDS uh environment so that's by C or
15:54
by uh not just clicks but like API calls or things like that and then start to
15:59
convert that into your infrastructure's code so you can have that immutable uh
16:04
stack based uh design um which is I think a super effective tool not only
16:11
for uh taking your uh click Ops work and bringing it in but also educating
16:16
yourself on uh what specific fields are doing what in the environment and you
16:23
know when you might not necessarily know a property or something like that in your infrastructure is code that's a
16:28
really good to figure that out and does it take into account the order of operation so if I'm you know building a
16:34
classic three- tier architecture database app server web server um or you know web layer whatever that ends up
16:41
being uh I know that you know the the RDS instance needs to come up first so
16:46
that there is a database server that the app server can connect to and instantiate the database tables or
16:51
whatever the exact sequence of operations is that's all kind of built into this former two um approach yeah
16:58
absolutely so either within terraforms attribute controls or with cloud formation intrinsic functions that your
17:05
ref and you'll get at it basically looks at the known uh outputs whether that's IDs and
17:11
Arns figures out that that's actually present in another resource and then automatically does the mapping for you
17:19
uh which is an interesting programming challenge to solve basically like writing out the graph of the thing you
17:24
just scanned um but once I got it working it's super effective and um yeah
17:31
very cool it's really interesting and I mean you know not to go down too deep of a rabbit hole around this but it's
17:37
really interesting to me that you use the word graph when you're talking about that because I know there is there's a
17:43
few of us who have been in the club Community for a long time I'm sure yourself included that tend to think
17:49
about workloads as actually being collections of resources with these intrinsic connections to each other and
17:57
all of that being represented presented by a graph and that graph concept is increasingly being adopted on the cyber
18:03
security uh side when you think about things like one of the most modern I say
18:09
modern and kind of air quotes here but one of the most common ways that people are analyzing their Cloud security
18:15
posture right now is through a combination of attack paths and blast radiuses right and an attack path is
18:21
kind of you know from let's say a vulnerability on an ec2 instance x what
18:27
else can I get to or what is the path towards exploiting an environment and then the blast radius is kind of you
18:33
know the maximum exposure from that was Security in your mind when you
18:40
created former 2 or was it you know kind of something that you think really is kind of off to the side you're really
18:46
focused on the infrastructure side of it yeah I think when I was creating it I was focused entirely on the
18:53
infrastructure security was on my mind in that I knew that I personally would never uh or would be reluctant to give
19:01
access to my cloud environment to third party vendors and things like that so I actually went out of my way and it's
19:07
actually really annoying to uh have it such that this is a static thing that I
19:13
I never see uh the usage of it or or what people are doing with the tool because I've specifically said I don't
19:20
want to be involved in this this is a direct call that you make with uh the cloud provider so yeah um that that was
19:26
always in my mind but as as far as the idea of visualizing infrastructure in a graph I think that's one of the
19:32
fundamental things that really helps your understanding of infrastructurist code
19:38
when you get into that space because it starts to make you think about the
19:43
relationships and the life cycle of events uh one of the biggest questions
19:49
that people always talk about is how do how should I lay out my my gra my stacks or my templates or things like that and
19:57
it really comes down to the life cycle of your infrastructure if this is a static style infrastructure yeah
20:04
everything that relates that piece of static um material so that might be a database or something like that should
20:10
be in its own stack but if you have uh something like a Lambda where it's very ephemeral in nature and can update and
20:17
things like that it should be separate um as far as the stack management side of things goes because you don't want to
20:22
have those two things be affected in the same way yeah but but I'm curious along
20:28
those lines when you think about kind of laying out Stacks where do you think a stack should start and end and I'll I'll kind of
20:35
explain what I mean and get your opinion on it right so over the years and talking to I I don't know how many
20:41
hundreds of customers about Cloud security and their overall Cloud security strategy I've seen kind of two
20:46
approaches right and so one is two general like high level approaches so one is more the kind of um you know
20:55
command and control and you kind of can't do it unless it's explicitly allowed and you can think of that as
21:01
kind of the service catalog type of approach Etc one of the other approaches that I've seen within larger
21:07
organizations that are fast moving um and maybe I should qualify like my experiences are usually with larger fast
21:14
moving Cloud environments the the other approach that I've seen is kind of guard
21:19
rails that usually take the form of we've laid out a VPC structure and we've
21:25
laid out I am roles and policies and as long as you kind of color within the lines of those two things you know you
21:33
can't really break outside this VPC structure you can't really violate permission sets that we've applied from
21:40
these I you know kind of known good I am policies we feel safe as an organization
21:45
from a risk management perspective like when you think about these Stacks do you usually think about Stacks incorporating
21:52
vpcs and am roles and so you really want to like build up the entire network and
21:57
I structure for the stack or do you think about them using something out of let's say a known good collection of
22:04
network and um identity um kind of templates yeah we usually take the
22:10
Approach at least within my company of doing the guard rails approach of having
22:15
a bunch of borders around what you can and can't do um particularly with things like Security Services that you can't
22:21
touch but having giving them the freedom to do whatever they need to do to solve
22:26
their workload I don't think the the problem with the service catalog style
22:33
approach is that you run into this limitation where you become the single
22:38
point of failure IE totally and that's probably a bad uh bad way of phrasing it but you have a bunch of teams coming
22:45
into you saying we need we have these new requirements we want to do X we want to do y and then if you don't have that template for you in your service catalog
22:53
it's on you to develop that and that can be a huge BTL net for the organization
22:58
so definitely take that guard rail style approach as often as we can yeah yeah
23:04
that makes total sense and it's funny I mean you you know I tend to think of the the former the service catalog approach
23:10
as the um we used to talk about it a lot as The Rock in the river right so let's say imagine you've got a river or a
23:16
creek or you know whatever scale you want it to be but you've got let's say a path of water flowing and you say well
23:23
hold on I only want to allow these things to go byy it so you'll put a rock to Dam up that water flow and you can
23:30
make that rock as big as you want but eventually what happens is there's erosion around the edges and more and more water gets by it and so to your
23:37
point if there's not a service catalog offering for the brand new media service
23:43
that AWS just launched or whatever you know you're you're going to fail at some
23:48
point because either the developers and the people who own the workloads get so
23:54
frustrated that they can't get what they need out of your service catalog and they just just go you know the shadow it route without a credit card create a new
24:01
AWS account whatever or you know they do something that's completely out of your control which I guess that kind of that
24:07
that example kind of is so um awesome now um you have a couple of other uh
24:13
open source packages former two is the one that I I spent the most time kind of browsing but you've got I am live which
24:18
or I am live I don't know how you pronounce it but I assume it's also related to I am yeah sure um so I am
24:24
live is a uh go application that basically intercepts your calls um from
24:31
your local environment or from your Cloud environment perhaps um on the way to ads endpoints and then generates a
24:38
set of least privileged IM policies for what you're doing um with with those
24:43
services so you can put that as a client side monitoring or just a sort of man
24:49
in-the-middle proxy approach yeah uh and whatever the whatever calls go out to
24:54
the Eds endpoints during that egress you're looking at those calls and then
24:59
I'm basically generating a least privileged template of Y um of the am
25:04
permissions that would be needed to do that again uh and so this is really uh useful for generating like I said leas
25:12
privilege policies um without saying you know star star administrator access
25:17
whatever um so you can really scope down what you need to do um one of the and
25:24
you it's always funny when you release tools you never really how they going to be used by the
25:30
community former 2 has been used as a uh sort of a whole account like 8 account
25:37
catalog tooling without the um the infrastructures code as well so you
25:43
never really understand how how that might work and I am live is uh very
25:50
frequently used to generate terraform lease privilege uh roles so like oh
25:56
interesting ter makes calls to the edus endpoints in order to do its actions but by doing that we can intercept those
26:03
calls and figure out if I was to deploy this uh in a cloud account for example
26:09
uh what would be the role that I have to give terraform in order to do those deployments um there's have been a lot
26:15
of work around using it in that use case well it's interesting because as you were describing it the use case that
26:20
popped to my mind was um local application development but using like
26:26
AWS backend say like S3 RDS Dynamo whatever kind of like the for for the
26:31
long-term storage of the data that my app is collecting and then you know narrowing permissions between whatever
26:37
app service I'm going to use whether Lambda some container or ec2 and those
26:44
other uh components that that's where immediately where my thinking went on I am live I don't know if that's what your
26:50
original intention was but that's how I saw it being used because otherwise I do to your point I see developers all the
26:55
time doing oh it's a it's a workload I'm deing on ec2 I'm just going to give it S3 star and RDS star because I know it
27:02
needs to you know read and write a database and some files yeah it's one of the hardest I think it's one of the
27:08
hardest areas within Cloud to get permissions and identity access right
27:15
and the guidance around it is still lacking in some way yeah there
27:22
there's still a lot of work that needs to happen to educate people because it's a very complex language and it's a very
27:28
complex thing to work on um to do it to the point where you
27:34
can El eliminate you know potential lateral movement and things like that should your application actually get
27:41
compromised and and you don't find that the um the IM am policy generator is I
27:46
don't know widely understood enough or or good enough I don't know I mean I just think it's it's a huge commitment
27:53
to get to the level that you need to be to be proficient what I would consider
27:58
proficient in it enough that you can protect yourself adequately because there's so many gotas things like the
28:06
confused Deputy problem is not well understood within the uh the cloud community at all and it's I think it's a
28:14
Time BMB waiting to happen yeah um we've only got a few minutes left and I know
28:20
there's a couple of other packages that you maintain and I've got a couple of other questions I'm hoping to get to but maybe just briefly uh permissions cloud
28:27
and I data set what would you want to tell the audience about those yeah sure so the IM data set is basically that
28:33
mapping of apia actions to IM permissions it's being used to drive IM
28:39
live and permissions cloud is basically uh a web front end so it's permissions. Cloud as a website uh that you can use
28:46
to view and inspect that data set so you can understand what permissions would I need if I was to do this API action
28:53
without actually doing it with your local environment gotcha gotcha awesome
28:58
so I know you do a lot of research on your own as you're kind of building things out whether for yourself or for
29:03
clients and whatnot and I know that's one of the things that um I've enjoyed in our conversations is that you've got
29:08
a a wealth of knowledge on things that I probably haven't looked at deeply one of the ones that I spotted on your blog
29:15
recently was Cedar and you know Cedar I guess it's been around for a couple of years at this point and I'm always
29:21
curious whenever I see yet another policy language I mean I think there's even an acronym for what is it Yara yet
29:26
another rule um language or something like that like did we really need another policy language have you played with it what
29:32
are your thoughts on it so far like a year and a half two years into its life yeah I think Ceda really filled a
29:39
specific niche of that very common problem of I have a simple uh
29:46
application that has you know very basic authorization logic maybe like an if or two depending upon if they're an admin
29:53
or not and the problem is that that grows over time so you become like oh in this in this case in this case so what
30:00
this language is really good at doing is starting off um with a policy set that
30:06
can expand over time without actually changing application codes the idea is you change your
30:11
policy uh around like what what you know what entities you're allowed in and and things like that but without changing
30:18
your actual application code to to achieve those results and then potentially having misconfigurations so
30:23
I think it's pretty good and effective at that um you can run it Loc or Ed are running a service called uh verify
30:30
permissions to do it for you um there's some uh slight issues in some like very
30:37
minor cases it's got some interesting language uh features and choices that are a bit suspect in my opinion U but
30:45
overall it's it's a pretty good um uh language or engine for the specific
30:51
Niche use case yeah yeah and it's it's interesting I mean the the kind of the use case that
30:57
you described there very much sounds to me like how our back has gotten I won't
31:03
say broken but it you kind of see the limitations of it over time and it's always with the kind of exceptions right
31:10
it's a um Ian is a member of the development group but he's also an admin
31:16
of this one workload but I don't want to add him to the admin group because then he gets admin on everything he's really
31:22
only an admin on whatever application and so then you think about this kind of combination of you know workload tags
31:29
plus permission sets and that's where I've seen a lot of people kind of move away from rback and in terms of aback um
31:35
but that's I think of that more on the infrastructure side so it sounds like with cedar when we talk about the kind of authorization that you're talking
31:42
about that's more application layer um application uh sorry application layer authorization uh yeah it's intended as
31:49
an auth doesn't have to be technically application layer but I think that's where they're mostly targeting so it's
31:55
about here's your entities here's your action your resource given all
32:01
those things here's a set of rules that apply to whether you're allowed or denied into a specific space it's very
32:07
it's very similar to IM but has none of the things that make that are like awsc
32:13
in I am I guess okay so it it's something that you could actually deploy anywhere not only on AWS or on apps that
32:19
you're running on AWS yeah that's the intention it's like I am but anywhere else yeah makes a lot of sense and you
32:26
know I work in the API security space and one of the common common problems in apis is
32:32
actually authorization um we will be releasing some research not too too long from now we're just kind of putting the
32:39
Finish finishing touches on some of it but authorization problems are responsible for the Lion Share of
32:46
Records breached um the we could talk about initial breach factors and other
32:51
time but authorization is like a huge huge percentage of it so hopefully this will help solve it for a a lot of those
32:57
use cases but also working on the API security space you know one of the things I get asked a lot is around wafs
33:03
and aren't wafs good enough to protect apis I noticed you had a post about kind
33:08
of beating a WF recently and it wasn't specific to apis but talk us through what you learned there and and you know
33:15
how did you program a work around to beat a capture yeah sure thing so uh this is actually round two I've blogged
33:21
about in terms of okay uh my involvement with the ABS we uh just we capture
33:28
feature specifically um in the first round I did a basically a Twitter thread on their
33:33
quote car maze puzzle uh and on the blog I've done uh a breakdown on their kind
33:39
of shape match puzzles so the idea is that ad provided this feature that gives new and creative types of capture not
33:47
just uh write what the text says or show me you know point to the buses in this picture or something like that it's
33:53
about trying to innovate in that space um but the I guess the main thing I've
33:59
gotten from this is that it is extremely hard to make challenges hard for computers but easy for humans and this
34:07
problem is only getting worse with the Advent of generative Ai and uh the like
34:13
the amount of um image recognition and audio recognition and all sorts of new features that we have available to us
34:19
now it's getting so so harder to differentiate um at a challenge um
34:25
tooling level to do this and so you kind of basically reverse engineered the
34:32
movements of the car through the maze um or I guess that was maybe V1 of your of
34:38
your programming but you kind of reverse engineered what the transformation was
34:43
from the initial puzzle to the final puzzle and kind of from that then extrapolated almost sounded like a bit
34:49
of triangulation from what I read to kind of determine the positional movement that led to solving the puzzle
34:56
yeah it was it was interesting in the car maze was all around uh here's a route that it takes on a map where would
35:02
it end up uh and and it was all about looking at uh the 3D geometry uh looking
35:09
at you know where colors were and making assumptions based on its movement IE can't drive back on itself and things
35:15
like that yeah so that was it's just it's a really interesting programming challenges with the shape match it's all
35:21
about uh matching top half and bottom half of shapes together and uh that one
35:26
was all about um lining up vertices from a basically per pixel perspective and
35:33
seeing trying every different combination see what actually fit and then making a bunch of rules and horis
35:39
STS around what is valid and what isn't valid in order to come the right answer
35:45
so and that's all program and that's all programmatic as well so it's it's you run a script and it's done in half a
35:52
second or whatever and you didn't find that you got blocked by trying to kind
35:57
of reverse engineer this due to volume of calls or frequency of calls or the you know things like that well well the
36:04
interesting thing is you can work on this offline in most the cases um for this specific Feature A lot of it is
36:10
around a very limited set of possible circumstances and things like that so
36:15
it's somewhat easy to work on it um even offline so basically just taking maybe 10 challenges or something like that and
36:22
bringing them offline um yeah but even like uh online if you if you do it
36:29
enough then sure you might get blocked for a few minutes or so but it's going to come back so yeah yeah humans make
36:36
mistakes just as much as computers so um there has to be sort of a leeway in both
36:42
both areas I mean arguably humans make more mistakes than computers right but
36:47
that's neither here nor there it's interesting though you know this is a um this is a challenge specifically
36:53
designed to prevent computers from solving it and yet what we find is you know it
36:59
doesn't take that much to find a technical solution if one can be found what's interesting for us and I mean not
37:06
to digress again on too big of a tangent but in our own testing in our Labs where we stand up apis on a regular basis for
37:13
you know pen testing security testing purposes we see a ton of automated traffic coming to them a lot of bots and
37:19
so on any protective technology that gets developed that gets widely enough
37:26
deployed will get automated against so if this W capture becomes a common protection
37:32
protection mechanism it won't be long before the hacker automation will also
37:38
have solutions to then solving these puzzles because we see the nature of the traffic that we see in the attempted
37:44
automated attacks clearly shows us that you know the Breakin capabilities are
37:50
there yep and it's even human labor sheap like yeah the common
37:57
the most common capture technology out there recapture you can get $2 per a thousand soles for that so like you know
38:05
that's going to be worth an attacker's time or to do it even at at Large Scale
38:12
um for for the benefit they get out of it and so I think what we really need to do is stop thinking about this as a
38:18
challenge problem and stop thinking about other solutions to this um to to
38:24
this problem so it things about thinking about what is the frequency of attacks what
38:29
are our IP ranges looking at botlike activity unrelated to the actual
38:36
challenge solution itself so using a combination of of these factors together
38:41
is what's going to help things over time yeah look and I mean from our
38:46
perspective I would I would double down on a couple of things which is you know building stronger authentication and authorization into your applications and
38:54
hardening your applications before they even go live whether that is eliminating third party vulnerability cve doing
39:02
stronger security analysis of your own source code and what you're building you know bug bounties whatever you can do to
39:08
kind of Harden your application structure and and kind of you know I would say avoid the avoid the mental
39:15
trap of thinking that you can protect away your problems by slapping a Band-Aid WAFF on top of it before it
39:21
goes live because I think there's enough evidence out there that ws can be defeated yeah awesome
39:26
well listen we we've kind of come up to the end of time and I want to thank you again for taking the time to talk to us today for sharing your experiences for
39:33
sharing the great work that you're doing you know as an AWS Community hero and all of the open source packages if
39:39
people want to contact you or look up anything um from the open source CER for your blogs where should they look yeah
39:46
sure so I'm available on Twitter LinkedIn or GitHub ATN
39:51
0036 0036 and that's your GitHub or your Twitter or your LinkedIn us said that's right yep awesome awesome and where's
39:58
your blog for your security research and my blog is at oncloud.com oncloud.com there you go well Yan McKay
40:05
thank you again so much for taking the time to join us on the modern cyber podcast we will talk to you next time thank you so
40:11
[Music]