Patent Description:
Industrial automation systems may be used to provide automated control of one or more actuators. Specifically, a controller may receive power from a power source and output a conditioned power signal to an actuator to control movement of the actuator. One or more components of an industrial automation system may be equipped with memory. Some entities (e.g., government, military, government/military contractors, private sector enterprises, etc.) may enforce policies against repurposing devices that contain memory because sensitive data may have been stored in memory and may be recoverable from the memory. Accordingly, many such entities destroy devices with memory when they are no longer employed in an application and purchase new devices for new applications instead of repurposing the previously used devices. This can be cost, resource, and materially intensive, and creates more electronic waste. Accordingly, it may be desirable to develop techniques for purging the memory of devices such that devices can be repurposed without the risk of previously stored data being recoverable.

<CIT> relates to a method and a device for managing a controller program. The method comprises the following steps: after offline detection is performed on the basis of an offline detection EOL program provided by a hardware provider, erasing the EOL program through a first BootLoader program provided by the hardware provider, wherein the first BootLoader program and the EOL program are programmed into a controller nonvolatile memory at a bare board stage; the method comprises the steps that a second BootLoader program and an application file provided by a product supplier are written into a nonvolatile memory through a first BootLoader program; and storing a preset erasing code into a preset memory through the first BootLoader program, and executing an erasing operation on the first BootLoader program through the erasing code so as to ensure that no hardware provider program residue exists in the controller. <CIT> relates to a system for permanent data deletion. The file deletion system consists of a permanent deletion unit, an analysis module, a database of rules for forming deletion algorithm and an algorithm forming unit. A file to be deleted is passed into the system and the system permanently deletes the file. The system dynamically forms the deletion algorithm based on algorithm forming rules. The rules are selected from the database according to file parameters and user criteria. The file parameters are determined by the analysis module. A user has an access to algorithm forming rules and can edit the rules. Algorithm forming rules can be based on an arbitrary number of complex conditions. <NPL>, relates to an automated system for rapid and secure device sanitization. Public and private organizations face the challenges of protecting their networks from cyber-attacks, while reducing the amount of time and money spent on Information Technology. Organizations can reduce their expenditures by reusing server, switch and router hardware, but they must use reliable and efficient methods of sanitizing these devices before they can be redeployed. The sanitization process removes proprietary, sensitive or classified data, as well as persistent malware from a device prior to reuse. <CIT> relates to systems and methods for performing data sanitization at a data storage device (DSD). In an example, a controller may direct a memory device to sanitize data by securely erasing the data, generate an attestation confirming that the data was successfully sanitized, and sign the attestation using an authentication key to create a signed attestation. In another example, a circuit may direct a memory device to sanitize data based on the data sanitization instruction, generate a sanitization confirmation indicating that the data was successfully sanitized, and provide the sanitization confirmation including a first thumbprint and a second thumbprint to another device. Generating the sanitization confirmation may include processing a first storage encryption key to produce the first thumbprint, directing the memory device to obliterate the first storage encryption key, and processing a second storage encryption key to produce the second thumbprint.

It is the object of the present invention to provide an improved method and system for purging a non-volatile memory of a device like an industrial automation component.

In an embodiment, an industrial automation component includes a processor, a volatile memory, and a non-volatile memory. The non-volatile memory is accessible by the processor and stores instructions that, when executed by the processor, cause the processor to receive a command to perform a memory purge, retrieve code of a purging firmware package from the non-volatile memory, store the code in the volatile memory, execute the code from volatile memory, thereby causing the processor to purge the non-volatile memory, and cycle power to the industrial automation component, wherein cycling the power comprises purging the volatile memory.

In another embodiment, an industrial automation component includes a processor, a volatile memory, and a non-volatile memory. The non-volatile memory is accessible by the processor and stores instructions that, when executed by the processor, cause the processor to receive a command to perform a memory purge from a device communicatively coupled to the industrial automation component via a network, store code of a purging firmware package in the volatile memory, execute the code from volatile memory, thereby causing the processor to purge the non-volatile memory, and cycle power to the industrial automation component, wherein cycling the power comprises purging the volatile memory.

In another embodiment, a method of purging a non-volatile memory of an industrial automation component comprises retrieving code of a purging firmware package from the non-volatile memory, storing the code in the volatile memory, executing the code from volatile memory, thereby causing the processor to purge the non-volatile memory, and cycling power to the industrial automation component, wherein cycling the power comprises purging the volatile memory.

Various refinements of the features noted above may exist in relation to various aspects of the present disclosure. Further features may also be incorporated in these various aspects as well. These refinements and additional features may exist individually or in any combination. For instance, various features discussed below in relation to one or more of the illustrated embodiments may be incorporated into any of the above-described aspects of the present disclosure alone or in any combination. The brief summary presented above is intended only to familiarize the reader with certain aspects and contexts of embodiments of the present disclosure without limitation to the claimed subject matter.

These and other features, aspects, and advantages of the present embodiments 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:.

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 enterprise-related constraints, which may vary from one implementation to another.

The present disclosure includes techniques for purging memory of devices such that data previously stored in memory that cannot be recovered using various laboratory techniques, thus allowing memory-containing devices to be repurposed for another application rather than being destroyed. Specifically, the memory may be purged via a self-deleting firmware package. The firmware package may be stored in non-volatile memory of the device. The firmware package may be received from another device via a wired or wireless network connection, received via removable media (e.g., SD card, USB drive, optical disc, etc.), or in any other suitable manner. The firmware package may be copied to volatile memory and executed by a processor to perform a purging process. This may include, for example, overwriting some or all of the addressable locations of the memory a number of times using specific sequences of patterns of <NUM> and <NUM>, such that data stored in the memory before the purge process was started cannot be recovered by various laboratory techniques.

