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

Abstract

A method and apparatus are provided for securing the operation of software processes within devices, such as computer devices, in a process or plant environment. In one embodiment, desktop applications and services or other processes within a computing device are isolated by partitioning the global namespace of each computing device in a process control system into one or more service namespaces and one or more user namespaces. All communication between the various desktop applications and services implemented by the operating system must be via known and reliable inter-process communication (IPC).

Description

Technical Field

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

Background Art

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

[0003] A process controller is typically located within a process plant environment and receives signals indicating 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, for example, implements different control modules that make process control decisions, generates control signals based on the received information, and coordinates with control modules or blocks within field devices, such as HART® and FOUNDATION® fieldbus field devices. The control modules within the process controller transmit control signals to field devices via communication lines or other signal paths, thereby controlling the operation of the process.

[0004] Information from 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, portable devices, data historians, report generators, and centralized databases. The information communicated over the network allows operators or maintainers to perform desired process functions and / or verify plant operation. For example, this information enables operators to change process control routine settings, modify the operation of control modules in process controllers or smart field devices, check the current status of processes or the status of specific devices within the process plant, review warnings generated by field devices and process controllers, simulate process operation for training or process control software testing purposes, and diagnose problems or hardware failures within the process plant.

[0005] Field devices typically communicate with other hardware devices via a process control network, which may be, for example, an Ethernet-configured LAN. The network relays process parameters, network information, and other process control data to various entries within the process control system through various network devices. 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 their routing, frame rate, timeout, and other network parameters, but they do not modify the process data itself. As the process control network grows in size and complexity, the number and types of network devices increase accordingly. As a result of the growth of the system and network, security and management can gradually become more 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. Therefore, open ports on a device can become access points for network expansion by adding other devices, or they can allow malicious or non-malicious entities to access the network and initiate unwanted and potentially harmful network traffic, or introduce malware (e.g., malicious programs, spy or data-gathering programs, adware, or other unwanted and potentially dangerous software) that could cause serious problems within the plant control system.Effectively monitoring or controlling access to all ports on devices within a network that control communications across complex process control systems becomes increasingly impractical as the number of network devices and associated access points grows.

[0006] Similarly, in a typical industrial control system, workstations / servers are strategically positioned between the plant network and embedded devices (e.g., controllers, PLCs, RTUs) that perform control and data acquisition functions. Therefore, the primary security objectives of these workstations / servers are to prevent malware from entering the control system and harmfully affecting embedded devices, as well as to prevent malware from altering configuration and historical data stored in the plant database. Numerous security features, such as "antivirus" software and "whitelisting," can be used to address this objective, but 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, some of these security features are too intrusive to be operationally practical in a process control system, as they have the potential to hinder the activities of plant operators.

[0007] Generally, malware, such as those at the heart of zero-day attacks, is typically introduced into a control system on a specific device via an external memory device (such as a removable flash drive) or through a communication connection by the operation of an application or service that has the privilege or authorization to access these memory devices, network ports, or direct data links. (For the purposes of this patent, a communication connection includes connections made via a communication network connection or a direct data link such as a modem connection.) The malware can then propagate to other devices (e.g., via communication or portable memory devices) and / or run within a device using the security privileges of the application or service that is infected with the malware. Furthermore, the malware may remain locally able to run again after a reboot. In some cases, the malware may use the privileges of the account under which the application or service is running to extend the privileges of the host, e.g., the infected application or service, thereby enabling the malware to perform actions or operations within the process control device or system that require higher privileges and are therefore typically detrimental to the control system operation. In any given scenario, zero-day attacks that infect already running applications pose 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, potentially destructive, or even fatal effects within a process plant if they disrupt the ongoing operation of the plant control system. [Overview of the project]

[0008] The process control system employs a new set of security features or software security architecture that is effective in preventing zero-day or other types of malware attacks. Generally speaking, the new security features or architecture implement the use of what is referred to herein as “least privilege” when running applications and services within any particular control system device, such as within a workstation, server, database, controller, or field device, in order to reduce the impact of malware that could infect a workstation, server, or other device. The term “privilege” as used 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] Generally, least-privilege-based security features or architectures isolate "service" processes from desktop applications running for logged-on users (local or remote) by dividing the global namespace of a device (e.g., controller, workstation, server, etc.) into a service namespace and, if present (e.g., within a desktop application), a user namespace. The architecture then uses inter-process communication to strictly control communication between processes (e.g., applications and services) within these different namespaces, in order to prevent an infected service or application from directly infecting or disrupting other services or applications. Specifically, new security architectures use this namespace division to prevent desktop applications from directly accessing targets in the service namespace and vice versa.

[0010] Furthermore, the new security architecture restricts the privileges granted to services and desktop applications in a manner that limits or reduces the ability of an infected service or application to adversely affect or infect other services or applications. Generally, the security architecture limits the operating system privileges of a service or application or other process to a subset of the privilege designations granted to the account under which the service or application or other process operates or is generated, limits the privileges of an application initiated by a logged-on user to a subset of the privileges associated with that user, and prevents privilege escalation through desktop applications (running under the logged-on user). In some cases, the software security system reinforces the restriction that all access to communication ports or external media ports (e.g., removable storage devices connected via external media ports such as USB ports) must be made through a service with restricted privileges (and never by a desktop application), where the privileges of the restricted service 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 is benign because it cannot store itself on the local disk or other memory, cannot perform administrative functions, cannot access the desktop, cannot propagate through the communication network if the infection enters from a removable storage device via an external media port, and cannot be stored on a removable storage device via an external media port or propagated to another communication connection if the infection enters from a communication connection via a communication port.

[0011] Therefore, the new security architecture uses access control to enhance which user accounts and processes (services or desktops) are authorized to access secure objects through calls to the operating system and its subsystems, and includes mechanisms to prevent lower-privileged processes from injecting code into higher-privileged 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 takeovers from other group accounts.

