ES2911500T3 - Physically Secured Authorization for Utility Applications - Google Patents

Abstract

A method of operating a network having a plurality of endpoints (26) that communicate with a first data center (70) and a second data center (72) through access points (APs), in which that the first data center (70) includes a first physically secure environment having a first certificate, and the second data center (72) includes a second physically secure environment having a second certificate, the procedure comprising: receiving, by of the second physically secure environment, an indication that the security of the first secure environment has been compromised; and in response to receiving the indication, issuing, by the second physically secure environment, a command to the access points to configure a certificate revocation list indicating that the certificate associated with the first physically secure environment is not valid; and issuing, by the second physically secure environment, a command to the endpoint nodes to load the certificate revocation list from any of the access points.

Description

DESCRIPTION

Physically Secured Authorization for Utility Applications

technical field

This disclosure refers to the management and control of operations associated with public service companies, and more specifically to the security of the systems that manage and control said operations.

Background

Utilities have complex and highly interconnected systems, running on physical servers running a multitude of associated software modules to manage and control utility operations. Figure 1 is a general block diagram of some of the components that can be found in a typical management and control system of a utility company that supplies electricity to customers, and possibly other basic products such as gas, water, etc. . The back office (company management office) 10 of the system comprises a series of individual subsystems associated with various operations of the company, for example a customer information system (CIS) 12, a customer relations module (CRM ) 14, an outage management system (OMS) 16, a GPS information system 18, a billing system 20, a network stability module 22, and a user interface 24. Although not illustrated in Fig. 1 , there may be other functional modules in the back office 10. Some of these subsystems may have the ability to communicate with the devices of the distribution network of the services that are supplied, and remotely control the operations associated with these devices. For example, the back office server may communicate with individual meters 26 located at customer premises to obtain consumption data for billing purposes, and direct the meters to selectively disconnect or reconnect the customer from the supply of one or more of the basic products provided by the utility company. Other commands from the back office server to individual meters may include commands to accept the flow of outgoing energy from customers.

In the example of Figure 1, the meters constitute end nodes that communicate with the back office via a local area network 30 that has access points 32 that provide input and output to the network. The local area network may be a wireless mesh network. The access points 32 communicate with the back office servers 10 via a wide area network 34 or a dedicated communications link.

In such a system, one issue of concern is the secure management of remote disconnections and reconnections, which can occur when a customer leaves a location or defaults on payments, or when a new customer takes over the location, respectively. Malicious or erroneous orders to remotely disconnect and/or reconnect installations can destabilize the electricity distribution network. Unauthorized reconnections could also lead to distributed power theft. To limit these possibilities, efforts must be made to ensure that command and control operations are conducted safely, and only by entities authorized to conduct such operations. However, since the back office of a typical utility is made up of a variety of interconnected systems, enforcement of secure access becomes difficult. Many different groups within the utility need to access all or part of the software system, complicating the ability to limit logical and/or physical access to individual subsystems.

A possible solution to this problem is to place certain systems, or parts of said systems, within a physically secure environment, hereinafter referred to as a bunker. Examples of a bunker include a restricted access room or container, for example a locked room, and a tamper-proof enclosure or enclosure around a protected system. The bunker severely restricts physical access to the hardware devices on which the systems run, or protected parts of them. Also, the systems inside the bunker export very limited logical access. However, this solution still presents a problem as it is difficult to refactor utility software systems to determine which parts should be inside the bunker and which parts can stay outside to provide more flexible access to those who need it. they need it.

Document US2006/095454 describes a system and method for secure authentication of terminal identity in collaboration between a wireless communication device and a wireless operator. WO02/063847 describes the distribution of mobile certificates in a PKI.

Summary