In some embodiments, inputs may be provided authorizing the memory purge in case that the firmware package is received from a different device. In some embodiments, the entirety of the non-volatile memory and volatile memory of the device may be purged. In other embodiments, portions (e.g., less than the whole) of the non-volatile memory of the device used by specific applications having a sensitivity level above a threshold level may be purged. After the purge of the non-volatile memory is complete, power to the device is cycled, thereby clearing the volatile memory. At such a point, the non-volatile memory and volatile memory of the device have been purged.

With this in mind, in some embodiments, the device may receive and execute a baseline software and/or firmware package that returns the device to its original factory settings. In some embodiments, the device may generate and display a hash value or some other visualization indicating that the device has been purged. In other embodiments, the device may generate a report indicating that the device has been purged, and the report may include the generated hash value or other suitable representative visualization. The report may or may not be encrypted. If the report is encrypted, the report may be encrypted using asymmetric cryptography. That is, the report may be encrypted using a public key. In such an embodiment, a customer would decrypt the report using a provided private key. However, in some embodiments, the use of public and private keys may be reversed such that the report is encrypted using a private key and decrypted using a public key. Use of these techniques allows an entity to purge memory of memory-containing devices such that data previously stored in memory of the device pre-purge cannot be recovered using various laboratory techniques (e.g., live Compact Discs (CD), live Digital Video Disc (DVD), magnetic force microscopy, reference recovery, cross-drive analysis, file carving, and so forth), such that devices can be repurposed for new applications instead of being destroyed. Additional details with regard to purging the memory of various devices in accordance with the techniques described above will be provided below with reference to <FIG>.

By way of introduction, <FIG> is a schematic view of an example industrial automation system <NUM> in which the embodiments described herein may be implemented. As shown, the industrial automation system <NUM> includes a controller <NUM> and an actuator <NUM> (e.g., a motor). The industrial automation system <NUM> may also include, or be coupled to, a power source <NUM>. The power source <NUM> may include a generator, an external power grid, a battery, or some other source of power. The controller <NUM> may be a stand-alone control unit that controls multiple industrial automation components (e.g., a plurality of motors <NUM>), a controller <NUM> that controls the operation of a single automation component (e.g., motor <NUM>), or a subcomponent within a larger industrial automation system <NUM>. In the instant embodiment, the controller <NUM> includes a user interface <NUM>, such as a human machine interface (HMI), and a control system <NUM>, which may include a memory <NUM> and a processor <NUM>. The controller <NUM> may include a cabinet or some other enclosure for housing various components of the industrial automation system <NUM>, such as a motor starter, a disconnect switch, etc..

The control system <NUM> may be programmed (e.g., via computer readable code or instructions stored on the memory <NUM> and executable by the processor <NUM>) to provide signals for controlling the motor <NUM>. In certain embodiments, the control system <NUM> may be programmed according to a specific configuration desired for a particular application. For example, the control system <NUM> may be programmed to respond to external inputs, such as reference signals, alarms, command/status signals, etc. The external inputs may originate from one or more relays or other electronic devices. The programming of the control system <NUM> may be accomplished through software configuration or firmware code that may be loaded onto the internal memory <NUM> of the control system <NUM> (e.g., via a locally or remotely located computing device <NUM>) or programmed via the user interface <NUM> of the controller <NUM>. The firmware of the control system <NUM> may respond to a set of operating parameters. The settings of the various operating parameters may determine the operating characteristics of the controller <NUM>. For example, various operating parameters may determine the speed or torque of the motor <NUM> or may determine how the controller <NUM> responds to the various external inputs. As such, the operating parameters may be used to map control variables within the controller <NUM> or to control other devices communicatively coupled to the controller <NUM>. These variables may include, for example, speed presets, feedback types and values, computational gains and variables, algorithm adjustments, status and feedback variables, programmable logic controller (PLC) control programming, and the like.

In some embodiments, the controller <NUM> may be communicatively coupled to one or more sensors <NUM> for detecting operating temperatures, voltages, currents, pressures, flow rates, and other measurable variables associated with the industrial automation system <NUM>. With feedback data from the sensors <NUM>, the control system <NUM> may keep detailed track of the various conditions under which the industrial automation system <NUM> may be operating. For example, the feedback data may include conditions such as actual motor speed, voltage, frequency, power quality, alarm conditions, etc. In some embodiments, the feedback data may be communicated back to the computing device <NUM> for additional analysis.

The computing device <NUM> may be communicatively coupled to the controller <NUM> via a wired or wireless connection. The computing device <NUM> may receive inputs from a user defining an industrial automation project using a native application running on the computing device <NUM> or using a website accessible via a browser application, a software application, or the like. The user may define the industrial automation project by writing code, interacting with a visual programming interface, inputting or selecting values via a graphical user interface, or providing some other inputs. The computing device <NUM> may send a project to the controller <NUM> for execution. Execution of the industrial automation project causes the controller <NUM> to control components (e.g., motor <NUM>) within the industrial automation system <NUM> through performance of one or more tasks and/or processes. In some applications, the controller <NUM> may be communicatively positioned behind a firewall, such that the controller <NUM> does not have communication access outside a local network and is not in communication with any devices outside the firewall, other than the computing device <NUM>. As previously discussed, the controller <NUM> may collect feedback data during execution of the project, and the feedback data may be provided back to the computing device <NUM> for analysis. Feedback data may include, for example, one or more execution times, one or more alerts, one or more error messages, one or more alarm conditions, one or more temperatures, one or more pressures, one or more flow rates, one or more motor speeds, one or more voltages, one or more frequencies, and so forth. The project may be updated via the computing device <NUM> based on the analysis of the feedback data.

