SEI Insights

SEI Blog

The Latest Research in Software Engineering and Cybersecurity

This blog post is the sixth in a series on Agile adoption in regulated settings, such as the Department of Defense, Internal Revenue Service, and Food and Drug Administration.

"Across the government, we've decreased the time it takes across our high-impact investments to deliver functionality by 20 days over the past year alone. That is a big indicator that agencies across the board are adopting agile or agile-like practices," Lisa Schlosser, acting federal chief information officer, said in a November 2014 interview with Federal News Radio. Schlosser based her remarks on data collected by the Office of Management and Budget (OMB) over the last year. In 2010, the OMB issued guidance calling on federal agencies to employ "shorter delivery time frames, an approach consistent with Agile" when developing or acquiring IT. As evidenced by the OMB data, Agile practices can help federal agencies and other organizations design and acquire software more effectively, but they need to understand the risks involved when contemplating the use of Agile. This ongoing series on Readiness & Fit Analysis (RFA) focuses on helping federal agencies and other organizations in regulated settings understand the risks involved when contemplating or embarking on a new approach to developing or acquiring software. Specifically, this blog post, the sixth in a series, explores issues related to system attributes organizations should consider when adopting Agile.

Attacks and disruptions to complex supply chains for information and communications technology (ICT) and services are increasingly gaining attention. Recent incidents, such as the Target breach, the HAVEX series of attacks on the energy infrastructure, and the recently disclosed series of intrusions affecting DoD TRANSCOM contractors, highlight supply chain risk management as a cross-cutting cybersecurity problem. This risk management problem goes by different names, for example, Supply Chain Risk Management (SCRM) or Risk Management for Third Party Relationships. The common challenge, however, is having confidence in the security practices and processes of entities on which an organization relies, when the relationship with those entities may be, at best, an arms-length agreement. This blog post highlights supply chain risks faced by the Department of Defense (DoD), federal civilian agencies, and industry; argues that these problems are more alike than different across these sectors; and introduces practices to help organizations better manage these risks.

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.

Occasionally this blog will highlight different posts from the SEI blogosphere. Today we are highlighting a recent post by Will Dormann, a senior member of the technical staff in the SEI's CERT Division, from the CERT/CC Blog. This post describes a few of the more interesting cases that Dormann has encountered in his work investigating attack vectors for potential vulnerabilities. An attack vector is the method that malicious code uses to propagate itself or infect a computer to deliver a payload or harmful outcome by exploiting system vulnerabilities.

A 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.

Software 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 integrationprocess. 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.

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