EP4702406A1

EP4702406A1 - System and method for securing data in a storage device

Info

Publication number: EP4702406A1
Application number: EP24796420.8A
Authority: EP
Inventors: Eran Fine; Nitzan Daube
Original assignee: Nanolock Security Israel Ltd
Current assignee: Nanolock Security Israel Ltd
Priority date: 2023-04-27
Filing date: 2024-04-29
Publication date: 2026-03-04
Also published as: WO2024224378A1

Abstract

A system and method for access control for a programmable logic controller ("PLC") that has been locked with a PLC credential, includes a management device and a user device. The management device has a credentials database and an access policies database. The user device has a programmer application and a user agent application. The user agent is configured to interface with the management device to determine whether a proposed transaction is authorized on a PLC, and then transmit the PLC credential to the user agent, for transmission to the PLC with the proposed transaction, while preventing the user from discovering, modifying or sharing the PLC credential.

Description

System and Method for Securing Data in a Storage Device

TECHNICAL FIELD

[0001] The disclosed implementations relate generally to cybersecurity, and more specifically relate to systems and methods to protect programmable logic controllers from unauthorized modification.

BACKGROUND

[0002] A Programmable Logic Controller (“PLC”) is a ruggedized computer used for industrial automation. These controllers can automate a specific process, machine functions, or even an entire production line. PLCs store code in memory. The code is typically developed on a separate device, e.g. a user device such as a general purpose computer. Code is developed on a programming application running on the user device, and then transferred from the user device to the memory of the PLC.

[0003] Most PLCs on the market have a basic built-in protection mechanism controlled by the programming application to protect the content of the PLC’s memory. However, existing systems for protection pose many challenges. Different PLC vendors and different PLC families from the same vendor may implement or assign different credentials to the PLC to implement the protection. Application or removal of the protection is generally at the discretion of the engineer using the programming application at the time the PLC is programmed. Further, once an engineer has access to a given PLC, that engineer can share the access control with others, and/or use the access credential at any point in the future to access the said PLC from that programming application and/or any programming application. Also, present solutions do not track changes to PLCs, and there is no audit trail as to who did what, when and to which PLC. [0004] Accordingly, there is a need for a system and method where PLC protection credentials are not exposed to the engineer using the programmer application and the use of the protection mechanism is not at engineer discretion.

SUMMARY

[0005] A system for access control for a programmable logic controller (PLC) that has been locked with a PLC credential is disclosed. The system also includes a management device having a management processor and a management memory, the management memory containing a PLC credentials database and an access policies database. The system also includes a user device, having a user processor and a user memory, the user memory containing computer readable instructions configured to instruct the user processor to run a programmer application, the programmer application designed to submit proposed transactions the PLC, and a user agent application, the user agent application designed to communicate with the PLC and the management device. The system also includes where the programmer application is configured to: receive user input relating to a proposed transaction to be executed on the PLC. The system also includes where the user agent application is configured to: receive user input relating to the user’s identity; transmit proposed transaction information, user identity information, and PLC identity information to the management device. The system also includes where the management device is configured to: authenticate the user based on the user identity information; determine whether an entry for the PLC exists in the PLC credentials database, using the PLC identity information; upon a determination that an entry for the PLC exists in the PLC credentials database, query the access policies database, using the user identity information and the PLC identity information, to determine whether the user is authorized to execute the proposed transaction; upon a determination that the user is authorized to execute the proposed transaction; transmit the PLC credential to the user agent application. The system also includes where the user agent application is configured to: receive the PLC credential from the management device while preventing the user from discovering, modifying or sharing the PLC credential; and transmit the PLC credential and information relating to the proposed transaction to the PLC, where the PLC credential is formatted based on a vendor identity and a PLC version. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0006] Implementations may include one or more of the following features. The system where the proposed transaction is a proposed modification of code stored in a memory of the PLC. The management device is further configured to store a record of the proposed transaction in a log stored in the memory of the management device. Querying the access policies database to determine whether the user is authorized to execute the proposed transaction further may include determining whether the user is authorized to execute the proposed transaction at a time at which the user proposes to execute the proposed transaction. The access policies database may include rules relating to a time at which as user is allowed to execute a transaction. Querying the access policies database to determine whether the user is authorized to execute the proposed transaction further may include determining whether the user is authorized to execute the proposed transaction only upon approval by another person. Upon a determination that the user is not authorized to execute the proposed transaction, the management device is configured to reject the transaction. Upon a determination that an entry for the PLC does not exist in the PLC credentials database, the management device is configured to register the PLC, assign a second PLC credential to the PLC, and transmit the second PLC credential to the user agent application, and where the user agent application is configured to update the PLC to be locked from transactions that do not include the second PLC credential. The PLC is configured to reject proposed transactions that do not include the PLC credential. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