The computing device <NUM> may be communicatively coupled to a cloud server <NUM> or remote server via the internet, or some other network. In one embodiment, the cloud server <NUM> is operated by the manufacturer of the controller <NUM>. However, in other embodiments, the cloud server <NUM> may be operated by a seller of the controller <NUM>, a service provider, operator of the controller <NUM>, owner of the controller <NUM>, etc. The cloud server <NUM> may be used to help customers create and/or modify projects, to help troubleshoot any problems that may arise with the controller <NUM>, or to provide other services (e.g., project analysis, enabling, restricting capabilities of the controller <NUM>, data analysis, controller firmware updates, etc.). The remote/cloud server <NUM> may be one or more servers operated by the manufacturer, seller, service provider, operator, or owner of the controller <NUM>. The remote/cloud server <NUM> may be disposed at a facility owned and/or operated by the manufacturer, seller, service provider, operator, or owner of the controller <NUM>. In other embodiments, the remote/cloud server <NUM> may be disposed in a datacenter in which the manufacturer, seller, service provider, operator, or owner of the controller <NUM> owns or rents server space. In further embodiments, the remote/cloud server <NUM> may include multiple servers operating in one or more data center to provide a cloud computing environment.

<FIG> illustrates a block diagram of example components of a computing device <NUM> that could be used as the computing device <NUM>, the cloud/remote server <NUM>, the controller <NUM>, or some other device within the system <NUM> shown in <FIG>. As used herein, a computing device <NUM> may be implemented as one or more computing systems including laptop, notebook, desktop, tablet, HMI, or workstation computers, as well as server type devices or portable, communication type devices, such as cellular telephones and/or other suitable computing devices.

As illustrated, the computing device <NUM> may include various hardware components, such as one or more processors <NUM>, one or more busses <NUM>, memory <NUM>, input structures <NUM>, a power source <NUM>, a network interface <NUM>, a user interface <NUM>, and/or other computer components useful in performing the functions described herein.

The one or more processors <NUM> may include, in certain implementations, microprocessors configured to execute instructions stored in the memory <NUM> or other accessible locations. Alternatively, the one or more processors <NUM> may be implemented as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and/or other devices designed to perform functions discussed herein in a dedicated manner. As will be appreciated, multiple processors <NUM> or processing components may be used to perform functions discussed herein in a distributed or parallel manner.

The memory <NUM> may encompass any tangible, non-transitory medium for storing data or executable routines. As shown in <FIG>, the memory <NUM> may include non-volatile memory <NUM> and volatile memory <NUM>. The non-volatile memory <NUM> is static, and may store data, program instructions, etc. Data stored in non-volatile memory <NUM> persists when the computing device <NUM> is powered down. The non-volatile memory <NUM> may include, for example, Read Only Memory (ROM), Hard Disk Drive (HDD), flash memory, including NAND flash and Solid-State Drives (SSDs), floppy disks, optical discs, magnetic tape, etc. The volatile memory <NUM> may store data and program instructions that are used by the processor <NUM> in real time. The volatile memory <NUM> fetches and stores data at high speed and is cleared when the computing device <NUM> is powered down. The volatile memory <NUM> may include, for example, Random Access Memory (RAM), including Dynamic Random Access Memory (DRAM) and Static Random Access Memory (SRAM), cache memory, etc. Although shown for convenience as a single block in <FIG>, the memory <NUM> may encompass various discrete media in the same or different physical locations. The one or more processors <NUM> may access data in the memory <NUM> via one or more busses <NUM>.

The input structures <NUM> may allow a user to input data and/or commands to the device <NUM> and may include mice, touchpads, touchscreens, keyboards, controllers, and so forth. The power source <NUM> can be any suitable source for providing power to the various components of the computing device <NUM>, including line and battery power. In the depicted example, the device <NUM> includes a network interface <NUM>. Such a network interface <NUM> may allow communication with other devices on a network using one or more communication protocols. In the depicted example, the device <NUM> includes a user interface <NUM>, such as a display that may display images or data provided by the one or more processors <NUM>. The user interface <NUM> may include, for example, a monitor, a display, and so forth. As will be appreciated, in a real-world context a processor-based system, such as the computing device <NUM> of <FIG>, may be employed to implement some or all of the present approach, such as performing the functions of the controller, the computing device <NUM>, and/or the cloud/remote server <NUM> shown in <FIG>, as well as other memory-containing devices.

Returning to <FIG>, an enterprise may wish to repurpose the controller <NUM>, one of the computing devices <NUM>, or any other component that contains a memory component <NUM> for a different application. For example, the enterprise may cease manufacturing a product produced by a production line of which the industrial automation system <NUM> is a part. Accordingly, the enterprise may wish the repurpose the industrial automation controller <NUM>, or some other component within the industrial automation system <NUM>, into a new industrial automation system <NUM> that produces a different product. However, if the industrial automation controller <NUM> was used in a government and/or military application, used in a process related to trade secrets, or otherwise stored information considered to be sensitive or confidential on its memory <NUM>, the enterprise may wish the sanitize the memory <NUM> of the industrial automation controller <NUM>, such that the sensitive or confidential information once stored on the memory <NUM> cannot be recovered. Similarly, if the enterprise wishes to transfer a computing device <NUM>, or any other device containing memory, from one employee to another, one facility to another, or otherwise return the computing device to its factory settings for some new use or purpose, the enterprise may wish to sanitize the memory of the computing device <NUM>, such that information previously stored on the memory <NUM> cannot be recovered. Such memory purges are defined by the "National Institute of Science and Technology (NIST) <NUM>-<NUM> Guidelines for Media Sanitization" published in December <NUM>. The NIST <NUM>-<NUM> Guidelines set forth three levels of media sanitization with decreasing likelihood of data recoverability-clearing, purging, and destroying.

