When I ask network teams whether they are enforcing configuration policies, more often than not the reply is an awkward silence.\u00a0 Why?<\/p>\n
First, what do I mean by a policy? \u00a0It\u2019s often thought of as a \u201cGold Standard\u201d configuration or list of config requirements for network devices. \u00a0Most network engineering teams have these standards and best practices, born from years of experience managing networks. \u00a0In some cases, policies are also mandated from external industry or governing agencies such as PCI, DISA STIG, NERC, FERC, or many others.\u00a0 Policy requirements exist to ensure security, reliability, optimization, and consistency of the network. \u00a0\u00a0A couple very simple examples include ensuring insecure services are disabled (such as HTTP) and authentication requirements are met on the infrastructure devices.<\/span><\/p>\n So why are organizations not actively enforcing these policies?\u00a0 \u00a0Simple:\u00a0 it\u2019s complicated & time consuming. \u00a0The concept seems easy enough, but the reality is far from it.\u00a0 Most consider detailed policy enforcement not practical with the exception of infrequent and partial manual checks.\u00a0 The result is recurring, wasted manual effort, security risks, network stability problems, and excessive troubleshooting time.<\/span><\/p>\n Perhaps the biggest challenge is that a configuration text file can\u2019t encompass all the complex, conditional situations that arise when testing requirements against a production network.\u00a0 Configuration requirements on the same make and model of device can vary from device to device, interface to interface, or other objects based simply on how the device is used, where it is in the network, what services are enabled, what it is connected to, what protocols are used, or any number of other situational variables.<\/span><\/p>\n Further complicating the challenge is that security configuration requirements go well beyond what is contained in the device config file.\u00a0 Two use case examples include ensuring proper OS\/Firmware versions, and evaluating rules conditionally with contextual information from SNMP, CLI show commands, or external data sources.<\/span><\/p>\n Infoblox NetMRI provides unique capabilities that make dealing with these complex scenarios practical, perhaps for the first time in many cases.\u00a0 All resulting from years of responding to customer feedback and needs. Check out our community site for some examples or simply reach out any time with questions.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" When I ask network teams whether they are enforcing configuration policies, more often than not the reply is an awkward silence.\u00a0 Why? First, what do I mean by a policy? \u00a0It\u2019s often thought of as a \u201cGold Standard\u201d configuration or list of config requirements for network devices. \u00a0Most network engineering teams have these standards and […]<\/p>\n","protected":false},"author":233,"featured_media":1797,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[3],"tags":[16,113],"class_list":{"0":"post-2897","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-community","8":"tag-infoblox","9":"tag-networking-control","10":"entry"},"acf":[],"yoast_head":"\n