The CERT C Secure Coding Standard provides rules and recommendations for secure coding in the C programming language. The goal of these rules and recommendations is to eliminate insecure coding practices and undefined behaviours that can lead to exploitable vulnerabilities. The application of the secure coding standard will lead to higher-quality systems that are robust and more resistant to attack
Why Secure Coding?
Security is an important parameter that contributes to overall system quality. Easily avoided software defects are a primary cause of commonly exploited software vulnerabilities. CERT (Computer Emergency Response Team) has observed, through an analysis of thousands of vulnerability reports, that most vulnerabilities stem from a relatively small number of common programming errors. By identifying insecure coding practices and developing secure alternatives, software developers can take practical steps to reduce or eliminate vulnerabilities before deployment.
As part of this initiative, the CERT Secure Coding team works with software developers and software development organisations to reduce vulnerabilities resulting from coding errors before they are deployed. In collaboration with the software assurance and C language development communities, CERT developed the CERT C Secure Coding Standard to provide secure coding guidance to developers and suggests secure code must exhibits properties like:
Dependability: Dependable software executes predictably and operates correctly under all conditions, including hostile conditions, including when the software comes under attack or runs on a malicious host.
Trustworthiness: Trustworthy software contains few if any vulnerabilities or weaknesses that can be intentionally exploited to subvert or sabotage the software's dependability. In addition, to be considered trustworthy, the software must contain no malicious logic that causes it to behave in a malicious manner.
Survivability: Survivable software is software that is resilient enough to (1) either resist (i.e., protect itself against) or tolerate (i.e., continue operating dependably in spite of) most known attacks plus as many novel attacks as possible, and (2) recover as quickly as possible, and with as little damage as possible, from those attacks that it can neither resist nor tolerate.
Solution: Integrating Security into the Software Development Lifecycle (SDLC)
"Security enhancement" of the SDLC process mainly involves the adaptation or augmentation of existing SDLC activities, practices, and checkpoints, and in a few instances, it may also entail the addition of new activities, practices, or checkpoints. In very few instances, it may also require the elimination or wholesale replacement of certain activities or practices that are known to obstruct the ability to produce secure software. The key elements of a secure software life cycle process are:
Security risk identification
Add security to system requirements
Add security to architectural design
Adopt secure coding practices
Test for security or security testing practices that focus on verifying the dependability, trustworthiness, and sustainability of the software being tested.
TBsecure® automates documentation for security compliance and certification.
LDRA, the leading provider of automated software verification, source code analysis, and test tools has developed TBsecure® to provide developers with the means to determine software compliance to the Secure Coding Standard (CERT C), which identifies the common programming errors behind the majority of software security attacks.
LDRA Testbed, the core analysis engine of the LDRA tool suite, performs the static analysis required for coding standards enforcement. TBvision may then be used to review the results against any of the many LDRA tool suite supported industry coding standards, including CERT C.
Building Security into the SDLC
The foundation of sound software design and development practices starts with requirements, which establish the verification baseline for the project; the highest level description of what the 'right' system is. This includes both the functional requirements (i.e. what the system is supposed to do), together with non-functional requirements (e.g. performance requirements). In addition, requirements should describe the assurance activities necessary to ensure that the requirements have been implemented correctly. This refers to the ability to link system requirements to software safety requirements, then from software safety requirements to design requirements and then to source code and the associated test cases. Tracing requirements is the best way to ensure that the final system does exactly what is specified by the initial requirements.
The LDRA tool suite spans the entire software development lifecycle, from requirements traceability through static and dynamic software analysis and unit testing, facilitating the process automation required to achieve good quality software, which is on time and within budget. The accuracy, determinism and formal reporting capabilities of the LDRA tool suite lend themselves to their use in the development of safety critical software.
Helps drive security focus
Requirements Traceability - Ensures security focus throughout SDLC
Static Analysis - Improves the overall quality of code
Unit Test - Improves security testing productivity - Helps ensure 100% code coverage
Test Verification - Ensures 100% requirements coverage