AWS Simplifies Security While Complicating Vendor Choices

Anyway . So let's jump right into the news .

So the big news that happened really recently , actually just the last couple of days , is that HPE and Juniper have been given the go ahead or sorry , HPE has been given the go ahead by the Department of Justice to acquire Juniper $40 a share , so about $14 billion , and the big difference , or the change that allowed this to move forward , are two things .

One is that Juniper has to divest itself of the Instant On branch and wireless portfolio , which , I'll be honest , I don't even barely remember . Instant On , I don't even barely remember instant on . I don't know if it's like a ubiquity thing or whatnot ?

So , given those two concessions , I guess . So now HPE is able to buy Juniper . And I was telling Chris , before we hit record , that my financial advisor , literally two days before this was announced , had just told me hey , let's get out of HPE because this deal is stalled and we can make more money elsewhere .

So that's life , that's the stock market for you and that's life . Um , that's , that's the stock market for you and that's life . Uh , yeah , that's that's interesting . Anything , oh my God . January 9th 2024 is when this was originally announced . I can't believe it's been that long .

The open item here is that if they go through with this , you know kind of licensing of the source code , like who knows who's going to get be able to get access to it , right .

So I think we kind of went through this a bit in that the the main reason we thought that you know this was even being acquired by hpe was for the you know the miss ai ops technology , right , that was kind of the , the meat of it , right .

And if that is the part that has to , you know , basically be um put to you know , basically be put out to you know the source code put out to a license . You know Cisco could buy it . Any number of the competitors could buy it .

Don't know what to degree they would want to integrate it based on , you know , their existing portfolio and their existing technology , et cetera . But if the I don't know like it's , like , on one hand hand I could see like , oh , this is huge , like the . You know Cisco could buy it and then it would just be a completely level playing field .

But I don't think that Cisco would buy this and be able to integrate it at any degree . So it's like I think the idea is to level the playing field , but it just like no one would go through the effort of that . Uh , at least from from my perspective .

I think it because that's going to answer the question of who would really Already I'm with you , I don't think Cisco , cisco's got the what is it ? Deep network or whatever that they're working on their own model , which probably is built on Splunk's data .

So yeah , I'm with you on that I don't think the big players would probably truly license it for real reasons , maybe competitive intelligence or something . Yeah , I think the question is how much ? What does limited really mean in this context ?

finished . Now , honestly , I wasn't able to keep up with Reinforce at all this year . I know , chris , you did quite a bit of watching on the keynotes and all of that , so you want to tell us a little bit about what happened this year at Reinforce .

So I watched a few of the keynotes and I watched some of the sessions as well , just to kind of stay up to date . And you know there was definitely some themes that I saw coming out from this particular reinforce in that the . You know they kind of went back to talking about the kind of the traditional stuff about .

You know , security usually slows down innovation et cetera . So it needs to be , you know , directly integrated and easy to consume et cetera , not kind of stifle that innovation piece .

But then you know they also talked about how it's from what they've seen they being AWS that you know companies with a more kind of mature security practice in place are able to actually adopt generative , generative ai a bit faster than other companies . Um , so you know , kind of reinforcing the importance on security .

You know , if that kind of foundational element is there , um , then you know that you should be able to consume ai at a faster pace than than typical um enterprises , or you know businesses , etc . Um , you know businesses , et cetera . You know they wanted to reinforce that security should become a competitive advantage and not a cost center .

I mean , I don't know . I feel like any kind of conference you go to where , whatever is the theme , whether it be a networking conference or a security conference , they're going to be like we need to stop being a cost center . At the end of the day , you're probably still a fucking cost center .

I don think you ever think you ever get away from that , uh , in the grand scheme of things . But , um , there was some interesting stuff that um , they talked about in regard to comcast .

And you know kind of comcast , um , you know kind of they have this you know cyber security team with thousands of people , um , and their ai adoption has , you know , kind of increased a lot of their security findings over the last I'd say last year I guess and apparently they're building tons of AI bots for things like threat modeling .

It's contributed to a good deal of their patents that they've published as well , which I thought was quite interesting . And I think they have this kind of like seven year North Star type strategy to get , you know , everything adopting AI .

And that's where the challenge came in of security being this cost center , whereas it should be , you know , kind of used for innovation , et cetera . So it was . I think there was a strong emphasis as well on proactive security rather than reactive security and leveraging AI obviously to do all that .

You know AI is obviously going to be kind of peppered into everything . So that was kind of my overall rub of the general theme of the conference . So , yeah , it was quite interesting .

I mean , this is the , this is the thing , though , if you , if you are a , if are a non-CSP provider of services to CSP customers , you really need to be paying attention to your moat , and by moat , of course , what I mean is what makes you differentiated from the CSP . I mean moat in the