By way of reference, media is considered cleared when a layperson would be unable to recover data previously stored on the memory. Clearing techniques may include overwriting user-addressable storage space on media with non-sensitive data using the standard read and write commands of the device. In addition, media is considered purged when retrieval of the data previously stored on the memory is infeasible using various laboratory techniques. Purging techniques may include overwriting, block erase, cryptographic erase, sanitize commands that apply media-specific techniques to bypass the abstraction of typical read/write commands, as well as techniques that may render the media unusable, such as incinerating, shredding, disintegrating, degaussing, and pulverizing. Moreover, media is considered destroyed when the media is rendered unusable and retrieval of the data previously stored on the memory is infeasible using various laboratory techniques. Destruction techniques include disintegrating, pulverizing, melting, incinerating, shredding, etc..

With the foregoing in mind, purging memory of various devices such that data previously stored on the memory cannot be recovered by laboratory techniques without rendering the device unusable has been difficult to achieve. Accordingly, rather than purging the memory of devices used in a government and/or military application, used in a process related to trade secrets, or that otherwise stored information considered to be sensitive or confidential, devices have traditionally been destroyed after being used in a single application. Though such practices may have certain advantages, such practices may be wasteful, costly, and resource intensive. Accordingly, the disclosed techniques include using a memory purging firmware package to purge the memory of a device in accordance with the NIST <NUM>-<NUM> Guidelines, while enabling the device to be restored to factory settings and repurposed for another application.

With the preceding in mind, <FIG> illustrates a schematic of a system <NUM> for providing firmware to one of more components (e.g., the industrial automation controller <NUM>, the computing device <NUM>, etc.) of an industrial automation system <NUM>. As shown, the industrial automation system <NUM> is disposed within a private network <NUM>, which may include a network address translation (NAT). The remote server <NUM> may be disposed in a public network <NUM> (e.g., the internet). Devices within the private network <NUM> may not be reachable by devices within the public network <NUM>, but devices within the public network <NUM> may be reachable by devices within the private network <NUM>. Accordingly, the computing device <NUM> may discover and establish a connection with the remote server <NUM>. This may include, for example, transmitting a discovery request to the remote server <NUM>, receiving a location and trust certificate from the remote server <NUM>, requesting a policy and an identity from the remote server <NUM>, and receiving the policy and the identity from the remote server <NUM>. The policy may define various activities performed by the computing device <NUM>, or other devices within the industrial automation system <NUM>, including how often checks for firmware updates are performed.

After a connection is established between the computing device <NUM> and the remote server <NUM>, the computing device may periodically transmit requests for firmware to the remote server <NUM> and receive firmware from the remote server <NUM>. In embodiments in which the industrial automation system <NUM> includes components that are not capable of communicating with the remote server <NUM>, or otherwise prohibited from communicating outside of the private network <NUM>, the computing device <NUM> may distribute firmware to various devices (e.g., the industrial automation controller <NUM>) within the industrial automation system <NUM>. However, in some embodiments, the industrial automation controller <NUM>, and/or other components of the industrial automation system <NUM> may be capable of direct communication with the remote server. Accordingly, in such embodiments, the industrial automation controller <NUM>, and/or other components of the industrial automation system <NUM> may go through the process of establishing a connection with the remote server <NUM> and requesting and receiving firmware from the remote server <NUM> individually. However, embodiments are also envisaged in which a first subset of components within the industrial automation system <NUM> communicate directly with the remote server <NUM> for firmware, while a second subset of components within the industrial automation system <NUM> receive firmware from the remote server <NUM> via the computing device <NUM>.

As will be described in more detail below, the remote server <NUM> may be used to provide self-deleting memory purge firmware packages to one or more devices (e.g., the industrial automation controller <NUM>) within the industrial automation system <NUM> that, when implemented, purge the memory of the device and return the device to its factory settings.

<FIG> is a swim lane diagram <NUM> illustrating communication between a device <NUM> of the industrial automation system <NUM> and the remote server <NUM> for firmware. The device <NUM> may be any device that includes memory. For example, the device <NUM> may include the controller <NUM> shown in <FIG> or the computing device <NUM> shown in <FIG>. Further, the device <NUM> may be any other component of the industrial automation system <NUM> shown in <FIG>, or any other industrial automation system, that include memory, such as a controller, a motor starter, a Motor Control Center (MCC), a server, a desktop computer, a laptop computer, a tablet, a mobile device, a phone, a wearable, an HMI, input and/or output modules, embedded computers, etc..

As shown, the private network <NUM> in which the industrial automation system <NUM> is disposed may include a NAT <NUM>, which may be used to conserve Internet Protocol (IP) addresses utilized by the network. Specifically, the NAT <NUM> connects the private network <NUM> to the public network <NUM> and translates network addresses of devices within the private network <NUM> into a legal IP address before packets are sent to the remote server <NUM> in the public network <NUM>. Accordingly, one or more, or all, devices in the private network <NUM> can share an IP address. The NAT <NUM> may enable communication between the private network <NUM> and the public network <NUM> more secure because the addresses of the devices within the private network <NUM> are hidden. As such, when an outgoing message passes through the NAT <NUM>, the address of the device <NUM> is scrubbed from the message and replaced with the IP address assigned to the private network <NUM>. Correspondingly, when an incoming message passes through the NAT <NUM>, IP address assigned to the private network <NUM> may be replaced with the address of the device <NUM> and the message routed to the appropriate device <NUM>.

