An Introduction to the Mission Thread Workshop

Architecture , Mission Thread Workshop 2 Comments »

By Mike Gagliardi
Principal Engineer 
Software Solutions Division

Mike GagliardiIn Department of Defense (DoD) programs, cooperation among software and system components is critical. A system of systems (SoS) is used to accomplish a number of missions where cooperation among individual systems is critical to providing (new) capabilities that the systems could not provide. SoS capabilities are a major driver in the architecture of the SoS and selection of constituent systems for the SoS. There are additional critical drivers, however, that must be accounted for in the architecture that significantly impact the behavior of the SoS capabilities, as well as the development and sustainment of the SoS and its constituent systems’ architectures. These additional drivers are the quality attributes, such as performance, availability, scalability, security, usability, testability, safety, training, reusability, interoperability, and maintainability. This blog post, the first in a series, introduces the Mission Thread Workshop (MTW), and describes the role that it plays in assisting SoS programs to elicit and refine end-to-end SoS mission threads augmented with quality attribute considerations.


Four Types of Shift Left Testing

Testing 2 Comments »

By Donald Firesmith
Principal Engineer
Software Solutions Division

Don Firesmith One of the most important and widely discussed trends within the software testing community is shift left testing, which simply means beginning testing as early as practical in the lifecycle. What is less widely known, both inside and outside the testing community, is that testers can employ four fundamentally-different approaches to shift testing to the left. Unfortunately, different people commonly use the generic term shift left to mean different approaches, which can lead to serious misunderstandings. This blog post explains the importance of shift left testing and defines each of these four approaches using variants of the classic V model to illustrate them.


DevOps Technologies: Fabric or Ansible

DevOps , DevOps Tips No Comments »

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

This post is the latest installment in a series aimed at helping organizations adopt DevOps.

Tim PalkoThe workflow of deploying code is almost as old as code itself. There are many use cases associated with the deployment process, including evaluating resource requirements, designing a production system, provisioning and configuring production servers, and pushing code to name a few. In this blog post I focus on a use case for configuring a remote server with the packages and software necessary to execute your code. This use case is supported by many different and competing technologies, such as ChefPuppetFabricAnsibleSalt, andForeman, which are just a few of which you are likely to have heard on the path to automation in DevOps. All these technologies have free offerings, leave you with scripts to commit to your repository, and get the job done. This post explores Fabric and Ansible in more depth. To learn more about other infrastructure-as-code solutions, check out Joe Yankel's blog post on Docker or my post on Vagrant.


An Enhanced Tool for Securing Android Apps

Android , Secure Coding , Tools No Comments »

By Lori Flynn
Member of the Technical Staff
CERT Secure Coding Team

This blog post was co-authored by Will Klieber.

flynn_loriEach software application installed on a mobile smartphone, whether a new app or an update, can introduce new, unintentional vulnerabilities or malicious code. These problems can lead to security challenges for organizations whose staff uses mobile phones for work. In April 2014, we published a blog post highlighting DidFail (Droid Intent Data Flow Analysis for Information Leakage), which is a static analysis tool for Android app sets that addresses data privacy and security issues faced by both individual smartphone users and organizations. This post highlights enhancements made to DidFail in late 2014 and an enterprise-level approach for using the tool.


Data-Driven Software Assurance

Team Software Process (TSP) 2 Comments »

By Mike Konrad
Principal Researcher
Software Solutions Divisions

Michael KonradAs recent news headlines about ShellshockSonyAnthem, and Target have demonstrated, software vulnerabilities are on the rise. The U.S. General Accounting Office in 2013 reported that “operational vulnerabilities have increased 780 percent over the past six years.” These vulnerabilities can be hard and expensive to eradicate, especially if introduced during the design phase. One issue is that design defects exist at a deeper architectural level and thus can be hard to find and address. Although coding-related vulnerabilities are preventable and detectable, until recently scant attention has been paid to vulnerabilities arising from requirements and design defects. In 2014, the IEEE Computer Society Center for Secure Design was established to “shift some of the focus in security from finding bugs to identifying common design flaws—all in the hope that software architects can learn from others’ mistakes.” “We believe that if organizations design secure systems, which avoid such flaws, they can significantly reduce the number and impact of security breaches,” the center states in its report Avoiding the Top 10 Security Design Flaws. On a separate front, a group of researchers from various disciplines within the Carnegie Mellon University Software Engineering Institute recently came together to explore the implications of design-related vulnerabilities and quantify their effects on system cost and quality. This post highlights key issues and findings of our work.