AWS re:Inforce 2023 - Firewalls, and where to put them (NIS306)

Aug 16, 2023

AWS re:Inforce 2023 - Firewalls, and where to put them (NIS306)

Firewalls play an important role in infrastructure security. But do you know the different security and visibility use cases for each type and deployment model? In this session featuring a customer, learn about different types of firewalls and deployment models, and discover how AWS Network Firewall and AWS WAF can help you manage your inbound and outbound security rules at scale.

Learn more about AWS re:Inforce at https://go.aws/42zqk7C.

Subscribe:
More AWS videos: http://bit.ly/2O3zS75
More AWS events videos: http://bit.ly/316g9t4

ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.

AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

#reInforce2023 #AWSEvents

Content

0.93 -> - Welcome to your second day of re:Inforce.

3.63 -> I know it's kinda early in the morning, right?

5.46 -> But I will promise this session

6.543 -> will be worth it for waking up, I promise.

8.97 -> I'm not a early person as well,

10.17 -> but I'm gonna make it worth your while.

12.54 -> My name is Ivo Pinto,

13.56 -> I'm a Solution Architect for AWS, and I'm here joined by my

17.13 -> colleagues, Tzoori from AWS as well, and Buzor from Workday.

22.11 -> During the next hour we'll be talking about firewalls

24.747 -> for one hour, and where to put them, obviously.

28.89 -> There are a lot of different types of firewalls

30.69 -> with different names, right?

31.77 -> Web application firewall, network firewalls.

34.23 -> Sometimes they're called next generation firewalls.

36.48 -> And even some constructs like security groups

38.19 -> that are not explicitly called a firewall,

40.65 -> but work as some sort of firewall.

44.22 -> To make things more interesting, there's also different

47.52 -> levels of visibility, different levels

49.44 -> of functionality that come from configuration

52.11 -> and where you put those firewalls in your network.

54.45 -> But don't worry, that's why we've created this session.

57.18 -> During this session you'll see how these

58.95 -> different security constructs apply in AWS.

61.8 -> What levels of visibility they give you.

64.38 -> Also what level of applications, like application types

66.84 -> they're good for, and all of that within an hour.

70.86 -> How we're gonna do it?

71.7 -> Well, this a level-trended session,

74.37 -> but we're gonna start with a architectural constructs

76.26 -> where we'll cover these different concepts

78.33 -> like security groups, network firewalls.

80.07 -> What do they do at high level?

82.44 -> But then we'll deep dive into specific

84.33 -> use cases and how we use, both for inbound,

86.73 -> which is the main focus of this session.

88.29 -> We'll deep dive really a lot there.

90.45 -> And then cover outbound,

92.28 -> sort of a shallow dive and give you some homework

94.223 -> as well that you can follow up and learn more about.

97.23 -> Then from theory to practice, Workday

99.96 -> is gonna talk to you about their firewall journey.

102.27 -> How they've evolved their security architecture over time

105.09 -> to meet the requirements that were changing.

108.09 -> And at the end we're gonna give you some bite-sized journey,

111.51 -> bite-size takeaways that you can take home

113.79 -> and apply in your own environment.

116.58 -> So let's get started with the first pieces

118.98 -> of this bigger puzzle, right?

121.83 -> Security groups and network ACLs.

123.51 -> Most likely heard of this, right?

124.83 -> These are the most common constructs that people use in AWS.

129.18 -> Security groups function as a stateful firewall, right?

132.42 -> They work in the TCP/IP layer, so that's Layer 4.

134.88 -> You can take decisions based on source IP,

136.71 -> destination IP, port as well.

139.5 -> And they are applied at ENI level.

141.267 -> You know, this could be an EC2 for example.

143.67 -> But that's where you apply.

145.59 -> Typically they are mandatory for many resources.

147.87 -> You know when you create an EC2 it's mandatory.

149.7 -> And you've for certainly seen it and certainly used it.

153.42 -> Then you have network ECLs, NACLs.

155.73 -> I know there's a lot of contention on how to say this name.

158.88 -> They are stateless.

159.72 -> They're not stateful, like security groups,

161.97 -> But they also work in the TCP/IP layer.

163.89 -> Again, Layer 4.

165.63 -> Unlike security groups, they're not applied

167.55 -> at the ENI level, rather then applied at the subnet level.

171.87 -> But then when you move further from this basic

174.36 -> security use case, you might have to apply

176.67 -> policy based on something more than Layer 4.

179.43 -> And that's where network firewall comes in.

181.44 -> This is our managed service offering, right?

184.11 -> So we manage it for you.

185.34 -> It automatically scales up and down, so on, so forth.

188.247 -> And it allows you to create

189.54 -> both stateless and stateful rules.

191.91 -> So it's not a one and done like

193.408 -> security groups or network ACLs.

194.85 -> It's a choice, right?

196.44 -> Likewise, these rules are applied up to Layer 7.

199.23 -> So from Layer 3 to Layer 7, you can choose the rules.

203.7 -> The way network file protects your resources

205.95 -> is that it filters traffic in between Layer 7.

208.56 -> So typically you would place it in a separate subnet

211.23 -> and use route tables to use traffic.

214.65 -> However, there are yet another concern, right?

218.22 -> Gateway load balancer.

219.053 -> This one is one of those that

220.44 -> does not have firewall in its name.

222.65 -> As you see, just Gateway Load Balancer.

224.43 -> And there's a good reason for it

225.35 -> is because it's not a firewall.

227.49 -> However, it enables firewall use cases

229.98 -> and that's why we will speak about it today.

232.68 -> We is it?

233.64 -> It's a bump-in-the-wire load balancer.

236.94 -> So it's a transparent load balancer.

238.5 -> You send traffic to it and it's transparently routed back.

241.47 -> Its virtual appliances where a policy decision is made.

244.44 -> How do you route traffic to it?

245.46 -> Again, you use just the subnet route.

249 -> Why do you care for create a load balancer

250.89 -> in the firewall too?

251.73 -> Well, because this is an easy way to insert

254.73 -> firewalls within your traffic push.

256.71 -> And this is specially useful if you have

258.72 -> already invested into third-party firewalls.

260.937 -> So if you're already invested,

261.77 -> you have the knowledge, right, and you have bought them,

263.76 -> this is one way of using it.

267.9 -> It is more features than just inserting

269.82 -> your firewalls directly on the traffic.

271.38 -> For example, automatic rerouting of traffic

274.14 -> and also health check.

276.24 -> So that's something to look out for.

283.23 -> - Thanks Ivo.

284.19 -> I'll cover two extra tools

286.02 -> in your toolbox when it comes to firewalls.

287.85 -> My name is Tzoori, I'm a solutions architect specialist,

290.28 -> which is a fancy way to say I only know a few services,

292.71 -> not all of them when it comes to AWS services.

295.2 -> One of these services that I do know,

296.49 -> luckily enough, is AWS WAF.

298.307 -> So AWS WAF is a web application firewall,

300.93 -> so it does have the word firewall in it,

302.517 -> so this is why we're talking about it today.

304.29 -> But it can definitely be used as an ingress control point

306.9 -> when it comes to firewalling access into your applications.

309.87 -> So basically what AWS WAF does, because I know WAF

313.173 -> is a kind of different and some people

314.94 -> are only network firewall kind of people,

316.74 -> so we do take the time to explain what it does.

319.32 -> The one thing it allows you to do is to have

321.21 -> Layer 7 controls over ingress traffic.

323.4 -> So you can have your own

324.3 -> allow list and block lists configured.

327.72 -> You can have them populated

329.34 -> automatically through an API call.

