Secure Software Development Can Be Challenging

Image Source: Gorodenkoff/Shutterstock.com

By Jeff Shepard for Mouser Electronics

Published December 22, 2020

The on-going explosion in the number of connected devices across all types of applications increases the importance of developing secure software. Every device is subject to a different set of risks, and therefore, the requirements for software security must be assessed in detail for each new project. The growing use of the cloud also opens new attack vectors and makes software security increasingly complex and difficult to achieve. Zero trust has become the new mantra of software security.

The development of secure software is always a challenge and is never a completed task. Understanding what you are protecting, who you are protecting it from, and the potential impact of various attacks are the starting points for developing secure software. The evolving nature of the threats means that security requirements often cannot be fully identified at the start of a project. They can be subject to change several times through the development process. And once the system or device is in the field, various cyber threats and threat vectors continue to evolve. Over-the-air updates and patches are being increasingly used to maintain security in the face of changing threats.

Software vulnerabilities are, unfortunately, an ever-present and dynamic risk (Figure 1). For that reason, you must ensure that your code is secure and protected. An insecure application lets in hackers. They can take direct control of a device–or provide an access path to another device. Software security is a multi-dimensional challenge that includes secure communications, secure operating systems, secure boot, secure data at rest and in transit, secure coding standards and practices to eliminate vulnerabilities, robustness testing, and so on. The following will explore what secure coding is and provide you with examples of resources for secure coding, including industry standards, guidelines, regulations, and accepted testing and validation protocols.

Figure 1: Software security is a multi-dimensional and constantly evolving challenge. (Source: buffaloboy/Shutterstock.com)

Secure coding

Secure coding is the development of computer software that protects against the accidental introduction of security vulnerabilities. By identifying insecure coding practices, you can take proactive steps to reduce or eliminate vulnerabilities in software before deployment significantly. The development of secure software is a complex process, including many national and international guidelines, regulations, and standards. It begins with threat modeling.

Threat modeling

Threat modeling and understanding the needed security level are important steps to take in the early stages of a new project in defining the goals for secure code development (Figure 2). Security costs time and effort and is not absolute. Security levels, scores, or ratings are employed by several standards and guidelines to define the capabilities of secure software. As a result, you need a clear understanding of each project’s specific security needs, and goals. The common elements in each approach to threat modeling include:

• Documenting data flows to identify where the system is vulnerable to attack.
• Systematically identifying as many possible threats as possible.
• Identifying controls to be used to reduce the likelihood or impact of each potential threat.

Figure 2: Threat modeling is a complex and critical first step in the development of secure software. (Source: Panchenko Vladimir/Shutterstock.com)

Some of the commonly used threat modeling approaches include:

• Microsoft Security Development Lifecycle (SDL) is an engineering technique you can use to help identify threats, attacks, vulnerabilities, and countermeasures that could affect your application.
• The Process for Attack Simulation and Threat Analysis (PASTA) is a seven-step, risk-centric methodology. It provides a process for aligning business objectives and technical requirements, taking into account compliance issues and business analysis.
• The Common Vulnerability Scoring System (CVSS) is an open framework for communicating software vulnerabilities’ characteristics and severity. CVSS consists of three metric groups: Base, Temporal, and Environmental.
• The Hybrid Threat Modeling Method (hTMM) was developed by the Carnegie Mellon University Software Engineering Institute in 2018. It consists of a combination of SQUARE (Security Quality Requirements Engineering Method), Security Cards (developed at the University of Washington), and Persona non Grata (PnG, developed at DePaul University).

Guidelines and regulations

Technical specification ISO/IEC TS 17961 is a set of coding rules for the C programming language. This specification defines best practices for ensuring the safety, reliability, security, and integrity of software written in C. The specification is designed to use static analysis of software code, reducing the cost of compliance. Two publications from the ISO define it:

• ISO/IEC TS 17961:2013: Information technology—Programming languages, their environments, and system software interfaces—C secure coding rules
• ISO/IEC TS 17961:2013/Cor 1:2016: Information technology—Programming languages, their environments and system software interfaces—C secure coding rules, Technical Corrigendum 1

MISRA C is a set of software development guidelines for the C programming language developed by the Motor Industry Software Reliability Association (MISRA). It aims to facilitate code safety, security, portability, and reliability, specifically those systems programmed in ISO C / C90 / C99. There is also a set of guidelines for MISRA C++. MISRA C has evolved as a widely accepted model for best practices by leading developers in sectors, including automotive, aerospace, telecom, medical devices, defense, railway, and others. For a claim of MISRA compliance to have meaning, it is necessary to establish:

• Use of a disciplined software development process.
• Exactly which guidelines are being applied.
• The effectiveness of the enforcement methods.
• The extent of any deviations from the guidelines.
• The status of any software components developed outside of the project.

