Process control software security architecture based on least privilege

Abstract

A process control system software security architecture that more effectively prevents zero-day or other types of malware attacks by implementing the use of "least privilege" when executing applications and services running within a computer device. The least privilege-based architecture separates "service" processes from desktop applications running on behalf of a logged-in user by partitioning the global namespace of the software system into a service namespace and a logged-in user namespace, and by strictly controlling the communication between applications and services in these different namespaces using inter-process communication. In addition, the security architecture uses custom accounts to ensure that each service process has the minimum set of privileges required to perform its functions, regardless of the privileges associated with the calling application or user.

Description

[0001] This application is a divisional application of the patent application with the same name as application number 201510441630.7 filed on July 24, 2015. Technical Field

[0002] The present application relates generally to process plant computer systems and, more particularly, to methods and apparatus for securing the operation of software processes within a device (eg, a computer device) in a process or plant environment. Background Art

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

[0004] A process controller, typically located within a process plant environment, receives signals indicative of process measurements or process variables made by or associated with field devices and / or other information related to the field devices and uses the information to execute controller applications. The controller applications implement, for example, making process control decisions, generating control signals based on the received information, and communicating with field devices (e.g., and Fieldbus field devices) in different control modules that cooperate with each other. The control modules in the process controller send control signals to the field devices through communication lines or other signal paths to thereby control the operation of the process.

[0005] Information from the field devices and process controllers is also typically made available to one or more other hardware devices (e.g., operator workstations, maintenance workstations, servers, personal computers, handheld devices, data historians, report generators, centralized databases, etc.) via the process control network. The information transmitted over the network enables an operator or maintenance personnel to perform desired operations on the process and / or view the operation of the plant. For example, the information allows an operator to change the settings of a process control routine, modify the operation of a control module within a process controller or smart field device, view the current state of a process or the state of a specific device within a process plant, view alarms generated by field devices and process controllers, simulate the operation of a process for the purpose of training personnel or testing process control software, diagnose problems or hardware failures within a process plant, etc.

[0006] Field devices usually communicate with other hardware devices through a process control network (which can be, for example, a LAN configured with Ethernet). The network relays process parameters, network information, and other process control data through various network devices and relays them to various entities in the process control system. Common network devices include network interface cards, network switches, routers, servers, firewalls, controllers, and operator workstations. Network devices usually help data flow through the network by controlling the routing, frame rate, timeout, and other network parameters of the data flow, but they do not change the process data themselves. As the scale and complexity of the process control network grow, the number and type of network devices grow accordingly. As a result of the growth of systems and networks, security and management in these complex systems may become increasingly difficult. For example, each network device may include one or more communication ports, which provide access points or ports for physically interconnecting process control system components and other network devices to each other through the network. However, some of these ports or connections can be used to connect control devices to publicly accessible networks (e.g., the Internet), and to connect portable memory devices to control system devices. Thus, an open port on a device may become an access point for network expansion by adding other devices, or may allow malicious or non-malicious entities to access the network and initiate undesirable and potentially harmful network traffic or introduce malware (e.g., including malicious programs, spyware or data collection programs, adware, or other unwanted and potentially harmful dangerous software) that may cause serious problems within the plant control system. As the number of network devices and associated access points increases, it quickly becomes impractical to effectively monitor or control access to all ports on devices within a network that controls communications for an entire complex process control system.

[0007] Likewise, in a typical industrial control system, workstations / servers are strategically placed between the plant network and embedded devices (e.g., controllers, PLCs, RTUs) that perform control and data acquisition functions, and therefore the primary security goal of these workstations / servers is to prevent malware from entering the control system and adversely affecting the embedded devices, as well as to prevent malware from changing configuration and historical data stored in the plant database. Although multiple security features (e.g., "anti-virus" software and "whitelists") can be used to address this goal, these security features are often insufficient. For example, anti-virus software cannot combat "zero-day" viruses, and whitelists only prevent unauthorized applications from running. In addition, some of these features are too invasive to be practically operational in a process control system because they have the potential to block plant operator activities.

[0008] Generally speaking, malware (e.g., malware at the core of a zero-day attack) is typically introduced into a control system at a specific device via an external memory device (e.g., a removable flash drive) or via a communication connection by operating an application or service with privileges or permissions to access these memory devices, network ports, or direct data links. (For the purposes of this patent, a communication connection includes a connection made via a communication network connection or via a direct data link such as a modem connection). Thereafter, the malware can be spread to other devices (e.g., via a communication or portable memory device) and / or executed within the device using the security privileges of the application or service infected by the malware. In addition, the malware can be locally self-perpetuated to allow it to be executed again after a reboot. In some cases, the malware can use the privileges of the account in which the application or service is executed to upgrade the privileges of the host (e.g., the infected application or service), and by doing so, the malware may be able to perform actions or operations in a process control device or system that requires higher privileges, and thereby is generally more harmful to the control system operation. In any event, a zero-day attack that infects an already running application causes serious problems in a process control system because there is no good technology for preventing these types of attacks. However, within a process plant these attacks can have severe and potentially destructive, even fatal, effects when they disrupt the ongoing operation of the plant control system. Summary of the invention

[0009] Process control systems use a new set of security features or software security architecture that more effectively prevents zero-day or other types of malware attacks. In general, the new security features or architecture implements what is referred to herein as "least privilege" when executing applications and services within any specific control system device (e.g., within a workstation, server, database, controller, field device, etc.) to reduce the impact of malware that may infect a workstation, server, or other device. The term "privilege" herein includes both operating system privileges / rights and access control permissions. For example, a user may be granted the right to remotely log in or impersonate another user (privilege) and also be granted access (permission) to read / write / execute specific files.

[0010] In summary, a least privilege based security feature or architecture separates "service" processes from desktop applications running on behalf of logged-in users (locally or remotely) by, for example, partitioning the global namespace of a device (e.g., a controller, workstation, server, etc.) into a service namespace and, if present (e.g., in a desktop application), into a logged-in user namespace. The architecture then uses inter-process communication (rather than shared memory) to strictly control communication between processes (e.g., applications and services) in these different namespaces in order to prevent infected services or applications from being able to directly infect or damage other services or applications. Specifically, the new security architecture uses such namespace partitioning to prevent desktop applications from directly accessing objects in a service namespace and vice versa.