traditional business sense , basically , like the traditional business sense . Basically , what is the , what is the , the thing you are defending , the , the , the IP , the , the use case , whatever that is that , um , you know , makes your company essentially viable as a company .

You know and , uh , you know I'm saying that with my , the own , my own self-awareness that I work for .

You know , I work for a company that's that also offers , you know , kind of third-party services line on the CSPs , but that's something that's been top of mind right For us as well , because the CSPs are going to continue to innovate and to bring new services , and it's going to be based on in my experience , it's been based on two things right , who's asking

for it ? Right . And then how much money is involved , which makes perfect sense , right ? If you're a CSP or if you're any kind of business really ? I mean , cisco does the same thing , like every company that offers something to customers is asking the same questions , right ? Who wants it and how much are they willing to pay for it ?

So , anyway , let's go through some of the announcements here , actually , and you'll kind of see what I'm talking about . Let's see the first one here is unify your security with AWS Security Hub for risk prioritization and response at scale . This is a preview feature .

This was announced and this is in preview , but it seems like it's just a , and we'll have , of course , all the links to the stuff in the show notes . So there's some visuals here , there's some workflows and whatnot that you'll want to go through and take a look at yourself , but the basic idea of the security hub seems to be that it is a .

What do they call it ? Because there's so many of these . I don't know if it's a CSPM itself , but it's basically a threat correlator analyzer and like surface insights from other services .

They're running on aws and kind of correlating all that together and , you know , building this kind of like map for you and offering remediation techniques etc .

So , like I said , take a look at the , take a look at the threat , the visuals that go along with this .

Again , we'll have the posts and you can really get an idea of , like , what they're talking about , when we're talking about , like you know , ingesting the feeds and surfacing the insights and giving you kind of that , that overall view of your , your network not network , sorry your cloud environment , just kind of based on all of those services .

So , of course , it also means that the value of this service is going to be based on how many of the other AWS security feed services you are leveraging , right , like Macy and Inspector . So there is kind of you know , tongue in cheek there . It is going to be as useful as how much AWS security feeds you're already bringing into it , right ? Yeah ?

Network Firewall . So one thing that they also touched on was something that is called . What is it ? I always bury the names in these things . You can never actually find what it's called Active Threat Defense for AWS Network Firewall .

So basically , if you can think of kind of the AWS managed rules that you have within AWS Network Firewall or even something like a WAF , where basically there's common things , the common exploits , et cetera , that are well-defined in a rule set that AWS manages , and you just basically invoke that and use it on your traffic , this is kind of the same thing , except

typically they call out that customers are commonly looking for third-party threat feeds to get pull-in sources of threat intel , et cetera , and so this looks like they've enabled that to run with their own threat intelligence system , which is called MadPot , which I think they've been using for quite a while .

I think they started this around 2010 or something like that . So basically kind of the same thing . You have these active threat feeds that are managed by AWS in conjunction with MadPot and you have to do things like deep packet inspection et cetera on the traffic .

For this to really take effect , they have something called deep threat inspection built into this as well , which is labeled as collective defense , and it enables shared threat intelligence improving protection for active threat managed role group users . So I don't know if that means it's shared . That one kind of confused me .

I couldn't really tell if that means it's shared amongst like other organizations , or just like shared in terms that AWS manages . I wasn't really sure about that .

Um , I don't think your specific data is going to be shared between rule sets or anything like that but I think the the day you know the data that is ingested and you know , learned by um , the data you push through could potentially be used for another customer . I suppose um yeah , I think that's what that comes back to I agree .

Starting out , it looks like this is you know you're going to pay about half a cent per gigabyte that you use these specific rules , so kind of leaning towards things like IPS et cetera in this kind of service with AWS's own threat feed .

Yeah , we talked about this before we hit record and obviously turning on certain things like this usually impacts performance , but with this being an auto-scaled service enabled by things like AWS Hyperplane et cetera , I wonder if this really does have any impact on that , especially since they're charging you for it , right ?

So they probably want you to funnel as much as you can through this thing , because you're going to definitely pay the piper at the end of the day , right ? So , yeah , that was a new one that was added . I thought that was pretty cool . Anything to add there , Tim ?

It also mentions at the very end it's a little bit of a buried lead because it kind of leaves some questions . Another consideration is the mitigation of false positives .

When you use this managed rule group in your firewall policy , you can edit the rule group alert settings to help identify false positives as part of a mitigation strategy , and there's a whole thing about mitigating false positives . So remember that this is a threat feed , like a threat intelligence thing .

So you know , depending on what your business is doing and what you know , maybe your homegrown applications or whatever that be , it's possible and they point this out that like , oh , by the way , as you're pushing data through here , you know you might , whatever you're doing , might , light this thing up like a Christmas tree and be and be perfectly safe , but so

so , by the way , you know , at the very end you might want to do some work on making sure that you know how to mitigate these false positives . So that's , that's it . Otherwise , yeah , yeah , this is this is just one more piece .