At <NUM>, the device <NUM> discovers the remote server <NUM> by transmitting a discovery request to the remote server <NUM>. The discovery request may include, for example, a request for a server location and a trust certificate. At <NUM>, the remote server transmits its server location and trust certificate to the device <NUM>. At <NUM>, the device <NUM> transmits a request for a policy and an identity to the remote server <NUM>. In some embodiments, the request may include default credentials for the device <NUM> to establish a connection with the remote server <NUM>. At <NUM>, the remote server <NUM> provides its identity and a policy to the device <NUM>. The identity identifies the remote server <NUM> and may include, for example, an IP address, a URL, a Media Access Control (MAC) address, etc. The policy may define one or more operational parameters of the device <NUM> and/or various activities performed by the device <NUM>, or other devices within the industrial automation system <NUM>, including how often checks for firmware updates are performed. After a connection is established between the device <NUM> and the remote server <NUM>, the device <NUM> enters a firmware update loop <NUM>. For example, at <NUM>, the device <NUM> may periodically transmit requests for firmware to the remote server <NUM>. The frequency of the requests may be determined based on the policy received from the remote server <NUM>. At <NUM>, a firmware update, if an update is available, is transmitted from the remote server <NUM> to the device <NUM> and stored in non-volatile memory of the device <NUM>. In some embodiments, the firmware update loop <NUM> may be used to receive a self-deleting firmware package to purge memory of the device <NUM>.

<FIG> illustrates a flow chart of a process <NUM> for implementing a self-deleting memory purge firmware package on a device. Although the following description of the process <NUM> is described in a particular order and being performed by the device <NUM>, it should be noted that the process <NUM> may be performed in any suitable order by any suitable component.

At <NUM>, the device <NUM> may receive the self-deleting memory purge firmware package and store the firmware package in non-volatile memory. In some embodiments, the device <NUM> may receive the self-deleting memory purge firmware package directly from a remote server, as shown and described with regard to <FIG>. In other embodiments, the device <NUM> may receive the self-deleting memory purge firmware package from a computing device within the private network that manages the industrial automation system, as shown and described with regard to <FIG>. In further embodiments, the device <NUM> may have the self-deleting memory purge firmware package preloaded in non-volatile memory.

At block <NUM>, the device <NUM> may identify a sensitivity level associated with the device itself and/or applications running on the device <NUM>. In some embodiments, the sensitivity level may be binary. That is, the device <NUM> and/or applications running on the device <NUM> may be considered sensitive or not sensitive. In other embodiments, the sensitivity level may have multiple degrees of sensitivity. Accordingly, the varying degrees of sensitivity may correspond to the degrees of media sanitization set forth in the NIST <NUM>-<NUM> Guidelines mentioned above. However, it should be understood that the scale of sensitivity levels may or may not have three levels that correspond directly to the three degrees of media sanitization set forth in the NIST <NUM>-<NUM> Guidelines. In some embodiments, the sensitivity level for the device <NUM> and/or applications running on the device <NUM> may be set by the user. In other embodiments, the sensitivity level for the device <NUM> and/or applications running on the device <NUM> may be outside of the control of the user and set by a network administrator or automatically set based on how the device <NUM> is being used, the application running on the device <NUM>, how the applications running on the device <NUM> are being used, etc. In some embodiments, the sensitivity level of a device or an application may be determined based on the data being used or stored. For example, customer data, vendor data, data related to trade secrets, data related to processes or equipment inventories, data that is restricted or classified by the government, information classified as top secret, information classified as secret, information classified as confidential, information related to human resources for an organization, information related to medical history of one or more people, information related to military operations, information produced by or for government agencies or organizations, information related to law enforcement, information related to government intelligence, and so forth may trigger a device or an application being given a specific sensitivity level.

At block <NUM>, the device <NUM> may execute the self-deleting memory purge firmware package to purge the memory based on the sensitivity level identified in block <NUM>. Executing the self-deleting memory purge firmware package may include retrieving program code from the non-volatile memory, writing the program code to the volatile memory, and executing the program code stored in the volatile memory to purge the non-volatile memory. The purging process may involve a specific sequence of overwriting addressable locations in the non-volatile memory a sufficient number of times (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or more times) that retrieval of the data previously stored on the non-volatile memory is infeasible using laboratory techniques and the non-volatile memory is considered purged according to the NIST <NUM>-<NUM> Guidelines. One example sequence of overwriting the non-volatile memory is discussed in more detail below with regard to <FIG>. In some embodiments, the entirety of the non-volatile memory may be purged. For example, if the entire device <NUM> is classified as sensitive or if one or more applications running on the device <NUM> meet or exceed a threshold level of sensitivity, the entire non-volatile memory of the device <NUM> may be purged. Alternatively, if the sensitivity is limited to a portion of the memory or a subset of memory units within the non-volatile memory, and the sensitivity level does not meet or exceed a threshold level of sensitivity, only a portion of the non-volatile memory may be purged. At this point, the self-deleting memory purge firmware package, as well as any other data stored in non-volatile memory has been erased from the non-volatile memory such that it cannot be recovered.

At block <NUM>, the device <NUM> may execute a power cycle by disconnecting from a power source and reconnecting to the same power source. In some embodiments, the device <NUM> may cycle power to itself (e.g., by automatically shutting itself down, physically disconnecting itself from a power source, etc.). In other embodiments, the device <NUM> may cycle the power in response to an input received from the user. Powering the device <NUM> down includes clearing the volatile memory, such that the instructions related to the self-deleting memory purge firmware package, as well as any other data stored on the volatile memory have been completely erased from the memory and cannot be recovered.