[0011] Further, the new security architecture limits the privileges granted to services and desktop applications in a manner that limits or reduces the ability of infected services or applications to adversely affect or infect other services or applications. In general, the security architecture limits the operating system privileges of a service or application or other process to a specified subset of the privileges given to the account under which the service or application or other process runs or is generated, limits the privileges of applications launched by a logged-in user to a subset of the privileges associated with the user, and prevents the elevation of privileges from being performed via a desktop application (running under the logged-in user). In one case, the software security system enforces the restriction that access to a communication port or an external media port (e.g., to a removable storage device connected via an external media port such as a USB port) must be performed through a service with limited privileges (and never by a desktop application), wherein the service's limited privileges prevent the service from writing to a local data storage device (e.g., disk), from communicating via the other of a communication network port or a removable media port, or from acting with administrative privileges. In this way, if the service is infected, the infection becomes benign because the infection cannot store itself on the local disk or other storage, cannot perform administrative functions, cannot access the desktop, cannot be propagated via the communications network if it came from a removable storage device via the external media port, and cannot be stored on a removable storage device via the external media port or propagated to another communications connection if it came from a communications connection via the communications port.

[0012] Thus, the new security architecture uses access controls that enforce which user accounts and which 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. To do this, the security architecture includes or uses accounts that are generally referred to as "groups," which allow user accounts and service accounts to belong to inheritance from other group accounts.

[0013] The combination of one or more of these security features results in a more secure software environment within a process control system or process plant that is less susceptible to virus attacks (e.g., zero-day virus attacks) and other malware because these security features, either alone or in combination, make it difficult if not impossible for malware to be introduced into the system through the operation of a desktop application that accesses a network connection or a removable / portable storage media connection (e.g., a USB port). These security features also limit the ability of malware to be introduced into an internal data storage device via a network or external device, limit the ability of malware to elevate the privileges of a service so that the service can access devices, storage media, or processes that are not required by the application requesting the service, etc.

[0014] Thus, using these features, the new software architecture design divides (isolates) services and desktop applications running in process control automation system workstations and in servers to achieve the purpose of reducing their malware profiles or surfaces. In addition, if a service or other process generated by a service is infected, it will not have the necessary privileges to perform actions it has not done, and it will not have permission to access resources that it does not directly need. In addition, if a desktop application is infected, the desktop application can neither directly access the privileged functions of the operating system nor write directly to the network or directly to a removable storage device connected via an external media port. Instead, the desktop application must request that the action be executed on behalf of the desktop application by services and processes generated by them that are designed to enable and provide additional access control levels to privileged functions and resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is an exemplary block diagram of a process plant having a distributed process control system and process automation network, which includes one or more operator and maintenance workstations, servers, controllers, field devices, and other network devices configured to implement the least privilege-based software security architecture and functionality described herein;

[0016] Figure 2 is an exemplary block diagram of a workstation / server / controller device within a process control plant illustrating various namespaces and security restrictions implemented with respect to applications, services, and other processes executing in a process control software architecture to implement improved security functionality;

[0017] Figure 3A diagram showing accounts including grouped accounts and customized accounts that define sets of privileges associated with various different applications and services in accordance with the least privilege software security architecture described herein;

[0018] Figure 4 It shows Figure 2 An exemplary block diagram of the software and hardware components of one of the workstations of the system, showing the use of Figure 3 The communication connection between various devices and applications of your account. DETAILED DESCRIPTION

[0019] Figure 1 is a schematic representation of a process control system or process automation system 100 disposed within, for example, a process plant, wherein various computer devices may be subjected to various software security features to enhance software security and facilitate management and maintenance of the system / network. More specifically, the process control system 100 includes one or more process controllers 110 and one or more process plant databases 112 (e.g., data historians) communicatively connected to one or more host workstations or computers 120-122 (which may be any type of personal computer, workstation, server, etc.) via a process control communication network 130. The controller 100 and the database 112 may be connected to the communication network or bus 130 (which may be, for example, an Ethernet communication network) via one or more network interface cards 132. Further, the controller 110 may be connected to field devices 140, 143, and 154 within the process plant or control system via an input / output (I / O) card 142. The database 112 may include one or more data historians, which may be any desired type of data collection unit or memory device having any desired type of memory and any desired or known software, hardware, or firmware for storing data. In addition, the database 112 may be separate from or part of one or more workstations or servers 120-122. For example, the database 112 may be a DeltaV TM The controller 110 of the controllers is communicatively connected to the host computers 120-122 via, for example, an Ethernet connection 130 or any other desired communication network, through one or more network cards or devices 132. The network devices 132 may include one or more of 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.

[0020] like Figure 1As shown, the server 122 is connected to various network devices, which may be physically located in any part of the communication or process control network and within any part of the process plant, and may include any part of the security functions described herein. In this example, the communication network 130 is typically a closed local area network (LAN) connected only to the devices involved in the control system and may be implemented using hardwired or wireless technology. In addition, the controller 110 uses a protocol that is compatible with, for example, a standard 4-20mA device protocol, an Ethernet protocol, and / or a protocol such as Fieldbus protocol (Fieldbus), Protocol, Wireless The field device 140 may be communicatively connected to any desired hardware or software associated with any intelligent communication protocol such as the WIRE® protocol, the Profibus protocol, the CAN protocol, or the like.

[0021] Field devices 140, 143, and 154 may be any type of device, such as sensors, valves, transmitters, positioners, etc., and I / O card 142 may be any type of I / O device that complies with any desired communication or controller protocol. Figure 1 In the illustrated embodiment, field device 140 is a HART or 4-20mA device that communicates with a modem or I / O card 142 via a standard HART or analog 4-20mA line 141, while field device 143 is an intelligent device that communicates with one of the I / O cards 142 via a digital bus 145 or an I / O network using a fieldbus protocol, e.g. Fieldbus field devices. Of course, field devices 140 and 143 may comply with any other desired standard or protocol, including any standard or protocol developed in the future. In addition, field devices 140 and 143 may communicate via any desired wireless communication standard (e.g., Protocol) is wirelessly connected to the controller 110.