[0007] One general aspect includes a method of for access control for a programmable logic controller (PLC) that has been locked with a PLC credential. The method also includes receiving, at a programmer application running on a user device, user input relating to a proposed transaction to be executed on the PLC; receiving, at a user agent application running on the user device, user input relating to the user’s identity; transmitting, from the user agent application to a management device, proposed transaction information, user identity information, and PLC identity information; authenticating, at the management device, the user based on the user identity information; determining whether an entry for the PLC exists in a PLC credentials database at the management device, using the PLC identity information; upon a determination that an entry for the PLC exists in the PLC credentials database, querying an access policies database, at the management device, using the user identity information and the PLC identity information, to determine whether the user is authorized to execute the proposed transaction; upon a determination that the user is authorized to execute the proposed transaction; transmitting the PLC credential from the management device to the user agent application; receiving the PLC credential, at the user agent application, from the management device, while preventing the user from discovering, modifying or sharing the PLC credential; and transmitting the PLC credential and information relating to the proposed transaction to the PLC, where the PLC credential is formatted based on a vendor identity and a PLC version. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods. [0008] Implementations may include one or more of the following features. The method where the proposed transaction is a proposed modification of code stored in a memory of the PLC. The method may include the step of storing a record of the proposed transaction in a log stored in the memory of the management device. Querying the access policies database to determine whether the user is authorized to execute the proposed transaction further may include determining whether the user is authorized to execute the proposed transaction at a time at which the user proposes to execute the proposed transaction. The access policies database may include rules relating to a time at which a user is allowed to execute a transaction. Querying the access policies database to determine whether the user is authorized to execute the proposed transaction further may include determining whether the user is authorized to execute the proposed transaction only upon approval by another person. The method may include, upon a determination that the user is not authorized to execute the proposed transaction, rejecting the transaction. The user agent application is configured to update the PLC to be locked from transactions that do not include the second PLC credential. The PLC is configured to reject proposed transactions that do not include the PLC credential. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] For a better understanding of the various described implementations, reference should be made to the Description of Implementations below, in conjunction with the following drawings in which like reference numerals refer to corresponding parts throughout the figures. [0010] FIG. 1 is a schematic diagram of an assembly of a programmable logic controller, and ancillary devices thereto, in accordance with one aspect of the present disclosure.

[0011] FIG. 2 is a system diagram of a system for protecting PLCs from unauthorized access, in accordance with one aspect of the present disclosure.

[0012] FIG. 3 is a flow diagram of a method of provisioning a PLC in accordance with one aspect of the present disclosure.

[0013] FIG. 4 is a flow diagram of a method of rejecting an unauthorized transaction on a PLC in accordance with one aspect of the present disclosure.

[0014] FIG. 5 is a flow diagram of a method of determining authorization for, and deploying, a transaction on a PLC in accordance with one aspect of the present disclosure.

DESCRIPTION OF IMPLEMENTATIONS

[0015] Reference will now be made in detail to implementations, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the various described implementations. However, it will be apparent to one of ordinary skill in the art that the various described implementations may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the implementations.

