Graph algorithms are in wide use in Department of Defense (DoD) software applications, including intelligence analysis, autonomous systems, cyber intelligence and security, and logistics optimizations. In late 2013, several luminaries from the graph analytics community released a position paper calling for an open effort, now referred to as GraphBLAS, to define a standard for graph algorithms in terms of linear algebraic operations. BLAS stands for Basic Linear Algebra Subprograms and is a common library specification used in scientific computation. The authors of the position paper propose extending the National Institute of Standards and Technology's Sparse Basic Linear Algebra Subprograms (spBLAS) library to perform graph computations. The position paper served as the latest catalyst for the ongoing research by the SEI's Emerging Technology Center in the field of graph algorithms and heterogeneoushigh-performance computing (HHPC). This blog post, the second in our series, describes our efforts to create a software library of graph algorithms for heterogeneous architectures that will be released via open source.
As software continues to grow in size and complexity, software programmers continue to make mistakes during development. These mistakes can result in defects in software products and can cause severe damage when the software goes into production. Through the Personal Software Process (PSP), the Carnegie Mellon University Software Engineering Institute has long advocated incorporating discipline and quantitative measurement into the software engineer's initial development work to detect and eliminate defects before the product is delivered to users. This blog post presents an approach for incorporating formal methods with PSP, in particular, Verified Design by Contract, to reduce the number of defects earlier in the software development lifecycle while preserving or improving productivity.
"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.
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.
The CERT Division of the SEI has a history of helping organizations develop, improve, and assess their incident management functions. Frequently we discover that an organization's primary focus is on security incident response, rather than the broader effort of security incident management. Incident response is just one step in the incident management lifecycle. In this blog post, we look at five recurring issues we regularly encounter in organizations' Incident Management programs, along with recommended solutions. By discovering and resolving these issues, organizations can attain a better cybersecurity posture.