331.11 -> Another thing can have at Layer 3 is having

334.74 -> managed rules when it comes to IP reputation lists,

337.26 -> anonymous IPs, well-known sources that you

340.89 -> probably wanna block or maybe do something with,

343.56 -> maybe you wanna challenge them or just flag them

346.2 -> for downstream services to be made aware

349.23 -> that there are suspicious IPs.

351.75 -> And you can also do geolocation-based controls.

353.76 -> So you can do country-based or city region-based controls

357.18 -> if you wanna control whoever is allowed in.

359.43 -> So this is at Layer 3.

360.99 -> When it comes to Layer 7 AWS WAF, obviously it's a web

363.72 -> application firewall, so it has a full Layer 7 capabilities.

366.42 -> It understands HTTP.

368.25 -> HTTP only, by the way.

370.62 -> And you can have either managed rules or custom rules

374.58 -> that identify and control what goes into your application.

378.03 -> So you can use it in a positive security mode

380.61 -> where you only allow specific URIs, or host names,

383.55 -> or whatever it is that you wanna allow, or request

385.62 -> that carry an authentication cookie for example.

388.5 -> Or you can use it in a negative security model

390.6 -> where you wanna block certain pages, certain URIs

393.69 -> from being accessed from the outside world.

395.91 -> It could be your admin pages

397.56 -> or any sensitive part in your application.

401.04 -> Other than that, we have DDoS mitigation

402.78 -> capabilities built into AWS WAF.

404.61 -> So you can create your own baselines

407.19 -> and custom rules that control rates

409.32 -> in which you are willing to receive requests.

411.45 -> They could be as generic as blank rate limiting rule

414.42 -> saying I do not want to allow any more than a certain amount

417.93 -> of requests within a five minute period from any source.

421.35 -> So let's say no more than 10,000 requests, or a million,

423.87 -> or 500, whatever works for your application.

427.11 -> And you can also make these rate-based rules more granular

431.22 -> and you can say, I don't want to to receive

433.08 -> more than X amount of requests coming in,

435.39 -> but only if they're targeting my signup pages,

438.6 -> or only if it's coming from well known suspicious sources.

441.87 -> So you can create your own rate limiting rules

443.85 -> to be as coarse or as granular as you wish.

446.79 -> And as a recent advancement, we also introduced

448.68 -> the way for you to keep track of requests,

451.41 -> not based on IP addresses, but based on pretty much

453.78 -> any part of the application.

455.97 -> So you can say, I don't wanna receive any more

457.98 -> than X amount of POST requests from anywhere

460.83 -> at once without tracking individual IP addresses.

463.77 -> Super useful for distributed attacks.

466.95 -> Last but not least, AWS WAF also allows you

469.38 -> to run two managed rules that deal

471.63 -> with automated clients, automated actors, namely bots.

477.18 -> And we deal with bots in two separate use cases.

479.76 -> One is, you know, abnormal non-human behavior.

483.6 -> These well-known bots that we can detect through

485.64 -> a service managed rule, that's called bot control.

489.57 -> And the other thing we can do

490.71 -> in a managed session is to control fraud.

493.86 -> We can detect anomalous login activities,

496.26 -> anomalous signup activities, that goes beyond

500.31 -> just detecting whether or not it's a signup request.

502.29 -> But really is the entity requesting to sign up or requesting

505.95 -> to log in is using proper credentials,

507.9 -> going through the proper flow, acting like a human.

510.66 -> So all of these capabilities are built into AWS WAF,

512.787 -> and you can put it, as we'll see later, in multiple places

516.48 -> in your architecture as agnostic to the application,

519.09 -> or as application-specific as your needs are.

523.11 -> Another tool in your toolbox is Firewall Manager.

525.21 -> So Ivo talked about...

526.77 -> Later on, by the way, we'll be holding a competition

529.17 -> about properly pronouncing all of our names.

531.03 -> It's gonna be a challenge.

533.28 -> So the services that Ivo mentioned as well as AWS WAF,

538.17 -> can be controlled through an organizational

540.09 -> service called Firewall Manager.

541.86 -> It controls multiple service and multiple features.

543.99 -> So it control, obviously, WAF.

545.48 -> It control network firewall.

547.11 -> It can control security groups at the organizational level.

549.99 -> And when I say control, it can also control

552.06 -> some third-party firewall appliances.

555.42 -> And when I say control, it can automatically

557.91 -> deploy and remediate misconfigurations.

559.98 -> So let's say you can easily detect with Firewall Manager

562.68 -> whether someone has opened up port 80 to the world on your

566.46 -> ALB and automatically slap like an AWS WAF web ACL on it.

571.11 -> Or whenever someone opens up SSH port 22 to the world,

575.64 -> you can have Firewall Manager detect that,

577.23 -> report that, and also remediate that.

579.63 -> So remove that offending rule

581.4 -> that does not comply with your policy.

583.86 -> The other thing that Firewall Manager does,

585.18 -> it can propagate all of its findings into Security Hub.

587.94 -> So it can allow you to centrally control and view

591.33 -> your status across the organization

592.98 -> when it comes to ingress mitigation or ingress control.

598.5 -> Now when it comes to network flows,

600.9 -> there are three directions, or three use cases,

603.3 -> for controlling traffic, right?

604.68 -> The one that we'd be focusing most today is inbound.

607.29 -> Basically that's the most dangerous path because this

610.53 -> is where you expose your applications to the bad internet

612.98 -> to the world, and you wanna make sure

615.12 -> that whoever accesses your applications from the world

617.37 -> is the proper people, the proper entities.

620.52 -> And we'll be covering a lot around the inbound controls

623.73 -> and considerations when it comes to traffic.

626.43 -> Another use case is for outbound control.

628.53 -> So if you do allow outbound traffic

631.08 -> from within your cloud infrastructure to the world,

633.06 -> there are considerations to be made

634.26 -> about how to control that outbound traffic, if you wish.

638.58 -> And we won't go into much depth around that,

641.1 -> but there are a few slides that Ivo will cover later on.

643.83 -> And the east-west use case where you have applications

646.89 -> talking to applications, or internal users talking

649.22 -> to applications, which we won't cover in this session.

653.19 -> We will point out the outbound use case

655.29 -> in another separate session that happened yesterday.

657.63 -> Ivo will point it out for you for later viewing if you want.

660.72 -> So let's focus on the inbound use case, right?

663.15 -> This is the meat of this session.

666.09 -> So first, when we try and decide what controls do we want

669.06 -> to enforce or use, what tools we want to use for controlling

671.7 -> inbound traffic, which is also ingress traffic.

675.66 -> So we might be using inbound and ingress

678.51 -> throughout this presentation.

680.31 -> So when we come to choose our tool, the proper tool,

682.74 -> or probably tools, that control inbound traffic,

685.41 -> there are a few considerations that we need to think about.

687.27 -> So firstly, what kind of traffic are we dealing with?

690.42 -> Is it only HTTP?

692.25 -> And then we have a myriad of options and possibilities

696.15 -> when it comes to ingress traffic control.

698.07 -> We can use WAF, we can use CloudFront, we can use

699.93 -> other ALBs, we can use other proxy services

703.53 -> that enable us finer control over what comes in.

705.84 -> Or is it for all application?

707.16 -> Do we have, like, custom ports, custom protocols

710.04 -> that we also want to provide inbound traffic to, right?

712.47 -> Some use cases are like that.

714.99 -> How big are we deploying here?

716.82 -> Is it like a single VPC, single entry point,

719.52 -> super easy like, and then the question is kind of moot.

722.91 -> We don't really want to go into complexities

