Least-privilege-based process control software security architecture, computer devices

Abstract

To provide a process control system software security architecture that implements the use of least privileges when executing applications and services running within a computer device.SOLUTION: The least privileges based architecture separates "service" processes from desktop applications that run on behalf of a logged-on user by partitioning the global namespace of the software system into service spaces and logged-on user namespaces, and by strictly controlling communications between the applications and services in these different namespaces using interprocess communications. The architecture uses custom accounts to assure that each service process has the least set of privileges that are needed for implementing its function regardless of the privileges associated with the calling application or user.SELECTED DRAWING: None

Description

[Technical Field]

[0001] This application relates generally to process plant computer systems, and more particularly to methods and apparatus for securing the operation of software processes within devices, such as computer devices, in a process or plant environment. [Background technology]

[0002] Process control systems, such as distributed or scalable process control systems like those used in power generation, chemical, petroleum, or other processes, typically include one or more controllers communicatively coupled to each other, to at least one host or operator workstation via a process control network, and to one or more field devices via analog, digital, or combined analog / digital buses. Field devices, which may be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, and flow sensors), perform functions within the process or plant, such as opening or closing valves, switching devices on and off, and measuring process parameters. Controllers receive signals indicative of process or plant measurements made by the field devices and / or other information associated with the field devices, use this information to implement control routines, and then generate control signals that are transmitted to the field devices via the bus to control the operation of the process or plant. Information from the field devices and controllers is typically made available to one or more applications executed by the operator workstation to enable an operator to perform any desired function related to the process or plant, such as ascertaining the current status of the plant, modifying plant operation, etc.

[0003] A process controller, typically located within a process plant environment, receives signals indicative of process measurements or process variables produced by or associated with field devices and / or other information about the field devices and uses this information to execute a controller application. The controller application implements, for example, different control modules that make process control decisions, generates control signals based on the received information, and coordinates with control modules or blocks within the field devices, such as HART® and FOUNDATION® Fieldbus field devices. The control modules within the process controller send control signals over communication lines or other signal paths to the field devices, thereby controlling the operation of the process.

[0004] Information from the field devices and process controllers is also made available via the process control network to one or more hardware devices, such as operator workstations, maintenance workstations, servers, personal computers, handheld devices, data historians, report generators, centralized databases, etc. The information communicated over the network enables an operator or maintenance personnel to perform desired functions with respect to the process and / or verify the operation of the plant. For example, this information enables an operator to change settings on process control routines, modify the operation of control modules in a process controller or smart field device, verify the current state of a process or the status of particular devices in the process plant, verify alerts generated by field devices and process controllers, simulate the operation of a process for purposes of personnel training or testing process control software, and diagnose problems or hardware faults in the process plant.

[0005] Field devices often communicate with other hardware devices over a process control network, which may be, for example, an Ethernet-based LAN. The network relays process parameters, network information, and other process control data through various network devices to various entities within the process control system. Typical network devices include network interface cards, network switches, routers, servers, firewalls, controllers, and operator workstations. Network devices typically facilitate the flow of data through the network by controlling its routing, frame rate, timeouts, and other network parameters, but do not modify the process data itself. As process control networks grow in size and complexity, the number and types of network devices correspondingly increase. As a result of system and network growth, security and management can become increasingly difficult. For example, each network device may include one or more communication ports that provide access points or ports for physically interconnecting process control system components and other network devices with each other over the network. However, some of these ports or connections may be used to connect control devices to publicly accessible networks, such as the Internet, and to connect portable memory devices to control system devices. Thus, open ports on a device can become access points for network expansion by adding other devices, or can allow entities, malicious or not, to access the network and initiate undesirable and potentially harmful network traffic or introduce malware (e.g., malicious programs, spy or data collection programs, adware, or other unwanted and potentially dangerous software) that can cause serious problems within the plant control system.Effectively monitoring or controlling access to every port on devices in a network that controls communications across a complex process control system quickly becomes impractical as the number of network devices and associated access points increases.

[0006] Similarly, in a typical industrial control system, workstations / servers are strategically placed between the plant network and the embedded devices (e.g., controllers, PLCs, RTUs) that perform control and data acquisition functions. Therefore, a primary security objective of these workstations / servers is to prevent malware from entering the control system and detrimentally affecting the embedded devices, as well as to prevent malware from modifying configuration and historical data stored in the plant database. While numerous security features, such as “antivirus” software and “whitelisting,” can be used to address this goal, these security features are typically insufficient. For example, antivirus software cannot protect against “zero-day” viruses, and whitelisting only prevents unauthorized applications from running. Furthermore, because these security features have the potential to hinder the activities of plant operators, some of these features are too intrusive to be operationally practical in process control systems.

[0007] In general, malware, such as that at the heart of a zero-day attack, is typically introduced into a control system in a particular device via an external memory device (such as a removable flash drive) or a communications connection by the operation of an application or service with privileges or authorization to access these memory devices, network ports, or direct data links. (For purposes of this patent, communications connections include connections made via communications network connections or direct data links, such as modem connections.) The malware can then be propagated to other devices (e.g., via communications or portable memory devices) and / or executed within the device using the security privileges of the application or service it infects. Furthermore, malware may persist locally, allowing itself to run again after a reboot. In some cases, malware may escalate the privileges of the host (e.g., the infected application or service) by using the privileges of the account under which the application or service is running, allowing the malware to perform actions or behaviors within the process control device or system that require higher privileges and are therefore typically more harmful to control system operation. In any event, zero-day attacks that infect applications that are already running present a major problem in process control systems because there are no good techniques to prevent these types of attacks. However, these attacks can have serious and potentially destructive or even fatal effects within a process plant if they disrupt the ongoing operation of the plant control system. Summary of the Invention

[0008] A process control system uses a new set of security features or software security architecture that is more effective at preventing zero-day or other types of malware attacks. Generally speaking, the new security features or architecture implements the use of what is referred to herein as "least privilege" when executing applications and services running within any particular control system device, such as within a workstation, server, database, controller, or field device, to reduce the impact of malware that may infect a workstation, server, or other device. The term "privilege" herein includes both operating system privileges / rights and access control permissions. For example, a user may be granted the right (privilege) to log on remotely or impersonate another user, and may also be granted access (permission) to read / write / execute certain files.

[0009] In general, a least-privilege-based security feature or architecture separates "service" processes from desktop applications running on behalf of logged-on users (local or remote), for example, by partitioning the global namespace of a device (e.g., controller, workstation, server, etc.) into a service namespace and, if present, into the logged-on user's namespace (e.g., within a desktop application). The architecture then tightly controls communication between processes (e.g., applications and services) in these different namespaces using inter-process communication to prevent a compromised service or application from being able to directly infect or subvert other services or applications. Specifically, the new security architecture uses this namespace partitioning to prevent desktop applications from directly accessing objects in a service namespace and vice versa.

[0010] Furthermore, new security architectures restrict the privileges granted to services and desktop applications in a manner that limits or reduces the ability of a compromised service or application to adversely affect or infect other services or applications. Typically, the security architecture limits the operating system privileges of a service, application, or other process to a specified subset of the privileges granted to the account under which the service, application, or other process runs or is spawned, limits the privileges of applications started by a logged-on user to the subset of privileges associated with that user, and prevents privilege escalation through desktop applications (running under the logged-on user). In some cases, software security systems enforce the restriction that all access to communication ports or external media ports (e.g., to removable storage devices connected through external media ports such as USB ports) must be through a service with limited privileges (and never by a desktop application), where the limited service privileges prevent the service from writing to local data storage (e.g., disk), communicating through other communication network ports or removable media ports, or operating with administrative privileges. If a service is infected in this manner, the infection will be benign because it will be unable to store itself on the local disk or other memory, unable to perform administrative functions, unable to access the desktop, unable to be propagated over a communications network if the infection comes from a removable storage device via an external media port, and unable to be stored on a removable storage device via an external media port or propagated to another communications connection if the infection comes from a communications connection via a communications port.

