Itential’s Golden Configuration Methodology for Achieving Network Consistency

Introduction

Network configuration management is a critical challenge for modern enterprises, given the diversity of devices, evolving technologies, and a mix of legacy systems and new infrastructures. These complexities often result in configuration drift, where configurations across the network diverge from established standards over time. This divergence can introduce security vulnerabilities, degrade network performance, and increase operational overhead.

The Golden Configuration Methodology addresses these challenges by creating a standardized baseline that defines optimal configurations for all network devices. This methodology leverages the automation capabilities of Itential to create a comprehensive, automated, and adaptive framework. By aligning network configurations with corporate policies, regulatory requirements, and industry standards, organizations can enhance their security posture, operational efficiency, and compliance.

The Value of a Golden Configuration

The primary goal of establishing a Golden Configuration is to create a unified baseline that defines the optimal configurations for all network devices. Consider the case of a multinational enterprise that has different operational teams managing various regions. Over time, network configurations in different regions may diverge due to local optimizations, regulatory requirements, or historical inconsistencies introduced by different teams. Without a clear Golden Configuration standard, the risk of inconsistent security protocols or outdated policies increases. By establishing a Golden Configuration, organizations reduce these risks, ensuring alignment with business goals and industry standards.

Key Terminology

A successful implementation of this methodology requires familiarity with the following key terms:

  • Configuration Diversity: Differences in configurations that arise due to factors like regional variations, device roles, vendor-specific features, and business requirements. For example, configurations in Europe may need to comply with GDPR requirements, which could introduce specific access controls.
  • Golden Configuration: A standardized, validated configuration that aligns with corporate policies, security standards, and business goals. This configuration acts as a “gold standard” to prevent unwanted deviations.
  • Compliance Check: An automated process that compares current device configurations against the Golden Configuration to identify deviations. This is akin to performing a routine audit of financial records to identify any discrepancies.
  • Remediation: Corrective actions taken to realign network configurations with the Golden Configuration. For example, updating SNMP configurations across all routers to ensure consistency.

Overview:
Golden Configuration Methodology

The methodology consists of five key phases that collectively work towards identifying, defining, implementing, and sustaining the Golden Configuration standard. Each phase builds on the previous one, creating a cohesive approach to standardizing configurations across a dynamic network environment.

  1. Internal Discussion and Analysis: Identifying configuration diversity and understanding its causes within the organization.
  2. Analysis of Current State: Collecting and analyzing current configurations to assess consistency and compliance.
  3. Definition and Development of Golden Configurations: Establishing and standardizing configurations through templates.
  4. Compliance Check and Non-Compliance Categorization: Conducting automated checks to identify deviations and categorize non-compliance issues.
  5. Remediation and Continuous Monitoring: Addressing non-compliance and continuously monitoring configurations for new issues.

The following sections provide an in-depth look at each phase and its significance in the broader context of network management.

Phase 1:
Internal Discussion and Analysis

The first phase of the methodology is crucial for understanding the landscape of configurations within the organization. It involves internal discussions among key stakeholders to identify and classify the different types of configuration diversity.

Identifying Causes of Configuration Diversity

During internal analysis, teams examine various sources of configuration diversity, such as:

Operational Diversity: Different devices serving different roles may have unique configuration requirements. For instance, edge routers in remote offices might require specific access control policies that differ from those of core routers in a data center. Additionally, regional requirements can lead to variations, such as EMEA networks adhering to GDPR while North American networks may prioritize different standards.

Historical Inconsistencies: Over time, network teams may have introduced custom configurations to solve localized problems, leading to unintentional drift. For example, engineers might apply custom VLAN configurations to accommodate local access needs, which later results in inconsistent naming conventions or ACL rules.

Business Requirements: Specific business needs, such as regulatory requirements or performance goals, can introduce configuration variations. A common example is different routing policies based on business priorities, such as prioritizing video traffic over web traffic in a media company’s core routers.

Establishing Acceptable & Unacceptable Variations

