Cessation of Misconfigurations: Common Network Misconfiguration Risks & How to Avoid Them
•Download as PPT, PDF•
0 likes•1,661 views
Misconfigurations aren’t simply inconvenient mistakes but serious security threats. According to Gartner, 99% of all firewall breaches will be caused by misconfigurations by 2020 and misconfigurations made OWASP’s list of Top 10 most critical web application security risks. A single change to a network device can have far-reaching effects on your business and create security holes for cybercriminals, impact your audits, and cause costly outages that bring your business to a standstill. In this webinar, Avivi Siman-Tov, AlgoSec’s Director of Product, will show examples of common misconfigurations, including device changes, business application connectivity changes, and data center migrations. He will also reveal specific techniques to help you avoid them. Watch the webinar to learn how to: Understand and map your entire network before you make a change Proactively assess the impact of a change to ensure it does not break connectivity, affect compliance or create a security hole and understand the impact of changes to your entire network Maximize the capabilities of network management automation to avoid common misconfigurations Avoid common mistakes when making changes to your network security devices
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Cessation of Misconfigurations: Common Network Misconfiguration Risks & How to Avoid Them
Similar to Cessation of Misconfigurations: Common Network Misconfiguration Risks & How to Avoid Them (20)
More from AlgoSec
More from AlgoSec (20)
Recently uploaded
Recently uploaded (20)
Cessation of Misconfigurations: Common Network Misconfiguration Risks & How to Avoid Them
- 1. CESSATION OF MISCONFIGURATIONS: COMMON NETWORK MISCONFIGURATION RISKS & HOW TO AVOID THEM! Avivi Siman-Tov Director, Product Management
- 2. WELCOME Have a question? Submit it via the chat tab or email us: This webinar is being recorded! The recording will be emailed to you after the webinar And the slides will be available in the attachments tab Follow AlgoSec online ! 2 marketing@algosec.com
- 3. Taking it to the next level Automation, automation, automation! How to avoid misconfigurations? AGENDA Understanding the problem: misconfigured network devices
- 4. THE BALANCING ACT Security Business Continuity Prevent Cyber Attacks Firewall Breaches Enable Business Applications Data Center Automation 4
- 5. SECURITY Security Prevent Cyber Attacks Firewall Breaches 5% Vulnerabilities 95% Misconfiguration 5
- 6. THE BALANCING ACT Business Continuity Enable Business Applications Data Center Automation Resource Time to Provision Server Storage Security Minutes Minutes Days/Weeks 6
- 7. HOW CAN A DEVICE BE MISCONFIGURED? 100.77.28.98 Database Servers on 100.77.28.32 network 7
- 8. HOW CAN A DEVICE BE MISCONFIGURED? access-list dmz2_acl permit tcp 100.77.28.64 255.255.255.224 64.46.252.0 255.255.255.0 eq 1400 access-list dmz2_acl permit tcp 100.77.28.96 255.255.255.224 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp host 100.77.28.9 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp host 100.77.28.4 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp host 100.77.28.5 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 64.46.193.0 255.255.255.224 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 64.46.194.0 255.255.255.224 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 100.77.28.96 255.255.255.224 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp host 100.77.28.4 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp host 100.77.28.5 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp host 100.77.28.9 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp host WEBSRV 100.77.28.32 255.255.255.240 neq 1433 access-list dmz2_acl permit tcp 64.46.193.0 255.255.255.224 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp 64.46.194.0 255.255.255.224 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.64 255.255.255.224 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.96 255.255.255.224 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.32 255.255.255.224 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 64.46.193.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 64.46.194.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.64 255.255.255.224 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.96 255.255.255.224 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.32 255.255.255.224 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 64.46.193.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 64.46.194.0 255.255.255.0 range 1900 1901 ……………………………… 8
- 9. HOW CAN A DEVICE BE MISCONFIGURED? access-list dmz2_acl permit tcp 100.77.28.64 255.255.255.224 64.46.252.0 255.255.255.0 eq 1400 access-list dmz2_acl permit tcp 100.77.28.96 255.255.255.224 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp host 100.77.28.9 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp host 100.77.28.4 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp host 100.77.28.5 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 64.46.193.0 255.255.255.224 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 64.46.194.0 255.255.255.224 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 100.77.28.96 255.255.255.224 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp host 100.77.28.4 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp host 100.77.28.5 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp host 100.77.28.9 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp host WEBSRV 100.77.28.32 255.255.255.240 neq 1433 access-list dmz2_acl permit tcp 64.46.193.0 255.255.255.224 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp 64.46.194.0 255.255.255.224 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.64 255.255.255.224 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.96 255.255.255.224 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.32 255.255.255.224 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 64.46.193.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 64.46.194.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.64 255.255.255.224 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.96 255.255.255.224 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.32 255.255.255.224 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 64.46.193.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 64.46.194.0 255.255.255.0 range 1900 1901 ……………………………… 9
- 10. HOW CAN A DEVICE BE MISCONFIGURED? access-list dmz2_acl permit tcp 100.77.28.64 255.255.255.224 64.46.252.0 255.255.255.0 eq 1400 access-list dmz2_acl permit tcp 100.77.28.96 255.255.255.224 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp host 100.77.28.9 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp host 100.77.28.4 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp host 100.77.28.5 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 64.46.193.0 255.255.255.224 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 64.46.194.0 255.255.255.224 64.46.252.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 100.77.28.96 255.255.255.224 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp host 100.77.28.4 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp host 100.77.28.5 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp host 100.77.28.9 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp host WEBSRV 100.77.28.32 255.255.255.240 neq1433 access-list dmz2_acl permit tcp 64.46.193.0 255.255.255.224 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp 64.46.194.0 255.255.255.224 64.46.252.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.64 255.255.255.224 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.96 255.255.255.224 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.32 255.255.255.224 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 64.46.193.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 64.46.194.0 255.255.255.0 range 1600 1601 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.64 255.255.255.224 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.96 255.255.255.224 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 100.77.28.32 255.255.255.224 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 64.46.193.0 255.255.255.0 range 1900 1901 access-list dmz2_acl permit tcp 64.46.252.0 255.255.255.0 64.46.194.0 255.255.255.0 range 1900 1901 ……………………………… 10
- 11. MISCONFIGURED EXAMPLE – THE IMPACT • The web server can not access the database on port 1433… • The web server can access ANY OTHER SERVICE on that network!! FTP, Active Directory, File Sharing, SSH, RPC, etc. • over 65,000+ ports are available • One simple “n” out of place! neq 11
- 12. IT’S THE SAME IN THE CLOUD 12
- 13. IT’S THE SAME IN THE CLOUD 13 Traffic does not go through the firewall!
- 14. IT’S THE SAME IN THE CLOUD 14
- 15. IT’S THE SAME IN THE CLOUD Application connectivity Security – Application is vulnerable • One simple routing mistake on AWS VPC configuration 15
- 16. CLEAN-UP GONE BAD …Unfortunately one of the removed rules was in use by a critical application. Service was down for a significant amount of time before the mistake was found and resolved.” - Network Security Manager, Large Enterprise “We performed a periodic policy clean-up and removed multiple unused rules in preparations for an audit. 16
- 17. AGENDA How to avoid misconfigurations? Automation, automation, automation 02 03 Taking it to the next level04 Understanding the problem: misconfigured network devices01 17
- 18. HOW TO AVOID MISCONFIGURATIONS Resource intensive | Not scaable >>> SLOWS DOWN BUSINESS Automation, Automation, Automation 01| Separation of duties, permission enforcement 02| Strict process, mandatory approval steps 03| Peer review 04| Careful validation of changes 05| Hire qualified personnel, training 18
- 19. THE SOLUTION: AUTOMATION • Make sure you have proper visibility and control 19
- 20. AUTOMATION • Avoid human error • business agility • Saves time even when human intervention is required • Full and accurate documentation 20
- 21. AUTOMATION – FIND RELEVANT SECURITY DEVICES 21
- 22. AUTOMATION – RISK CHECK CHANGE 22
- 23. AUTOMATION – PLAN CHANGE 23
- 24. AUTOMATION – PUSH CHANGE TO DEVICE 24
- 25. AUTOMATION – VALIDATE CHANGE 25
- 27. AGENDA How to avoid misconfigurations? Automation, automation, automation 02 03 Taking it to the next level04 Understanding the problem: misconfigured network devices01 27
- 28. TAKING IT TO THE NEXT LEVEL Think in terms of: • Applications • Connectivity • Servers Think in terms of: • Firewall rules • Routing • IP Addresses • Subnets • Vulnerabilities SECURITY/NETWORKING Mind the gap! APPLICATION DELIVERY 28
- 29. TAKING IT TO THE NEXT LEVEL Miscommunication “Reverse engineering” Lack of visibility “Holes” in policy left behind How is this relevant to device misconfigurations? 29
- 31. HOW DOES A BUSINESS-DRIVEN APPROACH HELP? Manage security policy changes “top down” • E.g. application decommissioning Consistency between policies No more “reverse engineering” of connectivity requirements Clear business context and impact analysis 31
- 32. PRO-ACTIVELY DETECT MISCONFIGURATIONS • Connectivity is there – but is it secure? 32
- 33. • Application tags automatically attached to all firewall rules • Know what you may break! BUSINESS CONTEXT (“BOTTOM UP”) 33
- 34. SUMMARY • Device misconfigurations create severe security and operational issues • Automation is key to prevent misconfigurations • A comprehensive, intelligent automation solution can ensure continuous operations and compliance • Business-driven approach enables taking control and holistically managing security policies 34
- 35. Connect with AlgoSec Where You Are Q&A 36 Send us your questions Request a Free Evaluation: marketing@algosec.com youtube.com/user/AlgoSec linkedin.com/company/AlgoSec facebook.com/AlgoSec twitter.com/AlgoSec www.AlgoSec.com/blog
- 36. THANK YOU! Contact us: marketing@algosec.com
Editor's Notes
- Welcome everyone and thank you for joining. In Today’s session we will talk about various misconfigurations to network devices and the potential destructive impact they cause Later, we will discuss best practices and recommended approaches on how to avoid such misconfigurations.
- People who own security in any organization needs to carry the delicate balancing act between: protecting the company’s assets and Enabling business continuity. It’s hard: A mistake in security configuration can not only compromise the organization to outside threats but can also cause a downtime to a critical applications which can cost millions.
- Few recent examples demonstrate how a simple misconfiguration in AWS S3 storage - resulted in an attack Just last month, Capital One was hurt by one hacker who managed to took data from more than 30 companies Nobody wants to be the next headline
- Other examples can show how a misconfiguration can bring your business down: United Airlines had a router misconfigure resulting in hundreds of flights grounded With DevOps trend today the business is also expecting security to be agile: So, if we have less time to evaluate the security change (which traditionally took days/weeks), the risk of making mistakes gets higher. So, why does it happen? Let’s have a closer look on few examples:
- In this example we have a small network where traffic is filtered using a Cisco ASA FW. Let’s say my job is to allow access from a new application/web server (100.77.28.98) to the DB. Sounds like a pretty simple task right? All I have to do is open the command line and update the access list…. Let do so:
- As you can see, this is not the only line in the firewall configuration….. In many cases there could be thousands of entries in the ACL of the firewall or router. I added the line and guess what…. It does not work…. Let’s try to see why…….
- The highlighted line is the one I added….
- Taking a closer look you will see that we have the NEQ not equals to the DB port. This can be a small typo or a big disaster….
- The impact; It does not work: the application server tried to connect to the DB on port 1433 and it was not working…. Imagine the frustration on the other side (developer / project ) who needs this to be working….. 2. From the security perspective every other port can access the DB……. What I am trying to emphasis here is that: A . These things can happen B. When it does happen, its is not always trivial to find the source of the problem. At this point, you might think that this is a simple example, a legacy setup…. And in today’s world, anything is better in the cloud…. Is it?
- In this example, I have my Amazon cloud where we are looking into a specific VPC In orange, I have an internet gateway providing access to my applications and data And I also have a checkpoint FW, filtering the traffic to the internal zones.
- To make sure things are configured right, I choose to use my AlgoSec system to run a network simulation query to test: how traffic from the internet (8.8.8.8) goes to one of my data servers (172.31.18.240) [Click] And guess what…. Traffic goes directly without any filtering… Now, I try to understand why this is happening
- On AWS console I see the routing definitions for my data network, The default GW (the default route here) goes to the internet GW and not to the FW. Since AWS routing is symmetric it also means that traffic from the outside (from the internet) is allowed to my data NW…. The results of this mistake: [CLICK]
- Application connectivity works fine (nobody complaints about a thing) And it is hard to notice that the application is now vulnerable Firewall policy is set, and we *think* it’s securing application servers Incoming traffic from the internet goes directly to the servers, and is not filtered by the Check Point virtual firewall Everything is open This is similar to the S3 storage incidents I mentioned….. Where the application was working and nobody noticed until it was too late
- One last example – something we heard about (in a large enterprise company) A routine policy cleanup resulted in a downtime to a critical application And that is because somebody removed a rule that was in use. Again, like in the other examples, it is really hard to find the root cause. By now I assume that most of you can relate to some of the examples…
- Now that we understand that bad things can happen and this can be our fault, let’s see what we can do about it:
- There are many approaches I am sure you already using today: Some has to do with methodology: like separation of duties and peer review Some with processes and some with getting the right people onboard But as you know, these are resource intensive and takes time - which can slow our business The solution that can address these challenges is of course Automation!
- The reasons are simple: Automation is fast and scalable since its done by machines. Its easier to scale with CPU, than with people…. But most important Automation can be accurate, reliable and auditable. We know, there is a concern about automation [CLICK] Paul R. Erlich said: “ To err is human, but to really foul things up you need a computer”…. So we need to remember [CLICK] that whenever we introduce automation to the process, we need to make sure we have the proper viability and control.
- Let’s see what are the benefits of using automation in our network security: Avoid typos and human error Enables zero-touch changes within minutes – business agility Saves time even when human intervention is required Full and accurate documentation (That allows audit and undo change) What are the steps we can actual automate: [NEXT SLIDE]
- Find which security devices are in the path, and are currently blocking the requested traffic Firewall policies, Router ACLs, SDN segmentation, cloud security groups
- Define ‘allowed connectivity’ between zones Whatever is not pre-approved – should raise a risk
- Vendor-specific decisions – choose policy, zones, ACLs, objects Implement in an optimal way (avoid rule/object duplications)
- Push change to device management (via APIs) or directly to the device (CLI)
- Verify change was implemented successfully and requested traffic is now allowed
- Verify all changes go through the process! Alert in the event of out-of-band changes Monitor the entire security infrastructure Alert in case of non-compliant configuration
- It is clear that automation is key to avoid misconfiguration. Now, let’s talk about how we can take it to the next level: [CLICK]
- Up until now, we have been talking about the security…. Networking…. Firewalls rules…. ACLs…. and other network components / terms And, although its important, we need to remember that these elements exists mainly to serve the business needs actually, the business applications. So while we focus on the network elements, we need to pay attention to the knowledge gap we have on the right side…. But, how is this relevant to our topic?
- Let me try to explain: This gap can be a good reason for misconfiguration. Why? Because: Misconfiguration are not always typos, they can be a result of miscommunication: The application team asked something which was interpreted and implemented not as required…. Sometimes, the Application teams don’t care about security…. This may cause security engineers to feel like they have to do “Reverse engineering” to the connectivity requirements so they can understand what is really needed…. On the other side, Lack of visibility to business needs can have a bad impact like in the cases of: Cleanup / Security incidents / Maintenance Imagine someone cleaning a rule that is used by a critical application That can even bring to “Holes” in policy left behind
- AlgoSec can help you to bridge the gap between the network and the business. We call it: “Business-driven security management” And…it is based on: Application connectivity described in abstract terms and…. A Smart engine that translates it to network infrastructure actions
- Resources: Network Security Policy Management Lifecycle Whitepaper Network Security Policy Management Across The Next Generation Data Center Professor Wool Course Webinar Slides LinkedIn Links
- Seed Questions Seed1 : What about other misconfigurations such as routing or VPN tunnels? Seed2: How are the firewall rules being tagged with relevant applications they support? Seed3: What cloud environments do you support? Seed 4: do you have tips for auditing the group that manages your enterprises' cloud envt?
- And, before we part – AlgoSummit and Upcoming webinars
- And, before we part – AlgoSummit