Modern Cyber with Jeremy Snyder - Episode

Ian McKay of Kablamo

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.

Ian McKay of Kablamo

Podcast Transcript




all right welcome to another episode of the modern cyber podcast we are again coming to you from Down Under this week


and I am thrilled to be joined by Ian McKay who is joining us Ian is a cloud


principal sorry the cloud principal at kblo which is a cloud product development and data consultancy


specializing in building applications native to the cloud he's usually focused on cloud architecture cicd and security


but is always trying out the latest cloud services between helping clients he loves the chance to build open source


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


enjoys speaking at meetups co-hosting podcasts engaging with the community on slack and posting his latest experiences


within the cloud on his blog couple of the projects that you may know Ian from our console recorder former 2 I am live


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


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


appreciate you taking the time to join us today thank you so much for having me Jeremy awesome awesome well I've got a


bunch of things that I want to get into today and definitely want to talk about some of your open source projects but


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


is building Secure Solutions for customers with strong Regulatory Compliance requirements and I'm curious


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


you've learned over the years around kind of let's say like walking the fine line of moving quickly in the cloud but


then staying compliant what what are some of the things you've learned yeah I think for me one of the main lessons


I've learned as a consultant is that every customer has very different needs very different requirements and levels


of like technical competence a lot of customers are really far along on their Cloud journey and experiencing


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


get them through so it's about uh I sometimes have to change the way I talk


to uh my customers to figure out you know what what would best suit them in


in their specific use case so you know not to kind of oversimplify it but is it


fair to say that you know got some customers who have let's say maybe just executed the lift and shift and haven't


really embraced Cloud Ops as we might think about it today and those that are Al then at the other end of the spectrum


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


there's a lot of customers that have still in that server full mindset of uh having their pets in the cloud and


things like that and not embracing uh immutable infrastructure things like that and there's some customers that are


really at the bleeding edge and doing some really interesting uh Cloud native style


applications well I'm curious for those that are at that bleeding edge and building kind of cloud native and you


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


the of the spectrum how do you talk to them about balancing speed and


compliance because they're probably because they are at that know Edge they're probably used to moving really


quickly yeah usually it's really about uh having a discussion with them


about their risk tolerances so I always find it really helpful to go through that uh standard


risk Matrix about what is the likelihood of a specific uh risk or incident


happening versus the impact that it has and that really helps me understand how


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


are very happy to even have you know production downtime or things like that


and a lot of customers will spend uh six months testing a uh a deployment just to


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


establishing the boundaries within the cloud environment between your different environments helps them achieve some


sort of a balance between their and their stable stability um so having


lower environments having being a little bit more agile maybe allowing more permissions to do to interact with those


sort of environments and then taking a hands-off approach in those higher style


environments and in along those lines do you find that there is a firm


understanding about where security and compliance overlap versus where they diverge or do you feel like that


conversation gets like gets pretty blurry for customers that are like moving quickly but do have strong


regulatory requirements yeah so there's there's always this I guess conflict about what


they have to do for their Regulatory and compliance programs uh things like ISO


27 K1 sof 2 Etc and uh even even their own internal programs uh versus what


they uh can achieve I feel like both program both uh the companies and the


compliance programs are really doing very good job at covering off all the major areas and especially with the idea


of regular enforcement so making sure that not only are their controls in place but they're being tested and


they're going through it all the time what I find uh they sometimes fall down


uh on is practicality so okay having Auditors come in and not really caring


about how controls are met or when controls are met in a non-standard way


uh and they sometimes get confused or or disagree that specific needs are met despite the organization really doing


the leg work and saying no yes we've done we've done all this uh work to make


sure that this is uh covered off um so it's a little bit of inconsistency with


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


about that inconsistency I mean first of all kind of the graduated scale of risk


tolerance for different environments right so if we think about to your example you know tolerating a a somewhat


higher level of risk in let's say Dev test or even in staging environments where we might not have customer data we


shouldn't have customer data right and we also um probably have some kind of


network uh Network layer controls that maybe don't make those environments public they're only for internal usage


they're only for internal testing Etc maybe staging has some external exposure


to kind of simulate what public uh attacks against an environment might mean from a security perspective but one


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


the stack into production environments can lead to a somewhat disjointed experience where you know you have it


where customers come to expect a certain level of access in an environment and then as you get stricter and stricter


that can be hard for them to internalize in their operation you must have gone through a similar


Journey with certain customers how did you explain to them like no no no the controls are this for Dev this for prod