The key outcome of this phase is distinguishing between acceptable and unacceptable configuration variations. This sets the foundation for the Golden Configuration framework:

Acceptable Variations: These are deliberate and justified differences, such as performance tuning configurations for different hardware models or compliance-related changes based on geography.

Unacceptable Variations: Inconsistent or arbitrary variations, such as using different NTP servers across routers, represent risks that should be addressed in the Golden Configuration.

Phase 2:
Analysis of Current State

Once internal discussions have defined the acceptable variations, the organization needs to analyze the current configurations across the network. This phase leverages Itential’s capabilities to collect and assess configurations comprehensively.

The intent of Phase II, Analysis of Current State, is to develop a comprehensive snapshot of your network’s existing configurations and highlights any patterns, inconsistencies, or deviations from desired standards.

The major steps of this phase are:

  • Collect configuration data from existing network devices.
  • Analyze existing configurations to identify trends and anomalies.
  • Document baselines, trends, and anomalies as inputs to Phase 3.

Collecting Configuration Data Using Itential

Itential enables centralized collection of configurations from various types of devices and environments, including:

CLI-Based Devices: For traditional network devices like routers and switches, Itential extracts configurations using command-line interfaces (CLI). This approach ensures comprehensive data collection from devices that lack modern API support.

API-Based Systems: For modern platforms, such as cloud environments or SDN solutions like AWS, Azure, or VMware NSX, Itential integrates directly via APIs to pull configurations, ensuring a unified view of the entire network infrastructure.

Inventory of All Devices: Itential’s capabilities ensure that all device types are inventoried, from traditional firewalls to cloud-based virtual appliances, establishing a single source of truth for network configurations.

Analyze Existing Configurations to Identify Trends and Anomalies: Leveraging Large Language Models (LLMs)

With configuration data collected, one method for gaining insights is to use LLMs for initial analysis.

In this context, LLMs can be utilized to identify patterns and trends. For instance, an LLM might detect consistent naming conventions across routers in different regions or identify deviations in the configuration of NTP servers. By recognizing these patterns, LLMs can provide actionable insights to refine the Golden Configuration.

It is recommended that organizations use privately hosted LLMs to avoid the risks identified below. By hosting LLMs privately, organizations maintain control over their data, ensuring compliance with security standards and safeguarding sensitive information.

Risks & Mitigation Strategies

Data Security and Privacy: Ensure that sensitive configuration data is not exposed to external servers. For maximum security, use on-premise or private cloud-hosted LLMs to maintain control over data.

Model Training and Data Sensitivity: Avoid training models on sensitive, identifiable information directly. Instead, use synthetic or anonymized data where possible, or rely on pre-trained models that don’t require further training on proprietary data.

Control Access to LLMs: Limit access to the LLM tools to authorized personnel only. Implement role-based access controls (RBAC) to prevent unauthorized modifications or data access.

Regular Audits of LLM Outputs: Since LLMs may produce false positives or inaccuracies, schedule periodic audits of their outputs. This ensures that compliance checks are both accurate and reflective of the latest standards.

Secure Deployment Practices for LLMs

To maximize the benefits of LLMs while maintaining data security, follow these deployment best practices:

Use Private or On-Premises Deployments: Avoid sending configuration data to third-party LLM providers. If possible, host LLM models on-premises or within a secure, private cloud environment.

Implement Encryption and Access Control: Ensure all data in transit and at rest is encrypted and apply strict access control measures. Use multi-factor authentication (MFA) to protect access to the LLM environment.

Continuous Monitoring: Enable monitoring to detect any unauthorized access attempts or anomalies in model performance, particularly if the model is used in sensitive environments or handles regulated data.

Example Prompt

Here is one example of a prompt for identifying patterns that can be incorporated into a Golden Configuration strategy.

Config Analysis Prompt:

You are provided with configuration files from a variety of network devices and services, including both CLI-based configurations (e.g., routers, switches, firewalls) and API-based configurations from cloud environments, security platforms, and SD-WAN systems.