At block <NUM>, the device <NUM> may restore itself to its factory settings. In some embodiments, the device <NUM> may receive a baseline software/firmware package from a remote server, as shown and described with regard to <FIG>, or from a computing device within the private network that manages the industrial automation system, as shown and described with regard to <FIG>. The baseline software/firmware package may include software or firmware with which the device comes "out of the box" pre-installed.

<FIG> illustrate an embodiment of a sequence of overwriting addressable locations in the non-volatile memory during the memory purge. As previously discussed, the memory purging process may include a specific sequence of overwriting addressable locations in the non-volatile memory a threshold number of times that retrieval of the data previously stored on the non-volatile memory is infeasible using laboratory techniques and the non-volatile memory is considered purged according to the NIST <NUM>-<NUM> Guidelines. For example, <FIG> illustrates overwriting addressable locations in the non-volatile memory with a pattern <NUM> entirely of <NUM>. <FIG> illustrates overwriting addressable locations in the non-volatile memory with a pattern <NUM> consisting entirely of <NUM>. <FIG> illustrates overwriting addressable locations in the non-volatile memory with a pattern <NUM> consisting of alternating <NUM> and <NUM>. <FIG> illustrates overwriting addressable locations in the non-volatile memory with an inverted pattern <NUM> consisting of alternating <NUM> and <NUM> relative to the pattern <NUM> shown in <FIG> illustrates overwriting addressable locations in the non-volatile memory with a first randomly generated pattern <NUM> consisting of <NUM> and <NUM>. <FIG> illustrates overwriting addressable locations in the non-volatile memory with a second randomly generated pattern <NUM> consisting of <NUM> and <NUM>. It should be understood, however, that the specific randomly generated patterns of <NUM> and <NUM> shown in <FIG> are merely examples and that other randomly generated patterns of <NUM> and <NUM> are also envisaged.

In some embodiments, the memory purging process may include overwriting addressable locations in the non-volatile memory according to the specific sequence shown in <FIG>. However, embodiments in which the sequence of overwriting addressable locations in the non-volatile memory occurs in a different order, includes few steps, additional steps, and/or repeats steps are also envisaged.

<FIG> illustrates a flow chart of an embodiment of a process <NUM> for implementing a self-deleting memory purge firmware package that has been locally stored on a device. Although the following description of the process <NUM> is described in a particular order and being performed by the device <NUM>, it should be noted that the process <NUM> may be performed in any suitable order by any suitable component.

At <NUM>, the device <NUM> receives a command to purge the memory. The command may be received via a user interface of the device, which may include a display with buttons or a touch screen. In other embodiments, the command may be received via a hardware switch or other physical input device. For example, a user may press and hold a button, such as a reset button, actuate the button according to some sequence (e.g., press button a specific number of times) or throw a reset switch. In further embodiments, the device <NUM> may receive the command via some other remote device, such as a Human Machine Interface (HMI), a mobile device, a tablet, etc..

At block <NUM>, the device <NUM> retrieves the self-deleting memory purge firmware package from non-volatile memory and copies the self-deleting memory purge firmware package to volatile memory for execution. In some embodiments, the device <NUM> may receive the self-deleting memory purge firmware package from a remote server, as shown and described with regard to <FIG>, or from a computing device within the private network that manages the industrial automation system, as shown and described with regard to <FIG>. In other embodiments, the device <NUM> may receive the self-deleting memory purge firmware package from removable media (e.g., Secure Digital (SD) card, a Universal Serial Bus (USB) drive, optical disc, floppy disk), or via a short range communication protocol (e.g., Bluetooth, near field communication, etc.) from a nearby device. In further embodiments, the device may have the self-deleting memory purge firmware package preloaded in non-volatile memory.

At block <NUM>, the device <NUM> identifies a sensitivity level associated with the device <NUM> and/or applications running on the device <NUM>. In some embodiments, the sensitivity level may be binary (e.g., sensitive or not sensitive). In other embodiments, the sensitivity level may have multiple degrees of sensitivity, which may or may not correspond to the degrees of media sanitization set forth in the NIST <NUM>-<NUM> Guidelines. The sensitivity level for the device and/or applications running on the device may be set by the user or may be outside of the control of the user (e.g., set by a network administrator or automatically set based on how the device is being used, the application running on the device, how the applications running on the device are being used, etc.).

At block <NUM>, the device <NUM> executes the self-deleting memory purge firmware package to purge the memory based on the sensitivity level identified in block <NUM>. Executing the self-deleting memory purge firmware package may include executing the program code stored in the volatile memory to purge the non-volatile memory. The purging process may involve a specific sequence of overwriting addressable locations in the non-volatile memory a threshold number of times (e.g., <NUM>) that the data previously stored on the non-volatile memory cannot be retrieved using laboratory techniques and the non-volatile memory is considered purged according to the NIST <NUM>-<NUM> Guidelines. The specific sequence of overwriting the non-volatile memory was discussed in more detail with regard to <FIG>. At this point, the self-deleting memory purge firmware package, as well as any other data stored in non-volatile memory has been erased from the non-volatile memory such that it cannot be recovered.

At block <NUM>, the device <NUM> may execute a power cycle by disconnecting from a power source and reconnecting to the same power source. Powering the device down includes clearing the volatile memory such that the instructions related to the self-deleting memory purge firmware package, as well as any other data stored on the volatile memory have been completely erased from the memory such that they cannot be recovered. At block <NUM>, the device <NUM> may restore itself to its factory settings. In some embodiments, the device may receive a baseline software/firmware package from a remote server, as shown and described with regard to <FIG>, or from a computing device within the private network that manages the industrial automation system, as shown and described with regard to <FIG>. The baseline software/firmware package may include software or firmware with which the device comes "out of the box" pre-installed.

