Downloaded 15 times
Uploaded byAlgoSec
Avoid outages-from-misconfigured-devices-webinar-slides
Misconfigured network devices can lead to outages and security breaches, emphasizing the need for effective change control processes and better communication between IT and business sectors. Automation and validation are recommended to reduce human errors, while the security change management process must improve to meet rapid business demands. The document outlines strategies for addressing these issues, particularly during data center migrations.
More Related Content
Similar to Avoid outages-from-misconfigured-devices-webinar-slides
Avoid outages-from-misconfigured-devices-webinar-slides
- 1. HOW TO AVOID BUSINESSOUTAGES FROM MISCONFIGURED NETWORK DEVICES
- 2. TOPICS COVERED TODAY •Understanding the problem: misconfigured network devices • Typical change control processes • The Gap between Business and IT Security • Data center migration 2 | Confidential
- 3.
- 4. Firewall Breaches 5% Vulnerabilities 95%Misconfiguration THEBALANCING ACT Security Agility Prevent Cyber Attacks
- 5. Firewall Breaches Data CenterAutomation5% Vulnerabilities 95%Misconfiguration THE BALANCING ACT 5 Security Agility Prevent Cyber Attacks Enable Business Applications Resource Timeto Provision Server Minutes Storage Minutes Security Access Days/Weeks
- 6. JUST SOME CONTEXT… 6| Confidential
- 7. JUST SOME CONTEXT… 7| Confidential
- 8. HOW CAN ADEVICE BE MISCONFIGURED?
- 24. SECURITY DEVICE CHANGECONTROL PROCESS • Understand and map your enterprise infrastructure topology 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 • Avoid common mistakes when making changes to your network security devices and firewalls • Monitor all changes in case there is an outage. You can easily reverse the newest implemented change if necessary • Translate business requirements into the network and security policies that are implemented on firewalls 24 | Confidential
- 25. TYPICAL SECURITY DEVICECHANGE CONTROL PROCESS 25 | Confidential Plan Approve ImplementValidate Close Request 1 2 3 4 6 5
- 26. TYPICAL SECURITY DEVICECHANGE CONTROL PROCESS 26 | Confidential Plan Approve ImplementValidate Close Request 1 2 3 4 6 5 In some cases, “Recertify”… but that’s a topic for another day
- 27. TYPICAL SECURITY DEVICECHANGE CONTROL PROCESS 27 | Confidential Plan Approve ImplementValidate Close Request 1 2 3 4 6 5 • Identify what devices need to be changed • In our example, there are three devices • CheckPoint • Juniper • AWS Server • How did we know?
- 28. VISIBILITY INTO THEPLANNING STAGE • We understand the topology of the network and the security policies associated with the devices in the path 28 | Confidential
- 29. Plan Approve ImplementValidate Close Request TYPICAL SECURITY DEVICECHANGE CONTROL PROCESS 29 | Confidential 1 2 3 4 6 5 • Always perform a risk check BEFORE you approve • Understanding the risk during the approval phase gives you a chance to “replan” the change or deny it if it will cause undue risk to the environment
- 30. Plan Approve ImplementValidate Close Request TYPICAL SECURITY DEVICECHANGE CONTROL PROCESS 30 | Confidential 1 2 3 4 6 5 • During the implementation phase consider how to insert the new security rule into the device’s current policy • Add a new rule? • Modify an existing rule? • Create new objects? • Automatically document the rule change
- 32. Plan Approve ImplementValidate Close Request TYPICAL SECURITY DEVICECHANGE CONTROL PROCESS 32 | Confidential 1 2 3 4 6 5 • Check the request and validate it is implemented correctly before notifying stakeholders • Was the original request implemented: • In good working order for the entire path, so the requester does not ask for the same information again! • Exactly as requested? • With an overly permissive rule (ie. “any” vs https service)
- 33. Plan Approve ImplementValidate Close Request TYPICAL SECURITY DEVICECHANGE CONTROL PROCESS 33 | Confidential 1 2 3 4 6 5 Need to figure out why the change was not implemented correctly
- 40. GAP BETWEEN BUSINESSAND IT SECURITY • A simplistic summary of the Business and IT relationship: 1. The business created value for customer’s and has stored this data in databases and allowed users to access the data via applications 2. IT maintains the infrastructure to support the data (databases) and applications. 3. IT Security maintains secure access to data and applications so these assets don’t compromise the value of the business • Without 1, 2 & 3 above, a business would not exist • Applications provide a vehicle to create additional value for their customers • Applications and “data” MUST be secure and maintainable • Application developers and database administrators request security infrastructure changes as business requirements adapt to new customer and market demands • The security change management process has to improve - just like provisioning a web or database server….It only takes minutes now… 40 | Confidential
- 41. A SIMPLE DIAGRAMWILL DO….PLEASE!!! • The current challenge is that Information security talk a different language than application developers and database administrators (DBA’s) who are requesting application changes • Security architects must bridge the gap between a secure business application and operational disasters • How many organizations can document their business applications so the security team has a prayer in understanding how their applications works? 41 | Confidential
- 42. A SIMPLE DIAGRAMWILL DO….PLEASE!!! • The diagram to the right can be dynamically created to help document how the application interacts with the network infrastructure • Provides Security Architects with a communication vehicle to start the conversation • Dive one level deeper and understand the security 42 | Confidential
- 54. DATACENTER AND/OR CLOUDMIGRATION MOTIVES • Upgrade capacity • Save money – server consolidation • Mergers and acquisitions to combine resources 54 | Confidential
- 55. DATA CENTER (DC)MIGRATION • Requirements for DC • Complete inventory of what needs to move • Official and “unofficial” equipment • Discover the hidden assets via the security policy • New hardware and IP address schemes • Change Firewall Rulebase for transition connectivity • Migrate IPs in DNS servers • After migration is complete, decommission original application • Planning • What if analysis • What applications are using these servers? • What applications are impacted by these firewalls? • What applications are vulnerable to these security issues? 55 | Confidential
- 57. CUSTOMER PHILOSOPHY ISCHANGING • We currently see connectivity requests being manually planned, assessed, designed and implemented • This needs to change…..and quickly! • How do you manage these 1,000 security change requests? • Customers are moving to agile development & deployment • The Internet of Things is impacting service expectations • We are required to intelligently automate as much of the change process as possible • The bottom line is that security needs to dramatically improve change responsiveness with zero errors at a lower cost! 57 | Confidential
- 58. SUMMARY • Misconfigured devicescan cause outages and security breaches • Use automation and validation to help reduce human errors • Help application developers and information security understand each other by automatically documenting applications and translating security policy rules into flows that everyone can understand • Use “projects” to help accelerate data center migration security policies so that it will be completed on time! 58 | Confidential
- 59. MORE RESOURCES 59 |Confidential
- 60.