SEI Insights

SEI Blog

The Latest Research in Software Engineering and Cybersecurity

By Donald Firesmith
Principal Engineer
Software Solutions Division

Due to advances in hardware and software technologies, Department of Defense (DoD) systems today are highly capable and complex. However, they also face increasing scale, computation, and security challenges. Compounding these challenges, DoD systems were historically designed using stove-piped architectures that lock the Government into a small number of system integrators, each devising proprietary point solutions that are expensive to develop and sustain over the lifecycle. Although these stove-piped solutions have been problematic (and unsustainable) for years, the budget cuts occurring under sequestration are motivating the DoD to reinvigorate its focus on identifying alternative means to drive down costs, create more affordable acquisition choices, and improve acquisition program performance. A promising approach to meet these goals is Open Systems Architecture (OSA), which combines

This blog posting expands on earlier coverage of how acquisition professionals and system integrators can apply OSA practices to effectively decompose large monolithic business and technical architectures into manageable and modular solutions that can integrate innovation more rapidly and lower total ownership costs.

By Douglas Gray
Information Security Engineer
CERT Division

In leveraging threat intelligence, the operational resilience practitioner need not create a competing process independent of other frameworks the organization is leveraging. In fact, the use of intelligence products in managing operational resilience is not only compatible with many existing frameworks but is, in many cases, inherent. While it is beyond the scope of this blog to provide an in-depth discussion of some of the more widely used operational resilience measurement and decision-making best practices--including the CERT® Resilience Management Model (CERT-RMM), Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Allegro methodology, the NIST Risk Management Framework (RMF), Agile, and the Project Management Body of Knowledge (PMBOK)-- this blog post, the second in a series, provides a discussion of how to operationalize intelligence products to build operational resilience of organizational assets and services.

By David Svoboda
Senior Member of the Technical Staff
CERT Division

Whether Java is more secure than C is a simple question to ask, but a hard question to answer well. When we began writing the SEI CERT Oracle Coding Standard for Java, we thought that Java would require fewer secure coding rules than the SEI CERT C Coding Standard because Java was designed with security in mind. We naively assumed that a more secure language would need fewer rules than a less secure one. However, Java has 168 coding rules compared to just 116 for C. Why? Was our (admittedly simplistic) assumption completely spurious? Or, are there problems with our C or Java rules? Or, are Java programs, on average, just as susceptible to vulnerabilities as C programs? In this post, I attempt to analyze our CERT rules for both C and Java to determine if they indeed refute the conventional wisdom that Java is more secure than C.

By Douglas Gray
Information Security Engineer
CERT Division

What differentiates cybersecurity from other domains in information technology (IT)? Cybersecurity must account for an adversary. It is the intentions, capabilities, prevailing attack patterns of these adversaries that form the basis of risk management and the development of requirements for cybersecurity programs. In this blog post, the first in a series, I present strategies for enabling resilience practitioners to organize and articulate their intelligence needs, as well as relevant organizational information, establish a collaborative relationship with their intelligence providers, organize and assess intelligence, and act upon intelligence via frameworks such as the CERT® Resilience Management Model (CERT-RMM), Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Allegro methodology, the NIST Risk Management Framework, Agile, and the Project Management Body of Knowledge (PMBOK). Subsequent postings in this blog series, we discuss how these common resilience, risk, and project-management frameworks can be leveraged to integrate threat intelligence into improving the operational resilience of organizations.

By Donald Firesmith
Principal Engineer
Software Solutions Division

There are more than 200 different types of testing, and many stakeholders in testing--including the testers themselves and test managers--are often largely unaware of them or do not know how to perform them. Similarly, test planning frequently overlooks important types of testing. The primary goal of this series of blog posts is to raise awareness of the large number of test types, to verify adequate completeness of test planning, and to better guide the testing process. In the previous blog entry in this series, I introduced a taxonomy of testing in which 15 subtypes of testing were organized around how they addressed the classic 5W+2H questions: what, when, why, who, where, how, and how well. This and future postings in this series will cover each of these seven categories of testing, thereby providing structure to roughly 200 types of testing currently used to test software-reliant systems and software applications.

This blog entry covers the four, top-level subtypes of testing that answer the following questions:

  • What-based testing: What is being tested?
    • Object-Under-Test-based (OUT) testing
    • Domain-based testing
    • When-based testing: When is the testing being performed?
      • Order-based testing
      • Lifecycle-based testing
      • Phase-based testing
      • Built-in-Test (BIT) testing

After exploring the what-based and when-based categories of testing, this post presents a section on using the taxonomy, as well as opportunities for accessing it.

By Julien Delange
Member of the Technical Staff
Software Solutions Division

For decades, safety-critical systems have become more software intensive in every domain--in avionics, aerospace, automobiles, and medicine. Software acquisition is now one of the biggest production costs for safety-critical systems. These systems are made up of several software and hardware components, executed on different components, and interconnected using various buses and protocols. For instance, cars are now equipped with more than 70 electronic control units (ECUs) interconnected with different buses and require about 100 million source lines of code (SLOC) to provide driver assistance, entertainment systems, and all necessary safety features, etc. This blog post discusses the impact of complexity in software models and presents our tool that produces complexity metrics from software models.

By Douglas C. Schmidt
Principal Researcher

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, technical notes, and white papers. These reports highlight the latest work of SEI technologists in Agile software development and Agile-at-scale, software architecture fault analysis, computer network design, confidence in system properties, and system-of-systems development as well as commentary from two CERT researchers on the Proposed BIS Wassenaar Rule. This post includes a listing of each report, author(s), and links where the published reports can be accessed on the SEI website.

By Donald Firesmith
Principal Engineer
Software Solutions Division

While evaluating the test programs of numerous defense contractors, we have often observed that they are quite incomplete. For example, they typically fail to address all the relevant types of testing that should be used to (1) uncover defects (2) provide evidence concerning the quality and maturity of the system or software under test, and (3) demonstrate the readiness of the system or software for acceptance and being placed into operation. Instead, many test programs only address a relatively small subset of the total number of potentially relevant types of testing, such as unit testing, integration testing, system testing, and acceptance testing. In some cases, the missing testing types are actually performed (to some extent) but not addressed in test-related planning documents, such as test strategies, system and software test plans (STPs), and the testing sections of systems engineering management plans (SEMPs) and software development plans (SDP). In many cases, however, they are neither mentioned nor performed. This blog, post, the first in a series on the many types of testing, examines the negative consequences of not addressing all relevant testing types and introduces a taxonomy of testing types to help testing stakeholders understand--rather than overlook--them.