The document discusses best practices for migrating and managing security in an AWS environment, focusing on AWS firewall policies, security groups, and network access control lists (NACLs). It highlights the importance of understanding security configurations, modular policy organization, and achieving visibility in hybrid cloud environments. Additionally, it provides insights on challenges and tips for managing AWS security efficiently while addressing integration with traditional firewalls.

1. MIGRATING AND MANAGING
SECURITY IN AN AWS
ENVIRONMENT- BEST PRACTICES
Edy Almer, VP Product

2. AGENDA
• Introduction to Amazon AWS Firewall and Security Groups
• AWS Network ACLs
• Challenges, pitfalls, and tips for a manageable AWS firewall policy
• Visibility in the AWS firewall
• Hybrid environments: AWS firewall alongside traditional firewalls

3. HOW ARE YOU USING AWS?
• In production – for over 50 instances
• For Shadow IT and under 50 instances
• Planning to use AWS within 6 months
• Planning to use AWS within the next 12 months
• No current plans, just interested in learning more
Please vote using the “votes from audience” tab in your BrightTALK panel

4. INTRODUCTION TO AMAZON AWS

5. WHAT AMAZON PROVIDES
• Rent servers
• Compute boxes (EC2)
• Storage (S3)
• Networking
• Low cost
• Outsourced – No IT department
• Elastic (power-up/shut-down lots of servers fast)
• Web UI, and programmable web-service API

6. WHAT ABOUT SECURITY?
• Amazon guarantees tenant/tenant separation
• But what about filtering policy (firewalls) for:
• Internet <-> Amazon-server,
• Amazon-server <-> Datacenter
• Amazon-server <-> Amazon-server
• Amazon’s solution: “AWS firewall”
• Free (price included in the server cost)
• Embedded in infrastructure

7. AWS FIREWALL: SECURITY GROUPS

8. SECURITY GROUPS – BASICS
• A key concept in AWS is “Security Group”
• A Security Group is a list of rules
• Comparable to a Check Point “Policy” or Cisco “Access List”
• Has a name
• A Security Group is associated with an instance:
• Like a “host-based firewall”

11. ZOOM INTO RULES: WHERE IS THE DESTINATION?

12. SECURITY GROUPS – DETAILS
• Consists of 2 lists of rules: Inbound and Outbound
• One side of the rule is implicitly “me”
• Inbound rules: from <Somewhere> to “me” with service S
• Outbound rules: from “me” to <Somewhere> with service S
• “my” IP address is not listed in the rule
 Result: the security group can be associated with any instance
without any modification

13. INBOUND RULES

14. OUTBOUND RULES

15. SECURITY GROUPS – MORE DETAILS
• All rules are “PASS” rules
• Not an oversight but a deliberate feature
• Rules do not perform NAT
• The instance can have public and private IP addresses
• AWS infrastructure takes care of this
• The order of rules inside a Security Group does not matter

16. SECURITY GROUPS AND INSTANCES: MANY TO MANY
A Security Group can be associated with many instances
An instance can be associated with many Security Groups!
• This is a unique AWS innovation
Why this works:
• All rules are PASS rules
• The order of security groups on an instance does not matter

18. AWS FIREWALL: NETWORK ACCESS LISTS
(NACL)

19. NACL– BASICS
• A Network Access List (NACL) is also a list of rules, with a name
• Has separate Inbound and Outbound rules
• One side of the rule is implicitly “me”
• Similar to Security Groups
• A NACL is associated with the Subnet:
• Applies to traffic into and out of all instances in the Subnet
• “me” in NACL rules is really “all instances in the Subnet”
• A Subnet can have a single NACL
• An instance belongs to a single Subnet
• … so at most one NACL applies to each instance

20. NACL– EVALUATION ORDER
• A NACL can have both Allow and Deny rules
• So rule order matters inside a NACLs
• Traffic incoming into an instance is evaluated against:
1. The one NACL associated with the Subnet
2. Then all the security groups associated with the instance (in some order)
• Traffic outgoing from an instance is evaluated against:
1. All the security groups associated with the instance (in some order)
2. Then the one NACL associated with the Subnet
• Traffic must be allowed by both the NACL and some Security group