[0016] It will also be understood that, although the terms first, second, etc. are, in some instances, used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first electronic device could be termed a second electronic device, and, similarly, a second electronic device could be termed a first electronic device, without departing from the scope of the various described implementations. The first electronic device and the second electronic device are both electronic devices, but they are not necessarily the same electronic device.

[0017] The terminology used in the description of the various described implementations herein is for the purpose of describing particular implementations only and is not intended to be limiting. As used in the description of the various described implementations and the appended claims, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “includes,” “including,” “comprises,” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

[0018] As used herein, the term “if’ is, optionally, construed to mean “when” or “upon” or “in response to determining” or “in response to detecting” or “in accordance with a determination that,” depending on the context. Similarly, the phrase “if it is determined” or “if [a stated condition or event] is detected” is, optionally, construed to mean “upon determining” or “in response to determining” or “upon detecting [the stated condition or event]” or “in response to detecting [the stated condition or event]” or “in accordance with a determination that [a stated condition or event] is detected,” depending on the context. [0019] A PLC is an industrial microprocessor-based controller with programmable memory used to store program instructions and various functions. It consists of a processor unit (CPU) that interprets inputs, executes the control program stored in memory and sends output signals, a power supply, a memory unit storing data from inputs, and program code to be executed by the processor, an input and output interface, and a communications interface to receive and transmit data on communication networks.

[0020] PLCs are made by many different vendors, and each vendor may have more than one model, family, or other classifications of PLCs in their offering. Also, over time, PLC vendors may create new generations of PLCs. Examples of vendors for PLCs include Siemens and Allen-Bradley. One system, e.g. within a larger operational context, may contain multiple PLCs that may vary across manufacturers, vendors, model numbers, families, generations, classifications or the like. Different vendors may require or otherwise use different security protocols, and different formats for security credentials and/or transactions. Similarly, an individual vendor may use different security protocols or messaging formats for different families, generations, or classifications, even amongst PLCs from the same vendor. Prior to the disclosure described herein, no system or method known in the art has been able to manage security credentials across PLCs from different vendors and different families of PLC products.

[0021] Turning now to FIG. 1, a schematic figure of a PLC assembly 100 is shown. Persons having skill in the art will realize that PLC assembly 100 is an exemplar for explanatory purposes, and that PLCs may be configured differently and connected to different ancillary devices, including having other features, and having a different number of any feature shown as compared to PLC assembly 100. PLC assembly 100 includes input module 102, which in turn includes digital input 104 and analog input 106. Digital input 104 and analog input 106 may be used by input module 102 to receive data, signals, or other information, e.g. from other components of the system in which PLC assembly 100 is deployed. PLC assembly 100 also includes output module 108, which includes digital output 110 and analog output 112. Digital output 110 and analog output 112 may be used to deliver data, signals, or other information, e.g. to other components of the system in which PLC assembly 100 is deployed.

[0022] Input module 102 and output module 108 may be operatively coupled to PLC 114 of PLC assembly 100. PLC 114 may include network interface 116, which may be an ethernet card, a wireless networking chip-set, a transceiver, or other networking hardware that may be configured to communicate with other components. PLC 114 may also include a processor 118, which may be a microprocessor, application-specific integrated circuit (ASIC), CPU, or another suitable electronic device to execute program code.

[0023] PLC 114 may also include a memory 120. Although a single memory 120 is shown, PLC 114 may contain multiple kinds of memory 120. A PLC may include volatile memory, or may include non-volatile memory, which may also be referred to as storage. Memory 120 may include read-only memory (“ROM”) random access memory (“RAM”) flash memory, hard disk drives, or the like. Memory 120 may also include more than one chip or physical device supplying memory of the same kind. For example, PLC 114 may contain flash memory devices and RAM devices. Programmed logic code, e.g. source code, object code, machine code, or the like, configured to instruct processor 118 to execute desired instructions, may be stored permanently and/or temporarily, in memory 120. Program code stored in memory 120 may be executed by processor 118 to perform the functions designed for PLC 114.

[0024] User device 122 may be operatively connected to or otherwise associated with

