By Will Dormann
The Heartbleed bug, a serious vulnerability in the Open SSL crytographic software library, enables attackers to steal information that, under normal conditions, is protected by the Secure Socket Layer/Transport Layer Security (SSL/TLS) encryption used to secure the internet. Heartbleed and its aftermath left many questions in its wake:
- Would the vulnerability have been detected by static analysis tools?
- If the vulnerability has been in the wild for two years, why did it take so long to bring this to public knowledge now?
- Who is ultimately responsible for open-source code reviews and testing?
- Is there anything we can do to work around Heartbleed to provide security for banking and email web browser applications?
In late April 2014, researchers from the Carnegie Mellon University Software Engineering Institute and Codenomicon, one of the cybersecurity organizations that discovered the Heartbleed vulnerability, participated in a panel to discuss Heartbleed and strategies for preventing future vulnerabilities. During the panel discussion, we did not have enough time to address all of the questions from our audience, so we transcribed the questions and panel members wrote responses. This blog posting presents questions asked by audience members during the Heartbleed webinar and the answers developed by our researchers. (If you would like to view the entire webinar, click here.)
By Robert C. Seacord
Secure Coding Technical Manager
Software developers produce more than 100 billion lines of code for commercial systems each year. Even with automated testing tools, errors still occur at a rate of one error for every 10,000 lines of code. While many coding standards address code style issues (i.e., style guides), CERT secure coding standards focus on identifying unsafe, unreliable, and insecure coding practices, such as those that resulted in the Heartbleed vulnerability. For more than 10 years, the CERT Secure Coding Initiative at the Carnegie Mellon University Software Engineering Institutehas been working to develop guidance—most recently, The CERT C Secure Coding Standard: Second Edition—for developers and programmers through the development of coding standards by security researchers, language experts, and software developers using a wiki-based community process. This blog post explores the importance of a well-documented and enforceable coding standard in helping programmers circumvent pitfalls and avoid vulnerabilities.
By Anne Connell
Design Team Lead
CERT Cyber Security Solutions Directorate
This blog post was co-authored by Tim Palko.
According to a report issued by the Government Accountability Office (GAO) in February 2013,
the number of cybersecurity incidents reported that could impact
“federal and military operations; critical infrastructure; and the
confidentiality, integrity, and availability of sensitive government,
private sector, and personal information” has increased by 782
percent—from 5,503 in 2006 to 48,562 in 2012. In that report, GAO also
stated that while there has been incremental progress in coordinating
the federal response to cyber incidents, “challenges remain in sharing
information among federal agencies and key private sector entities,
including critical infrastructure owners.” Progress in this area was
hindered by “difficulties in sharing and accessing classified
information and the lack of a centralized information-sharing system,”
the report stated. This blog post describes a tool that members of the CERT Cyber Security Solutions (CS2) Directorate
are developing to provide the various agencies and organizations that
respond to cyber incidents a platform by which to share information and