To provide overall security for a utility management system, critical command and control messages issued to system components are required to be explicitly approved by a secure authority. Explicit approval authenticates the requested action and authorizes the performance of the specific action indicated in a message. The key components of the public services management and control system that are associated with access control are located in a physically secure environment. With this approach, it is only necessary to physically secure the subsystems that are responsible for approving network actions, for example, by means of a bunker. In other words, most of the management modules, such as CIS, CRM, OMS, billing, etc. they can remain outside the bunker, thus avoiding the need to divide those subsystems into bunkered and non-bunkered components. Access to critical components of each of the non-bunkered subsystems is controlled through the bunkered approval system.

The invention to which this European patent relates is defined in the appended claims.

Brief description of the figures

Figure 1 is a general block diagram of a utility management and control system according to a useful example for understanding the present disclosure;

Figure 2 is a block diagram of a utility back office system with bunkered components according to an example useful for understanding the present disclosure;

Figure 3 is a block diagram schematically representing the data flow when sending a message to a meter according to an example useful for understanding the present disclosure;

Figure 4 is a block diagram of the configuration of a hardware security module according to an example useful for understanding the present disclosure;

Figure 5 is a block diagram of a multistage buffer that counts cryptographic operations over a sliding window according to an example useful for understanding the present disclosure;

Figure 6 illustrates an example system and procedure for issuing order permits according to an example useful for understanding the present disclosure;

Figure 7 is a block diagram of an exemplary format of a permission payload according to an example useful in understanding the present disclosure; Y

Figure 8 is a block diagram of a utility control and management system implemented in multiple data centers according to an embodiment of the invention to which this European patent relates.

Detailed description

In order to facilitate the understanding of the principles on which this disclosure is based, it is described below with reference to the safe control of remote connection and disconnection commands in an electrical power distribution system. However, it will be appreciated that this example is not the only practical application of these principles. Rather, they can be used in connection with any type of critical command that, if improperly or erroneously issued, could have the potential to seriously disrupt or damage a system. They can also be used in conjunction with all commands and control messages sent to a critical system component whose correct operation is essential at all times.

Figure 2 illustrates an example of a data center 40 in which the concepts of the present disclosure are illustrated. As is conventional, the data center contains a number of physical servers running various applications 12, 14, 16. Although only a few representative applications are illustrated in the figure, it will be appreciated that a larger number of such applications could be implemented. inside the data center. Conversely, the functions performed by two or more of the applications can be integrated into a single, comprehensive program.

Also located within the data center is a physical bunker 42 with limited physical access, such as a locked room with reinforced walls. As another example, the bunker can be, in addition to or instead of being closed, an area closely guarded or protected by security cameras, motion detectors, etc. Another example is that the bunker may be physically distributed, a security relationship having been established between the distributed parties. As another example, the bunker may be logically secured, such as through the use of run-safe software and/or firmware whose functionality is secured against physical tampering, such as self-destructive packaging. The bunker does not have to be a room, but can be, for example, a physically secure box.

One or more additional server devices having an associated hardware security module 44 are located within the bunker, for implementation of an authorization engine 46 having software modules that perform security related operations such as authorization, authentication and accounting. The hardware security module holds private keys and other secret keys securely. It can also contain public certificates linked to private keys. The hardware security module preferably uses a strong security algorithm, such as elliptic curve cryptography or another high security cryptographic method, to perform the cryptographic operations. An example of hardware security modules that are suitable for the applications described in this document is Utimaco Safeware AG's SafeGuard CryptoServer line of hardware security modules.

Secure access to the bunker, and the server devices located within it, can be enhanced with biosensor technology, for example, fingerprint detection, physical keys or tokens, and/or password protection. In an implementation, a hierarchical and layered security system can be employed to maximize protection. If one level of security fails, for example, if passwords are accidentally revealed or stolen, a higher level security mechanism, such as a key or token-actuated deadbolt lock, can be activated to maintain the physical security of the entire system .

Certain types of orders from back office applications 12-16, etc., which are not restricted in use, will not be able to be executed unless individually authenticated. For example, remote disconnection and reconnection orders are one category of these restricted orders, due to the potential they present for seriously disturbing the stability of the power distribution network. To enhance the security of these types of operations, the applications that carry them out can only accept commands to do so if they originate from a console within bunker 42, or are otherwise authenticated by a permit issued from bunker 42. Therefore, only personnel who have the authority to issue those orders, and who have the necessary means to access the bunker, for example, password, key, fingerprint, etc., will be able to issue the orders restricted to the application.