and here's why I think the way that I I tend to pitch this is about their own


protection and always working within uh their guidelines and their requirements to get as


much uh understanding and access that they can achieve without then compromising them so I'll always ask


what is the main pain points for your developers or what what are you seeing


that is is causing costing you a lot of time and we'll try and work around those things with various different tricks and


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


access because then you're liable for this um and sometimes that's a hard


conversation to have but it's a conversation that we need to do yeah and do you find that you've been able to


develop some of a templated approach to this over the years where you can maybe like go into a customer you know have a


conversation with them to assess what the risk tolerance level are is assess what their um regulatory requirements


are and then maybe come out with something of a blueprint for oh okay you need Landing zones that look like this


you need an AWS org that looks like this with these service control policies and maybe control tower to deploy this set


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


customer engagement that you go into yeah so we definitely have a lot of uh


bootstrap templates and things like that uh a lot of that vary in complexity based on the customer we


technically or we usually know the level of competence with a customer kind of walking in the door so we can start the


conversation pretty well on there um as we start and then manipulate that from there


um but yes absolutely we have a number of different approaches um that we take internally and that's good for our own


standardization as well so when we're handing off to support teams and things like that if we're supporting a customer


post production then everyone knows what it kind of looks like everyone sees the same patterns the same places to look


and so it's a lot easier to triage and debug issues and do you find I mean one


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


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


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


cloud if they haven't baked security into let's say the designs of their account structures or their uh


permissions boundaries or things like that it can often be easier to you know kind of start fresh with a new


organizational structure and again the service control policies and whatnot that we talked about and then actually do a cloud to Cloud


migration is that something that you run across a lot or you find that now most of the time for customers if they've


kind of started that migration Journey they really want to kind of retrofit clean up the environments that they're


working in already usually we would get to that point where it's already that


far gone so if we can usually retrofit an existing architecture Within you know


reasonable uh means to to get it to where it needs to be uh we did this a


lot when uh Ed control tower came out and that had a bunch of standardized


practices and now we had to figure out what is the customer actually doing versus what is the service providing and


then uh kind of retrofitting that in which is uh its own set of challenges but


usually the types of customers that we speak to are usually engaging in either green projects or don't have the


technical level of Competency that they want to have any say in it whatsoever so you will usually come in and dictate to


them this is your ground workor layer these are your guard rails Etc uh and they're they're very happy


with that because they're taking that subject matter expertise from us um to


make sure that they are secure in the way they work yeah this is one of the things that we found pretty consistently


over the last I guess eight years or so that I've been working on cloud security is that


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


for somebody to come in and help kind of dictate uh require to them because it


can be very informative right if especially if they're coming out of let's say Legacy data center type of


architectures um they may often have a strong focus on let's say perimeter oriented security and monitoring as you


know the the next kind of pillar of of a security strategy and monitoring can be


particularly challenging in very ephemeral environments where things are changing on a regular basis you know


installing the agent or even if you're not using um an agent full service but


you're using an agent list service um assigning the ephemeral infrastructure


to the workload so that you can have a consistent level of monitoring over time all of that can be very challenging if


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


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


code especially if you are doing a lot of ephemeral things um with agentless architectures so um you I guess built


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


across as one of your open source projects I mean talk to us a little bit about it what was the origin story what


problem did you set out to solve sure so I guess forward to is the second in a


line of products that uh I've primarily built and maintain uh the first of which


is called console recorder for EDS uh that that first one console


recorder for EDS was actually built out of my own frustration of uh I can actually tell you the exact call it was


medialized create channel call which if you look at the Botto docs for like six pages long or something like that just


massive amount of parameters and things like that that I needed for that and I found myself uh going into the network


tab of the console to trying to figure out what exactly are these parameters and figuring out how my console actions


are mapped to uh what these AI calls needed to do and so I took that as an


idea and made uh with the F the first uh product called console recorder for ads


which is a browser extension which records the actions you take within the Eds console and then converts that to uh


Botto 3 or cloud or terraform and things like that and so I wanted to generate


these um uh infrastructure as code or even just scripts so I could so I can


understand what the console is actually doing uh and that turned out to be very popular but the common ask I got from


that was well I've already had uh my employee over there create this infrastructure or I forgot to PR press


record because it's a very live thing yeah what about my existing resources and that's why I've moved from that


project into Forma 2 which I currently maintain today and Forma 2 basically does a scan of your account so that's