[0022] In addition, one or more of the field devices 154 may be connected to the digital bus 145 via a specialized network device (e.g., gateway 153). For example, the field device 154 may only understand HART commands, and the I / O network 145 may implement the PROFIBUS protocol. For this purpose, the gateway 153 may provide bidirectional PROFIBUS / HART conversion.

[0023] The controller 110 may be one or more of a plurality of distributed controllers in a plant having one or more processors therein, and the controller 110 implements or monitors one or more process control routines. The routine may include one or more control loops stored in or associated with the controller 110. The controller 110 also communicates with devices 140, 143, 154 via a network 130 and associated network devices 132, and communicates with a host computer and server 120-122 and a data historian or other database 112 to control the process in any desired manner. It should be noted that any control routine or element described herein may have its parts implemented or executed by different controllers or other devices if desired. Similarly, the control routines and elements described herein to be implemented in the process control system 100 may take any form including software, firmware, hardware, etc. For the purposes of this discussion, a process control element may be any component or portion of a process control system, including, for example, a routine, block, or module stored on any computer-readable medium. The control routine, which may be any part of a module or control program such as a subroutine, a portion of a subroutine (e.g., a line of code), etc., may be implemented in any desired software format, such as using ladder logic, sequential function charts, function block diagrams, object-oriented programming, or any other software programming language or design paradigm. Similarly, the control routine may be hard-coded into, for example, one or more EPROMs, EEPROMs, application specific integrated circuits (ASICs), or any other hardware or firmware elements. Further, the control routine may be designed using any design tool including a graphical design tool or any other type of software / hardware / firmware programming or design tool. Thus, the controller 110 may be configured to implement a control strategy or control routine in any desired manner.

[0024] Furthermore, if Figure 1 As shown, an additional communication network 160 is connected to the server 122 and workstations 120 and 121 to enable the process control system server 122 and workstations 120 and 121 to connect to the plant information technology system, to business systems or other networked systems within the plant.

[0025] Generally speaking, workstations and servers 120-122 and Figure 1 The other devices in the network implement what is referred to herein as a least privilege based security architecture, wherein the least privilege based security architecture (1) operates to connect the Figure 1The invention relates to the isolation or separation of services and other lower-level processes executed in various computing devices (e.g., workstations, servers, databases, controllers, etc.) from desktop applications, and (2) limiting the privileges of services and desktop applications to only those required by these processes to perform their functions. This least-privilege-based security architecture helps prevent malware from being imported into process control system devices and instantiated or executed within process control system devices. In general, desktop applications within any computing device can be isolated from services or other processes by dividing the global namespace of each computer device of the process control system into one or more service namespaces and one or more user (desktop application) namespaces. Such division prevents desktop applications from being able to directly access objects defined in the namespace used by the service (e.g., mutexes), and prevents services from being able to directly access objects defined in the desktop namespace used by the desktop application (e.g., in a desktop environment). Instead, all communications between the various desktop applications and services implemented by the operating system must communicate via well-known and trusted inter-process communications (IPC), which provides a trusted messaging-based communication structure that limits communications to the devices / workstations / servers in which the communications are implemented, and thereby prevents or reduces the ability of one application or service to damage, infect, or interfere with the operation of other applications and services (e.g., memory spaces). In this way, malware introduced via a desktop application cannot be easily imported into a service or other lower-level process, and vice versa.

[0026] Further, the security-based architecture described herein limits / restricts the ability of malware to be introduced into or spread within a system by limiting the privileges granted to each service and desktop application to a specified subset of privileges, for example, to a subset of the privileges granted to the logged-in user account under which the service and application runs or is called. For example, where a service running normally under an administrator account typically has all the privileges of the administrator, the new secure software architecture only utilizes the specific privileges required by the service to perform the functions it is designed to perform rather than utilizing all administrator privileges to generate or run some or all services. Further, services with communication network access (via a communication network port) or access to a removable data storage device via a removable storage port (e.g., a USB port) run under an account with strictly restricted privileges, wherein these services do not have administrative privileges, do not have local disk (i.e., local storage) storage (write) privileges, and cannot communicate directly via the other of the communication network port or the removable storage port. Such a feature prevents or at least reduces the ability of malware to use a service invoked by a user with higher privileges to gain access to devices or functionality not required by the service itself, thereby limiting the ability of malware to infect other devices or execute higher privileged commands or services simply because the service is executed or invoked under the logged-in user account.

[0027] Likewise, security features can automatically limit the privileges of applications (e.g., desktop applications launched by a logged-in user) to prevent the elevation of privileges. In some cases, the security architecture can prevent any or all desktop applications from being able to elevate privileges, such that a request for a user to elevate privileges will indicate that the application has been infected. Generally speaking, privilege elevation by desktop applications (running under a logged-in user account) currently typically requires the approval of an authorized user to perform the operation requiring elevation. Newer operating systems typically implement this feature by granting only standard user privileges (non-elevated / administrator privileges) to applications launched by logged-in users, including administrators, and requiring that elevation of privileges be specifically authorized by the user. The new architecture can prevent privilege elevation of desktop applications in any event, thereby providing another level of security that limits the ability of malware to automatically elevate privileges within the system and use the elevation to infect additional processes or devices.

[0028] Likewise, the security architecture described herein may also use access controls that enforce which user accounts and which processes (services or desktops) are authorized to access secure objects through calls to the operating system and its subsystems (e.g., files, mutexes, events); may use mechanisms that prevent lower privileged processes from injecting code into higher privileged processes; and may use group-based accounts, generally referred to as "groups," to allow inheritance of privileges / permissions. For example, user A may belong to group B, and group B belongs to group C. User A therefore inherits privileges and permissions from both B and C. However, while these privileges are shared or portable on the logged-in user account side, these privileges cannot be propagated to services or processes that receive messages from applications running under these accounts, which prevents services and processes (e.g., those instantiated by the operating system in response to messages received from these applications) from being able to have elevated privileges. Thus, in general, privileges for services and processes generated or executed by the operating system are defined independently of privileges defined for a logged-in user account, such that services and processes (and in many cases, applications) running under a higher-privileged account are restricted to a subset of privileges, i.e., the minimum privileges necessary for the intended operation of the service, application, or other process.

