JAN-FEB 2018

Issue link:

Contents of this Issue


Page 35 of 53

36 INTECH JANUARY/FEBRUARY 2018 WWW.ISA.ORG ware to install itself onto a computer and for users to copy their own pro- grams to a workstation, not realizing that these programs may interfere with control system software or have vulner- abilities that can be attacked. To find nonessential software, exam- ine the programs in the start menu (or equivalent), and use an administrative tool, such as control panel, to check the installed programs and services. You may also search the file system of the device for executables and DLL files that should not be there. Check to make sure games, email programs, and other unnecessary or unauthorized applications are not present. Vital sign #6 Does your supply chain program re- quire product developers in the supply chain (suppliers, their suppliers, etc.) to use security best practices? Security best practices for developers are embodied in security additions to their develop- ment and product support processes. Upgraded product development processes are standardized in ISA/IEC 62443-4-1 and are commonly referred to collectively as a Secure Develop- ment Lifecycle (SDL). Although not all developers have upgraded their devel- opment processes to a full SDL, many follow a good number of SDL best prac- tices. So, instead of asking the product developer if it has implemented an SDL, ask about the security practices in its current development process. The key components of an SDL that are of interest are: (1) documenting se- curity capabilities provided by the ICS in which the product will be used, (2) identifying security threats to which the product is expected to be exposed, (3) documenting and tracing product security requirements through design and implementation, and (4) specify- ing the types of security tests to which the product will be subjected. The first two address the environ- ment in which the product is expected to be used. The third and fourth ad- dress the security features of the prod- uct, including assurance that those features were implemented correctly and completely. The fourth, should, at a minimum, include testing of secu- rity requirements, testing for known vulnerabilities, and exhaustive testing of invalid inputs, also known as fuzz testing. Additional testing, such as threat testing and penetration testing, can provide greater confidence that the product has adequate security. Of course, no amount of testing guaran- tees an absence of security flaws. Security best practices for product support are equally valuable, and are often incorporated into SDL practices. They include security patching, vul- ner ability handling and reporting, and security-related documentation that describes how to harden, configure, use, and securely decommission products. Vital sign #7 Is confidential ICS data protected from disclosure, and is critical data protected from tampering? For example, are com- munications carrying confidential data encrypted? Are programs, configura- tion files, run-time parameters (e.g., set points, alarm limits), logs, and backup data protected from tampering? Transmitting confidential data—like recipes, trade secrets, production data, and other control system informa- tion—in the clear makes industrial es- pionage easier. Similarly, program files, configuration files, and critical param- eters/data that are not protected from unauthorized access are susceptible to being changed or even replaced by at- tackers. Leaving this data unprotected from tampering gives attackers an opening to insert spyware into files or to change the way the system operates. To assess this vital sign, first look to see if ICS data is categorized or clas- sified according to its security needs. Second, make sure that user access controls are set to prevent unauthor- ized reading of confidential data and unauthorized writing/updating of files and critical data. Third, for highly con- fidential data, like passwords and trade can flood the network or interfere with device operations (e.g., if devices are scanned too rapidly). Testing scan rates before putting them into operation is recommended. The fourth capability protects against someone connecting an un - authorized device to the network. For example, attackers may try to connect an unauthorized laptop to a wireless access point, or they may unplug an authorized device from the network and then connect their own device or network device in its place. Connecting a network device in place of an original authorized device ex - tends the network. Attackers not only can plug one or more of their own de - vices into the network, but can also reconnect the original device, so users will not notice a change in connectiv - ity. When the additional network device has wireless capabilities, attacker de - vices can be located anywhere within wireless range. However, having capa - bility four helps administrators find them and take corrective action. Vital sign #5 Are your workstations and other de- vices hardened for security? You should check to make sure that (1) they have been stripped down to only necessary software, (2) anti-malware software is running and current, and (3) security patches are regularly installed. Security patches close vulnerabilities that attack - ers often successfully exploit using free hacker tool kits downloaded from the Internet. Capabilities of vital sign #2 above can be used to en sure that an- ti-malware updates and patches are current. To verify that devices are stripped down, ask your vendors if they removed unnecessary software before delivery, and then look for software that may have been loaded after the device was installed. It is all too common for mal - SPECIAL SECTION Security patches close vulnerabilities that attackers often successfully exploit using free hacker tool kits downloaded from the Internet.

Articles in this issue

Links on this page

Archives of this issue

view archives of InTech - JAN-FEB 2018