Automated Firewall Change Management. Ensure continuous compliance and reduce risk with secure change management workflows

Transcription

1 Automated Firewall Change Management Ensure continuous compliance and reduce risk with secure change management workflows JANUARY 2015

2 Executive Summary Firewall management has become a hot topic among network and firewall professionals, particularly for enterprise organizations. Firewalls are a critical security control, and the most secure firewall is the one that is best administered. Whether you are managing one firewall or thousands, proper configuration is a necessity. The struggle to keep firewalls configured properly can impact network availability, access, security, and compliance, as well as reduce IT productivity and add management costs. Automated change workflow is essential for any enterprise or government IT organization. A typical organization may receive hundreds of changes required each month with every request requiring hours of manual analysis to assess the potential impact to business continuity and security. A flaw in the way a change is performed can block access to critical services, increase threat exposure levels, or break compliance with regulations. Disconnected, manual change management steps and handoffs can impair change tracking. Disparate network and firewall-related database information makes it difficult for a network analyst to evaluate security and availability risks. Automated change workflow links the change process, reduces risk, ensures compliance, and improves communication between IT teams, ensuring the desired changes are implemented as intended. This white paper examines the current challenges in managing firewall changes, the typical firewall change management cycle, and the concepts of an automated workflow system that address these challenges.

3 Contents Executive Summary Introduction IT Standards Recommend Formal Change Management Processes A Typical Firewall Change Management Cycle Current Challenges in Managing Firewall Changes Disparate Data Repositories Can Camouflage Risk Exposures Manual Analysis Can t Keep Up with Change Process Fragmented Change Processes are Highly Inefficient Automated System for Firewall Change Management Layer 1: User Interface Layer 2: Workflow Mechanism Layer 3: Data Repository Why is Access Analysis so Important? Working with the System Step 1: Request a Change Step 2: Technical Details Step 3: Risk Assessment Step 4: Implementation Step 5: Verifying Closure Next Steps About Skybox Security

4 Introduction The dynamic nature of enterprise networks introduces significant challenges for day-to-day firewall management. Enterprise environments change frequently due to business needs, and these change often impact firewall configurations. For example, when new applications are introduced or a group of users are added to a service, access rule changes are required. When applications are extended to include more servers or to communicate with other applications, firewall configuration settings are impacted. When major network topology changes are made to support new networking requirements or to protect against a security threat, they require a complete evaluation of firewall configurations and rules. Firewalls limit or provide access to specific network segments based on a set of firewall rules, and each firewall may contain hundreds or thousands of rules that specify how and where certain types of traffic can flow to handle the complex network access decisions. These decisions may be based on security or access policies, application needs, type of request, and more. Ensuring every change complies with internal and regulatory security policies is a tedious, time-consuming process to consider: > > What devices are in this path? > > Which firewalls allow access now? > > What needs to be changed? What doesn t? Ultimately, firewall administrators need tools to effectively manage and complete firewall changes faster and more accurately. IT Standards Recommend Formal Change Management Processes Enterprise firewalls change daily, sometimes hourly, requiring continuous change management, monitoring, and maintenance to keep them secure, compliant, and optimized for high performance. The challenge is significant and the risks are real. One misconfiguration, and you are open to attack. To reduce the likelihood of errors or introducing risk to the network, many security control frameworks recommend implementing a set of change management processes controls such as: > > Establishing a documented change management process > > Conducting impact analysis prior to every change, including assessment, prioritization, and authorization > > Tracking and reporting on all changes to ensure they have been made as planned and as authorized Many frameworks such as Council on CyberSecurity Top 20 Critical Security Controls (also known as the SANS Institute Top 20 Critical Security Controls), ISACA s Control Objectives for Information and Related Technology (COBIT) 5, National Institute of Standards and Technology (NIST) Special Publication (CM-1 to CM-7), and the National Security Agency (NSA) Manageable Network Plan (Milestone 7) prioritize secure configurations based on formal configuration management and strong change control processes. 4

