Understand operational security (2023)

Satisfied

General descriptionThree security components
operational threats
Operational Security Measures
defense in depth
Complexity and Security
Regulation and Compliance
Cisco products covering operational security
Summary
expressions of gratitude
References

In discussions of Multiprotocol Label Switching (MPLS) VPN security, the general statement often heard is: MPLS is not secure, because a simple operator error (such as misconfiguring a route destination) can break VPN isolation. Such statements show some fundamental misunderstandings, which this white paper will try to explain.

Another similar example may illustrate why operational errors are not an argument against a given technology. Suppose an operator makes a mistake configuring a firewall that accidentally leaves a security hole open. No one would argue that firewalls are insecure because of such an act. Since the operator has the authority to make changes, he also has the authority to make mistakes. These examples help to show why operational issues are a different category of security. Strictly speaking, you cannot trust your network operators, which can pose a very difficult problem.

Security depends on three components, each independent of the others:

• Architecture(or algorithm) set: This is the formal specification. In cryptography it is the algorithm itself, in the case of MPLS VPN it is the formal specification (as defined in RFC4364).
• Implementationarchitecture or algorithm: Refers to how the architecture or algorithm is actually being implemented. Programming errors such as buffer overflows can affect this component.
• Operationsame: This includes carrier issues such as choosing weak passwords on routers or workstations or accidentally disclosing a shared key. For example, settings can be sent to untrusted third parties.

Note that these components are not specific to networking or even computing. Physical security has the same three fundamental properties and the possibility of failure in any one of them. A door lock, for example, may have design deficiencies (e.g., built with the wrong material), manufacturing errors (e.g., not being properly secured to the door), or operational errors (e.g., leaving the key under the door). door). . of the doormat). ).

The main conclusion is that an operational error, such as a misconfiguration in an MPLS Provider Border (PE) router, does not automatically imply that the architecture is insecure. Configuration errors can occur in any technology, which means that operational security measures must be implemented to detect such problems.

There are two types of operational security issues:

• accidental misconfigurations: These are accidental in nature and are by far the most frequent type of operating problems. Misspelling a value (such as route destination in MPLS VPN) is one example, or forgetting instructions at a firewall is another example.
• deliberate configuration errors: These are of a deliberate nature, but vary in their degree of malice. For example, violating security policy to allow access to an operator's home system through the corporate firewall is probably not as serious as acts of sabotage by a disgruntled employee.

The impact of misconfigurations of any kind can range from little or no effect to catastrophic. This is especially true in the case of accidental misconfigurations, where there is a reasonable chance that even the true extent of the resulting security breach will not be discovered. It should also be noted that only a small fraction of possible configuration errors will result in a security breach. Deliberate misconfiguration is naturally more likely to lead to a breach since there is malicious intent aimed at violating the security policy.

For MPLS VPNs today, the biggest concern in the industry is accidental misconfigurations. The likelihood that an operator will mistype a route destination or make other configuration errors cannot be ignored. This type of error can cause a certain VPN site to become part of another VPN, breaking the separation of both VPNs. When this happens by accident, it is unlikely that either party will discover the true nature of the incident. The misplaced site will usually notice that you can no longer access your business applications, while the other VPN might not notice the breach unless there is an address space overlap or some routing issues due to the new prefixes. This issue is a serious concern for VPN users.

The typical reaction when looking for a solution to a security issue is to look for resources to configure. It is important to understand that operational issues cannot be completely resolved with features, as the misconfigured person can also remove the feature that serves to protect against misconfigurations. Operational problems require operational solutions and organizational operational competence.
Operational solutions include:

• Operational Safety Policy: There should be clear guidelines on what operators can and cannot do. It is necessary to define escalation routes that describe the steps to be followed in case an operator does not have the necessary authorization for a specific action. The security policy must clearly define responsibilities and powers, as well as disciplinary actions in case of non-compliance. The policy also acts as a deterrent against deliberate misconfigurations.
• change management process: Every company running a network must create precise processes that define and control how changes are performed on the network. The integrity of the hardware, operating system and settings must be monitored and all changes must be logged and executed in a controlled manner. Logs should be evaluated and checked for possible configuration errors. Logs can also be used to prove a deliberate breach of operational security policy. (For this, the concept ofdual controlis important and is discussed below).
• Access control: It is good practice to restrict access to network devices. Access restrictions are traditionally implemented on networks through AAA authentication. This security measure is normally implemented, although in many networks many operators have access to network devices. Restricting this number to the minimum number of operators required reduces risk.
• Authorization: An operator's access should be restricted to the minimum access necessary for the operator to perform his job. In most cases, it's not a good idea for all operators to have full (level 15) access to devices. This practice can be more difficult to implement; however, simple distinctions such as who can and cannot enter configuration mode are very helpful.
• dual control: Security control and network control should not be the responsibility of the same group. Ideally, a security group controls who has access to what, and a network group performs configuration actions. Typically, logs are controlled by security group. This way, it is much more difficult to deliberately misconfigure devices, as the security team can recognize a misconfiguration in the log files.
• protect and verify: All of the above measurements are active attempts to detect a network change, such as a configuration change. It is also possible to detect policy violations by analyzing network traffic or the state of dynamic information such as routing tables, ARP tables, etc. For example, intrusion detection systems can create alerts when they detect network flows that do not match the policy. There are many other ways to monitor traffic anomalies. For example, Cisco IOS NetFlow can be critical in detecting misrouted packets on the network, and routing tables can be checked for missing or unknown routing prefixes.
• Automation: In general, it is recommended to automate processes and procedures, specifically recurring scan processes, because details in log files and similar processes tend to be overlooked by humans. Automated processes are also less likely to make mistakes, although if an error does occur it is often systematic and therefore easily detectable.

