Risk inherent in any military, government, or industry network system cannot be completely eliminated, but it can be reduced by implementing certain network controls. These controls include administrative, management, technical, or legal methods. Decisions about what controls to implement often rely on computed-risk models that mathematically calculate the amount of risk inherent in a given network configuration. These computed-risk models, however, may not calculate risk levels that human decision makers actually perceive.
I recently joined the Carnegie Mellon Software Engineering Institute (SEI) as deputy director and chief technology officer (CTO). My goal in this new role is to help the SEI advance computer science, software engineering, cybersecurity, and related disciplines to help ensure that the acquisition, development, and operation of software-dependent systems have lower cost, higher quality, and better security. I have spent the past two decades conducting a range of research and development activities, and I have served on various Department of Defense (DoD) advisory boards. In this blog posting, I'd like to talk a little bit about my background and outline the priorities I'm pursuing at the SEI. In subsequent blog postings, I'll describe the SEI technical strategy in more detail.
Warfighters in a tactical environment face many constraints on computational resources, such as the computing power, memory, bandwidth, and battery power. They often have to make rapid decisions in hostile environments. Many warfighters can access situational awareness data feeds on their smartphones to make critical decisions. To access these feeds, however, warfighters must contend with an overwhelming amount of information from multiple, fragmented data sources that cannot be easily combined on a small smartphone screen. The same resource constraints apply to emergency responders involved in search-and-rescue missions, who often must coordinate their efforts with multiple responders. This posting describes our efforts to create the Edge Mission-Oriented Tactical App Generator (eMontage), a software prototype that allows warfighters and first responders to rapidly integrate geotagged situational awareness data from multiple remote data sources.
Aircraft and other safety-critical systems increasingly rely on software to provide their functionality. The exponential growth of software in safety-critical systems has pushed the cost for building aircraft to the limit of affordability. Given this increase, the current practice of build-then-test is no longer feasible. This blog posting describes recent work at the SEI to improve the quality of software-reliant systems through an approach known as the Reliability Validation and Improvement Framework that will lead to early defect discovery and incremental end-to-end validation.
The ubiquity of mobile devices provides new opportunities to warn people of emergencies and imminent threats using location-aware technologies. The Wireless Emergency Alerts (WEA) system, formerly known as the Commercial Mobile Alert Service (CMAS), is the newest addition to the Federal Emergency Management Agency (FEMA) Integrated Public Alert and Warning System (IPAWS), which allows authorities to broadcast emergency alerts to cell phone customers with WEA-enabled devices in an area affected by a disaster or a major emergency. This blog posting describes how the Software Engineering Institute's (SEI) work on architecture, integration, network security, and project management is assisting in implementing the WEA system, so it can handle a large number of alert originators and provide an effective nationwide wireless emergency warning system.
Building a complex weapon system in today's environment may involve many subsystems--propulsion, hydraulics, power, controls, radar, structures, navigation, computers, and communications. Design of these systems requires the expertise of engineers in particular disciplines, including mechanical engineering, electrical engineering, software engineering, metallurgical engineering, and many others. But some activities of system development are interdisciplinary, including requirements development, trade studies, and architecture design, to name a few. These tasks do not fit neatly into the traditional engineering disciplines, and require the attention of engineering staff with broader skills and backgrounds. This need for breadth and experience is often met by systems engineers. Unfortunately, system engineering is often not valued among all stakeholders in the Department of Defense (DoD), and is often the first group of activities to be eliminated when a program is faced with budget constraints. This blog post highlights recent research aimed at demonstrating the value of systems engineering to program managers in the DoD and elsewhere.
Occasionally this blog will highlight different posts from the SEI blogosphere. Today's post by Will Dormann, a senior member of the technical staff in the SEI's CERT Program, is from the CERT/CC (Coordination Center) blog. This post explores Dormann's investigation into the state of signed Java applet security.
In the first blog entry of this two part series on common testing problems, I addressed the fact that testing is less effective, less efficient, and more expensive than it should be. This second posting of a two-part series highlights results of an analysis that documents problems that commonly occur during testing. Specifically, this series of posts identifies and describes 77 testing problems organized into 14 categories; lists potential symptoms by which each can be recognized; potential negative consequences, and potential causes; and makes recommendations for preventing them or mitigating their effects.
According to DevSecOps: Early, Everywhere, at Scale, a survey published by Sonatype, "Mature DevOps organizations are able to perform automated security analysis on each phase (design, develop, test) more often than non-DevOps organizations." Since DevOps enables strong collaboration and automation of the process and enforces traceability, mature DevOps organizations are more likely to perform automated security analysis than non DevOps organizations. My previous blog post, Microcosm: A Secure DevOps Pipeline as Code, helped address the problem that most organizations do not have a complete deployment pipeline in place (and are therefore not considered to be DevOps mature) by automating penetration tests of software applications and generating HTML reports as part of the build process through the Jenkins CI service. In this follow-up blog post, I explore the use of a service evolution of Microcosm as a simple one-stop shop for anyone interested in learning how to implement a DevSecOps pipeline.