725.01 -> where we don't have to, we don't have to over engineer.

727.89 -> But if we are built organizationally differently

731.07 -> and we want to centralize control over the ingress traffic

733.527 -> and allow the application owners to run their own thing

736.26 -> as well as they go through our centralized choke point,

738.33 -> the centralized control point, or whether we want to provide

741.42 -> services for multiple VPCs, possibly multiple accounts,

745.02 -> these are considerations that might affect our decision

747.36 -> on what tool, what service we want to deploy.

750.87 -> And lastly, how deep is our love, right?

753.06 -> How much do we want to take a look into the traffic?

755.66 -> Do we only care about IPs and ports

757.44 -> when it comes to ingress traffic?

758.82 -> Which is fine, I'm not judging, right?

760.2 -> Some use cases are like that.

761.76 -> We only want to have the IP and ports made sure

764.28 -> that we are using proper ports and that's it.

767.61 -> I'm sure that a lot of you are using security groups

769.98 -> and have been using security groups and that's it,

772.05 -> which is great, that's fine.

774.42 -> But if you want like a deeper understanding of what goes

776.25 -> into our traffic, whether it's HTTP or not HTTP,

779.19 -> we might need to choose something else that could have

781.32 -> a deep packet inspection capabilities to allow us

784.29 -> better understanding more than just the ports, right?

787.56 -> Is it really an HTTP request? What goes in it, for example.

793.26 -> Another consideration, or one of the key considerations

796.74 -> will cover today, is how do we build

799.35 -> our networking traffic flows?

801.81 -> So how do we do it?

802.71 -> Do we distribute our control points?

806.67 -> And again, if you have a smaller footprint,

809.16 -> maybe a single workload or a single VPC,

811.32 -> single account, that's fine.

812.79 -> We don't need to go into complexities and over-engineering.

815.46 -> We can have like a VPC with an internet gateway attached

818.85 -> to it and security groups and that's fine.

822.36 -> But when it comes to more complicated environments,

824.49 -> we might want to choose to have a centralized

827.25 -> approach where we control all ingress traffic

829.62 -> in a minimal number of places.

831.33 -> I wouldn't say necessarily a single place.

833.43 -> And this single place, or this minimal number

835.35 -> of places can contain multiple controls.

837.69 -> So it can have a WAF in it, a reverse proxy in it,

841.2 -> a network firewall in it.

842.033 -> It can have multiple components in it,

843.6 -> but it's all centralized and all traffic

845.43 -> is flowing through the same choke point.

847.56 -> It might be an organizational necessity,

850.02 -> because maybe the VPC application people are set to roam

855.15 -> free in the cloud and they create their own workloads

857.88 -> and they can do whatever they want inside the VPC.

860.37 -> But if they want to expose something to the internet

862.59 -> they have to go through another organization that basically

865.23 -> controls the incoming traffic centrally.

867.9 -> It might be a technological effort, right?

869.61 -> So your considerations may vary,

871.11 -> your mileage may vary in your own organization.

873.45 -> But this is one key consideration to think about when you

876.81 -> build your own network infrastructure,

878.85 -> when you want to control ingress traffic.

885.24 -> Why would we centralize?

886.621 -> So centralizing your traffic obviously has its pros

890.94 -> because we have a single control point.

892.95 -> We have a single place to look for,

895.38 -> you know, forensics, logs.

897.27 -> We have a small number of people

899.28 -> dealing with all ingress traffic.

900.84 -> So we can standardize and optimize our efforts

905.04 -> when it comes to controlling ingress traffic.

907.08 -> But then if we only have a single point of failure

910.68 -> or a single entry point, it might also introduce

913.71 -> a greater risk of a larger blast radius.

917.43 -> So if something goes wrong, a misconfiguration

919.23 -> or something goes wrong with our inbound

921.51 -> control point, it will affect everybody.

923.28 -> All of the underlying services

924.63 -> that we have exposed through that.

928.02 -> It also increases complexity.

930 -> Even though, you know, conceptually

932.34 -> it has less moving parts, but now we

935.04 -> have to deal with routing in between VPCs, right?

938.25 -> So we have to deal with where traffic is coming from

940.32 -> and where is it going through.

943.29 -> When you think about distributed workloads,

945.36 -> we only have like EC2s, load balancers, IGWs,

948.21 -> a single back and forth flow.

951.45 -> And again, even though it has like potentially

955.65 -> a fewer number of moving pieces, like one central

958.62 -> chunky firewall in the front, it may increase our costs.

962.76 -> As traffic traverses more than just

964.74 -> a single VPC and has to go in between multiple

967.08 -> components, it may increase our cost.

969.03 -> But then on the flip side,

970.38 -> if we do a distributed architecture,

973.17 -> we might have duplicate constructs.

975.18 -> So we might have multiple firewalls or multiple

978.15 -> WAF configurations, which have a cost attached to them.

981.09 -> So again, your mileage may vary,

982.86 -> but you should be made aware of these considerations.

986.46 -> Let's first dive in into the distributed

988.41 -> workflow for web applications.

990.75 -> So when it comes to AWS WAF, AWS WAF is a service

995.4 -> that does not have traffic carrying capabilities, right?

998.97 -> It's not a reverse proxy in on itself.

1000.74 -> We have to attach it to something.

1002.96 -> The most probable situations that you'll encounter

1005.6 -> in the wild is when you attach an AWS WAF web ACL

1008.33 -> or a WAF policy to something like ALB or CloudFront.

1013.76 -> When we talk about distributed models,

1015.53 -> we'll typically have a single entry point.

1017.84 -> So it could be a single load balancer,

1019.88 -> a single ALB that distributes traffic across your workloads.

1023.9 -> It could be a single CloudFront distribution

1026.66 -> with a wild card associated with it,

1028.55 -> or it could be multiple CloudFront distributions.

1030.95 -> Depends on how you control your DNS names or vanity domains.

1038.51 -> But eventually you'll have a minimum

1040.16 -> number of people that control a single

1041.87 -> choke point on incoming requests, right?

1044.15 -> This is only dealing with HTTP traffic.

1046.16 -> We're talking about web application firewalls.

1047.69 -> So we only deal with AWF.

1049.46 -> There are a lot of benefits to running your AWS WAF web

1053.3 -> ACL as far away from your application as possible

1055.88 -> at the edge, right, at the CloudFront level.

1058.34 -> And we'll cover those in a couple of minutes.

1063.02 -> The centralized model for AWS WAF

1067.73 -> is where we basically allow one group

1072.41 -> of people to control a single entry point

1076.01 -> which will front all of our applications, right?

1078.32 -> It requires building multiple

1080.18 -> moving parts, as mentioned before.

1081.59 -> So basically we want CloudFront to send traffic to an ALB,

1085.76 -> or to send traffic to a centralized reverse proxy.

1088.67 -> In this case it's an ALB, it could be NLB.

1090.71 -> And this NLB routes traffic to multiple ALVs behind it.

1093.92 -> So again, it's a similar concept as the distributed model,

1097.82 -> but this time we're using a single

1100.04 -> entry point that controls all inbound traffic.

1102.68 -> When it come to AWS WAF policies

1104.33 -> and that we'll see that in a second.

1106.34 -> The policy may change if you're dealing

1108.35 -> with a distributed model or a centralized model.

1111.08 -> Which means that your policy may contain only agnostic

1115.52 -> elements in it, only elements that do not take

1118.01 -> into consideration how the application looks like

1120.35 -> when you're dealing with centralized controls,

1122.27 -> because your web application firewall will be reused

1125.06 -> across multiple different applications.