[0012] These security features, individually or in combination, make it difficult, if not impossible, for malware to be imported into the system through the operation of desktop applications accessing network connections or removable / portable storage media connections (such as USB ports). Therefore, a combination of one or more of these security features results in a more secure software environment within process control systems or process plants that is less susceptible to virus attacks, such as zero-day virus attacks, and other malware. These security features also limit malware's ability to be imported into internal data storage devices via networks or external devices, and to extend the privileges of services, etc., to allow services to access devices, storage media, or processes that are not required by the applications that require those services.

[0013] Therefore, using these features, the new software architecture design separates (isolates) the services and desktop applications running in process control automation system workstations and servers for the purpose of reducing their malware attack profiles or surface. Furthermore, if a service or another process generated by a service becomes infected, it will no longer have the privileges necessary to do anything it has not yet done, and it will no longer have permission to access resources that it does not directly need. In addition, if a desktop application becomes infected, it will no longer be able to directly access privileged functions of the operating system, nor will it be able to directly write to removable storage devices connected via the network or external media ports. Instead, the desktop application will have to request that the service and the processes it generates take actions designed to enable and provide an additional level of access control to privileged functions and resources for itself. [Brief explanation of the drawing]

[0014] [Figure 1] This is an exemplary block diagram of a process plant having a distributed process control system and process automation network, including one or more operator and maintenance workstations, a server, a controller, field devices, and other network devices configured to implement a least-privilege-based software security architecture and the functions described herein. [Figure 2] This is an illustrative block diagram of workstation / server / controller devices within a process control plant, illustrating various namespaces and security restrictions implemented to implement improved security features for applications, services, and other processes within the process control software architecture. [Figure 3]This specification provides an example of an account diagram, including group accounts and custom accounts, that defines sets of privileges associated with various different applications and services, in accordance with the least privilege software security architecture described herein. [Figure 4] This is an illustrative architecture diagram illustrating one of the software and hardware components of a workstation in the system shown in Figure 2, illustrating communication connections between various services and applications using the account shown in Figure 3. [Modes for carrying out the invention]

[0015] Figure 1 is a schematic diagram of a process control system or process automation system 100, for example, installed in a process plant, where various computer devices may receive various software security features to enhance software security and to 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 (data historians, etc.) which are communicably connected to one or more host workstations or computers 120-122 (which may be any kind of personal computer, workstation, server, etc.) via a process control communication network 130. The controllers 110 and databases 112 may be connected to a communication network or bus 130 (which may be an Ethernet communication network, for example) via one or more network interface cards 132. Furthermore, the controllers 110 may be connected to field devices 140, 143, and 154 in the process plant or control system via input / output (I / O) cards 142. The database 112 may include one or more data historians, which may be any desired type of data acquisition unit or memory device having any desired type of memory and any desired or known software, hardware, or firmware for storing data. Furthermore, the database 112 may be separate from or part of one or more workstations or servers 120-122. For example, the controller 110, which may be a DeltaV® controller sold by Fisher Rosemount Systems Inc., is communicably connected to the host computers 120-122 by one or more network cards or devices 132, for example, via an Ethernet connection 130 or any other desired communication network.The network device 132 may include one or more of the following: a network interface card, a network switch, a router, a firewall, or any other device that facilitates the transmission of data over the network 130 without altering the underlying data.

[0016] As illustrated in Figure 1, the server 122 is connected to various network devices that can be physically located in any part of the communication or process control network and in any part of the process plant, and may include any part of the security features described herein. In this embodiment, the communication network 130 is typically a closed local area network (LAN) to which only devices included in the control system are connected, and can be implemented using wired or wireless technology. Furthermore, the controller 110 is communicably connected to the field device 140 using any desired hardware and software associated with any smart communication protocol, such as the standard 4-20mA device protocol, Ethernet protocol, and / or any smart communication protocol such as the 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, and positioners, while the 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 Figure 1, field device 140 is a HART or 4-20mA device that communicates via a standard HART or analog 4-20mA 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 via an I / O network with a digital bus 145 or I / O card 142. Naturally, field devices 140 and 143 may conform to any other desired standard(s) or protocol, including any standards or protocols that may be developed in the future. Furthermore, the field devices 140 and 143 can be wirelessly connected to the controller 110 via any desired wireless communication protocol, such as the WirelessHART® protocol.

[0018] Furthermore, 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, a field device 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] Controller 110 may be one or more of a number of distributed controllers in a plant, each having one or more processors internally, but implements or supervises one or more process control routines. These routines may include one or more control loops stored within or associated with Controller 110. 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 that control processes in any desired manner, via the network 130. It should be noted that any control routine or element described herein may, if desired, have parts implemented or executed by different controllers or other devices. Similarly, control routines or elements described herein as being implemented within the process control system 100 may take any form, including software, firmware, hardware, etc. For the purposes of this description, a process control element may be any part or component of a process control system, including, for example, routines, blocks, or modules stored on any computer-readable medium. A control routine can be any part of a control procedure, such as a module, subroutine, or subroutine (e.g., a line of code), and can 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 can be hardcoded into, for example, one or more EPROMs, EEPROMs, application-specific integrated circuits (ASICs), or any other hardware or firmware elements. Furthermore, a control routine can be designed using any design tool, including a graphic design tool or any other type of software / hardware / firmware programming or design tool. Thus, the controller 110 can be configured to implement a control strategy or control routine in any desired manner.

[0020] Furthermore, as illustrated in Figure 1, an additional communication network 160 is connected to the process control system server 122 and workstations 120 and 121 to enable them to connect to the plant information technology system, the business system, or other network systems within the plant.

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

[0022] Furthermore, the security-based architectures described herein limit the capabilities of malware by restricting the privileges granted to each service and desktop application to a subset of privilege designations, such as a subset of the privileges granted to the logged-on user account under which the service or application runs or is invoked. For example, if a service that normally runs under an administrator account typically has all administrator privileges, the newly secure software architecture will create or run some or all of the services using only the specific privileges required by the service to perform the functions it is designed to do, without using all administrator privileges. Furthermore, services that involve communication network access (via a communication network port) or access to removable data storage devices via removable memory ports (e.g., USB ports) will 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 via the other of the communication network port or removable memory port. This feature prevents, or at least reduces, the ability of malware to use services invoked by users with higher privileges, or to gain access to devices or functions not required by the service itself, thereby limiting the malware's ability to infect other devices or execute higher-privileged commands or services solely due to the logged-on user account under which the service runs or is invoked.