[0011] Thus, the new security architecture uses access controls to enforce which user accounts and which processes (services or desktops) are authorized to access securable objects through calls to the operating system and its subsystems, and includes mechanisms to prevent lower privilege processes from injecting code into higher privilege processes. In doing so, the security architecture includes or uses accounts commonly referred to as "groups," which allow user accounts and service accounts to belong to or inherit from other group accounts.

[0012] Because these security features, alone or in combination, make it difficult, if not impossible, for malware to be imported into a system through the operation of a desktop application accessing a network connection or a removable / portable storage media connection (such as a USB port), the combination of one or more of these security features results in a more secure software environment within a process control system or process plant that is less susceptible to virus attacks, such as zero-day virus attacks, and other malware. These security features also limit the ability of malware to be imported into internal data storage devices via a network or external device, to escalate the privileges of a service to allow the malware to access devices, storage media, or processes not needed by the application requiring the service, and the like.

[0013] Therefore, using these features, the new software architecture design compartmentalizes (isolates) services and desktop applications running on process control automation system workstations and on servers for the purpose of reducing their malware attack profile or surface area. Furthermore, if a service or another process spawned by the service becomes infected, it will no longer have the privileges necessary to do anything it does not already do, and it will no longer have permission to access resources it does not directly need. Furthermore, if a desktop application becomes infected, it will no longer have direct access to privileged functions in the operating system, nor will it be able to write directly to removable storage devices connected through the network or external media ports. Instead, the desktop application will have to require, on its behalf, that actions be taken by the service and the processes it spawns that are designed to enable and provide additional levels of access control to privileged functions and resources. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 is an example block diagram of a process plant having a distributed process control system and a process automation network including one or more operator and maintenance workstations, servers, controllers, field devices, and other network devices configured to implement a least-privilege based software security architecture and the functionality described herein. [Figure 2] FIG. 1 is an example block diagram of a workstation / server / controller device within a process control plant illustrating various namespaces and security restrictions implemented to implement improved security features with respect to applications, services, and other processes occurring within a process control software architecture. [Figure 3]1 illustrates a diagram of accounts, including group accounts and custom accounts, that define sets of privileges associated with various different applications and services in accordance with the least-privilege software security architecture described herein. [Figure 4] 4 is an exemplary architecture diagram illustrating the software and hardware components of one of the workstations of the system of FIG. 2, illustrating the communication connections between various services and applications using the accounts of FIG. 3. DETAILED DESCRIPTION OF THE INVENTION

[0015] 1 is a schematic diagram of a process control system or process automation system 100 disposed within, for example, a process plant, in which various computing devices may receive various software security features to enhance software security and facilitate computer / network management and maintenance. More specifically, the process control system 100 includes one or more process controllers 110 and one or more process plant databases 112 (e.g., data historians) communicatively connected to one or more host workstations or computers 120-122 (which may be any type of personal computer, workstation, server, etc.) via a process control communication network 130. The controllers 110 and databases 112 may connect to a communication network or bus 130 (which may be, for example, an Ethernet communication network) via one or more network interface cards 132. Furthermore, the controllers 110 may connect to field devices 140, 143, and 154 within the process plant or control system via input / output (I / O) cards 142. Database 112 may include one or more data historians, which may be any desired type of data collection unit or memory device having any desired type of memory and any desired or known software, hardware, or firmware for storing data. Additionally, database 112 may be separate from or part of one or more of workstations or servers 120-122. Controller 110, which may be, for example, a DeltaV™ controller sold by Fisher Rosemount Systems Inc., is communicatively connected to host computers 120-122 by one or more network cards or devices 132, for example, via an Ethernet connection 130 or any other desired communications network.Network device 132 may include one or more of a network interface card, a network switch, a router, a firewall, or any other device that facilitates data transmission over network 130 without altering the underlying data.

[0016] 1 , the server 122 is connected to various network devices, which may be physically located in any part of the communication or process control network and within any part of the process plant, and may include any of the security features described herein. In this example, the communication network 130 is typically a closed local area network (LAN) to which only devices included in the control system are connected and may be implemented using wired or wireless technology. Additionally, the controller 110 is communicatively connected to the field devices 140 using any desired hardware and software associated with, for example, a standard 4-20 mA device protocol, an Ethernet protocol, and / or any smart communication protocol, such as FOUNDATION® Fieldbus protocol (Fieldbus), HART® protocol, WirelessHART® protocol, Profibus protocol, CAN protocol, etc.

[0017] Field devices 140, 143, and 154 can be any type of device, such as sensors, valves, transmitters, positioners, etc., while I / O card 142 can be any type of I / O device that conforms to any desired communication or controller protocol. In the embodiment illustrated in FIG. 1 , field device 140 is a HART or 4-20 mA device that communicates over a standard HART or analog 4-20 mA line 141 using a modem or I / O card 142, while field device 143 is a smart device, such as a FOUNDATION® Fieldbus field device, that communicates using Fieldbus protocol communication over a digital bus 145 or I / O network with I / O card 142. Of course, field devices 140 and 143 can conform to any other desired standard(s) or protocol, including any standards or protocols developed in the future. Additionally, field devices 140 and 143 may be wirelessly connected to controller 110 via any desired wireless communication protocol, such as the WirelessHART® protocol.

[0018] Additionally, one or more of the field devices 154 may be connected to the digital bus 145 via a dedicated network device, such as a gateway 153. For example, the field devices 154 may only understand HART commands, while the I / O network 145 may implement the PROFIBUS protocol. At this end, the gateway 153 may provide bidirectional PROFIBUS / HART translation.

[0019] The controller 110, which may be one or more of many distributed controllers within a plant having one or more processors therein, implements or oversees one or more process control routines. The routines may include one or more control loops stored within or associated with the controller 110. The controller 110 also communicates with devices 140, 143, and 154, as well as with host computers and servers 120-122 and data historians or other databases 112 and associated network devices 132 through a network 130 that control the process in any desired manner. It should be noted that any control routine or element described herein may have portions implemented or performed by different controllers or other devices, if desired. Similarly, a control routine or element described herein as being implemented within the process control system 100 may take any form, including software, firmware, hardware, etc. For purposes of this description, a process control element may be any portion or part of a process control system, including, for example, a routine, block, or module stored on any computer-readable medium. A control routine may be any portion of a control procedure, such as a module, subroutine, portion of a subroutine (e.g., a line of code), or the like, but may be implemented in any desired software format, for example, using ladder logic, sequential function charts, functional block diagrams, object-oriented programming, or any other software programming language or design paradigm. Similarly, a control routine may be hard-coded, for example, into one or more EPROMs, EEPROMs, application-specific integrated circuits (ASICs), or any other hardware or firmware elements. Furthermore, a control routine may be designed using any design tool, including graphical design tools or any other type of software / hardware / firmware programming or design tool. Thus, the controller 110 may be configured to implement a control strategy or control routine in any desired manner.

[0020] Still further, as illustrated in FIG. 1, a further communication network 160 is connected to the process control system server 122 and the workstations 120 and 121 to enable the server 122 and the workstations 120 and 121 to connect to plant information technology systems, business systems, or other network systems within the plant.

[0021] Generally speaking, the workstations and servers 120-122 and other devices in the network of Figure 1 implement what is referred to herein as a least-privilege-based security architecture that (1) operates to isolate or separate services and other lower-level processes executing within the various computing devices of Figure 1, such as workstations, servers, databases, and controllers, from desktop applications in various ways, and (2) limits the privileges of services and desktop applications to only those required by these processes to implement their functionality. This least-privilege-based security architecture helps prevent malware from being imported into, instantiated within, or executed within a process control system device. Generally, desktop applications and services or other processes within any computing device can be isolated by partitioning the global namespace of each computing device of the process control system into one or more service namespaces and one or more user (desktop application) namespaces. This division prevents desktop applications from gaining direct access to objects (e.g., mutexes) defined within the namespace used by a service, and prevents services from gaining direct access to objects (e.g., within the desktop environment) defined for the desktop namespace used by a desktop application. Instead, all communication between the various desktop applications and services implemented by the operating system must be via well-known and reliable inter-process communication (IPC), which provides a reliable message-based communication structure that confines communication to the device / workstation / server on which the communication is implemented, thereby preventing or reducing the ability of one application or service to corrupt, infect, or interfere with the operation (e.g., memory space) of other applications and services.In this manner, malware introduced via a desktop application cannot easily be imported into a service or other lower level process, and vice versa.