1127.28 -> So you can't really refer to specific URIs

1130.79 -> in the application because your single web application

1133.13 -> firewall policy will have multiple applications under it.

1135.8 -> So you'll have controls which are more agnostic.

1138.38 -> Going back to the distributed approach,

1141.14 -> you can have the people who manage WAF have

1143.36 -> a very fine grain over what goes into our web ACL.

1146.66 -> Meaning our web ACL can now contain application-specific

1149.75 -> controls like managed rules that only deal

1153.56 -> with PHP vulnerabilities or stuff like that.

1157.37 -> In any case, when it comes to controlling ingress traffic,

1160.34 -> a web ACL, I will leave you with this image

1162.83 -> of a sample web ACL that does not deal

1165.71 -> with any application-level vulnerabilities, right?

1169.7 -> It's not a typical WAF policy.

1171.32 -> It's more of a policy that you'll see when you

1173.75 -> deal with ingress traffic control and that's it.

1176.15 -> So you'll be seeing IP-based rules.

1177.95 -> So IP allow lists and block lists.

1180.35 -> You'll be seeing maybe a list of countries

1185.57 -> that we don't want to allow any kind of traffic from.

1188.72 -> We might also see a list of countries

1190.19 -> where we want to challenge incoming requests.

1193.01 -> So suspicious countries.

1194.06 -> Not countries that we are not allowed to deal with,

1195.74 -> but countries that we don't typically see traffic from.

1197.69 -> An AWS WAF can present the incoming traffic,

1200.48 -> incoming HTTP request with a JavaScript challenge

1203.03 -> just to make sure that whoever is speaking to us is a proper

1205.67 -> browser and not some kind of an automated client.

1208.55 -> And then we can also have managed rules

1210.23 -> that deal with IP reputation, anonymous IPs,

1213.11 -> these are managed IP lists that we keep populated for you

1216.98 -> and they can track well-known bad sources

1220.25 -> like DDoS contributors and botnets and all of these

1222.89 -> bad sources that you not don't necessarily

1225.32 -> want to allow traffic from into your applications.

1228.86 -> And then again, you can also add your bot control

1231.29 -> management rules, which allows you

1232.67 -> to keep track of sessions and volumetric sessions.

1236.18 -> And then at lastly, you can create your rate limiting rules,

1238.58 -> which can be as specific or as generic as you wish.

1242.45 -> If you look at the last rule here,

1243.59 -> like a blanket rate limiting,

1244.91 -> I do not want to allow more than X amount

1246.92 -> of requests from any regardless of where it's

1252.8 -> coming from or where it's going to.

1254.18 -> And we can have more specific rate limiting rules that say

1257.09 -> I want to be more aggressive with maybe my signup page.

1260.75 -> or login page, or search page, or maybe specific sources.

1264.26 -> I want to be more aggressive,

1265.19 -> have lower rates allowed for specific sources

1268.31 -> or specific destinations at the application level.

1272.39 -> To sum it up, when it comes to blocking ingress traffic

1277.25 -> when you have purely HTP traffic for your application,

1279.89 -> it makes a ton of sense to push your OACL

1282.71 -> as far away from the application as possible.

1284.9 -> Namely, I wanna see whenever it's possible

1288.32 -> CloudFront fronting your web application.

1290.81 -> Because not only will you be benefiting from

1292.91 -> acceleration, because CloudFront terminates TLS and TCP

1296.39 -> at the edge, at 450 plus pops around the world.

1299.66 -> So clients will experience a faster time to connect.

1303.98 -> CloudFront is also natively filtering out traffic

1306.5 -> which is not designated to your application, right?

1309.05 -> It only listens or on port 40 and 883.

1311.6 -> This is no longer your problem to filter traffic,

1313.49 -> which is not pure HTTP traffic.

1315.53 -> It filters out any non RSC compliant requests.

1318.8 -> So nothing which is on port 443 or port 80,

1322.58 -> but it's not a proper HTP request, it's just filtered out.

1325.04 -> You'll never see it.

1326.05 -> It also filters out any traffic

1328.49 -> which does not match your host names.

1330.17 -> So any random internet noise.

1332.3 -> If you look at your firewall logs, at your web application

1334.61 -> firewall logs, if you're not running on CloudFront,

1336.59 -> you'll be seeing a ton of traffic

1337.82 -> that just targets your IP address as a host name.

1340.37 -> This is just random internet noise,

1341.81 -> it can be a lot of traffic.

1343.49 -> CloudFront does not allow this traffic through.

1345.41 -> It has to have a valid host name that matches

1347.36 -> your configuration to allow traffic through.

1351.77 -> Another thing that CloudFront does for you

1353.51 -> when you enforce application security

1355.25 -> at the edge is volumetric network level attacks.

1358.4 -> Again, network level stuff is getting managed

1361.25 -> by the AWS CloudFront team, or the service rather.

1365.81 -> We only allow proper HTTP requests.

1367.88 -> So network level data attacks SYN floods, UDP floods,

1371.33 -> ICMP floods, whatever is non HTTP, you should not care

1376.61 -> anymore when you expose your application through CloudFront.

1380.12 -> Plus, we're also benefiting from a service

1381.74 -> called Shield Standard, which is our basic

1383.66 -> DDoS mitigation service, which runs in line,

1386.75 -> always on, on CloudFront, whenever you enable it.

1390.23 -> And it also helps when mitigating a lot of the unwanted

1393.17 -> traffic from hitting your front ends.

1394.58 -> Even your front end components like your firewall,

1396.38 -> your ALBs, even if you block it at the ALB level,

1399.14 -> traffic will still reach your ALB

1401.793 -> if it's just random internet noise.

1403.4 -> Not so the case where you use CloudFront.

1405.83 -> We make sure that only proper traffic

1407.3 -> is going through it before reaching your backend.

1411.89 -> And will that, I'll switch back to Ivo.

1415.01 -> - Thank you Tzoori.

1416.39 -> So we were talking a lot about HTTP, you know,

1419.477 -> and web traffic and all of that.

1420.98 -> But many of you might have other applications, right?

1423.44 -> Other applications that are not web applications, right?

1425.9 -> So not HTTP.

1426.733 -> FTP, syslog, anything like that.

1429.98 -> If what mentioned, if you consider

1432.08 -> what Tzoori mentioned before, right?

1433.4 -> And you think a distributed model for you, right?

1435.65 -> You could choose a distributed model

1437.57 -> and the network firewall, right?

1439.52 -> So with this model in mind,

1441.65 -> you can support any type of application.

1443.39 -> You don't necessarily only support

1445.19 -> HTTP like you did with WAF.

1446.89 -> So you can filter on anything.

1448.76 -> And and how would you go about deploying it, right?

1450.44 -> So you just create network firewall endpoint and all your

1453.29 -> VPC and the distribute the environment, and you would use

1456.08 -> route tables to pass traffic through, right?

1458.03 -> It enters through the internet,

1460.07 -> then network firewall, then there.

1462.35 -> With this approach you can also

1464.87 -> take decisions up to Layer 7.

1466.46 -> Just like the WAF, but in this case

1467.99 -> Layer 7 of all these different products.

1471.02 -> We recently introduced encryption,

1472.82 -> TLS encryption capability on the network firewall.

1475.7 -> So even if your traffic is encrypted,

1477.68 -> you can provide it with a load balancer

1479.45 -> and you'll be able to take decisions

1480.74 -> and have visibility even on the track, okay?

1484.37 -> The data plan of this solution is distributed,

1486.29 -> and that's important for the scales considerations,

1488.18 -> as Tzoori was mentioning.

1489.35 -> So this scales very well.

