Wirral, UK, July 19, 2011. LDRA won the attention of Military Embedded Systems (MES) editors with its announcement that the LDRA tool suite is now capable of testing software for Common Weakness Enumeration (CWE) Compatibility. By awarding the Editor’s Choice award to this announcement, MES recognizes both the criticality of security in today’s increasingly connected systems and LDRA’s leadership in preventing the catastrophic impact a security breach can cause to a company’s revenue, brand and customer trust.
The CWE project involves an international, community-developed formal list of common software weaknesses. Sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security, the CWE project aims to better understand flaws in software and to create automated tools that can be used to identify, fix and prevent those flaws. For the LDRA tool suite, CWE Compatibility ensures companies can eliminate most security vulnerabilities early in the development lifecycle, lower downstream testing costs, and mitigate the risk of a devastating security breach.
“In an increasingly connected world, systems fundamental to our infrastructure such as our power grid, communications and finances are vulnerable to external attack,” noted Sharon Hess, OpenSystems Media, Assistant Managing Editor, Military and Aerospace Group. “Unfortunately, much of our vulnerability stems from exploitation of coding errors. Such errors could easily be avoided by implementing security standards that tools such as the LDRA tool suite can enforce through static analysis, dynamic analysis and unit testing.”
LDRA’s commitment to software security is a natural extension to a 35-year commitment to programming standards and industry certification. From its inception, LDRA has advocated for software quality by design, a mantra VDC Research applied to security in its blog “The New (Read: Old) Demon of Embedded Device Development.” VDC asserted, “To focus on the ‘secure by design’ methods, which we believe to be a critical first step to secure device deployment, we view there to be three distinct approaches: development tools targeted at precluding the introduction of security vulnerabilities, testing tools, and the implementation of specific run-time software (e.g. RTOS, hypervisor, etc.).”
“Research at the National Institute of Security Technology indicates that 64% of software vulnerabilities stem from programming errors,” notes Ian Hennell, LDRA Operations Director. “Because of this, our goal is to encourage development teams to program security in by starting at the requirements level and applying security standards throughout the entire development lifecycle. Such a proactive stance mitigates risk, dramatically cuts costs and enables teams to identify errors early instead of at the systems level where it’s much more expensive to correct those errors.”
LDRA addresses security in all aspects of the LDRA tool suite. CWE compatibility is enforced via static and dynamic analysis as well as during unit testing. This same level of enforcement extends to the CERT C Secure Coding standard which aims to eliminate insecure coding practises and undefined behaviours that lead to exploitable vulnerabilities.
Both CWE and CERT C are managed by LDRA’s TBsecure which interfaces with the LDRA tool suite to easily show how source code performs against security vulnerabilities, fault-detection and adherence to the required security standards. Findings from TBsecure’s application of CERT C and CWE coding rules graphically illustrate code quality, fault detection and avoidance measures through call graphs, flow graphs and code review reports. Managers and team developers can collectively monitor the implementation of security metrics in their applications in an easy-to-read, intuitive format.
“Enforcing security standards represents the same commitment to software quality that LDRA has advocated for more than 35 years,” added Hennell. “LDRA champions software quality not only in the tools it produces, but by committing executive and field application engineer involvement in the technical committees of nine standards committees.”