[0023] Similarly, this security feature can automatically restrict privileges for applications, such as desktop applications initiated by the logged-on user, to prevent privilege escalation. In some cases, the security architecture prevents any and all desktop applications from being able to escalate privileges so that a request for elevated privileges to a user indicates that the application is infected. Generally, privilege escalation by desktop applications (running under the logged-on user account) currently typically requires authorization from an authorized user to perform actions that require escalation. Newer operating systems typically enhance this feature by granting applications initiated by logged-on users, including administrators, only standard user privileges (no escalation / administrator privileges) and requiring privilege escalation to be specifically authorized by the user. Newer architectures can prevent desktop application privilege escalation in any event, thereby providing another level of security that prevents malware from automatically escalating privileges within the system and using this escalation to infect further processes or devices.

[0024] Similarly, the architecture to be secured described herein may also use access control to enforce which user accounts and which processes (services or desktops) are authorized to access security-enabled objects through calls to the operating system and its subsystems (such as files, mutexes, events), and 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. Thus, user A inherits privileges and permissions from both B and C. However, while these privileges are shared or portable on the logged-on user account side, these privileges are not propagated to services or processes that receive messages from the operation of applications 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, generally, the operation of services and processes (and in many cases applications) under accounts with higher privileges is limited to a subset of the privileges required for the intended operation of the service or application or other process, i.e., the minimum privilege, such that the privileges for services and processes generated or executed by the operating system are defined separately from the privileges defined for the logged-on user account.

[0025] Generally, referring to Figure 2, the security features and secure architectures described herein are exemplified as being implemented in a server, workstation, or controller, such as any of the devices in Figure 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 computer devices or machines, such as workstations, database servers, etc. More specifically, Figure 2 illustrates a workstation / server / controller 220 connected to zero or more network / data links 230, one of which may be, for example, network 130 in Figure 1. Furthermore, in this case, the server / workstation 220 is connected to one or more local data memories 235, which are exemplified in Figure 2 as being internal to or directly connected to the workstation / server / controller 220. Furthermore, the workstation / server / controller 220 may include or be connected to a user interface or display device 237 and include zero or more removable media ports 239. Removable media ports 239, through which external or removable memory devices can be connected to device 220, may include or may include any type of memory access port(s), including USB ports, standard or dedicated connections to CD or DVD drives, external hard drives, flash or solid-phase memory drives, magnetic drives, etc. As illustrated in Figure 2, data, programs, etc., may be provided to or exported from the workstation / server / controller 220 via one of the ports 239 through a removable or portable memory device, such as a USB flash drive 240, DVD or CD 241, for example.

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

[0027] As further illustrated in Figure 2, the workstation / server / controller 220 is divided into two namespaces, including a service namespace 250 and zero or more logon user namespaces (exemplified in Figure 2 as a single logon user namespace 252). Naturally, there may be different logon user namespaces (also referred to herein as user namespaces) for each of several different users who log in to the workstation / server / controller 220, and some devices such as servers may not have logon user namespaces. 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, a desktop application 258 is a process that runs within the user namespace, while a service process, referred to herein simply as a service, runs independently of the logged-on user and is generated or run by the operating system (or one of its agents, such as the Windows Service Control Manager), typically in response to configuration settings, calls to the operating system, or request messages sent to them (e.g., Windows COM / DCOM messages). 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 implement USB or other local data storage device reading or its interface with a communication network in the manner described herein. While services 260 are typically started automatically, these processes may be started in response to request messages sent by a user process or another service.However, as will be 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 were 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, the service 260 in Figure 2 may include zero or more service namespace processes with network access 262 (via one of the communication ports 245), a service namespace process with access to a removable storage device 264 via an external media port 239, and other service namespace processes 266 that are portable or have neither local memory access nor communication network access. Furthermore, the local data storage device or memory 235 may include various types of files or folders, including service files or folders 270 created and used by the service namespace process 260, and desktop files or folders 272 created and used by a logged-on user namespace process, for example, a desktop application 258.

[0028] As can be understood 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 into services (isolated processes generated by services), where these rules are reinforced by the operating system and its configuration data. The division of the global computing environment namespace into service and logged-on user (desktop application) namespaces prevents desktop applications from directly accessing objects defined within the service namespace (e.g., mutexes), and prevents service namespace processes from directly accessing objects defined for the logged-on user namespace (used by desktop applications) (e.g., desktops). In this configuration, services and desktop applications must communicate with each other or through each other to reach objects created in each of these different namespaces (i.e., they are compelled to communicate with each other). This feature prevents malware that may reside within a service or desktop application in one environment from creating or using targets in the other namespace without passing through the respective service or application in the other namespace, which generally limits the malware's ability to disrupt other services or applications. This feature limits, for example, the malware's ability to create or infect targets in other environments, which limits the malware's ability to be configured within a control system and propagate to it, for example, via a communication network 230.

[0029] The secure software architecture described above operates in various ways to enhance the overall security of workstations / servers / controllers 220 used within plants or other industrial automation systems. Generally applicable to all computer devices or machines within control systems, including machines running processes / applications developed by third parties (as well as processes / applications developed and provided by control system vendors), this security mechanism is structured to implement numerous rules or features.

[0030] Some of the rules described herein, enhanced by the operating system configuration of the workstation / server / controller 220, apply to all processes that require elevated privileges, network access, local disk write access, or 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 Figure 2. Specifically, these processes (1) run as a service or are generated by a service, (2) run under a custom (non-standard / default) account belonging to a custom group / role, (3) are granted access only to the resources they need, (4) are explicitly denied access to resources that are not explicitly needed, (5) are granted only the privileges they need to operate, (6) do not have impersonation privileges that allow a process running under another account to change the account to this custom account, and (7) do not have delegation privileges that grant authority to another running process to run under this custom account. Furthermore, if these processes have network access or access to portable or removable memory devices, these processes do not have elevated privileges or the ability to write to local memory storage devices (e.g., disks).

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

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