PLC 114, e.g. over network interface 116. User device 122 may run a programmer application 202, which is shown in FIG. 2 and which will be discussed in further detail below. Programmer application 202 may be a software application that is operatively connected to PLC 114 via user device 122. User device 122 may interact with PLC 114, via programmer application 202 to, e.g., update or modify the code stored in memory 120.

[0025] Turning now to FIG. 2, a system 200 in accordance with one embodiment of the present invention is disclosed. System 200 contains PLC 114 and may also contain the other components of PLC assembly 100 as disclosed in FIG. 1. As discussed with reference to FIG. 1, PLCs with different features than those present in PLC 114 may also be used in system 200. System 200 also contains user device 122. As discussed with reference to FIG. 1, user device 122 may be a general purpose computer, such as a desktop or a laptop computer, or another device such as a smartphone, tablet, or any other device capable of running software applications and connecting to a network. User device 122 may contain a microprocessor for executing code, and a memory for storing code. User device 122 may contain, e.g. in its memory, two software applications, programmer application 202 and cyber agent application 204. Programmer application 202, which may also be known as “Engineering Work Station” or “EWS,” may be used, e.g. by engineer 206, to program PLC 114, e.g. by modifying or replacing code that may be present in memory 120 of PLC 114, or adding code to memory 120 of PLC 114. Cyber agent application 204 is an application that runs on user device 122. In some embodiments, cyber agent application 204 is pre-installed on all authorized user devices 122 that also contain a programmer application 202 to program PLC 114.

[0026] Cyber agent application 204 may be configured to interact with management device 208, which may be located on a server operatively coupled to user device 122, e.g. via a local network, or over the internet. Accordingly, management device 208 may be located proximate to user device 122, or may be located remotely and connected via the internet or “the cloud” as it is known in the art. Management device 208 may contain an access policies database 210 and a PLC credentials database 212. Persons skilled in the art will realize that the term “database” is used in a non-limiting way, and is only an example of how access policies and/or PLC credentials may be stored at management device 208.

[0027] Turning now to FIG. 3, a process 300 for detecting and provisioning a PLC 114 and associating it with a programmer application 202 and a cyber agent 204 is shown.

[0028] Programmer application 202, running on user device 122, detects (302) PLCs on the network, e.g. the network local to user device 122. PLCs may be detected via listening along the network, and detection may also involve an application program interface (“API”), e.g. an API specific to the PLC or its manufacturer, brand, model, etc.

[0029] Once a PLC, e.g. PLC 114, is detected, a check is performed (304) to determine whether PLC 114 is provisioned. In some embodiments, a PLC may be considered provisioned when the PLC is known to management device 208, e.g. via an entry in credentials database 212, and configured to work within system 200 of FIG. 2. A provisioned PLC will, in accordance with some embodiments, be locked, and will have been assigned, and be using, credentials that were assigned to the PLC via a user agent 204, running on a user device 122, in conjunction with a management device 208. Credentials associated with a PLC may include a password. Credentials may also include a network identifier or other directory information. In some embodiments of the present disclosure, the credentials are specific to the PLC to which they are associated, and are not associated with a specific user, user name, user account, etc.

[0030] If a detected PLC 114 is provisioned, no further action is taken, and the provisioning process 300 returns to detect further PLCs. [0031] If the detected PLC is not provisioned, credentials may then be registered (306). In a credential registration process in accordance with some embodiments of the present disclosure, user agent 204 transmits a request to management device 208, e.g. over the network or over the internet. Management device 208 creates credentials for the detected PLC, and then sends the credentials to user agent 204. Credentials may in some embodiments be based on a kind or type of PLC that PLC 114 is. Selected PLC 114 may include a relay output, a transistor output or a triac output. Selected PLC 114 may also be of different sizes, e.g. mini, micro, or nano-sized. Selected PLC 114 may also be in a class of PLCs separated by function, and/or separated by what kinds of input and/or output devices to which it may be connected in the larger system in which PLC 114 is deployed.