the list and get calls this is done entirely locally so there's no server that I manage or anything else like that


it's just um it's a your your PC to EDS endpoints and basically again through a


browser Plugin or it's basically just through a website so you can just view a


website as a static website uh and you can see the calls that going out to uh


the ads website to the ads end points you provide credentials and things like that and it'll okay go and pull in that


data and it takes those list and get calls and then converts that again to your infrastructure as code your Cloud


information terraform uh palumi cdk things like that so that you can figure


out what you've created in the uh EDS uh environment so that's by C or


by uh not just clicks but like API calls or things like that and then start to


convert that into your infrastructure's code so you can have that immutable uh


stack based uh design um which is I think a super effective tool not only


for uh taking your uh click Ops work and bringing it in but also educating


yourself on uh what specific fields are doing what in the environment and you


know when you might not necessarily know a property or something like that in your infrastructure is code that's a


really good to figure that out and does it take into account the order of operation so if I'm you know building a


classic three- tier architecture database app server web server um or you know web layer whatever that ends up


being uh I know that you know the the RDS instance needs to come up first so


that there is a database server that the app server can connect to and instantiate the database tables or


whatever the exact sequence of operations is that's all kind of built into this former two um approach yeah


absolutely so either within terraforms attribute controls or with cloud formation intrinsic functions that your


ref and you'll get at it basically looks at the known uh outputs whether that's IDs and


Arns figures out that that's actually present in another resource and then automatically does the mapping for you


uh which is an interesting programming challenge to solve basically like writing out the graph of the thing you


just scanned um but once I got it working it's super effective and um yeah


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


really interesting to me that you use the word graph when you're talking about that because I know there is there's a


few of us who have been in the club Community for a long time I'm sure yourself included that tend to think


about workloads as actually being collections of resources with these intrinsic connections to each other and


all of that being represented presented by a graph and that graph concept is increasingly being adopted on the cyber


security uh side when you think about things like one of the most modern I say


modern and kind of air quotes here but one of the most common ways that people are analyzing their Cloud security


posture right now is through a combination of attack paths and blast radiuses right and an attack path is


kind of you know from let's say a vulnerability on an ec2 instance x what


else can I get to or what is the path towards exploiting an environment and then the blast radius is kind of you


know the maximum exposure from that was Security in your mind when you


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


focused on the infrastructure side of it yeah I think when I was creating it I was focused entirely on the


infrastructure security was on my mind in that I knew that I personally would never uh or would be reluctant to give


access to my cloud environment to third party vendors and things like that so I actually went out of my way and it's


actually really annoying to uh have it such that this is a static thing that I


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


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


always in my mind but as as far as the idea of visualizing infrastructure in a graph I think that's one of the


fundamental things that really helps your understanding of infrastructurist code


when you get into that space because it starts to make you think about the


relationships and the life cycle of events uh one of the biggest questions


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


it really comes down to the life cycle of your infrastructure if this is a static style infrastructure yeah


everything that relates that piece of static um material so that might be a database or something like that should


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


things like that it should be separate um as far as the stack management side of things goes because you don't want to


have those two things be affected in the same way yeah but but I'm curious along


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


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


hundreds of customers about Cloud security and their overall Cloud security strategy I've seen kind of two


approaches right and so one is two general like high level approaches so one is more the kind of um you know


command and control and you kind of can't do it unless it's explicitly allowed and you can think of that as


kind of the service catalog type of approach Etc one of the other approaches that I've seen within larger


organizations that are fast moving um and maybe I should qualify like my experiences are usually with larger fast


moving Cloud environments the the other approach that I've seen is kind of guard


rails that usually take the form of we've laid out a VPC structure and we've


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


can't really break outside this VPC structure you can't really violate permission sets that we've applied from


these I you know kind of known good I am policies we feel safe as an organization


from a risk management perspective like when you think about these Stacks do you usually think about Stacks incorporating


vpcs and am roles and so you really want to like build up the entire network and


I structure for the stack or do you think about them using something out of let's say a known good collection of


network and um identity um kind of templates yeah we usually take the


Approach at least within my company of doing the guard rails approach of having


a bunch of borders around what you can and can't do um particularly with things like Security Services that you can't


touch but having giving them the freedom to do whatever they need to do to solve


their workload I don't think the the problem with the service catalog style


approach is that you run into this limitation where you become the single


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


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


it's on you to develop that and that can be a huge BTL net for the organization


so definitely take that guard rail style approach as often as we can yeah yeah


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


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


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


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


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


