DevOps and Your Organization: Where to Begin

DevOps , Weekly DevOps No Comments »

C. Aaron Cois
Software Engineering Team Lead
CERT Cyber Security Solutions Directorate
This post is the latest in a weekly series to help organizations implement DevOps.

C. Aaron CoisOn the surface, DevOps sounds great. Automation, collaboration, efficiency—all things you want for your team and organization. But where do you begin? DevOps promises high return on investment in exchange for a significant shift in culture, process, and technology. Substantially changing any one of those things in an established organization can feel like a superhuman feat. So, how can you start your organization on the path to DevOps without compromising your existing business goals and trajectories?

Read more...

Managing Model Complexity

Architecture , Model-Based Engineering No Comments »

By Julien Delange
Member of the Technical Staff
Software Solutions Division

Julien Delange Over the years, software architects and developers have designed many methods and metrics to evaluate software complexity and its impact on quality attributes, such as maintainability, quality, and performance. Existing studies and experiences have shown that highly complex systems are harder to understand, maintain, and upgrade. Managing software complexity is therefore useful, especially for software that must be maintained for many years. To generate the complexity metrics, tools extract applicable data—such as source lines of code, cohesion, coupling, and more—from binary or source code to analyze the software and report its complexity and quality. Several tools support these techniques and help stakeholders manage the evolution of system development, provide quality improvements, prevent lack of cohesion, and perform other tasks. To date, such approaches have been successfully used in many projects, but as system development moves toward model-based engineering, these methods, metrics, and tools might not be sufficient to manage model complexity. This blog post details the state of the art for reporting model complexity and introduces research underway at the SEI in this area.

Read more...

DevOps Technologies: Vagrant

DevOps , Weekly DevOps No Comments »

By Tim Palko
Senior Member of the Technical Staff
CERT Cyber Security Solutions Directorate

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

Tim PalkoEnvironment parity is the ideal state where the various environments in which code is executed behave equivalently. The lack of environment parity is one of the more frustrating and tenacious aspects of software development. Deployments and development both fall victim to this pitfall too often, reducing stability, predictability, and productivity. When parity is not achieved, environments behave differently, which makes troubleshooting hard and can make collaboration seem impossible. This lack of parity is a burden for too many developers and operational staff.  Looking back on almost every problem I have seen in new production deployments, I find it hard to think of one issue that wasn't due in some part to lack of parity. For developers, this pain is felt when integrating and testing code.

Read more...

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.

Read more...

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.

Read more...

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

Cyber Risk , 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.

Read more...

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

No Comments »

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. 

Read more...

What is DevOps?

DevOps , Weekly DevOps No Comments »

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.

 

Read more...