[0033] Furthermore, all processes that require network access or have access to portable or removable memory devices (e.g., processes 262 and 264 in Figure 2) run or operate under an account that (1) does not have command shell access, (2) does not have access to programs that modify the security configuration (policy settings and accounts) of the workstation / server / controller 220, and (3) is restricted from performing file system writes, as illustrated by the dotted line 294 in Figure 2. As a result, only service 266, which does 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 known as bidirectional applications / processes, run or operate without elevated privileges, regardless of which user or logon account was used to start or invoke these applications or processes. Therefore, even when a user with administrative privileges starts a desktop application, this desktop application still runs with limited operating system privileges, equivalent to those of a standard user, independent of the privileges of the user who started it. Furthermore, as described above, desktop application 258 cannot directly access the communication network 230, but instead must communicate with service 262 in the service namespace 250, which provides access to the communication network, via inter-process communication. Similarly, desktop application 258 cannot directly access portable memory devices 240 and 241, but instead must communicate with service 264 (via inter-process communication), which provides access to these devices. Furthermore, desktop application 258 is restricted from accessing directories and files owned by the system; otherwise, if infected, it could jeopardize the system's performance / operation. Therefore, as illustrated by line 296 in Figure 2, desktop application 258 can write to the desktop folder and file 272, but not to the service folder and file 270. Moreover, desktop application 258 is designed to be independent of the user privileges that launch it, never requiring elevated privileges, and never being elevated. Similarly, desktop application 258 can never impersonate another user and must communicate with each other via reliable local inter-process communication.

[0035] Furthermore, all user IDs are transmitted between the service and process 260 and the desktop application 258 via digitally signed ID requests, which follow or flow with the communication, enabling verification of process control system authorization through various processes and network devices. For example, a process control system operator may make a request (via the desktop application) to write parameters (e.g., setpoints) into a process control device such as a controller. This request may require various services to be invoked or generated between the process that sends the request over the communication network to the process control device that will implement the write. The user ID request flows along with the request through various machines in the process control network and through various processes used to create and transmit the request, 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 thus can inspect and log the change as close as possible to the process where the write operation is performed. This feature ensures that the human user performing the operation is precisely and accurately identified without the use of impersonation and / or delegation. Furthermore, 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 to continue operating through the shift change without requiring the logged-on user to log off, thus eliminating the need to be restarted by another user. Instead, the new shift operator identifies itself to the process control system without needing to log on to the operating system. In this configuration, it is irrelevant which operator starts the desktop application, as long as all desktop applications can run with the privileges of the logged-on user and thus identify themselves when using the application to ensure that the appropriate identity request flows along with the process operation request.Furthermore, without this mechanism, a service / process / application might only be able to identify the user with the account from which it operates or from which it is invoked. This feature is also important in control systems, as the current user on the operator console may not be the logged-on user. This restriction eliminates the risk of having the identity of a stolen logged-on user, which is used in determining operating system privileges and access control permissions, as it is used to determine access control permissions used to provide access to control system resources (e.g., parameters and warnings).