[0032] User agent 204 then updates (308) the credentials of the detected PLC, which triggers protection of the PLC. Credentials may then be stored in credentials database 212 (as shown in Fig. 2) which may be stored at management device 208.

[0033] User agent 204 then either discards or deletes the credentials, or stores them in a manner such that a user interacting with user agent 204 or programmer application 202 on user device 122, cannot see, read, or otherwise discover the credentials.

[0034] Cyber agent application 204 may actively block the ability of engineer 206 to export, backup, or see the PLC credentials. Because cyber agent application 204 is separate from programmer application 204, it may have its own storage procedures and/or locations at user device 122, and may therefore store PLC credentials separately, in a manner that is not accessible to the user of programming application 202. In some embodiments, user device 122 may not receive credentials for PLC 114 at all. In such embodiments, such credentials may be sent directly from management device 208 to PLC 114 without ever being sent to or stored at user device 122. [0035] After protection of the PLC is triggered (308), the process 300 returns to the detection step (302) to further detect additional PLCs that may be present along the network.

[0036] Turning now to FIG. 4, a process 400 for protecting a PLC such as PLC 114 from unauthorized modifications from unknown programmer applications (402). An unknown programmer application may refer to a programmer application that is not associated with a user agent that otherwise would be, itself, associated with a management device that manages the credentials of the PLC.

[0037] In process 400, an unknown programmer application first initiates (404) a protected transaction attempt on a PLC 114 that has been provisioned in accordance with process 300 of FIG. 3. In accordance with some embodiments, the protected transaction may include a write operation on memory 120 of PLC 114 or a read operation on memory 120 of PLC 114. The protected transaction may include a use command to use PLC 114 to perform a function.

[0038] Upon receipt of the request from the unknown programmer application, PLC 114 may then request (406) credentials from the programmer application. However, as previously noted, unknown programmer application is not associated with a user agent or an administrator device. Accordingly, without a connection to an administrator device, programmer application is unable to retrieve credentials to unlock the PLC, and the transaction therefore fails (408).

[0039] Turning now to FIG. 5, a process 500 for executing commands on a provisioned PLC such as PLC 114 from an authorized programmer applications, is shown.

[0040] In process 500, an authorized programmer application, such as programmer application 202 of FIG. 2, initiates (502) the process of attempting to update a provisioned PLC such as PLC 114. The transaction may include updating the code that runs on PLC 114. [0041] Programmer application 202 detects (504) that the transaction being attempted is protected. For example, a protected transaction may include an attempt to read the memory of PLC 114, an attempt to write to the memory of PLC 114, or an attempt to execute code via the processor of PLC 114. A protected transaction may also include an attempt to override password protection or other security measures enabled on PLC 114.

[0042] User agent 204 then contacts management device 208 to authenticate (506) the user of the programmer application 202. Authentication may include confirming the user’s identity via use of a username and password, or may include sending information to management device 208 confirming that the user has successfully logged into the programmer application. Authentication may also include other login authentication procedures that may be known in the art.

[0043] User agent 204 also contacts the management device 208 to identify (508) the provisioned PLC 114 that is the target of the protected transaction. Persons having ordinary skill in the art will appreciate that these contacts between user agent 204 and management device 208 may occur simultaneously, or in sequence, together or separately, or in any other sequence consistent with the operations being performed.

[0044] Management device 208 then consults access policies database 210 to determine (510) whether the user is authorized to execute the transaction on the identified PLC 114. In accordance with some embodiments, access policies for PLCs, stored in access policies database 210, may include policies specific to each PLC. Access policies may be specific to a type of transaction. For example an access policy may relate only to “write” operations, “read” operations, “execute” operations, or the like. Access policies may be specific to users or groups of users. For example, certain users or categories of users may be authorized to execute write operations on this PLC, while others may be authorized to execute “read” operations but not “write” operations. Access policies may also be specific to time. Certain users may be authorized to execute operations on PLC 114 only at certain times of day, certain days of the week, etc. Access policies may also limit who may override the protection of the PLC itself, which is typically limited to administrators. Access policies may also designate certain transactions, potentially only certain kinds of transactions or transactions at certain times, that can be performed only upon authentication or authorization by another user such as an administrator.