[0022] Furthermore, the security-based architecture described herein limits / restricts the ability of malware from being introduced to or expanding within a system by limiting the privileges granted to each service and desktop application to a specified subset of privileges, such as the subset of privileges granted to the logged-on user account under which the service or application runs or is invoked. For example, while services that normally run under an administrator account typically have all of administrator's privileges, the new secured software architecture creates or runs some or all of the services with only the specific privileges needed by the service to perform the function it is designed to perform, without all administrator privileges. Furthermore, services with communication network access (via a communication network port) or access to removable data storage devices via a removable memory port (e.g., a USB port) run under an account with very limited privileges, where these services do not have administrative privileges, do not have local disk (i.e., local memory) storage (write) privileges, and cannot communicate directly through the other of the communication network port or the removable memory port. This feature prevents, or at least reduces, the ability of malware to use a service that is invoked by a user with higher privileges and have access to devices or functions not needed by the service itself, thus limiting the ability of malware to infect other devices or execute higher privileged commands or services solely because of the logged on user account under which the service is run or invoked.

[0023] Similarly, this security feature can automatically limit privileges for applications, such as desktop applications started by a logged-on user, to prevent privilege escalation. In some cases, the security architecture prevents any and all desktop applications from being able to be elevated in privileges, so that a request for elevated privileges from the user indicates that the application is infected. In general, privilege escalation by desktop applications (running under a logged-on user account) currently typically requires the approval of an authorized user to perform operations requiring elevation. Newer operating systems typically enhance this feature by granting only standard user privileges (no elevated / administrative privileges) to applications started by logged-on users, including administrators, and by requiring elevation in privileges to be specifically authorized by the user. The new architecture can prevent desktop application privilege escalation in all events, thereby providing another level of security that prevents malware's ability to automatically escalate privileges within a system and use this elevation to infect additional processes or devices.

[0024] Similarly, the secured architecture described herein may also use access controls to enforce which user accounts and which processes (services or desktops) are authorized to access securable objects through calls to the operating system and its subsystems (e.g., files, mutexes, events), may use mechanisms to prevent lower-privilege processes from injecting code into higher-privilege processes, and may use group-based accounts, commonly referred to as "groups," to enable privilege / permission inheritance. For example, user A may belong to group B, which belongs to group C. User A therefore inherits privileges and permissions from both B and C. However, while these privileges are shared or portable among logged-on user accounts, these privileges are not propagated to services or processes that receive messages from applications running under these accounts, which prevents services and processes (such as those instantiated by the operating system in response to messages received from these applications) from being able to have elevated privileges. Thus, typically, privileges for services and processes spawned or executed by the operating system are defined separately from the privileges defined for the logged-on user account, so that services and processes (and often applications) running under accounts with higher privileges are limited to the subset of privileges required for the intended operation of the service or application or other process, i.e., least privileges.

[0025] Generally, with reference to FIG. 2, the security features and secured architecture described herein are illustrated as being implemented in a server or workstation or controller, such as any of the devices of FIG. 1. However, it will be understood that the security concepts described herein may be implemented in the same or similar manner in other types of computing devices or machines, such as workstations, database servers, etc. More specifically, FIG. 2 illustrates a workstation / server / controller 220 connected to zero or more networks / data links 230, one of which may be, for example, network 130 of FIG. 1. Furthermore, in this case, the server / workstation 220 is connected to one or more local data memories 235, which are illustrated in FIG. 2 as being internal to or directly connected to the workstation / server / controller 220. Additionally, the workstation / server / controller 220 may include or be connected to a user interface or display device 237 and includes zero or more removable media ports 239. Removable media port(s) 239, through which external or removable memory devices may be connected to device 220, may include or be any type of memory access port(s), including a USB port, a standard or proprietary connection to a CD or DVD drive, an external hard drive, a flash or solid-state memory drive, a magnetic drive, etc. As illustrated in Figure 2, data, programs, etc. may be provided to or exported from workstation / server / controller 220 via one of ports 239 via a removable or portable memory device, such as a USB flash drive 240, a DVD or CD 241, etc.

[0026] Additionally, the workstation / server / controller 220 includes zero or more communication ports 245, each of which connects to a communication network / data link or communication interface, which may be a wired or wireless connection network, such as an Ethernet network, a Wifi network, an Internet Protocol network, or any other local or wide area network or data link.

[0027] As further illustrated in Figure 2, workstation / server / controller 220 is partitioned into two types of namespaces, including service namespace 250 and zero or more logged-on user namespaces (illustrated in Figure 2 as a single logged-on user namespace 252). Of course, there may be a different logged-on user namespace (also referred to herein as a user namespace) for each different one of multiple users logged into workstation / server / controller 220, and some devices, such as servers, may not have a logged-on user namespace. As further depicted in Figure 2, a set of desktop applications 258 reside and run within user namespace 252, while services 260 reside and run within service namespace 250. Generally speaking, desktop applications 258 are processes that run within a user namespace, while service processes, referred to herein simply as services, are processes that run independently of a logged-on user and are typically spawned or run by the operating system (or one of its agents, such as the Windows Service Control Manager) in response to a configuration setting, a call to the operating system, or a request message (e.g., a Windows COM / DCOM message) sent to it. Isolated processes are independent processes that run within the same namespace as the process that starts them (e.g., a service process or a desktop application process). For example, an isolated process may be started within the service namespace and may be a process that implements a USB or other local data storage device reading or its interface with a communications network in the manner described herein. While services 260 are typically started automatically, these processes may be started in response to a request message sent by a user process or another service.However, as described in more detail herein, services 260 always run under a designated account independent of the user account of the process that starts them and independent of how they are started, while isolated processes run or execute under the account of the process that starts them (e.g., a service or desktop application). In particular, services 260 in FIG. 2 may include zero or more service namespace processes with network access 262 (via one of communication ports 245), service namespace processes with access to removable storage devices 264 via external media port 239, and other service namespace processes 266 that have neither portable or local memory access nor communication network access. Furthermore, local data storage device or memory 235 contains various types of files or folders, including service files or folders 270 created and used by service namespace processes 260, and desktop files or folders 272 created and used by logged-on user namespace processes, e.g., by desktop application 258.

[0028] As can be seen from Figure 2, the workstation / server / controller computing environment is thus separated into multiple subspaces with different namespace rules associated with separate namespaces for each logged-on user (or group of users) and services (separate processes created by the services), with these rules enforced by the operating system and its configuration data. The partitioning of the global computing environment namespace into service and logged-on user (desktop application) namespaces prevents desktop applications from directly accessing objects (e.g., mutexes) defined within the service namespace, and prevents service namespace processes from directly accessing objects (e.g., the desktop) defined for the logged-on user namespace (used by desktop applications). In this manner, services and desktop applications must (or are forced to) communicate with or through each other to reach objects created in each of these different namespaces. This feature prevents malware that may reside in a service or desktop application in one environment from creating or using objects in the other namespace without passing through the respective service or application in the other namespace, which may generally limit the ability of malware to corrupt other services or applications. This feature, for example, limits the ability of malware to create or infect objects in other environments, which limits the ability of malware to be established in a control system and propagate thereto, for example, via communications network 230.

[0029] The secured software architecture described above operates in various ways to increase the overall security of the workstations / servers / controllers 220 used within a plant or other industrial automation system. This security mechanism, which applies generally to all computing devices or machines within a control system, including machines running processes / applications developed by third parties (as well as processes / applications developed and provided by the control system vendor), is structured to implement a number of rules or features.