1490.46 -> It's distributed at each of its VPCs

1492.08 -> is gonna have its own dedicated firewall clusters.

1494.63 -> But this will be more clear on the next slide.

1497.12 -> And from the management perspective,

1498.41 -> you can either choose to manage it centrally using

1501.62 -> Firewall Manager because there's net integration there.

1503.78 -> You create the policy, you say which VPCs you want it

1507.04 -> to use, and it'll just deploy it for you.

1509.72 -> Or you can manage it individually.

1511.22 -> Let's say each of your teams has its own firewall,

1514.16 -> has its own rules, they wanna manage it themselves,

1516.29 -> you wanna give them that power, you can do so, right?

1518.39 -> So you would not use Firewall Manager in that sense.

1521.66 -> However, like I mentioned in the beginning

1523.46 -> of this presentation, some of you might have already

1525.71 -> invested into third-party firewalls, right?

1527.9 -> From some of our partners.

1528.98 -> And you might want to maintain that, right?

1530.57 -> You already have trained engineers, and that's fine.

1533.21 -> So the architecture with gateway

1534.56 -> load balancer would look exactly the same.

1537.26 -> Simply the endpoints would not be firewall endpoints,

1539.21 -> it would be Gateway Load Balancer endpoint.

1541.61 -> It would still support any type of application.

1543.89 -> You'd still route traffic through using the route tables.

1546.89 -> However, both the inspection that NTLS decryption

1549.68 -> capabilities don't come from the Gateway Load Balancer.

1552.08 -> Like I've said, comes from the virtual appliances

1553.97 -> themselves, so you'll need to check, right?

1555.89 -> You'll need to make sure those appliances support your need.

1560.21 -> The data plane of this solution is also distributed, right?

1562.639 -> So you have Gateway Load Balancer endpoint

1564.83 -> throughout your estate, throughout your VPC.

1567.32 -> And they will route traffic transparently

1569.18 -> to this backend appliance.

1570.86 -> It's important to note, and again on the next slide,

1572.48 -> this will be very visual, to understand

1574.31 -> that with this solution with the Gateway Load Balancer,

1576.8 -> versus the network firewall, this can

1578.21 -> air pin to the same firewall cluster, right?

1580.46 -> So you can have gateway balancer

1581.87 -> which pointing to the same cluster.

1583.82 -> So this solution, when you're scaling it, right,

1585.53 -> you have to have that into consideration.

1588.35 -> Lastly, on the management part, you can typically

1591.2 -> manage the solution via the vendor management tools.

1593.36 -> So they have their own.

1594.38 -> It's one way.

1595.4 -> Or just the traditional way, you know,

1596.57 -> using like CLI, SSH, whatever you like.

1600.17 -> Now, deep diving on the data path itself,

1602.78 -> as I mentioned this is an important consideration,

1604.67 -> especially for scale and for cost.

1607.01 -> With the Gateway Load Balancer, you see that you have

1608.96 -> multiple VPCs with different Gateway Load Balancer

1612.47 -> pointing to the same Gateway Load Balancer,

1614.27 -> and therefore the same third-party appliances.

1616.91 -> So although the data plan is distributed, right,

1619.91 -> they are going airplane into the same appliances.

1622.22 -> So you're scaling it and you have thousands of VPCs, right?

1624.41 -> All the traffic is going to be hitting the same appliances.

1626.69 -> So it's sort of distributed data plane in the sense

1630.17 -> that it can air pin to the same cluster.

1633.35 -> On the net of firewall, however, it's completely different.

1635.99 -> Each of your VPC is gonna have a dedicated firewall cluster.

1638.84 -> It'll scale individually.

1640.19 -> So it's fully distributed data plane.

1643.34 -> It's important to note that this

1645.11 -> comes with a cost, of course, right?

1646.52 -> So you're gonna have different firewall clusters,

1648.53 -> it's a more costly model.

1650.24 -> If you want to replicate the model of network firewall

1652.816 -> with Gateway Load Balancer, it's possible.

1654.47 -> Simply have to create, you know, different

1655.639 -> firewall clusters for all of those gateway load balancers.

1660.11 -> But let's say a distributed model is not for you, right?

1662.21 -> Like you were hearing from Tzoori,

1663.74 -> you want a centralized response.

1665.12 -> It could be a requirement for you,

1666.23 -> could be a compliance requirement,

1667.91 -> you could just like it, right?

1670.49 -> It's perfectly reasonable.

1671.72 -> You can choose to use the same security constructs,

1674.12 -> network firewall, gateway load balancer,

1675.65 -> architecture would look like that.

1678.05 -> Fairly similar.

1678.98 -> But there are some considerations

1680.21 -> you need to have in mind, right?

1681.08 -> There's some trade offs here.

1682.58 -> And although you might pay less in terms of endpoint, right?

1685.82 -> Because you have a single endpoint in a single edge VPC,

1688.61 -> there will be added cost that you need to take

1690.17 -> into consideration like the transit gate, right?

1692.9 -> All your traffic will be passing through transit gateway

1695.09 -> or some sort of mechanism, right,

1696.62 -> to route traffic from your edge VPC to your application VPC,

1699.8 -> and therefore there will be processing costs there.

1702.35 -> It's also worth noting that you will need static IPs

1705.5 -> for the solution to work because the load balancers

1706.843 -> in edge VPC cannot point to host names,

1709.52 -> nor they can point to instance types.

1711.44 -> Therefore, if you need static IPs, you will need

1713.57 -> network load balancers on your application VPCs,

1716.21 -> and therefore you'll need to pay for those as well.

1718.64 -> It's not one-size-fits-all solution.

1720.74 -> You know, there's nuances here.

1722.45 -> But these are important considerations to have in mind.

1725.9 -> On the benefits side though, right?

1727.37 -> Both of these solutions are centrally managed

1729.11 -> in this sense that you know, there's a single VPC,

1731.51 -> single fiber cluster, both gateway

1732.95 -> load balancer and network firewall.

1734.143 -> You can just manage it from there.

1736.31 -> And the previous consideration of data path

1739.88 -> does not apply here neither, right?

1741.02 -> Because again, you have a single file path.

1743.3 -> But more than choosing centralized versus distributed

1746.18 -> or gateway load balancer versus network firewall,

1748.43 -> there's also the consideration that you need

1750.05 -> to take of, where do you place it in your VPC?

1753.02 -> Do you place it before the load balancer

1755.21 -> or do you place it after?

1757.61 -> And again, no size fits all.

1759.98 -> This will affect how you create your rules.

1761.96 -> So if you put it before,

1762.92 -> you'll have to create your rules in one way.

1764.03 -> If you put it after you need to create rules in another way.

1766.52 -> But it's all about the visibility that you want to have.

1769.19 -> So if you put it before the load balancer,

1771.14 -> you'll see all the inbound traffic,

1772.76 -> you'll see the real source IPs as well,

1774.68 -> but you will lose the destination IP because the destination

1777.26 -> IPs in this case will be the the load balancer.

1781.31 -> On the other hand, if you put it after the load balancer,

1783.56 -> you won't see all the traffic, right?

1784.88 -> You'll only see the traffic as sent by the load balancer,

1787.7 -> but you'll be able to see the real destination.

1791.09 -> It's also worth noting that there's

1792.5 -> something with certificates here, right?

1793.88 -> It's different type of certificate

1794.96 -> that you need to use with each solution.

1796.73 -> It's a little bit technical there, but again,

1798.68 -> have that in mind when you're choosing, okay?

1801.8 -> So far this was a big deep dive in inbound.

1805.1 -> I know it's a lot to take in, right?