One thing , one question I did have that was a little very tongue-in-cheek , was I was thinking of the uh that report from uh cyber ratings earlier . Yeah I was like is this gonna be an extra percent on the , you know , on the ratings ?

I guess we'll see next year what cyber ratings has to guess we'll see next year what Cybratings has to say , we'll see if they play nice .

But typically when you'd want to deploy AWS Network Firewall as a native service isn't already natively integrated but typically when you'd want to deploy AWS Network Firewall you would have to .

Essentially , either you could put it in every single VPC which a lot of customers do that if they are willing to pay that particular price for it but what most customers would do is put that into a dedicated security VPC which kind of hangs off of your TGW and is either used for all your east-west inspection or north-south inspection , et cetera .

This actually removes the need for that , which totally makes sense under the hood . Like I'm kind of surprised I didn't do this sooner . But basically you can , as you're creating a network firewall , you can just natively attach it to a TGW .

So you're not creating a VPC , you're not creating endpoints , you're not doing all this stuff , you're not updating route tables et cetera .

It's just a native integration which is really cool and probably gonna be removing quite a bit of complexity , I would imagine , which means that the people that are typically they are managing complex stuff have one less job to do , which is not great for us , but it seems to be that's where they're leaning . So I just thought this was .

It was kind of a cool feature that they added . I wonder if they'll end up adding this type of integration for for third parties , but I highly doubt it because it's AWS . But we'll see Anything to add there , tim .

Consider considering the actual work to build an inspection VPC and build the network end point or the firewall end points and orchestrate the route tables and all that . There was literally no reason AWS couldn't just have and they did now right , make it completely and transparent to the users . So will this drive adoption ? I am interested Same reason as before .

I'm thinking of that cyber ratings report and some other things . You know , at the end of the day , it doesn't matter how useful . You know how easy it is to get traffic to a firewall if it's not effective . But I don't know . Like we'll see , like are people finding that the firewall is effective ? That's one thing I still haven't heard .

So what I think we'll see is more adoption and hopefully , with more adoption , we'll see more data on how effective AWS Network Firewall , the native integration , is . I think this piece with the TGW is just an ease of use , an uplift for usability , to drive adoption , but I think it's ultimately going to be a good thing .

one . This is interesting . This is another one in preview , and this one is called AWS Shield . It's funny because it's called AWS Shield . I was looking at this , we were talking about this beforehand .

It's called AWS Shield , or they've now named it officially AWS Shield , but before that it was either before that or they're still calling it the Network Security Director . It's actually AWS Shield , network Security Director . It's a preview feature and it's basically what would you call it . It's a preview feature and it's basically what would you call it .

It's like CSPM , basically for your network is kind of what it is right , I could agree , yeah .

Yeah , it's made to scan your network deployment in ADBS and first of all identify holes like that you've been permissive or that you have allowed , like maybe your security groups or TGW or something it mentions specifically like oh , you left your CloudFront distribution connected open to public and stuff like that .

So it goes through your environment , finds network problems but also maps them this is the part where the real value comes in maps them to kind of known security , where the real value comes in , maps them to known security , vulnerabilities , exploits , problems .

So think of the thing we just talked about a little while with the security hub and then make this like it's a little bit like that , but it's specifically focused on all the network implementation stuff , so like WAF , cloudfront , tgw , security groups , all that good stuff .

So again , this is another one where we're going to have the links in the show notes , because there's a lot of visuals that are with this to kind of visualize for you what that looks like . What does the security director sorry , what does the network , the AWS Shield director look like ?

Because there's a lot of questions that I can't really explain very well in a voice , but if you look at the screenshots it'll kind of answer the questions about , like what is the value ? What does this do for you ? What is this fine for you ? Yeah , so another one where I really feel like this is they're coming after yeah .

So another one where I really feel like they're really coming after third-party type of things that do this today .

But I feel like this is AWS , is like they're releasing new things that are useful , but they're doing it in a very AWS way as well , where they can't help but release like five or six different products that still all kind of do the same thing .

Like there's still like there's still not a lot of clarity for me around when you would specifically go to this versus that .

But if you were relatively new to the industry , I would feel for you very much , because you would probably read these and be like what the hell these all do the same thing . Yeah , so it's , you know very , very small details built into this . A lot of them build out these kind of you know maps , which are very useful , kind of mapping .

You know this , you know this service then talks to this and this . So you know known exploits here and there . You know there's even severities . You know whether they're critical or you know low priority , et cetera . But yeah , it's like all of it's still slightly confusing to me , um , but yeah , well , uh , like you said , eventually we'll see if this gets used .

If it doesn't , they'll axe it and then we'll never see it again , but we'll see , it's very , it's a very aws thing .

