Least privilege-based security architecture for manufacturing control software

Abstract

Computer device, comprehensive at least one storage unit, set up to store configuration data of an operating system and data for a plurality of user-defined service accounts (310); at least one processor; and an operating system that runs on the processor according to the configuration data, in order to (i) to run a plurality of desktop applications (314) with a set of application rights in a desktop namespace on the computer device, wherein the desktop applications (314) are executable for a plurality of user accounts (306) having a corresponding set of user rights, and (ii) Providing services for the majority of desktop applications (314) wherein a service namespace (250) is partitioned from the desktop namespace of the computer device, wherein, according to the configuration data and before the operating system executes multiple service processes (312) at runtime of the computer device, the operating system assigns to each of the service processes (312) one of the plurality of user-defined service accounts (310), each associated with a corresponding predetermined set of operating system rights, wherein each corresponding predetermined set of operating system rights grants access to a corresponding limited number of resources defined in the service namespace (250) in which the plurality of service processes (312) are executed, and wherein the operating system enforces the corresponding operating system rights of the service processes (312) at runtime based on the user-defined service accounts (310) to prevent the service processes (312) from acquiring a set of application rights or user rights, such that (1) When a first of the plurality of desktop applications (314) requests the execution of a first service process (312) of the plurality of service processes (312) on behalf of a first of the plurality of user accounts (306), the operating system requires that the first service process (312) be executed under the operating system rights of a first of the user-defined service accounts (310) to which the first service process (312) was assigned, and not under the rights of the first desktop application (314) or the rights of the first user account (306), and (2) If a second of the plurality of desktop applications (314) requests the execution of the first service (312) on behalf of a second of the plurality of user accounts (306), the operating system requires that the first service process (312) be executed under the operating system rights of the first user-defined service account (310) and not under the rights of the second desktop application (314) or the rights of the second user account (306).

Description

AREA OF TECHNOLOGY

[0001] This application relates generally to computer systems in manufacturing plants and in particular to a method and a device for ensuring the operation of software processes within devices such as computers in a manufacturing or manufacturing plant environment. DESCRIPTION OF THE STATE OF THE TECHNOLOGY

[0002] Process control systems, such as distributed or scalable process control systems used in energy generation, chemical, petroleum-related, or other processes, typically comprise one or more controllers that communicate with each other and with at least one host or operator workstation via a process control network. These controllers are also connected to one or more field devices via analog, digital, or combined analog and digital data lines. The field devices, which may include valves, valve positioners, switches, or transmitters (e.g., temperature, pressure, or flow rate sensors), perform functions within the process or plant, such as opening and closing valves, switching devices on and off, and measuring process parameters.The controller receives signals indicating process and plant measurements originating from field devices and / or other information relating to the field devices. It uses this information to implement a control operating program and then generates control signals that are sent to the field devices via data lines to control the operation of the process or plant. Information from the field devices and the controller is typically made available to one or more applications executed from an operator's workstation, enabling the operator to perform desired functions with respect to the process or plant, such as viewing the current status of the plant or modifying its operation.

[0003] The process controllers, typically located within the process plant environment, receive signals indicating process measurements or process variables originating from or associated with field devices and / or other information about the field devices. Using this information, they execute controller applications. These applications implement, for example, various control modules that make decisions regarding process control, generate control signals based on the received information, and interact with the field devices, such as HART. ® and FOUNDATION ® -fieldbus devices, control modules, or blocks. The control modules in the process controllers send the control signals to the field devices via communication lines or other signal lines to control the process operation.

[0004] Information from field devices and process controllers is typically made available to one or more other hardware devices via the process control network, such as workstations, maintenance stations, servers, PCs, handheld devices, data archives, report generators, centralized databases, etc. Using the information transmitted over the network, an operator or maintenance technician can perform desired functions related to the process and / or view the operation of the plant.For example, an operator can use the information to change the settings of the control operating program, modify the operation of the control modules within the process controllers or communication-enabled field devices, view the current process stage or the status of a specific device within the process plant, view alarm signals originating from field devices and process controllers, simulate process operation for personnel training or for testing the process control software, diagnose problems or failures regarding the hardware within the process plant, and so on.

[0005] Field devices typically communicate with other devices via the process control network, which might be an Ethernet-configured LAN, for example. The network transmits process parameters, network information, and other process control data to various units within the process control system via different network devices. Typical network devices include network cards, switches, routers, servers, firewalls, controllers, and workstations. These devices usually enable data flow across the network by controlling its 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 type of network devices increase accordingly. Due to the growth of the system and the network, the security and management of such complex systems become increasingly challenging.For example, each network device can include one or more communication ports, which provide an access point or port for physically connecting the process control system components and other network devices to each other across the network. However, some of these ports or connections can also be used to connect the control devices to publicly accessible networks such as the internet, or to connect portable storage devices to the control system devices.An open port on a device can therefore become an access point for network expansion by adding other devices or granting network access to any entity, malicious or otherwise, thereby initiating unwanted and potentially harmful network traffic or introducing malware (such as malicious programs, spyware, data-gathering programs, and other unwanted and potentially harmful programs) that can cause serious problems within the plant control system. Effective monitoring or control of access to all ports on devices within a network that manages communications via a complex process control system becomes increasingly difficult with the growth of network devices and their associated access points.

[0006] Similarly, in a typical industrial control system, workstations / servers are strategically distributed between the plant network and the embedded devices that perform control and data termination functions (e.g., controllers, PLCs, RTUs). A key security objective for these workstations and servers is to prevent malware from infiltrating the control system and adversely affecting the embedded devices, as well as from modifying the configuration and historical data stored in the plant database. While several security features, such as antivirus software and whitelisting, can be employed to achieve this goal, they are generally insufficient. For example, antivirus software does not protect against zero-day viruses, and whitelisting only prevents the execution of unauthorized applications.Furthermore, some of these functions are so aggressive that they are not usable in a process control system because the safety functions have the potential to hinder the actions of plant operators.

[0007] Generally, malware, such as in a destructive zero-day attack, is typically introduced into the control system through a specific device via an external storage device (such as a removable USB flash drive) or through communication links by an application or service that has access rights or permissions to these storage devices, network ports, or direct data connections. (For the purposes of this patent, communication links include connections established via a communication network connection or a direct data connection such as a modem.) The malware is then able to spread to other devices (e.g., via communication or portable storage devices) and / or to execute within the device using the security privileges of the applications or services infected by the malware.Furthermore, the malware can persist locally, allowing it to be executed again after a reboot. In some cases, the malware can abruptly escalate the privileges of a host, such as an infected application or service, using the privileges of the account under which the application or service is running. This allows the malware to perform actions or transactions within the process control device or system that require elevated privileges and are therefore generally even more damaging to the operation of the control system. In any case, zero-day attacks that infect an already running application pose a significant problem for process control systems, and there is no effective method to prevent this type of attack.These attacks can have serious, destructive and even fatal consequences in a process plant if they disrupt the ongoing operation of the plant's control system.

