By Mike Gagliardi,
Software Solutions Division
In 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.
By Donald Firesmith
Software Solutions Division
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.
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.
The 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 Chef, Puppet, Fabric, Ansible, Salt, 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.
By Lori Flynn
Member of the Technical Staff
CERT Secure Coding Team
This blog post was co-authored by Will Klieber.
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.
By Mike Konrad
Software Solutions Divisions
As recent news headlines about Shellshock, Sony, Anthem, 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.