When an operation is initiated that causes an order to be generated, it may be signed or otherwise authenticated by the authorization engine 46, and then forwarded to an application programming interface (API) associated with the appropriate application external to the bunker. 42. For example, the command may be signed by a private key stored within the hardware security module 44. Upon receipt of the signed command in an external application, eg, one of applications 12-16 or an application running in one of the counters 26, it is verified by a public key to which the application has access. Once it has been verified that it has originated in the bunker, the order is executed by the external application.

In some situations, it may not be practical for an entity issuing remote shutdown orders to be physically present inside the bunker. However, if remote generation of such commands is supported, they could be maliciously issued by users posing as authorized entities. To limit the possibility of these events, a policy module 48 is implemented within the bunker. The policy module can be a separate software or firmware component, as shown in Figure 2, or logically embedded in the hardware security module, as described below. The policy module 48 can be safely reconfigured or reprogrammed, such as by commands entered from within the bunker. This module contains the business logic that examines a requested action and determines whether it will be allowed to take place. For example, if reconnection orders are issued in a sequence, or with a relative timing, that could disturb the stability of the power distribution network, they can be blocked by policy and not passed to the authorization engine for signing. In addition, policy flags can be raised and appropriate actions taken, such as shutting down a command-issuing entity, when certain conditions are detected. These conditions may include, for example:

1. A large number of remote shutdown commands are issued at the same time, for example, at a predetermined time interval, indicating a possible intention to maliciously shut down users from the power distribution network;

2. Commands are issued in a suspicious order, such as a sequence of repetitive connect and disconnect commands that are associated with the same client, or commands that are inconsistent with the current state of a client, for example, issuing a disconnect command to a user who is no longer connected to the electricity grid;

3. An application that is requested does not provide the necessary credentials, or is not otherwise authenticated;

4. An application being requested is not among a set of approved requests that are allowed to issue certain operations; Y

5. The status of the distribution network, based on actual power loads and projected power needs.

To implement this functionality, the bunker may contain a proxy 50 for application programming interfaces (APIs) of applications that are external to the bunker. In operation, when an API call is made to one of these "external" applications, the call goes to proxy 50 inside the bunker. The proxy consults utility business logic in policy module 48 that may be necessary to authorize the request, and causes the request to be signed by the appropriate business logic. The request is then transmitted to the authorization engine 46 for signing. Once authorized, the proxy invokes the normal API for the called application that is external to the bunker, and relays the authorized call.

In an alternate implementation, bunker 42 may not include a proxy. In this case, a request can be made directly to the API of an external application. In turn, the external application calls the authorization engine inside the bunker if it determines that the requested operation requires a signature. By default, all requests could be bunkered for authorization, to avoid the need for any determination by the external application.

Requests sent to the bunker are first verified and signed by the policy module, and then passed to the authorization engine 46. Once a request is authorized, the called application acts on the request.

The hardware security module 44 included in the bunker 42 can operate at two levels. The following are examples related to the operations that are carried out in the counters 26. At the first level of operation, the utility company could institute a policy according to which all communications between an application in the back office 10 and a counter 26, or any other component of the network 30, must be encrypted and signed. The implementation of this policy is shown in the example of Figure 3. In this example, a meter management application 52 has a message, such as a command, to send to one or more of the meters 26. This message is constructed in a counter control and interface module 54 of the application, and is sent to the hardware security module 44 of the bunker 42, with a request to perform the appropriate encryption and signature of the message. Policy module 48 may first check to confirm that the request is from an authorized source. If so, it is passed to the hardware security module. Hardware security module 44 performs the requested operation on the message, using the appropriate keys associated with the application, and returns the encrypted and signed data. The control and interface module 54 of the meter management application then creates a data packet that incorporates the encrypted and signed message, and transmits it to the meter through the network 30.