The org chart here where you know , like these people are working on things and the products that they're shipping essentially match the organization charts , meaning , like you know , you're having these different orgs coming up with these different things and anyway .

So I think that's got to be part of why we have these , because you would think what I would have thought is that you would take this functionality and just put it in this thing that the SOAR , you know , the security hub that already has all of the other threat intelligence and feeds that are coming into it for surfacing of vulnerabilities .

But yeah , so we will see . Time will tell on how this is differentiated , and it's also possible . I don't know , it depends on what's in here . Maybe there's just too much in here to put it in the other one , I don't know right . I do feel like it's more about shipping the org chart in that case than about truly differentiated services .

And then there's one more on top of this that's to point out , which is the Hold on . I just had the IAM Access Analyzer . So this one is similar to the others , except it's focused on IAM and it does exactly what you think it would do . It goes through all of your IAM roles , resources and services for overly permissive IAM access .

So I know there are entire products , third-party products that are probably going to be unless they're multi-cloud products which they probably are are going to be in trouble . But yeah , so there's not a lot to say about the IAM Access Analyzer .

It's pretty short actually , but the idea is go find overly permissive guidelines or overly permissive access , rather Surface it and then remediate it . It's pretty short and sweet actually .

So this is , you know , potentially going to be majorly impact those that are using those services , in that , you know , under the assumption that AWS can do this any better To your point , the products out there that probably do this from a third party perspective are probably multi-cloud and their consumers are probably multi-cloud , so switching whole hog to this is

not really an option . But you know , that's the thing . That's the problem with being multi-cloud . Right , the organization is going to automatically determine what level of complexity and , you know , number of tools that they are willing to use to get the same job done in different environments , right ?

Um , so I mean looking at the pricing , I'll be honest , I don't know how their competitors would typically price this stuff out , but , um , it seems like aws monitor like charges based this , not based on the im roles , but based on the resources um the ones they're looking at . Yeah yeah , so this could I mean .

I , I guess you're going to have way more IAM roles . I don't know , actually that's a good question . I don't know if typically customers would have more IAM roles or more resources . Um , I can honestly think of examples where it would be .

You know one or the other , like I know customers that have built millions of IAM roles , um , or you'd probably want a product like I know customers that have built millions of im roles , um , or you'd probably want a product like this to clean all this shit up . Um .

And I also know companies that have , you know , done very strict im roles that are that are not , you know , kind of bountiful in quantity . I should say um . So I guess it depends , um . But I mean , if you're single cloud aws , I don't see why you wouldn't use this . It seems relatively cheap , cheap to do so . Yeah , it seems a bit like a no brainer .

Another thing that kind of surprised it took this long to come to the table , if I'm being honest let's see .

But now you have the ability to actually export your certificates from ACM for use in other locations , right On-prem , other clouds , wherever you would need the ability to leverage that certificate . Before I guess you could only do it for AWS resources . Big , big , big deal , I would think , because , again , I always thought you could do that .

Yeah , I wonder what we were doing before . Actually , now I'm kind of scratching my head .

I guess you just weren't , you were using Certificate Manager to manage certificates you already had generated elsewhere , and then you were only generating from ACM for AWS resources , I guess maybe you weren't really , you were only generating from ACM for AWS resources , I guess maybe .

There's a lot of things that are completely embedded in there that you don't have to worry about from the customer's perspective , but that comes at a price in that you can't use it with external resources , right . There's some kind of dependencies built into there .

So this does also kind of introduce some new kind of I don't want to say new things to certificate management , maybe new things to certificate manager or ACM within AWS in that focusing on you know kind of things like revocation , you know revoking certificates whereas it's not all contained within AWS at that time and kind of the renewal of those certificates as

well . I don't know if you could actually revoke certificates specifically and previously to this , so I don't know if that's a new thing that's been added previously to this . So I don't know if that's a new thing that's been added . I know you can automatically renew them in ACM , but I don't remember being able to explicitly revoke them .

I could be just completely misremembering that , but yes , I mean . This note here does say you can only revoke certificates that were previously exported . So it leads me to believe that this is a new thing , but , but , like you said , now , this is , this is adding an amount of complexity that wasn't there before .

It hasn't been there for the last , you know , 15 years . At this point , um , so , uh , you know , I'm sure some people are , you know , sighing a breath of relief . Um , um , until the day comes when they have to , uh , something gets compromised and they do have to revoke these , and I don't know how that fits into their existing workflows , et cetera .

So yeah , so it's good , but comes at a price of your sanity , potentially yeah .

Like it kind of sucks when all the announcements are really focused on analysis and things like that , nothing actually , you know , changing the forefront , um of how the technology works , but sometimes that's just how the cookie crumbles , right .

Well , this has been a cables to clouds a fortnight in the news . Thanks for joining us . The stuff will be in the show notes . I encourage you to take a look . See you next time .