Archive: 2018-08

This post was co-authored by Cecilia Albert and Harry Levinson.

At the SEI we have been involved in many programs where the intent is to increase the capability of software systems currently in sustainment. We have assisted government agencies who have implemented some innovative contracting and development strategies that provide benefits to those programs. The intent of the blog is to explain three approaches that could help others in the DoD or federal government agencies who are trying to add additional capability to systems that are currently in sustainment. Software sustainment activities can include correcting known flaws, adding new capabilities, updating existing software to run on new hardware (often due to obsolescence issues), and updating the software infrastructure to make software maintenance easier.

In the first post in this series, I presented 10 types of application security testing (AST) tools and discussed when and how to use them. In this post, I will delve into the decision-making factors to consider when selecting an AST tool and present guidance in the form of lists that can easily be referenced as checklists by those responsible for application security testing.

IPv6 deployment is on the rise. Google reported that as of July 14 2018, 23.94 percent of users accessed its site via IPv6, up 6.16 percent from that same date in 2017. Drafted in 1998 and an Internet Standard as of July 2017, Internet Protocol 6 (IPv6) is intended to replace IPv4 in assigning devices on the internet a unique identity. Plans for IPv6 got underway after it was realized that IPv4's cap of 4.3 billion addresses would not be sufficient to cover the number of devices accessing the internet. This blog post is the first in a series aimed at encouraging IPv6 adoption, whether at the enterprise-wide level, the organizational level, or the individual, home-user level.

It's common for large-scale cyber-physical systems (CPS) projects to burn huge amounts of time and money with little to show for it. As the minimum viable product (MVP) strategy of fast and focused stands in sharp contrast to the inflexible and ponderous product planning that has contributed to those fiascos, MVP has been touted as a useful corrective. The MVP strategy has become fixed in the constellation of Agile jargon and practices. However, trying to work out how to scale MVP for large and critical CPS, I found more gaps than fit. This is the first of three blog posts highlighting an alternative strategy that I created, the Minimum Viable Capability (MVC), which scales the essential logic of MVP for CPS. MVC adapts the intent of the MVP strategy--to focus on rapidly developing and validating only essential features--to systems that are too large, too complex, or too critical for MVP.