In the case of the messages received from the network nodes 30 by the application 52, these are first forwarded to the hardware security module, to be decrypted. Module 48 may also perform any appropriate verification of the authenticity of the sender of the received message, and of the integrity of the data. The verified and decrypted message is then returned to the application 52.

For critical operations, such as remote connections and disconnections, the hardware security module can operate at a second level to enforce a rate limit on such operations. Figure 4 shows an example of the internal configuration of a hardware security module. The module is configured with a number of slots. Each slot contains a collection of private keys, certificates, secret keys, and access privileges, to perform cryptographic services such as signing, encryption, decryption, etc. Different slots are associated with different security contexts, and contain the keys, certificates, and other information relevant to their respective contexts. Performing a cryptographic service on an order with the hardware security module, such as signing with a private key, allows the recipient of the order, for example, a node 26, to authenticate the source of the order, using a public key. associated. The policy module 48 makes the initial determination of whether to submit a requested command to the hardware security module for one or more cryptographic services.

Each slot can be selectively configured with one or more rate limits, for example by a command line management tool, to enforce desired trading logic. An example of the order to configure a slot is as follows:

HSM_configure slot=2 rate-name="ratel" window=24h count=10000

Said order configures Slot 2 with a maximum rate limit of 10,000 crypto operations per 24-hour sliding window. If more than this allotted number of crypto operations occur in the previous 24 hours, the slot stops all further crypto operations. Thereafter, an administrator will need to reset the slot by sending a reset command.

A slot can be configured with more than one rate, as follows:

HSM_configure slot=2 rate-name="ratel" window=24h count=40000

HSM_configure slot=2 rate-name="rate2" window=60m count=2000

These two orders set up slot 2 with two rate limit windows, one for 40,000 crypto trades in a 24-hour sliding window, and one for 2,000 crypto trades in a 60-minute sliding window.

If a slot is configured with a rate limit, all cryptographic operations executed on the slot are counted against the assigned limit over a sliding window. In the example above, if there are more than 40,000 crypto operations in the last 24 hours, or more than 2,000 crypto operations in the last 60 minutes, the slot stops any further crypto operations.

Counting of threshold violations can be done in 5-minute increments. Figure 5 illustrates an example where a slot has been configured with a limit of 800 crypto operations in a 25-minute sliding window. The sliding window can be implemented as a multi-stage buffer 56. The illustrated buffer comprises five stages 58, each representing a 5 minute time interval. Each stage contains a count of the number of cryptographic operations performed by the slot during its corresponding time interval. The following table provides a snapshot of the data contained in the buffer at any given time.

If the sum of all counts, in this case 15+0+7+1+6 = 29, exceeds the threshold, the slot stops all further cryptographic operations until it is administratively restarted. An alert mechanism can be implemented to notify administrative staff before operations stop. For example, a first alert can be generated when the total count exceeds 80% of a rate limit, and a second alert if it reaches 90% of the limit.

The stage associated with the most recent interval, in this case Stage 5, keeps a running count of each new cryptographic operation. At the end of each 5 minute interval, the stored counts roll over to the next oldest stage. The last stage resets to zero, and starts counting crypto operations again for the next 5-minute interval.

Since each slot can be selectively configured with its own rate limits, flexibility in implementing business logic is provided. For example, as described below, certain critical commands may require an explicit type of authentication, hereinafter referred to as "permission", before they can be executed. These commands can be assigned to a security context that is associated with a slot that performs the permission procedures, and they have particularly strict rate limits. Other types of "commands" may be assigned to different security contexts and be encrypted and/or signed through a different slot that has less stringent rate limits.