[0029] In general, refer to Figure 2 , the security features and security architecture described herein are shown as being implemented in a server or workstation or controller, e.g. Figure 1 However, it should be understood that the security concepts described herein can be implemented in the same or similar manner in other types of computer devices or machines (e.g., workstations, database servers, etc.). More specifically, Figure 2 A workstation / server / controller 220 is shown connected to zero, one, or more networks / data links 230, one of which may be, for example, Figure 1 In addition, in this case, the server / workstation 220 is connected to one or more local data storages 235, which are located in Figure 2 20 is shown as being internal to or directly connected to the workstation / server / controller 220. In addition, the workstation / server / controller 220 may include or be connected to a user interface or display device 237, and include zero, one or more removable media ports 239. The removable media ports 239 through which external or removable memory devices may be connected to the device 220 may include or be any type of memory access port, including a USB port, a standard or proprietary connection to a CD or DVD drive, an external hard drive, a flash or solid-state memory drive, a disk drive, etc. Figure 2As shown, data, programs, etc. can be provided to or exported from the workstation / server / controller 220 via a removable or portable memory device (e.g., USB flash drive 240, DVD or CD 241, etc.) via one of the ports 239.

[0030] In addition, the workstation / server / controller 220 includes zero, one 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 communication network, such as an Ethernet network, a WiFi network, an Internet Protocol network, or any other local or wide area network or data link.

