Software Engineering Institute | Carnegie Mellon University

SEI Insights

SEI Blog

The Latest Research in Software Engineering and Cybersecurity

My prior blog post on product lines in DoD sustainment described the complexity of contractual relationships in a DoD software product line. Recall that a software product line is a collection of related products with shared software artifacts and engineering services that has been developed by a single organization in support of multiple programs serving multiple missions and different customers. A product line can reduce cost of development and support. In exchange, it can be a cause of conflicting priorities between customers, much like the similar problem in joint program management. This blog post describes a set of guidelines and goals for establishing governance and monitoring the product line for long-term success.

Every January on the SEI Blog, we present the 10 most-visited posts of the previous year. This year's top 10, which features posts published between January 1, 2018, and December 31, 2018, brought an ever-increasing number of visitors to the blog.

10. Why You Should Apply Agile-DevOps Earlier in the Lifecycle
9. Best Practices and Considerations in Egress Filtering
8. Deep Learning: Going Deeper toward Meaningful Patterns in Complex Data
7. Why Does Software Cost So Much?
6. Revealing True Emotions through Micro-Expressions: A Machine Learning Approach
5. Translating Between Statistics and Machine Learning
4. Best Practices for Cloud Security
3. Security Begins at the Home Router
2. 10 Types of Application Security Testing Tools: When and How to Use Them
1. 12 Risks, Threats, and Vulnerabilities in Moving to the Cloud

This post was co-authored by Ebonie McNeil.

Static analysis tools analyze code without executing it, to identify potential flaws in source code. These tools produce a large number of alerts with high false-positive rates that an engineer must painstakingly examine to find legitimate flaws. As described in Lori's first blog post on this topic, we in the SEI's CERT Division have developed the SCALe (Source Code Analysis Laboratory) tool since 2010 as part of our research on new ways to help analysts be more efficient and effective at auditing static analysis alerts.

In a previous post, I discussed the Pharos Binary Analysis Framework and tools to support reverse engineering of binaries with a focus on malicious code analysis. Recall that Pharos is a framework created by our CERT team that builds upon the ROSE compiler infrastructure developed by Lawrence Livermore National Laboratory. ROSE provides a number of facilities for binary analysis including disassembly, control flow analysis, instruction semantics, and more. Pharos uses these features to automate common reverse engineering tasks.

Since our last post, we have developed new techniques and tools in the Pharos framework to solve a problem that may be of interest to reverse engineers and malware analysts. Specifically, this post describes how we have worked on techniques and tools to identify the specific program inputs and environments that are needed to reach an execution of interest to an analyst, which we call path finding.

Almost all software systems today face a variety of threats, and the number of threats grows as technology changes. Malware that exploits software vulnerabilities grew 151 percent in the second quarter of 2018, and cyber-crime damage costs are estimated to reach $6 trillion annually by 2021. Threats can come from outside or within organizations, and they can have devastating consequences. Attacks can disable systems entirely or lead to the leaking of sensitive information, which would diminish consumer trust in the system provider. To prevent threats from taking advantage of system flaws, administrators can use threat-modeling methods to inform defensive measures. In this blog post, I summarize 12 available threat-modeling methods.

Today, organizations build applications on top of existing platforms, frameworks, components, and tools; no one constructs software from scratch. Hence today's software development paradigm challenges developers to build trusted systems that include increasing numbers of largely untrusted components. Bad decisions are easy to make and have significant long-term consequences. For example, decisions based on outdated knowledge or documentation, or skewed to one criterion (such as performance) may lead to substantial quality problems, security risks, and technical debt over the life of the project. But there is typically a tradeoff between decision-making speed and confidence. Confidence increases with more experience, testing, analysis, and prototyping, but these all are costly and time consuming. In this blog post, I describe research that aims to increase both speed and confidence by applying existing automated-analysis techniques and tools (e.g., code and software-project repository analyses) mapping extracted information to common quality indicators from DoD projects.

Statistics and machine learning often use different terminology for similar concepts. I recently confronted this when I began reading about maximum causal entropy as part of a project on inverse reinforcement learning. Many of the terms were unfamiliar to me, but as I read closer, I realized that the concepts had close relationships with statistics concepts. This blog post presents a table of connections between terms that are standard in statistics and their related counterparts in machine learning.

Earlier this year, a team of researchers from the SEI CERT Division's Network Situational Awareness Team (CERT NetSA) released an update (3.17.0) to the System for Internet-Level Knowledge (SiLK) traffic analysis suite, which supports the efficient collection, storage, and analysis of network flow data, enabling network security analysts to query large historical traffic data sets rapidly and scalably. As this post describes, our team also recently updated the Network Traffic Analysis with SiLK handbook to make it more analyst-focused and teach not only the toolset but also the tradecraft around using it.