point if there's not a service catalog offering for the brand new media service


that AWS just launched or whatever you know you're you're going to fail at some


point because either the developers and the people who own the workloads get so


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


AWS account whatever or you know they do something that's completely out of your control which I guess that kind of that


that example kind of is so um awesome now um you have a couple of other uh


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


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


live is a uh go application that basically intercepts your calls um from


your local environment or from your Cloud environment perhaps um on the way to ads endpoints and then generates a


set of least privileged IM policies for what you're doing um with with those


services so you can put that as a client side monitoring or just a sort of man


in-the-middle proxy approach yeah uh and whatever the whatever calls go out to


the Eds endpoints during that egress you're looking at those calls and then


I'm basically generating a least privileged template of Y um of the am


permissions that would be needed to do that again uh and so this is really uh useful for generating like I said leas


privilege policies um without saying you know star star administrator access


whatever um so you can really scope down what you need to do um one of the and


you it's always funny when you release tools you never really how they going to be used by the


community former 2 has been used as a uh sort of a whole account like 8 account


catalog tooling without the um the infrastructures code as well so you


never really understand how how that might work and I am live is uh very


frequently used to generate terraform lease privilege uh roles so like oh


interesting ter makes calls to the edus endpoints in order to do its actions but by doing that we can intercept those


calls and figure out if I was to deploy this uh in a cloud account for example


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


of work around using it in that use case well it's interesting because as you were describing it the use case that


popped to my mind was um local application development but using like


AWS backend say like S3 RDS Dynamo whatever kind of like the for for the


long-term storage of the data that my app is collecting and then you know narrowing permissions between whatever


app service I'm going to use whether Lambda some container or ec2 and those


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


original intention was but that's how I saw it being used because otherwise I do to your point I see developers all the


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


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


hardest areas within Cloud to get permissions and identity access right


and the guidance around it is still lacking in some way yeah there


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


complex thing to work on um to do it to the point where you


can El eliminate you know potential lateral movement and things like that should your application actually get


compromised and and you don't find that the um the IM am policy generator is I


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


to get to the level that you need to be to be proficient what I would consider


proficient in it enough that you can protect yourself adequately because there's so many gotas things like the


confused Deputy problem is not well understood within the uh the cloud community at all and it's I think it's a


Time BMB waiting to happen yeah um we've only got a few minutes left and I know


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


and I data set what would you want to tell the audience about those yeah sure so the IM data set is basically that


mapping of apia actions to IM permissions it's being used to drive IM


live and permissions cloud is basically uh a web front end so it's permissions. Cloud as a website uh that you can use


to view and inspect that data set so you can understand what permissions would I need if I was to do this API action


without actually doing it with your local environment gotcha gotcha awesome


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


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


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


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


curious whenever I see yet another policy language I mean I think there's even an acronym for what is it Yara yet


another rule um language or something like that like did we really need another policy language have you played with it what


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


specific niche of that very common problem of I have a simple uh


application that has you know very basic authorization logic maybe like an if or two depending upon if they're an admin


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


this language is really good at doing is starting off um with a policy set that


can expand over time without actually changing application codes the idea is you change your


policy uh around like what what you know what entities you're allowed in and and things like that but without changing


your actual application code to to achieve those results and then potentially having misconfigurations so


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


permissions to do it for you um there's some uh slight issues in some like very


minor cases it's got some interesting language uh features and choices that are a bit suspect in my opinion U but


overall it's it's a pretty good um uh language or engine for the specific


Niche use case yeah yeah and it's it's interesting I mean the the kind of the use case that


you described there very much sounds to me like how our back has gotten I won't


say broken but it you kind of see the limitations of it over time and it's always with the kind of exceptions right


it's a um Ian is a member of the development group but he's also an admin


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


only an admin on whatever application and so then you think about this kind of combination of you know workload tags


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


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


about that's more application layer um application uh sorry application layer authorization uh yeah it's intended as


an auth doesn't have to be technically application layer but I think that's where they're mostly targeting so it's


about here's your entities here's your action your resource given all


those things here's a set of rules that apply to whether you're allowed or denied into a specific space it's very


it's very similar to IM but has none of the things that make that are like awsc


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


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


know I work in the API security space and one of the common common problems in apis is


actually authorization um we will be releasing some research not too too long from now we're just kind of putting the


Finish finishing touches on some of it but authorization problems are responsible for the Lion Share of


Records breached um the we could talk about initial breach factors and other