Your task is to:
1. Analyze both CLI-based and API-based configurations, identifying common patterns in the following categories:

   - SNMP configurations

   - NTP server settings

   - Routing protocols (e.g., BGP, OSPF)

   - Security settings (e.g., ACLs, firewall rules, security groups)

   - VPN configurations (e.g., IPsec, MPLS)

   - Quality of Service (QoS) settings

   - Access control (e.g., AAA, RBAC, SSH)

   - Cloud-specific settings (e.g., VPC configurations, cloud security groups)

   - SD-WAN and security-related configurations (e.g., traffic policies, security zones, segmentation policies)

2. Detect any unknown patterns or recurring configurations that are not predefined. This could include:

   - Common configuration pairs across different services or devices.

   - Configuration structures that frequently appear together but are not explicitly defined as a pattern.

   - Naming conventions, styles, or organizational methods in cloud or security configurations.

3. Identify anomalies or outliers that deviate from the common configurations. These could include:

   - Legacy settings, deprecated commands, or duplicate entries (e.g., multiple NTP servers or unused firewall rules).

   - Misconfigurations in cloud environments (e.g., open security groups) or conflicting configurations in SD-WAN (e.g., overlapping segmentation policies).

4. Highlight any "ghost" configurations—settings that may exist but are redundant, not actively used, or could cause issues in the future. This could include:

   - Leftover CLI commands from previous configurations.

   - API configurations in cloud or SD-WAN systems that are misaligned with current policies but not actively causing problems.

5. Provide a summary of findings for both CLI-based and API-based configurations, categorized by device type, service, or configuration category. Where applicable, recommend whether these configurations should be standardized, flagged for review, or removed.

Format the results in a report structure, with clear separation between the types of configurations (e.g., CLI-based, cloud, security, SD-WAN) and provide recommendations on any needed remediations or improvements.

Documenting Baselines, Trends, & Anomalies

The next step is to document the findings of the previous steps. The deliverables that should be developed as outcomes of this phase include:

Unified Configuration Baseline: The collected configs and analyses should be collected into a single repository or document store to establish the baseline. This unified baseline serves as the starting point for creating the Golden Configuration Templates.

Identification of Configuration Patterns and Inconsistencies: The results of the analysis should be documented to indicate which patterns emerged, showing where configurations are consistent and where they diverge. This includes identifying commonly used settings, frequently applied security policies, and region-specific variations. Any inconsistencies flagged during this analysis help pinpoint areas needing standardization.

Documentation of Compliance Gaps: The documentation should  highlight any gaps where current configurations do not meet regulatory or security standards, such as outdated encryption protocols or missing access controls. Documenting these compliance gaps provides a clear roadmap for addressing risks in future phases.

Insights into Configuration Drift: This phase may reveal instances of configuration drift—where devices have gradually diverged from expected settings. This insight helps identify systemic issues and prioritize areas for remediation.

These deliverables will collectively provide a details of the network’s current configuration state, establishing a strong foundation for implementing standardized, compliant, and secure configurations in the following phases.

Phase 3:
Definition & Development of Golden Configurations

Establishing Golden Configuration standards and templates is a critical step in ensuring that configurations remain consistent, compliant, and aligned with organizational goals. This phase involves creating standardized templates for each device type and implementing robust version control to maintain configuration integrity over time.

Best Practices for Defining Standards & Templates

Use Device-Specific Templates: Create templates tailored to specific device types and network elements (e.g., routers, firewalls, switches). These templates should account for device capabilities and security requirements while following organizational standards.

Incorporate Vendor and Regulatory Guidelines: Ensure templates integrate vendor-recommended settings and industry compliance requirements, such as encryption protocols, firewall rules, and access controls. This helps maintain both performance and regulatory compliance.

Define Acceptable and Unacceptable Variations: Not all devices or configurations are identical; thus, it’s essential to define what variations are acceptable (e.g., regional settings, custom access controls) versus unacceptable (e.g., disabled security protocols). Document these distinctions to reduce confusion during compliance checks.

