Java Zero Day Vulnerabilities

Java , Secure Coding No Comments »

By David Svoboda
Member of the Technical Staff
CERT Secure Coding Initiative

David SvobodaA zero-day vulnerability refers to a software security vulnerability that has been exploited before any patch is published. In the past, vulnerabilities were widely exploited even when a patch was available, which means they were not zero-day. Today, zero-day vulnerabilities are common. Notorious examples include the recent Stuxnet and Operation Aurora exploits. Vulnerabilities may arise from a variety of sources, but most vulnerabilities are the result of simple coding errors. Consequently, developers need to understand common traps and pitfalls in the programming language, libraries, and platform to produce code that is free of vulnerabilities. To address this problem, CERT published The CERT Oracle Coding Standard for Java in 2011. This book is version 1 of this standard and was written primarily for Java SE 6, but also covers features introduced in Java SE 7. This coding standard provides secure coding rules that help programmers recognize and avoid vulnerabilities in their products. Each rule provides simple instructions regarding what a programmer must and must not do. Each rule description is accompanied by noncompliant code examples, as well as compliant solutions that can be used instead. In this blog post, I examine a Java zero-day vulnerability, CVE 2012-0507, which infected half a million Macintosh computers, and consider how this exploit could have been prevented through adherence to two secure coding rules.


Security in Continuous Integration

DevOps , Weekly DevOps No Comments »

By Chris Taschner
Project Lead
CERT Cyber Security Solutions Directorate

This post is the latest in a series to help organizations implement DevOps. 

Chris TaschnerSoftware development teams often view software security as an afterthought, something that can be added on after the product is fully functional. Although this approach may have made some sense in the past, today it’s largely seen as a mistake since it can lead to unanticipated vulnerabilities in released code. DevOps provides a mechanism for change and enforcement when it comes to security. DevOps practitioners should find it natural to integrate a security focus into development iterations by adding security tests to their continuous integration process. Continuous integration is the practice of merging all development versions of a code base several times a day. This practice provides the same level of automated enforcement for security attributes as for other functional and non-functional attributes, ultimately leading to more secure, robust software systems.

Making security testing a part of continuous integration enforces security standards on your software and identifies security as a first-class quality attribute of your project. Making this decision from the start on a new project enables those responsible for development and operations to make knowledgeable decisions about the architecture, design, and implementation with full consideration given to necessary security requirements. This process may mean choosing certain technologies over others based on security concerns. For instance, choosing to implement secure sockets layer (ssl) rather than sending data in the clear may improve application security. Being forced to make security decisions early may also mean that developers are incentivized to define expected development processes in a way that requires a certain level of security-focused unit test coverage for critical modules. For instance, employing tests to check that sql injection prevention is being employed properly.  By enforcing these decisions through continuous integration, teams can use their existing DevOps practices to ensure an unwavering—yet attainable and efficient—focus on software security.

Adding Security Testing to DevOps

The image above represents one approach for adding security testing to the DevOps cycle. 

While continuous security testing on new projects is clearly ideal, a strong argument exists for retrofitting security testing to continuous integration for ongoing software projects, even if security testing has been previously non-existent. As new features are secured, existing unchanged features may also see security benefits. Moreover, exposing the lack of security thinking in previous processes (e.g., by automating test coverage metrics or failing builds for security oversights) can motivate developers to refactor and secure previously unattended code. While this new security influence may take some time to propagate through existing codebases, fostering a security-aware culture in software development teams is a long-term win for any organization.

Every Thursday, the SEI Blog will publish a new blog post that will offer guidelines and practical advice to organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below.


Malware Analysis, Acquisition Strategies, Network Situational Awareness, & Cyber Risk - The Latest Research from the SEI

Cyber Risk and Resilience Management , Emerging Technologies , Resilience Management Model (RMM) No Comments »

By Douglas C. Schmidt
Principal Researcher

Douglas C. Schmidt As part of an ongoing effort to keep you informed about our latest work, I would like to let you know about some recently published SEI technical reports and notes. These reports highlight the latest work of SEI technologists in malware analysis, acquisition strategies, network situational awareness, and resilience management (with three reports from this research area), incident management, and future architectures. This post includes a listing of each report, author(s), and links where the published reports can be accessed on the SEI website.


Agile Software Teams: How they Engage with Systems Engineering on Department of Defense Acquisition Programs

1 Comment »

By Eileen Wrubel
Senior Member of the Technical Staff
Acquisition Support Program

Eileen WrubelTension and disconnects between software and systems engineering functions are not new. Grady Campbell wrote in 2004 that “systems engineering and software engineering need to overcome a conceptual incompatibility (physical versus informational views of a system)” and that systems engineering decisions can create or contribute to software risk if they “prematurely over-constrain software engineering choices” or “inadequately communicate information, including unknowns and uncertainties, needed for effective software engineering.” This tension holds true for Department of Defense (DoD) programs as well, which historically decompose systems from the system level down to subsystem behavior and breakdown work for the program based on this decomposition. Hardware-focused views are typically deemed not appropriate for software, and some systems engineers (and most systems engineering standards) have not yet adopted an integrated view of the two disciplines. An integrated view is necessary, however, because in complex software-reliant systems, software components often interact with multiple hardware components at different levels of the system architecture. In this blog post, I describe recently published research conducted by me and other members of the SEI’s Client Technical Solutions Division highlighting interactions on DoD programs between Agile software-development teams and their systems engineering counterparts in the development of software-reliant systems. 


What is DevOps?

DevOps , Weekly DevOps 1 Comment »

By Todd Waits
Project Lead
CERT Cyber Security Solutions Directorate

This post is the latest in a series to help organizations implement DevOps.

Todd Waits In a previous post, we defined DevOps as ensuring collaboration and integration of operations and development teams through the shared goal of delivering business value. Typically, when we envision DevOps implemented in an organization, we imagine a well-oiled machine that automates 

  • infrastructure provisioning
  • code testing 
  • application deployment 

Ultimately, these practices are a result of applying DevOps methods and tools. DevOps works for all sizes, from a team of one to an enterprise organization.