5 A Typical Firewall Change Management Cycle Let s consider how a recommended change management lifecycle applies specifically to firewall changes. Figure 1 illustrates the phases from the time the change request is initiated through to change implementation and verification. REQUEST TECHNICAL DETAILS RISK ASSESSMENT IMPLEMENTATION RECONCILIATION > > Capture business and/or technical details > > Translate > > Path identification > > Rule analysis > > Identify policy violations and vulnerability exposures > > Accept/reject > > Assign to team for provisioning > > Reconcile against observed changes > > Verify access FIGURE 1: CHANGE MANAGEMENT PHASES PHASE REQUEST CHANGE TECHNICAL DETAILS RISK ASSESSMENT > > IT or business owner makes request BEHAVIOR > > Request is usually specified in network terms (e.g. access is needed from source A to destination B using port X) and may or may not relate to a specific firewall > > Network or firewall expert identifies the firewalls that should support the requested connectivity and addresses the change request > > Implementation details might be added to the request at this phase or later (e.g. rules or objects to be added or changed) > > Each request is evaluated to assess its risk, compliance, and business justification > > Members from various disciplines might be involved in the process (dependent on risk) > > The depth and formality of the process can vary for each organization > > The request may be approved, rejected, or approved with modifications based on the assessment results IMPLEMENTATION > > Implement changes to the firewall rule base (ACL rules, NAT rules, and objects) VERIFICATION > > Identify changes to firewall configuration (change tracking) > > Compare identified changes and approved change requests to verify identified changes correspond directly with approved requests and requests are implemented as specified; highlight deviations > > Close verified change requests TABLE 1: CHANGE MANAGEMENT PHASES 5

6 Current Challenges in Managing Firewall Changes Many enterprises and government agencies have a firewall change management process that covers some or all of the recommended stages. However, the change management process is usually manual (often documented on Microsoft Excel documents) and requires the efforts of disparate IT teams, tools, policies, and priorities. Firewall changes typically require different teams in network operations and IT security groups that may use different tools and information. Ensuring the streams of change requests will be addressed consistently, on time, and in a safe way from all parts of the organization poses a major challenge for enterprise IT organizations. Disparate Data Repositories Can Camouflage Risk Exposures Disparate databases, formats, and descriptors add to the complexity of comparing and correlating firewall information through the change lifecycle. For example, to accurately describe a firewall change, the IT team may need to compare data from multiple types of firewalls with varying configuration settings and rule formats. And, to assess its potential risk, team members may need to correlate the request against the configuration management database, policy repository, and other known risk factors. Normalized data in common or integrated repositories makes it significantly easier to uncover potential risk exposures, such as security gaps that can be introduced by the change, compliance violations, or access and availability issues. Common data formats or links between types of data also give business, operations, and security managers a consistent view into the change process and reduce the chance of errors. When firewall rules, configuration data, corporate access policies, and industry standards are stored in disparate repositories that do not communicate, IT teams can easily overlook potential threats or access issues that happen through the combination of different factors. Multiple databases increase the cost and time required for change verification and reconciliation. Tracking the effect of actual changes across multiple data repositories requires considerable manual correlation and review time. This also increases the likelihood of a late discovery of an error or risk exposure. Manual Analysis Can t Keep Up with Change Process The change planning and design stage is the first step where manual analysis may significantly slow down the process. A change request may impact several firewalls, and understanding which of these firewalls need to be changed is a serious task. Furthermore, deciding how to implement a required change on an existing firewall with hundreds or thousands of rules is time consuming. Manual evaluation of firewall change requests increase the chance of risk exposure and rework after the change is implemented because organizations may conduct only a cursory risk assessment due to resource constraints. When an organization has a complex network, the manual effort required to describe a firewall change, evaluate the risk of a change, and reconcile change requests is difficult and requires special expertise. Change requests pile up awaiting constrained IT security resources, or shortcuts may be taken to avoid creating an IT bottleneck. 6

7 Fragmented Change Processes are Highly Inefficient Automating firewall change workflow can significantly reduce the amount of time spent on repetitive and inefficient IT tasks, accomplishing a number of objectives: 1. Optimize Processes: Firewall change request details are captured in a consistent and organized structure. Workflow tools specifically built for firewall change management can also help assess the change impact risks. 2. Demonstrate Change Compliance: Changes andhandoffs can be tracked and verified in a systematicway that supports audit needs, providing improved security and compliance with policies. Theprocess also helps avoid communication headaches and time-consuming, emergency rework. 3. Centralized Communication: IT and network groups have a centralized environment to communicate When the steps in a change control process and supporting tools are fragmented it takes enterprise network and operations teams an exorbitant amount of time and energy to communicate firewall change requests, evaluate changes, and link actual changes back to the desired outcome. firewall change information among team members. Instead of multiple tickets, s, or sticky notes, a common workflow readily links the planning, reconciliation, and verification steps. 7

