US8959362B2 - Systems and methods for controlling file execution for industrial control systems - Google Patents

Systems and methods for controlling file execution for industrial control systems Download PDF

Info

Publication number
US8959362B2
US8959362B2 US13/460,771 US201213460771A US8959362B2 US 8959362 B2 US8959362 B2 US 8959362B2 US 201213460771 A US201213460771 A US 201213460771A US 8959362 B2 US8959362 B2 US 8959362B2
Authority
US
United States
Prior art keywords
file
whitelist
hardware controller
hash key
input
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
US13/460,771
Other versions
US20130290729A1 (en
Inventor
William Robert Pettigrew
Justin Brandon Chong
Manas Ranjan Sahoo
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GE Infrastructure Technology LLC
Original Assignee
General Electric Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by General Electric Co filed Critical General Electric Co
Priority to US13/460,771 priority Critical patent/US8959362B2/en
Assigned to GENERAL ELECTRIC COMPANY reassignment GENERAL ELECTRIC COMPANY ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: Sahoo, Manas Ranjan, CHONG, JUSTIN BRANDON, Pettigrew, William Robert
Priority to EP13166007.8A priority patent/EP2660668B1/en
Priority to ES13166007T priority patent/ES2868141T3/en
Priority to CN201310157177.8A priority patent/CN103377328B/en
Publication of US20130290729A1 publication Critical patent/US20130290729A1/en
Publication of US8959362B2 publication Critical patent/US8959362B2/en
Application granted granted Critical
Assigned to BAKER HUGHES, A GE COMPANY, LLC reassignment BAKER HUGHES, A GE COMPANY, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GENERAL ELECTRIC COMPANY
Assigned to BAKER HUGHES, A GE COMPANY, LLC reassignment BAKER HUGHES, A GE COMPANY, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GENERAL ELECTRIC COMPANY
Assigned to BAKER HUGHES HOLDINGS LLC reassignment BAKER HUGHES HOLDINGS LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: BAKER HUGHES, A GE COMPANY, LLC
Assigned to GE INFRASTRUCTURE TECHNOLOGY LLC reassignment GE INFRASTRUCTURE TECHNOLOGY LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BAKER HUGHES HOLDINGS LLC
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/04Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/048Monitoring; Safety
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/24Pc safety
    • G05B2219/24161Use of key, in key is stored access level
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04SSYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y04S40/20Information technology specific aspects, e.g. CAD, simulation, modelling, system security

Definitions

  • the subject matter disclosed herein relates to industrial control systems and, more particularly, to securing the operation of industrial control systems.
  • Industrial control systems such automated power generation systems (e.g., wind, water, and gas turbine systems) and automated manufacturing systems (e.g., petroleum refineries, chemical manufacturing plants, and the like) are a common feature of modern industry.
  • an industrial controller may generally control the operation of the system.
  • certain devices in the industrial control system e.g., sensors, pumps, valves, actuators, and the like
  • the industrial controller may execute instructions (e.g., firmware and/or applications) that may generally enable the industrial controller to control the operation of the industrial control system (e.g., a gas turbine system).
  • a system in one embodiment, includes a controller configured to control a process, and store at least one binary file, wherein the at least one binary files is generated from at least one source file, wherein the at least one source file comprises instructions configured to be executed by a processor in the controller.
  • the controller may also be configured to retrieve a whitelist file comprising a first hash key value derived from the at least one binary file, and execute an executable file based on the whitelist file, wherein the executable file comprises the source file.
  • a method includes determining an input binary by using an executable file, wherein the executable file is configured to be executed by a controller, calculating an input hash key value from the input binary, determining if the input hash key value is included in a whitelist, wherein the whitelist comprises a plurality of hash key values calculated from a plurality of authenticated binary files, and allowing the executable file to execute if the input hash key matches one of the plurality of hash key values in the whitelist.
  • a tangible, non-transitory, computer-readable medium includes instructions configured to be executed by a processor of an industrial controller.
  • the instructions are configured to determine an input hash key value for an input binary file, and block execution of the input binary file if the input hash key value is not found in a whitelist, the whitelist comprising a plurality of hash key values.
  • FIG. 1 is a schematic diagram of an embodiment of an industrial control system and a build system, in accordance with aspects of the present disclosure
  • FIG. 2 is a flow diagram for an embodiment of a process by which the build system builds the executable files and whitelist for later use by the industrial controller, in accordance with aspects of the present disclosure
  • FIG. 3 is a flow diagram for an embodiment of a process by which the industrial controller receives and decrypts the whitelist, in accordance with aspects of the present disclosure
  • FIG. 4 is a flow diagram for an embodiment of a process by which the industrial controller uses the decrypted whitelist to verify an executable file prior to execution, in accordance with aspects of the present disclosure.
  • FIG. 5 is a detailed flow diagram for an embodiment of a process by which the industrial controller verifies an executable file prior to execution, in accordance with aspects of the present disclosure.
  • 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.
  • the terms “executable file” and “binary file” may both generally refer to a computer-readable file that that includes instructions (e.g., binary instructions) that may be performed by a processor (e.g., the processor of an industrial controller).
  • the term “software developer” may generally refer to an organization which develops, maintains, and/or provides instructions in the form of source code and/or executable files to control the operation of industrial controllers.
  • the term “whitelist” may refer to a file which includes a list identifying executable files that are authorized to run on an industrial controller.
  • the term “authorized” may be used herein to refer to an executable file that is verified to be from a trustworthy source (i.e., the software developer) and whose contents are verified as being the same as when it was provided by the trustworthy source.
  • an industrial controller may generally execute instructions (e.g., base code, firmware, and/or applications stored in the form of one or more executable files) that may enable the industrial controller to control the operation of an industrial control system.
  • These instructions may be initially loaded onto the industrial controller (e.g., into a memory or data storage component of the industrial controller) by the manufacturer before it is supplied to a customer.
  • These instructions e.g., base code, firmware, and/or applications
  • the industrial controller may execute these updated instructions to control the operation of the industrial control system.
  • each executable file storing instructions for the industrial controller may be desirable prior to execution. That is, it may be desirable to ensure that, prior to execution, each executable or binary file storing instructions for the industrial controller is verified as being provided from a trustworthy or reputable source (e.g., the software developer). Furthermore, it may be desirable to verify that each executable or binary file has not been altered since it was prepared by this trustworthy source (e.g., in transit between the hardware manufacturer and the customer). Moreover, it may be desirable to be able to perform this verification of executable files quickly and using limited resources (e.g., memory space and processor time), so as not to otherwise disrupt the operations of the industrial controller.
  • a trustworthy or reputable source e.g., the software developer
  • each executable or binary file has not been altered since it was prepared by this trustworthy source (e.g., in transit between the hardware manufacturer and the customer).
  • limited resources e.g., memory space and processor time
  • the presently disclosed systems and methods enable the verification of both the identity and the contents of each of the executable files before they are executed by the industrial controller in an efficient manner using a whitelisting system. That is, as discussed in detail below, presently disclosed embodiments utilize a secure whitelist file that may be provided by the software developer along with each release of executable files (e.g., each software installation or update release). This whitelist file generally includes a number of values, and each of these values may be associated with an authorized executable file. By verifying that each executable has an associated entry in the whitelist prior to execution, the presently disclosed embodiments provide the industrial controller with improved security to block or prevent the execution of undesired and/or malicious instructions (i.e., instructions from a non-trustworthy source).
  • undesired and/or malicious instructions i.e., instructions from a non-trustworthy source.
  • the presently disclosed whitelist file includes a collection of hash key values for the authorized executable files in a particular software release. That is, after each executable file is built, the executable file may be provided as input to a hash function and the hash key value output associated with that executable file may be stored in the whitelist file.
  • the hash function may include a Cyclic Redundancy Check (CRC), a Message Digest (MD) algorithm, a Secure Hash Algorithm (SHA), or a combination thereof.
  • CRC Cyclic Redundancy Check
  • MD Message Digest
  • SHA Secure Hash Algorithm
  • the whitelist file may be securely provided to the industrial controller (e.g., encrypted prior to packaging and/or transport and decryption by the industrial controller).
  • the industrial controller prior to executing a particular executable file may also provide the particular executable file to the same hash function (e.g., cyclic redundancy check [CRC], MD5, SHA-1, or other hash function) and may search the whitelist file to determine if the hash key value output from the hash function is listed in the whitelist file. If the hash key value is located in the whitelist file, the industrial controller may conclude that the particular executable file is authorized (e.g., from a trustworthy source and unaltered since it was built) and proceed with executing the file. If, however, the hash key value is not located in the whitelist file, the industrial controller may block the execution of the particular executable file.
  • the same hash function e.g., cyclic redundancy check [CRC], MD5, SHA-1, or other hash function
  • FIG. 1 is a schematic diagram illustrating an industrial control system 10 .
  • the illustrated industrial control system 10 includes an industrial controller 12 that may be coupled to a network 14 to control the operation of a number of field devices 16 , 18 and 20 .
  • the illustrated industrial controller 12 receives sensory data from a number of field devices 16 , 18 , and 20 (e.g., temperature sensors, pressure sensors, voltage sensors, control valves, actuators, or similar field devices for an industrial control system) via the network 14 to monitor and control the operation of a gas turbine system 22 .
  • a number of field devices 16 , 18 , and 20 e.g., temperature sensors, pressure sensors, voltage sensors, control valves, actuators, or similar field devices for an industrial control system
  • a gasification system may include a gasifier configured to gasify a carbonaceous feedstock to generate a synthetic gas, a gas treatment unit is configured to process the synthetic gas to remove undesirable elements (e.g., acid gases), a combustor configured to combust the synthetic gas to drive a turbine, and a generator coupled to the turbine configured to produce electrical power.
  • the industrial controller 12 may monitor and control the various components of the gasification system (e.g., the gasifier, gas treatment unit, combustor, and turbine) using the field devices 16 , 18 , and 20 .
  • the field devices 16 , 18 , and 20 are be communicatively coupled to the industrial controller 12 (e.g., via the network 14 ) while monitoring and controlling various aspects and parameters of the operation of the gas turbine system 22 (e.g., monitoring the temperature in a combustor of the gas turbine system, controlling the voltage output of an electrical generator coupled to a shaft of the gas turbine system, regulating a flow of a fuel into the combustor, controlling a valve to regulate a gas flow to a gas processor, controlling a steam input of a heat recovery steam generator (HRSG), and the like).
  • HRSG heat recovery steam generator
  • the illustrated industrial control system 10 represent a simplified industrial control system, and that other industrial control systems may include any suitable number of industrial controllers 12 , networks 14 , networking devices, field devices, etc., to monitor and control various portions of any automated system 22 .
  • the industrial control system may include a triple modular redundant (TMR) controller configured to provide redundant operations.
  • TMR triple modular redundant
  • the industrial control system may also include redundant controllers having a plurality of controllers (e.g., 2 , 3 , 4 , 5 etc., controllers).
  • industrial controller 12 may use the network 14 for communicating with and controlling any one of the field devices 16 , 18 , or 20 .
  • the industrial controller 12 may reside in an industrial plant and may be configured to adjust one or more process conditions related to the devices 16 , 18 , 20 .
  • the network 14 may be any electronic and/or wireless network suitable for enabling communications, and may include fiber media, twisted pair cable media, wireless communications hardware, Ethernet cable media (e.g., Cat-5, Cat-7), and the like. Further, the network 14 may include several sub-buses, such as a high speed Ethernet sub-bus suitable for connecting components of the industrial control system 10 at communication speeds of 100 MB/sec and upwards.
  • the network 14 may include an input/output (I/O) network, such as an I/O network conforming to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 standard.
  • the network 14 may also include an H1 network sub-bus suitable for connecting components of the industrial control system 10 at communications speeds of approximately 31.25 Kb/sec.
  • the sub-buses may intercommunicate with each other, for example, by using linking devices or gateways, such as those gateways available under the designation FG-100 provided by softing AG, of Haar, Germany, and/or I/O packs available from General Electric Co. of Schenectady, N.Y. Indeed, a number of interconnected sub-buses of the network 14 may be used to communicate amongst the components of the industrial control system 10 .
  • the industrial controller 12 includes memory 34 and processor 36 that may execute instructions (e.g., binary instructions in executable files) to generally control the operation of the industrial control system 10 .
  • the memory 34 of the industrial controller 12 may include one or more files including binary instructions that may be performed by the processor 36 in order to control and monitor the field devices 16 , 18 , and 20 disposed within portions of the gas turbine system 22 .
  • These executable files may, for example, be initially installed in the memory 34 of the industrial controller 12 by the manufacturer of the industrial controller 12 before the industrial controller 12 is installed in the industrial control network 10 .
  • the executable files stored in the memory 34 of the industrial controller 12 may occasionally be updated, for example, to augment the features of previous software versions as well as improve performance.
  • the device 24 Also communicatively coupled to the industrial controller 12 (e.g., via the network 14 or another suitable network) is the device 24 , having a memory 25 and a processor 26 , which may host a human machine interface (HMI) system 27 , a manufacturing execution system (MES) 28 , a supervisor control and data acquisition (SCADA) system 29 , a distributed control system (DCS) 30 , or similar interface systems.
  • HMI human machine interface
  • MES manufacturing execution system
  • SCADA supervisor control and data acquisition
  • DCS distributed control system
  • the device 24 may host a configuration application or tool, such as ToolboxST 32 , available from General Electric Co., of Schenectady, N.Y.
  • the aforementioned systems may provide one or more interfaces by which a user may monitor and control the operation of the industrial controller 12 .
  • the HMI 27 and/or the ToolboxST 32 may provide a user interface through which various parameters of the industrial control system 10 (e.g., stored in the memory 34 of the industrial controller 12 ) may be forced or set.
  • the HMI 27 and/or the ToolboxST 32 may include an interface through which the various executable files stored in the memory 34 of the controller 12 may be updated to newer versions.
  • the aforementioned systems may be hosted on a single device 24 , while, in other embodiments, they may each be installed on one or more devices in the industrial control network.
  • the memory 34 of the industrial controller 12 generally stores a number of executable files (e.g., binary files) to be executed by the processor 36 .
  • the executable files stored in the memory 34 of the industrial controller 12 may occasionally be updated.
  • a software developer may produce and/or provide software updates for the executable files used by the industrial controller 12 .
  • the software developer may have a build system 38 (e.g., a computer, laptop, or similar computing device), having a memory 40 and a processor 42 , that may be used to build the executable files for later execution by the industrial controller 12 (e.g., once loaded into the memory 34 of the industrial controller 12 ), such as at the time of manufacturing or during a software update, as discussed below.
  • the memory 40 of the build system 38 may include a number of source files that may contain instructions in the form of human-readable code in a computer programming language.
  • the software developer may use the processor 42 to compile these source files, translating them into computer-readable (e.g., binary) instructions in the form of executable files for later execution by the processor 36 of the industrial controller 12 .
  • the executable files once the executable files have been created, they may be packaged together (e.g., placed in an archive, compressed, encrypted, and the like). Then, the software developer may provide the updated executable files to the industrial controller 12 , as represented by the dashed line 44 of FIG. 1 .
  • the software developer may place the updated executable files on a physical medium (e.g., an optical disc, a magnetic medium, a flash drive, or other similar data storage medium) that may be provided to (e.g., mailed to) a user of device 24 .
  • a physical medium e.g., an optical disc, a magnetic medium, a flash drive, or other similar data storage medium
  • This user may, in turn, utilize the HMI 27 and/or ToolboxST 32 to transfer the contents of the physical medium to the memory 34 of the industrial controller 12 .
  • the device 24 may, for example, be capable of establishing a network connection to build system 38 in order to download the executable files from the memory 40 of the remote build system 38 of the software developer.
  • the industrial controller 12 may generally be desirable to ensure that the industrial controller 12 only executes authorized executable files. That is, regardless of how the executable files are provided by the software developer (e.g., via physical medium or network connection), it would be beneficial to verify that the executable file has been in no way modified since it was compiled by the software developer (e.g., the processor 42 of the build system 38 of the software developer).
  • the presently disclosed embodiments utilize a whitelist file that is provided by the software developer along with the executable files as a way of verifying that all of the executable files are authorized prior to execution.
  • the whitelist file contains hash key values for each of the executable files such that the industrial controller 12 may efficiently and simultaneously verify the identity and contents of each executable file prior to execution.
  • FIG. 2 illustrates a flow diagram of a process 50 by which a device (e.g., the processor 42 of the build system 38 ) may prepare a software package including executable files and a whitelist identifying authorized executable files for the industrial controller 12 .
  • the illustrated process 50 begins with the build system 38 receiving (block 52 ) a plurality of source files that include instructions to be later executed by the processor 36 of the industrial controller 12 .
  • the processor 42 of the build system 38 may generate (block 54 ) a private encryption key.
  • the processor 42 may utilize one or more algorithms to produce random or pseudo-random characters or values for this private encryption key.
  • the build system 38 may include one or more random number generating devices that may be used to generate random or pseudo-random characters or values for the private encryption key.
  • the processor 42 may add (block 56 ) this private encryption key to at least one of the plurality of source files.
  • a source file associated with a startup executable file e.g., an executable file that may usually run first when the industrial controller 12 is started
  • the processor 42 may edit the source file such that the value of the variable is defined to be the private encryption key.
  • the industrial controller 12 may have the variable set to the private encryption key (e.g., in order to later decrypt the whitelist file).
  • the processor 42 of the build system 38 may generate a plurality of executable files from the plurality of source files. That is, the processor 42 may compile the source files in memory 40 of the build system 38 in order to output a number of executable files, which may also be stored in memory 40 of the build system. The processor 42 may then determine a hash key value for each of the plurality of executable files. That is, the processor 42 may apply a hash function to each of the executable files in order to determine a hash key value.
  • a non-limiting list of example hash functions include: Cyclic Redundancy Check (CRC) 32, CRC 64, Message-Digest Algorithm (MD) 5, MD 6, Secure Hash Algorithm (SHA) 1, SHA 2, SHA 256, or SHA 512.
  • CRC Cyclic Redundancy Check
  • MD Message-Digest Algorithm
  • MD 6 Message-Digest Algorithm
  • SHA Secure Hash Algorithm
  • SHA Secure Hash Algorithm
  • SHA Secure Hash Algorithm
  • the processor 42 may construct (block 62 ) a whitelist file including each of the hash key values determined for the plurality of executable files. For example, the processor 42 may create a new file and populate the file with a delimited list of the determined hash key values for the executable files previously compiled by the processor 42 .
  • the whitelist file may be constructed as an Extensible Markup Language (XML) file.
  • the processor 42 may use an Advanced Encryption Standard (AES) algorithm, a Data Encryption Standard (DES) algorithm, Pretty good privacy (PGP) algorithm, or other suitable data encryption algorithm. Then, in certain embodiments, the processor 42 may package (block 66 ) the executable files together with the encrypted whitelist file. That is, the processor 42 may combine the executable file and the encrypted whitelist file into a single archive or compressed file for distribution to the industrial controller 12 . In other embodiments, the build system 38 may make the whitelist file available to the industrial controller 12 and/or device 24 for eventual use by the processor 36 of the industrial controller 12 .
  • AES Advanced Encryption Standard
  • DES Data Encryption Standard
  • PGP Pretty good privacy
  • the processor 42 may package (block 66 ) the executable files together with the encrypted whitelist file. That is, the processor 42 may combine the executable file and the encrypted whitelist file into a single archive or compressed file for distribution to the industrial controller 12 .
  • the build system 38 may make the whitelist file available to
  • FIG. 3 illustrates a flow diagram for an embodiment of a process 70 by which a processor 36 of the industrial controller 12 receives and decrypts the whitelist file.
  • the process 70 may begin with the processor 36 of the industrial controller 12 receiving and unpackaging (block 72 ) the plurality of executable files and the encrypted whitelist file.
  • the HMI 27 and/or ToolboxST application 32 of the device 24 may assist the industrial controller 12 in receiving and/or unpackaging the plurality of executable files from the software developer (e.g., from build system 38 via physical medium or a network connection).
  • the process 70 continues with the processor 36 of the industrial controller 12 executing (block 74 ) a startup executable file which may include the private encryption key, as discussed in blocks 64 and 54 of FIG. 2 .
  • the processor 36 of the industrial controller 12 may decrypt (block 76 ) the encrypted whitelist file using the private encryption key in order to provide a decrypted whitelist file (e.g., in the memory 34 of the industrial controller 12 ). It should be appreciated that, while the actions described in block 72 may generally only be performed during an update of the industrial controller 12 , in certain embodiments, the actions described in blocks 74 and 76 may also be performed, for example, during reboots of the industrial controller 12 .
  • FIG. 4 illustrates a flow diagram for an embodiment of a process 80 by which a processor 36 of the industrial controller 12 may use the whitelist to verify that an executable file is authorized prior to execution.
  • the process 80 begins with the processor 36 determining (block 82 ) that a particular executable file is attempting execution.
  • the processor 36 may then determine (block 84 ) a hash key value for the executable file that is attempting execution. It should be appreciated that the processor 36 will apply the same hash function as was used to determine the hash key values during the construction of the whitelist file (e.g., discussed in block 60 of FIG. 2 ).
  • the process 80 continues with the processor 36 determining (block 86 ) if the hash key value is included within the decrypted whitelist file (e.g., the decrypted whitelist file discussed with respect to block 76 of FIG. 3 ).
  • the decrypted whitelist file discussed in block 76 of FIG. 3 may be loaded into the memory 34 of the industrial controller 12 as a particular data structure, such as a hash table, which may enable fast and/or efficient searching when determining if a particular hash key value is present in the whitelist.
  • the processor 36 may allow (block 88 ) the executable file to execute when or if the hash key determined for the executable file is located in the decrypted whitelist file.
  • the process 80 may also terminate with the processor 36 blocking (block 90 ) the execution of the executable file if the hash key value for the executable file is not located in the decrypted whitelist file.
  • the processor 36 may further log (e.g., the blocked execution of the executable file as a potential security concern).
  • FIG. 5 illustrates a detailed flow diagram of an embodiment of a process 94 by which an executable file 95 is verified prior to execution.
  • the process 94 may be implemented by using a non-transitory machine readable medium including code executable by the controller 12 .
  • the process 94 may begin when the processor 36 receives (block 96 ) the executable file 95 , such as an input executable (e.g., binary) file.
  • the executable file 95 may include executable code attempting to execute in the processor 36 .
  • the processor 36 may then determine (block 98 ) a binary from the executable file that is attempting to execute such that the executable file is expressed as a binary file.
  • multiple executable files may be used, and the process 94 may determine which executable binary is attempting to execute (block 98 ) so that it may be checked against a whitelist file, as described in more detail below.
  • the processor 36 may then use the determined binary to decide (decision 100 ) whether or not the binary exists in the whitelist.
  • the processor 36 may access a whitelist file 102 listing executable system binary files that may be approved for execution by the processor 36 in order to determine whether the determined binary exists.
  • the system binary files are generally executable or binary files such as operating system files that exist in the operating system. If the determined binary does not exist in the whitelist file 102 , then the processor 36 may return (block 104 ) an error.
  • the error may result in an alert or notification that is outputted to the user through the HMI 27 or other output. Additionally, the executable file 95 may be blocked from executing. If the determined binary does exist in the whitelist file 102 , then the processor 36 may determine (block 106 ) an input hash key value of the determined binary. It should be appreciated that the processor 36 may generally apply the same hash function as was used to determine the hash key values during the construction of the whitelist file 102 (e.g., discussed in block 60 of FIG. 2 ). In some embodiments, this involves passing the binary files through a secure hash algorithm to generate a 160-bit hash string.
  • the processor 36 decides (decision 108 ) whether the input hash key value matches the hash key value from the whitelist file 102 .
  • the input hash key value of the determined binary file is compared to the hash key value of the corresponding binary file in the whitelist file 102 . If the input hash key value matches the value from the whitelist file 102 , the executable file may be allowed to execute. If the input hash key value does not match the value from the whitelist file 102 , the processor 36 may return (block 104 ) an error. The error may be an alert or notification outputted to the user. Further, the executable file 95 may also be blocked from executing. In certain embodiments, when an error is returned (block 104 ), the event and/or the executable file may be stored for future analysis or security reporting.
  • the technical effects of this disclosure include improving the security of an industrial controller of an industrial control system. That is, presently disclosed embodiments enable a processor 36 of the industrial controller 12 to verify that each executable file is authorized prior to execution. In particular, by using hash key values for the verification process of the executable files, the presently disclosed embodiments provide a light-weight system, enabling the processor 36 of the industrial controller 12 to perform this verification process with minimal impact on resources (e.g., memory space and/or processing time). Furthermore, through the use of hash key values, presently disclosed embodiments provide verification of both the content and the identity of the executable files, such that even a single bit change (e.g., due to a transmission error, file corruption, or file tampering) in the executable file would easily be detected. Accordingly, the presently disclosed embodiments provide a robust system for the detection and the blocking of unauthorized executable files from execution.

Abstract

A system includes a controller configured to control a process, and store at least one binary file, wherein the at least one binary files is generated from at least one source file, wherein the at least one source file comprises instructions configured to be executed by a processor in the controller. The controller may also be configured to retrieve a whitelist file comprising a first hash key value derived from the at least one binary file, and execute an executable file based on the whitelist file, wherein the executable file comprises the source file.

Description

BACKGROUND OF THE INVENTION
The subject matter disclosed herein relates to industrial control systems and, more particularly, to securing the operation of industrial control systems.
Industrial control systems, such automated power generation systems (e.g., wind, water, and gas turbine systems) and automated manufacturing systems (e.g., petroleum refineries, chemical manufacturing plants, and the like) are a common feature of modern industry. For such industrial control systems, an industrial controller may generally control the operation of the system. For example, certain devices in the industrial control system (e.g., sensors, pumps, valves, actuators, and the like) may be controlled by, and may report data to, the industrial controller. Furthermore, the industrial controller may execute instructions (e.g., firmware and/or applications) that may generally enable the industrial controller to control the operation of the industrial control system (e.g., a gas turbine system).
BRIEF DESCRIPTION OF THE INVENTION
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 one embodiment, a system includes a controller configured to control a process, and store at least one binary file, wherein the at least one binary files is generated from at least one source file, wherein the at least one source file comprises instructions configured to be executed by a processor in the controller. The controller may also be configured to retrieve a whitelist file comprising a first hash key value derived from the at least one binary file, and execute an executable file based on the whitelist file, wherein the executable file comprises the source file.
In another embodiment, A method includes determining an input binary by using an executable file, wherein the executable file is configured to be executed by a controller, calculating an input hash key value from the input binary, determining if the input hash key value is included in a whitelist, wherein the whitelist comprises a plurality of hash key values calculated from a plurality of authenticated binary files, and allowing the executable file to execute if the input hash key matches one of the plurality of hash key values in the whitelist.
In a third embodiment, a tangible, non-transitory, computer-readable medium includes instructions configured to be executed by a processor of an industrial controller. The instructions are configured to determine an input hash key value for an input binary file, and block execution of the input binary file if the input hash key value is not found in a whitelist, the whitelist comprising a plurality of hash key values.
BRIEF DESCRIPTION OF THE DRAWINGS
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:
FIG. 1 is a schematic diagram of an embodiment of an industrial control system and a build system, in accordance with aspects of the present disclosure;
FIG. 2 is a flow diagram for an embodiment of a process by which the build system builds the executable files and whitelist for later use by the industrial controller, in accordance with aspects of the present disclosure;
FIG. 3 is a flow diagram for an embodiment of a process by which the industrial controller receives and decrypts the whitelist, in accordance with aspects of the present disclosure;
FIG. 4 is a flow diagram for an embodiment of a process by which the industrial controller uses the decrypted whitelist to verify an executable file prior to execution, in accordance with aspects of the present disclosure; and
FIG. 5 is a detailed flow diagram for an embodiment of a process by which the industrial controller verifies an executable file prior to execution, in accordance with aspects of the present disclosure.
DETAILED DESCRIPTION OF THE INVENTION
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. Additionally, as used herein, the terms “executable file” and “binary file” may both generally refer to a computer-readable file that that includes instructions (e.g., binary instructions) that may be performed by a processor (e.g., the processor of an industrial controller). Furthermore, as used herein, the term “software developer” may generally refer to an organization which develops, maintains, and/or provides instructions in the form of source code and/or executable files to control the operation of industrial controllers. Also, as used herein, the term “whitelist” may refer to a file which includes a list identifying executable files that are authorized to run on an industrial controller. Additionally, the term “authorized” may be used herein to refer to an executable file that is verified to be from a trustworthy source (i.e., the software developer) and whose contents are verified as being the same as when it was provided by the trustworthy source.
As mentioned above, an industrial controller may generally execute instructions (e.g., base code, firmware, and/or applications stored in the form of one or more executable files) that may enable the industrial controller to control the operation of an industrial control system. These instructions may be initially loaded onto the industrial controller (e.g., into a memory or data storage component of the industrial controller) by the manufacturer before it is supplied to a customer. These instructions (e.g., base code, firmware, and/or applications) may also be subsequently updated (e.g., by the hardware manufacturer) and provided to the customer so that the instructions stored on the industrial controller may be updated to augment functionality and/or to fix errors or bugs in the instructions. Once the instructions in the memory of the industrial controller have been updated, then the industrial controller may execute these updated instructions to control the operation of the industrial control system.
However, under certain circumstances, it may be desirable for the industrial controller to verify that each executable file storing instructions for the industrial controller is authorized prior to execution. That is, it may be desirable to ensure that, prior to execution, each executable or binary file storing instructions for the industrial controller is verified as being provided from a trustworthy or reputable source (e.g., the software developer). Furthermore, it may be desirable to verify that each executable or binary file has not been altered since it was prepared by this trustworthy source (e.g., in transit between the hardware manufacturer and the customer). Moreover, it may be desirable to be able to perform this verification of executable files quickly and using limited resources (e.g., memory space and processor time), so as not to otherwise disrupt the operations of the industrial controller.
Accordingly, the presently disclosed systems and methods enable the verification of both the identity and the contents of each of the executable files before they are executed by the industrial controller in an efficient manner using a whitelisting system. That is, as discussed in detail below, presently disclosed embodiments utilize a secure whitelist file that may be provided by the software developer along with each release of executable files (e.g., each software installation or update release). This whitelist file generally includes a number of values, and each of these values may be associated with an authorized executable file. By verifying that each executable has an associated entry in the whitelist prior to execution, the presently disclosed embodiments provide the industrial controller with improved security to block or prevent the execution of undesired and/or malicious instructions (i.e., instructions from a non-trustworthy source).
As discussed in detail below, the presently disclosed whitelist file includes a collection of hash key values for the authorized executable files in a particular software release. That is, after each executable file is built, the executable file may be provided as input to a hash function and the hash key value output associated with that executable file may be stored in the whitelist file. The hash function may include a Cyclic Redundancy Check (CRC), a Message Digest (MD) algorithm, a Secure Hash Algorithm (SHA), or a combination thereof. Furthermore, the whitelist file may be securely provided to the industrial controller (e.g., encrypted prior to packaging and/or transport and decryption by the industrial controller). The industrial controller, prior to executing a particular executable file may also provide the particular executable file to the same hash function (e.g., cyclic redundancy check [CRC], MD5, SHA-1, or other hash function) and may search the whitelist file to determine if the hash key value output from the hash function is listed in the whitelist file. If the hash key value is located in the whitelist file, the industrial controller may conclude that the particular executable file is authorized (e.g., from a trustworthy source and unaltered since it was built) and proceed with executing the file. If, however, the hash key value is not located in the whitelist file, the industrial controller may block the execution of the particular executable file.
With the foregoing in mind, FIG. 1 is a schematic diagram illustrating an industrial control system 10. The illustrated industrial control system 10 includes an industrial controller 12 that may be coupled to a network 14 to control the operation of a number of field devices 16, 18 and 20. For example, the illustrated industrial controller 12 receives sensory data from a number of field devices 16, 18, and 20 (e.g., temperature sensors, pressure sensors, voltage sensors, control valves, actuators, or similar field devices for an industrial control system) via the network 14 to monitor and control the operation of a gas turbine system 22. In other embodiments, rather than a gas turbine system 22, the system being monitored and controlled by the industrial control system 10 may include, for example, any automated manufacturing systems (e.g., petroleum refinery systems, chemical production systems, or other automated manufacturing system) or automated power generation systems (e.g., power plants, steam turbine systems, wind turbine systems, gasification systems, and similar automated power generation systems). For example, in an embodiment, a gasification system may include a gasifier configured to gasify a carbonaceous feedstock to generate a synthetic gas, a gas treatment unit is configured to process the synthetic gas to remove undesirable elements (e.g., acid gases), a combustor configured to combust the synthetic gas to drive a turbine, and a generator coupled to the turbine configured to produce electrical power. In such an embodiment, the industrial controller 12 may monitor and control the various components of the gasification system (e.g., the gasifier, gas treatment unit, combustor, and turbine) using the field devices 16, 18, and 20.
For the illustrated industrial control system 10, the field devices 16, 18, and 20 are be communicatively coupled to the industrial controller 12 (e.g., via the network 14) while monitoring and controlling various aspects and parameters of the operation of the gas turbine system 22 (e.g., monitoring the temperature in a combustor of the gas turbine system, controlling the voltage output of an electrical generator coupled to a shaft of the gas turbine system, regulating a flow of a fuel into the combustor, controlling a valve to regulate a gas flow to a gas processor, controlling a steam input of a heat recovery steam generator (HRSG), and the like). It should be appreciated that the illustrated industrial control system 10 represent a simplified industrial control system, and that other industrial control systems may include any suitable number of industrial controllers 12, networks 14, networking devices, field devices, etc., to monitor and control various portions of any automated system 22. For example, the industrial control system may include a triple modular redundant (TMR) controller configured to provide redundant operations. The industrial control system may also include redundant controllers having a plurality of controllers (e.g., 2, 3, 4, 5 etc., controllers).
In the depicted embodiment, industrial controller 12 may use the network 14 for communicating with and controlling any one of the field devices 16, 18, or 20. For example, the industrial controller 12 may reside in an industrial plant and may be configured to adjust one or more process conditions related to the devices 16, 18, 20. The network 14 may be any electronic and/or wireless network suitable for enabling communications, and may include fiber media, twisted pair cable media, wireless communications hardware, Ethernet cable media (e.g., Cat-5, Cat-7), and the like. Further, the network 14 may include several sub-buses, such as a high speed Ethernet sub-bus suitable for connecting components of the industrial control system 10 at communication speeds of 100 MB/sec and upwards. Additionally, the network 14 may include an input/output (I/O) network, such as an I/O network conforming to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 standard. The network 14 may also include an H1 network sub-bus suitable for connecting components of the industrial control system 10 at communications speeds of approximately 31.25 Kb/sec. The sub-buses may intercommunicate with each other, for example, by using linking devices or gateways, such as those gateways available under the designation FG-100 provided by softing AG, of Haar, Germany, and/or I/O packs available from General Electric Co. of Schenectady, N.Y. Indeed, a number of interconnected sub-buses of the network 14 may be used to communicate amongst the components of the industrial control system 10.
The industrial controller 12 includes memory 34 and processor 36 that may execute instructions (e.g., binary instructions in executable files) to generally control the operation of the industrial control system 10. For example, the memory 34 of the industrial controller 12 may include one or more files including binary instructions that may be performed by the processor 36 in order to control and monitor the field devices 16, 18, and 20 disposed within portions of the gas turbine system 22. These executable files may, for example, be initially installed in the memory 34 of the industrial controller 12 by the manufacturer of the industrial controller 12 before the industrial controller 12 is installed in the industrial control network 10. Furthermore, as discussed in detail below, the executable files stored in the memory 34 of the industrial controller 12 may occasionally be updated, for example, to augment the features of previous software versions as well as improve performance.
Also communicatively coupled to the industrial controller 12 (e.g., via the network 14 or another suitable network) is the device 24, having a memory 25 and a processor 26, which may host a human machine interface (HMI) system 27, a manufacturing execution system (MES) 28, a supervisor control and data acquisition (SCADA) system 29, a distributed control system (DCS) 30, or similar interface systems. In particular, in certain embodiments, the device 24 may host a configuration application or tool, such as ToolboxST 32, available from General Electric Co., of Schenectady, N.Y. In general, the aforementioned systems may provide one or more interfaces by which a user may monitor and control the operation of the industrial controller 12. For example, the HMI 27 and/or the ToolboxST 32 may provide a user interface through which various parameters of the industrial control system 10 (e.g., stored in the memory 34 of the industrial controller 12) may be forced or set. By further example, as discussed in detail below, the HMI 27 and/or the ToolboxST 32 may include an interface through which the various executable files stored in the memory 34 of the controller 12 may be updated to newer versions. In certain embodiments, the aforementioned systems may be hosted on a single device 24, while, in other embodiments, they may each be installed on one or more devices in the industrial control network.
As mentioned above, the memory 34 of the industrial controller 12 generally stores a number of executable files (e.g., binary files) to be executed by the processor 36. Also mentioned, the executable files stored in the memory 34 of the industrial controller 12 may occasionally be updated. For example, a software developer may produce and/or provide software updates for the executable files used by the industrial controller 12. For example, the software developer may have a build system 38 (e.g., a computer, laptop, or similar computing device), having a memory 40 and a processor 42, that may be used to build the executable files for later execution by the industrial controller 12 (e.g., once loaded into the memory 34 of the industrial controller 12), such as at the time of manufacturing or during a software update, as discussed below. That is, the memory 40 of the build system 38 may include a number of source files that may contain instructions in the form of human-readable code in a computer programming language. In order to produce an updated version of the executable files, the software developer may use the processor 42 to compile these source files, translating them into computer-readable (e.g., binary) instructions in the form of executable files for later execution by the processor 36 of the industrial controller 12. Additionally, in certain embodiments, once the executable files have been created, they may be packaged together (e.g., placed in an archive, compressed, encrypted, and the like). Then, the software developer may provide the updated executable files to the industrial controller 12, as represented by the dashed line 44 of FIG. 1. In certain embodiments, the software developer may place the updated executable files on a physical medium (e.g., an optical disc, a magnetic medium, a flash drive, or other similar data storage medium) that may be provided to (e.g., mailed to) a user of device 24. This user may, in turn, utilize the HMI 27 and/or ToolboxST 32 to transfer the contents of the physical medium to the memory 34 of the industrial controller 12. In other embodiments, the device 24 may, for example, be capable of establishing a network connection to build system 38 in order to download the executable files from the memory 40 of the remote build system 38 of the software developer.
Accordingly, as stated above, it may generally be desirable to ensure that the industrial controller 12 only executes authorized executable files. That is, regardless of how the executable files are provided by the software developer (e.g., via physical medium or network connection), it would be beneficial to verify that the executable file has been in no way modified since it was compiled by the software developer (e.g., the processor 42 of the build system 38 of the software developer). As such, the presently disclosed embodiments utilize a whitelist file that is provided by the software developer along with the executable files as a way of verifying that all of the executable files are authorized prior to execution. As discussed in detail below with respect to FIGS. 2 and 3, the whitelist file contains hash key values for each of the executable files such that the industrial controller 12 may efficiently and simultaneously verify the identity and contents of each executable file prior to execution.
FIG. 2 illustrates a flow diagram of a process 50 by which a device (e.g., the processor 42 of the build system 38) may prepare a software package including executable files and a whitelist identifying authorized executable files for the industrial controller 12. The illustrated process 50 begins with the build system 38 receiving (block 52) a plurality of source files that include instructions to be later executed by the processor 36 of the industrial controller 12. Next, the processor 42 of the build system 38 may generate (block 54) a private encryption key. In certain embodiments, the processor 42 may utilize one or more algorithms to produce random or pseudo-random characters or values for this private encryption key. In other embodiments, the build system 38 may include one or more random number generating devices that may be used to generate random or pseudo-random characters or values for the private encryption key. Once the private encryption key has been generated, the processor 42 may add (block 56) this private encryption key to at least one of the plurality of source files. For example, a source file associated with a startup executable file (e.g., an executable file that may usually run first when the industrial controller 12 is started) may include a variable that is defined but whose value is not initially specified by the software developer. Accordingly, the processor 42 may edit the source file such that the value of the variable is defined to be the private encryption key. By doing so, as discussed in detail below with respect to FIG. 3, when the industrial controller 12 executes the executable file that was compiled from this edited source file, the industrial controller 12 may have the variable set to the private encryption key (e.g., in order to later decrypt the whitelist file).
Next, the processor 42 of the build system 38 may generate a plurality of executable files from the plurality of source files. That is, the processor 42 may compile the source files in memory 40 of the build system 38 in order to output a number of executable files, which may also be stored in memory 40 of the build system. The processor 42 may then determine a hash key value for each of the plurality of executable files. That is, the processor 42 may apply a hash function to each of the executable files in order to determine a hash key value. A non-limiting list of example hash functions include: Cyclic Redundancy Check (CRC) 32, CRC 64, Message-Digest Algorithm (MD) 5, MD 6, Secure Hash Algorithm (SHA) 1, SHA 2, SHA 256, or SHA 512. It should be appreciated that the hash key value uniquely identifies an executable file based on a digestion of the contents of the executable file. This means that even a single bit change in the content of the executable file (e.g., caused by an error or corruption during transmission over a network connection) may produce a significantly different hash key value. It should also be appreciated that it may be substantially difficult or impossible to intentionally or accidentally produce two different executable files that will produce the same hash key value. As such, it should be appreciated that this essentially enables a processor (e.g., the processor 34 of the industrial controller 12) to quickly verify both the identity and the contents of an executable file by comparing hash key values.
Next, the processor 42 may construct (block 62) a whitelist file including each of the hash key values determined for the plurality of executable files. For example, the processor 42 may create a new file and populate the file with a delimited list of the determined hash key values for the executable files previously compiled by the processor 42. In certain embodiments, the whitelist file may be constructed as an Extensible Markup Language (XML) file. Once the whitelist file has been created, the processor 42 may then encrypt (block 64) the constructed whitelist file using the private encryption key determined in block 54. For example, the processor 42 may use an Advanced Encryption Standard (AES) algorithm, a Data Encryption Standard (DES) algorithm, Pretty good privacy (PGP) algorithm, or other suitable data encryption algorithm. Then, in certain embodiments, the processor 42 may package (block 66) the executable files together with the encrypted whitelist file. That is, the processor 42 may combine the executable file and the encrypted whitelist file into a single archive or compressed file for distribution to the industrial controller 12. In other embodiments, the build system 38 may make the whitelist file available to the industrial controller 12 and/or device 24 for eventual use by the processor 36 of the industrial controller 12.
FIG. 3 illustrates a flow diagram for an embodiment of a process 70 by which a processor 36 of the industrial controller 12 receives and decrypts the whitelist file. The process 70 may begin with the processor 36 of the industrial controller 12 receiving and unpackaging (block 72) the plurality of executable files and the encrypted whitelist file. As mentioned above, the HMI 27 and/or ToolboxST application 32 of the device 24 may assist the industrial controller 12 in receiving and/or unpackaging the plurality of executable files from the software developer (e.g., from build system 38 via physical medium or a network connection). The process 70 continues with the processor 36 of the industrial controller 12 executing (block 74) a startup executable file which may include the private encryption key, as discussed in blocks 64 and 54 of FIG. 2. Next, the processor 36 of the industrial controller 12 may decrypt (block 76) the encrypted whitelist file using the private encryption key in order to provide a decrypted whitelist file (e.g., in the memory 34 of the industrial controller 12). It should be appreciated that, while the actions described in block 72 may generally only be performed during an update of the industrial controller 12, in certain embodiments, the actions described in blocks 74 and 76 may also be performed, for example, during reboots of the industrial controller 12.
FIG. 4 illustrates a flow diagram for an embodiment of a process 80 by which a processor 36 of the industrial controller 12 may use the whitelist to verify that an executable file is authorized prior to execution. The process 80 begins with the processor 36 determining (block 82) that a particular executable file is attempting execution. The processor 36 may then determine (block 84) a hash key value for the executable file that is attempting execution. It should be appreciated that the processor 36 will apply the same hash function as was used to determine the hash key values during the construction of the whitelist file (e.g., discussed in block 60 of FIG. 2). The process 80 continues with the processor 36 determining (block 86) if the hash key value is included within the decrypted whitelist file (e.g., the decrypted whitelist file discussed with respect to block 76 of FIG. 3). For example, in certain embodiments, the decrypted whitelist file discussed in block 76 of FIG. 3 may be loaded into the memory 34 of the industrial controller 12 as a particular data structure, such as a hash table, which may enable fast and/or efficient searching when determining if a particular hash key value is present in the whitelist. Then, the processor 36 may allow (block 88) the executable file to execute when or if the hash key determined for the executable file is located in the decrypted whitelist file. However, the process 80 may also terminate with the processor 36 blocking (block 90) the execution of the executable file if the hash key value for the executable file is not located in the decrypted whitelist file. In certain embodiments, the processor 36 may further log (e.g., the blocked execution of the executable file as a potential security concern).
FIG. 5 illustrates a detailed flow diagram of an embodiment of a process 94 by which an executable file 95 is verified prior to execution. The process 94 may be implemented by using a non-transitory machine readable medium including code executable by the controller 12. The process 94 may begin when the processor 36 receives (block 96) the executable file 95, such as an input executable (e.g., binary) file. The executable file 95 may include executable code attempting to execute in the processor 36. The processor 36 may then determine (block 98) a binary from the executable file that is attempting to execute such that the executable file is expressed as a binary file. In one embodiment, multiple executable files may be used, and the process 94 may determine which executable binary is attempting to execute (block 98) so that it may be checked against a whitelist file, as described in more detail below. The processor 36 may then use the determined binary to decide (decision 100) whether or not the binary exists in the whitelist. The processor 36 may access a whitelist file 102 listing executable system binary files that may be approved for execution by the processor 36 in order to determine whether the determined binary exists. The system binary files are generally executable or binary files such as operating system files that exist in the operating system. If the determined binary does not exist in the whitelist file 102, then the processor 36 may return (block 104) an error. The error may result in an alert or notification that is outputted to the user through the HMI 27 or other output. Additionally, the executable file 95 may be blocked from executing. If the determined binary does exist in the whitelist file 102, then the processor 36 may determine (block 106) an input hash key value of the determined binary. It should be appreciated that the processor 36 may generally apply the same hash function as was used to determine the hash key values during the construction of the whitelist file 102 (e.g., discussed in block 60 of FIG. 2). In some embodiments, this involves passing the binary files through a secure hash algorithm to generate a 160-bit hash string. The processor 36 then decides (decision 108) whether the input hash key value matches the hash key value from the whitelist file 102. In the depicted embodiment, the input hash key value of the determined binary file is compared to the hash key value of the corresponding binary file in the whitelist file 102. If the input hash key value matches the value from the whitelist file 102, the executable file may be allowed to execute. If the input hash key value does not match the value from the whitelist file 102, the processor 36 may return (block 104) an error. The error may be an alert or notification outputted to the user. Further, the executable file 95 may also be blocked from executing. In certain embodiments, when an error is returned (block 104), the event and/or the executable file may be stored for future analysis or security reporting.
The technical effects of this disclosure include improving the security of an industrial controller of an industrial control system. That is, presently disclosed embodiments enable a processor 36 of the industrial controller 12 to verify that each executable file is authorized prior to execution. In particular, by using hash key values for the verification process of the executable files, the presently disclosed embodiments provide a light-weight system, enabling the processor 36 of the industrial controller 12 to perform this verification process with minimal impact on resources (e.g., memory space and/or processing time). Furthermore, through the use of hash key values, presently disclosed embodiments provide verification of both the content and the identity of the executable files, such that even a single bit change (e.g., due to a transmission error, file corruption, or file tampering) in the executable file would easily be detected. Accordingly, the presently disclosed embodiments provide a robust system for the detection and the blocking of unauthorized executable files from execution.
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.

Claims (19)

The invention claimed is:
1. A system comprising:
a machinery disposed on an industrial plant;
at least one sensor disposed on an industrial plant component of the machinery;
a hardware controller communicatively coupled to the sensor, the hardware controller configured to :
receive at least one sensor value from the at least one sensor;
execute an executable file that utilizes the at least one sensor value as input to the executable file to derive a control action, wherein the executable file comprises an executable binary file stored in a memory of the hardware controller;
control a process of the industrial plant by actuating a field device based on the control action, wherein actuating the field device controls an operation of a gas turbine system of the machinery;
retrieve a whitelist file wherein the whitelist file comprises an encrypted file stored in the hardware controller and used by the hardware controller to enable execution of commands;
decrypt the whitelist file to derive a first hash key value;
derive a second hash key value from the executable file;
determine whether the executable file is listed in the whitelist file by comparing the first hash key value to the second hash key value; and
executing, during machinery operations, the executable file to control the gas turbine based on the determination that the executable file is listed on the whitelist file.
2. The system of claim 1, wherein the hardware controller is configured to block execution of the executable file when the first hash key value does not match the second hash key value.
3. the system of claim 1, wherein the hardware controller is configured to raise an alert, raise an alarm, write to a log file, or a combination thereof, when the first hash key value does not match the second hash key value.
4. the system of claim 1, wherein the hardware controller is configured to receive a command comprising the executable file.
5. The system of claim 1, wherein a hash function is configured to derive the first hash key value.
6. The system of claim 5, wherein the hash function comprises a Cyclic Redundancy Check (CRC), a Message Digest (MD) algorithm, a Secure Hash Algorithm (SHA), or a combination thereof.
7. The system of claim 1, wherein the first hash key value comprises at least 160 bits.
8. The system of claim 1, wherein the hardware controller is configured to execute the executable file conditional on verification with the whitelist upon a request, at a predetermined time interval, at random, or a combination thereof.
9. The system of claim 1, wherein the machinery comprises the tubine system disposed on the industrial plant and configured to convert a fuel into a power, wherein the hardware controller comprises an industrial controller configured to control the turbine system.
10. The system of claim 1, wherein the whitelist comprises an encrypted whitelist and the hardware controller is configured to decrypt the encrypted whitelist.
11. The system of claim 1, wherin the hardware controller comprises a triple modular redundant (TMR) controller configured to provide redundant operations.
12. A method, comprising:
operating, via a hardware controller, a machinery disposed on an industrial plant;
receiving, via a sensor disposed on an industrial plant component of the machinery and communicatively coupled to the hardware controller, a sensor signal;
executing, via the hardware controller, an executable file that utilizes the sensor signal as input to the executable file to derive a control action, wherein the executable file comprises an executable binary file;
controlling, via the hardware controller, a process of the industrial plant by actuating a field device based on the control action;
determining, via the hardware controller, an input binary by using the executable file, wherein the executable file is configured to be executed by the hardware controller, and wherein the input binary, when executed by the hardware controller, commands the hardware controller to control an operation of a turbine system of the machinery;
decrypting, via the hardware controller, an encrypted whitelist to produce a decrypted whitelist;
calculating, via the hardware controller, an input hash key value from the input binary;
determining, via the hardware controller, whether the input hash key value is included in the decrypted whitelist, wherein the decrypted whitelist comprises a plurality of hash key values calculated from a plurality of authenticated binary files, wherein the encrypted whitelist comprises an encrypted file stored in the hardware controller and used by the hardware controller to enable execution of commands; and
executing, via the hardware controller, the executable file to control the turbine system when the input hash key matches one of the plurality of hash key values in the decrypted whitelist.
13. The method of claim 12, comprising blocking the executable file from executing when the input hash key does not match at least one of the plurality of hash key values in the decrypted whitelist.
14. the method of claim 12, wherein the hardware controller comprises a triple modular redundant (TMR) controller configured to provide redundant operations to the turbine system included in the machinery.
15. the method of claim 12, comprising:
determining whether the input binary matches a system binary by using a list of system binary files;
blocking the executable file from executing when the input binary does not match one of the system binary files in the list of system binary files.
16. The method of claim 12, comprising storing an execution prevention information outputting an alert, outputting a notification, or a combination thereof, when the input hash key does not match at least one of the plurality of hash key values in the decrypted whitelist.
17. A tangible, non-transitory, computer-readable medium comprising instructions configured to be executed by a processor of a hardware controller, the instructions configured to:
operate a machinery disposed on an industrial plant;
receive, via a sensor disposed on the industrial plant component, a sensor signal;
execute an executable file that utilizes the sensor signal as input to the executable file to derive a control action;
control a process of the industrial plant by actuating a field device based on the control action, wherein actuating the field device controls an operation of a gas turbine system of the machinery;
decrypt an encrypted whitelist to provide a decrypted whitelist;
determine an input hash key value for an input binary file, wherein the input binary file of the executable file, when executed by the hardware controller, commands the hardware controller to control an operation of the gas turbine system of the machinery; and
block execution of the input binary file when the input hash key value is not found in the decrypted whitelist, execute the input binary file when the input hash key value is found in the decrypted whitelist; wherein the decrypted whitelist comprising a plurality of hash key values, and wherein the encrypted whitelist comprises an encrypted file stored in the hardware controller and used by the hardware controller to enable execution of commands.
18. The computer-readable medium of claim 17, wherein the instructions are configured to execute the input binary file when the input hash key value is found in the decrypted whitelist.
19. The computer-readable medium of claim 17, wherein the instructions are configured to determine the input hash key value for the input binary file by using a Cyclic Redundancy Check (CRC), a Message-Digest Algorithm (MD), a Secure Hash Algorithm (SHA), or a combination thereof.
US13/460,771 2012-04-30 2012-04-30 Systems and methods for controlling file execution for industrial control systems Active US8959362B2 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US13/460,771 US8959362B2 (en) 2012-04-30 2012-04-30 Systems and methods for controlling file execution for industrial control systems
EP13166007.8A EP2660668B1 (en) 2012-04-30 2013-04-30 System and method for controlling file execution for industrial control systems
ES13166007T ES2868141T3 (en) 2012-04-30 2013-04-30 System and method to control the execution of files for industrial control systems
CN201310157177.8A CN103377328B (en) 2012-04-30 2013-05-02 The system and method that file for controlling industrial control system executes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US13/460,771 US8959362B2 (en) 2012-04-30 2012-04-30 Systems and methods for controlling file execution for industrial control systems

Publications (2)

Publication Number Publication Date
US20130290729A1 US20130290729A1 (en) 2013-10-31
US8959362B2 true US8959362B2 (en) 2015-02-17

Family

ID=48184098

Family Applications (1)

Application Number Title Priority Date Filing Date
US13/460,771 Active US8959362B2 (en) 2012-04-30 2012-04-30 Systems and methods for controlling file execution for industrial control systems

Country Status (4)

Country Link
US (1) US8959362B2 (en)
EP (1) EP2660668B1 (en)
CN (1) CN103377328B (en)
ES (1) ES2868141T3 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190080080A1 (en) * 2017-09-11 2019-03-14 Kabushiki Kaisha Toshiba Information processing apparatus, information processing method, and computer program product
US10317860B2 (en) * 2013-05-20 2019-06-11 Mitsubishi Electric Corporation Monitoring control device

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4558099B1 (en) * 2010-02-03 2010-10-06 メキキ・クリエイツ株式会社 Digital data content certification system, data certification device, user terminal, computer program and method
US8973124B2 (en) 2012-04-30 2015-03-03 General Electric Company Systems and methods for secure operation of an industrial controller
US9046886B2 (en) 2012-04-30 2015-06-02 General Electric Company System and method for logging security events for an industrial control system
US8964973B2 (en) 2012-04-30 2015-02-24 General Electric Company Systems and methods for controlling file execution for industrial control systems
JP5863689B2 (en) * 2013-02-28 2016-02-17 京セラドキュメントソリューションズ株式会社 Shared library with unauthorized use prevention function
US9912733B2 (en) * 2014-07-31 2018-03-06 General Electric Company System and method for maintaining the health of a control system
US9710648B2 (en) 2014-08-11 2017-07-18 Sentinel Labs Israel Ltd. Method of malware detection and system thereof
US11507663B2 (en) 2014-08-11 2022-11-22 Sentinel Labs Israel Ltd. Method of remediating operations performed by a program and system thereof
US10048960B2 (en) 2014-12-17 2018-08-14 Semmle Limited Identifying source code used to build executable files
IL243024A0 (en) * 2015-12-10 2016-02-29 Shabtai Asaf Method and system for detecting a plc in a scada system that is sending false telemetry data
US10366054B2 (en) * 2015-12-14 2019-07-30 Abb Schweiz Ag Method and apparatus for for software application internal re-structuring of specifically authorized multi-level sub-folders
US9858424B1 (en) * 2017-01-05 2018-01-02 Votiro Cybersec Ltd. System and method for protecting systems from active content
US10599842B2 (en) * 2016-12-19 2020-03-24 Attivo Networks Inc. Deceiving attackers in endpoint systems
US11695800B2 (en) * 2016-12-19 2023-07-04 SentinelOne, Inc. Deceiving attackers accessing network data
US11616812B2 (en) * 2016-12-19 2023-03-28 Attivo Networks Inc. Deceiving attackers accessing active directory data
US10331889B2 (en) 2017-01-05 2019-06-25 Votiro Cybersec Ltd. Providing a fastlane for disarming malicious content in received input content
CA2999581A1 (en) 2017-03-28 2018-09-28 Walmart Apollo, Llc Systems and methods for computer assisted database change documentation
EP3643040A4 (en) 2017-08-08 2021-06-09 SentinelOne, Inc. Methods, systems, and devices for dynamically modeling and grouping endpoints for edge networking
US11042610B1 (en) * 2017-10-04 2021-06-22 Xilinx, Inc. Enabling integrity and authenticity of design data
US10542007B2 (en) * 2017-12-28 2020-01-21 General Electric Company Command authentication related to the control of industrial systems
US11470115B2 (en) 2018-02-09 2022-10-11 Attivo Networks, Inc. Implementing decoys in a network environment
EP3528064B1 (en) * 2018-02-15 2023-12-06 Siemens Aktiengesellschaft Control system and associated method for commissioning, controlling and monitoring current supply components
WO2019199950A1 (en) * 2018-04-11 2019-10-17 Walmart Apollo, Llc Software artifact management systems and methods
US11132437B2 (en) * 2018-06-26 2021-09-28 The Government Of The United States Of America, As Represented By The Secretary Of The Navy Secure computer operating system through interpreted user applications
US11138085B2 (en) 2018-10-09 2021-10-05 Argo AI, LLC Execution sequence integrity monitoring system
EP3864544B1 (en) * 2018-10-09 2023-09-20 Argo AI, LLC Execution sequence integrity monitoring system
US11144375B2 (en) 2018-10-09 2021-10-12 Argo AI, LLC Execution sequence integrity parameter monitoring system
TWI774902B (en) * 2018-12-28 2022-08-21 新唐科技股份有限公司 Private key protection method and private key protection system
CN109726547A (en) * 2019-01-28 2019-05-07 北京和利时工业软件有限公司 A kind of file executes management method and relevant apparatus
CH715916B1 (en) * 2019-03-12 2022-06-15 Sauter Ag Data Integrity Check Procedure.
US11757663B1 (en) * 2019-03-22 2023-09-12 Emtruth, Inc. Blockchain-based monitoring of devices
US11044320B2 (en) * 2019-04-01 2021-06-22 Honeywell International Inc. Data distribution method for a process automation and internet of things system
JP7278423B2 (en) 2019-05-20 2023-05-19 センチネル ラブス イスラエル リミテッド System and method for executable code detection, automatic feature extraction and position independent code detection
JP7289739B2 (en) * 2019-06-27 2023-06-12 キヤノン株式会社 Information processing device, information processing method and program
TWI730415B (en) * 2019-09-18 2021-06-11 財團法人工業技術研究院 Detection system, detection method, and an update verification method performed by using the detection method
US11579857B2 (en) 2020-12-16 2023-02-14 Sentinel Labs Israel Ltd. Systems, methods and devices for device fingerprinting and automatic deployment of software in a computing network using a peer-to-peer approach
US11899782B1 (en) 2021-07-13 2024-02-13 SentinelOne, Inc. Preserving DLL hooks

Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5774652A (en) 1995-09-29 1998-06-30 Smith; Perry Restricted access computer system
EP0891611A1 (en) 1996-03-22 1999-01-20 Activcard Function access control system with encryption using a plurality of dynamic variables
US6449732B1 (en) * 1998-12-18 2002-09-10 Triconex Corporation Method and apparatus for processing control using a multiple redundant processor control system
US6694434B1 (en) * 1998-12-23 2004-02-17 Entrust Technologies Limited Method and apparatus for controlling program execution and program distribution
WO2005069823A2 (en) 2004-01-15 2005-08-04 Jun Song Centralized transactional security audit for enterprise systems
US7246002B2 (en) * 2003-11-20 2007-07-17 General Electric Company Method for controlling fuel splits to gas turbine combustor
US20080168564A1 (en) * 2007-01-08 2008-07-10 Apple Inc. Software or other information integrity verification using variable block length and selection
US20080175388A1 (en) 2006-11-27 2008-07-24 Yokogawa Electric Corporation Control system and multicast communication method
US20090049430A1 (en) * 2007-08-17 2009-02-19 Pai Ramachandra N Verifying that binary object file has been generated from source files
US20090171479A1 (en) 2005-11-25 2009-07-02 Satoru Oosako Plant Control System
US7577848B2 (en) * 2005-01-18 2009-08-18 Microsoft Corporation Systems and methods for validating executable file integrity using partial image hashes
US20100185857A1 (en) * 2009-01-21 2010-07-22 Lee Allen Neitzel Removable security modules and related methods
US20100192208A1 (en) 2007-06-11 2010-07-29 Ulf Mattsson Method and system for preventing impersonation of a computer system user
US20100313264A1 (en) 2009-06-08 2010-12-09 Microsoft Corporation Blocking malicious activity using blacklist
US20110040470A1 (en) * 2009-08-14 2011-02-17 Lockheed Martin Corporation Starter Control Valve Failure Prediction Machine To Predict and Trend Starter Control Valve Failures In Gas Turbine Engines Using A Starter Control Valve Health Prognostic, Program Product and Related Methods
US8015791B2 (en) * 2008-11-18 2011-09-13 General Electric Company Fuel control system for gas turbine and feed forward control method
US8121707B2 (en) 2009-04-14 2012-02-21 General Electric Company Method for download of sequential function charts to a triple module redundant control system
US20120226917A1 (en) * 2009-10-22 2012-09-06 Qinetiq Limited Data Content Checking
US20130036311A1 (en) * 2011-08-05 2013-02-07 Battelle Memorial Institute Intelligent sensor and controller framework for the power grid
US20130110298A1 (en) * 2011-10-31 2013-05-02 Emerson Process Management Power & Water Solutions , Inc. Model-based load demand control

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005099340A2 (en) * 2004-04-19 2005-10-27 Securewave S.A. On-line centralized and local authorization of executable files
WO2006101549A2 (en) * 2004-12-03 2006-09-28 Whitecell Software, Inc. Secure system for allowing the execution of authorized computer program code
US7805765B2 (en) * 2004-12-28 2010-09-28 Lenovo (Singapore) Pte Ltd. Execution validation using header containing validation data
CN101593259B (en) * 2009-06-29 2011-03-23 北京航空航天大学 Method and system for verifying software completeness
US8484474B2 (en) * 2010-07-01 2013-07-09 Rockwell Automation Technologies, Inc. Methods for firmware signature
US9792429B2 (en) * 2010-10-06 2017-10-17 Red Hat, Inc. Detection of malicious software packages

Patent Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5774652A (en) 1995-09-29 1998-06-30 Smith; Perry Restricted access computer system
EP0891611A1 (en) 1996-03-22 1999-01-20 Activcard Function access control system with encryption using a plurality of dynamic variables
US6449732B1 (en) * 1998-12-18 2002-09-10 Triconex Corporation Method and apparatus for processing control using a multiple redundant processor control system
US6694434B1 (en) * 1998-12-23 2004-02-17 Entrust Technologies Limited Method and apparatus for controlling program execution and program distribution
US7246002B2 (en) * 2003-11-20 2007-07-17 General Electric Company Method for controlling fuel splits to gas turbine combustor
WO2005069823A2 (en) 2004-01-15 2005-08-04 Jun Song Centralized transactional security audit for enterprise systems
US7577848B2 (en) * 2005-01-18 2009-08-18 Microsoft Corporation Systems and methods for validating executable file integrity using partial image hashes
US20090171479A1 (en) 2005-11-25 2009-07-02 Satoru Oosako Plant Control System
US20080175388A1 (en) 2006-11-27 2008-07-24 Yokogawa Electric Corporation Control system and multicast communication method
US20080168564A1 (en) * 2007-01-08 2008-07-10 Apple Inc. Software or other information integrity verification using variable block length and selection
US20100192208A1 (en) 2007-06-11 2010-07-29 Ulf Mattsson Method and system for preventing impersonation of a computer system user
US20090049430A1 (en) * 2007-08-17 2009-02-19 Pai Ramachandra N Verifying that binary object file has been generated from source files
US8015791B2 (en) * 2008-11-18 2011-09-13 General Electric Company Fuel control system for gas turbine and feed forward control method
US20100185857A1 (en) * 2009-01-21 2010-07-22 Lee Allen Neitzel Removable security modules and related methods
US8121707B2 (en) 2009-04-14 2012-02-21 General Electric Company Method for download of sequential function charts to a triple module redundant control system
US20100313264A1 (en) 2009-06-08 2010-12-09 Microsoft Corporation Blocking malicious activity using blacklist
US20110040470A1 (en) * 2009-08-14 2011-02-17 Lockheed Martin Corporation Starter Control Valve Failure Prediction Machine To Predict and Trend Starter Control Valve Failures In Gas Turbine Engines Using A Starter Control Valve Health Prognostic, Program Product and Related Methods
US20120226917A1 (en) * 2009-10-22 2012-09-06 Qinetiq Limited Data Content Checking
US20130036311A1 (en) * 2011-08-05 2013-02-07 Battelle Memorial Institute Intelligent sensor and controller framework for the power grid
US20130110298A1 (en) * 2011-10-31 2013-05-02 Emerson Process Management Power & Water Solutions , Inc. Model-based load demand control

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
U.S. Appl. No. 13/460,721, filed Apr. 30, 2012, Sahoo et al.
U.S. Appl. No. 13/460,759, filed Apr. 30, 2012, Socky et al.
U.S. Appl. No. 13/460,779, filed Apr. 30, 2012, Chong et al.
U.S. Appl. No. 13/460,794, filed Apr. 30, 2012, Chong et al.
U.S. Appl. No. 13/460,801, filed Apr. 30, 2012, Chong et al.

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10317860B2 (en) * 2013-05-20 2019-06-11 Mitsubishi Electric Corporation Monitoring control device
US20190080080A1 (en) * 2017-09-11 2019-03-14 Kabushiki Kaisha Toshiba Information processing apparatus, information processing method, and computer program product
US10846394B2 (en) * 2017-09-11 2020-11-24 Kabushiki Kaisha Toshiba Information processing apparatus, information processing method, and computer program product

Also Published As

Publication number Publication date
CN103377328B (en) 2018-09-25
EP2660668A2 (en) 2013-11-06
US20130290729A1 (en) 2013-10-31
EP2660668B1 (en) 2021-01-20
ES2868141T3 (en) 2021-10-21
EP2660668A3 (en) 2017-04-05
CN103377328A (en) 2013-10-30

Similar Documents

Publication Publication Date Title
US8959362B2 (en) Systems and methods for controlling file execution for industrial control systems
US8964973B2 (en) Systems and methods for controlling file execution for industrial control systems
US9397997B2 (en) Systems and methods for secure operation of an industrial controller
US20130291115A1 (en) System and method for logging security events for an industrial control system
US8533492B2 (en) Electronic device, key generation program, recording medium, and key generation method
CN106249704B (en) Method and device for controlling communication of endpoints in industrial enterprise system based on integrity
US8726372B2 (en) Systems and methods for securing controllers
EP3963867A1 (en) Device data protection based on network topology
EP2975546B1 (en) Systems and methods for verifying the authenticity of an application during execution
CN115097807A (en) Memory attack detection method and system for programmable logic controller
JP6069160B2 (en) Control system and authentication device

Legal Events

Date Code Title Description
AS Assignment

Owner name: GENERAL ELECTRIC COMPANY, NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PETTIGREW, WILLIAM ROBERT;CHONG, JUSTIN BRANDON;SAHOO, MANAS RANJAN;SIGNING DATES FROM 20120412 TO 20120420;REEL/FRAME:028145/0535

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCF Information on status: patent grant

Free format text: PATENTED CASE

CC Certificate of correction
MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551)

Year of fee payment: 4

AS Assignment

Owner name: BAKER HUGHES, A GE COMPANY, LLC, TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GENERAL ELECTRIC COMPANY;REEL/FRAME:056442/0072

Effective date: 20170703

AS Assignment

Owner name: BAKER HUGHES, A GE COMPANY, LLC, TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GENERAL ELECTRIC COMPANY;REEL/FRAME:056846/0372

Effective date: 20170703

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8

AS Assignment

Owner name: BAKER HUGHES HOLDINGS LLC, TEXAS

Free format text: CHANGE OF NAME;ASSIGNOR:BAKER HUGHES, A GE COMPANY, LLC;REEL/FRAME:061318/0306

Effective date: 20220415