[0036] Regarding Figure 2, one way to implement the security features described above is to use a more restrictive method for defining the privileges and permissions granted to various applications and services within a standard open architecture operating system-based control system. In particular, privileges and permissions are currently defined on a per-user basis, so that some users have more privileges and permissions than others. In this architecture, applications (e.g., desktop applications and the processes they initiate) are generally granted the privileges and permissions of the logged-on user account from which these applications or processes are started or invoked. On the other hand, many services (e.g., processes generated based on configuration settings, or in response to calls from applications or user requests to the operating system, for starting them or processing 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 accounts configured for them, and processes started by other processes are always started using the account under which the process starting them is running. Therefore, in many cases, this service runs under either the standard OS service account or a user account.

[0037] In contrast, the secure architecture in Figure 2 defines privileges and permissions for services separately from those defined for logon user accounts, thus preventing services from running under user accounts with bidirectional logon privileges. That is, services can always run under specific service accounts that do not have bidirectional logon privileges. Specifically, the secure architecture in Figure 2 can define what are referred to herein as custom service accounts, having different or limited sets of privileges and permissions, and each of the services 260 in Figure 2 can be assigned to one or more of these custom service accounts for the purpose of assigning privileges and permissions to those services. Each service is assigned to a custom service account that has the minimum set of privileges required by that service. A service should not be assigned to a custom service account that has more privileges than it needs to operate. 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 consists of a limited set of services that restrict the privileges assumed by the custom account to only those it needs. In some cases, such as services that access communication ports or external media ports, services may be assigned to the least privileged account, 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 user who launches them, but should always be started with limited standard user privileges, and should only be elevated when necessary and only with the user's authorization. If a user does not have the necessary privileges, the user with those privileges should be required to authorize the elevation. In this manner, services and applications may have a set of limited privileges that limit 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 subsequently assigned to a service, which can further restrict custom account privileges so that the service has only the privileges or permissions necessary to perform the tasks or functions for which it was designed.

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

[0040] As illustrated in Figure 3, sets of user accounts 306 are established, and each user account 306 may belong to one or more group accounts 302, as indicated by the dotted line between user account 306 and group account 302. In this manner, each user account 306 may inherit the operating system privileges and permissions of any group account 302 to which it is associated or belongs, and pass these privileges / permissions to desktop applications when initiated by the associated logon user. As illustrated in Figure 3, a user account 306 may belong to multiple group accounts 302 and therefore inherit their privileges and permissions, which it may also belong to and inherit from other group accounts 302. Similarly, as illustrated in Figure 3, sets of custom service accounts 310 are 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 in order to perform actions. Each custom service account 310 may belong to one or more group accounts 302 and therefore inherit their privileges. Each of the various services 312 and processes initiated by them within a computer device is assigned to one (or possibly more than one) of the custom service accounts 310, and assumes or possesses the operating system privileges of the custom service account(s) 310 to which these services 312 belong. Generally, the operating system privileges and permissions granted to each custom service account 310 are defined separately from those of the user account 306.Specifically, the privileges and permissions of custom accounts 310 should be tailored (restricted) specifically for the services 312 and processes they initiate (e.g., isolated processes, dependent processes), and should only have the operating system privileges and permissions necessary for the services 312 and processes they initiate to perform their intended functions, unless those services / processes are configured to further restrict the privileges inherited from the custom service accounts.

[0041] With the use of user account 306 and custom service account 310, service namespace process 312 (i.e., the operating namespace in which services and processes they initiate run) and desktop namespace process 314 (i.e., the operating namespace in which desktop applications and processes they initiate run) may be associated with different custom account 310 or user account 306 so that services invoked by desktop applications may run with different privileges than those invoked by desktop applications. The phrase "invoked by desktop applications" refers to the reception of a remote procedure invocation message by a service sent by a desktop application.

[0042] Furthermore, as illustrated in Figure 3, a set of group accounts 302 may be established at a higher level to define specific sets of operating system privileges and permissions (including access permissions). A group account may be associated with zero or more custom service or user accounts within a computer device or within a process control plant or system as a whole (e.g., using Active Directory). Each group account 302 may include specific sets of operating system privileges and permissions (including access permissions), custom service accounts, and / or user accounts that are members of group account 306, which may be taken over by other group accounts. Takeover is achieved by creating these account members of the group account. Thus, custom account 312 and user account 306 may belong to the same group 302 and therefore take over the same operating system privileges and permissions. Group accounts 302 are therefore different from roles typically used in process control systems to define process control (as opposed to operating system) privileges and permissions. Process control roles tend to include groups of individuals (operators, configuration engineers, technicians, etc.) responsible for specific parts or functions of the plant (as opposed to operating system groups). While such different roles may define different process control system privileges and permissions for these individuals, individuals assigned to different roles often operate 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 understood, in any event, group account 302 defines operating system privileges and permissions that may be taken over by custom service account 312, which is used to run service namespace processes and / or user account 306 and desktop namespace processes, initiated by those logon users.

[0043] Therefore, Figure 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 services and applications. The custom service account 310 illustrated in Figure 3 is used only for service processes 312 and other processes within the service namespace, while the user account 306 is used only for processes within the desktop namespace (e.g., applications 314). Generally, all processes within the desktop namespace (e.g., desktop applications 314) are started with the privileges of a “standard user” account 306A (least privileged account) that does not include administrator privileges. Furthermore, custom accounts 310 are defined with only the additional privileges they require. However, as illustrated in Figure 3, two or more services 312 may run under the same custom service account 310, and if a service 312 does not require all of the custom service account privileges, some of those privileges may be individually denied. However, for services involving access to communication ports or external media ports (e.g., USB ports), the services 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 devices or disks. Here, local or internal data storage devices are intended to mean data storage devices connected in a relatively permanent manner within the computer device, and are not intended to be portable or easily removable, and therefore not connected via external media access ports. Local memory or data storage devices may generally include internal disk drives or internal random access memory.

[0044] Therefore, as can be understood from the explanation provided above, operating system privileges, including access permissions, are granted to a process (e.g., a service or desktop application) entirely independently of access controls used to grant / deny user access to process control system objects (e.g., setpoints, temperature and pressure measurements, and warning limits). Access to process control objects requires a separate user ID to be passed along with a request that enables the process control device to validate process control system authorization, because the operating system, which strengthens access permissions and operating system privileges, knows nothing about the control system objects. As is known, control systems generally have a separate user manager that defines what each control system user can access within the control system, and the user ID request is provided to enable this separate user manager to function properly.

[0045] In any given event, the permissions and privileges a user has to use this architecture to access process-controlled targets, perform actions within a process plant, etc., are independent of the privileges and permissions of services and applications running under a custom service account or user logon account. This feature mitigates 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 in order to access or interrupt the execution of process-controlled targets beneath it.

[0046] As further illustrated in Figure 3, the execution engine 320 (e.g., the operating system execution engine) of a computer on which processes (e.g., services or applications or processes started by services or applications) are to run grants privileges for services 312 or applications 314 or the processes they start using the following rules: A process started directly by a logged-on user receives 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). A service started by the operating system receives the privileges and permissions of the custom service account to which they belong, reduced by any restrictions configured for the service. A process started by another process receives the current set of privileges and permissions of the process that starts it. This organization enables each process (e.g., each service 312 or application 314 or the processes started by them) to run or execute with the minimum set of privileges required to perform a particular function of the process. This function therefore limits the ability of malware that infects service 312 or application 314 or processes initiated by them to take actions that service 312 or application 314 do not require for its normal operation (e.g., by acquiring operating system privileges or permissions), thereby limiting the ability of malware to operate within a computer device or propagate to other process control system devices or other computer devices within a process control system network. Furthermore, the execution engine 320 may not allow or may prevent privilege expansion within desktop application 314 or service 312 in order to prevent malware from being able to break this operating system privilege structure.

[0047] Figure 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 in order to limit the spread of malware or the infection that may result therefrom. Specifically, as illustrated in Figure 4, the computer system diagram 400 is divided into a hardware system 402 (below the solid line 403) having various hardware components and a software system 404 (above the solid line 403) having various software / firmware components. It will be understood that the software / firmware components of the software system 404 are implemented in one or more computer processors and memory devices (not shown in Figure 4) associated with the computer system or device 400.

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

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