8 Automated System for Firewall Change Management To address these challenges, organizations must automate change management workflow and integrate all steps in the change workflow to relieve the burden on network operation and IT security. Automated analysis alleviates the time-consuming, repetitive steps of correlating data and analyzing multiple firewalls. Best practice checks can be conducted based on the type of change requested or corporate policy, which greatly improves the quality of the assessment steps. As a result, evaluators gain consistent, high-quality assessments to better identify if the requested change: > > Introduces any security risk > > Violates compliance with guidelines and regulations (e.g. PCI DSS) > > Is likely to cause any performance degradation or network downtime The Components of an Automated Firewall Change System CHANGE REQUESTOR REQUESTS ALERTS & REPORTS WEB GUI WORKFLOW MECHANISM REQUEST TECHNICAL DETAILS RISK ASSESSMENT IMPLEMENTATION VERIFICATION DATA REPOSITORY CHANGE REQUESTS ACCESS POLICY TRACKED CHANGES NORMALIZED FIREWALL REPOSITORY NETWORK MODEL VULNERABILITIES FIGURE 2: CHANGE MANAGEMENT SYSTEM COMPONENTS 8

9 The Change Management Platform consists of three major layers. Layer 1: User Interface The user interface allows IT and business owners to feed change requests into the system. Following the process, technical and security team members can then view, augment, and approve the requests. Alerts can be established according to business policy and reports created for the various users of the system. Layer 2: Workflow Mechanism The workflow mechanism is responsible for transferring the request among the involved users according to the lifecycle phases. In a firewall change management system, two sets of built-in tools can assist the IT staff throughout the change process: PRE-DEPLOYMENT TOOLS > > Planning and Design: Identify the firewalls to be changed and define the implementations details such as rules or objects to be created or changed > > Risk Assessment: Automatic checks assess if the change will introduce security or compliance risks POST-DEPLOYMENT TOOLS > > Change Tracking: Identify and record the actual changes performed to the firewall configurations > > Change Reconciliation and Verification: Match the tracked change with the change request and identify any deviations such as changes performed without authorization or those that did not deliver the intended result Layer 3: Data Repository In order to support the computation performed by the workflow tools, the system maintains: > > A repository of change requests > > A repository of up-to-date firewall configurations, represented in a normalized way > > A topological network model (optional) The change request repository holds the details and the status of the requests and their full history (audit trails). The repository enables searches for requests according to owner, requester, status, and request details. A normalized firewall configuration repository is maintained automatically. Firewall configurations are collected on a regular basis (e.g. nightly) through communication with the firewall vendor s management platforms or with individual firewalls. The repository can be extended to hold a topological model that puts firewalls in an accurate network context (see Figure 3). In this case the system automatically collects the configurations of additional network devices, such as routers and load balancers, and builds the topology, creating a normalized representation. With this network model, the workflow system better understands the firewalls behavior and enables automated analysis of possible access from one area of the network to another, considering topology, routing rules, access lists, and NAT rules of firewalls along the route (access analysis). 9

10 Why is Access Analysis so Important? Firewall change requests are about network access. To determine if a request is already fulfilled, find a network device that blocks the requested access, or verify that the access request was fully achieved, network access has to be analyzed in an accurate way. Another crucial capability of the change management system is its ability to check compliance of an access request with the corporate access policy. The corporate access policy defines the acceptable network traffic. It is specified using a set of rules that typically relate to network zones. Firewall change management should provide a few out-of-the-box policies that the organization can start with and then customize if needed (e.g. NIST , PCI DSS policies). Following are examples of typical corporate policy rules: > > There should not be direct access from the Internet to internal zones (unless defined as exception) > > There should not be access from external zones to non-secure login services in the internal zones (critical) > > The access from Internet to DMZ should be limited only to HTTP, HTTPS, SMTP, and DNS > > The number of destination addresses that have DNS access should not exceed 10 The corporate policy rules are represented in a formal way that can be used in automatic change request compliance checks. FIGURE 3: ANALYZING ACCESS PATHS ON A NETWORK 10