[0008] US 7,308,702 B1 describes a system and procedure for defining and enforcing a security policy. Application-specific information for each security mechanism is encapsulated as keys. Keys are combined to form keychains within the semantic layer. The keychains are then encapsulated as keys and passed to another semantic layer. A security policy is defined by creating keychains from keys and linking users to the keychains. The security policy is translated and exported to the security mechanisms. The security policy is then enforced through the security mechanisms.

[0009] US 6 389 542 B1 discloses a multi-level computer security system comprising a computer with multiple security subsystems for data storage and data communication, a smart card reader for controlling user access to each security level, an electronically activated switch for activating only the selected and authorized security level, and a mechanically activated switch that detects the availability of the selected security level.

[0010] US 7,849,469 B1 describes a system that uses generative aspect-oriented programming to transfer the context between components in a component server. The system generates code that, when executed, implicitly transfers the authentication context between a client component and a called component that calls the client component in a component server. SUMMARY OF THE REVELATION

[0011] It is an object of the present invention to provide a computing device with an improved security architecture. This object is achieved by the subject matter of independent claim 1. Further advantageous embodiments of the invention are specified in the dependent claims.

[0012] A computer device according to the invention, in particular a process control system, uses a novel combination of security functions or a software security architecture that more effectively prevents attacks by zero-day malware or other types of malware. Generally, when applications and services are executed in a specific control system device, such as workstations, servers, databases, controllers, field devices, etc., the novel security function or security architecture implements what is referred to here as "least privileges" to reduce the impact of malware that can infect a workstation, server, or other device. The term "privilege" here encompasses both operating system privileges and access permissions.For example, a user may be granted the right to log in remotely or to impersonate another user (or right), and may also be granted access to read / write / execute certain files (permissions).

[0013] In general, a least-privilege security feature or architecture separates "service processes" from desktop applications that run on behalf of a logged-in user (local or remote). This is achieved, for example, by partitioning the device's general namespace (e.g., controller, workstation, server, etc.) into a service namespace and, where available, into the logged-in user's namespace (e.g., for desktop applications). The architecture then precisely controls communication between processes (e.g., applications and services) in these different namespaces using inter-process communication (and non-shared memory) to prevent an infected service or application from directly infecting or corrupting other applications or services.In particular, the new security architecture uses this namespace partitioning to prevent a desktop application from directly accessing objects in the service namespace and vice versa.

[0014] Furthermore, the new security architecture restricts the rights granted to services and desktop applications in such a way as to limit the ability of an infected service or application to infect or corrupt other services or applications. In general, the security architecture restricts the operating system rights of a service, application, or other process to a specific subset of rights granted to the account under which the service, application, or other process is run or spawned; restricts the rights of applications running on behalf of logged-in users to a specific subset of rights associated with the user; and prevents the escalation of fill rights through a desktop application (running under the logged-in user).In one case, the software security system enforces a restriction that any access to a communication port or external media port (e.g., for a removable storage device connected via an external media port such as a USB port) must be performed through a service with restricted rights (and never through a desktop application), with the service's restricted rights preventing the service from writing to local storage (e.g., hard drive), communicating through the other of the communication port or external media port, or acting with administrator privileges.In this way, the infection becomes harmless in the event that a service is infected, since the infection cannot be stored on a local hard drive or other storage, cannot perform management functions, cannot access the desktop, cannot be spread over a communication network if it was introduced via an external media port from a removable storage device, and cannot be stored on a removable storage device via an external media port or spread to another communication link if it was introduced via a communication port from a communication link.

[0015] Therefore, the new security architecture uses access controls that enforce which user accounts and which processes (service or desktop) are authorized to access discoverable objects by requesting the operating system and its subsystems. It also includes a mechanism that prevents lower-privileged processes from injecting code into higher-privileged processes. To this end, the security architecture has or uses accounts, commonly called "groups," so that user and service accounts can belong to other group accounts.

[0016] The combination of one or more security features results in a more secure software environment within a process control system or process plant, making it less vulnerable to virus attacks, such as zero-day attacks, and other malware. This is because these security features, alone or in combination, make it difficult, if not impossible, for malware to enter the system through the operation of a desktop application accessing a network connection or a removable / portable storage connection (such as a USB port). These security features also limit the ability of malware to be introduced to an internal data storage device via a network or external device, to exponentially escalate the privileges of services to access devices, storage media, or processes not required by the application requesting the service, and so on.

[0017] Using these features, the new security architecture partitions (isolates) the services and desktop applications running on the system's process control and automation workstations and servers to reduce their profile or surface area for malware attacks. Furthermore, if a service or a process spawned by a service becomes infected, it will not have the rights to modify anything it is not already modifying, nor will it have permissions to access resources it does not directly require. Additionally, if a desktop application becomes infected, it will not be able to directly access privileged operating system functions, nor will it be able to write directly to the network or to a removable storage device connected via an external media port.The desktop application must therefore request actions to be performed on its behalf by services and processes spawned by them, which are designed to provide and validate an additional layer of access control to privileged functions and resources. BRIEF DESCRIPTION OF THE IMAGES Fig. Figure 1 shows an exemplary block diagram of a process plant with a distributed process control system and process automation network including one or more operator and management workstations, servers, controllers, field devices and other network devices configured to implement the least privileged security architecture for software described here. Fig. Figure 2 shows an exemplary block diagram of a workstation / server / controller within a process control system, showing various namespace and security restrictions implemented with respect to applications, services and other processes executed in the process control software architecture to implement advanced security features. Fig. Figure 3 shows a diagram of accounts, including group accounts and user-defined accounts, that define sets of rights associated with the various applications and services according to the least privileged security architecture for software described here. Fig. Figure 4 shows an exemplary architecture diagram illustrating the software and hardware components of one of the system's workstations. Fig. 2 maps and the communication links between different services and applications that the accounts of Fig. Use 3, it depicts. DESCRIPTION

[0018] Fig. Figure 1 shows a schematic representation of a process control system or process automation system 100, which is arranged, for example, in a process plant, in which various computer devices can be subjected to different software security functions to improve software security and support the management and maintenance of computers / network. The process control system 100 includes, in particular, one or more process controllers 110 and one or more process plant databases 112 (such as data archives), which are communicatively connected to the process control system 130 via a communication network with one or more databases (hosts) or computers 120-122 (which can be any type of PC, workstation, server, etc.). The controllers 110 and the databases 112 can be connected to the communication network or bus 130 (for example, an Ethernet communication network) via one or more network cards 132.Furthermore, the controllers 110 can be connected via I / O cards 142 to field devices 140, 143, and 154 located in the process plant or control system. The databases 112 can comprise one or more data repositories, which may include any type of desired data collection unit or storage device with any storage type and desired or known software, hardware, or firmware for storing data. The databases 112 can also be part of one or more workstations or servers 120-122, or exist separately. The controllers 110, such as the Delta V™ controllers offered by Fisher Rosemount Systems, Inc., are communicatively connected to the hosts 120-122 via one or more network cards or devices 132, for example, via the Ethernet connection 130 or any desired communication network.The network devices 132 can include a network card, a switch, a router, a firewall or other device or several of them that enable data transmission over the network 130 without changing the underlying data.