[0030] Some of the rules described herein and enforced by the configuration of the workstation / server / controller 220 operating system apply to all processes that require elevated privileges, network access, local disk write access, or have access to portable or removable memory devices (e.g., USB memory devices, smartphones, CD / DVD drives). These processes include, for example, processes 262 and 264 in FIG. 2. Specifically, these processes (1) run as or are spawned by a service, (2) run under a custom (standard / non-default) account that belongs to a custom group / role, (3) are granted access to only the resources they need, (4) are explicitly denied access to resources not explicitly required, (5) are granted only the privileges they require to operate, (6) do not have impersonation privileges, which allow a process running under another account to change accounts to this custom account, and (7) do not have delegation privileges, which grant another running process permission to run under this custom account. Furthermore, if these processes have network access or access to portable or removable memory devices, they do not have elevated privileges or the ability to write to local memory storage (eg, disk).

[0031] Similarly, these processes communicate with each other via trusted local inter-process communication (e.g., WCF named pipes, COM, etc.), with the exception that processes requiring network access are not allowed to communicate directly with processes that have access to the portable or removable memory device, and vice versa. This exception, illustrated in Figure 2 by line 290, is implemented to protect against the transfer of malware read from the portable memory device to the communications network, as well as the storage of malware received from the communications network onto the portable or removable memory device.

[0032] Furthermore, as illustrated by dotted line 291 in Figure 2, none of the processes 260 (e.g., processes 262, 264, 266) have direct access to desktop namespace 252 or objects within desktop namespace 252. As a result, these processes provide services (and particularly privileged services) to desktop application 258 only via trusted local inter-process communication 292, illustrated in Figure 2 by the line going between service 260 and desktop application 258.

[0033] Additionally, all processes (e.g., processes 262 and 264 in FIG. 2) that require network access or have access to portable or removable memory devices (1) run or operate under accounts that do not have command shell access, (2) do not have access to programs that change the security configuration (policy settings and accounts) of workstation / server / controller 220, and (3) are restricted from performing file system writes, this characteristic being illustrated by dotted line 294 in FIG. 2. As a result, only services 266 that do not have network access (e.g., via port 245) or portable or removable memory access (e.g., via port 239) can perform file system writes to data files 270 in database 235.

[0034] Furthermore, there are various security features implemented within the desktop environment 252. Specifically, all desktop applications, also referred to as interactive applications / processes, run or execute without elevated privileges, regardless of which user or logon account is used to start or invoke these applications or processes. Thus, if a user with administrative privileges starts a desktop application, the desktop application still runs with limited operating system privileges equivalent to a standard user, independent of the privileges of the invoking user. Furthermore, as noted above, the desktop application 258 cannot directly access the communications network 230 but instead must communicate via inter-process communication with a service 262 in the service namespace 250 that provides communications network access. Similarly, the desktop application 258 cannot directly access the portable memory devices 240, 241 but instead must communicate (via inter-process communication) with a service 264 that provides access to these devices. Additionally, desktop applications 258 are restricted from accessing directories and files owned by the system, or else could jeopardize system performance / operation if infected. Thus, as illustrated by line 296 in Figure 2, desktop applications 258 can write to desktop folders and files 272 but cannot write to services folders and files 270. Furthermore, desktop applications 258 are designed to never require elevated privileges and cannot be elevated, independent of the invoking user privileges. Similarly, desktop applications 258 can never impersonate another user and must communicate with each other via reliable local inter-process communication.

[0035] Furthermore, all user identities are passed between the services and processes 260 and the desktop application 258 via digitally signed identity claims that follow or flow with communications, enabling verification of process control system authorizations through various processes and network devices. For example, a process control system operator may make a request (via a desktop application) to write a parameter (e.g., a setpoint) into a process control device such as a controller. This request may require various services to be invoked or created during the process of sending the request over a communications network to the process control device that will implement the write. The user identity claim flows along with the request through the various processes used to create and forward the request, through various machines in the process control network, so that the process control device implementing the change can verify that the request is from a user with the appropriate authorization to make the change and can therefore review and log the change close to the process where the write operation occurs. This feature ensures that the human user performing the action is precisely and accurately identified without the use of impersonation and / or delegation. Additionally, this feature allows desktop applications, or processes started by desktop applications, such as process control applications, to be started in the context of the logged-on user and continue to operate through shift changes without having to be resumed by another user because the shift change does not require the logged-on user to log off. Instead, the new shift operator identifies themselves to the process control system without having to log on to the operating system. In this manner, all desktop applications can run with the privileges of the logged-on user, and therefore it does not matter which operator starts a desktop application, as long as the new operator identifies themselves when using that application so that the appropriate identity claim can flow with the process operation request.Furthermore, without this mechanism, a service / process / application may only be able to identify the user with the account under which it runs or from which it is invoked. This feature is also important in control systems, since the current user of the operator console may not be the logged-on user. This restriction eliminates the risk of having a stolen logged-on user's identity used in determining operating system privileges and access control permissions, which are used to determine access control permissions used to provide access to control system resources (e.g., parameters and alerts).

[0036] One way to implement the security features described above with respect to FIG. 2 is to use a more restrictive method of defining the privileges and permissions granted to various applications and services within a standard, open-architecture, operating-system-based control system. In particular, currently, privileges and permissions are typically defined for users on a per-user basis, so that some users have more privileges and permissions than other users. In this architecture, applications (e.g., desktop applications and the processes they start) are generally granted the privileges and permissions of the logged-on user account from which these applications or processes are started or invoked. Meanwhile, many services (e.g., processes spawned based on configuration settings or in response to calls from applications or user requests to the operating system to start them or to process incoming messages) are granted the privileges of the operating system account under which they are configured to run. As a result, all privileges and permissions or services are controlled by accounts within these systems. More specifically, desktop applications are always started under the logged-on user's account, while services and processes are always started under the account configured for them, and processes started by other processes are always started using the account under which the process that starts them is running. Thus, in many cases, the service will run under the standard OS service account or under the user account.

[0037] In contrast, the secured architecture of FIG. 2 defines privileges and permissions for services separately from the privileges and permissions defined for logon user accounts, thereby preventing a service from running under a user account with interactive logon privileges. That is, a service may always run under a specific service account that does not have interactive logon privileges. Specifically, the secured architecture of FIG. 2 may define what are referred to herein as custom service accounts with different or limited sets of privileges and permissions, and each of the services 260 of FIG. 2 may be assigned to one or more of these custom service accounts for purposes of assigning privileges and permissions to those services. Each service is assigned to a custom service account with the minimum set of privileges required by that service. A service should not be assigned to a custom service account with more privileges than required for the operation of that service. However, to reduce the proliferation of custom service accounts, a service can run under a custom service account with more privileges than it needs only if it is configured with a restricted service set that limits the privileges inherited from the custom account to only those it requires. In some cases, such as those involving services that access communication ports or external media ports, services may be assigned to least-privilege accounts, with the further restriction that these services cannot write to local data storage (disk). Desktop applications, on the other hand, run with the privileges of the invoking user, but should always be started with limited standard user privileges and should be elevated only when they require elevation and only with the user's approval. If the user does not have the necessary privileges, a user with those privileges should be required to approve the elevation. In this manner, services and applications can have a limited set of privileges, limiting the ability of malware to infect control systems using this architecture.

[0038] Generally speaking, custom service accounts (and the privileges of these accounts) can be defined and then assigned to services, which can further restrict the custom account privileges so that the service has only the privileges or permissions it needs to perform the tasks or functions for which it is designed.

[0039] FIG. 3 illustrates a block diagram 300 of an example interrelationship or association of a user account 306 that authorizes user logon and a custom service account 310 that can be used to configure or provide operating system privileges and permissions to services 312 and desktop applications 314, as well as other processes, separate or distinct from the permissions and privileges associated with the process control system permissions defined for the user logon account.