Formalizing Golden Configuration Categories

A key step in this phase is establishing a well-defined hierarchical structure for categorizing devices. Examples include:

Device Types: Differentiating between routers, firewalls, switches, and cloud-based instances.

Vendor and Model Specifics: Accounting for specific hardware capabilities and features (e.g., Cisco ASR routers in core networks versus Juniper edge routers).

Functional Roles: Categorizing configurations based on their network role, such as core, distribution, and access layers.

Regional and Site-Specific Requirements: Including compliance and regional optimizations (e.g., security policies specific to the EU or access controls for US sites).

Building Golden Configuration Templates

Once categories are defined, the next step is to define the code that will represent the “Golden Config” for each of the categories.

Creating effective Golden Configuration Templates requires a thoughtful approach to ensure that each template captures the optimal, standardized settings for a specific category. Here are some recommended steps to help you select or construct the configurations that align with the needs of your network:

1.     Leverage Known Good Configurations: Start by identifying existing configurations from devices that have a history of stable and secure operation. These configurations, which may already reflect best practices, can serve as a foundation for the Golden Configuration Template. Extract specific settings, such as security protocols, access controls, or routing configurations, that are consistently applied across similar devices and roles.

2.     Collaborate with Subject Matter Experts (SMEs): SMEs, particularly those with expertise in network architecture or security, can provide insights into the most effective settings for each device type and category. Their knowledge can help ensure that each template meets both operational and security standards, incorporating advanced configurations that may be unfamiliar to the broader team. SME involvement is especially valuable for defining settings in complex areas like Quality of Service (QoS) or BGP routing policies.

3.     Engage with Vendors for Best Practice Recommendations: Network equipment vendors often publish configuration best practices and recommended templates for their devices, covering aspects like performance optimization, security hardening, and compliance. Consult these resources to ensure your templates align with the vendor’s latest guidance. This is particularly useful for configurations involving proprietary features, such as Cisco’s DNA Center settings or Juniper’s security policies.

4.     Align with Regulatory and Compliance Requirements: For templates used in environments subject to regulatory standards (e.g., PCI-DSS, HIPAA, or GDPR), ensure that the configurations meet those specific requirements. This may involve adding or adjusting settings related to data encryption, logging, and access control.

5.     Iterate and Refine Based on Testing and Feedback: Once initial templates are created, validate them by applying them in test environments or to a small subset of devices in production. Collect feedback from operational teams and monitor the performance of these templates. Adjust the configurations as necessary to address any issues or inconsistencies, ensuring that the Golden Configuration truly represents the optimal settings for your network.

6.     Document Configuration Rationales: For each template, document the rationale behind the selected configurations. This documentation should include references to best practices, SME advice, vendor guidelines, and compliance requirements. Having a documented rationale helps maintain consistency in future updates and provides clarity to team members about the purpose of each configuration choice.

Once documented, these configurations can be entered into the Itential platform.

Creating the Golden Configuration compliance trees is covered in the Itential Golden Configuration documentation, available at: https://docs.itential.com/docs/golden-configuration-iap-on-prem.

During this phase, teams should create the Golden Configuration Compliance tree that align with the categories developed in earlier phases and should be prepared to run the initial compliance check.

Phase 4:
Initial Compliance Check & Non-Compliance Categorization

With standardized configurations in place, the organization can now conduct the initial compliance check to assess alignment of the existing network devices with the Golden Configuration.  The initial compliance check will identify all the configuration components that are out of compliance with the golden configuration. For each non-compliant configuration line, team members should determine the type of non-compliance using the categories below.

Identifying & Categorizing Non-Compliance

Non-compliance issues can be categorized into three groups:

Needing Remediation: Deviations that violate the Golden Configuration and pose risks. For example, missing NTP servers that could impact time-sensitive applications. These deviations are identified as critical issues and must be corrected to restore alignment with the Golden Configuration.