1806.81 -> But I want to switch gears here

1808.91 -> a little bit to the outbound, okay?

1811.16 -> Most of the considerations we've talked so far in our

1813.02 -> distributed, centralize, all of that still applies here.

1815.93 -> And as you can see here.

1816.86 -> So for egress that's the same.

1818.51 -> You'll have to make a decision if you need a single ingress

1821.06 -> point or you can have multiple, right, it's up to you.

1824.21 -> Bear in mind it's the consideration

1825.38 -> is about the same, right?

1826.213 -> So in the centralized you have a single point,

1828.14 -> but it's typically more costly, typically more complex.

1830.78 -> So same as for the ingress.

1833.15 -> And likewise where you place your firewalls,

1834.793 -> in this case won't be regarding the load balance.

1837.26 -> This kind will be regarding the NAT gateway.

1839.42 -> But they still apply, right?

1840.56 -> So if you place them after the NAT gateway,

1842.96 -> you'll lose the visibility of the source IP.

1845 -> Place them before you'll see the source IP.

1847.28 -> Unlike ingress though, typically in this outbound scenario,

1850.67 -> we typically favor the more specific routing approach

1853.55 -> because there's really not that many trade off there.

1856.16 -> But whatever you choose, just bear in mind that you

1858.41 -> need to apply those rules for your use case, right?

1862.49 -> You will have to make your firewall rules use those.

1866.33 -> But there's a very interesting thing

1867.77 -> for the outbound scenario that we didn't mention

1870.11 -> at all for the ingress, right?

1871.88 -> Which is DNS.

1873.26 -> Most solutions out there, you know, most instances

1876.89 -> do not do IP, that direct IP communications, right?

1879.26 -> They first do a DNS lookup

1880.76 -> that's standard across the industry.

1883.34 -> And therefore that's another path

1885.77 -> that you should secure, right?

1886.85 -> The DNS outbound path.

1889.46 -> If you are on AWS, there's also here

1892.25 -> the at blade the DNS .2 resolver.

1894.77 -> For those that don't know what the DNS .2 resolver is,

1897.35 -> you're likely using it, of course,

1898.97 -> because that's the default DNS resolver.

1900.83 -> It sits on the .2 address of your VPC,

1903.53 -> and unless you change it to something else,

1906.02 -> that's a DNS resolver use to solve queries.

1909.47 -> So how can you secure this path?

1910.79 -> Can you use the firewall? What can you do?

1913.31 -> I need to introduce you yet another concept.

1915.71 -> We didn't do it in the beginning ones

1917.51 -> because this is sort of a different type of firewall.

1919.91 -> This is the DNS firewall.

1921.11 -> What is it?

1922.64 -> It's an AWS-managed DNS firewall.

1924.83 -> It allows you to block outbound

1926.9 -> DNS request from AWS, from your VPC.

1930.74 -> You can use managed rules, meaning AWS has that for you.

1933.41 -> Or you can create your own if you know,

1934.667 -> you know, your own malicious domain,

1936.23 -> you don't want your users to go to.

1938.66 -> Or simply you can do like a different

1940.01 -> approach and only allowing specific domains.

1941.9 -> That's kind of a very explicit report, right?

1946.31 -> How does it work?

1947.24 -> Well, since it's a feature of the Route 53 resolver, right?

1950.183 -> It's a feature on top of it.

1951.47 -> If you're already using, the .2 resolver is very simple.

1953.63 -> You just have to create these rules,

1955.64 -> choose which VPCs you wanna apply them to,

1958.04 -> and they automatically are applied

1959.45 -> before the DNS resolution comes through, right?

1961.31 -> So your instance goes to the .2 resolver,

1963.77 -> and the .2 resolver will check first the DNS firewall,

1965.837 -> and then it'll resolve the query.

1968.03 -> So very simple.

1970.07 -> But you might ask, well Ivo, then do I just use it

1972.86 -> and I don't need to use anything else?

1974.57 -> No. Don't, don't get that message for me, right?

1976.97 -> This is works in parallel.

1978.044 -> It works in tandem with the network firewall

1980.39 -> and/or with other firewall solution.

1982.37 -> So first your instance would do the DNS query.

1985.43 -> It would be filtered on the DNS firewall.

1987.8 -> And from there the data path would be filtered

1990.68 -> on the firewall that you have.

1991.88 -> This picture is a network firewall, but it could be

1993.537 -> a gateway load balancer, or something, right?

1996.86 -> So again, they work together so you secure both paths,

2000.1 -> the DNS path and the data path.

2003.55 -> This was a very shallow dive, okay?

2005.62 -> Like we've mentioned,

2006.453 -> the meat of this session was the inbound one.

2009.22 -> But I wanna refer you back to the NIS 305.

2012.97 -> It was a deep dive, one hour deep dive in outbound.

2015.46 -> So it'll talk about all these use case,

2016.81 -> DNS and all of those.

2018.79 -> There's small problem here,

2019.84 -> which is this session happened yesterday.

2022.03 -> So I guess if you have a time machine you can go,

2024.46 -> but if not, I would really urge you to use

2027.37 -> the on-demand platform to watch it.

2030.37 -> And last consideration that I wanna talk about outbound

2033.16 -> before I move on to a summary

2034.72 -> is that the WAF does not apply, right?

2036.34 -> If you look back to this picture, you'll see

2038.14 -> there's no WAF in there, for those that notice it.

2040.51 -> If you're wondering, the reason

2041.56 -> is because WAF is an ingress construct, right?

2043.69 -> So WAF is not used to secure an outbound path.

2049.36 -> Now this slide, I will not talk specifically about it.

2052.03 -> What I want you to do if you have a phone,

2053.47 -> you know I see you guys taking your phones up.

2054.97 -> That's great, That's what I want you to do.

2056.62 -> This just a summary, side-by-side summary

2058.93 -> so you can compare all of the solutions

2060.67 -> we talked through minus the DNS firewall.

2062.83 -> And you can have like a good idea when you're trying

2065.02 -> to decide on a use case, where do they apply,

2066.76 -> what type of path, what type of layer,

2069.04 -> and what type of feature, right?

2070.45 -> It's just to refer back to the slide.

2073.33 -> And now off to Buzor on this practical uses of this.

2077.95 -> - Yeah, thanks Ivo.

2079.69 -> Hello everyone.

2082.51 -> I'm here to...

2083.8 -> My name is Buzor Okoye, cybersecurity engineer at Workday.

2087.64 -> I'm basically here to talk you through our firewall journey.

2091.27 -> How we moved from different firewall solutions we had

2094.66 -> in AWS to what we currently have now,

2097.9 -> and what we plan to have in the near range feature.

2103.15 -> So about Workday.

2104.53 -> Workday is a leading provider of enterprise cloud-based

2107.41 -> application for human capital management, HCM,

2111.49 -> financial management, product capability

2114.638 -> analytics and reporting tools.

2117.43 -> And our customers cut across the educational sector,

2120.61 -> the healthcare industries, financial services,

2123.82 -> government establishments, and technology companies.

2129.1 -> My team at Workday is the infrastructure

2131.47 -> security engineering and we are responsible

2134.23 -> for providing technical security solutions

2137.71 -> for protecting the Workday infrastructure.

2140.59 -> And this includes the on-prem data centers,

2143.68 -> the public cloud data centers,

2145.75 -> and of course the corporate network.

2148.81 -> My team is heavily focused on shift-left security.

2152.26 -> And what this means is that we try as much as possible

2155.41 -> to bake security into our products

2157.72 -> from the very beginning of the development cycle.

