technology connected
security. Worse still, many of these credentials are shared across all the installations for a particular range of devices, making it very easy for a generic piece of malware to spread and gain access to a wide range of plants. However, securing the passwords of the devices only gives a minor improvement in overall security, as the underlying communications channels of the devices expose a significant attack surface. It is often assumed that the data passed over these channels would be produced by a trusted system and that per-device data validation is either unnecessary or could be simplified. This assumption fails when a third party (e.g., a hacker or malware) is able to manipulate or generate data passed over a channel. For example, the signals for a Polish tram system had been designed so that the drivers could control them by using a remote control. The system was considered to be secure as the hardware was not commercially available and no thought was given to the injection of commands from any other external source, resulting in a decision to use encrypted data without any validation. In 2008, a teenager modified a different remote control unit so that he could change the signals. His actions lead to the derailing of at least four trams, resulting in twelve people being injured.
CWE
According to research by the National Institute of Security Technology (NIST), 64% of software vulnerabilities stem from programming errors. The Common Weakness and Enumeration (CWE) is a strategic software assurance initiative run by the MITRE Corporation under a U.S. Federal grant, co-sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security. It lists those programming errors that lead to security failures within systems with the aim of improving the software assurance and review processes used to ensure connected devices are secure. Enumeration of the vulnerabilities in this way allows coding standards to be defined to target
30
APRIL 2012 RTC MAGAZINE
them so that they can be eliminated during development. The CWE database contains information on security weaknesses that have been proven to lead to exploitable vulnerabilities. These weaknesses could be at the infrastructure level (e.g., a poorly configured network and/or security appliance), policy and procedure level (e.g., sharing usernames and/or passwords) or coding level (e.g. failing to validate data). The CWE database holds information on actual exploits, not theoretical, and so only captures those coding weaknesses that have been exploited in the field. CWE should be used within the development environment to ensure that known vulnerabilities are not introduced into the software. Many of the issues that have been identified are amenable to automatic detection by static and/or dynamic checking tools. To obtain maximum benefit, such tools should be used as early as possible in the development process, as trying to add security in at the last minute is very unlikely to succeed. The adoption of other tool-enforced security standards, such as the CERT-C Secure Coding Standard, complements this objective and enhances the security characteristics even further.
To prevent the introduction of security vulnerabilities, a development team needs to have a common understanding of the security goals and approaches to be taken during development. This should include an assessment of the security risks and the establishment of the secure coding practices that are to be used. The risk assessment determines the quantitative and qualitative security risk for the various system components in relation to a concrete situation and recognized threat. This information is used to reduce security vulnerabilities in the areas that will have a high impact if their security is breached. The assessment results in the development of a set of security control and mitigation strategies that will form the core of the system security requirements. These security requirements become part of the same development process used for all other requirements. Detailed at the outset, the security requirements are then traced through the design, coding and testing stages in order to ensure fulfillment of the initial requirements. These linkages form documentation that demonstrates how the final system meets the security objectives laid down at the beginning.
Ensuring System Security
Coding Standards
Many security vulnerabilities can be traced to coding errors or architecture flaws and are generally hard and/ or expensive to fix once a system has been deployed. Unfortunately, many developers are only interested in the development and testing of core application functionality. Security is rarely tested with the same rigor. The security of a system needs to be considered as one of the most important attributes of a system. Security requirements need to be included up front in the system design and implemented during normal development if the final system is to be secure. Figure 1 illustrates the attributes associated with system quality. By focusing on these measures at all phases of the software development lifecycle, developers can help eliminate known weaknesses.
CWE is a “do not get caught by� list and is not an actual coding standard. However, coding standards can be used to ensure that the CWE issues are not present in a project. Compliance with these standards helps to ensure that project security goals are achieved, especially as many security issues result directly from the coding errors that they target. Additionally, compliance with a recognized standard helps to demonstrate that contractual security obligations have been met. Compliance with the chosen coding standard, or standards, should be a formal process (ideally tool-assisted, but manual is also possible) as it is virtually impossible for a programming team to follow all the rules and guidelines throughout the entire code-base. Adherence to the standards is a useful metric to apply when determining code quality.