For critical commands, such as remote disconnect and reconnect commands, a higher level of security may be appropriate, such as approval by multiple parties, each of which must be authenticated at the receiving node. However, from the point of view of network efficiency, it is desirable that the node, to which the command is addressed, only needs to be contacted once to execute the command. These goals can be achieved by a permission system that provides all the information necessary for the node to authenticate an order. Essentially, every critical command that is sent to an application, such as a shutdown command to a meter, may require an accompanying permission. As noted above, different types of commands can be assigned to different security contexts. When a command is to be issued, either automatically by an application or through a user interface, the issuing application checks the security context of the command. If encryption is required, the command is forwarded to an appropriate hardware security module slot for such operation. If the security context is determined to require a permission, the command is forwarded to a permission server in the bunker, which issues the permissions. The permission server function can be implemented by a slot in the hardware security module.

Figure 6 illustrates an example of a provision and procedure for granting permits, with reference to an order to disconnect a premises from the electricity distribution network. In this example, one of the business modules of the back office 10, for example, an accounting system, issues an order to the meter management application 52, to disconnect the premises associated with an account. Upon receiving this order, the meter management application can schedule the disconnection operation for a specific time and then sends a message to a load manager module 59 through a secure link, requesting permission to issue the order. The load manager is a business logic component that sits within bunker 42 and determines whether load changes in the distribution network may be detrimental. In this example, the load manager works as an implementation of a permissions server. The upload manager can reject the request if it determines that the requested change may be harmful, defer the request for a period of time, for example, if there are too many pending requests, or approve the request. The request to the load manager may include information such as the target node, the scheduled time of operation, and the size of the time window required to complete the execution of the order.

If the request is approved, the load manager creates a permission that can be recognized by the node to which the order will be directed. Before the permission is returned to the meter management application 52, it is signed with a key associated with the load manager. In the illustrated example, the permission server, that is, load manager 59 is separate from the hardware security module 44. In this case, therefore, the permission is sent to the hardware security module to be signed with the upload manager's private key. The signed permit is returned to the load manager for transmission to the meter management application 52.

Upon receiving the signed permission, the meter management application sends the authorized order to the node 26 that is associated with the installations to be disconnected, together with the signed permission. The node can then verify the permission, for example, by following a chain of certificates from the permission, through the load manager's credentials, to a root authority associated with the system operator for the power distribution network. The node also checks that the time values within the permission are consistent with the current time. If all the information is correct and verified, the node executes the order and sends a signed receipt to the meter management application 52, indicating the fulfillment of the order. A copy of the receipt can be sent to load manager 59, so that it can keep track of pending requests.

The meter management application 52 may also sign the packet payload that is sent to the node, to provide two separate authorizations for the command that are issued by different controlling entities, namely the meter management application and the meter manager. load. Both forms of authorization must be verified by the node before executing the command. In this example, the permission server, for example the load manager, does not have the necessary credentials to communicate directly with the node 26. Rather, it provides credentials to another controlling entity, in this case the meter management application 52 , for the execution of the authorized order.

The business logic for determining whether to approve an order may be relatively simple, for example, a leaky bucket algorithm in which an initial burst of a predetermined number of disconnect operations is allowed, followed by a smaller number of operations per unit of time. weather. In this case, the load manager function could be implemented within a hardware security module slot, using the rate control described above. Another more complex algorithm may be based on the state of the power distribution network, for example, by tracking actual power loads and making projection-based determinations of power needs. This example can be done outside of the hardware security module, as shown in Figure 6, for example within a dedicated physical system, a virtual server, or an application on a shared system.

In addition to remote disconnects and reconnects, other types of commands can be required to have a permission, such as load limiting commands that are directed to a customer's premises to reduce consumption for a specified period of time. In addition, if the secure operation of a particular type of device in the system is critical to system stability, such as a distribution automation component, all commands issued to that device may be required to have a permission. Every time a back office module issues an order to such a device, it forwards the order to the permission server, to obtain the necessary permission.

An exemplary format for a permission contained in a message payload is depicted in Figure 7. The first field 60 of the permission payload indicates a start time, ie, the time when the permission becomes valid. When a node receives a message containing a permission payload, the node compares the start time with its current time. If the start time is later than the current time plus a default increment, for example, five minutes, the node rejects the permission as invalid.

