CONTEXT-AWARE SECURITY SELF-ASSESSMENT

Abstract

The present invention generally relates to a context-aware security self-assessment method or module that determines the context in which the device is used and based on this, assesses the devices security settings. The context may refer to the system environment, the applications the device is used for, and/or the current life-cycle stage of the device, without being limited to said contexts. The method of the present invention preferably prioritizes and rates the security relevant findings and presents them in combination with mitigation options through a web interface, a configuration tool, or through notifications in the control system.

Claims

1. A method for context-aware security self-assessment of an industrial device, the method comprising the steps: self-assessing current context of said device it presently operates, based on a predefined rule set; self-assessing presently used security settings for said device based on the assessed current context of the device and a predefined and customizable set of security assessment checks for that context; and providing a suggested action to a user/operator on both, the basis of the assessed security settings and the assessed context, to adapt the present security settings of the device to the suggested settings.

2. The method according to claim 1, wherein the industrial device is embedded in an industrial control system.

3. The method according to claim 1, wherein the assessed current context of the device is a temporarily taken out of service state, a testing mode, an operation mode, a maintenance mode, an emergency-shutdown mode, an end-of-life mode, decommissioned state or a not yet commissioned state.

4. The method according to claim 1, wherein the rule set checks for the device environment, the applications the device is used for, the current life-cycle stage of the device and/or the usage of certain security relevant features for a certain period of time.

5. The method according to claim 1, wherein the rule set comprises potential security requirements and an indication as to which contexts it affects.

6. The method according to claim 1, wherein the security settings are vendor defined or definable by the user.

7. The method according to claim 1, wherein the security settings check for Telnet, FTP, SSH, OPC Server, Local user Accounts, Password Policy, Internet Connectivity, Reverse Internet Connectivity.

8. The method according to claim 1, wherein the provided suggested action(s) are compiled and displayed to the user together with at least one selectable action, such that the user can decide which action should be executed.

9. The method according to claim 1, wherein the provided suggested action(s) are executed automatically.

10. The method according to claim 1, wherein the industrial device comprising: means for self-assessing the current context of the device it presently operates, based on a defined rule set; means for self-assessing presently used security settings for the device based on the assessed current context of the device and a predefined and customizable set of security assessment checks for that context, wherein said means for self-assessing are part of the device itself; and means for providing suggested action(s) to a user/operator on both, the basis of the assessed security settings and the assessed context to adapt the present security settings of the device to the suggested settings.

11. (canceled)

12. A memory device comprising: a set of instructions for context-aware security self-assessment of an industrial device when executed by a processor of a computing device are effective to: self-assess current context of said device it presently operates, based on a predefined rule set; self-assess presently used security settings for said device based on the assessed current context of the device and a predefined and customizable set of security assessment checks for that context; and provide a suggested action to a user/operator on both, the basis of the assessed security settings and the assessed context, to adapt the present security settings of the device to the suggested settings.

13. The method according to claim 1, wherein the industrial device is embedded in an Industrial Automation and Control System (IACS).

14. The method according to claim 2, wherein the assessed current context of the device is a temporarily taken out of service state, a testing mode, an operation mode, a maintenance mode, an emergency-shutdown mode, an end-of-life mode, decommissioned state or a not yet commissioned state.

15. The method according to claim 4, wherein the rule set is preferably defined by the vendor of the device or changeable by the user.

16. The method according to claim 2, wherein the rule set checks for the device environment, the applications the device is used for, the current life-cycle stage of the device and/or the usage of certain security relevant features for a certain period of time.

17. The method according to claim 3, wherein the rule set checks for the device environment, the applications the device is used for, the current life-cycle stage of the device and/or the usage of certain security relevant features for a certain period of time.

18. The method according to claim 2, wherein the rule set comprises potential security requirements and an indication as to which contexts it affects.

19. The method according to claim 3, wherein the rule set comprises potential security requirements and an indication as to which contexts it affects.

20. The method according to claim 4, wherein the rule set comprises potential security requirements and an indication as to which contexts it affects.

21. The method according to claim 2, wherein the security settings are vendor defined or definable by the user.

22. The method according to claim 3, wherein the security settings are vendor defined or definable by the user.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The subject matter of the invention will be explained in more detail in the following text with reference to preferred exemplary embodiments which are illustrated in the attached drawings, in which:

