Making ACI Configurations Consistent
In the modern enterprise, configuration audits are central to managing an efficient and up-to-date network. Configuration audits – whether functional or physical – help NetOps ensure that their increasingly complex, multi-system, multi-standard enterprise is validated properly and running like a top.
Here are six tips for making your next configuration audit error free and easier to implement.
The nice thing about standards is that there are so many from which to choose. This is an old joke about standards. Joking aside, it is useful to take advantage of pre-defined configuration standards. The only trouble is selecting which standard(s) to use.
You will want to ensure that the tools you use support today’s recommended compliance requirements. For instance, Gluware’s configuration audit capability supports the recommendations from more than 20 compliance organizations. Your organization’s main business will be the primary driver for selecting the most important configuration standards. For example, a healthcare organization might select an FDA and a HIPAA configuration standard to secure patient health data, combined with a PCI standard to protect financial data.
Overlap between multi-standards may make it necessary to merge requirements to create an organization-wide network configuration policy. While the merger of standards takes time, it is almost certainly faster than creating your own set from scratch. Besides, working from a set of standards makes sure that you don’t overlook something.
While selecting which recommendations to implement, take the time to document why you include or exclude each recommendation. Future audits will go much smoother if you have a record of the decision process, particularly where the recommendations differ. Spending a few minutes to document the justification for your selection indicates to the auditors that you’ve considered each element and have a reason for your decision.
For example, some of the more stringent standards recommend disabling CDP/LLDP (neighbor discovery protocols) because they facilitate network discovery, making it easy for attackers to map out your network. However, neighbor protocols are very useful for troubleshooting internal network problems. Instead of disabling CDP/LLDP everywhere, it makes more sense to leave the neighbor discovery protocols running internally and disable them on interfaces that connect to external networks.
You will find that some internal policies are not covered by standards-based configuration compliance standards. These differences are typically due to the design and implementation of your network. This is where your network is unique, even though much of its design may be from vendor reference designs. The unique details might include the following:
Internal policies involve enough details that it is important to use an automated configuration audit system like Gluware to verify its correctness across the entire network.
The problem with Security Vulnerability is that we often don’t know about it until it’s too late. The Gluware configuration audit system includes a very valuable capability: automatic detection of vulnerabilities that are tied to specific CVEs (Common Vulnerabilities and Exposures), the industry mechanism for distributing information about known security holes. Once a security hole is identified, the OS version can quickly be upgraded or a configuration workaround can be implemented. Your NetOps and security team will greatly appreciate the ability to automate these tasks.
Modern networks are based on equipment from multiple vendors – both older, brownfield systems and newer, greenfield ones. Today’s configuration management systems must be able to handle disparate vendors. It makes sense to try to organize the configuration audit into sections that correspond to policies that are applied across multiple devices and device types. Very simple examples are the NTP and SNMP configurations. More complex examples involve security configurations that require consistency between routers, switches, and firewalls. Obtaining this consistency is difficult when multiple vendor-specific tools are used, each with its own configuration audit syntax, features, and bugs. Gluware support spans brownfield and greenfield – readying your enterprise for anything that comes its way.
By the way, beware of network products that don’t have a CLI and that don’t have a well-defined API (yes, they exist). There is definitely potential for you to get stuck with expensive network devices that can’t be configured and controlled by automation.
Role-based access control is used to assign different levels of privileges to groups of network administrators. You will want a configuration management and audit system that integrates with your existing authentication mechanisms. One group could be assigned read-only access to view reports and initiate pre-defined configuration changes. Another group could have authorization to create new configuration audit rules. A third group could be allowed to create new configuration templates. The division of roles allows the distribution of tasks to spread the load and to assign tasks based on training and experience.
Gluware supports both centralized authentication through LDAP and RADIUS, the two leading user authentication systems. It has five levels of role-based access, which is enough to implement common task partitioning.
Interest has been growing to develop automation scripts using frameworks like Ansible, Nornir, or SaltStack. The downside to home-grown automation is that it is typically developed by a single person. The organization is seldom equipped to have someone else assume ownership of the automation system, putting the whole effort at risk.
Software development continuity through vendor-supplied product like Gluware has a big advantage over internal projects. The configuration management vendor is dedicated to its product and will have multiple developers, quality assurance systems, and documentation staff. If you’re considering an in-house automation project, keep in mind that it is very difficult to find good software developers who also know networking well enough to create a great system. Another role that is often overlooked is that of documentation. Technical writing is not something that many developers enjoy doing, so internal projects rarely have any documentation.
Network configuration compliance is an important factor in network stability and security. Some compliance standards must be met to stay in business, such as PCI and HIPAA, while other standards may be essential to meet internal requirements. Since configuration errors are the source of most network outages, good configuration consistency practices reduce the opportunity for error and are critical for a smoothly operating network. Security vulnerability auditing helps identify and eliminate known security holes, leading to a more secure IT infrastructure. Configuration Audits using Gluware meets these compliance requirements while adding the multi-vendor support and role-based access that is required for ease of deployment. Like all Gluware Intent-Based Applications, configuration audits from Gluware benefit from its integrated Intelligent Network Automation platform.
To read the original blog post, view Gluware’s post here.
Making ACI Configurations Consistent
Six Tips to Help with Your Next Configuration Audit
Does Security Belong Near Endpoints?
Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.
Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.
John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services. Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.
He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.