[0050] As illustrated in Figure 4, OS410 uses configuration information 416 to control operating system privileges and therefore the permissions and capabilities of various applications 420 (which may communicate with OS410 via API 412 or directly), and uses services 414 to enhance the least privilege security features described above. Thus, OS410 uses configuration information (generally account management information, stored in databases or files such as Active Directory, Workgroup configuration files, exe-specific configuration files, etc.) and uses partitioned namespaces to enhance the requirement that applications 420 communicate with each other only via IPC (illustrated by line 430 in Figure 4), the requirement that applications 420 communicate with services 414 only via IPC (illustrated by line 431 in Figure 4), and the requirement that services 414 communicate with other services 414 only via IPC (illustrated by line 432 in Figure 4). Similarly, OS410 (or the execution of applications / services in the manner described herein) may use configuration information 416 to prevent certain services from communicating with other services (for example, to prevent services with network access from communicating with services with external media access), to prevent applications 420 from writing to service files and folders stored on local or internal storage devices (e.g., file 270 in Figure 2), to prevent any service from writing to the desktop folder (e.g., file 272 in Figure 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 Figure 2). As can be understood, one way OS410 reinforces these rules is by tightly controlling the operating system permissions or privileges of various accounts, as well as the services and applications associated with various accounts in the configuration files of the configuration module 416.

[0051] To make it clear that the overall purpose of this design, illustrated in Figures 2-4, is to isolate services, applications, and other processes running within automated system workstations and servers or other computer devices, such as process control networks, to reduce the damage they can cause, to reduce their ability to propagate, to reduce the damage they can cause, and to eliminate the infection upon reboot, by isolating the infection, by preventing the infection from acquiring elevated privileges, and by restricting the privileges of communication interface services and external or external media port handler processes, so that the infection disappears upon reboot. Using these rules, if a service or other process generated by a service becomes infected, (1) the infected service or process cannot have elevated privileges because it is running with restricted privileges, (2) the infected service or process cannot have permission to access resources it does not directly need, and (3) the infected service or process cannot persist on its own through reboot. Specifically, services that have access to communication networks and external media ports (e.g., USB ports) have limitations on what they can do, and since these services are the only means by which an infection can enter the machine, limiting what these specific services can do (e.g., preventing them from writing to local memory storage or disk to enable elevated privileges, directly accessing the desktop, and preventing the infection from spreading between portable / external media and communication networks / data links) prevents the infection from spreading within the computer device or network if it does occur. As a result, the infection is automatically quarantined and removed by restarting the service. For services that only run when accessed (e.g., COM / DCOM services), the calling process obtains a clean copy of the service with each new call, thereby wiping out any infections within the service.

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

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

[0054] While the security technologies described in this specification have been described as being used in conjunction with networked process control devices and systems using fieldbuses and standard 4-20mA devices, they can, of course, be implemented within any type of control device using any other process control communication protocol or programming environment, and can be used with any other type of device, functional block, or controller. Furthermore, the security technologies described herein can be implemented within any other type of computer device, including computer devices that are not part of a process control system. Although the software security architectures described herein are preferably implemented in software, they can be implemented in hardware, firmware, etc., and can be executed by any other processor associated with a computer device. Thus, the methods described herein can be implemented within a standard multipurpose CPU, or, if desired, on specially designed hardware or firmware, such as an ASIC. When implemented in software, the software can 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 a process control system via any known or desired delivery method, including, for example, a computer-readable disk or other transportable computer storage device, or it may be modulated via a communication channel such as a telephone line or the internet.