[0040] As illustrated in FIG. 3 , a set of user accounts 306 is established, and each user account 306 may belong to one or more of the group accounts 302, as indicated by the dotted lines between the user accounts 306 and the group accounts 302. In this manner, each user account 306 may inherit the operating system privileges and permissions of any group accounts 302 with which it is associated or to which it belongs, and pass these privileges / permissions to desktop applications when initiated by the associated logged-on user. As also illustrated in FIG. 3 , a user account 306 may belong to multiple group accounts 302 and thus inherit their privileges and permissions, but it may also belong to and inherit from other group accounts 302. Similarly, as illustrated in FIG. 3 , a set of custom service accounts 310 is also established, each having various different operating system privileges and permissions (including access permissions), such as communication privileges, read / write privileges, access privileges, etc., within the operating system to perform actions. Each custom service account 310 may belong to one or more group accounts 302 and thus inherit their privileges. Each of the various services 312 and processes started by them within the computing device is assigned to one (or possibly more than one) of the custom service accounts 310 and inherits or has the operating system privileges of the custom service account(s) 310 to which those services 312 belong. Typically, the operating system privileges and permissions provided to each custom service account 310 are defined separate and apart from the user account 306.Specifically, the privileges and permissions of the custom account 310 should be specifically tailored (restricted) for the services 312 and processes (e.g., isolated processes, subordinate processes) that they start, and should have only the operating system privileges and permissions necessary for the services 312 and processes that it starts to run to perform their intended functions, unless that service / process is configured to further restrict the privileges inherited from the custom service account.

[0041] With the use of user accounts 306 and custom service accounts 310, service namespace processes 312 (i.e., the running namespace within which services and the processes they start run) and desktop namespace processes 314 (i.e., the running namespace within which desktop applications and the processes they start run) can be associated with different custom accounts 310 or user accounts 306 so that a service invoked by a desktop application can run with different privileges than the invoking desktop application. The phrase "invoked by a desktop application" refers to the receipt by a service of a remote procedure call message sent by the desktop application.

[0042] Furthermore, as illustrated in FIG. 3 , at a higher level, a set of group accounts 302 can be established to define a specific set of operating system privileges and permissions (including access permissions). A group account can be associated with zero or more custom service or user accounts within a computing device or within an entire process control plant or system (e.g., using Active Directory). Each group account 302 can contain a specific set of operating system privileges and permissions (including access permissions) that can be inherited by other group accounts, custom service accounts, and / or user accounts that are members of the group account 306. The inheritance is achieved by making these accounts members of the group account. Thus, a custom account 312 and a user account 306 can belong to the same group 302 and therefore inherit the same operating system privileges and permissions. Group accounts 302 are therefore distinct from roles typically used in process control systems to define process control (as opposed to operating system) privileges and permissions. Process control roles (as opposed to operating system groups) tend to include groups of individuals (operators, configuration engineers, technicians, etc.) who are responsible for specific areas or functions of the plant. While such different roles may define different process control system privileges and permissions for these individuals, people assigned to different roles often run under the same user logon account and have the same set of operating system privileges and permissions, but different process control system privileges and permissions. As can be appreciated, in any event, the group account 302 defines the operating system privileges and permissions that can be assumed by the custom service account 312 used to run service namespace processes and / or user account 306 and desktop namespace processes started by those logged-on users.

[0043] Thus, FIG. 3 illustrates the grouping of various services 312 and applications 314 under various accounts 302, 306, and 310, which are used to assign operating system privileges to the services and applications. The custom service account 310 illustrated in FIG. 3 is used only for the service process 312 and other processes within the service namespace, while the user account 306 is used only for processes (e.g., applications 314) within the desktop namespace. Typically, all of the processes (e.g., desktop applications 314) within the desktop namespace start with the privileges of a “standard user” account 306A (a least-privileged account), which does not include administrative privileges. Furthermore, the custom accounts 310 are defined with only the additional privileges they require. However, as illustrated in FIG. 3, two or more services 312 may run under the same custom service account 310, and if the services 312 do not require all of the custom service account privileges, they may be individually denied some of those privileges. However, for services with communication port or external media port (e.g., USB port) access, the services are run under a custom service account without elevated (e.g., administrator) privileges and with the further restriction that these services cannot write to local (internal) data storage or disk. Here, it is understood that local or internal data storage is intended to mean data storage connected in a relatively permanent manner within a computing device, and is not inherently portable or easily removable, and therefore is not connected via an external media access port. Local memory or data storage may generally include an internal disk drive or internal random access memory.

[0044] Thus, as can be understood from the description provided above, operating system privileges, including access permissions, are granted to processes (e.g., services or desktop applications) completely independent of the access controls used to grant / deny user access to process control system objects (e.g., set points, temperature and pressure measurements, and alarm limits). Access to process control objects requires that a separate user ID be passed with the request to enable the process control device to verify process control system permissions, because the operating system, which enforces access permissions and operating system privileges, knows nothing about the control system objects. As is known, control systems typically have a separate user manager that defines what each control system user can access within the control system, and user ID claims are provided to enable this separate user manager to operate properly.

[0045] In any event, using this architecture, the permissions and privileges that a user has to access process control objects, perform actions within a process plant, etc. are not related to the privileges and permissions of services and applications running under the custom service account or user logon account. This feature reduces or eliminates the ability of an infected process to use operating system privileges and permissions inherited from the custom service account or user account under which the infected process is running to access or disrupt the execution of process control objects.

[0046] As further illustrated in FIG. 3 , the execution engine 320 (e.g., operating system execution engine) of a computer on which a process (e.g., a service or application or a process started by a service or application) is to run grants privileges for a service 312 or application 314 or the processes they start using the following rules: Processes started directly by a logged-on user get the standard set of user privileges and permissions associated with a standard user account, even if the user has elevated privileges (i.e., is an administrator). Services started by the operating system get the privileges and permissions of the custom service account to which they belong, reduced by any restrictions configured for the service. Processes started by a process get the current set of privileges and permissions of the process that starts them. This organization allows each process (e.g., each service 312 or application 314 or the processes it starts) to run or execute with the minimum set of privileges required to perform the process's specific function. This functionality therefore limits the ability of malware that infects a service 312 or application 314 or a process started by them to be able to take actions (e.g., have operating system privileges or permissions) that the service 312 or application 314 does not need for its normal operation, thereby limiting the malware's ability to operate within the computing device or propagate to other process control system devices or other computing devices within a process control system network. Still further, the execution engine 320 may not allow or prevent privilege escalation within the desktop application 314 or service 312 to prevent malware from being able to subvert this operating system privilege structure.

[0047] 4 illustrates a schematic diagram of a computer system 400 that may implement the rules or configuration features described above with respect to increasing the security of a computer device or plant network to limit the spread of or potential infection by malware. Specifically, as illustrated in FIG. 4, computer system diagram 400 is divided into a hardware system 402 (below solid line 403) having various hardware components and a software system 404 (above solid line 403) having various software / firmware components. It will be understood that the software / firmware components of software system 404 are implemented in one or more computer processors and memory devices (not shown in FIG. 4) associated with computer system or device 400.

[0048] As illustrated in FIG. 4 , hardware system 402 may include one or more memory devices 405, such as a database, internal local memory, a hard drive, a flash drive, RAM, ROM, etc. These memories 405 may include local data memory 235 and data files 270 and 272 of FIG. 2 . Hardware system 402 may also include one or more network cards or ports 406, which may connect software system 404 to one or more external communication networks via a network port, such as network port 245 of FIG. 2 . Similarly, hardware system 402 may include one or more peripheral devices 407, such as a user interface (e.g., user interface 237 of FIG. 2 ), a printer, a keyboard, a mouse device, an external memory drive (e.g., connected via external memory port 239 of FIG. 2 ), etc. Of course, any other peripheral devices or device ports or connections may be included within hardware system 402 in place of or in addition to those specifically described herein. Still further, hardware system 402 may include one or more processors 408 upon which the operating system and processes described herein execute.