[0045] If management device 208, having received the identity of the user, the time of the transaction, the identity of the PLC, and/or the nature of the transaction, determines (512) that the user is not authorized to execute the transaction on the target PLC at the time of the request, the transaction is deemed invalid (514). Information relating to the attempted transaction is then added (516) to a transaction log, which may in some embodiments be stored at management device 208.

[0046] If management device 208 determines (518) that the user is authorized to execute the transaction on the PLC at the time of the request, management device 208 may then transmit credentials for the PLC to user agent 204. User agent 204 then adds (520) the credentials to the transaction, which it receives from programmer application 202. Adding the credentials to the transaction may be implemented by adding the transaction and the credentials to a data structure in accordance with a protocol established for the particular brand and/or model of PLC that was targeted. User agent 204 may be configured to format the data structure in accordance with known protocols associated with the particular PLC that is being configured, and may in some embodiments format the transaction, the credential, or both, to match the identity of the PLC. [0047] In the process of user agent 204 receiving the credentials from management device 208 and adding them to the transaction created by programmer application 202, the user of the programmer application 202 has no direct access to the credentials and is unable to see, read, or discover, modify, or share them. This protects PLC 114 from direct access, even by users who are authorized to have certain levels of access to PLC 114. Credentials can be changed by administrators, e.g. administrators of management device 208, without knowledge by any user of any instance of programmer application 202, because the credentials are associated with PLC 114 and are independent of the identity of the user or the user’ s account.

[0048] The transaction and the credentials are then sent from user agent 204 to PLC 114. A record of the transaction is then added (516) to the transaction log. After additions to the log are made, whether they reflect valid or invalid transactions, the process returns to the step of detecting (504) transactions.

[0049] When the disclosed system of securing PLCS is used, PLCs are protected from unauthorized access by unauthorized programmer applications. PLC protection credentials are never exposed to the engineer 206. Credentials may be assigned automatically, and protection may be installed automatically. In some embodiments, access policies, e.g. in access policies database 210, may be modified at any time. In some embodiments, access policies may support a time domain. A programmer, such as engineer 206, that has access to a PLC at one time may not necessarily have access to the same PLC at another time, after a change in an access policy. Additionally, in some embodiments, modifications to protected PLCs may be registered on the server, which may serve as an audit trail for easier versioning of code on a PLC, and for determining which user made a specific change. Furthermore, using a server such as management device 208, as opposed to logging into the PLC directly, may also permit more complex security measures to be used, such as multi factor authentication.

[0050] The foregoing description, for purpose of explanation, has been described with reference to specific implementations. However, the illustrative discussions above are not intended to be exhaustive or to limit the scope of the claims to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The implementations are chosen in order to best explain the principles underlying the claims and their practical applications, to thereby enable others skilled in the art to best use the implementations with various modifications as are suited to the particular uses contemplated.

Claims

CLAIMS What is claimed is:

1. A system for access control for a programmable logic controller (“PLC”) that has been locked with a PLC credential, the system comprising: a management device having a management processor and a management memory, the management memory containing a PLC credentials database and an access policies database; and a user device, having a user processor and a user memory, the user memory containing computer readable instructions configured to instruct the user processor to run a programmer application, the programmer application designed to submit proposed transactions the PLC, and a user agent application, the user agent application designed to communicate with the PLC and the management device; wherein the programmer application is configured to: receive user input relating to a proposed transaction to be executed on the PLC; wherein the user agent application is configured to: receive user input relating to the user’s identity; transmit proposed transaction information, user identity information, and PLC identity information to the management device; wherein the management device is configured to: authenticate the user based on the user identity information; determine whether an entry for the PLC exists in the PLC credentials database, using the PLC identity information; upon a determination that an entry for the PLC exists in the PLC credentials database, query the access policies database, using the user identity information and the PLC identity information, to determine whether the user is authorized to execute the proposed transaction; upon a determination that the user is authorized to execute the proposed transaction; transmit the PLC credential to the user agent application; wherein the user agent application is configured to: receive the PLC credential from the management device while preventing the user from discovering, modifying or sharing the PLC credential; and transmit the PLC credential and information relating to the proposed transaction to the PLC, wherein the PLC credential is formatted based on a vendor identity and a PLC version.