[0026] FIG. 1 shows a self-assessment mechanism through an agent that monitors processes and configurations;

[0027] FIG. 2 shows a self-assessment report as presented to a user; and

[0028] FIG. 3 shows a more detailed self-assessment report as presented to a user.

[0029] The reference symbols as used in the drawings and their primary meanings are listed in summary form in the list of designations. In principle, identical parts are provided with the same reference symbols in the figures.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0030] According to a first preferred embodiment of the present invention, the self-assessment mechanism is embedded into a device. The mechanism or method may use an agent that is either performing an assessment periodically, according to a schedule and/or on demand. In order to carry out the self-assessment, certain inputs are preferably provided which can define what is secure:

[0031] For instance, a rule set may contain potential security requirements and preferably all potential security requirements, and an indication as to which contexts it affects. This information can be encoded, e.g., in an XML type language such as XCCDF (Extensible Configuration Checklist Description Format, which is a part of the Security Content Automation Protocol (SCAP)).

[0032] A further input preferably relates to information concerning the current context. According to the present invention, said information may be provided by an operator/user or the method of the present invention determines the context itself, preferably automatically. For example, based on attached devices, the method may determine that the device is either in testing or operational mode.

[0033] Given this information, the agent (see FIG. 1) reads in all relevant configuration files and checks all running processes to determine if there are any deviations from the security rules for the current context. For example, the use of FTP may be prohibited during operation, and a running FTP server (process) constitutes a deviation from the security rules.

[0034] The results of this analysis can be gathered and made available in form of a self-assessment report. This report (see FIG. 3) can be exported and/or shown to the operator of the system. For instance the report as illustrated in FIG. 2 can be displayed at a user display (monitor).

[0035] The exemplary report lists of FIG. 3 show a few examples of security requirements in more detail. One exemplary security requirement concerns Internet connectivity.

[0036] For instance, industrial automation and energy devices such as controllers, IEDs, etc. are generally utilized within a plant network and should not be connected to the Internet. However, due to ignorance or human error, some devices are directly connected and can even be accessed from the Internet, which can be seen on search engines created for that purpose (e.g., Shodan). This can be a serious threat for the operator of the device, as the search engine advertises the device, and search engine users are tempted to access or even hack the device. However, standalone devices may be put on the Internet on purpose. The self-assessment feature alerts in case the device is connected to the Internet.

[0037] The types of dynamic assessment that are possible can be seen in the example of the OPC server. In this case, the device has noticed that the OPC server is enabled, but has not been used for 576 days. As an enabled but unneeded OPC server may present security vulnerability, and as it does not seem the server functionality is required, the user should disable the OPC server.

[0038] The following possible checks can also be performed, but the present invention is not limited to this set.

[0039] Commissioning/Engineering phase [0040] Is the device integrated in a central user account management system? [0041] Internet connectivity: Is the device connected to the Internet? Are search engines (Shodan) accessing the device? [0042] Are certificates valid and not self-signed? [0043] Is the device integrated into a central logging system? [0044] Have the security settings of the device been reviewed and set?Operational phase [0045] If local user accounts are used, is the password complexity and password length adequate? Were they changed when the device was put into operation? [0046] Are unused communication protocols activated? [0047] Are insecure industrial protocols activated? Are they used at all? [0048] Has the device enough space for storing local logs? [0049] Are certificates valid? [0050] Internet connectivity: Is the device connected to the Internet? Are search engines (Shodan) accessing the device?

[0051] The following implementation in the form of a bash script shows a simple example how it is possible to determine the device context and how to perform a different security assessment depending on the relevant context. Below are screenshots from the implementation running in the development context and in the production context.

[0052] Production Context:

TABLE-US-00001 $ ./security_check.sh No recent config change, asssuming production mode. [OK]: TCP port 21 (ftpd) is closed Warn: TCP port 22 (sshd) is being listened on [OK]: TCP port 23 (telnetd) is closed [OK]: No FTP daemon is running Warn: SSH daemon is running [OK]: No telnet daemon is running [OK]: no public IP address found [OK]: Direct internet connectivity not available

[0053] Development Context:

TABLE-US-00002 $ touch config_file $ ./security_check.sh Recent config change, asssuming development mode. [OK]: TCP port 21 (ftpd) is closed [OK]: TCP port 23 (telnetd) is closed [OK]: No FTP daemon is running [OK]: No telnet daemon is running [OK]: no public IP address found [OK]: Direct internet connectivity not available

[0054] The source code of this implementation is listed below:

TABLE-US-00003 #!/bin/bash # # Script to perform basic security checks. # # Check whether config file was modified within the last 14 days. if [ $((date +%s - stat -c %Y config_file)) -gt 1209600 ] then echo No recent config change, asssuming production mode. MODE=prod else echo Recent config change, asssuming development mode. MODE=dev fi # Check open ports. function check_open_port( ) { PORT=$1 MSG_OPEN=$2 MSG_CLOSED=$3 netstat -lnt | awk {print $4} | sed s/.*:\(.*$\)/\1/ | \ grep -q {circumflex over ()}$PORT\$ if [ $? -eq 0 ] then echo -e $MSG_OPEN else echo -e $MSG_CLOSED fi } # ftpd check_open_port 21 \ \e[31mWarn:\e[0m TCP port 21 (ftpd) is being listened on \ \e[32m[OK]:\e[0m TCP port 21 (ftpd) is closed # sshd if [ $MODE = prod ] then check_open_port 22 \ \e[31mWarn:\e[0m TCP port 22 (sshd) is being listened on \ \e[32m[OK]:\e[0m TCP port 22 (sshd) is closed fi # telnetd check_open_port 23 \ \e[31mWarn:\e[0m TCP port 23 (telnetd) is being listened on \ \e[32m[OK]:\e[0m TCP port 23 (telnetd) is closed # Check running programs for known programs. # ftpd (vsftp,...) pgrep ftpd >/dev/null if [ $? -eq 0 ] then echo -e \e[31mWarn:\e[0m FTP daemon is running else echo -e \e[32m[OK]:\e[0m No FTP daemon is running fi # sshd (we ignore dropbear, lsh, and other implementations) if [ $MODE = prod ] then pgrep sshd >/dev/null if [ $? -eq 0 ] then echo -e \e[31mWarn:\e[0m SSH daemon is running else echo -e \e[32m[OK]:\e[0m No SSH daemon is running fi fi # telnetd pgrep telnetd >/dev/null if [ $? -eq 0 ] then echo -e \e[31mWarn:\e[0m telnet daemon is running else echo -e \e[32m[OK]:\e[0m No telnet daemon is running fi # Check whether we have a private or public IP address. # Ordering: wlan0, then eth0 PRIVATEIP_REGEX= ({circumflex over ()}127\.0\.0\.1) | ({circumflex over ()}10\.) | ({circumflex over ()}172\.1[6- 9]\.) | ({circumflex over ()}172\.2[0-9]\.) | ({circumflex over ()}172\.3[0-1]\.) | ({circumflex over ()}192\.168\.) # Extract all PI addresses from all network interfaces # and check for addresses outside of the private address range. ifconfig | grep inet addr | awk -F: {print $2} | awk {print $1} | \ egrep -q -v $PRIVATEIP_REGEX if [ $? -eq 0 ] then echo -e \e[31mWarn:\e[0m public IP address found else echo -e \e[32m[OK]:\e[0m no public IP address found fi # Check direct internet connectivity by # pinging Google's public DNS server. ping -c 1 8.8.8.8 >&/dev/null if [ $? -eq 0 ] then echo -e \e[31mWarn:\e[0m Direct internet connectivity is available else echo -e \e[32m[OK]:\e[0m Direct internet connectivity not available fi

[0055] Along with the suggested devices, systems and modules, respective methods for their operation are provided as well as a computer-readable medium having stored thereon instructions executable by a computer processor, the instructions, which, when executed by the processor, performing the method of the aspects as set forth above While the invention has been described in detail in the drawings and foregoing description, such description is to be considered illustrative or exemplary and not restrictive.

[0056] Variations to the disclosed embodiments can be understood and effected by those skilled in the art and practising the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word comprising does not exclude other elements or steps, and the indefinite article a or an does not exclude a plurality. The mere fact that certain elements or steps are recited in distinct claims does not indicate that a combination of these elements or steps cannot be used to advantage, specifically, in addition to the actual claim dependency, any further meaningful claim combination shall be considered disclosed.