[0049] As illustrated in FIG. 4 , software system 404 includes operating system (OS) components 410, services or other processes 414, and a set of configuration information or data 416 (e.g., the Windows registry, etc.) that can be used to configure the operation of software system 404 in the manner described herein. In this case, service processes 414, referred to herein simply as services 414, are processes that run independently of the logged-on user and generally run in response to calls or commands to OS 410 or messages conveyed by OS 410 to service process 414. That is, services 414 are generally created or run under the control of OS 410 or an agent of OS 410 (e.g., the Windows Service Control Manager). While these processes are typically started automatically, they may also be started in response to a request message sent by a desktop application. However, in both cases, as noted above, these services always run under a designated custom service account, regardless of who or what process caused them to start. Additionally, software system 404 of FIG. 4 includes various desktop applications 420. As can be appreciated, applications are typically initiated by and available to various logged-on users and run under those users' accounts 425 (illustrated by dotted lines in FIG. 4). Thus, unlike services that always run under the same custom service account, applications run under a different user account than indicated above (the currently logged-on user account). Of course, application 420 could be desktop application 258 of FIG. 2, and user account 425 could have different privileges and rights than typical, or all could have the same operating system privileges and permissions, such as those associated with or defined for a standard user, which may generally have the lowest level or set of operating system privileges and permissions.Importantly, configuration information 416 may include registry and other configuration information that defines the configuration of OS 410 to operate in the manner described above or to implement the rules described above with respect to FIG. 2. In this case, configuration information 416 may define account information, including privileges, access control lists that associate accounts with OS resources and define the account's access permissions, and information that enables run-time limitations on inherited account privileges. In this latter case, the service / application is started with a reduced set of account privileges as specified by the configuration information. However, this type of configuration information does not add privileges to those inherited from the account; it only reduces these privileges. Configuration information may be created and / or provided as part of a configuration activity provided by a control system supplier or configuration engineer, so that the configuration information may be pre-set to specify which operating system privileges are associated with and provided (e.g., required) for each of services 414 and applications 420 via user accounts, group accounts, and custom service accounts. Similarly, certain users, such as administrators, may modify the configuration information 416 to add new accounts, define new privileges, etc. Additionally, similar configuration information may be created for desktop applications and may be provided by a configuration engineer during the configuration process or by the application provider (e.g., a third-party provider of the desktop application), or may be set by default to a minimum level of privileges, or may be set by an administrator.

[0050] 4, OS 410 uses configuration information 416 to control operating system privileges, and therefore the permissions and capabilities, of various applications 420 (which may communicate with OS 410 via API 412 or directly), and uses services 414 to enforce the least privilege security feature described above. Accordingly, OS 410 uses configuration information (account management information generally stored in a database or file, e.g., Active Directory, Workgroup configuration files, exe-specific configuration files, etc.) and uses partitioned namespaces to enforce the requirement that applications 420 communicate with each other only via IPC (illustrated by line 430 in FIG. 4), the requirement that applications 420 communicate with services 414 only via IPC (illustrated by line 431 in FIG. 4), and the requirement that services 414 communicate with other services 414 only via IPC (illustrated by line 432 in FIG. 4). Similarly, OS 410 (or applications / services running in the manner described herein) may use configuration information 416 to prevent certain services from communicating with other services (e.g., to prevent a service with network access from communicating with a service with external media access), to prevent applications 420 from writing to service files and folders stored on a local or internal storage device (e.g., file 270 in FIG. 2 ), to prevent any service from writing to the desktop folder (e.g., file 272 in FIG. 2 ) or accessing the desktop in any other manner, and to prevent any service with network or external media access from writing to service files or folders (e.g., file 270 in FIG. 2 ). As can be appreciated, one way in which OS 410 enforces these rules is by tightly controlling the operating system permissions or privileges of various accounts and the services and applications associated with various accounts in the configuration files of configuration module 416.

[0051] As can be appreciated, the overall goal of this design illustrated in Figures 2-4 is to compartmentalize (isolate) services, applications, and other processes running within automation system workstations and servers or other computer devices, for example, in a process control network, so that the infection will disappear upon reboot, to reduce the damage the infection can do, to reduce its ability to propagate by preventing it from gaining elevated privileges and by limiting the privileges of communication interface services and external or media port handler processes, for the purpose of isolating the infection to prevent it from persisting on its own. Using these rules, if a service or another process spawned by the service becomes infected, (1) the infected service or process will not have elevated privileges because the service or process is running with limited privileges, (2) the infected service or process will not have permission to access resources it does not directly need, and (3) the infected service or process will not be able to persist on its own through a reboot. Specifically, services with communication network access and external media port (e.g., USB port) access have limitations on what they can do, and because these services are the only means by which infections can enter a machine, limiting what these specific services can do (e.g., preventing them from writing to local memory storage or disk so they can run with elevated privileges, from directly accessing the desktop, and from propagating infections between portable / external media and communication networks / data links) prevents the spread of infection within a computing device or network in the event of an infection. As a result, infections are automatically quarantined, and restarting the service removes the infection. For services that run only when accessed (e.g., COM / DCOM services), the calling process gets a clean copy of the service with each new call, thereby wiping out any infection within the service.

[0052] Similarly, using these rules, if a desktop application is infected, the application will not be able to directly access privileged functions in the operating system (OS), nor will the application be able to write to the network or portable memory devices. Instead, the application will have to request (via IPC) that actions be taken on its behalf by services and their processes that are designed to enable and provide an additional level of access control to privileged functions and resources.

[0053] As a result, some of the key benefits realized from this architecture include protection against processes with network or portable memory device access, which, if infected with malware, could use administrative privileges to attack the system, having access to resources available to commonly used / standard accounts, writing to the file system, and propagating malware from portable memory devices to the network and vice versa. This architecture also provides protection against desktop applications having direct access to trusted or restricted resources (e.g., local data files) or using elevated privileges, thus limiting the system's exposure to malware if a desktop application is infected with malware. Furthermore, this architecture allows control system processes to run under operating system accounts with only the operating system / file system privileges and permissions they need, while allowing them to access control system resources using user identity claims.

[0054] While the security techniques described herein have been described as being used in conjunction with networked process control devices and systems using Fieldbus and standard 4-20 mA devices, they may, of course, be implemented in any type of control device using any other process control communication protocol or programming environment and used with any other type of device, function block, or controller. Furthermore, the security techniques described herein may be implemented in any other type of computing device, including computing devices that are not part of a process control system. While the software security architectures described herein are preferably implemented in software, they may also be implemented in hardware, firmware, etc., and may be executed by any other processor associated with a computing device. Thus, the methods described herein may be implemented in a standard general-purpose CPU, or, if desired, on specifically designed hardware or firmware, such as an ASIC. If implemented in software, the software may be stored in any computer-readable memory, such as RAM or ROM of a computer or processor, on a magnetic disk, laser disk, optical disk, or other storage medium. Similarly, this software may be delivered to a user or to a process control system via any known or desired delivery method, including, for example, on a computer-readable disk or other transportable computer storage mechanism, or may be transmitted over a communications channel such as a telephone line, the Internet, or the like.

[0055] Thus, while the present invention has been described with reference to specific embodiments, it is intended that this is merely illustrative and not limiting of the invention, and it will be apparent to those skilled in the art that modifications, additions, or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention.