Justifiable Non-Compliance: Deviations that, while non-standard, are necessary for specific business or operational reasons. For instance, a unique security configuration might be justified by a specific regulatory requirement in a particular region, such as data localization laws in specific countries.

To Be Added to the Golden Configuration: Consistent deviations that indicate emerging best practices or commonly required configurations should be evaluated for inclusion in the Golden Configuration. For example, if a unique QoS policy is consistently applied across multiple locations to enhance video streaming performance, it may be worth incorporating this into the standardized templates.

Refining the Golden Configuration Templates

Based on the compliance findings, the Golden Configuration templates should be refined and updated to capture any new, necessary configurations. This iterative process ensures that the Golden Configuration evolves with changing business needs and industry standards. For instance, if a security audit identifies that multi-factor authentication (MFA) is now a required standard, templates should be revised to include MFA configurations across all devices.

After refining the templates, it is essential to re-run compliance checks to verify that all necessary configurations are accurately captured. This reinforces the importance of maintaining version control and documentation throughout the entire process, ensuring that all changes are tracked and transparent to the network management team.

Phase 5:
Remediation & Continuous Monitoring

Achieving compliance is not a one-time effort, but an ongoing responsibility. Continuous monitoring and proactive remediation are essential to sustain network consistency and security over time. This phase focuses on establishing processes to address non-compliance issues and monitor the network for emerging risks.

Developing a Remediation Plan

Remediation plans should assign specific tasks to network engineers, outlining clear steps for addressing non-compliant configurations. For example, if a compliance check reveals that routers in multiple regions are using outdated SNMP versions, the plan should include detailed remediation steps, such as updating SNMP settings, validating the changes, and documenting the updates.

Automation plays a key role in the remediation process. Itential’s automation workflows allow organizations to streamline the correction of non-compliant configurations, reducing manual effort and minimizing the risk of human error. In scenarios where automated remediation is feasible, such as updating outdated NTP server configurations, these workflows can be scheduled and executed directly within Itential.

Creating a Structured Remediation Plan

Prioritize by Risk and Impact: Begin by categorizing non-compliant configurations based on their potential risk and business impact. High-risk configurations affecting critical systems should be remediated immediately, while lower-risk deviations can be scheduled for regular maintenance cycles.

Define Remediation Steps: For each category of non-compliance, outline specific remediation steps. Include steps for configuration updates, security adjustments, and testing to ensure the changes do not introduce new issues.

Assign Responsibilities: Designate team members or roles responsible for implementing remediation. Use clear ownership guidelines to ensure accountability and timely completion of remediation tasks.

Documentation and Change Tracking: Document each remediation action, noting the reason for the change and the expected outcome. Maintain a change log that includes pre- and post-remediation configuration states, ensuring full traceability.

Establishing Continuous Monitoring Using Itential

Continuous monitoring is vital to ensure that network configurations remain aligned with the Golden Configuration over time. Organizations should establish automated compliance checks at regular intervals, such as monthly or quarterly, to proactively detect new deviations. Itential’s alerting and reporting features provide real-time notifications to network teams, enabling rapid response to potential issues.

As technologies, regulatory requirements, and organizational goals evolve, so too must the Golden Configuration standards Teams should regularly review, update, and refine these standards to ensure they remain relevant and effective.

To keep configurations aligned with evolving needs, implement a structured review and improvement cycle:

Quarterly Reviews: Conduct quarterly reviews of Golden Configuration standards, incorporating insights from recent compliance checks, security incident reports, and stakeholder feedback. Quarterly reviews ensure that configurations stay current with security trends and operational requirements.

Annual Overhaul: Perform a comprehensive annual review of all Golden Configuration templates, particularly when new technologies, industry regulations, or organizational changes impact network requirements. This is an opportunity to update baselines, review compliance metrics, and integrate lessons learned.