[0019] As in Fig. As shown in Figure 1, a server 122 is connected to various network devices, which may be located in any area of ​​a communication or process control network and within an area of ​​a process plant, and may encompass any part of the safety function described here. In this example, the communication network 130 is typically a closed local area network (LAN) to which only the devices involved in the control system are connected and which can be implemented using hardwired or wireless technology.

[0020] Furthermore, the controllers 110 are communicative with the field devices 140 using any hardware and software compatible with, for example, standard 4-20 mA device protocols, Ethernet protocols and / or any intelligent communication protocol such as the FOUNDATION ® Fieldbus protocol (fieldbus), the HART ® -protocol, WirelessHART ® -protocol, the Profibus protocol, the CAN protocol, etc. are associated with it.

[0021] Field devices 140, 143, and 154 can be any type of device, such as sensors, valves, transmitters, positioners, etc., while I / O cards 142 can be any I / O device conforming to any desired communication or control protocol. In the Fig. In the embodiment shown in Figure 1, the field devices 140 are HART or 4-20 mA devices that communicate with a modem or I / O card 142 via standard HART or analog 4-20 mA lines 141, while the field devices 143 are intelligent devices, such as FOUNDATION ® Fieldbus field devices are those that communicate with one of the I / O cards 142 via a digital bus 145 or I / O network using fieldbus protocol communication. Field devices 140 and 143 can, of course, conform to any standard or protocol, including those developed in the future. Furthermore, field devices 140 and 143 can communicate wirelessly with controllers 110 via any wireless communication protocol, such as WirelessHART. ® -protocol, be connected.

[0022] Furthermore, one or more field devices 154 can be connected to a digital bus 145 via a special network device such as a gateway 153. For example, the field devices 154 may only understand HART commands, while the I / O network 145 can implement the PROFIBUS protocol. For this purpose, the gateway 153 can provide bidirectional PROFIBUS / HART conversion.

[0023] The controllers 110, which may be one or more controllers distributed throughout the plant with one or more integrated processors, implement or monitor one or more process control programs. These programs may include one or more control loops that are stored in or associated with the controllers 110. The controllers 110 also communicate via the network 130 and associated network devices 132 with devices 140, 143, and 154, as well as with hosts and servers 120-122, and with the data archive and other databases 112, to control a process as desired. It should be noted that any control operating programs and elements described herein may contain parts that can be implemented or executed by different controllers or other desired devices.Likewise, the control programs and elements described here, which are to be implemented in the process control system 100, can be of any type, such as software, firmware, hardware, etc. For the purposes of this discussion, a process control element can represent a part or section of a process control system that is stored on a computer-readable medium, such as a control program, a data block, or a module. Control programs, which can be modules or any part of a control procedure, such as a subroutine, parts of a subroutine (such as lines of code), etc., can be implemented in any software format, such as using ladder logic, sequential function chart (SFC) languages, function block languages, object-oriented programming, or any other programming language or software development pattern.Control programs can also be hard-coded into, for example, one or more EPROMs, EEPROMs, application-specific integrated circuits (ASICs), or any other hardware or firmware elements. Furthermore, the control programs can be developed using any programming aid, including graphical programming aids or any other type of software, hardware, or firmware programming or development aid. Therefore, the 110 controllers can be configured to implement a control strategy or control programs in any desired form.

[0024] Furthermore, another communication network is 160, as in Fig. 1 is shown, connected to server 122 and workstations 120 and 121, so that the process control system server 122 and workstations 120 and 121 can be connected to the plant's computer science, operational information systems and other network systems within the plant.

[0025] In general, the workstations and servers 120-122, as well as the others within the network, implement Fig. 1. The devices located here are referred to as the least-privileged security architecture, which (1) protects the services and other low-level processes that run on various computers of Fig. 1. This architecture isolates or separates processes such as workstations, servers, databases, controllers, etc., from desktop applications in various ways, and (2) restricts the rights of services and desktop applications to only those necessary for these processes to implement their functionalities. This least-privilege security architecture helps prevent malware from being imported and instantiated and executed within the process control devices. Generally, desktop applications and the services or other processes within a computer can be isolated by partitioning the common namespace of each computer in the process control system into one or more service namespaces and one or more username spaces (desktop applications). This partitioning prevents desktop applications from directly accessing objects (e.g.,Mutexes) that are defined in the namespace used by the services, and services that can directly access objects (e.g., in the desktop environment) defined for the desktop namespaces used by the desktop applications. Instead, all communication between the various desktop applications and services implemented by the operating system must use known and reliable interprocess communication (IPC) protocols. These provide a reliable, message-based communication structure that restricts communication to devices / workstations / servers where the communication is implemented, thus preventing or reducing the ability of an application or service to disrupt, infect, or impair the operation of other applications or services (e.g., memory).This prevents malware introduced via a desktop application from being easily imported into a service or other low-level process, and vice versa.

[0026] The least privileged security architecture described here also restricts the introduction and spread of malware within the system by limiting the rights granted to each service or desktop application to a specific subset of rights, such as a subset of rights granted to a logged-in user account under which the service or application is running or accessed. For example, for services that normally run on an administrator account and typically have all administrator rights, the new secure software architecture will run or access some or all services with only the specific rights the service needs to perform its intended function, and not with all administrator rights.Furthermore, services with access either to a communication network (via a communication network port) or to removable data storage via a removable storage port (e.g., a USB port) are run on an account with very limited rights, with these services having no administrator rights, no rights to save or write to a hard disk (i.e., local storage), and unable to communicate directly via either the communication network port or the removable storage port.This function prevents or at least reduces the ability of malware to use a service accessed by a user with elevated privileges and to access devices and functionalities not required by the service itself, thereby limiting the ability of malware to infect other devices or execute commands or services with elevated privileges simply because of the logged-in user account from which the service is run or accessed.

[0027] Security features can also automatically restrict privileges for applications, such as desktop applications launched by logged-in users, to prevent privilege escalation. In some cases, the security architecture prevents any conceivable desktop application from obtaining privileges, so a privilege escalation request from a user is an indication that the application has been infected. Generally, privilege escalation for a desktop application (running from the logged-in user account) now typically requires approval from an authorized user to perform a workflow that necessitates privilege escalation.Modern operating systems typically enforce this feature by granting applications launched by logged-in users, including administrators, only standard user rights (no elevated or administrator privileges) and requiring explicit user approval for any elevation of rights. The new architecture could prevent desktop applications from ever elevating their rights, thus providing an additional layer of security that limits malware's ability to automatically escalate system privileges and use this elevation to infect additional processes or devices.