<FIG> illustrates a flow chart of an embodiment of a process <NUM> for implementing a self-deleting memory purge firmware package received from a remote device. Although the following description of the process <NUM> is described in a particular order and being performed by the device <NUM>, it should be noted that the process <NUM> may be performed in any suitable order by any suitable component.

At <NUM>, the device <NUM> receives an input that authorizes a remote purge of the memory (e.g., "remote decommission"). The device <NUM> may receive the input via a user interface of the device, via a hardware switch, or other some physical input device. The input may include, for example, actuating an "allow remote decommission" switch, providing a Personal Identification Number (PIN), an authorization code, a password, etc..

At <NUM>, the device <NUM> receives the self-deleting memory purge firmware package and stores the self-deleting memory purge firmware package in memory. In some embodiments, the device <NUM> receives the self-deleting memory purge firmware package directly from a remote server, as shown and described with regard to <FIG>. In other embodiments, the device <NUM> receives the self-deleting memory purge firmware package from a computing device within the private network that manages the industrial automation system, as shown and described with regard to <FIG>. If not already in volatile memory, the device <NUM> retrieves the self-deleting memory purge firmware package from non-volatile memory and copies the self-deleting memory purge firmware package to volatile memory for execution. In some embodiments, the self-deleting memory purge firmware package may already be stored non-volatile memory. In such an embodiment, the device may receive a command to execute the self-deleting memory purge firmware package already stored in memory from the remote device.

In some embodiments, the device <NUM> may execute the self-deleting memory purge firmware package without receiving an input at the device authorizing the memory purge. For example, a device may be recognized as compromised and the memory remotely purged to protect data stored in memory. Recognizing that the device is compromised may include detecting an open cabinet/case, using a beacon to determine that the device has been moved outside of an authorized area, using Global Positioning System (GPS) to determine that the device has been moved outside of the authorized area, determining that the device has been hacked or otherwise remotely accessed by an unauthorized party, etc. In such embodiments, the self-deleting memory purge firmware package may be used to purge the memory of the device without authorization being provided at the device's physical location.

At block <NUM>, the device <NUM> identifies a sensitivity level associated with the device and/or applications running on the device. The sensitivity level may be binary (e.g., sensitive or not sensitive), or may have multiple degrees of sensitivity, which may or may not correspond to the degrees of media sanitization set forth in the NIST <NUM>-<NUM> Guidelines. The sensitivity level for the device and/or applications running on the device may be set by the user or may be outside of the control of the user (e.g., set by a network administrator or automatically set based on how the device is being used, the application running on the device, how the applications running on the device are being used, etc.).

At block <NUM>, the device <NUM> executes the self-deleting memory purge firmware package to purge the memory based on the sensitivity level identified in block <NUM>. Executing the self-deleting memory purge firmware package may include executing the program code stored in the volatile memory to purge the non-volatile memory. The purging process may involve a specific sequence of overwriting addressable locations in the non-volatile memory a threshold number of times that the data previously stored on the non-volatile memory cannot be retrieved using certain laboratory techniques and the non-volatile memory is considered purged according to the NIST <NUM>-<NUM> Guidelines. The specific sequence of overwriting the non-volatile memory was discussed in more detail with regard to <FIG>. At this point, the self-deleting memory purge firmware package, as well as any other data stored in non-volatile memory has been erased from the non-volatile memory such that it cannot be recovered.

At block <NUM> power to the device is cycled by powering the device down and then powering the device back up. Powering the device down includes clearing the volatile memory such that the instructions related to the self-deleting memory purge firmware package, as well as any other data stored on the volatile memory have been completely erased from the memory such that they cannot be recovered. At block <NUM>, the device is restored to its factory settings. In some embodiments, the device may receive a baseline software/firmware package from a remote server, as shown and described with regard to <FIG>, or from a computing device within the private network that manages the industrial automation system, as shown and described with regard to <FIG>. The baseline software/firmware package may include software or firmware with which the device comes "out of the box" pre-installed.

<FIG> illustrates a flow chart of an embodiment of a process <NUM> for implementing a self-deleting memory purge firmware package and generating a purge report. Although the following description of the process <NUM> is described in a particular order and being performed by the device <NUM>, it should be noted that the process <NUM> may be performed in any suitable order by any suitable component.

At <NUM>, the device <NUM> retrieves the from non-volatile memory and copies the self-deleting memory purge firmware package to volatile memory for execution. In some embodiments, the device <NUM> may receive the self-deleting memory purge firmware package from a remote server, as shown and described with regard to <FIG>, or from a computing device within the private network that manages the industrial automation system, as shown and described with regard to <FIG>. In other embodiments, the device may have the self-deleting memory purge firmware package preloaded in non-volatile memory.

At block <NUM>, the device <NUM> executes the self-deleting memory purge firmware package to purge the memory based on the sensitivity level identified in block <NUM>. Executing the self-deleting memory purge firmware package may include executing the program code stored in the volatile memory to purge the non-volatile memory. The purging process may involve a specific sequence of overwriting addressable locations in the non-volatile memory a threshold number of times that the data previously stored on the non-volatile memory cannot be retrieved using various laboratory techniques and the non-volatile memory is considered purged according to the NIST <NUM>-<NUM> Guidelines. The specific sequence of overwriting the non-volatile memory was discussed in more detail with regard to <FIG>. At this point, the self-deleting memory purge firmware package, as well as any other data stored in non-volatile memory has been erased from the non-volatile memory such that it cannot be recovered.