Stakeholder Involvement: Involve key stakeholders—such as network engineers, compliance officers, security professionals, and business leaders—in these reviews. Each group provides unique perspectives that ensure the Golden Configuration remains balanced between technical, regulatory, and business priorities.

Leveraging Data Insights for Improvement

Use data gathered from compliance checks, remediation reports, and performance metrics to guide continuous improvement:

Identify Patterns and Trends: Regularly analyze compliance data to identify recurring non-compliance issues. Patterns may reveal areas where additional training, process changes, or template adjustments are needed.

Adjust Configurations for New Threats: Stay informed of emerging security threats and adapt configurations as needed to mitigate risks. Integrating threat intelligence into your Golden Configuration updates ensures configurations are proactive against new vulnerabilities.

Optimize for Operational Efficiency: Review remediation metrics to identify areas where automation or process improvements can reduce time-to-compliance or manual intervention.

Adaptation to Regulatory & Business Changes

Golden Configuration standards must adapt to regulatory updates and changes in business strategy:

Regulatory Compliance Adjustments: Whenever new regulatory standards are introduced (e.g., GDPR updates, PCI-DSS changes), update Golden Configuration standards to ensure ongoing compliance. Document each change and assess its impact on current configurations.

Alignment with Business Initiatives: As organizational priorities shift (e.g., cloud adoption, IoT deployments, edge computing), adjust configurations to support new initiatives. For example, as more devices connect remotely, Golden Configurations should incorporate stricter access controls and endpoint security measures.

Documentation & Change Management

Maintain thorough documentation of all updates to Golden Configuration standards, ensuring that every change is traceable and validated:

Changelog for Golden Configurations: Document each update, including the reason for the change, expected outcomes, and any relevant risks or mitigation measures. A detailed changelog provides transparency and accountability.

Training and Knowledge Transfer: Communicate updates to all relevant stakeholders, providing training when necessary to ensure that network teams understand and follow the updated configurations.

Audit Readiness: Ensure that each configuration change is logged and auditable, supporting transparency and compliance. Regular audits of configuration documentation will confirm that changes align with organizational policies and regulatory standards.

Template Maintenance & Review Cycles

To keep Golden Configurations effective and aligned with evolving requirements, implement regular review cycles for templates:

Quarterly or Biannual Reviews: Schedule regular reviews of each template, ideally every quarter or six months, to account for changes in regulatory standards, security threats, or operational needs.

Stakeholder Collaboration: Engage stakeholders—including network engineers, compliance officers, and security teams—in these reviews to gather diverse perspectives and ensure templates remain relevant.

Update Notifications and Training: When a template update is approved, communicate changes to all relevant team members. Provide training if needed to ensure that team members understand the new configuration and any updated best practices.

Conclusion

The benefits of adopting the Golden Configuration Methodology extend beyond immediate security and compliance improvements. Organizations that implement this methodology can streamline network operations, minimize risks associated with configuration drift, and free up valuable resources to focus on strategic initiatives and business growth.

Ultimately, the Golden Configuration Methodology empowers organizations to transform their approach to network management, creating a unified baseline that supports long-term agility, security, and efficiency in an ever-evolving network landscape.

Appendix:
Golden Configuration & Compliance Program Project Plan

Sprint 0: Project Kickoff & Planning

Objective: Set up the project framework, define team roles, and align on goals and milestones.

User Story: As a project team, we need to align on objectives, roles, and expectations to ensure project clarity.

Tasks:

  • Define project goals and success metrics.
  • Assign team roles and responsibilities.
  • Review available resources, tools, and access (e.g., Itential platform).
  • Create a project timeline with milestones and review points.
  • Hold a project kickoff meeting with stakeholders.

Outcome: Clear project roadmap and understanding of team roles and milestones.

Sprint 3: Phase IIb – Analysis of Current State (Data Analysis)

Objective: Analyze collected data for patterns, inconsistencies, and compliance gaps.

User Story:  I need to identify trends and anomalies in configurations to highlight areas for improvement.