[0031] like Figure 2 As also shown, the workstation / server / controller 220 is divided into two types of namespaces, including a service namespace 250 and zero, one or more login user namespaces (in Figure 2 Of course, there may be a different login user namespace (also referred to herein as a user namespace) for each different user of the multiple users logged into the workstation / server / controller 220, and some devices (e.g., servers) may not have a login user namespace. Figure 2 As also depicted in FIG. 2 , a collection of desktop applications 258 exist and run in user namespace 252, while services 260 exist and execute in service namespace 250. Generally speaking, desktop applications 258 are processes that execute in user namespaces, while service processes, referred to herein as services, are processes that run independently of logged-in users and are typically generated or run by the operating system (or one of its agents, such as the Windows Service Control Manager) in response to configuration settings, calls to the operating system, request messages (e.g., Windows COM / DCOM messages) sent to the service process. Separate processes are independent processes that execute in the same namespace as the process that starts them (e.g., a service process or a desktop application process). As an example, a separate process can be started in a service namespace and can be a process that implements reading of a USB or other local data storage device or connecting to a communication network in the manner described herein. Although services 260 are typically started automatically, these processes can be started in response to request messages sent by user processes or other services. However, as described in more detail herein, services 260 always run under a specified account, regardless of the user account of the process that launches them and regardless of how they are launched, whereas separate processes run or execute under the account of the process that launches them (e.g., a service or desktop application). Of particular note, Figure 2The services 260 in may include zero, one, or more service namespace processes 262 that are capable of accessing a network (via one of the communication ports 245), service namespace processes 264 that are capable of accessing a removable storage device via an external media port 239, and other service namespace processes 266 that are capable of accessing neither portable or local storage nor a communication network. Further, the local data storage device or memory 235 includes various types of files or folders, including service files or folders 270 created and used by the service namespace processes 260, and desktop files or folders 272 created and used by logged-in user namespace processes (e.g., by desktop applications 258).

[0032] from Figure 2 It should be understood that the workstation / server / controller computing environment is thus separated into multiple subspaces using different namespace rules, which are associated with separate namespaces for each of the logged-in users (or user groups), and separated into services (or separate processes generated by services) using the rules enforced by the operating system and its configuration data. The division of the global computing environment namespace into service and logged-in user (desktop application) namespaces prevents desktop applications from directly accessing objects defined in the service namespace (e.g., mutexes), and prevents service namespace processes from directly accessing objects defined for the logged-in user namespace (used by desktop applications) (e.g., desktops). In this way, services and desktop applications must communicate with each other (e.g., forced to communicate) or communicate with each other to reach objects created in each of those different namespaces. The feature prevents malware that may exist in a service or desktop application in one environment from creating or using objects in another namespace without going through the corresponding service or application in another namespace, which generally limits the malware from being able to damage other services or applications. This feature limits, for example, the ability of malware to create or infect objects in another environment, which limits the ability of malware to be established in or propagated to the control system via, for example, the communication network 230 .

[0033] The secure software architecture described above operates in various ways to improve the overall security of workstations / servers / controllers 220 used in a factory or other industrial automation system. Such security mechanisms are built to implement multiple rules or features, and the security mechanisms are generally applied to all computing devices or machines in the control system, including machines executing processes / applications developed by third parties (as well as processes / applications developed or provided by operating system vendors).

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

[0035] Likewise, these processes communicate with each other via trusted local inter-process communication (e.g., WCF named pipes, COM, etc.), except that processes requiring network access are not allowed to communicate directly with processes with access to portable or removable storage devices, and vice versa. Figure 2 This exception, shown by line 290 in FIG. 2 , is implemented to prevent malware read from a portable memory device from being forwarded to a communications network, and malware received from a communications network from being stored on a portable or removable memory device.

[0036] In addition, if Figure 2 As shown by the dashed line 291 in FIG. 29 , none of the processes 260 (e.g., processes 262, 264, 266) can directly access the desktop namespace 252 or objects in the desktop namespace 252. As a result, these processes provide services (and in particular, privileged services) to the desktop applications 258 only via trusted local inter-process communication 292, which is provided by the Figure 2 The lines going back and forth between the service 260 and the desktop application 258 are shown.

[0037] Additionally, all processes that require network access, or access to portable or removable storage devices (e.g. Figure 2 The processes 262 and 264) are executed or run under the following accounts: (1) cannot access the command shell, (2) cannot access programs that change the security configuration (policy settings and accounts) of the workstation / server / controller 220, and (3) is restricted from performing file system writes, the characteristics of which are Figure 2 As shown by the dashed line 294 in . As a result, only services 266 that cannot access the network (e.g., via port 245) or cannot access portable or removable storage (e.g., via port 239) can perform file system writes to data files 270 within database 235.

[0038] Further, there are various security features implemented in the desktop environment 252. In particular, all desktop applications, also referred to as interactive applications / processes, run or execute without elevated privileges, regardless of what user or login account is used to launch or invoke the applications or processes. Thus, in the event that a user with administrative privileges launches a desktop application, the desktop application is still executed with limited operating system privileges equivalent to a standard user, regardless of the privileges of the initiating user. Further, as described above, the desktop application 258 cannot directly access the communication network 230, but instead must communicate via inter-process communication with a service 262 in the service namespace 250 that provides access to the communication network. Similarly, the desktop application 258 cannot directly access the portable memory devices 240, 241, but instead must communicate (via inter-process communication) with a service 264 that provides access to these devices. In addition, the desktop application 258 is restricted from accessing directories and files owned by the system, which, if infected, could impair the performance / operation of the system. Thus, if Figure 2 As shown in line 296, desktop applications 258 can write to desktop folders and files 272, but cannot write to service folders and files 270. In addition, desktop applications 258 are designed to never require elevated privileges and cannot be elevated, regardless of the initiating user privileges. Likewise, desktop applications 258 can never impersonate another user and must communicate with each other via trusted local inter-process communication.

[0039] Further, all user identities are passed between services and processes 260 and desktop applications 258 via digitally signed identity assertions, and such identity assertions follow or flow with communications and through various processes and networks to enable verification of process control system permissions. For example, a process control system operator may make a request (via a desktop application) to, for example, write a parameter (e.g., a location point) in a process control device such as a controller. During the process of sending the request via a communication network to the process control device to implement the write, the request may require the invocation or generation of various services. The user identity assertion flows with the request through various processes for creating and forwarding the request via various machines in the process control network, so that the process control device implementing the change can verify that the request is from a user with appropriate permissions to make the change, and thereby can check and record changes close to the process performing the write operation. This feature ensures that the individual user performing the operation is accurately and correctly identified without the use of impersonation and / or delegation. In addition, this feature enables desktop applications or processes started by desktop applications (e.g., process control applications) to be started in the context of the logged-in user and to continue operating through a handover without being restarted by another user, because a handover does not require the logged-in user to log off. Instead, the new handover operator identifies himself to the process control system without having to log into the operating system. In this way, all desktop applications will run with the privileges of the logged-in user, and therefore, it does not matter which operator starts the desktop application, as long as the new operator identifies himself when using the application so that the appropriate identity statement flows with the process operation request. In addition, without this mechanism, services / processes / applications can only identify users with the following accounts: the service / process / application runs under this account or is called by this account. This feature is also important in control systems because the current user of the operator console may not be the logged-in user. This restriction eliminates the risk of having a stolen logged-in user identity, which is used in determining operating system privileges and access control permissions to prevent the access control permissions used to provide access to control system resources (e.g., parameters and alarms).

[0040] A method for realizing the above Figure 2The method of security features described is to use a more stringent method of defining the privileges and permissions granted to various applications and services within a control system based on a standard, open architecture operating system. In particular, currently, privileges and permissions are generally defined for users on a per-user basis, so that some users have more privileges and permissions than other users. In this architecture, applications (e.g., desktop applications and processes launched by them) are generally granted the privileges and permissions of the login account that launches or calls these applications or processes. On the other hand, many services (e.g., processes generated based on configuration settings, or in response to calls to the operating system from applications or from user requests, or for 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 in these systems are controlled by the account. More specifically, desktop applications are always launched under the account of the logged-in user, while services and processes are always launched under the account configured for them, and processes launched by other processes are always launched using the account under which the process that launched them runs. Therefore, it is common for services to run under standard OS service accounts or user accounts.

[0041] on the contrary, Figure 2 The security architecture of defines privileges and permissions for services differently than those defined for logged-in user accounts, and therefore does not allow services to run under user accounts with interactive logon privileges. That is, services always run under a special service account that does not have interactive logon privileges. In particular, Figure 2 The security architecture of this article can define custom service accounts with different or limited sets of privileges and permissions, and can be Figure 2Each of the services 260 is assigned to one or more of these custom service accounts to achieve the purpose of assigning privileges and permissions to these services. Each service is assigned to a custom service account with the minimum set of privileges required by the service. Services should not be assigned to custom service accounts with more privileges than the operation of the service requires. However, in order to reduce the large number of custom service accounts, services can be run under the following custom service accounts: the custom service account has more privileges than it needs only if the account is configured with a restricted service set that limits the privileges inherited from the custom account to only those privileges required by the service. In some cases, such as in the case of services that can access communication ports or external media ports, services can be assigned to the least privileged account with the further restriction that these services cannot write to local data storage devices (disks). On the other hand, desktop applications run with the privileges of the initiating user, but they should always be started with limited standard user privileges and can only be elevated when they need to be elevated and only then approved by the user. If the user does not have the necessary privileges, the user with the privileges should be required to approve the elevation. In this way, services and applications can have a limited set of privileges that limits the ability of malware to use this architecture to infect control systems.

[0042] Generally speaking, custom service accounts (and privileges for those accounts) can be defined and subsequently assigned to services, which can further limit the privileges of the custom accounts so that the service has only the privileges or permissions that the service needs to perform the tasks or functions for which it was designed.

[0043] Figure 3 A block diagram 300 illustrates exemplary interrelationships or associations of user accounts 306 that allow a user to log in and customize a service account 310 that may be used to configure or provide operating system privileges and permissions to services 312 and desktop applications 314 and other processes in addition to or separate from permissions or privileges associated with process control system permissions defined for the user login account.

[0044] like Figure 3 As shown, a set of user accounts 306 are defined, and as indicated by the dashed lines between the user accounts 306 and the group accounts 302, each user account 306 can belong to one or more group accounts 302. In this way, each user account will inherit the operating system privileges and permissions of any group account 302 with which it is associated or to which it belongs, and then pass those privileges / permissions on to the desktop application when the desktop application is launched by the associated logged-in user. Figure 3As also shown in FIG. 1 , a user account 306 may belong to multiple group accounts 302 and thereby inherit the privileges and permissions of multiple group accounts 302, which may also belong to or inherit from other group accounts 302. Similarly, as Figure 3 As shown, a collection of custom service accounts 310 is also established, each of which has various operating system privileges and permissions (including access permissions) within the operating system to perform activities, such as communication privileges, read / write privileges, access privileges, etc. Each custom service account 310 may belong to one or more group accounts 302 and thereby inherit the privileges of the one or more group accounts 302. Each of the various services 312 within the computing device and the processes launched by them is assigned to one (or possibly more than one) of the custom service accounts 310 and inherits or has the operating system privileges of the custom service account 310 to which these services 312 belong. In general, the operating system privileges and permissions provided for each custom service account 310 are defined individually and separately from the user account 306. In particular, the privileges and permissions of custom account 310 should be tailored (defined) specifically for service 312 and the processes it launches (e.g., separate processes, dependent processes), and should have only the operating system privileges and permissions necessary for service 312 and the processes it launches to operate to perform their intended functions, and no more, unless the service / process is configured to further define the privileges inherited from the custom service account.

[0045] By using user account 306 and custom service account 310, service namespace process 312 (i.e., an operating namespace in which services and processes started by services are running) and desktop namespace process 314 (i.e., an operating namespace in which desktop applications and processes started by them are running) can be associated with different custom accounts 310 or user accounts 306, so that a service called by a desktop application can be executed with different privileges from the calling desktop application. The expression "called by a desktop application" means that the service receives a remote procedure call message sent by the desktop application.

[0046] Furthermore, if Figure 3As shown, at a higher level, a set of group accounts 302 can be established to define a specific set of operating system privileges and permissions (including access permissions). Group accounts can be associated with zero, one or more custom services or user accounts within a computer device or within a process control plant or system as a whole (for example, using an active directory). Each group account 302 can include a specific set of operating system privileges and permissions that can be inherited by other group accounts, custom service accounts and / or user accounts that are members of the group account 306. Inheritance is achieved by making these accounts members of the group account. Thus, custom accounts 312 and user accounts 306 can belong to the same group 302 and thereby inherit the same operating system privileges and permissions. Group accounts 302 are thus different from roles that are commonly used in process control systems to define process control (different from operating system) privileges and permissions. Process control roles (different from operating system groups) tend to include groups of individuals (operators, configuration engineers, technicians, etc.) responsible for specific areas or functions of the plant. Although such different roles may define different process control system privileges and permissions for such persons, persons assigned to different roles often run under the same user login account and have the same set of operating system privileges and permissions, but have different process control system privileges and permissions. It should be understood that in any event, as understood, the group account 302 defines the following operating system privileges and permissions: which may be inherited by the custom service account 312 and / or user account 306 used to run the service namespace process and the desktop namespace process launched by its logged in user.

[0047] thus, Figure 3 Various services 312 and applications 314 are shown grouped under various accounts 302, 306, and 310, which are used to assign operating system privileges to the services and applications. Figure 3 The custom service account 310 shown in FIG. 1 is used only for the service process 312 and other processes in the service namespace, while the user account 306 is used only for processes in the desktop namespace (e.g., application 314). In the typical case, all processes in the desktop namespace (e.g., desktop application 314) start with the privileges of the "standard user" account 306A (a least privileged account), which does not include administrator privileges. In addition, the custom account 310 is defined to have only the additional privileges it needs. However, as Figure 3As shown, more than one service 312 can run under the same custom service account 310, and if a service 312 does not need all of the custom service account privileges, some of the privileges of the custom service account can be individually denied. However, for those services that are able to access a communication port or an external media port (e.g., a USB port), the services run under a custom service account that does not have elevated (e.g., administrator) privileges and has the further restriction that these services cannot write to a local (internal) data storage device or disk. It should be understood here that a local or internal data storage device is intended to mean a data storage device that is connected in a relatively permanent manner in a computer device, rather than being portable or easily removable in nature and thus not connected via an external media access port. Local memory or data storage devices generally include internal disk drives or internal random access memory.

[0048] Thus, based on the discussion provided above, it should be understood that operating system privileges, including access permissions, are granted to processes (e.g., services or desktop applications) that are completely unrelated to access controls used to grant / deny users access to process control system objects (e.g., setpoints, temperature & pressure measurements, and alarm thresholds). Access to process control objects requires that a separate user identity be passed along with the request to allow the process control device to verify the process control system permissions because the operating system, which enforces access permissions and operating system privileges, has no knowledge of the control system objects. As is known, control systems typically have a separate user manager that defines what each control system user can access in the control system, and user identity assertions are provided to enable the separate user manager to operate properly.

[0049] In any case, using this architecture, the permissions and privileges that a user has to access process control objects to perform actions, etc. in the process plant are not related to the privileges and permissions of services and applications running under the custom service account or user login account. This feature reduces or eliminates the ability of a compromised process to use operating system privileges and permissions inherited from a custom service account or user account under which the compromised process is running to access or corrupt the execution of process control objects.

[0050] like Figure 3Also shown, the execution engine 320 (e.g., an operating system execution engine) of a computer on which a process (e.g., a service or application, or a process started by a service or application) is executed uses the following rules to grant privileges to services 312 or applications 314 or processes started by them. Processes started directly by a logged-in user obtain the standard set of user privileges and permissions associated with a standard user account, even if the user has elevated privileges (e.g., an administrator). Services started by the operating system obtain the privileges and permissions of the custom service account to which the service belongs, reduced by any restrictions configured for the service. Processes started by a process obtain the current set of privileges and permissions of the process that started it. This organization enables each process (e.g., each service 312 or application 314 or a process started thereby) to run or execute with the minimum privileges required to perform the specific functions of the process. This functionality thereby limits the ability of malware that infects the service 312 or application 314, or processes launched thereby, to take actions that are not necessary for normal operation of the service 312 or application 314, and thereby limits the ability of malware to operate in a computer device or to spread within a process control system network to other process control system devices or other computer devices. Further, the execution engine 320 may not allow or may prevent privilege escalation within the desktop application 314 or service 312 to prevent malware from being able to defeat the privileged constructs of the operating system.

[0051] Figure 4 Schematic diagram of a computer system 400 is shown, which can implement the rules or configuration features described above with respect to improving the security of computer equipment or factory networks to limit the spread of malware or possible infection caused by malware. In particular, Figure 4 As shown, computer system diagram 400 is divided into a hardware system 402 having various hardware components (below solid line 403) and a software system 404 having various software / firmware components (above solid line 403). It should be understood that the software / firmware components of software system 404 are implemented in one or more computer processors and storage devices (not shown) associated with computer system or device 400. Figure 4 .

[0052] like Figure 4 As shown, the hardware system 402 may include one or more memory devices 405, such as a database, an internal local memory, a hard drive, a flash drive, a RAM, a ROM, etc. These memories 405 may include Figure 2 The local data storage 235 and data files 270 and 272 of the hardware system 402 may also include one or more network cards or ports 406, which may be connected via a network port (e.g., Figure 2 The network port 245 of the software system 404 connects the software system 404 to one or more external communication networks. Similarly, the hardware system 402 may include one or more peripheral devices 407, such as a user interface (e.g., Figure 2 237), printers, keyboards, mouse devices, external storage drives (e.g., via Figure 2 Of course, 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. Further, the hardware system 402 may include one or more processors 408 on which the operating system and processes described herein are executed.

[0053] like Figure 4 As shown, software system 404 includes operating system (OS) components, services or other processes 414 and configuration information or configuration data sets 416 (e.g., Windows registry), which can be used to configure the operation of software system 404 in the manner described herein. In this case, service process 414, referred to herein as service 414, runs independently of the logged-in user, and it generally runs in response to a call or command to OS 410 or a message passed by OS 410 to service process 414. That is, service 414 is typically generated or runs under the control of OS 410 or an agent of OS 410 (e.g., Windows Service Control Manager). Although these processes are typically started automatically, they can be started in response to request information sent by a desktop application. However, as indicated above, in both cases, these services always run under a specified custom service account, regardless of what process or processes cause these services to start. In addition, Figure 4 The software system 404 includes various desktop applications 420. It should be understood that the applications are typically launched by and available to various logged-in users and are available in accounts 425 ( Figure 4 Thus, unlike a service that always runs under the same custom service account, as shown above, the application runs under a different user account (the currently logged in user account). Of course, application 420 can be Figure 2410, and the user accounts 425 may have different privileges and permissions as usual or may all have the same operating system privileges and permissions, such as those associated with or defined for standard users, which generally have a minimum level or set of operating system privileges and permissions. Importantly, the configuration information 416 may include registry and other configuration information that defines the configuration of the OS 410 to operate or implement the above-described Figure 2 The rules described. In this case, the configuration information 416 can define account information containing privileges, can define access control lists that associate accounts with OS resources, and define access permissions for the account, and can define information that allows inherited account privileges to be restricted at runtime. In the latter case, the service / application begins with a set of account privileges that have been reduced as specified by the configuration information. However, this type of configuration information does not add privileges to those inherited from the account, but only reduces these privileges. The configuration information can be created or provided as part of a configuration activity provided by a control system provider or control engineer, so that the configuration information can be preset to specify which operating system privileges are associated with or provided to each of the services 414 and applications 420 (e.g., required) via user accounts, group accounts, and custom service accounts. Similarly, certain users (e.g., administrators) can change the configuration information 416 to add new accounts, define new accounts, etc. In addition, similar configuration information can be created for desktop applications, or it can be provided by a configuration engineer during the configuration process, or by an application provider (e.g., a third-party provider of a desktop application), or it can be set by default to a minimum level of privileges, or it can be set by an administrator.

[0054] like Figure 4 As shown, OS 410 uses configuration information 416 to control operating system privileges, and thereby controls the permissions and capabilities of various applications 420 (which can communicate with OS 410 via APIs or directly), as well as control services 414 to implement the least privilege security features described above. Thus, OS 410 uses configuration information (generally, account management information is stored in a database or file, such as Active Directory, workgroup configuration files, .exe-specific configuration files, etc.), and uses partitioned namespaces to enforce the requirement that applications 420 only communicate via IPC (by Figure 4 430) communicate with each other, and the application 420 communicates only via IPC (by Figure 4 ) communicates with service 414, and service 414 communicates only via IPC ( Figure 4Similarly, OS 410 (or applications / services executed in the manner described herein) may use configuration information 416 to prevent certain services from communicating with other services (e.g., preventing services that can access the network from communicating with services that can access external media), prevent applications 420 from writing to service files and folders stored on local or internal storage devices (e.g., Figure 2 270), preventing any service from writing to the desktop folder (e.g. Figure 2 272 in the server) or prevent it from accessing the desktop in any other way, and prevent any service that can access the network or external media from writing to service files or folders (e.g., Figure 2 It should be appreciated that one way that OS 410 enforces these rules is by tightly controlling the operating system permissions and privileges of various accounts and services and applications associated with the various accounts in configuration files of configuration module 416.

[0055] It should be understood that Figure 2-4 The goal of the overall design shown is to partition (isolate) services, applications, and other processes that run in, for example, automated system workstations and servers or other computer devices in a process control network to isolate infections to prevent them from persisting themselves so that they disappear on reboot, thereby reducing the ability of infections to spread and the damage they can cause by not allowing them to gain elevated privileges and by limiting the privileges of communication interface services and internal or external media port handling processes. Using these rules, if a service or other process generated by a service is infected, then (1) the infected service or process will not have elevated privileges because the service or process runs with restricted privileges, (2) the infected service or process will not have permission to access resources that it does not directly need, and (3) the infected service or process will not be able to persist itself through a reboot. In particular, services that can access the network and that can access external media ports (e.g., USB ports) have restrictions on what they can do, and since these services are the only way the infection can enter the machine, if infected, limiting what these particular services can do (e.g., preventing these services from writing to local memory storage or disk, preventing being able to run elevated privileges, preventing direct access to the desktop, preventing spreading the infection between portable / external media and communications networks / data links, etc.) prevents the infection from spreading within the computer device or network. As a result, the infection is automatically isolated, and restarting the service will clear the infection. For services that execute only when accessed (e.g., COM / DCOM services), the calling process gets a clean copy of the service on each new call, thereby clearing any infection in the service.

[0056] Likewise, using these rules, if a desktop application is infected, the application will neither be able to directly access privileged functions of the operating system (OS) nor write to network or portable storage devices. Instead, the application will request (via IPC) that actions be performed on its behalf by services and processes designed to validate privileged functions and resources and provide them with additional levels of access control.

[0057] Thus, some of the key advantages achieved according to this architecture include preventing processes from being able to access a network or portable storage device if those processes are infected with malware, preventing the ability to use administrative privileges to attack the system, preventing access to resources available to generic / standard accounts, preventing writing to the file system, and preventing malware from spreading from a portable storage device to the network and vice versa. This architecture also provides protection from desktop applications directly accessing trusted or restricted resources (e.g., local data files) or using elevated privileges, thereby limiting the system's exposure to malware if the desktop application is infected with malware. In addition, 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 allowing those processes to access control system resources using user identity assertions.

[0058] Although the safety techniques described herein have been described herein as being used in combination with networked process control devices and systems using fieldbus and standard 4-20ma devices, they can of course also be implemented in 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, function block or controller. In addition, the safety techniques described herein can be implemented in any type of computer device, including computer devices that are not part of a process control system. Although the software security architecture features described herein are preferably implemented in software, they can also be implemented in hardware, firmware, etc., and can be executed by any other processor associated with a computer device. Thus, if desired, the methods described herein can be implemented in a standard multi-purpose CPU or on specially designed hardware or firmware (e.g., ASIC). When implemented in software, the software can be stored in any computer-readable memory, for example, on a disk, a laser disk, an optical disk or other storage medium, in a RAM or ROM of a computer or processor, etc. Likewise, the software may be delivered to users or process control systems via any known or desired delivery method including, for example, on a computer readable disk or other portable computer storage mechanism, or modulated over a communications channel such as a telephone line, the Internet, etc.

[0059] Therefore, although the present invention has been described with reference to specific examples, these specific examples are merely illustrative and not intended to limit the present invention, and it is obvious to those skilled in the art that changes, additions or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the present invention.

Claims

1. A computer device comprising: processor; as well as an operating system, the operating system being executed on the processor according to the configuration data to implement a plurality of service processes and one or more desktop applications, wherein the plurality of service processes provide services to the one or more desktop applications, wherein the operating system executes to implement a service namespace separate from a desktop namespace, and operates to execute the service process in the service namespace and execute the one or more desktop applications in the desktop namespace separate from the service namespace, wherein operating system privileges of the multiple service processes are defined separately from a set of operating system privileges assigned to the one or more desktop applications, and wherein all processes implemented in the service namespace must communicate with processes in the desktop namespace via inter-process communication.

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

3. The computer device according to claim 1, wherein: The one or more desktop applications are assigned a same set of operating system privileges that are independent of operating system privileges associated with a user account that launches the one or more desktop applications.

4. The computer device according to claim 3, wherein: The set of operating system privileges assigned to the one or more desktop applications does not include administrator operating system privileges.

5. The computer device according to claim 4, wherein: The set of operating system privileges assigned to the one or more desktop applications are operating system privileges associated with a general user.

6. The computer device according to claim 3, wherein: The operating system enforces the rule that one or more desktop applications cannot be elevated in operating system privileges.

7. The computer device according to claim 1, wherein: The computer device includes a local memory storage unit, and wherein the operating system enforces a rule that prevents the one or more desktop applications from writing to a service file or service folder stored in the local memory storage unit.

8. The computer device of claim 1, further comprising a desktop, the desktop comprising a user interface, and wherein The operating system enforces a rule that prevents any service process among the plurality of service processes from accessing the desktop.

9. The computer device according to claim 1, wherein: The message initiated at the one or more desktop applications includes user identity information identifying the desktop application, and wherein the user identity information follows the message through a plurality of processes associated with sending the message.

10. The computer device according to claim 9, wherein: The user identity information does not control operating system privileges associated with one or more processes used to forward the message to the message recipient.

11. The computer device according to claim 1, wherein: The computer device also includes a communication port and a local memory storage unit, and wherein one of the plurality of service processes capable of communicating with the communication port does not have privileges to write to the local memory storage unit.

12. The computer device according to claim 11, wherein: The computer device further includes an external media port, and wherein one of the plurality of service processes capable of communicating with the communication port does not have privileges to communicate with the removable storage unit via the external media port.

13. The computer device of claim 1, wherein: The computer device also includes a communication port, a local memory storage unit, and an external media port, and wherein one of the multiple service processes capable of communicating with the communication network port does not have the privilege of writing to the local memory storage unit or the privilege of communicating with the removable storage unit via the external media port, wherein one of the multiple service processes capable of communicating with the removable storage unit via the external media port does not have the privilege of writing to the local memory storage unit and does not have the privilege of communicating with the communication port, and wherein one of the multiple service processes capable of communicating with the communication port does not have the following privilege: directly communicate with one of the multiple service processes capable of communicating with the removable storage unit via the external media port.

14. The computer device of claim 1, wherein: The operating system executes according to the configuration data to: executing the one or more desktop applications, the desktop applications having corresponding sets of application privileges, and the desktop applications being operable on behalf of multiple user accounts having corresponding sets of user privileges; Allocating the plurality of service processes to corresponding customized service accounts among a plurality of customized service accounts, each customized service account among the plurality of customized service accounts having a corresponding set of operating system privileges; as well as The multiple service processes are provided to run on behalf of the one or more desktop applications, wherein the running of the service processes uses the corresponding operating system privilege sets of the corresponding customized service accounts to which the multiple service processes are assigned to prevent the service processes from obtaining any application privilege sets in the corresponding application privilege sets or any user privilege sets in the corresponding user privilege sets.

Images