[0056] (Appendix 1) 1. A computing device comprising: a processor; an operating system executing on the processor in accordance with configuration data to implement service processes, wherein the configuration data causes each of the service processes to be assigned to one of a plurality of custom service accounts, each having a predetermined set of operating system privileges associated therewith, the predetermined set of operating system privileges for each of the plurality of custom service accounts being defined based on the operating system privileges required by a service assigned to the custom service account, and the custom service accounts do not have two-way logon privileges. (Appendix 2) 2. The computer device of claim 1, further comprising one or more communication ports and a local memory storage unit, wherein each of the service processes capable of communicating with the communication ports does not have privileges to write to the local memory storage unit. (Appendix 3) 3. The computer device of claim 2, wherein the computer device further includes an external media port, and one or more of the service processes capable of communicating with the communication port do not have privileges to communicate with a removable storage unit via the external media port. (Appendix 4) 3. The computer device of claim 2, wherein the computer device further includes an external media port, and wherein one or more of the service processes capable of communicating with the communication port do not have privileges to communicate directly with further service processes that have privileges to communicate with removable storage units via the external media port. (Appendix 5) 5. The computer device of claim 4, wherein the computer device further includes an external media port and a local memory storage unit, and one of the service processes that can communicate with the removable storage unit via the external media port does not have privileges to write to the local memory storage unit. (Appendix 6) 6. The computer device of claim 5, wherein the computer device further includes a communications port, and wherein one or more of the service processes capable of communicating with a removable storage unit via the external media port do not have privileges to communicate directly with further service processes that have privileges to communicate via the communications port. (Appendix 7) 10. The computing device of claim 1, further comprising a desktop environment, wherein the operating system executes to enforce a service namespace separate from a desktop namespace and operates to execute the service process within the service namespace and one or more desktop applications within the desktop namespace. (Appendix 8) 8. The computing device of claim 7, wherein the operating system enforces a requirement that processes running in the desktop namespace must communicate with processes running in the service namespace via inter-process communication. (Appendix 9) 8. The computing device of claim 7, wherein the operating system executes on the processor according to configuration data to implement desktop processes, the configuration data causing each of the desktop processes to be assigned to one of a plurality of user accounts, each having a predetermined set of operating system privileges associated therewith, the predetermined set of operating system privileges for each of the plurality of user accounts including interactive logon privileges. (Appendix 10) 10. The computing device of claim 9, wherein the set of operating system privileges assigned to a standard user account does not include elevated or administrative operating system privileges. (Appendix 11) 10. The computing device of claim 9, wherein the set of operating system privileges assigned to desktop applications when they are started is limited to standard user privileges even if the user account under which the desktop application is started has elevated operating system privileges, and processes started by processes running within the desktop namespace assume the privileges of the initiating process. (Appendix 12) 10. The computing device of claim 9, wherein the operating system enforces a rule that processes running within the desktop namespace cannot be elevated in operating system privileges without explicit authorization of an authenticated user whose account has elevation privileges. (Appendix 13) 8. The computing device of claim 7, wherein the operating system enforces a requirement that all processes running within the service namespace must communicate with other processes running within the service namespace via inter-process communication. (Appendix 14) 8. The computing device of claim 7, wherein the computing device further includes a local memory storage unit that stores service files or service folders, and wherein the operating system enforces rules that prevent processes running within the desktop namespace from writing to service files or service folders stored in the local memory storage unit. (Appendix 15) 8. The computing device of claim 7, further comprising a desktop comprising a user interface within the desktop namespace, wherein the operating system enforces rules preventing any of the service processes from directly accessing the desktop. (Appendix 16) 8. The computing device of claim 7, wherein messages originating from a desktop application include user ID information that identifies a user of the desktop application, and wherein the user ID information follows messages through multiple processes to their final destination, including through a service process that accesses a communication port to send the message over a communication link. (Appendix 17) 17. The computing device of claim 16, wherein the user identity information does not control operating system privileges and / or access permissions associated with one or more processes used to forward the message to a message recipient, and the user identity information controls access permissions for processes that are controlled. (Appendix 18) 1. A computing device comprising: a processor; A communication port; a local memory storage unit; an operating system executing on the processor in accordance with configuration data for implementing a service process, the service process being capable of communicating with the communication port, wherein the service process being capable of communicating with the communication port does not have privileges to write to the local memory storage unit. (Appendix 19) 19. The computing device of claim 18, wherein the local memory storage unit stores a service process file or a service process folder. (Appendix 20) 20. The computing device of claim 19, wherein the local memory storage unit further stores desktop application files. (Appendix 21) 19. The computer device of claim 18, wherein the computer device further includes an external media port, and wherein one of the service processes capable of communicating with the communication port does not have privileges to communicate with a removable storage unit via the external media port. (Appendix 22) 19. The computer device of claim 18, wherein the computer device further includes an external media port, and wherein one of the service processes capable of communicating with the communication port has privilege to communicate with a removable storage unit via the external media port but does not have privilege to communicate directly with a further service process. (Appendix 23) 23. The computing device of claim 22, wherein the further service process capable of communicating with a removable storage unit via the external media port does not have privileges to write to the local memory storage unit. (Appendix 24) 19. The computing device of claim 18, further comprising a desktop environment, wherein the operating system executes to enforce a service namespace separate from a desktop namespace and operates to execute the service process within the service namespace and one or more desktop applications within the desktop namespace. (Appendix 25) 25. The computing device of claim 24, wherein the operating system enforces a requirement that processes running in the desktop namespace must communicate with processes running in the service namespace via inter-process communication. (Appendix 26) 26. The computing device of claim 25, wherein a desktop application is assigned a set of operating system privileges that is set separately from a set of operating system privileges associated with a user account that starts the desktop application, and wherein the set of operating system privileges to which the desktop application is assigned does not include administrator operating system privileges. (Appendix 27) 26. The computing device of claim 25, wherein the operating system enforces a rule that the desktop application cannot be elevated in operating system privileges. (Appendix 28) 26. The computing device of claim 25, wherein the operating system enforces rules that prevent the desktop application from writing to service files or folders stored in a local memory storage unit. (Appendix 29) 25. The computing device of claim 24, wherein a message originating from a desktop application includes user ID information identifying a user of the desktop application, the user ID information following the message through the service process accessing a communications network port to transmit the message over a communications network. (Appendix 30) 19. The computing device of claim 18, further comprising a desktop including a user interface, wherein the operating system enforces rules preventing any of the service processes from directly accessing the desktop. (Appendix 31) 1. A computing device comprising: a processor; External media ports and a local memory storage unit; an operating system executing on the processor in accordance with configuration data for implementing a service process, including a service process capable of communicating with a removable memory device via the external media port, wherein the service process capable of communicating with the removable memory device via the external media port does not have privileges to write to the local memory storage unit. (Appendix 32) 32. The computing device of claim 31, wherein the local memory storage unit stores a service process file or a service process folder. (Appendix 33) 33. The computing device of claim 32, wherein the local memory storage unit further stores desktop application files. (Appendix 34) 32. The computer device of claim 31, wherein the computer device further includes a communications port, and wherein one of the service processes capable of communicating with removable memory via the external media port does not have privilege to communicate directly with a further service process that has privilege to communicate via the communications port. (Appendix 35) 32. The computing device of claim 31, further comprising a desktop environment, wherein the operating system executes to enforce a service namespace separate from a desktop namespace and operates to execute the service process within the service namespace and one or more desktop applications within the desktop namespace. (Appendix 36) 36. The computing device of claim 35, wherein the operating system enforces a requirement that processes running in the desktop namespace must communicate with processes running in the service namespace via inter-process communication. (Appendix 37) 37. The computing device of claim 36, wherein a desktop application is assigned a set of operating system privileges that is set separately from a set of operating system privileges associated with a user account that starts the desktop application, and wherein the set of operating system privileges to which the desktop application is assigned does not include administrator operating system privileges. (Appendix 38) 38. The computing device of claim 37, wherein the operating system enforces a rule that the desktop application cannot be elevated in operating system privileges. (Appendix 39) 32. The computing device of claim 31, further comprising a desktop including a user interface, wherein the operating system enforces rules preventing any of the service processes from directly accessing the desktop. (Appendix 40) 1. A computing device comprising: a processor; External media ports and A communication port; an operating system executing on the processor in accordance with configuration data for implementing a service process, the service process being capable of communicating with a removable memory device via the external media port, wherein the service process being capable of communicating with the removable memory device via the external media port does not have privileges to access the communication port. (Appendix 41) 41. The computer device of claim 40, wherein the service process capable of communicating with a removable memory device via the external media port does not have the privilege to directly access another service that can access the communication port. (Appendix 42) 41. The computing device of claim 40, further comprising a desktop environment, wherein the operating system executes to enforce a service namespace separate from a desktop namespace and operates to execute the service process within the service namespace and one or more desktop applications within the desktop namespace. (Appendix 43) 43. The computing device of claim 42, wherein the operating system enforces a requirement that processes running in the desktop namespace must communicate with processes running in the service namespace via inter-process communication. (Appendix 44) 41. The computing device of claim 40, wherein the operating system enforces a requirement that services must communicate with other services via inter-process communication. (Appendix 45) 1. A computing device comprising: a processor; an operating system executing on the processor in accordance with configuration data for implementing a service process and one or more desktop processes; 1. A computing device, wherein the operating system executes to enforce a service namespace that is separate from a desktop namespace, and operates to execute the service processes within the service namespace and the one or more desktop applications within a desktop namespace that is separate from the service namespace, and wherein all processes implemented within the service namespace must communicate with processes in the desktop namespace via inter-process communication. (Appendix 46) 46. ​​The computing device of claim 45, wherein the one or more desktop applications are assigned a set of operating system privileges that are configured separately from a set of operating system privileges associated with a user account that starts the desktop application. (Appendix 47) 46. ​​The computing device of claim 45, wherein the one or more desktop applications are assigned the same set of operating system privileges independent of operating system privileges associated with a user account that starts the desktop application. (Appendix 48) 48. The computing device of claim 47, wherein the set of operating system privileges to which the desktop application is assigned does not include an administrator operating system privilege. (Appendix 49) 49. The computing device of claim 48, wherein the set of operating system privileges to which the desktop application is assigned are operating system privileges associated with a general user. (Appendix 50) 48. The computing device of claim 47, wherein the operating system enforces a rule that desktop applications cannot be elevated in operating system privileges. (Appendix 51) 46. ​​The computing device of claim 45, wherein the computing device includes a local memory storage unit, and wherein the operating system enforces rules that prevent desktop applications from writing to service files or service folders stored within the local memory storage unit. (Appendix 52) 46. ​​The computing device of claim 45, further comprising a desktop including a user interface, wherein the operating system enforces rules preventing any of the service processes from accessing the desktop. (Appendix 53) 46. ​​The computing device of claim 45, wherein a message originating from a desktop application includes user ID information that identifies a user of the desktop application, the user ID information following the message through multiple processes associated with sending the message. (Appendix 54) 54. The computing device of claim 53, wherein the user ID information does not control operating system privileges associated with one or more processes used to forward the message to a message recipient. (Appendix 55) 46. ​​The computer device of claim 45, wherein the computer device further includes a communication port and a local memory storage unit, and one of the service processes that can communicate with the communication port does not have privileges to write to the local memory storage unit. (Appendix 56) 46. ​​The computer device of claim 45, wherein the computer device further includes an external media port, and wherein the one of the service processes capable of communicating with the communication port does not have privileges to communicate with a removable storage unit via the external media port. (Appendix 57) 46. ​​The computer device of claim 45, further comprising a communications port, a local memory storage unit, and an external media port, wherein one of the service processes capable of communicating with the communications network port does not have privileges to write to the local memory storage unit or to communicate with a removable storage unit via the external media port, one of the service processes capable of communicating with the removable storage unit via the external media port does not have privileges to write to the local memory storage unit and does not have privileges to communicate with the communications port, and one of the service processes capable of communicating with the communications port does not have privileges to communicate directly with one of the service processes capable of communicating with the removable storage unit via the external media port. (Appendix 58) 1. A computing device comprising: a processor; an operating system executing on the processor in accordance with configuration data for implementing a service process and one or more desktop processes; a computing device, wherein the operating system enforces operating system privileges for the service processes based on a custom service account to which each service process is assigned, regardless of which process invokes the service process; the operating system enforces operating system privileges for each of the one or more desktop applications using a standard set of operating system privileges defined for the desktop application that are used for the desktop application, regardless of which set of user accounts invokes the desktop application; a sending desktop application sends the message to a recipient process such that the message includes a user ID that identifies a user of the desktop application; and the user ID flows with the message as the message is processed by each of a number of different service processes as the message is relayed from the desktop application to the receiving process. (Appendix 59) 59. The computing device of claim 58, wherein user ID information of the user ID follows messages through multiple processes to their final destination, including through a service process that accesses a communication port to send the message over a communication link. (Appendix 60) 60. The computing device of claim 59, wherein the user ID information does not control the operating system privileges and / or access permissions associated with one or more processes used to forward the message to a message recipient. (Appendix 61) 61. The computing device of claim 60, wherein the user ID information controls access permissions for processing control objects in a process control network. (Appendix 62) 59. The computing device of claim 58, wherein the standard set of operating system privileges defined for the desktop application does not include an administrator operating system privilege. (Appendix 63) 63. The computing device of claim 62, wherein the operating system enforces a rule that desktop applications cannot be elevated in operating system privileges. (Appendix 64) 59. The computing device of claim 58, wherein the computing device includes a local memory storage unit, and wherein the operating system enforces rules that prevent desktop applications from writing to service files or service folders stored within the local memory storage unit. (Appendix 65) 59. The computing device of claim 58, further comprising a desktop including a user interface, wherein the operating system enforces rules preventing any of the service processes from accessing the desktop. (Appendix 66) 59. The computing device of claim 58, wherein the user ID information does not affect the operating system privileges associated with one or more processes used to forward the message to the receiving process. (Appendix 67) 59. The computer device of claim 58, wherein the computer device further includes a communication port and a local memory storage unit, and wherein one of the service processes that can communicate with the communication port does not have privileges to write to the local memory storage unit. (Appendix 68) 59. The computer device of claim 58, wherein the computer device further includes an external media port, and wherein the one of the service processes capable of communicating with the communication port does not have privileges to communicate with a removable storage unit via the external media port. (Appendix 69) 59. The computer device of claim 58, further comprising a communications port, a local memory storage unit, and an external media port, wherein one of the service processes capable of communicating with the communications port does not have privileges to write to the local memory storage unit, one of the service processes capable of communicating with a removable storage unit via the external media port does not have privileges to write to the local memory storage unit, and one of the service processes capable of communicating with the communications port does not have privileges to communicate directly with one of the service processes capable of communicating with a removable storage unit via the external media port. (Appendix 70) 59. The computing device of claim 58, wherein the operating system executes to enforce a service namespace separate from a desktop namespace and operates to execute the service processes within the service namespace and the one or more desktop applications within a desktop namespace separate from the service namespace, and all processes implemented within the service namespace must communicate with processes in the desktop namespace via inter-process communication.