[0028] The architecture described here can also use access controls that dictate which user accounts or processes (service or desktop) are authorized to access identifiable objects by making requests to the operating system or its subsystems (e.g., files, mutexes, processes). Furthermore, it can employ mechanisms to prevent processes with lower privileges from injecting code into processes with higher privileges, and it can use group-based accounts, commonly referred to as "groups," to allow the inheriting of rights / permissions. For example, user A might belong to group B, which in turn belongs to group C. User A therefore inherits rights and permissions from both B and C.Although these privileges may be shared or portable within the logged-in user account, they are not propagated to services or processes that receive messages from applications running under those accounts. This prevents services or processes (such as those instantiated by the operating system in response to messages received from these applications) from having elevated privileges. Therefore, privileges for services or processes executed or introduced by the operating system are generally defined separately from privileges for logged-in user accounts. This ensures that services or processes (and in many cases, applications) running on a user account with elevated privileges are restricted to a subset of privileges—that is, the minimum privileges necessary for the intended operation of the service, application, or process.

[0029] Referring to Fig. 2. The security functions and the secure architecture described here are implemented in a server, workstation, or controller, as described in Fig. The devices shown in section 1 are examples. It goes without saying that the security concept described here can also be implemented in the same or a similar way on other types of computers or machines, such as workstations, database servers, etc. In particular, it shows Fig. 2 a workstation / server / controller connected to no, one or more networks / data links 230, one of which is, for example, the network 130 of Fig. 1. In this case, the server / workstation 220 remains connected to one or more local data stores 235, which are located in Fig. 2 are shown as being internally 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 may include zero, one, or more removable media ports 239. The removable media port(s) 239, through which external and removable storage devices may be connected to the device 220, may include any type of storage access port, such as a USB port, a standard or proprietary connection to a CD or DVD drive, an external hard disk, a USB flash drive or flash memory, a magnetic disk unit, etc. As shown in Fig. As shown in Figure 2, data, programs, etc. of the workstation / server / controller 220 can be provided via one of the ports 239, via a removable and portable storage device, such as a USB stick 240, a DVD or CD 241, etc., or exported from the workstation / server / controller 220.

[0030] Furthermore, the workstation / server / controller 220 includes zero, one or more communication ports 245, each connected to a communication network / data link / communication interface, which may be, for example, a hard-wired or wireless communication network, such as an Ethernet network, a WiFi network, an Internet Protocol network, or any other local computer network or wide area network or data link.

[0031] As further in Fig. As shown in Figure 2, the workstation / server / controller 220 is partitioned into two types of namespaces: a service namespace 250 and no, one or more logged-in username spaces (in Figure 2). Fig. 2 as a single logged-in username space 252). Of course, there can be a different logged-in username space (also called username space here) for each different user from a multitude of the users logged in to the workstation / server / controller 220, and some devices, such as servers, may not have logged-in username spaces. As further shown in Fig. As shown in Figure 2, a set of desktop applications 258 exists in and runs in the usernamespace 252, whereas the services 260 exist in and run in the service namespace 250. In general, desktop applications 258 are processes that run in a usernamespace, whereas service processes, referred to here simply as services, are processes that run independently of the logged-on user and are introduced and executed by an operating system (or an agent such as the Windows Service Control), typically in response to configuration settings, requests from the operating system, or request messages directed to it (e.g., a COM / DCOM message in Windows). Detached processes are independent processes that run in the same namespace as the process that started them (e.g., a service process or a desktop application process).For example, detached processes can be started in the service namespace and represent the processes that implement USB, read from another local storage device, or link a communication network as described here. While services 260 are typically started automatically, these processes can be started in response to a request message sent by a user process or another service. As described in more detail here, services 260 always run under a specified account, regardless of the user account of the process that starts them and regardless of how they are started, whereas detached processes run under the account of the process (e.g., a service or desktop application) that starts them. Of particular importance is that services 260 are located in... Fig. 2 none, one or more service namespace processes with network access 262 (via one of the communication ports 245), service namespace processes with access to a removable storage device 264 via an external media port 239, and other service namespace processes 266 that have no access to portable or local storage or to the communication network. Furthermore, the local data storage device or storage 235 includes various types of files or folders, including service files or folders 270 created or used by the service namespace processes 260, and desktop files and folders 272 created or used by the logged-on usernamespace processes, such as those created or used by the desktop applications 258.

[0032] Out of Fig. 2. It becomes apparent that the computer environment of the workstation / server / controller is divided into multiple subspaces with different namespace rules, associated with separate namespaces for all logged-in users (or user groups) and services (or detached processes spawned by services). These rules are enforced by the operating system and its configuration data. Partitioning the namespace of the general computer environment into service namespaces and logged-in usernamespaces (desktop applications) prevents desktop applications from directly accessing objects (e.g., mutexes) defined in service namespaces and prevents service namespace processes from directly accessing objects (e.g., the desktop) defined in logged-in usernamespaces (used by desktop applications).In this way, service and desktop applications must communicate with and about each other (that is, they are forced to) in order to access the objects created in each of the different namespaces. This feature prevents malware residing in a service or desktop application from one environment from using or creating objects in other namespaces without having to enter the other namespace through a corresponding service or application. This generally prevents malware from corrupting other services or applications. For example, this feature limits the malware's ability to create or infect objects in other environments, which in turn limits the malware's ability to establish itself in the control system and spread via, for example, the 230 communication network.

[0033] The secure software architecture described above functions in various ways to increase the overall security of the workstation / server / controller 220 used in the plant or other industrial automation system. This security mechanism, which is generally applied to all computers or machines in the control system, including machines that execute processes / applications developed by third parties (as well as processes / applications developed by vendors of the control system), is designed to implement a set of rules and functions.

[0034] Some of the rules described here, enforced by the operating system configuration of the workstation / server / controller 220, apply to all processes that require elevated privileges, network access, write access to the local hard drive, or access to portable or removable storage devices (e.g., USB flash drives, smartphones, DVDs, or CD drives). These processes include, for example, processes 262 and 264 of Fig. 2. In particular, these processes (1) run as services or are spawned by services, (2) run under custom (non-default) accounts belonging to custom groups or roles, (3) are granted access only to the resources they need, (4) are explicitly denied access to resources they do not need, (5) are granted only the rights they need to perform their workflow, (6) do not have impersonation rights, meaning a process running under another account cannot change accounts to this custom account, and (7) do not have delegation rights that authorize another running process to run under this custom account. Furthermore, if these processes have network access or access to portable or removable storage devices, they do not have elevated privileges and cannot write to local storage media (e.g., hard disks).