Standards for secure coding

Secure boot or the authentication of code before runtime is an increasingly important aspect of secure coding. It is especially important in applications where an attack’s risk or potential impact is high, such as avionics, autonomous vehicles, medical, and industrial systems. Also, the new IoT device security standards from the European Telecommunications Standards Institute (ETSI) (TS 103 645) and National Institute of Standards and Technology (NIST) (SP 800-193) include authentication of code before runtime.

The ISA/IEC 62443 series of standards, developed by the International Society of Automation ISA99 committee and adopted by the International Electrotechnical Commission (IEC), provides a flexible framework to address and mitigate current and future security vulnerabilities in industrial automation and control systems. ISA/IEC 62443-3-2, Security Risk Assessment, System Partitioning and Security Levels, is under development.

IEC 62443 requires that a static code analyzer be used to enforce secure coding standards, including:

• Common Weakness Enumeration (CWE™), a community-developed list of software and hardware weakness types. It serves as a common language, a measuring stick for security tools, and a baseline for weakness identification, mitigation, and prevention efforts.
• CERT from the Carnegie Mellon University Software Engineering Institute includes coding standards for commonly used programming languages such as C, C++, Java, Perl, and the Android™ platform.
• The Open Web Application Security Project® (OWASP®) is a nonprofit foundation that works to improve software security.
• The U.S. Defense Information Systems Agency (DISA) provides Security Technical Implementation Guides (STIG) that are especially relevant to the Department of Defense projects.

Some additional secure coding resources are:

• Common vulnerabilities and exposures (CVE) is a list of cybersecurity vulnerabilities and exposures found in a specific software product. The list is linked to information from several different vulnerability databases, allowing users to compare security tools and services more easily.

• The National Vulnerabilities Database (NVD) from NIST is the U.S. government repository of standards-based vulnerability management data, and it is connected with the CVE list and provides additional content, including how to fix vulnerabilities, severity scores, and impact ratings. To calculate severity scores, a common vulnerability scoring system (CVSS) must be used. CVSS is an open industry standard for assessing the severity of software vulnerabilities.

• The Payment Application Data Security Standard is a global security standard. It applies to the development of payment application software. It was previously known as the Payment Application Best Practices (PABP).

• SP 800-82 from NIST guides how to secure Industrial Control Systems. NIST also addresses concerns of ICS security in mid-sized companies and has begun expanding testbeds for robotics, smart transportation, and chemical processing, among others. NIST also has produced a Security Content Automation Protocol (SCAP).

Testing and validation

Penetration tests are an important component of a full security audit. A penetration test is an authorized simulated cyberattack on a system (Figure 3). The test is conducted to identify weaknesses, including the potential for unauthorized parties to gain access to the system's features and data, as well as strengths, enabling a full risk assessment to be completed. Testing typically includes network penetration testing, application security testing, and testing of controls and processes around the networks and applications.

For example, the Payment Card Industry Data Security Standard requires penetration testing regularly and after system changes. Several standard frameworks and methodologies exist for conducting penetration tests. These include the Open Source Security Testing Methodology Manual, the Penetration Testing Execution Standard, NIST SP 800-115, the Information System Security Assessment Framework, and the OWASP Testing Guide.

Figure 3: Penetration testing should consider malicious actors both outside the network trying to come in (external testing) and attacks from inside the network. (Source: Panchenko Vladimir/Shutterstock.com)

Common weakness enumeration (CWE™) is a community-developed list of software and hardware weakness types. CWE helps developers and security practitioners to:

• Describe and discuss software and hardware weaknesses in a common language.
• Check for weaknesses in existing software and hardware products.
• Evaluate coverage of tools targeting these weaknesses.
• Leverage a common baseline standard for weakness identification, mitigation, and prevention efforts.
• Prevent software and hardware vulnerabilities before deployment.

The Evaluation Assurance Level (EAL) of a device is a numerical value from 1 to 7 that is determined using an internationally standardized Common Criteria security evaluation. The higher the EAL levels, the more detailed the verification and testing requirements are outlined in the corresponding devices Security Target document. A higher EAL level does not necessarily identify a more secure device. It simply indicates thorough testing and verification process. In the case of two devices having the same Security Target definitions, the higher-rating device should be more trustworthy.

EAL requirements can also be augmented to include assurance requirements more extensive than the minimum needed for a given EAL. Augmented EALs can be indicated using the word augmented or using a plus sign as in EAL5+.

Conclusion

Software security is a multi-dimensional challenge, and the importance of developing secure software is growing across a wide variety of applications. In response, secure coding standards are also growing in importance, as is the need to test and validate performance. As shown, developers have access to a wide range of tools beginning with threat analysis through the development process to testing and validation.