The prevalence of Agile methods in the software industry today is obvious. All major defense contractors in the market can tell you about their approaches to implementing the values and principles found in the Agile Manifesto. Published frameworks and methodologies are rapidly maturing, and a wave of associated terminology is part of the modern lexicon. We are seeing consultants feuding on Internet forums as well, with each one claiming to have the "true" answer for what Agile is and how to make it work in your organization. The challenge now is to scale Agile to work in complex settings with larger teams, larger systems, longer timelines, diverse operating environments, and multiple engineering disciplines. I recently explored the issues surrounding scaling Agile within the Department of Defense (DoD) with Mary Ann Lapham, Suzanne Miller, Eileen Wrubel, and Peter Capell. This blog post, an excerpt of our recently published technical note Scaling Agile Methods for Department of Defense Programs, presents five perspectives on scaling Agile from leading thinkers in the field including Scott Ambler, Steve Messenger, Craig Larman, Jeff Sutherland, and Dean Leffingwell.
Interest in Agile and lightweight development methods in the software development community has become widespread. Our experiences with the application of Agile principles have therefore become richer. In my blog post, Toward Agile Strategic Planning, I wrote about how we can apply Agile principles to strategic planning. In this blog post, I apply another Agile concept, technical debt, to another organizational excellence issue. Specifically I explore whether organizational debt is accrued when we implement quick organizational change, short-cutting what we know to be effective change management methods. Since I started considering this concept, Steve Blank wrote a well-received article about organizational debt in the context of start-up organizations. In this post, I describe organizational debt in the context of change management and describe some effects of organizational debt we are seeing with our government clients.
The Domain Name System (DNS) is an essential component of the Internet, a virtual phone book of names and numbers, but we rarely think about it until something goes wrong. As evidenced by the recent distributed denial of service (DDoS) attack against Internet performance management company Dyn, which temporarily wiped out access to websites including Amazon, Paypal, Reddit, and the New York Times for millions of users down the Eastern Seaboard and Europe, DNS serves as the foundation for the security and operation of internal and external network applications. DNS also serves as the backbone for other services critical to organizations including email, external web access, file sharing and voice over IP (VoIP). There are steps, however, that network administrators can take to ensure the security and resilience of their DNS infrastructure and avoid security pitfalls. In this blog post, I outline six best practices to design a secure, reliable infrastructure and present an example of a resilient organizational DNS.
As part of an ongoing effort to keep you informed about our latest work, this blog post summarizes some recently published books, SEI technical reports, podcasts and webinars on insider threat, using malware analysis to identify overlooked security requirements, software architecture, scaling Agile methods, best practices for preventing and responding to DDoS attacks, and a special report documenting the technical history of the SEI.
These publications highlight the latest work of SEI technologists in these areas. This post includes a listing of each publication, author(s), and links where they can be accessed on the SEI website.
Federal agencies and other organizations face an overwhelming security landscape. The arsenal available to these organizations for securing software includes static analysis tools, which search code for flaws, including those that could lead to software vulnerabilities. The sheer effort required by auditors and coders to triage the large number of potential code flaws typically identified by static analysis can hijack a software project's budget and schedule. Auditors need a tool to classify alerts and to prioritize some of them for manual analysis. As described in my first post in this series, I am leading a team on a research project in the SEI's CERT Division to use classification models to help analysts and coders prioritize which vulnerabilities to address. In this second post, I will detail our collaboration with three U.S. Department of Defense (DoD) organizations to field test our approach. Two of these organizations each conduct static analysis of approximately 100 million lines of code (MLOC) annually.
By Will Klieber
CERT Secure Coding Team
This blog post is co-authored by Will Snavely.
Finding violations of secure coding guidelines in source code is daunting, but fixing them is an even greater challenge. We are creating automated tools for source code transformation. Experience in examining software bugs reveals that many security-relevant bugs follow common patterns (which can be automatically detected) and that there are corresponding patterns for repair (which can be performed by automatic program transformation). For example, integer overflow in calculations related to array bounds or indices is almost always a bug. While static analysis tools can help, they typically produce an enormous number of warnings. Once an issue has been identified, teams are only able to eliminate a small percentage of the vulnerabilities identified. As a result, code bases often contain an unknown number of security bug vulnerabilities. This blog post describes our research in automated code repair, which can eliminate security vulnerabilities much faster than the existing manual process and at a much lower cost. While this research focuses to the C programming language, it applies to other languages as well.
Many system and software developers and testers, especially those who have primarily worked in business information systems, assume that systems--even buggy systems--behave in a deterministic manner. In other words, they assume that a system or software application will always behave in exactly the same way when given identical inputs under identical conditions. This assumption, however, is not always true. While this assumption is most often false when dealing with cyber-physical systems, new and even older technologies have brought various sources of non-determinism, and this has significant ramifications on testing. This blog post, the first in a series, explores the challenges of testing in a non-deterministic world.