Claims

1. 1. A computing device comprising: a processor; External media ports and a local memory storage unit; and an operating system executing on the processor to provide services to applications in accordance with configuration data for implementing service processes, the service processes including (i) a first service process capable of communicating with a removable memory device via the external media port, and (ii) a second service process capable of communicating with the local memory storage unit, wherein the first service process capable of communicating with the removable memory device via the external media port does not have privileges to write to the local memory storage unit, the operating system privileges of the service processes are defined to be separate and distinct from the privileges of one or more user accounts, the service processes are run through the one or more user accounts, and the operating system privileges of the service processes are defined to be separate and distinct from the privileges of the applications.

2. The computing device of claim 1 , further comprising a desktop including a user interface, and wherein the operating system implements rules that prevent any of the service processes from directly accessing the desktop.

3. 3. The computing device of claim 1 or claim 2, further comprising a desktop environment, wherein the operating system executes to enforce a service namespace separate from a desktop namespace and operates to execute the service processes within the service namespace and the applications within the desktop namespace.

4. 4. The computing device of claim 3, wherein the application is assigned a set of operating system privileges that is set separately from a set of operating system privileges associated with a user account that starts the application, and the set of operating system privileges to which the application is assigned does not include administrator operating system privileges.

5. 5. A computing device according to claim 3 or claim 4, wherein the operating system implements a rule that the application cannot be elevated in operating system privileges.

6. 1. A computing device comprising: a processor; External media ports and A communication port; and an operating system executing on the processor to provide services to applications in accordance with configuration data for implementing service processes, the service processes including (i) a first service process capable of communicating with a removable memory device via the external media port, and (ii) a second service process having privileges to access the communication port, wherein the first service process capable of communicating with the removable memory device via the external media port does not have privileges to access the communication port, the operating system privileges of the service processes are defined to be separate and distinct from the privileges of one or more user accounts, the service processes are run via the one or more user accounts, and the operating system privileges of the service processes are defined to be separate and distinct from the privileges of the applications.

7. 7. The computing device of claim 6, wherein the service process capable of communicating with a removable memory device through the external media port does not have the privilege to directly access another service that can access the communication port.

8. 8. The computing device of claim 6 or claim 7, further comprising a desktop environment, wherein the operating system executes to enforce a service namespace separate from a desktop namespace and operates to execute the service processes within the service namespace and the applications within the desktop namespace.

Images