AWS re:Invent 2020: Use AWS Firewall Manager to audit overpermissive security groups
AWS re:Invent 2020: Use AWS Firewall Manager to audit overpermissive security groups
Centrally auditing VPC security groups for overpermissive rules is often a requirement. As the number of security groups increases, users also want to monitor them organization-wide. In this session, learn how you can centrally monitor VPC security groups for overpermissive rules using AWS Firewall Manager. Learn about the newly released managed policies, which provide preconfigured checks you can readily enable for auditing your VPC security groups. In addition, learn about the details dashboard to give visibility into violations while offering remediation options across all accounts.
Learn more about re:Invent 2020 at http://bit.ly/3c4NSdY
Subscribe:
More AWS videos http://bit.ly/2O3zS75
More AWS events videos http://bit.ly/316g9t4
#AWS #AWSEvents
Content
1.36 -> hello everyone and welcome to this
3.36 -> session
4.08 -> my name is adish bhobi and i'm a senior
6.319 -> product manager
7.2 -> at aws and in this session we're going
9.679 -> to talk about how you can use aws
11.679 -> firewall manager
12.96 -> to audit any over permissive security
14.96 -> groups in your organization
18.24 -> so here's the agenda for this session
20.32 -> i'll start
21.359 -> with a quick introduction of the service
23.279 -> aws firewall manager
25.039 -> followed by that i'll cover some of the
26.96 -> current challenges that you as a
28.64 -> security administrator face
30.48 -> when it comes to auditing for any over
32.64 -> permissive rules in your security groups
35.68 -> i'll then deep dive into some of the
37.36 -> current as well as new capabilities that
40.16 -> firewall manager offers for you to audit
43.28 -> any security
44 -> groups in your organization and then
46.079 -> i'll also supplement that with a few
48.32 -> demos that will showcase some common
50.8 -> scenarios
51.76 -> for which you can audit for using
53.28 -> firewall manager and then
55.12 -> in the end i will leave you with a few
58.48 -> resources for you to get started
63.039 -> so to level set for anyone who doesn't
66.08 -> know
66.96 -> firewall manager is a security
69.36 -> management service
70.72 -> that is leveraged by security
72.72 -> administrators like yourself
74.64 -> to configure and deploy firewall rules
78.32 -> and policies across an entire
80.159 -> organization
81.6 -> this could be across accounts or
83.68 -> resources that you have
85.52 -> in your organization and even as new
88.4 -> accounts and resources are created
90 -> firewall manager consistently enforces
92.4 -> those
93.28 -> firewall rules and we see security
96.479 -> admins today
98.159 -> across different organizations use
100.24 -> firewall manager
101.6 -> to centrally deploy aws wav rules
104.72 -> to deploy ddos protections offered by
107.84 -> shield advanced and also configure vpc
110.799 -> security groups and audit
112.399 -> vpc security groups for any over
114.32 -> permissive rules
116.399 -> in addition you can also view any
118.799 -> security notifications
120.799 -> offered by firewall manager on security
123.439 -> hub
123.84 -> alongside other security services
127.439 -> now in this session we'll only focus on
130.08 -> how you can audit
131.44 -> uh any of your vpc security groups for
134.16 -> all permissive rules
136 -> and for any uh security admin
139.12 -> or security engineer who's listening to
140.959 -> this session
142.319 -> you'll relate to the fact that
144.239 -> oftentimes
145.36 -> your security groups can end up being
148.239 -> over permissive for a variety of
149.92 -> different reasons
151.44 -> now we know that security groups are
155.44 -> virtual firewalls for your ec2 instances
158.8 -> and you can enable rules to have inbound
161.36 -> and outbound traffic going in and out of
163.44 -> those ec2 instances
165.12 -> uh but oftentimes uh they can end up
167.68 -> being over permissive because
169.44 -> of very wide sider ranges or
174.08 -> port ranges that are too permissive or
176.959 -> because there
177.68 -> are applications such as ssh or rdp
181.04 -> that may have been exposed to the
183.36 -> internet
184.159 -> and so you want to make sure that such
187.12 -> applications and such
188.239 -> rules are tracked audited
191.76 -> and finally remediated however there are
194.56 -> some challenges
195.84 -> when it comes to auditing and monitoring
198.48 -> for these over permissive vpc security
200.8 -> groups
201.84 -> and again for any security engineer or
205.92 -> any security administrator who's part of
208.319 -> a larger security team
210.56 -> you will hopefully relate to some of
212.319 -> these challenges that i'm going to talk
214 -> about
216 -> so first uh you'll see a lot of times
218.959 -> that security groups are
220.4 -> owned by individual application
222.4 -> developers within an organization
225.04 -> and uh because these are owned by
228.319 -> these application developers they may or
230.48 -> may not always
231.84 -> adhere to the centrally mandated set of
234.4 -> rules that you as a security admin
236.879 -> want to enforce uh while
240.159 -> uh application developers are rapidly
242.799 -> creating
243.76 -> uh resources uh and applications um
246.879 -> it may or may not always be their focus
249.84 -> to have
250.72 -> security uh as part of that and so
255.2 -> with that the second key challenge is
258.079 -> also to constantly
259.519 -> keep track of all the changes that are
261.759 -> happening
262.96 -> across your organization there may be
266 -> new applications or
267.28 -> changes to existing resources that are
270.4 -> happening within different accounts
272.4 -> and so maybe you have audited your
275.759 -> entire
276.56 -> infrastructure at some point but those
279.68 -> those changes might then trigger another
282.4 -> set of
283.68 -> audit checks that you may need to do
285.68 -> which can be very tight uh
287.12 -> cumbersome and error prone and tedious
289.919 -> to do at scale across your organization
293.68 -> and then the third challenge is is that
296.479 -> you would
297.199 -> also need to have central visibility
299.759 -> which is very hard and challenging to
301.44 -> have today on
302.639 -> across all your accounts and take
305.36 -> actions to remediate
307.28 -> this can particularly be challenging if
310.479 -> you
310.72 -> are part of a compliance team where you
313.12 -> want to ensure to
314.32 -> internal or external auditors that all
316.639 -> your applications
317.759 -> are adhering to certain mandated rules
320.96 -> but doing that at scale can can quickly
323.919 -> become
324.88 -> or take several weeks of job to do
328.16 -> across so in the next slide
332.32 -> um i want to talk about some of the key
335.52 -> capabilities that you as an admin
338.24 -> want to equip yourself with
342 -> and at the same time i want to talk
343.52 -> about some of the
345.039 -> features that firewall manager offers
347.6 -> that will help you
349.28 -> meet some of those gaps and overcome
351.44 -> some of those pain points
354.72 -> so the first thing that you as a
356.319 -> security admin needs
358.24 -> uh is to have a single central admin
360.72 -> account
361.44 -> from where you can monitor and audit all
364.639 -> your vpc security groups
366.4 -> across your accounts uh without having
368.88 -> to do that
369.68 -> manually on each and every single
371.199 -> account or a set of
373.28 -> production accounts that you have
375.199 -> grouped under organizational units
378.08 -> and so because firewall manager
380.24 -> integrates with aws organizations
382.8 -> it natively offers you that ability
386.319 -> to have a single account from where you
388.8 -> can deploy
389.84 -> audit rules across your accounts and
392.24 -> even as new accounts are created
394.08 -> firewall manager will automatically
395.68 -> detect those
397.199 -> and enforce those rules consistently
400.88 -> secondly um as as an admin
404 -> you often spend hours days sometimes
406.639 -> even weeks
408.479 -> configuring audit checks for certain
411.039 -> compliance
411.759 -> needs that you have within your team and
414.96 -> when those configurations change you'll
416.88 -> have to
417.919 -> once again go back and reconfigure all
420.08 -> those changes
421.039 -> and that can be tedious if you're doing
423.28 -> that across
424.08 -> different accounts and different subsets
425.759 -> of accounts
427.199 -> and so firewall manager offers you
430.16 -> managed policies
431.599 -> that we recently launched this year to
434.16 -> help you
434.88 -> audit and remediate for these over
436.8 -> permissive rules
438.24 -> and these are nothing but pre-configured
441.12 -> rules and pre-configured audit checks
443.12 -> that you can
444.24 -> readily enable across your entire
446 -> organization with minimal
448.24 -> configuration and minimal configuration
450 -> steps and so it takes away a lot of the
452.56 -> heavy lifting
453.44 -> and operational burden of configuring
456.56 -> rules and reconfigure them
458.479 -> when any of those compliance needs
460.56 -> change
463.28 -> the third key aspect that you need
466.479 -> as a security admin is to make sure that
469.759 -> your
470.56 -> resources are continuously audited for
472.96 -> and that you have an audit ready
474.479 -> infrastructure
475.44 -> at all times this can again get
478.96 -> very tedious if you are doing that
481.28 -> across multiple accounts
482.879 -> and looking for tracking for those
485.759 -> changes
486.319 -> in those rules at all times
489.599 -> again over here because firewall manager
491.759 -> uses aws config in the background
494.4 -> it is able to continuously check for
496.96 -> those changes
498.24 -> on new or existing resources track them
501.44 -> and surface them to you in one single
504.84 -> account
506.319 -> and so all of this culminates with the
508.479 -> need
509.36 -> to also have a central dashboard and as
512.56 -> i talked about this before
514.32 -> as a security admin or an engineer you
516.64 -> want to have this
518.479 -> central reporting dashboard to view
521.599 -> all your non-compliant or permissive
524 -> rules
524.8 -> uh share it with your compliance team
527.12 -> and also report it to your internal
529.04 -> external auditors
530.56 -> um this can also be a
534 -> dashboard from where you can then take
536.16 -> the action to further remediate any of
538.64 -> those over permissive rules
540.24 -> and so firewall manager recently
542.16 -> launched a central reporting dashboard
545.04 -> where you can view all of these over
547.92 -> permissive rules
548.88 -> and take the necessary actions to
551.04 -> remediate them
552.08 -> further and so with that
555.92 -> i want to uh next go into a couple of
559.04 -> demos that will show how
560.48 -> all of this works in action and while i
563.279 -> do that i also want to walk you through
565.6 -> some of the key prerequisites that you
567.44 -> would need to equip yourself before you
569.6 -> can get started
570.88 -> and start onboarding on firewall manager
575.36 -> so there are three key prerequisites
577.44 -> that are required
578.56 -> to uh leverage firewall manager the
581.279 -> first thing
582 -> would be to have your organization uh
584.72 -> master player account
586 -> enable aws organizations in full feature
588.56 -> mode across
589.6 -> your to have all your accounts part of
592.32 -> this
594.64 -> secondly you would need to also enable
597.2 -> aws config
598.24 -> across all your accounts in all your
600.16 -> regions uh
601.519 -> and as i alluded to this before this
603.92 -> would be required
605.12 -> to continuously audit and check
608.16 -> for any changes in those rules and track
611.279 -> any new
612 -> resources that appear in your
613.68 -> organization
616.079 -> and then once these two steps are
617.519 -> completed they would also need to
619.68 -> designate
620.399 -> one of the accounts in your organization
622.399 -> as the firewall manager administrator
624.959 -> now this could very well be your account
627.519 -> from where
628.56 -> you can start creating audit checks
632.56 -> and deploying them across your accounts
636.32 -> uh and then also using firewall
638.399 -> management dashboard to view
640 -> all of those audit uh non-compliant
642.64 -> rules
645.279 -> so in my demo i want to showcase a very
648.079 -> common
648.72 -> scenario that you would see in your
651.2 -> organization where you have
652.959 -> your administrator this could be your
655.44 -> account
656.24 -> from where you want to then audit uh
659.12 -> security group
660 -> rules for your member accounts so i'm
662.88 -> going to demo this using my
664.8 -> account as the firewall manager
666.24 -> administrator to look for
668.079 -> over permissive rules in member account
670.24 -> 1 and member account
671.279 -> 2. and i'm going to do this using a
673.44 -> firewall manager policy
675.839 -> now a firewall manager policy is nothing
678.88 -> but
679.2 -> a set of configuration items including
682.079 -> the rules that you want to audit for
684.24 -> in your organization the actions you
687.44 -> want to take
688.32 -> when there is a match to this audit
690.079 -> rules which could be to just
692.48 -> get a report or to actually go ahead and
694.88 -> remediate those and delete them
696.399 -> or reconfigure them based on your audit
699.6 -> checks
701.44 -> and then based on the rules and the
702.88 -> action you would also need to define the
705.04 -> scope of where you want to deploy
707.2 -> these policies and rules
710.8 -> this could be the accounts and resources
712.8 -> that you want to specifically audit for
715.04 -> so for example you could say i only want
717.279 -> to audit
718.16 -> my accounts and resources in my broad
721.44 -> environment
722.88 -> and do that consistently even as new
725.92 -> accounts and resources are added
727.68 -> and you can do all of this using a
729.279 -> single firewall manager policy
731.839 -> and we'll see that in our first demo
734.639 -> where i want to
735.839 -> showcase a very common scenario that a
738 -> lot of
739.04 -> the security engineers watching this
741.04 -> session would relate to
742.959 -> where you want to look for any over
745.36 -> permissive side
746.32 -> ranges in your in your organization
749.839 -> uh where you have security groups uh
752.72 -> with
753.2 -> such source and destination destination
756.079 -> side
756.399 -> ranges and you want to detect these
759.2 -> security groups and then remediate or
761.279 -> take appropriate action
764.48 -> so to do that we'll switch
767.6 -> to our console and
770.88 -> we'll start by looking at member account
773.279 -> one so we are
774.24 -> on the vpc console
777.36 -> for our member account number one and
780.399 -> we want to look at the security groups
782.56 -> within this account
785.6 -> you can see there is a default security
787.279 -> group but we also have
789.04 -> a second security group
792.72 -> which has inbound and outbound rules and
795.68 -> if you look at the
797.839 -> source and a destination mentioned in
800.639 -> the
801.12 -> uh rules they can be considered to be
804 -> fairly over permissive because of
806.079 -> their uh the range of outsider prefix
809.2 -> length that they have
810.399 -> mentioned in the source and destination
812.839 -> field and so you want to make sure that
815.519 -> such
816.959 -> rules are audited for and
820.72 -> also mandate certain minimal
823.92 -> range that you want any of your
827.279 -> rules to have we also see that these are
830.079 -> tagged
830.8 -> under the prod environment uh and so
833.839 -> this can be
834.72 -> uh something that you definitely want to
836.8 -> audit for
837.839 -> now we'll switch to the aws firewall
839.68 -> manager console
841.199 -> where we have our admin account already
843.839 -> assigned
845.519 -> we can see that we have completed all
848.32 -> the prerequisites required
850.16 -> uh to onboard firewall manager including
852.8 -> the organizations and the config
854.839 -> requirement so we can begin by creating
858 -> a policy
858.8 -> to audit and once you do that
862.8 -> you'll see uh different options
865.199 -> depending on which policy type
867.68 -> you want to assign for our case we'll
871.36 -> jump right into security groups
873.12 -> and this opens up a host of different
875.519 -> options depending on your use case
877.68 -> for our use case we want to look for how
880.72 -> we can audit
881.68 -> and enforce certain security group rules
884.16 -> in our organization so we'll go with the
885.92 -> second option there
887.36 -> and then each uh firewall manager policy
890.399 -> is region based so you'll need to
892.32 -> specify which
893.44 -> region you want to enforce these rules
895.6 -> in
897.6 -> now this opens up a next step how you
900.48 -> want to describe your policy so we can
902.24 -> start by giving this policy a name
904.959 -> but along with that you can also define
906.88 -> what policy rules
908.72 -> you want to audit for and as we talked
912.16 -> about this before
915.199 -> firewall manager offers a set of managed
918.24 -> audit policies these are predefined or
920.16 -> pre-configured rules and audit checks
922.959 -> uh that require minimal configuration
925.44 -> and so for our use case where we want to
928.079 -> only look for uh
931.199 -> over permissive security group rules we
933.519 -> will select
934.24 -> the first option and
937.92 -> once we toggle this this opens up a
940.399 -> couple of
941.759 -> sub-options where you can specify what
945.04 -> protocols you want explicitly defined
947.68 -> within your rules
949.839 -> you can also deny the use
953.04 -> of all in the protocol section
956.399 -> within your target security groups you
959.36 -> can also deny certain rules having port
961.759 -> range greater than the number you
963.12 -> specify
964.24 -> you can also deny rules having ipv4
966.92 -> ipv4sider range
968.32 -> less than any number you specify and so
971.12 -> for our use case
972.16 -> where we want to detect for these over
974.24 -> permissive side ranges
976.16 -> uh we'll set the third option there
979.36 -> to 16. so anything uh less than 16 will
982.48 -> be flagged as over permissive
984.48 -> in the policy action uh it again
986.959 -> presents you with two different options
988.72 -> the first option
990.24 -> is where you can uh simply get a report
993.36 -> of all those over permissive rules
997.6 -> the second option is where you can not
999.759 -> just get that report but also remediate
1002 -> them
1002.959 -> based on what you consider to be over
1005.36 -> permissive
1006.56 -> so as a best practice we generally
1010.48 -> advise that you select just the
1012.079 -> identification before we go into
1014.24 -> the auto remediation moving on
1017.68 -> the next page opens up our different
1020.8 -> options where you can define where you
1022.88 -> want to apply these rules and this
1024.959 -> actions
1026 -> and this can be done across your
1028.799 -> accounts
1029.52 -> resource types and also you can scope
1032.24 -> them based on
1033.6 -> certain tagged resources that you have
1035.52 -> in your organization
1036.959 -> so you can be as far reaching or as
1039.039 -> specific as possible
1040.799 -> for our uh demo we'll only look at
1044.079 -> the member account number one that we
1047.039 -> want to audit for which is
1048.4 -> part of our production account you can
1051.679 -> also do this based on organizational
1053.52 -> units if you have them grouped under
1056 -> uh specific organizational units for
1058.4 -> prod
1059.039 -> or dev and then in the resource types
1061.679 -> you have the option to select
1063.6 -> uh whether you want to do this for
1065.44 -> security groups on ec2 instances
1067.52 -> enis or simply all the security groups
1070.72 -> in your organization
1073.44 -> you can also scope this based on tags
1076.48 -> so um for instance you can say i only
1079.52 -> want to
1080.72 -> audit for all the resources and all the
1083.12 -> security groups that are part of my prod
1085.919 -> environment so um as we looked at this
1088.799 -> earlier
1090.4 -> i'm only going to look at or only going
1093.039 -> to audit for
1094 -> any resource and security groups that
1096 -> fall under the broad environment
1097.679 -> and this becomes a very effective tool
1100.48 -> because then
1101.36 -> you can have your application developers
1103.28 -> quickly spin up their resources and tag
1105.36 -> them
1106.32 -> without worrying too much about the
1107.76 -> security configurations but then
1109.6 -> as a security admin you can use this uh
1112.799 -> scoping
1113.679 -> to put to ex exclusively only audit for
1117.679 -> those rules and those resources on that
1120.64 -> part of that environment
1124.32 -> in the next step uh this is an optional
1126.88 -> step where you can
1128.32 -> configure a tag for your policy if you
1130.559 -> wish to
1131.36 -> track this later and then in the last
1134 -> step
1134.4 -> this is where you review all the details
1136.48 -> of your policy
1138 -> and your actions and then once once
1141.039 -> you're satisfied with all of the
1142.64 -> details you can go ahead and create the
1144.64 -> policy
1146.48 -> so as you can see in just a few
1148.08 -> configuration steps we were able to
1151.12 -> create our audit policies and deploy
1154.32 -> them across
1155.039 -> different accounts and different
1157.36 -> resources
1159.12 -> so once the policy has been created in
1161.2 -> the background you'll have
1162.96 -> aws config deploying those and tracking
1166.32 -> those for any of the
1168.72 -> non-compliant rules or permissive rules
1171.679 -> that we have set
1175.28 -> so while it does that
1178.48 -> it's going to take a few moments to show
1181.12 -> any of those non-compliant
1182.559 -> accounts and once it displays those
1185.28 -> accounts
1185.919 -> which it just did
1189.039 -> we can then further explore this by
1192.16 -> going into the policy and seeing which
1194.24 -> account
1194.72 -> was non-compliant uh once it shows the
1198.24 -> account we can also look at
1200.24 -> the security groups and
1203.44 -> once we click on the security group this
1205.919 -> brings up
1206.88 -> the central reporting dashboard that i
1208.88 -> was talking about earlier
1210.96 -> this is the dashboard that showcases all
1213.919 -> the
1214.72 -> uh non-compliant or permissive rules in
1217.2 -> your organization
1218.559 -> so as we uh saw earlier this brings up
1221.919 -> the ingress and the egress rules within
1224.08 -> one of our member accounts uh security
1227.12 -> group
1228.32 -> and it is flagged as over permissive
1231.679 -> because of the uh cider range which is
1234.48 -> considered to be
1235.6 -> wide depending on based on the
1238.559 -> referenced audit rule that we set
1240.559 -> in the admin account uh it also provides
1244 -> you with the remediation action
1246.08 -> uh if you see that in the fourth column
1248.24 -> there
1249.679 -> and the remediation recommendation would
1252.32 -> be to modify that
1254.4 -> to match with the prefix range that
1257.52 -> we have specified in our audit check
1260.96 -> um you can also automate this
1264.559 -> by uh automatically remediating
1268.72 -> this uh security group uh in which case
1271.919 -> it will
1272.559 -> modify all of those rules uh to match
1275.679 -> with the security
1277.6 -> audit check that we have so in this case
1280.559 -> to do that you'll just
1281.76 -> have to go back to the policy action
1283.44 -> step and auto remediate
1286.4 -> um once the auto remediation kicks in
1290.08 -> it will go ahead and modify
1293.2 -> all the security groups and the security
1296 -> group rules
1296.96 -> to match with the minimal minimum
1301.44 -> side range that we have specified in our
1303.52 -> central account over here
1307.28 -> and so we can see that it's already
1311.28 -> been remediated so to confirm that we
1313.919 -> can
1315.039 -> then go into our
1318.08 -> demo section
1322.799 -> and we see that it is now compliant and
1325.039 -> to verify this on the member account
1326.96 -> side we switched
1328.159 -> to the vpc console for uh the member
1331.52 -> account
1332.559 -> and if we look at the inbound and the
1336.159 -> outbound rules
1337.28 -> that were previously over permissive we
1339.12 -> can now see that they are now matching
1340.96 -> with the
1342.64 -> minimum prefix length that we specified
1345.039 -> in our audit
1346.799 -> uh account firewall manager audit
1349.36 -> account
1351.36 -> and so this makes it really easy with a
1353.2 -> few configuration steps to quickly track
1355.76 -> audit and then take the necessary
1357.76 -> remediation action to
1359.679 -> fix any of those rules across your
1361.679 -> organization
1363.2 -> so in the next demo uh i again want to
1366.4 -> talk about a very common scenario that a
1369.36 -> lot of
1370.08 -> the security engineers would experience
1373.2 -> where you want to audit for applications
1376.08 -> such as rdp
1377.28 -> or ssh that can be considered to be high
1379.76 -> risk
1380.4 -> when open to the internet um and you
1383.679 -> want to present
1384.64 -> these to maybe your compliance team to
1388.08 -> make sure that you are
1389.2 -> complying with all the necessary
1392.4 -> organizational standards and then also
1395.28 -> take the necessary actions to remediate
1397.2 -> these rules within your
1398.64 -> accounts so let's jump into the demo
1403.039 -> uh here we have a member account
1406.24 -> too
1410.08 -> and we'll again explore the security
1412.08 -> group for this member account
1415.12 -> which is the security group demo two
1417.76 -> we'll see that
1419.6 -> in the inbounds rules section we have
1421.679 -> two rules ssh and rdp
1424.48 -> applications that are exposed to the
1426.159 -> internet and
1427.76 -> these can be considered to be fairly old
1430.08 -> permissive
1431.2 -> so as a security admin
1435.76 -> you would want to audit and look for
1439.2 -> these security groups and quickly
1440.72 -> remediate them
1442.24 -> to prevent any undesired traffic from
1444.64 -> hitting your
1445.679 -> applications so in order to do that
1448.08 -> we'll once again go back to the file
1450.08 -> manager dashboard
1451.76 -> uh for our account and we'll start by
1454.08 -> creating the policy for auditing
1458.32 -> and in the describe policy section over
1460.96 -> here
1462 -> this time uh we'll while we're still
1464.64 -> focusing on the managed policy
1466.64 -> uh we will just we'll select how you can
1469.52 -> audit for
1470.32 -> high-risk applications so by selecting
1472.559 -> or toggling this option
1474.799 -> you have a couple of sub-options where
1477.2 -> you can say what applications you want
1479.12 -> to specifically
1480.24 -> allow access to local cider ranges
1483.76 -> or what applications that you want to
1485.44 -> specifically have public
1487.6 -> access to such as zero zero
1491.039 -> for our use case we'll only select the
1493.76 -> second option so we'll specify
1496.08 -> what applications you want to enable to
1500.08 -> have public access and you can
1502.08 -> create your own applications
1507.279 -> by giving a protocol name an application
1509.84 -> name
1511.039 -> and a port number
1515.12 -> alternately you can also choose one of
1518 -> our
1518.72 -> predefined set of applications that we
1520.72 -> provide
1523.039 -> and if you look into this uh list of
1525.6 -> applications these
1526.559 -> are very commonly seen applications that
1528.72 -> are open to the
1529.6 -> or exposed entrance such as http and
1531.76 -> https so
1533.36 -> um anything other than http and https
1537.039 -> will now be flagged as over permissive
1539.6 -> and will be resurfaced as non-compliant
1542.72 -> again in the policy action we only want
1546 -> to first identify those
1547.84 -> resources and then take the step to
1550.72 -> remediate further
1552.72 -> to scope this policy uh we will
1556.24 -> look at only member account 2
1560.88 -> for our use case so in order to do that
1563.84 -> we'll select
1565.039 -> the second account here
1569.279 -> and then um in the resource type
1572.4 -> and the resource tagging section again
1575.12 -> we will only look for resources that are
1577.36 -> tagged with an environment
1579.919 -> prod because we only want to make sure
1582.4 -> that any of the resources in the product
1584.559 -> section
1585.36 -> for those accounts will be flagged as
1588.559 -> over permissive
1590.64 -> and then uh we'll consider this step to
1593.679 -> be optional
1594.96 -> to tag the policy but then as a last
1598.24 -> step we will then review
1599.84 -> and create the policy if all the details
1602.24 -> look good
1604.08 -> so again as you can see in just a few
1607.12 -> configuration steps you are able to
1610 -> create an audit check for
1613.52 -> your accounts and look for these
1617.919 -> different applications to make sure that
1620.4 -> they are not
1621.039 -> exposed to the internet and once
1624.159 -> firewall manager surfaces these
1627.76 -> non-compliant accounts we can then uh
1632.4 -> further explore by digging into the
1635.44 -> policy
1636.4 -> and the account so we see that the
1640 -> member account two this time is
1641.76 -> non-compliant and if we look at the
1643.44 -> security group
1645.919 -> this again brings up our centralized
1648.559 -> dashboard
1649.52 -> showcasing um the different rules that
1652.32 -> were flagged as over permissive
1654.48 -> so in this case you have uh ssh and rdp
1657.84 -> both in the ingress rules within
1659.919 -> that account that were flagged as
1662.48 -> non-compliant
1663.76 -> and considered to be over permissive
1665.44 -> based on the audit checks that we have
1669.679 -> if you look at the fourth column it also
1673.2 -> recommends you that you take the
1675.84 -> remediation action to remove the rule
1677.919 -> and again you can automate the
1679.919 -> remediation action
1681.2 -> through firewall manager
1684.88 -> and this can be done by again going back
1687.2 -> to the policy details page
1692.159 -> and then switching the action of the
1694.24 -> policy
1695.279 -> from just identifying to actually auto
1697.84 -> remediate
1698.96 -> remediating those rules
1703.039 -> once those rules have been auto
1705.679 -> remediated
1707.76 -> you can confirm that by looking at the
1711.36 -> account
1714.08 -> and again to verify this on the member
1716.159 -> account side we will
1717.44 -> switch to the vpc console
1720.96 -> and look at the rules in this
1724.32 -> security group as you can see now those
1727.039 -> rules
1727.6 -> have been remediated they have been
1729.12 -> deleted from the
1731.2 -> child account that was considered to be
1733.919 -> non-compliant
1736 -> again this provides you with a very easy
1738.159 -> to use
1739.84 -> set of configuration checks that you can
1741.919 -> quickly enable with
1743.2 -> minimal configuration without having to
1745.52 -> do a lot of
1746.32 -> uh heavy lifting at your end
1749.44 -> so um i want to recap and summarize what
1752.72 -> we have learned so far
1755.2 -> we have just seen in the demo how you
1758 -> are able to
1759.36 -> create these rules we talked about what
1763.36 -> challenges you as a security
1764.88 -> administrator face when it comes to
1766.799 -> monitoring and auditing for
1769.2 -> security group rules that could be
1770.72 -> considered over permissive
1772.24 -> and do that at scale
1775.279 -> we talked about how you can use firewall
1778 -> manager
1778.559 -> and leverage the managed policies that
1780.88 -> we launched this year
1782.24 -> to enable these out-of-box rules and
1786.159 -> check
1786.64 -> for any over-permissive rules
1790 -> we then dove into some of the scenarios
1792.48 -> where you could analyze different
1793.76 -> violations
1795.12 -> on a centralized dashboard and then
1797.52 -> based on the
1798.399 -> recommended remediation actions you can
1800.88 -> then go ahead and modify or delete those
1803.039 -> rules from your
1804.159 -> organization so as a last step i want to
1808.08 -> leave you with a few resources so that
1809.919 -> you can get started
1810.96 -> and start using our service uh first
1814.32 -> you can visit our website and you can
1816.72 -> start using
1817.76 -> the managed policies from the console or
1820.32 -> the api
1822.64 -> and then we also launched an aws
1825.279 -> solution
1826 -> which is a reference solution to help
1828 -> you automate
1829.2 -> the setup of all the firewall manager
1831.52 -> prerequisites
1832.96 -> you can also use this cloud formation
1835.6 -> stacks it's offered by the solution to
1838.159 -> quickly spin up all the managed audit
1840.32 -> checks that we talked about in this
1841.76 -> session
1844.559 -> and with that we have come to the end of
1846.799 -> this session
1847.76 -> thank you for listening and hope you
1850.159 -> enjoyed
1852 -> and we look forward to your feedback as
1854.08 -> always
1855.039 -> thank you
Source: https://www.youtube.com/watch?v=7CX0cyrfVZQ