[0035] These processes also communicate with each other via reliable interprocess communication (e.g., WCF Named Pipes, COM, etc.), with the exception that processes requiring network access are not permitted to communicate directly with processes that have access to portable or removable storage devices, and vice versa. This exception, which is explained in Fig. 2, represented by line 290, is implemented as protection against the forwarding of malware read into the communication network from a portable storage device and against the storage of malware received from the communication network onto a portable or removable storage device.

[0036] Furthermore, none of the processes 260 (e.g., processes 262, 264, 266) have, as in Fig. 2, represented by the dashed line 291, direct access to the desktop namespace 252 or objects in the desktop namespace 252. This means that these processes can only provide services (and especially extended services) to the desktop applications 258 via reliable interprocess communication 292, as shown by the lines running between the services 260 and the desktop applications 258 in Fig. 2 is shown.

[0037] All processes that require network access or access to a portable or removable storage device (e.g., processes 262 and 264 of Fig. 2) are executed under an account that (1) does not have access for input requests, (2) does not have access to programs that can change the security configuration (policy setting and accounts) of the workstation / server / controller 220, and (3) is prevented from writing to the file system, as indicated by the dashed line 294 in Fig. 2 is shown. This results in only the services 266, which do not have network access (e.g. via port 245) or access to portable or removable storage devices (e.g. via port 239), being able to write to the data files 270 located in the database 235.

[0038] Furthermore, there are various security features implemented in the Desktop 252 environment. Specifically, all desktop applications, also referred to here as interactive applications / processes, run without elevated privileges, regardless of which user accounts or logged-in accounts are used to launch or access these applications or processes. Even if a user with administrator privileges launches a desktop application, it will still run with limited operating system rights equivalent to those of a standard user, irrespective of the executing user's privileges.Furthermore, as already mentioned, the desktop applications 258 are unable to directly access the communication network 230 and must instead communicate via interprocess communication with a service 262 in the service namespace 250, which provides access to the communication network. The desktop applications 258 are also unable to directly access the portable storage devices 240 and 241 and must therefore communicate (via interprocess communication) with a service 264 that provides access to these devices. Furthermore, the desktop applications 258 are not authorized to access directories and files owned by the system or those that, in an infected state, could impair the performance / operation of the system. Desktop applications 258 can therefore, as described by line 296 of... Fig. 2 shown, write to desktop folders and files 272, but not to service folders and files 270. Furthermore, desktop applications 258 are designed such that they never require elevated privileges, and their privileges cannot be elevated independently of the privileges of the executing user. Desktop applications 258 can also never impersonate another user and must communicate with each other via reliable interprocess communication.

[0039] Furthermore, all user identities between services and processes 260 and desktop applications 258 are exchanged via digitally signed identity claims, and such identity claims follow or travel with the communication and through various processes and network devices so that approvals from the process control system can be verified. For example, the operator of a process control system (via a desktop application) may request something, such as writing a parameter (e.g., a setpoint) to a process control device such as a controller. This request may require that various services be invoked or generated while sending this request over a communication network to the process control device that is to implement the write command.The user's identity claims, along with the request, are routed through various processes used to create and forward the request across different machines in the process control network. This allows the process control device implementing the change to confirm that the request originates from a user with the appropriate permissions and to verify and append the change to the process where the write command is executed. This functionality ensures that a person is accurately and correctly identified as a user when executing a workflow, without the use of impersonation or delegation.This feature also makes it possible for desktop applications, or processes started by desktop applications (such as process control applications), to be launched in association with a logged-in user and then continue running during a shift change without requiring another user to restart, because shift changes do not require a logged-in user to log off. Instead, the operator of a new shift identifies themselves to the process control system without having to log in to the operating system. In this way, all desktop applications run with the rights of the logged-in user, so it doesn't matter which operator starts a desktop application, as long as the new operators identify themselves when using the application so that the appropriate identity claim can run in conjunction with the process flow request.Without this mechanism, the service / process / application would only be able to identify the user by the account under which it is run or from which it is accessed. This function is also important in control systems because the current user of an operator workstation cannot be the same user who logged in. This restriction eliminates the risk of a stolen user identity being used for logging in, determining operating system rights and access control permissions, and establishing access rights to control system resources (e.g., parameters and alarm signals).

