They cited a document recently published by the U.S. Department of Homeland Security on product security bad practices (docket CISA-2024-0028), in particular areas pertaining to memory-unsafe languages like C and C++ and offered constructive comments to help inform ongoing cybersecurity developments.
He added that modern, next-generation sound and exhaustive static analysers such as TrustInSoft Analyser (TISA) support CISA's software security efforts by offering tools that mathematically prove the absence of memory-related vulnerabilities in software written in C and C++.
These tools are capable of scaling large codebases and offer comprehensive detection of undefined behaviours, including memory safety vulnerabilities. Such analysers have matured to a level where they can be incorporated at various stages of the software development lifecycle (SDLC) and can be invaluable for the vast number of organisations that rely on C and C++.
TISA differs from other tools on the market due to its ability to provide mathematical guarantees of software safety, which goes beyond the heuristic-based detection offered by traditional static or dynamic analysers. Recognised by the U.S. National Institute of Standards and Technology (NIST) for leveraging advanced formal methods, including abstract interpretation, TrustInSoft can mathematically guarantee analysed software is free of critical runtime errors and vulnerabilities.
In his comments, Monate went on to acknowledge that while memory-safe languages like Rust offer promising alternatives, their toolchains do not yet fully support the full range of embedded microcontrollers used across critical industries. For many organisations, C and C++ remain the most viable options, given the available and reliable toolchains compatible with diverse hardware platforms.
It was also suggested that the CISA provide further clarity around the definition of “product” scope, as outlined by the European Union in the Cyber Resilience Act, which would help organisations to ensure adherence with CISA guidelines.
In view of these considerations, Monate recommended additions to the CISA that could be included in the final CISA document.
He said, “When using memory-unsafe languages (e.g., C/C++) or unsafe features of a memory-safe language, it is advisable to employ sound and exhaustive static analysers that use formal verification techniques. These tools can ensure thorough coverage and identify memory-related bugs, enhancing the security of codebases.
“A dedicated security activity should be embedded within the SDLC, leveraging state-of-the-art tools (sound static analyser) and processes during development, testing, and maintenance phases. This aligns with the Shift Left paradigm, which advocates for early integration of security measures.
“Continuous Integration/Continuous Deployment (CI/CD) pipelines should incorporate security checks as part of automated workflows, ensuring regular and consistent assessments.
“And for high-criticality products or sensitive libraries - based on threat models - organisations should conduct third-party security assessments before product release. Depending on product criticality, such assessments could range from detailed bug reporting by sound and exhaustive static analysers to physical testing, e.g., penetration testing and security certifications by accredited security labs.”
@TrustInSoft @CISAgov @CRAConference #PAuto #IoT #Cybersecurity
No comments:
Post a Comment