2162.85 -> So our initial landed in the AWS cloud.

2166.75 -> When we first landed in the AWS cloud,

2169.78 -> I mean considering that we had a working model on premises,

2173.5 -> and the fact that the cloud was relatively new

2176.92 -> to most of the engineers handling the project at that time.

2179.79 -> So we felt that the safest thing to do was to export

2183.97 -> the same firewall component we had on-prem into the cloud.

2188.11 -> And with that we will still preserve

2189.73 -> the same security posture we had on-prem.

2194.08 -> And the plan was that as time went on,

2196.78 -> we will look for ways to improve on this setup.

2200.56 -> So what was happening at that time is that our design looked

2204.07 -> more like what you're looking at on the screen.

2206.26 -> At the upper layer we had VM

2208.57 -> load balancers in active/active HA.

2211.84 -> And in the middle layer we had next generation

2215.11 -> firewalls inactive/standby HA.

2218.14 -> And then beneath that we had auto scaling group

2220.57 -> of Kubernetes workers.

2223 -> So what was happening here was that within each AZ,

2227.05 -> the next-gen firewalls were inactive/standby.

2230.05 -> So only one firewall was active at any time.

2233.38 -> And the result was most of the time high CPU utilization

2236.98 -> on the part of these next gen firewalls.

2239.44 -> We also discovered that the engineers spent

2241.66 -> quite a good amount of time supporting this firewall.

2244.78 -> So we thought that it was about time

2247.21 -> we improved on this setup.

2250.03 -> So what we did was first of all identify the areas we needed

2253.78 -> to improve, and then ways to improve on these areas.

2257.8 -> We identified the CPU/memory utilization issue.

2261.52 -> Improve on system availability.

2263.86 -> And as well manageability and support.

2266.8 -> The first thing we did to solve the prevailing

2270.22 -> load issue on the next-gen firewalls was to separate

2273.16 -> the firewalls based on their functionalities.

2276.28 -> So we had some next-gen firewalls to handle

2279.07 -> inbound inspection and another set

2281.32 -> of next-gen firewalls to handle outbound inspection.

2284.65 -> And that helped us to kind of fix

2287.59 -> the prevailing performance issue at that time.

2290.29 -> And we also thought that these firewalls

2292.54 -> should be able to at least scale horizontally

2295.42 -> with increased load in the cloud.

2298.15 -> And then, for system availability, we thought

2301.093 -> that we should have these firewalls in active/active state,

2304.3 -> They should be able to share states.

2306.43 -> And with that, if we need to carry a maintenance upgrade

2309.07 -> on a firewall, we could easily drain

2312.52 -> a subset of the firewalls in the cluster, upgrade them,

2316.66 -> and return them back to the fleet without

2319.18 -> impacting on production traffic.

2322.391 -> For manageability and support, we started conceiving an idea

2325.72 -> of having a region-based inspection VPC,

2328.93 -> where would direct all traffic within the organization

2331.93 -> into this inspection VPC, carry out policy enforcement,

2337.66 -> and only allow clean traffic in and out.

2341.23 -> And most importantly, we maintain our shift-left principle.

2345.94 -> We want dev teams and service teams

2347.95 -> to be able to manage these firewall solutions.

2351.43 -> We want to be a the supervisory layer only ensuring

2355.15 -> that their design, their deployments are all in line

2358.09 -> with the Workday security standard.

2361.3 -> So we had two design options at that time.

2365.62 -> One was Amazon VPC traffic mirroring,

2368.26 -> and the second was the Gateway Load Balancer.

2373.27 -> So in the design for the VPC traffic mirroring,

2377.44 -> ingesting traffic from both the ingress

2379.75 -> and the egress nodes, a copy of it actually

2383.11 -> because it's mirroring, is sent to the mirror targets.

2387.13 -> And this mirror target behind that is scalable,

2391.06 -> this next-gen firewall.

2393.04 -> And with this solution we are able to achieve

2395.53 -> out of bound traffic inspection a firewall

2398.68 -> could scale horizontally, which was what we wanted.

2402.28 -> And this is a very good fit

2404.71 -> for our region-based inspection VPC.

2408.7 -> And we'll still utilize the rich threat

2411.94 -> and virus signatures of these next-gen firewalls.

2416.71 -> But then here is a problem.

2418.78 -> We are moving from a solution that allows us to enforce

2421.93 -> policy to a solution that only detects malicious traffic,

2427.6 -> because by default this solution works as an IDS.

2431.83 -> And as such, this did not go

2434.68 -> beyond the proof-of-concept stage.

2437.65 -> And we are left with the second option,

2440.47 -> which is the Gateway Load Balancer.

2443.56 -> I kind of feel that the support for GENEVE protocol

2446.92 -> in AWS was more like a game changer to the way firewalls

2451.3 -> are currently deployed in the AWS cloud.

2455.08 -> And in this setup we direct all outbound traffic

2459.16 -> to the Gateway Load Balancer endpoint for inspection.

2462.61 -> We also direct inbound traffic from the public

2465.52 -> internet to the gateway load balancer endpoint.

2468.07 -> And beneath that is this scalable next-gen firewall

2472.15 -> that still had the previous policies we had.

2474.97 -> We can achieve inline traffic

2476.83 -> inspection and policy enforcement.

2479.86 -> The firewalls could scale horizontally,

2482.68 -> which is what we wanted.

2484.9 -> But the idea of inspection VPC did not fly because we felt

2491.8 -> that there could be quite a lot of risk associated with it.

2495.34 -> So we ended up deploying this solution in the same VPC

2500.38 -> as our application, and we ended up to achieve both inbound

2504.46 -> and outbound inspection using the same firewall.

2509.2 -> So, but then as time went on we discovered that we are still

2513.79 -> maintaining and supporting these next-gen firewalls.

2518.44 -> Our initial idea of handing of this solution

2522.49 -> for the dev teams did not really fly even though

2525.85 -> we have all automations in place for teams

2530.95 -> to just plug and play and deploy this solution.

2534.007 -> But you agree with me that some level

2535.93 -> of firewall expertise is still required for this.

2539.83 -> And such, we were still managing this solution.

2544.18 -> So we felt that we needed something else.

2547.18 -> We needed a managed solution.

2549.58 -> We thought we needed a managed firewall at this point.

2552.88 -> And here comes the AWS network firewall.

2556.69 -> So we had a working application VPC.

2561.67 -> And how do we get the AWS network firewall

2565.36 -> into our infrastructure that is

2567.91 -> already working with this next-gen firewall?

2570.49 -> So we thought that it would be good to use the centralized

2574.87 -> model and what this allows us to do is to deploy

2580.96 -> the AWS network firewall VPC side-by-side

2585.31 -> at our existing application VPC.

2589.99 -> We tuned the policies of these next-gen firewalls,

2593.26 -> carry out our performance testing,

2595.78 -> stress testing, and vulnerabilities scanning

2598.57 -> on the two infrastructure.

2600.58 -> And if the result looks good, if we have confidence

2604.48 -> in this setup, then we can make a case to seamlessly

2609.64 -> cut over traffic to the AWS network firewall VPC.

2614.62 -> And that worked the way we wanted it,

2617.83 -> and we were able to route traffic from the existing

2620.32 -> VPC that had our application with the gateway

2623.86 -> advancer endpoint to the VPC that has

2627.19 -> the AWS network firewall via the transit gateway.

2633.25 -> For logging, we are sending logs to CloudWatch

2636.793 -> and then from CloudWatch we are shipping

2639.1 -> to our Splunk endpoint using AWS Kinesis.

2644.95 -> And the traffic flow for the AWS network file VPC,