Tasks:

  • Use LLMs or analysis tools to detect configuration patterns and anomalies.
  • Document compliance gaps, configuration drift, and systemic inconsistencies.
  • Create a report summarizing findings and recommendations for addressing gaps.

Deliverables: Analysis report detailing configuration patterns, compliance gaps, and areas for standardization.

Outcome: Detailed assessment of the current configuration state, including compliance and drift insights.

Sprint 2: Phase IIa – Analysis of Current State (Data Collection)

Objective: Gather configuration data from network devices to establish a baseline.

User Story: I need to collect current configurations to understand the baseline for our network.

Tasks:

  • Use Itential to pull configurations from CLI-based and API-based devices.
  • Store configuration data in a centralized repository for analysis.
  • Ensure configurations are collected from all device types, including routers, switches, firewalls, and cloud systems.

Deliverables: Comprehensive dataset of current configurations across the network.

Outcome: A unified configuration baseline stored in a single repository.

Sprint 1: Phase I – Preparation

Objective: Identify sources of configuration diversity, categorize acceptable vs. unacceptable variations, and prepare documentation.

User Story: As a network team, we need to identify sources of configuration diversity to understand the current state of configurations.

Tasks:

  • Conduct stakeholder interviews and discussions to identify sources of diversity.
  • Document operational, historical, and business-driven variations in configurations.
  • Classify variations as acceptable or unacceptable.
  • Create a working list of configuration categories for future phases.

Deliverables: Documented list of configuration diversity sources, categories, and classification of variations.

Outcome: Comprehensive documentation of acceptable and unacceptable configuration variations.

Sprint 4: Phase III – Define Golden Configuration Templates

Objective: Develop standardized configuration templates for each device category and role.

User Story: I need to create Golden Configuration templates to standardize configurations across devices.

Tasks:

  • Define categories for device types, vendor specifics, and functional roles.
  • Work with SMEs and vendors to draft configuration snippets based on best practices.
  • Test templates in a controlled environment to verify their effectiveness.
  • Document rationale for each template’s settings.

Deliverables: Golden Configuration templates for each defined category, along with documentation.

Outcome: Standardized templates that serve as the configuration baseline for different device types and roles.

Sprint 5: Phase IV – Initial Compliance Check & Non-Compliance Categorization

Objective: Conduct compliance checks against the Golden Configuration and categorize non-compliance issues.

User Story: I need to check current configurations against the Golden Configuration and categorize any deviations.

Tasks:

  • Run automated compliance checks using Itential.
  • Categorize non-compliance into “needing remediation,” “justifiable,” and “to be added.”
  • Document and classify each non-compliant item for further action.

Deliverables: Compliance check report with categorized non-compliance items.

Outcome: Clear categorization of non-compliant items to guide remediation efforts.

Sprint 6: Phase V – Remediation Planning & Execution

Objective: Develop and execute a remediation plan to address critical non-compliance issues.

User Story: I need a structured plan to address and correct non-compliant configurations.

Tasks:

  • Prioritize non-compliant items based on risk and business impact.
  • Define remediation steps for each non-compliance category.
  • Assign team members to remediation tasks and begin execution.
  • Document changes and maintain a change log for audit purposes.

Deliverables: Remediation plan, change log, and documented remediations.

Outcome: Corrected configurations aligned with the Golden Configuration standard.

Sprint 7: Phase VI – Continuous Monitoring Setup

Objective: Implement ongoing compliance checks and establish a continuous monitoring process.

User Story: As an operations manager, I need to monitor configurations continuously to maintain compliance.

Tasks:

  • Schedule regular compliance checks using Itential.
  • Set up real-time alerts and dashboards for non-compliance issues.
  • Develop a review cycle for configuration updates, including quarterly reviews and annual overhauls.

Deliverables: Continuous monitoring schedule, real-time alerts, and compliance dashboards.

Outcome: Ongoing monitoring of configurations to ensure continuous compliance with the Golden Configuration.