21. Control rule order
inside a NACL
Deny rules

22. TOPOLOGY AND 3RD PARTY FIREWALLS

23. 3RD PARTY FIREWALLS
• Both NACLs and Security groups have rule number limitations
• 3rd party firewalls have layer 7 capabilities, no such ceiling
• Many have integrated IPS, AV, other capabilities

24. AWS-Based 3rd Party Firewalls
24 | Confidential
• Traffic filtered by a 3rd party firewall inside the Amazon estate

25. The Full Picture
25 | Confidential

26. ARE YOU USING?
• Security Groups
• NACLs
• 3rd Party Firewalls
• Any combination of the above
• None
Please vote using the “votes from audience” tab in your BrightTALK panel

27. CHALLENGES AND TIPS

28. HOW TO ORGANIZE THE POLICY?
Things to think about:
• Modularity
• Making it understandable
Suggestions:
• General manageability Security Group (e.g., per OS)
• Specific functionality Security Group (e.g. by application)

30. • SSH access to command line (Linux)
• NTP to synchronize clocks
• ICMP to allow network troubleshooting (ping)
• Etc…

31. • Web Access etc…

32. NACL OR SECURITY GROUP?
• NACL are broader: applied to a whole Subnet
• NACL can have Deny rules
Possibilities:
• Put black-list IP ranges in NACL
• If all Subnet should use a small list of services:
• Allow (only) those services in NACL, drop the rest
• In Security Groups only do IP-address-based filtering (Service=Any)
• Or the other way around:
• IP-based filtering in NACL
• Only service-based filtering in Security Groups (Source=Any)

33. Broadly allowed services
(from anywhere)
Black-List

34. PITFALL: TOO MANY SECURITY GROUPS PER INSTANCE
Keep it understandable:
• Which policy protects a particular instance?
• Don’t forget the NACLs too
KISS principle: Keep It Simple…
Security Groups per Instance
1-2 Simple
3 Borderline
4 or more Complicated

35. How to view the policy on an instance

37. • May be understandable – as long as policy is really simple…
• Not too many rules (without scrolling)
• Not too many Security Groups (without many columns)
• What about NACLs?
• No search…

38. PITFALL: FINE-PRINT LIMITATIONS
AWS limitations:
• At most 20 rules per NACL (in each direction)
• At most 50 rules per Security Group (in each direction)
• At most 5 Security Groups per instance
Grand total of 5 x 50 + 20 = 270 rules per instance
• These are not large numbers!
• Plan your policy carefully so you don’t run out

39. AWS FIREWALL: VISIBILITY WITH ALGOSEC

40. • All rules applied to an instance:
• NACL
• Plus all associated Security Groups

41. • Searchable
• Across all vendors in security estate

42. Risk reporting all rules (NACL + security
groups) into account

43. Change reporting takes all rules (NACL +
security groups) into account

45. CHANGE MANAGEMENT IN A HYBRID
CLOUD

46. THE BIGGER PICTURE: AWS IS PART OF THE ESTATE
Business applications have:
• Resources in the AWS cloud
• Resources in the traditional data center
• … and connectivity requirements between them
Network security policy change process should support all
devices

47. Requestor does not know or care which
security policies need to be updated

48. AWS instance identified –
together with traditional firewalls

49. How does the system know?

51. Work Orders for AWS security groups +
Traditional device policies

52. WHAT WE COVERED TODAY:
• Amazon AWS Firewall: Security Groups and Network ACLs
• Challenges, pitfalls, and tips for a manageable AWS firewall policy
• Achieving visibility in the AWS firewall with AlgoSec
• Managing hybrid cloud+traditional environments with AlgoSec

53. MORE RESOURCES
WHITEPAPER
DATASHEET
PPT
VIDEO
www.algosec.com/resources

54. UPCOMING WEBINARS
Topic: From antiquity to the cloud: 25 years of firewalls and network filtering
When: Tuesday, April 10
Presented by: Prof. Avishai Wool
Topic: Intent based networking: turning intentions into reality with network
security policy management
When: Tuesday, April 24
Presented by: Edy Almer
---Sign up now on Brightalk!---

55. THANK YOU!
Questions can be emailed to
marketing@algosec.Com