The second field 62 of the permission payload indicates a duration window during which the permission remains valid. This field contains a value indicating the number of predetermined time intervals, for example, five minute blocks, beyond the start time of the permit validity. If the current node time is greater than the permission start time plus the product of the default interval and the window value, the permission is rejected as invalid. For example, if the start time is 1:00:00, the window value is 2, and the current time is 1:12:38, the permission will be rejected as expired.

The next field 64 of the permission payload indicates the operation that is allowed to be performed. For example, this field may contain a value indicating a power off operation, or a power back on operation. Multiple operations can be associated with the same permission. The target type field 66 indicates the format of the target field 68 that follows. The target field 68 designates the node, or device, that is to perform the permitted operation. For example, the target could be the MAC address of the node. The target type field 66 indicates the format in which this address is expressed, eg, a DER octet string.

To further increase security, the restriction that a disconnection or reconnection order can only be issued for one meter at a time can be imposed. Before issuing a permission, the load manager can verify that the target address of the device is associated with a single device and is not a group or broadcast address.

The permission payload may be signed by the private key associated with a certificate with privileges for the indicated operation. Upon receiving the data packet containing the permission payload, the node first checks whether the indicated operation requires a permission. If a permission is required, the node confirms that the certificate and key that were used to sign the permission have the necessary privileges to execute the requested operation. If the confirmation is affirmative, the node verifies the authenticity of the signed permission, since it has been signed by the corresponding private key of the indicated certificate. The node then verifies that the target designation identifies the node itself. Finally, the node examines the start time and window values, relative to its current time, to confirm that the permission has not expired.

If all verification checks are successful, the operation is executed, and a response is returned to confirm successful execution. If any of the verification steps fail, the permission is denied and an error message is returned. As soon as all operations on the data packet have completed, or an error message is returned, the permission is discarded and is no longer held.

In the event that access to the bunker is compromised, an appropriate form of corrective action can be implemented. One of these solutions is to provide a logical or physical panic button that is associated with a bunker. This panic button may be activated (for example, by a person pressing a physical button or activating a user interface element, or by logic automatically making an appropriate determination) to inform the management system that the bunker associated with the panic button is compromised, and should no longer be trusted. For example, any request for remote shutdown services that is signed by a compromised bunker should be ignored.

The panic button can be implemented in a variety of ways. Some suitable examples are control signals that are sent via a wired or wireless communication system, physical push buttons placed in suitable locations, for example, on employee desks, that are connected to a local area network, or wide, and/or portable devices with audio command capability and wireless connectivity.

Figure 8 illustrates an example of a system according to an embodiment of the invention referred to in this European patent, and in which the functionality of a panic button can be implemented. In this example, the utility management and control system is housed in two data centers 70 and 72. For example, each data center may contain a complete instance of the various management and control subsystems, for redundancy. Each data center contains an associated bunker, labeled respectively "bunker1" and "bunker2". Each bunker has a certificate with a chain of certificates rooted at a known authority. The certificates of the two bunkers are different from each other.

Each of the control network nodes, eg, access points 32 and endpoint nodes 26, have the ability to store and install a certificate revocation list. Access points 32 also have the ability to filter source addresses.

An exemplary operation will be described for a situation where access to bunker1 has been compromised. A panic button associated with bunker1 is activated, and the resulting panic signal is sent to a server in bunker2 that implements the panic button function. This panic signal includes a suitable indication of the authentication of the device from which it is sent. For example, it can include a signature associated with the device, or be accompanied by a hash value generated according to a predetermined algorithm. Upon receiving an authenticated panic signal, the server in bunker 2 issues commands to set up a firewall rule for all access points 32, instructing them to drop packets originating from data center 70. The server in bunker 2 bunker2 also issues commands to set up a certificate revocation list on all access points, indicating that the certificate associated with bunker1 is no longer valid. The server in bunker2 also sends a message to each end node, telling it to reload its certificate revocation list from an access point.