time but authorization is like a huge huge percentage of it so hopefully this will help solve it for a a lot of those


use cases but also working on the API security space you know one of the things I get asked a lot is around wafs


and aren't wafs good enough to protect apis I noticed you had a post about kind


of beating a WF recently and it wasn't specific to apis but talk us through what you learned there and and you know


how did you program a work around to beat a capture yeah sure thing so uh this is actually round two I've blogged


about in terms of okay uh my involvement with the ABS we uh just we capture


feature specifically um in the first round I did a basically a Twitter thread on their


quote car maze puzzle uh and on the blog I've done uh a breakdown on their kind


of shape match puzzles so the idea is that ad provided this feature that gives new and creative types of capture not


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


about trying to innovate in that space um but the I guess the main thing I've


gotten from this is that it is extremely hard to make challenges hard for computers but easy for humans and this


problem is only getting worse with the Advent of generative Ai and uh the like


the amount of um image recognition and audio recognition and all sorts of new features that we have available to us


now it's getting so so harder to differentiate um at a challenge um


tooling level to do this and so you kind of basically reverse engineered the


movements of the car through the maze um or I guess that was maybe V1 of your of


your programming but you kind of reverse engineered what the transformation was


from the initial puzzle to the final puzzle and kind of from that then extrapolated almost sounded like a bit


of triangulation from what I read to kind of determine the positional movement that led to solving the puzzle


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


it end up uh and and it was all about looking at uh the 3D geometry uh looking


at you know where colors were and making assumptions based on its movement IE can't drive back on itself and things


like that yeah so that was it's just it's a really interesting programming challenges with the shape match it's all


about uh matching top half and bottom half of shapes together and uh that one


was all about um lining up vertices from a basically per pixel perspective and


seeing trying every different combination see what actually fit and then making a bunch of rules and horis


STS around what is valid and what isn't valid in order to come the right answer


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


second or whatever and you didn't find that you got blocked by trying to kind


of reverse engineer this due to volume of calls or frequency of calls or the you know things like that well well the


interesting thing is you can work on this offline in most the cases um for this specific Feature A lot of it is


around a very limited set of possible circumstances and things like that so


it's somewhat easy to work on it um even offline so basically just taking maybe 10 challenges or something like that and


bringing them offline um yeah but even like uh online if you if you do it


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


mistakes just as much as computers so um there has to be sort of a leeway in both


both areas I mean arguably humans make more mistakes than computers right but


that's neither here nor there it's interesting though you know this is a um this is a challenge specifically


designed to prevent computers from solving it and yet what we find is you know it


doesn't take that much to find a technical solution if one can be found what's interesting for us and I mean not


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


you know pen testing security testing purposes we see a ton of automated traffic coming to them a lot of bots and


so on any protective technology that gets developed that gets widely enough


deployed will get automated against so if this W capture becomes a common protection


protection mechanism it won't be long before the hacker automation will also


have solutions to then solving these puzzles because we see the nature of the traffic that we see in the attempted


automated attacks clearly shows us that you know the Breakin capabilities are


there yep and it's even human labor sheap like yeah the common


the most common capture technology out there recapture you can get $2 per a thousand soles for that so like you know


that's going to be worth an attacker's time or to do it even at at Large Scale


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


challenge problem and stop thinking about other solutions to this um to to


this problem so it things about thinking about what is the frequency of attacks what


are our IP ranges looking at botlike activity unrelated to the actual


challenge solution itself so using a combination of of these factors together


is what's going to help things over time yeah look and I mean from our


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


hardening your applications before they even go live whether that is eliminating third party vulnerability cve doing


stronger security analysis of your own source code and what you're building you know bug bounties whatever you can do to


kind of Harden your application structure and and kind of you know I would say avoid the avoid the mental


trap of thinking that you can protect away your problems by slapping a Band-Aid WAFF on top of it before it


goes live because I think there's enough evidence out there that ws can be defeated yeah awesome


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


sharing the great work that you're doing you know as an AWS Community hero and all of the open source packages if


people want to contact you or look up anything um from the open source CER for your blogs where should they look yeah


sure so I'm available on Twitter LinkedIn or GitHub ATN


0036 0036 and that's your GitHub or your Twitter or your LinkedIn us said that's right yep awesome awesome and where's


your blog for your security research and my blog is at there you go well Yan McKay


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



Discover all of your APIs today

If you can't see it, you can't secure it. Let FireTail find and inventory all of the APIs across your organization. Start a free trial now.