Patent Application
20150324589
The subject matter disclosed herein relates to electronic device access. Specifically, the embodiments disclosed herein relate to systems and methods for providing controlled access to these devices.
A substation is a subsidiary or branch station of a larger electrical utility station that may generate, transmit, and/or distribute electrical power. A substation may perform functions such as transforming a high voltage to a low voltage or vice versa, transferring power from a transmission system to a distribution system, and collecting power from power plants (e.g. turbine-driven power generation systems, wind farms, etc.) to transfer to a transmission system. As such, a substation may generally include configurable equipment that provides data relating to the processes within the substation. For example, the generation, transmission, and/or distribution may include Intelligent Electronic Devices (IEDs), Distribution Automation Devices, Smart Meters, or other processor-based equipment. Access to configuration and data collection functions of these devices have traditionally been a local process where a user accesses a keypad on these devices and/or accesses the devices via a direct serial connection. Accordingly, securing the physical premises containing these devices has oftentimes been seen as sufficient protection regarding access to these devices.
Over time, as utility system devices have become increasingly sophisticated and intelligent, network communications between these devices and other devices within the utility system has increased. Unfortunately, these new communication functionalities may bring increased exposure, such that solely relying on premises security may be less effective. Further, premises based security does not offer device-specific customization of access.
Certain embodiments commensurate in scope with the originally claimed invention are summarized below. These embodiments are not intended to limit the scope of the claimed invention, but rather these embodiments are intended only to provide a brief summary of possible forms of the invention. Indeed, the invention may encompass a variety of forms that may be similar to or different from the embodiments set forth below.
In a first embodiment, an industrial environment includes an industrial system device. The industrial system device includes a processor to receive a certificate describing a security policy of one or more access constraints for the industrial system device and to implement the security policy on the industrial system device.
In a second embodiment, a method includes: determining one or more job-based access rights for a particular industrial system device; generating a digital certificate comprising a machine-readable definition for the one or more job-based access rights; and signing the digital certificate with a private key corresponding to a public key stored on the particular industrial system device.
In a third embodiment, a tangible, non-transitory, machine-readable medium, includes machine-readable instructions to: receive a certificate signed with a private key; retrieve a public key from an industrial system device; and determine validity of the certificate based at least upon the private key and the public key. If the certificate is invalid, the instructions disregard the certificate. If the certificate is valid, the instructions: determine a security policy defined in the certificate; and implement the security policy on the industrial system device.
These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
One or more specific embodiments of the present invention will be described below. In an effort to provide a concise description of these embodiments, all features of an actual implementation may not be described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.
When introducing elements of various embodiments of the present invention, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements. While the description used herein references use in an electrical grid, electrical generation, transmission, and/or distribution system, no such limitation is intended. Further, while the discussion may refer specifically to Intelligent Electronic Devices (IEDs), the systems and methods described herein are not intended to be limited merely to use in such IEDs.
Present embodiments relate to systems and methods for controlling access to devices in an industrial environment, such as at an electrical substation, at electrical grid facilities, etc. These industrial environments may employ processor-based (“smart”) devices that are configurable or may collect and/or process data (e.g., data from industrial sensor outputs, etc.). Such devices may include, for example, IEDs, which are processor-based devices that may be used to perform tasks and/or monitor certain aspects of an electrical substation (e.g., relays, remote terminal units, etc.); Distribution Automation Devices, such as processor-based switching devices, voltage controllers, and capacitors; Smart Meters (e.g., smart utility meters, such as electric meters, gas meters, water meters, etc.), which are processor-based consumption utility meters; etc. Because of the sensitive nature of the configuration and data retrieval from these devices, it may be desirable to define and provide customizable access policies for these devices. The embodiments below describe systems and methods that provide customizable access policies on these industrial environment devices without the use of an “always-on” centralized access server/service. By removing a reliance on these centralized access servers/services, the reliability of the system may be enhanced. For example, in a system relying on such servers/services, the system could only authenticate/provide access to devices when the servers/services are running properly. Accordingly, increased system redundancy would be warranted, resulting in increased information technology (IT) workload and cost. By using the systems and methods described herein, this workload and cost may be reduced.
Further, the systems and methods described herein describe job-based access policy customization as well as temporal based access policy customization. By increasing the customization functionalities of access policies, and increased number of use cases regarding device access may be covered. Accordingly, security and administration functions may be enhanced.
By way of introduction,
As mentioned above, the system 10 may generally include one or more processor-based devices 12, which may include Distribution Automation Devices 14, Smart Meters 16, IEDs 18 (e.g., relays, bay controller, meters, remote terminal units, digital fault recorders, sequence of events recorders, and communication devices such as routers and switches), and/or any other processor-based device. The smart meters 16 may include a variety of smart utility meters, such as electric meters, gas meters, water meters, or any combination thereof.
The devices 12 may include a processor 20, memory 22, and a communicative link 24 to other systems, components, and/or devices, as shown in
As mentioned above, it may be desirable to provide machine-interpretable access policies (e.g., machine-interpretable access rules stored on a tangible, non-transitory, machine-readable medium) for the one or more devices 12. The access policies may govern access provisions provided to the system 10. For example, it may be desirable to enable access to particular features/data of one or more of the devices 12 based upon a particular job to be performed by an actor in the system 10. In the provided example, actor 30 may be responsible for maintaining the IEDs 18, but not the Distribution Automation Devices 14 or Smart Meters 16. As discussed herein, job-based access to the devices 12 may be provided. Accordingly, actor 30 may be granted access to the IEDs 18, while being restricted from access to the Distribution Automation Devices 14 and/or Smart Meters 16. Because actor 30 is responsible for maintaining the IEDs 18, actor 30 may be provided access to the user-interface 26 and/or modify the configuration settings of the IEDs 18.
In some embodiments, it may be desirable to limit access to the configuration of the devices 12. In the provided example, actor 32 may be responsible for operating, but not modifying, one or more of the devices 12. Accordingly, actor 32's job-based access policy (e.g., access rules interpretable by the devices 12) may enable actor 32 to access the user-interface 26 and/or data of the one or more devices 12, while restricting access (or partially restricting access) to the configuration settings 28 of the devices 12.
Further, in some embodiments, job-based activities may be temporary. In one example, the actor 34 may be tasked with troubleshooting and/or repairing an IED 18. Because this task is temporary (i.e., will be over once resolved), the job-based access for user 34 may be temporal, meaning that the access may be for a limited duration of time. Temporal access for temporary tasks provides added security by reducing permanent access for jobs that do not need it.
The devices 12 may be accessed and/or configured using a number of methods. For example, the devices 12 may be accessed and/or configured using the user-interface 26 on-board the devices 12. Further, a number of management tools 36 may be used to access data and/or configure the devices 12. For example, the management tools 36 may include a computer that executes computer-readable instructions from a computer-readable medium. These instructions may enable the actors (e.g., actors 30, 32, and/or 34) to access data and/or configure the devices 12.
To provide the access policies discussed above, one or more security policies 38 (e.g., a digital certificate detailing access restrictions) may be provided to the devices 12. These security policies may define whether or not an actor (e.g., actors 30, 32, and/or 34) are performing jobs where job-based access has been granted. As will be discussed in more detail below, these security policies 38 may be authenticated at the devices 12 prior to use, such that a centralized and/or “always-on” authentication service is not needed. Accordingly, a reduction of authentication failures may be experienced.
Certificates (e.g., a certificate generated according to the X.509 standard and/or an XML certificate) may be more protective against cyber-attacks than user/password authentication. Turning now to a discussion of the creation and usage of the security policies 38,
Having now discussed creation of the security policy certificate,
The certificate is verified as coming from a legitimate (e.g., authorized) source by utilizing a public key in combination with the private key signature of the certificate (block 74). For example, asymmetric key cryptography may be used to verify the certificate. In one embodiment, the certificate signature and/or payload (e.g., the security policy data) is analyzed/decrypted using the public key embedded with the device 12. Accordingly, a signature verifying algorithm may Odetermine whether the certificate is from a verified source and/or should be trusted/used.
Based upon a determination of whether the certificate is valid (block 76), the certificate is either disregarded (block 78) or used to grant access to the device 12 (block 80). Accordingly, when used to grant access to the device 12, a job-based access policy may be implemented on the device 12 to control access to data and/or editing configuration settings of the device 12.
Once the access control module 104 determines the useful access rights, the certificate authority 106 may generate a certificate 108. The certificate 108 may be signed using a private key 110 associated with a public key 112 of the device 12. The certificate signatures may enable verification that the security policy certificate 108 has come from an authorized certificate authority 106.
In the embodiment of
After receiving the certificate 108, the secondary computer system/computer system storage 114 may transmit the certificate to the device 12 via the communicative interface 118. The secondary computer system/computer system storage 114 may send this upon desiring access to the device 12 and/or prior to desiring access to the device 12. For example, in some embodiments, the secondary computer system/computer system storage 114 may provide the certificate 108 upon receipt from the computer 102. In some embodiments, the secondary computer system/computer system storage 114 may provide the certificate 108 upon desired access (e.g., when access to the device 12 is attempted via the management tools 36).
Upon receiving the privately-signed certificate 108, the device 12 may use a public key 112 stored at the device 12 to verify that the certificate 108 is from a valid source and is to be trusted. Upon determining that the certificate 108 is to be trusted, the device 12 may provide access according to the security policies provided in the certificate 108.
In some embodiments, one or more certificate revocation lists (CRL) 116 may be used to modify the certificate-defined access to temporary access and/or status based access. Generally, CRLs provide a list of certificates that have been revoked and should no longer be trusted. Accordingly, the CRL's may be useful in implementing temporary access (e.g., access for 12 hrs, access from February 1-March 1, access between 10 AM and 12 PM, etc.) and/or status based access (e.g., access. For example, once a threshold of the temporary access and/or status based access is reached, the certificate may be added to the CRL 116 (which may be local to the device 12 and/or may be supplied, or at least have entries supplied by an external entity (e.g., the certificate authority 106). Once on the CRL 116, the certificate may no longer be trusted, causing the removal of access to the system.
Accordingly, access to the device 12 may be customizable based upon a particular job to be completed on the device 12, providing more appropriate device 12 access. Further, the security policy certificate may be provided to the device 12 without relying on an “always-on” server-based system, resulting in fewer points of failure for accessing the device 12.
In some embodiments, it may be desirable to provide the security policy certificate 108 directly from the host of the certificate authority 108 (e.g., computer 102).
In the embodiment of
Once the access control module 104 determines the useful access rights, the certificate authority 106 may generate a certificate 108. The certificate 108 may be signed using a private key 110 associated with a public key 112 of the device 12. The certificate signatures may enable verification that the security policy certificate 108 has come from an authorized certificate authority 106.
In the embodiment of
Upon receiving the privately-signed certificate 108, the device(s) 12 may use a public key 112 stored at the device 12 to verify that the certificate 108 is from a valid source and is to be trusted. Upon determining that the certificate 108 is to be trusted, the device 12 may provide access according to the security policies provided in the certificate 108.
The management tools 36 may attempt to access data and/or edit the configuration settings (e.g., configuration settings 28 of
Accordingly, access to the device 12 may be customizable based upon a particular job to be completed on the device 12, providing more appropriate device 12 access. For example, access may be customized based upon: a maintenance task, a data reading task, a reconfiguration task, etc. Further, the security policy certificate may be provided to the device 12 without relying on an “always-on” server-based system, resulting in fewer points of failure for accessing the device 12.
Technical effects of the disclosed embodiments include industrial environment systems and methods useful to provide device-specific customized access policies. For example, the present embodiments generate access certificates, which may be used to provide temporal access, job-based access, etc. to particular industrial devices. Thus, many individualized access cases can be implemented, resulting in better security of the industrial devices. Further, these customized access policies may be distributed in an automated and decentralized manner that does not rely on “always-on” services and/or servers. Thus, the use of these systems and methods may result in reduced configuration time for access polices and/or reduced expenses, time, and labor for information technology needs of a centralized system. The technical effects and technical problems in the specification are exemplary and not limiting. It should be noted that the embodiments described in the specification may have other technical effects and can solve other technical problems.
This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal language of the claims.