2. The system of claim 1, wherein the proposed transaction effects a change to the operation of the PLC.

3. The system of claim 1, wherein the management device is further configured to store a record of the proposed transaction in a log stored in the memory of the management device.

4. The system of claim 1, wherein querying the access policies database to determine whether the user is authorized to execute the proposed transaction further comprises determining whether the user is authorized to execute the proposed transaction at a time at which the user proposes to execute the proposed transaction.

5. The system of claim 4, wherein the access policies database comprises rules relating to a time at which a user is allowed to execute a transaction.

6. The system of claim 1, wherein querying the access policies database to determine whether the user is authorized to execute the proposed transaction further comprises determining whether the user is authorized to execute the proposed transaction only upon approval by another person.

7. The system of claim 1, wherein, upon a determination that the user is not authorized to execute the proposed transaction, the management device is configured to reject the transaction.

8. The system of claim 1, wherein, upon a determination that an entry for the PLC does not exist in the PLC credentials database, the management device is configured to register the PLC, assign a second PLC credential to the PLC, and transmit the second PLC credential to the user agent application, and wherein the user agent application is configured to update the PLC to be locked from transactions that do not include the second PLC credential.

9. The system of claim 1, wherein the PLC is configured to reject proposed transactions that do not include the PLC credential.

10. A method of for access control for a programmable logic controller (“PLC”) that has been locked with a PLC credential, comprising the steps of: receiving, at a programmer application running on a user device, user input relating to a proposed transaction to be executed on the PLC; receiving, at a user agent application running on the user device, user input relating to the user’s identity; transmitting, from the user agent application to a management device, proposed transaction information, user identity information, and PLC identity information; authenticating, at the management device, the user based on the user identity information; determining whether an entry for the PLC exists in a PLC credentials database at the management device, using the PLC identity information; upon a determination that an entry for the PLC exists in the PLC credentials database, querying an access policies database, at the management device, using the user identity information and the PLC identity information, to determine whether the user is authorized to execute the proposed transaction; upon a determination that the user is authorized to execute the proposed transaction; transmitting the PLC credential from the management device to the user agent application; receiving the PLC credential, at the user agent application, from the management device, while preventing the user from discovering, modifying or sharing the PLC credential; and transmitting the PLC credential and information relating to the proposed transaction to the PLC, wherein the PLC credential is formatted based on a vendor identity and a PLC version.

11. The method of claim 10, wherein the proposed transaction effects a change to the operation of the PLC.

12. The method of claim 10, further comprising the step of storing a record of the proposed transaction in a log stored in the memory of the management device.

13. The method of claim 10, wherein querying the access policies database to determine whether the user is authorized to execute the proposed transaction further comprises determining whether the user is authorized to execute the proposed transaction at a time at which the user proposes to execute the proposed transaction.

14. The method of claim 13, wherein the access policies database comprises rules relating to a time at which a user is allowed to execute a transaction.

15. The method of claim 10, wherein querying the access policies database to determine whether the user is authorized to execute the proposed transaction further comprises determining whether the user is authorized to execute the proposed transaction only upon approval by another person.

16. The method of claim 10, further comprising, upon a determination that the user is not authorized to execute the proposed transaction, rejecting the transaction.

17. The method of claim 10, further comprising, upon a determination that an entry for the PLC does not exist in the PLC credentials database, registering the PLC in the PLC credentials database; assigning a second PLC credential to the PLC; and transmitting the second PLC credential to the user agent application, and wherein the user agent application is configured to update the PLC to be locked from transactions that do not include the second PLC credential.

18. The method of claim 10, wherein the PLC is configured to reject proposed transactions that do not include the PLC credential.