Sprint 9 & On: Retrospective & Continuous Improvement Planning

Objective: Review the project outcomes and plan for future improvements.

User Story: As a project team, we want to assess what worked well and identify areas for improvement.

Tasks:

  • Conduct a retrospective meeting to discuss successes and challenges.
  • Gather feedback from stakeholders on the Golden Configuration process.
  • Plan for iterative improvements based on lessons learned.

Deliverables: Retrospective report and a continuous improvement plan.

Outcome: A plan for future enhancements to keep the Golden Configuration program effective and up to date.

Appendix:
Analysis of Current State – Data Collection Template

Purpose: This template is used to document the process of collecting network configuration data in high-volume environments, creating a clear baseline for analysis in the Golden Configuration Process.

Section 1: Device Inventory Summary

Device TypeApproximate CountPrimary Vendors ModelsRegions LocationsRoles (e.g. Core, Edge)Collection Methods (CLI/API)Notes
Routers
Switches
Firewalls
Cloud-Based Applications
Virtual Network Devices
Other Device Type

Instructions:

  1. Provide an estimated count for each device type to capture the overall scale of the network.
  2. List primary vendors/models to identify hardware or software variations.
  3. Specify general regions or locations (e.g., North America, EMEA) or major sites if applicable.
  4. Describe the main roles each device type serves in the network (e.g., edge router, core switch).
  5. Identify the primary data collection methods (e.g., CLI, API).
  6. Include any relevant notes, such as specific vendor requirements or collection challenges.

Section 2: Configuration Data Collection Categories

Configuration CategoryCLI CommandAPI EndpointData Collected (Y/N)Notes
Routing Configurations
Security Settings
VPN Configurations
Access Control (AAA, RBAC)
SNMP Configurations
NTP Server Settings
Quality of Service (QoS)
Cloud-Specific Settings
SD-WAN Policies

Instructions:

  1. For each configuration category, list the specific CLI commands or API endpoints used to pull data.
  2. Indicate if the data was successfully collected (Y/N).
  3. Include notes for each category to capture any issues, additional details, or dependencies in the collection process.

Section 3: Summary of Collected Data

Total Number of Devices in Scope:

Configuration Categories Collected (e.g., 8 out of 10):

Summary of Data Collection Status:

Complete: All intended configuration data collected successfully.

Partial: Some data collected but certain categories or devices remain incomplete.

Challenges Encountered: Describe any specific difficulties, such as inaccessible devices or incompatible data sources.

Instructions:

Summarize the overall data collection status and note any gaps or challenges encountered. This high-level view provides a quick assessment of data completeness.

Section 4: Centralized Repository for Collected Data

Repository Location (e.g., file path or database location for collected configurations):

Access Permissions: Specify who has access (e.g., network engineers, compliance team).

Backup and Security Measures: Document any security protocols and backup strategies to protect the collected configuration data.

Instructions:

Define where data will be stored, who can access it, and how it will be secured.

Section 5: Initial Observations & Insights

Common Configuration Patterns: Note any recurring settings or patterns across similar device types (e.g., common routing protocols, security configurations).

Inconsistencies or Deviations Observed: Describe any initial inconsistencies, such as mismatched security policies, time zone settings, or access controls.

Data Gaps or Collection Challenges: Identify specific devices or categories where data collection was incomplete or difficult, including reasons for these gaps.

Preliminary Recommendations for Phase III: Based on initial insights, list any recommended actions, such as targeted follow-up collection, adjustments to collection methods, or early template considerations.

Instructions:

Record any immediate observations that may influence later phases, particularly areas where further data collection or specific template development will be required.

Get Started with Itential

Schedule a Custom Demo

Schedule time with our automation experts to explore how our platform can help simplify and accelerate your automation journey.

Meet With Us

Try Now for Free

Try Itential’s Automation Service free for 30 days, full access, no credit card required.

Get Started

See Itential Products in Action

Watch demos of Itential's suite of network automation and orchestration products.

Watch Now