[0055] Therefore, while the present invention has been described with reference to specific examples, this is intended to be merely illustrative and not to limit 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] (Note 1) A computer device, Processor and A computer device comprising an operating system that runs on the processor according to 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 pre-configured set of operating system privileges associated therewith, and the pre-configured set of operating system privileges for each of the plurality of custom service accounts is defined based on the operating system privileges required by the service assigned to the custom service account, and the custom service accounts do not have bidirectional logon privileges. (Note 2) The computer device as described in Appendix 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 the privilege to write to the local memory storage unit. (Note 3) The computer device as described in Appendix 2, wherein the computer device further includes an external media port, and one or more of the service processes that can communicate with the communication port do not have the privilege to communicate with a removable storage unit via the external media port. (Note 4) The computer device as described in Appendix 2, wherein the computer device further includes an external media port, and one or more of the service processes that can communicate with the communication port do not have the privilege to communicate directly with further service processes that have the privilege to communicate with a removable storage unit via the external media port. (Note 5) The computer device according to Appendix 4, further comprising an external media port and a local memory storage unit, wherein one of the service processes capable of communicating with the removable storage unit via the external media port does not have the privilege to write to the local memory storage unit. (Note 6) The computer device according to Appendix 5, wherein the computer device further includes a communication port, and one or more of the service processes that can communicate with a removable storage unit via the external media port do not have the privilege to communicate directly with further service processes that have the privilege to communicate via the communication port. (Note 7) A computer device as described in Appendix 1, further including a desktop environment, wherein the operating system runs to enhance a service namespace separate from the desktop namespace, and operates to run the service processes within the service namespace and one or more desktop applications within the desktop namespace. (Note 8) The computer device described in Appendix 7, wherein the operating system reinforces the requirement that processes running within the desktop namespace must communicate with processes running within the service namespace via inter-process communication. (Note 9) The computer device as described in Appendix 7, wherein the operating system runs on the processor according to configuration data for implementing configuration data to implement desktop processes, the configuration data causes each of the desktop processes to be assigned to one of a plurality of user accounts, each having a pre-configured set of operating system privileges associated therewith, and the pre-configured set of operating system privileges for each of the plurality of user accounts includes bidirectional logon privileges. (Note 10) The computer devices described in Appendix 9, wherein the aforementioned set of operating system privileges assigned to a standard user account does not include elevated or administrative operating system privileges. (Note 11) The computer devices described in Appendix 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 applications are started has elevated operating system privileges, and processes started by processes running within the desktop namespace take over the privileges of the starting process. (Note 12) The computer device described in Appendix 9, wherein the operating system reinforces the rule that processes running within the desktop namespace cannot be elevated in operating system privileges without the explicit authorization of an authenticated user whose account has elevated privileges. (Note 13) The computer device described in Appendix 7, wherein the operating system reinforces the requirement that all processes running within the service namespace must communicate with other processes running within the service namespace via inter-process communication. (Note 14) The computer device according to Appendix 7, further comprising a local memory storage unit for storing service files or service folders, wherein the operating system reinforces rules preventing processes running within the desktop namespace from writing to the service files or service folders stored in the local memory storage unit. (Note 15) The computer device described in Appendix 7 further includes a desktop containing a user interface within the desktop namespace, and further reinforces the rules that the operating system prevents any service process from directly accessing the desktop. (Note 16) The computer device described in Appendix 7, wherein messages originating from a desktop application include user ID information that identifies the user of the desktop application, and the user ID information follows the messages through multiple processes to their final destination, including through a service process that accesses a communication port to send the messages via a communication link. (Note 17) The computer device described in Appendix 16, to which the user ID information is associated with one or more processes used to forward the message to a message recipient, and which does not control operating system privileges and / or access permissions, but which controls access permissions for the user ID information to process the controlled object. (Note 18) A computer device, Processor and Communication port and Local memory storage unit, A computer device comprising: an operating system that runs on the processor according to configuration data for implementing a service process, including a service process that can communicate with the communication port, wherein the service process that can communicate with the communication port does not have the privilege to write to the local memory storage unit. (Note 19) The computer device described in Appendix 18, wherein the local memory storage unit stores service process files or service process folders. (Note 20) The computer device described in Appendix 19, wherein the local memory storage unit further stores desktop application files. (Note 21) The computer device according to Appendix 18, wherein the computer device further includes an external media port, and one of the service processes capable of communicating with the communication port does not have the privilege of communicating with a removable storage unit via the external media port. (Note 22) The computer device according to Appendix 18, wherein the computer device further includes an external media port, and one of the service processes capable of communicating with the communication port has the privilege of communicating with a removable storage unit via the external media port, but does not have the privilege of communicating directly with a further service process. (Note 23) The computer device as described in Appendix 22, wherein the further service process, which is able to communicate with the removable storage unit via the external media port, does not have the privilege to write to the local memory storage unit. (Note 24) A computer device as described in Appendix 18, further including a desktop environment, wherein the operating system runs to enhance a service namespace separate from the desktop namespace, and operates to run the service processes within the service namespace and one or more desktop applications within the desktop namespace. (Note 25) The computer device described in Appendix 24, wherein the operating system reinforces the requirement that processes running within the desktop namespace must communicate with processes running within the service namespace via inter-process communication. (Note 26) A computer device as described in Appendix 25, wherein a desktop application is assigned a set of operating system privileges that are configured separately from the set of operating system privileges associated with the user account that starts the desktop application, and the set of operating system privileges to which the desktop application is assigned does not include administrator operating system privileges. (Note 27) The computer device described in Appendix 25, wherein the operating system reinforces the rule that the desktop application cannot be elevated in terms of operating system privileges. (Note 28) The computer device described in Appendix 25, wherein the operating system reinforces rules preventing the desktop application from writing to service files or service folders stored in the local memory storage unit. (Note 29) The computer device described in Appendix 24, wherein a message originating from a desktop application includes user ID information that identifies the user of the desktop application, and the user ID information follows the message through the service process that accesses a communication network port to transmit the message over the communication network. (Note 30) A computer device as described in Appendix 18, further including a desktop with a user interface, wherein the operating system reinforces rules preventing any service process from directly accessing the desktop. (Note 31) A computer device, Processor and External media port, Local memory storage unit, A computer device comprising: an operating system that runs on the processor according to configuration data for implementing a service process, the service process which is 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 the privilege to write to the local memory storage unit. (Note 32) The computer device described in Appendix 31, wherein the local memory storage unit stores service process files or service process folders. (Note 33) The computer device described in Appendix 32, wherein the local memory storage unit further stores desktop application files. (Note 34) The computer device according to Appendix 31, wherein the computer device further includes a communication port, and one of the service processes capable of communicating with removable memory via the external media port does not have the privilege to communicate directly with a further service process that has the privilege to communicate via the communication port. (Note 35) A computer device as described in Appendix 31, further including a desktop environment, wherein the operating system runs to enhance a service namespace separate from the desktop namespace, and operates to run the service processes within the service namespace and one or more desktop applications within the desktop namespace. (Note 36) The computer device described in Appendix 35, wherein the operating system reinforces the requirement that processes running within the desktop namespace must communicate with processes running within the service namespace via inter-process communication. (Note 37) A computer device as described in Appendix 36, wherein a desktop application is assigned a set of operating system privileges that are configured separately from the set of operating system privileges associated with the user account that starts the desktop application, and the set of operating system privileges to which the desktop application is assigned does not include administrator operating system privileges. (Note 38) The computer device described in Appendix 37, wherein the operating system reinforces the rule that the desktop application cannot be elevated in terms of operating system privileges. (Note 39) The computer device described in Appendix 31 further includes a desktop with a user interface, and further includes rules that the operating system reinforces to prevent any service process from directly accessing the desktop. (Note 40) A computer device, Processor and External media port, Communication port and A computer device comprising: an operating system that runs on the processor according to configuration data for implementing a service process, which includes 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 the privilege to access the communication port. (Note 41) The computer device according to Appendix 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. (Note 42) The computer device described in Appendix 40, further including a desktop environment, wherein the operating system runs to enhance a service namespace separate from the desktop namespace, and operates to run the service processes within the service namespace and one or more desktop applications within the desktop namespace. (Note 43) The computer device described in Appendix 42, wherein the operating system reinforces the requirement that processes running within the desktop namespace must communicate with processes running within the service namespace via inter-process communication. (Note 44) The computer device described in Appendix 40, which reinforces the requirement that the operating system must communicate with other services via inter-process communication. (Note 45) A computer device, Processor and Includes an operating system that runs on the processor according to configuration data for implementing a service process and one or more desktop processes, A computer device in which the operating system runs to enhance a service namespace separate from the desktop namespace, and runs 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 within the desktop namespace via inter-process communication. (Note 46) The computer device described in Appendix 45, wherein one or more desktop applications are assigned a set of operating system privileges, which are configured separately from the set of operating system privileges associated with the user account that starts the desktop applications. (Note 47) The computer device described in Appendix 45, wherein one or more desktop applications are assigned the same set of operating system privileges, independent of the operating system privileges associated with the user account that initiates the desktop applications. (Note 48) The computer device described in Appendix 47, wherein the set of operating system privileges to which the desktop application is assigned does not include administrator operating system privileges. (Note 49) The computer device described in Appendix 48, wherein the set of operating system privileges to which the desktop application is assigned is an operating system privilege associated with a regular user. (Note 50) The aforementioned operating system reinforces the rule that desktop applications cannot be elevated in terms of operating system privileges, as described in Appendix 47. (Note 51) The computer device described in Appendix 45, wherein the computer device includes a local memory storage unit, and the operating system reinforces rules preventing desktop applications from writing to service files or service folders stored within the local memory storage unit. (Note 52) The computer device described in Appendix 45 further includes a desktop with a user interface, and further includes rules that the operating system reinforces to prevent any service process from accessing the desktop. (Note 53) The computer device described in Appendix 45, wherein a message originating from a desktop application includes user ID information that identifies the user of the desktop application, and the user ID information follows the message through a plurality of processes associated with sending the message. (Note 54) The computer device described in Appendix 53, wherein the user ID information does not control the operating system privileges associated with one or more processes used to forward the message to the message recipient. (Note 55) The computer device according to Appendix 45, further comprising a communication port and a local memory storage unit, wherein one of the service processes capable of communicating with the communication port does not have the privilege to write to the local memory storage unit. (Note 56) The computer device according to Appendix 45, wherein the computer device further includes an external media port, and one of the service processes capable of communicating with the communication port does not have the privilege of communicating with a removable storage unit via the external media port. (Note 57) The computer device as described in Appendix 45, further comprising a communication port, a local memory storage unit, and an external media port, wherein one of the service processes capable of communicating with the communication network port does not have the privilege to write to the local memory storage unit or the privilege to communicate with the 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 the privilege to write to the local memory storage unit and does not have the privilege to communicate with the communication port, and one of the service processes capable of communicating with the communication port does not have the privilege to communicate directly with one of the service processes capable of communicating with the removable storage unit via the external media port. (Note 58) A computer device, Processor and Includes an operating system that runs on the processor according to configuration data for implementing a service process and one or more desktop processes, A computer device in which the operating system enhances operating system privileges for the service processes based on a custom service account to which each service process is assigned, regardless of the process that invokes the service process, and the operating system enhances 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, which is used for the desktop application, regardless of which set of user accounts invokes the desktop application, and the message is sent to a receiving process such that the message includes a user ID that identifies the user of the desktop application, and the user ID is carried along 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. (Note 59) The computer device described in Appendix 58, wherein the user ID information of the user ID follows the message through multiple processes to their final destination, including through a service process that accesses the communication port in order to transmit the message via a communication link. (Note 60) A computer device as described in Appendix 59, which does not control the operating system privileges and / or access permissions, to which the user ID information is associated with one or more processes used to forward the message to the message recipient. (Note 61) The computer device described in Appendix 60, which controls access permissions for processing a controlled object in a process control network, based on the aforementioned user ID information. (Note 62) The computer device described in Appendix 58, wherein the standard set of operating system privileges defined for the desktop application does not include administrator operating system privileges. (Note 63) The aforementioned operating system reinforces the rule that desktop applications cannot be elevated in terms of operating system privileges, as described in Appendix 62. (Note 64) The computer device described in Appendix 58, wherein the computer device includes a local memory storage unit, and the operating system reinforces rules preventing desktop applications from writing to service files or service folders stored in the local memory storage unit. (Note 65) A computer device as described in Appendix 58, further including a desktop with a user interface, wherein the operating system reinforces rules preventing any service process from accessing the desktop. (Note 66) The computer device described in Appendix 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. (Note 67) The computer device according to Appendix 58, further comprising a communication port and a local memory storage unit, wherein one of the service processes capable of communicating with the communication port does not have the privilege to write to the local memory storage unit. (Note 68) The computer device according to Appendix 58, wherein the computer device further includes an external media port, and one of the service processes capable of communicating with the communication port does not have the privilege of communicating with a removable storage unit via the external media port. (Note 69) The computer device as described in Appendix 58, further comprising a communication port, a local memory storage unit, and an external media port, wherein one of the service processes capable of communicating with the communication port does not have the privilege 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 the privilege to write to the local memory storage unit, and one of the service processes capable of communicating with the communication port does not have the privilege to communicate directly with one of the service processes capable of communicating with a removable storage unit via the external media port. (Note 70) The computer device described in Appendix 58, wherein the operating system runs to enhance a service namespace separate from the desktop namespace, and runs 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 within the desktop namespace via inter-process communication.

Claims

1. A computer device, Processor and Includes an operating system that runs on the processor according to configuration data for implementing a service process and one or more desktop applications, The service process provides services to one or more desktop applications. A computer device in which the operating system operates to separate the desktop namespace from the desktop namespace and the service namespace, and to prevent service processes in the service namespace from directly accessing objects in the desktop namespace, and one or more desktop applications in the desktop namespace from directly accessing objects in the service namespace, by restricting communication between the service processes and one or more desktop applications to inter-process communication, and when one or more desktop applications in the desktop namespace communicate with external media or a communication network, by restricting one or more desktop applications to communicate with the external media or the communication network via a service process that includes external media access or a service process that includes communication access, which is included in the service namespace.

2. The computer device according to claim 1, wherein one or more desktop applications are assigned a restricted set of operating system privileges from the set of operating system privileges associated with the user account that initiates one or more desktop applications.

3. The computer device according to claim 1 or 2, further comprising a desktop including a user interface, wherein the operating system implements rules to prevent any service process from directly accessing the desktop.

4. The computer device according to any one of claims 1 to 3, wherein the computer device includes a local memory storage unit, and the operating system implements rules to prevent one or more desktop applications from writing to service files or service folders stored in the local memory storage unit.

Images