[0040] A methodology for implementing the security functions described above with regard to Fig. Option 2 consists of a more restrictive methodology for defining the rights and permissions granted to various applications and services in a standard control system based on an open operating system architecture. In particular, user rights and permissions are typically defined for each individual user nowadays, so some users have more rights and permissions than others. With this architecture, applications (e.g., desktop applications and the processes they launch) are generally granted the rights and permissions of the logged-in user account under which these applications or processes were launched or invoked. On the other hand, many services (e.g.,Processes that are spawned based on configuration settings or in response to calls made by applications or user requests to the operating system to start them or process incoming messages are granted the rights of the operating system account under which they are configured to run. This means that all rights, permissions, and services are controlled by the accounts on these systems. Specifically, desktop applications always run under the account of the logged-in user, whereas services and processes always run under the account configured for them, and processes started by other processes are always started using the account under which the starting process is running. Therefore, it is common for services to run under default operating system service accounts or user accounts.

[0041] In contrast, the secure architecture of Fig. 2. Rights and permissions for services are separate from the rights and permissions defined for logged-in user accounts and therefore do not allow services to run under user accounts that have interactive login rights. Services are therefore always run under specific service accounts that do not have interactive login rights. In particular, the secure architecture of Fig. Define 2 custom service accounts, which are referenced here and which have different or limited sets of rights and permissions, and each of the services 260 of Fig. 2. One or more of these custom service accounts can be assigned to grant the rights and permissions for those services. Each service is assigned to a custom service account that has the minimum set of permissions required by the service. Services should not be assigned to custom service accounts that have more rights than necessary for the service to operate. However, to reduce the proliferation of custom service accounts, a service can run under a custom service account with more rights than required, but only if it is configured with a limited service set that reduces the rights inherited by the custom account to those required by the service.In some cases, such as services that access communication ports and external media ports, these services can be assigned to the account with the minimum set of permissions, with the further restriction that these services cannot write to local data storage (hard drive). On the other hand, desktop applications run with the rights of the executing user, but should always be started with limited default user rights and only elevated when necessary, and then only with user approval. If the user does not have the necessary rights, a user with the appropriate rights should be required to approve the elevation. In this way, services and applications can have a limited set of rights, restricting the ability of malware to infect a control system that uses this architecture.

[0042] In general, custom service accounts (and the rights of those accounts) can be defined and then assigned to services, further restricting the rights of the custom accounts so that the services only receive the rights or permissions they need to perform the tasks for which they were designed.

[0043] Fig. Figure 3 shows a block diagram 300 of an exemplary reciprocal relationship or association of user accounts 306, which allows user logon and user-defined service accounts 310 to be used for configuring or providing operating system rights and permissions for services 312 and desktop applications 314 and other processes, separate from the rights and permissions associated with the process control system that are defined for logged-on user accounts.

[0044] As in Fig. As shown in Figure 3, a set of user accounts 306 is defined, and, as illustrated by the dashed line between the user accounts 306 and the group accounts 302, each user account 306 can belong to one or more of the group accounts 302. In this way, each user account 306 inherits the operating system rights and permissions of any group account 302 with which it is associated or to which it belongs, and passes these rights / permissions to desktop applications when they are launched by an associated logged-on user. As shown in Fig. As also shown in section 3, a user account 306 can belong to multiple group accounts 302 and therefore inherit their rights and permissions, and these in turn can belong to other group accounts 302 and inherit their rights. This is also shown in section 3. Fig. As shown in Figure 3, a set of user-defined service accounts 310 is established, each with different operating system rights and permissions (including access permissions) to perform actions within the operating system, such as communication rights, read / write rights, access rights, etc. Each user-defined service account 310 can belong to multiple group accounts 302 and therefore inherit their rights and permissions. Each of the various services 312 and the processes they start on a computer is associated with one (or possibly more than one) of the user-defined service accounts 310 and inherits the operating system rights and permissions for the user-defined service account(s) 310 to which these services 312 belong. In general, the operating system rights and permissions provided to each user-defined service account 310 are defined separately from the user accounts 306.In particular, the rights and permissions of the custom service accounts 310 should be specifically tailored (restricted) to services 312 and processes started by them (e.g., detached processes, child processes), and they should only receive the operating system rights and permissions required for services 312 and processes started by them to perform the intended function, and no others, unless the service / process is configured to further restrict the rights inherited by the custom service account.

[0045] Using user accounts 306 and user-defined service accounts 310, processes in the service namespace 312 (i.e., the operational namespace in which services and the processes they launch run) and processes in the desktop namespace 314 (i.e., the operational namespace in which desktop applications and the processes they launch run) can be associated with different user-defined accounts 310 or user accounts 306. This allows services called by a desktop application to run with different privileges than those held by the calling desktop application. The term "called by a desktop application" refers to receiving a call message from a remote operation to a service, sent by a desktop application.

[0046] It can also be, and as in Fig. As shown in Figure 3, at a higher level, a set of Group Accounts 302 are established to define a specific set of different operating system rights and permissions (including access permissions). Group Accounts can be associated with none, one, or more user-defined service accounts or user accounts on a computer device or in the process control system as a whole (e.g., using Active Directory). Each Group Account 302 can encompass a specific set of operating system rights and permissions (including access permissions) that can be inherited by other Group Accounts, User-defined Accounts, and / or User Accounts that are members of Group Account 306. Inheritance is achieved by making these accounts members of the Group Account 306.Therefore, user accounts 312 and user accounts 306 can belong to the same group 302 and thus inherit the same rights and permissions as the operating system. Group accounts 302 are therefore distinct from the functions typically used in process control systems to define process control rights and permissions (as opposed to those of the operating system). Process control functions (as opposed to operating system groups) usually comprise groups of individuals (operators, configuration engineers, technicians, etc.) who are responsible for specific areas or functions of the plant.While these different roles can define different process control rights and permissions for these individuals, those assigned different roles usually perform them under the same logged-in user account and possess the same set of operating system rights and permissions, but different process control rights and permissions. In any case, it is assumed that group accounts 302 define operating system rights and permissions that can be inherited by user-defined service accounts 312, which are used to execute the processes of the service namespace and / or user accounts 306 and the desktop namespace processes started by the logged-in user.

[0047] Therefore, it clarifies Fig. 3. A grouping of various services 312 and applications 314 under different accounts 302, 306, and 310, which are used for assigning process control permissions to the services and applications. The in Fig. The three custom service accounts 310 shown are used only for service processes 312 and other processes in the service namespace, and the user accounts 306 are used only for processes (e.g., applications 314) in the desktop namespace. Generally, all processes (e.g., desktop applications 314) in the desktop namespace start with the rights of the "default user account" 306A (the account with the fewest rights), which has no administrator privileges. The custom accounts 310 are defined with only the additional rights they require. However, as shown in Fig. As shown in Figure 3, more than one service 312 can run under the same custom service account 310, and some privileges can be individually denied to each service if it does not require all the privileges of the custom service account. However, services that access a communication port and / or external media port (e.g., USB port) run under a custom user account without elevated privileges (e.g., administrator privileges) and with the further restriction that these services cannot write to local (internal) storage or a hard disk. Local and internal storage, in this context, refers to storage devices that are connected to a computer device in a relatively permanent manner and are not intended to be portable or easily removable, and therefore are not connected to an external media access port.Local and internal data storage generally includes internal hard drives or internal working memory (RAM).

[0048] The above discussion shows that operating system rights, including access permissions, are granted to a process (e.g., a service or a desktop application) completely independently of the access controls that allow / deny user access to objects of the process control system (e.g., setpoints, temperature and pressure measurements, and alarm limits). Access to objects of the process control system requires a separate user identity, which must be transmitted with requests so that process control devices can verify process control permissions, because the operating system, which enforces access permissions and operating system rights, has no knowledge of the objects of the process control system.As is well known, operating systems generally have a separate user management system that defines what each user of the operating system can access in the control system, and user identity claims are provided so that this separate user management system can operate properly.

[0049] In any case, when this architecture is used, the rights and permissions a user has to access process control objects in order to perform actions within the system, etc., are completely independent of the rights and permissions of services and applications running under user-defined service accounts or logged-in user accounts. This feature reduces or eliminates the ability of an infected process to use the operating system rights and permissions inherited from a user-defined service account or the user account under which the infected process is running to access or disrupt process control objects.

[0050] What's next in Fig. As shown in Figure 3, the execution engine 320 (e.g., the operating system's execution engine) of the computer on which a process (e.g., a service or application, or a process started by a service or application) is to run grants rights to services 312 or applications 314, or processes started by them, according to the following rules. Processes started directly by the logged-on user receive a standard set of rights and permissions associated with the standard user account, even if the user has elevated rights (i.e., administrator rights). Services started by the operating system receive the rights and permissions of the user-defined service account to which they belong, reduced by restrictions configured for the service. Processes started by a process receive the current set of rights and permissions of the starting process. With this organization, any process (e.g.,Each service (312), application (314), or process launched by it, is executed with the minimum set of privileges necessary to perform its specific functionality. This functionality therefore limits the ability of malware that has infected a service (312), application (314), or process launched by it to perform actions (e.g., obtain operating system rights and permissions) that the service (312) or application (314) does not require for normal operation. This, in turn, limits the malware's ability to operate on the computer and spread to other process control devices or other computers via the process control system's communication network.Furthermore, the execution engine 320 can prohibit or prevent an extension of rights for desktop applications 314 or services 312 in order to prevent malware from destroying this construct of operating system rights.

[0051] Fig. Figure 4 shows a schematic diagram of a Computer System 400 that can implement the rules and configuration functions described here for increasing the security of a computer device or plant network to prevent the spread or likely infection by malware. In particular, as shown in Fig. As shown in Figure 4, the diagram of Computer 400 is divided into a hardware system 402, which has various hardware components (below a solid line 403), and a software system 404, which has various software / firmware components (above the solid line 403). It is understood that the software / firmware components of Software System 404 are located in one or more computer processors and memory devices (not in the Fig. 4 shown) are implemented, which are associated with the computer or device 400.

[0052] What's next in Fig. As shown in Figure 4, the hardware system 402 can include one or more storage devices 405, such as databases, internal local storage, hard disks, USB flash drives, RAM, ROM, etc. Storage devices 405 can include local data storage 235 and the files 270 and 272 of Fig. 2. The hardware system 402 may also include one or more network cards or ports 406 that can connect the software system 404 to one or more external communication networks via network ports, such as network port 245 of Fig. 2. The hardware system 402 can equally support one or more peripheral devices 407, as well as a user interface (e.g., the user interface 237 of Fig. 2), printers, keyboards, mice, external storage devices (for example, with an external storage port 239 of Fig. 2 connected) etc. Of course, any other peripheral device, device port, or connection may be present in the hardware system 402, which may be in place of or in addition to those specifically described here. Furthermore, the hardware system 402 may include one or more processors 408 on which the operating system and the processes described here are executed.

[0053] As in Fig. As shown in Figure 4, the software system 404 comprises an operating system component 410, services or other processes 414, and a set of configuration information or data 416 (e.g., a Windows registry database, etc.) that can be used to configure the operation of the software system 404 as described herein. In this case, service processes 414, here simply called services 414, are processes that run independently of logged-on users and are generally executed in response to requests sent to the operating system component 410, which are forwarded by the operating system component 410 to a service process 414. This means that services 414 are generally spawned or executed by the operating system 410 or an agent of the operating system 410 (e.g., the Windows Service Control).Although these processes are typically started automatically, they can also be started in response to a request sent by a desktop application. In both cases, and as explained above, these services always run under a specific user-defined service account, regardless of which process started them. Additionally, the software system includes 404 errors. Fig. 4 different desktop applications 420. It is assumed that the applications are typically started by different logged-in users and under these user accounts 425 (by the dashed lines in Fig. 4 shown). Therefore, unlike services, which always run under the same user-defined service account, applications run under different user accounts (the currently logged-in user account), as discussed above. Applications 420 can, of course, be the desktop applications 258 of Fig. 2 and the user accounts 425 may have different rights and permissions than is normally the case, or they may have the same operating system rights and permissions as those defined for a standard user, who generally has the least amount of operating system rights and permissions. In particular, the configuration information 416 may include registrations and other configuration information that define the configuration of the operating system component 410 to operate in the manner described above, or the rights described above with respect to Fig. 2. To implement this, the configuration information can define 416 account information, including rights, access control lists that associate an account with an operating system resource, access permissions for the account, and information that reduces transferred account rights at runtime. In the latter case, the service / application runs with the reduced set of account rights as specified by the configuration information. In any case, this type of configuration information does not add rights to those transferred by the account; rather, it reduces them.The configuration information can be created and / or provided as part of configuration activities, supplied by the control system vendor or the configuration engineer, so that the configuration information is already set to specify which operating system rights are associated with or provided to each of the services 414 and applications 420 via user accounts, group accounts, and custom service accounts (e.g., required by them). Likewise, certain users, such as administrators, can modify the configuration information 416 to add new accounts, define new rights, etc. Furthermore, similar configuration information for desktop applications can be created and provided by a configuration engineer during the configuration process or by the application vendor (e.g.,third-party suppliers of the desktop application) or may be automatically or by an administrator set to the lowest level of rights.

[0054] As in Fig. As shown in Figure 4, the operating system component 410 uses the configuration information 416 to control the operating system rights and therefore also the permissions and functions of various applications 420 (which can communicate via APIs 412 or directly with the operating system component 410) and the services 414 in order to enforce the least-privilege security features described above. Therefore, the operating system component 410 uses the configuration information (generally, the account management information is stored in a database or file, such as an Active Directory directory, a workgroup configuration file, an .exe-specific configuration file, etc.) and the partitioned namespaces to enforce the requirement that the applications 420 communicate with each other only via IPCs (with line 430 of Fig. 4 indicated) communicate that the applications 420 only via IPCs (with line 431 from Fig. 4 indicated) communicate with services 414 and services 414 communicate with other services 414 only via IPCs (with line 432 from Fig. 4 indicated). Likewise, the operating system component 410 (or the execution of the applications / services in the manner described here) can use the configuration information 416 to prevent certain services from communicating with other services (e.g., a service with network access communicating with a service that has access to external media), to prevent applications 420 from accessing internal storage devices (e.g., files 270 from Fig. 2) write saved service files and folders or that services on desktop folders (e.g., Files 272 of Fig. 2) write to or otherwise access the desktop and to prevent services with network access or access to external media from accessing service files and folders (e.g., files 270 of Fig. 2) write. It is understood that the operating system component 410 enforces these rules in a manner that strictly controls the operating system's rights and permissions for various accounts and the associated services and applications in the configuration files of configuration module 416.

[0055] It goes without saying that the goal of all this in the Fig.The concept illustrated in 2-4 is to partition (isolate) the services and desktop applications running on the workstations of the process control and automation system and on the servers or other computer equipment of, for example, a process control network, in order to isolate an infection and prevent it from persisting, so that the infection disappears on restart, its ability to spread is reduced, and the damage introduced by the infection is reduced by not allowing the infection to gain elevated privileges and by restricting the rights of the services of the communication interfaces and external processes or processes of users of external media ports.If a service or a process spawned by a service becomes infected, (1) the infected service or process does not receive elevated privileges according to the rules because the service or process runs under restricted privileges, (2) the infected service or process does not receive permissions to access resources it does not directly need, and (3) the infected service or process cannot persist through restarts. In particular, services that have access to the communication network and external media ports (e.g., USB port) are restricted in what they can do, and because these services are the only points of entry for infections onto a machine, these restrictions concern what they can do (e.g.,This prevents these services from writing to local storage and hard drives, executing elevated privileges, directly accessing the desktop, spreading infections between portable or external media and communication networks / data links, etc. If infected, it prevents the infection from spreading within the computer or network. Consequently, the infection is automatically quarantined, and it is deleted when the services are restarted. For services that only run when accessed (e.g., COM / DCOM services), the calling process receives a clean copy of the service with each new call, thus deleting the infection within the service.

[0056] Similarly, if a desktop application becomes infected, it is not able, according to these rules, to directly access privileged functions of the operating system, nor to write to a network or portable storage device. Instead, the desktop application must request actions (via IPCs) that are performed on its behalf by services and processes spawned by them, which are designed to provide and validate an additional layer of access control to privileged functions and resources.

[0057] This results in several key advantages of the architecture, including protection against processes accessing a network or portable storage device. If these processes become infected with malware, they are prevented from using administrator privileges to attack the system, from accessing resources available to common / default accounts, from writing to file systems, and from spreading malware from a portable storage device to a network and vice versa. This architecture also protects against a desktop application gaining direct access to trusted or restricted resources (such as local files) or using elevated privileges, thus making the system less vulnerable to malware if the desktop application becomes infected.Furthermore, this architecture allows processes of the control system to be executed under operating system accounts that only have the rights and permissions of the operating system or file system that they require, while allowing them access to resources of the control system using user identity claims.

[0058] Although the safety techniques described here are related to network-based process control devices and systems using fieldbus and standard 4-20 mA devices, they can also be implemented with any type of control device using any communication protocol or process control programming environment, or with other types of devices, function blocks, or controllers. Furthermore, the safety techniques described here can be implemented on any type of computer device, including computer devices that are not part of a process control system. While the functions of the safety architectures described here 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.The methods described here can therefore be implemented in a standard general-purpose main processor or, if desired, in specially developed hardware or firmware such as ASICs. If implemented in software, the software can be stored on any computer-readable storage medium, such as magnetic disks, laser disks, image disks, or any other storage medium, in the RAM or ROM of a computer or processor, etc. Likewise, this software can be delivered to a user or a process control system via any known or desired transmission method, for example, on a computer-readable floppy disk or other portable storage mechanism, or modulated via a communication channel such as a telephone network, the internet, etc.

[0059] Although the present invention has been discussed with reference to specific examples which serve only for illustration and are in no way intended to limit the invention, it will be obvious to those skilled in the art that changes, additions or eliminations can be made to the disclosed embodiments without departing from the scope of protection or spirit of the invention.

Claims

[1] Computer device, comprising at least one storage unit, set up to store configuration data of an operating system and data for a plurality of user-defined service accounts (310); at least one processor; and an operating system that runs on the processor according to the configuration data, in order to (i) to run a plurality of desktop applications (314) with a set of application rights in a desktop namespace on the computer device, wherein the desktop applications (314) are executable for a plurality of user accounts (306) having a corresponding set of user rights, and (ii) Providing services for the majority of desktop applications (314) wherein a service namespace (250) is partitioned from the desktop namespace of the computer device, wherein, according to the configuration data and before the operating system executes multiple service processes (312) at runtime of the computer device, the operating system assigns to each of the service processes (312) one of the plurality of user-defined service accounts (310), each associated with a corresponding predetermined set of operating system rights, wherein each corresponding predetermined set of operating system rights grants access to a corresponding limited number of resources defined in the service namespace (250) in which the plurality of service processes (312) are executed, and wherein the operating system enforces the corresponding operating system rights of the service processes (312) at runtime based on the user-defined service accounts (310) to prevent the service processes (312) from acquiring a set of application rights or user rights, such that (1) When a first of the plurality of desktop applications (314) requests the execution of a first service process (312) of the plurality of service processes (312) on behalf of a first of the plurality of user accounts (306), the operating system requires that the first service process (312) be executed under the operating system rights of a first of the user-defined service accounts (310) to which the first service process (312) was assigned, and not under the rights of the first desktop application (314) or the rights of the first user account (306), and (2) If a second of the plurality of desktop applications (314) requests the execution of the first service (312) on behalf of a second of the plurality of user accounts (306), the operating system requires that the first service process (312) be executed under the operating system rights of the first user-defined service account (310) and not under the rights of the second desktop application (314) or the rights of the second user account (306). [2] Computer device according to claim 1, wherein the computer device further comprises one or more communication ports (245) and wherein each of the service processes (312) that can communicate with a communication port (245) has no right to write to the at least one storage unit. [3] Computer device according to any of the preceding claims, in particular according to claim 2, wherein the computer device further comprises an external media port and wherein one or more service processes (312) that can communicate with a communication port (245) do not have the right to communicate with a removable storage unit via an external media port; and / or wherein the computer device further comprises an external media port and wherein one or more service processes (312) that can communicate with a communication port (245) do not have the right to communicate directly with another service process (312) that has the right to communicate with the removable storage unit via an external media port. [4] Computer device according to any of the preceding claims, in particular according to claim 3, wherein the computer device further comprises an external media port and wherein one of the service processes (312) that can communicate with a removable storage unit via an external media port has no right to write to the at least one storage unit. [5] Computer device according to any of the preceding claims, in particular according to claim 4, wherein the computer device further comprises a communication port (245) and wherein one or more service processes (312) that can communicate with a removable storage unit via an external media port do not have the right to communicate directly with another service process (312) that has the right to communicate via the communication port (245). [6] Computer device according to one of the preceding claims, in particular according to claim 5, wherein the operating system is executed on the at least one processor according to the configuration data to implement desktop processes, wherein the configuration data causes each of the desktop processes to be associated with one of the plurality of user accounts (306), each of which has a predetermined set of operating system rights associated with it, wherein the predetermined set of operating system rights for each of the plurality of user accounts (306) includes interactive login rights. [7] Computer device according to any of the preceding claims, in particular according to claim 6, wherein a set of operating system rights associated with the standard user accounts (306) does not include elevated operating system rights or administrator rights; and / or wherein a set of operating system rights associated with the desktop applications (314) are restricted to standard user rights at startup, even if the user account (306) on which the desktop application (314) was started has elevated operating system rights, and wherein processes started by processes running in the desktop namespace inherit the rights of the starting process; and / or where the operating system enforces a rule that processes running in the desktop namespace can only be elevated to operating system privileges with the explicit permission of an authorized user whose account has elevated rights. [8] Computer device according to any of the preceding claims, in particular according to claim 1, wherein the operating system enforces a requirement that all processes running in the service namespace (250) must communicate with other processes running in the service namespace (250) via interprocess communication; and / or wherein the at least one storage unit includes service files or service folders, and wherein the operating system enforces a rule that prevents processes running in the desktop namespace from writing to service files or service folders stored in the at least one storage unit; and / or a computer device further comprising a desktop with a user interface in the desktop namespace and wherein the operating system enforces a rule that prevents any of the service processes (312) from directly accessing that desktop; and / or wherein messages originating from desktop applications (314) include user identity information that identifies a user of a desktop application (314) and wherein the user identity information follows the messages through multiple processes including a service process (312) that accesses a communication port (245) to send a message via a communication link to the final destination. [9] Computer according to any of the preceding claims, in particular according to claim 8, wherein user identity information does not control the operating system rights and / or access permissions associated with one or more processes used to forward a message to a recipient, and wherein the user identity information controls the access permissions to process control objects.

Images