It can be very difficult to implement a comprehensive operational security environment, and some measures (such as dual checks) may require a certain organizational size to work properly. The goal should be to make incremental improvements to the overall operational process. For example, precise command-level authorization schemes can be difficult to implement and expensive to operate in large networks. Other parts of the negotiation process are much easier to apply. For example, one such mechanism is a dual control system. Sending all access and configuration logs to a separate log server, which network operators do not have access to, is a step towards discouraging deliberate misconfiguration of network devices.

Extending the network to third parties, either by outsourcing parts of the network or certain aspects of network management, or by making extranets available, requires third parties to comply with operational security measures. This adds significant complexity to the operational security policy.

The main problem with many operational control functions is that they do not always prevent errors from occurring. They can make it harder for bugs to occur, but a lot of it is focused on catching bugs after they happen. This can largely resolve deliberate misconfigurations because an engineer would likely not violate security policy if he knew the attack could be detected and traced back to the engineer. But it is not always possible to proactively prevent errors. Obviously, this causes security issues.

Many organizations consider additional security measures to make the overall system more resistant to misconfigurations.

To maintain separation when the core network does not provide complete separation, possibly due to misconfiguration, IPsec can be considered in addition to MPLS VPN. GET VPN is a variant of IPsec, which is especially suited to run in addition to MPLS VPN. If an organization runs an IPsec VPN in addition to an MPLS VPN, carrier errors in the MPLS core will not break the separation of the VPN as it is also secured by IPsec. However, this represents an additional cost and operational burden. Some organizations choose to deploy two independent firewalls with different operating groups so that no errors or misconfigurations can affect overall security.

The use of multiple layers of security is called defense-in-depth and is a common model in security deployments. However, adding additional layers of security should not be done without a proper risk analysis. It is important to understand the threats, their impact on the organization and the cost of additional security measures.

A risk analysis must determine whether the cost of additional security measures is in balance with the cost of the actual risk without the additional security measures. In other words, a risk analysis must determine whether the impact of the risk is large enough to justify the additional cost of additional countermeasures. However, such a risk analysis must take into account the entire network, including all its current assets and countermeasures. Proper risk analysis requires significant resources.

The complexity of a network increases the likelihood of operational errors and security breaches. This applies to both the architecture of the network and the existing methods of securing the network. From a security perspective, less complex configurations are generally preferred.

This perspective also applies to the operational management of the network. Overly complex operating procedures are more likely to cause problems. For example, in a very complex operating procedure, a group of operators may not have the necessary privileges to perform an emergency operation. Under stress, the immediate reaction in these cases is to disable some security controls.

There is no clear guideline on what is too complex, as this also depends on the company's operating model. This parameter will be different for a highly skilled team and a frontline support team.

The main message is that adding additional operational measures, for example, command-level authorization or additional security measures such as IPsec, increases the complexity of the network and, in some cases, can result in less security because the network is becoming very complex. to maintain.

There are a growing number of regulations requiring certain operational security measures, such as PCI, HIPAA and Sarbanes-Oxley. These regulations are the main drivers of many operational safety measures today. Accurate access control and authorization, as well as logging, are essential requirements of most industry compliance standards.

Companies considering operational security measures should check which regulations apply to their business and what each regulation requires.

While operational security is a process and less feature or product driven, there are several Cisco products that address operational security:

• Cisco ACS e Cisco Identity Services Engine (ISE)(AAA servers): Helps with user authentication and authorization. AAA servers build the core of an operational security model. (http://www.cisco.com/go/acs/yhttp://www.cisco.com/go/ise)
• Cisco Intrusion Detection and Prevention Product Family: IDS/IPS products can alert when traffic is detected that violates the operational security policy.
• Cisco IOS: Contains various features that help with operational security, CLI views restrict the actions a user can perform. Login enhancements provide information about failed login attempts, etc. (http://www.cisco.com/go/ios/)

Operational errors can break security policies and are a major concern for service providers and enterprises alike. Most operational errors cannot be completely avoided; however, it is possible to reduce the risk of error. The ability to detect an error and trace it back to its source can also prevent internals from malicious misconfigurations or help quickly detect operator errors.

Industry compliance regulations require certain operational safety measures. Network operators must check which regulations apply and verify that the necessary measures are implemented.

It is often possible to provide additional security measures that are not completely dependent on operational errors. However, before implementing additional security measures, a formal risk analysis should be performed to balance the cost of the additional measures against the cost of the risk incurred due to operational deficiencies.

Michael Behringer (mbehring@cisco.com)
Distinguished Systems Engineer

RFC 3871: Operational Security Requirements for the IP Network Infrastructure of Large Internet Service Providers (ISPs)
http://www.ietf.org/rfc/rfc3871.txt

GET VPN
http://www.cisco.com/go/getvpn/

Normative compliance
http://www.cisco.com/go/compliance/

This document forms part ofcisco securityportal. Cisco provides the official information contained in thecisco securityPortal in English only.

This document is provided "as is" and no warranty of any kind is implied, including warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked to the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.

come back up