By configuring the firewall filter on the access point to drop data center 70 packets, a would-be attacker can be slowed down long enough to allow certificate revocation lists to propagate to all endpoint nodes. . To recover the bunker after a possible breach has occurred, a new certificate must be installed, and new associations with that certificate are made and propagated to all nodes in the control network.

In summary, the present disclosure provides a variety of security features to reduce the risk of malicious or inappropriate actions associated with the delivery of utility-provided commodities. Critical orders that have the potential to disrupt the stability of a utility distribution network are secured through the mechanism of a physical bunker that limits access to sensitive components of the back office management system, along with the use of a hardware security module to authenticate, sign and encrypt said orders. A permission-based authorization framework provides a finer level of security for especially critical orders. The hardware security module can also be configured to limit the execution rate of commands, to further prevent attempts to issue inappropriate scripts.

It will be appreciated by those skilled in the art that the disclosed concepts may be incorporated in other specific forms without departing from the spirit or essential features thereof. The presently disclosed illustrative embodiments and examples are considered in all respects to be illustrative and not restrictive. The scope of the invention to which this European patent refers is indicated in the appended claims, rather than in the previous description.

Claims (15)

1. A method of operating a network having a plurality of endpoints (26) that communicate with a first data center (70) and a second data center (72) through access points (APs), wherein the first data center (70) includes a first physically secure environment having a first certificate, and the second data center (72) includes a second physically secure environment having a second certificate, the method comprising: receiving, from the second physically secure environment, an indication that the security of the first secure environment has been compromised; Y in response to receipt of the indication, issuing, by the second physically secure environment, an order to the access points to configure a certificate revocation list indicating that the certificate associated with the first physically secure environment is not valid; Y issuing, by the second physically secure environment, a command to the endpoint nodes to load the certificate revocation list from any of the access points. 2. The method of claim 1, further comprising: issuing, by the second physically secure environment, a firewall rule to the access points, the firewall rule instructing the access points to discard packets from of the first physically safe environment. 3. The method of claim 1 or claim 2, wherein the indication includes a signature associated with the first data center. 4. The method of claim 1 or claim 2, wherein the indication includes a hash value generated according to a predetermined algorithm. The method of any preceding claim, wherein, in response to receipt of the indication, any request for remote disconnect services that is signed by the first physically secure location is ignored. 6. The method of any preceding claim, wherein the indication comprises a panic signal. 7. The method of any preceding claim, wherein the second data center contains a complete instance of the management and control systems contained in the first data center. 8. The method of any preceding claim, wherein the first certificate is different from the second certificate. 9. A control network having a plurality of endpoints (26) that communicate with a first data center (70) and a second data center (72) via access points (APs), wherein a utility management and control system is located within the first and second data centers, wherein the first data center includes a physically secure first environment having a first certificate, and the second data center includes a second environment physically sure that you have a second certificate; wherein the first physically secure environment is configured, in response to the security of the first physically secure environment being compromised, to send a panic signal to the second physically secure environment; wherein the second physically secure environment is configured to issue a command to access points to configure a certificate revocation list indicating that the certificate associated with the first physically secure environment is invalid; Y wherein the second physically secure environment is configured to issue a command to the endpoint nodes to load the certificate revocation list from any of the access points. 10. The control network of claim 9, wherein the second physically secure environment is further configured to issue a firewall rule to the access points, the firewall rule instructing the access points to drop packets from the first physically safe environment. 11. The control network of claim 9 or claim 10, wherein the panic signal includes a signature associated with the first data center. 12. The control network of claim 9 or claim 10, wherein the indication includes a hash value generated according to a predetermined algorithm. 13. The control network of any of claims 9 to 12, further configured, in response to sending the panic signal, to ignore any request for remote shutdown services that is signed by the first physically secure location. 14. The control network of any of claims 9 to 13, wherein each of the first and second data centers contains a complete instance of the utility management and control system. 15. The control network of any of claims 9 to 14, wherein the first certificate is different from the second certificate.