At block <NUM>, the device <NUM> may execute a power cycle by disconnecting from a power source and reconnecting to the same power source. Powering the device down includes clearing the volatile memory such that the instructions related to the self-deleting memory purge firmware package, as well as any other data stored on the volatile memory have been completely erased from the memory such that they cannot be recovered. At this point, the device is restored to its factory settings. In some embodiments, the device may receive a baseline software/firmware package from a remote server, as shown and described with regard to <FIG>, or from a computing device within the private network that manages the industrial automation system, as shown and described with regard to <FIG>. The baseline software/firmware package may include software or firmware with which the device comes "out of the box" pre-installed.

At <NUM>, the device may provide and/or display a hash value indicating that the memory purge has been successfully completed. In some embodiments, the hash value may be written to a cache, or some other portion of the memory. As described in more detail below, the generated hash value may be included in a purge report or used to sign a purge report to verify that the purge has been completed. The hash value may be a numeric value of a fixed length that uniquely identifies data. Generally, hash values can represent large amounts of data in significantly smaller numeric values. Accordingly, hash values are frequently used as or in conjunction with digital signatures. The hash value may be generated via a hash function or hash algorithm that utilizes managed hash classes to hash (i.e., generate hash values for) an array of bytes or a managed stream object. Hash values may also be used for verifying the integrity of data that may have been transmitted through insecure channels or may have otherwise been altered. A hash value of received data can be compared to the hash value of data before transmission to determine whether the data was altered. For example, data may be hashed at a certain time and the hash value protected in some way (e.g., encryption). The data can then be hashed again and compared to the protected value to assess the integrity of the data. If the hash values match, the data has not been altered. If the values do not match, the data has been corrupted. The hash value may be encrypted (e.g., via asymmetric cryptography using a public/private key scheme) or otherwise kept secret from untrusted parties.

At <NUM>, the device <NUM> may generate a purge report to confirm that the memory purge has been successfully completed. The purge report may be a text file, a Portable Document File (PDF), or a file in some other format. The purge report may indicate the portions of memory that were purged, the time at which the purge took place, one or more users or devices that requested and/or approved the purge, etc. In some embodiments, the purge report may be signed with the hash value to verify the authenticity of the purge report and the contents therein. For security purposes, the hash value may be encrypted using a public key. The public key may be unique to the device, the manufacturer of the device, the owner of the device, the operator of the device, etc. A private key may then be used to decrypt the encrypted hash value and verify the report signature. In other embodiments, the report may be signed using a private key. In such an embodiment, the signature may be verified using a public key.

The present disclosure includes techniques for purging memory of devices such that data previously stored in memory cannot be recovered using various laboratory techniques, thus allowing memory-containing devices to be repurposed for another application rather than being destroyed. Specifically, the memory may be purged via a self-deleting firmware package. The firmware package may be stored in non-volatile memory of the device, received from another device via a wired or wireless network connection, received via removable media (e.g., SD card, USB drive, optical disc, etc.), or some other way. The firmware package may be copied to volatile memory and executed by a processor to perform a purging process. This may include, for example, overwriting some or all of the addressable locations of the memory a number of times using specific sequences of patterns of <NUM> and <NUM> such that data stored in the memory before the purge process was started cannot be recovered by certain laboratory techniques.

In some embodiments, inputs may be provided authorizing the memory purge if the firmware package is received from a different device. In some embodiments the entirety of the non-volatile memory and volatile memory of the device are purged. In other embodiments, only portions of the non-volatile memory of the device used by specific applications having a sensitivity level above a threshold level are purged. Once the purge of the non-volatile memory is complete, power to the device is cycled, which clears the volatile memory. At such a point, the non-volatile memory and volatile memory of the device have been purged. In some embodiments, the device may receive and execute a baseline software and/or firmware package that returns the device to its original factory settings. In some embodiments, the device may generate and display a hash value indicating that the device has been purged. In other embodiments, the device may generate a report indicating that the device has been purged, which may include the generated hash value. The report may or may not be encrypted. If the report is encrypted, the report may be encrypted using a public key. In such an embodiment, a customer would decrypt the report using a provided private key. In other embodiments, the report may be signed using a private key. In such an embodiment, the signature may be verified using a public key.

Use of the disclosed techniques allows an entity to purge memory of memory-containing devices such that data previously stored in memory of the device pre-purge cannot be recovered using certain laboratory techniques. Having the capability to purge devices without previously stored data being recovery allows an entity to repurpose a device from one application to another rather than destroying the device and purchasing a new device. Repurposing devices rather than destroying and replacing devices is less costly, less resource intensive, and results in less material waste.

The specific embodiments described above have been shown by way of example, and it should be understood that these embodiments may be susceptible to various modifications and alternative forms. It should be further understood that the claims are not intended to be limited to the particular forms disclosed, but rather to cover all modifications, equivalents, and alternatives falling within the scope of this disclosure.

Claim 1:
A non-transitory computer readable medium storing instructions that, when executed by a processor (<NUM>, <NUM>) of an industrial automation component, cause the processor to perform operations comprising:
receiving (<NUM>), via the processor, a command to perform a purge of memory of a device (<NUM>);
retrieving (<NUM>), from non-volatile memory (<NUM>), via the processor, code of a purging firmware package;
storing, in volatile memory (<NUM>), via the processor, the code;
determining (<NUM>) that one or more software applications running on the industrial automation component have respective sensitivity levels above a threshold;
executing (<NUM>), via the processor, the code from the volatile memory, thereby causing the processor to purge the non-volatile memory, including overwriting a subset of the addressable locations of the non-volatile memory, wherein the subset of the addressable locations of the non-volatile memory corresponds to portions of the non-volatile memory used by the one or more software applications determined to have sensitivity levels above the threshold; and
cycling power (<NUM>) to the industrial automation component, wherein cycling the power comprises purging the volatile memory.