11 Working with the System Let s walk through a sample firewall change request using Skybox Firewall Assurance and Skybox Change Manager. Step 1: Request a Change An application owner places a request to allow access from the financial servers to the customer database. A user authorized to make service changes submits this request with his details and the request s description. Step 2: Technical Details The network group receives the request and uses the workflow tools to identify firewalls relevant for a particular change. The system examines the routing scopes of firewall interfaces and optionally analyzes the topological model. Figure 4 shows three relevant firewalls were found: prod FW, finance FW and main_fw. The system also conducts an access analysis to identify which of the relevant firewalls already allowed the required access. Here, the requested access is possible through finance FW and main_fw but is blocked by prod FW, which means only prod FW firewall needs to be changed. FIGURE 4: RELEVANT FIREWALLS DISCOVERED In cases where access is already allowed through all relevant firewalls, the request can be returned to the requester with an indication that the requested access is already supported, which eliminates wasted time spent on obtaining approval and defining implementation details. For each firewall that has to be changed, a dedicated request entry is generated by the system. 11

12 Step 3: Risk Assessment The IT Risk group receives the planned request and assesses its risk and compliance. To assist in this process, the system automatically checks the compliance of each of the individual firewall requests against the corporate access policy, as well as any vulnerabilities which would be exposed by the change presenting the results. In Figure 5, the system determined the requested access change is incompliant with the corporate access policy and exposes vulnerabilities. The compliance violation is depicted by the H in an orange circle indicating it is high level compliance violation. The exposed vulnerability is depicted by the X in the red circle indicating a new vulnerability is exposed. The request examiner decides the risk level based on this information, which is high in this case. Based on the assessed risk and the justification of the business need, the request is approved or transferred back to the planner for modifications (or, in some cases, completely rejected). FIGURE 5: RISK ASSESSMENT RESULTS Step 4: Implementation Once the request is approved, it is transferred to a firewall engineer who adds implementation details. The engineer should decide on questions such as: > > Should we implement the change using a new ACL rule or extend an existing rule? > > Where should we place a new ACL rule? > > Should we define a new object or extend the definition of an existing object? > > Do we need to add NAT rules? If so, which ones? The system assists the operator in these decisions by searching through the current firewall configuration to identify the relevant ACL rules and objects. After deciding on the implementation details, it can be checked for consistency with the original request and for compliance with rule and object guidelines. A firewall engineer deploys the approved changes in the next service window. Using the system, the engineer can examine the list of change requests awaiting deployment and their respective details, and use Change Manger to automatically generate the commands needed to implement the new rule in the firewall. 12

13 Step 5: Verifying Closure During the post-deployment phase, the change request is verified to ensure it was implemented correctly and that it enabled the required access. What was previously a time-consuming, manual process is now automated by: > > Regularly tracking changes to the firewalls > > Matching identified changes with the approved change requests > > Verifying access required by the change requests is now possible (access check analysis) > > Identifying unauthorized changes Next Steps An automated, secure change management workflow can reduce risk across your network. Skybox Change Manager automates the firewall change management workflow, assesses risk of proposed changes before they are implemented, and ensures continuous compliances and complete change management tracking. More information about Skybox Change Manager is available on our website, Or contact your local Skybox Security representative at to improve your change management processes now. REFERENCES > > ISACA COBIT 5; Control Objectives; AI2.9 Applications Requirements Management; AI3.3 Infrastructure Maintenance; AI7.9 Post-implementation Review; DS9.2 Identification of Maintenance of Configuration Items > > NIST; NIST SP Controls: CM-1, CM-3, CM-4, CM-5, CM-9 > > PCI DSS; Requirements 1, 6, 11 About Skybox Security Skybox arms security teams with a powerful set of security management solutions that extract insight from traditionally siloed data to give unprecedented visibility of the attack surface, including all Indicators of Exposure (IOEs). With Skybox, security leaders can quickly and accurately prioritize and address vulnerabilities and threat exposures. info@skyboxsecurity.com Copyright 2016 Skybox Security, Inc. All rights reserved. Skybox is a trademark of Skybox Security, Inc. All other registered or unregistered trademarks are the sole property of their respective owners.