2649.87 -> all traffic from our applications are forwarded

2652.06 -> to the transit gateway and then from the transit gateway

2655.66 -> to the network firewall subnet for inspection,

2660.85 -> and then en route to the internet.

2663.04 -> The inbound traffic goes the reverse way

2665.44 -> from the public internet to the inspection VPC,

2669.82 -> down to the transit gateway, and then on to the application.

2674.17 -> Is what you wanted you to know that all

2675.97 -> outbound traffic is hidden behind the NAT gateway

2679.27 -> within this AWS network firewall VPC.

2684.01 -> Yeah, but what's happening at this point

2686.65 -> is that the adoption rate for this set up from our service

2690.67 -> teams and dev teams, we are more like about 40 to 45%.

2696.037 -> The teams that were the early adopters were the teams

2700.48 -> that had mostly static setup, static network infrastructure.

2704.83 -> The guys that would normally update their network

2707.35 -> infrastructure did not really adopt this solution initially.

2713.35 -> So we started thinking about how about to have

2717.4 -> a solution that deploys the network firewall

2721.09 -> in the same VPC as the application.

2724.3 -> So we came up with the design of this distributed model.

2730.27 -> All outbound traffic sent to the AWS

2734.08 -> network firewall for inspection and for the AWS

2737.08 -> network firewall to the public subnet.

2740.32 -> And for inbound traffic we have edge association

2745.45 -> and we have a route table that's also sent

2749.35 -> inbound traffic to the network firewall for inspection.

2753.16 -> And this is probably, we will say is a simpler model

2757.39 -> and there was no reason why other teams will not adopt this.

2764.17 -> We developed a playbook for this.

2767.74 -> We encourage teams to use the AWS strict order rule

2774.16 -> instead of the default rule because we

2776.53 -> found out that there are few advantages of doing this.

2779.77 -> And then we put ourself in a position

2782.02 -> where every solution that is being deployed,

2785.53 -> we are the ones to review and approve it.

2789.19 -> The last time I checked there were about 140

2792.43 -> network firewalls that are attached to policy.

2795.73 -> It's not really about the numbers,

2797.17 -> but the fact that, imagine if we are still

2799.87 -> the ones managing this network firewalls.

2804.31 -> So I'm going to go through a few use cases

2808.27 -> from our service teams and our dev teams.

2811.45 -> So these guys here, they manage a platform that for testing

2818.05 -> different components of the Workday application.

2820.75 -> And their requirement is pretty basic.

2823.09 -> They needed an application-level inspection

2826.72 -> and application-level logging.

2828.64 -> Something beyond what they could get

2830.14 -> with the AWS security groups.

2832.3 -> And they practically just had to create an extra subnet

2835.09 -> for the AWS network firewall and then routed all outbound

2839.5 -> traffic to the AWS network firewall for inspection.

2843.67 -> And they're able to get the application-level

2846.224 -> inspection and logging which they wanted.

2849.25 -> They also have some custom Suricata rules.

2852.52 -> And they utilize the AWS managed rules as well.

2857.59 -> This other team, they manage the platform

2863.08 -> for installing software based on Kubernetes and Helm.

2866.97 -> So you expect that there will be different types of nodes,

2872.23 -> worker nodes within their infrastructure.

2875.29 -> And their use case is for outbound filtering

2879.4 -> based on the real IPs, and then inbound filtering

2882.85 -> on the internet based on the real IPs as well.

2886.66 -> But because they have all their workloads deployed

2889.45 -> in the private subnet and they have clients IP

2892.51 -> preservation enabled on the network load balancers,

2896.539 -> for them to not go into risk of happening,

2901.87 -> they deploy two network firewalls in their infrastructure.

2905.74 -> This is okay by us.

2907.51 -> We don't really have a problem with that.

2911.05 -> They also build quite a few automations in their deployment.

2914.95 -> One is that they use the network

2916.96 -> firewall Kubernetes operator.

2919.33 -> What this operator does is that because the workloads

2923.83 -> change by IP addresses, so they created

2926.5 -> an IP set for the AWS network firewall policy.

2930.34 -> And this operator updates the IP set with the IP address

2935.08 -> of the workers whenever it changes.

2937.39 -> And they use network firewall controller

2939.7 -> to deploy the network firewall as well.

2943.96 -> There's also another use case for the work

2947.56 -> in conjunction with our trend intel's team to block

2951.37 -> certain IP address inbound to the infrastructure.

2954.28 -> So there's a Lambda function

2957.25 -> within the network that kind of updates

2961.42 -> this IP sets whenever the IP address changes.

2966.22 -> So going forward, we are currently using the AWS firewall

2972.85 -> manager and resource assess manager to share

2976 -> a rule groups and policy within our organization.

2980.08 -> And the idea is that we have this as a single source

2984.07 -> of truth for all environments,

2987.04 -> all our deployments within the organization.

2990.19 -> And in case of a zero-day, for example,

2992.53 -> we could enforce policy to all the network firewalls

2997.75 -> deployed within the organization.

3000.87 -> We continue to make improvement on the Suricata rule groups

3005.31 -> and we hope to start utilizing some of the newly supported

3009.99 -> features in the AWS network firewall.

3012.24 -> For example, the tag-based resource group, inbound TLS

3015.93 -> inspection, and then support for symmetric routing.

3020.85 -> We also hope to start using

3023.43 -> the geo-IP blocking when it's supported.

3027.06 -> And then we continue to engage the AWS solution architect.

3034.59 -> Thank you.

3037.74 -> - Think it was...

3039.06 -> And now the last slide, really.

3041.4 -> if you can't remember anything else rather than the picture

3043.44 -> you took before, I want you to remember this, right?

3045.076 -> That's all we need today.

3047.16 -> So first of all, use security groups, right?

3049.38 -> You guys are probably already using it,

3051.54 -> but use them explicitly rather than, you know,

3053.79 -> just 0, 0,0 open everything.

3055.77 -> I'm using a security group.

3056.88 -> No, please have them, you know,

3057.713 -> specific network config here.

3061.83 -> If you need to centralize your management,

3063.33 -> for most of the solutions like you've seen

3064.98 -> there supporting the WAF, firewall security groups,

3067.14 -> you need to centralize that.

3068.82 -> Firewall Manager is probably the way to go.

3070.56 -> Simple. Supports a bunch of solutions.

3072.63 -> So go for that.

3074.37 -> Then as you've seen in this session, different firewalls,

3078.36 -> different architectures of those firewalls

3079.8 -> will give you different features.

3081.33 -> So start from your requirements,

3082.56 -> what you need from your security teams,

3084.27 -> work from there and you'll surely find a solution.

3088.59 -> Then, as Tzoori mentioned, we want you

3090.42 -> to start protecting as early as possible.

3092.31 -> So, start from the edge,

3093.3 -> don't let the trench get deep, right?

3095.34 -> So start there.

3096.57 -> And on top of that, protect in multiple places, right?

3099.33 -> So start at the edge, then in the edge of your VPC.

3102 -> For example, use security groups in the network firewall.

3104.01 -> You know, use security groups and network ACLs.

3106.05 -> Don't stick to single one and protect as early as possible.

3110.61 -> And lastly, of course, if you have known edge DB traffic,

3114.57 -> right, just focus on network firewall,

3117.42 -> gateway load balancer with that firewall, right?

3120.21 -> So this is the five takeaways that I want you

3123.15 -> to take with your home and apply.

3126.48 -> And that's all folks. Thank you.

3128.705 -> (audience claps)

Source: https://www.youtube.com/watch?v=lTJxWAiQrHM