Preventing DDoS Attacks, Scaling Agile, Insider Threat, and Software Architecture: The Latest Work from the SEI
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.
A Technical History of the SEI
By Larry Druffel
This report chronicles the technical accomplishments of the SEI and its impact on the Department of Defense (DoD) software community as well as on the broader software engineering community. The technical accomplishments of the SEI are interwoven with the technical developments in the broader software engineering community. The described technical work is organized into areas of importance to the mission of the SEI: Real-Time Embedded Systems, Education and Training, Management, Security, Software Engineering Methods, Software Architecture, and Computer Forensics.
For more information.
The Critical Role of Positive Incentives in Reducing Insider Threat
By Andrew P. Moore, Jeff Savinda, Elizabeth A. Monaco, Jamie L. Moyes, Denise M. Rousseau (Carnegie Mellon University), Samuel J. Perl, Jennifer Cowley, Matthew L. Collins, Tracy Cassidy, Nathan VanHoudnos, Palma Buttles-Valdez, Daniel Bauer, Allison Parshall
Traditional insider threat practices involve negative incentives that attempt to force employees to act in the interests of the organization and, when relied on excessively, can result in negative unintended consequences that exacerbate insider threats. Positive incentives that attempt to encourage employees to act in the interests of the organization can complement negative incentives. In our research, we identified and analyzed three avenues for aligning the interests of the employee and the organization: job engagement, perceived organizational support, and connectedness with co-workers. Based on an analysis of three insider threat incidents and an exploratory survey of organizations, we developed a model of the disgruntled insider threat problem as it relates to dissatisfaction with the employing organization and the potential benefits associated with positive incentives that improve perceived organizational support and justice. To help organizations understand their options for using positive incentives as part of their insider threat program, we outline workforce management practices to improve employees' feelings of being supported by the organization. This research is a first step toward creating a well-grounded foundation on which insider threat programs can establish a more balanced and effective means of reducing insider threats, one that is a net positive for both the employee and the organization.
Download the report.
Architecture-Led Safety Process
By Peter H. Feiler, Julien Delange, David P. Gluch, John McGregor
Architecture-Led Safety Analysis (ALSA) is a safety analysis method that uses early architecture knowledge to supplement traditional safety analysis techniques to identify faults as early as possible. The method begins by creating a definition of the operational environment within which the system under design will operate. ALSA uses the early architecture knowledge of the system and standardized error guide words to identify hazards in the system. These hazards are analyzed using knowledge of the architecture and safety requirements, intended to mitigate the hazards, that are added to the system's requirements. ALSA continues its analysis down the full depth of the system implementation hierarchy. As additional implementation details are defined, the hazard analysis is applied to the subcomponents. ALSA also cuts across many of the phases in the development lifecycle. The hazard analysis feeds the requirements definition, architecture definition, and verification and validation phases.
Download the technical report.
Best Practices for Preventing and Responding to DDoS Attacks
By Rachel Kartch
In November 2016, Internet users across the Eastern Seaboard of the United States had trouble accessing popular websites, such as Reddit, Netflix, and the New York Times. Known as the Dyn attack, the disruption was the result of multiple distributed denial of service (DDoS) attacks against a single organization: Dyn, a New Hampshire-based Internet infrastructure company. DDoS attacks can be extremely disruptive, and they are on the rise. The Verisign Distributed Denial of Service Trends Report states that DDoS attack activity increased 85 percent in each of the last two years, with 32 percent of those attacks in the fourth quarter of 2015 targeting IT services, cloud computing, and software-as-a-service companies. In this podcast, CERT researcher Rachel Kartch provides an overview of DDoS attacks and best practices for mitigating and responding to them.
View/listen to the podcast.
How to Reduce the Graveyard of Software Tools with UI/UX Capability
By Jennifer Cowley, Michael J. Szegedy
The DoD has a graveyard of software tools. Why? Software cannot always solve new socio-technical problems, yet contract software shops often repurpose old software for new problems. In some cases, the software product works, but for complex problems it often fails. Problem definition is the lynchpin of software development success. Viable software requirements--those that actually produce a tool that addresses the problem--arise from a detailed problem definition that reflects the complexity of the circumstances. If a complex problem is documented generically, the requirements are usually generic as well.
Consequently, the aperture of software solutions widens such that almost any tool could fix the problem. Generic problem definitions are often the failure point, and the users suffer the consequences. However, the process of defining problems is not well documented and is challenging to execute in operations so we offer the audience a method. Poorly suited software reduces human work efficiency, inflates error rates, disrupts the process of work within an organization, lowers user adoption rates, and ultimately leads to software obsolescence. Further, poor design exposes an array of exploitable human vulnerabilities in cyber network defense. Talented usability professionals can reverse most of these problems; however, the DoD is slow to request usability assistance. For different reasons, usability is generally an afterthought in the cybersecurity tool development process. In this webinar, we teach the audience the value of defining the problem and how this impacts the software quality outcomes.
View the webinar.
Scaling Agile Methods for Department of Defense Programs
By Will Hayes, Mary Ann Lapham, Suzanne Miller, Eileen Wrubel, Peter Capell
Most introductory discussions of Agile software development have focused on team management concepts and the implications of the Agile Manifesto for a single, small team. The focus now includes scaling these concepts for a variety of applications. The context in which Agile methods are employed drives important choices for how the work is done. Published frameworks and commercial training available in the market offer a variety of solutions for scaling Agile. This report addresses what is meant by scaling, contextual drivers for implementation choices, and the frameworks available for use today.
Read the technical note.
Update 2016: Considerations for Using Agile in DoD Acquisition
By Suzanne Miller, Dan Ward (Dan Ward Consulting), Mary Ann Lapham, Ray C. Williams, Charles (Bud) Hammons, Daniel Burton, Alfred Schenker
This report, an update to a 2010 report, Considerations For Using Agile In DoD Acquisitions, addresses developments in commercial Agile practices as well as the Department of Defense (DoD) acquisition environment. It covers some previously unanswered questions and asks some new ones. It includes new research, examples of Agile in practice, and policy updates.
Continuing with the 2010 report's theme, this report updates the exploration of these questions: Can Agile be used in the DoD environment? If so, how? It includes lessons learned from DoD programs that have employed Agile and information gleaned from myriad articles and books on Agile. While this report does not pretend to cover every paper or thought published about Agile in the DoD world, it provides an updated overview of some challenges in using Agile, an overview of how some programs have addressed these challenges, and some additional recommendations on dealing with these challenges. The intended audience is policy makers, program office staff, and software development contractors who are contemplating proposing the use of Agile methods.
We hope this report stimulates new discussion about adopting Agile in the DoD world and equips practitioners with the information they need to make informed decisions.
Read the report.
This presentation covers the problem of overlooked security requirements, how malware-analysis-driven use cases can be used to discover them, how these use cases are created, and case studies of their successful use. Also covered is information about the project currently underway to validate this approach and develop a tool.
View the presentation.
For the latest publications on SEI research, please visit http://resources.sei.cmu.edu/library/.