Sholom Cohen

Analysis of Unintentional Insider Threats Deriving from Social Engineering Exploits

Organizations often suffer harm from individuals who bear no malice against them but whose actions unintentionally expose the organizations to risk-the unintentional insider threat (UIT). In this paper we examine UIT cases that derive from social engineering exploits. We report on our efforts to collect and analyze data from UIT social engineering incidents to identify possible behavioral and technical patterns and to inform future research and development of UIT mitigation strategies.

Reuse: where to begin and why

The Software Engineering Institute (SEI) is interested in identifying the costs and benefits of software reuse to the mission critical computer resource (MCCR) community. In fulfilling this role, we were faced with the need to investigate reuse without making a large investment. This paper examines where to start a reuse activity by describing our initial view of reuse, our decisions on where to begin, what lessons we learned, and finally, our current view. The reuse life cycle described in our final view gives more insight on how and where to implement reuse. It defines the phases of a reuse life cycle that begin with business planning and shows their relationships. For each phase of the reuse life cycle, we give the goals, the outputs, and an approach for achieving the goals. Each organization that is interested in obtaining the benefits of reuse must evaluate reuse in terms of business goals and objectives. Once this evaluation has been made, the life cycle described in the paper provides one approach to achieving the benefits of reuse.

Unintentional Insider Threat: Contributing Factors, Observables, and Mitigation Strategies

Organizations often suffer harm from individuals who bear them no malice but whose actions unintentionally expose the organizations to risk in some way. This paper examines initial findings from research on such cases, referred to as unintentional insider threat (UIT). The goal of this paper is to inform government and industry stakeholders about the problem and its possible causes and mitigation strategies. As an initial approach to addressing the problem, we developed an operational definition for UIT, reviewed research relevant to possible causes and contributing factors, and provided examples of UIT cases and their frequencies across several categories. We conclude the paper by discussing initial recommendations on mitigation strategies and countermeasures.

Models for domains and architectures - A prescription for systematic software reuse

1 Abstract: This paper presents a tutorial on Model-Based Software Engineering (MBSE) as a systematic approach for software reuse. The use of models in MBSE differs from reuse approaches based on libraries which do not define how the components are structured, how they interoperate, and how they are combined to deliver a given functionality. MBSE offers an approach for systematic reuse by defining the required capabilities of a class of applications, or domains. It supports a trade-off decision process for design and implementation similar to that practiced in other engineering disciplines. Software modeling under MBSE is a key factor in successful reuse and is demonstrated in several case studies presented in this paper. The paper concludes by discussing the products necessary for successful transition of the MBSE technology.1

A Feature-Driven Requirements Engineering Approach for Software Product Lines

The importance of Requirements Engineering within software development has long been established and recognized by researchers and practitioners. Within Software Product Lines (SPL), this activity is even more critical because it needs to cope with common, variable, and product-specific requirements not only for a single product but for the whole set of products in the family. In this paper, we present a Feature-Driven Requirements Engineering approach (FeDRE) that provides support to the requirements specification of software product lines. The approach follows a strategy where features are realized into functional requirements considering the variability captured in a feature model. It also provides guidelines on how to associate chunks of features from a feature model and to consider them as the context for the Use Case specification. The feasibility of the approach is illustrated in a case study for developing an SPL of mobile applications for emergency notifications. Preliminary evaluations on the perceived ease of use and perceived usefulness of requirements analysts using the approach are also presented.

Process and products for software reuse in Ada

The large scale application of reuse to support software development is not a new concept. Over twenty years ago, M. D. McIlroy expressed the need for: “… standard catalogues of routines, classified by precision, robustness, time-space performance, size limits, and binding time of parameters.” [McIlroy 68] He also provided insight that is still valid into: “… the kinds of variability necessary in software components, ways of producing useful inventories, types of components that are ripe for such standardization, and methods of instituting pilot production.” McIlroy emphasized the importance of abstraction of common principles in developing these routines, the need for automatic generators, and uniformity of engineering. He also enumerated the degree of parameterization needed for successful reusable software:Choice of precision Choice of robustness, trading off reliability and time-space performance Choice of time-space behavior Choice of algorithm Choice of interfaces with standards for types of error conditions Choice of storage accessing method Choice of data structures within a given algorithm or within different related algorithms In the utility and tool area, these concerns have been met with stable, understandable and supported reusable software subsystems to support applications development. Examples of this software are collections of abstract data structures, data base management systems, development environments, and network managers. Requirements for new applications that depend on reuse of such general subsystems software are specified in light of the existence of that software. The development can achieve significant productivity gains when the software subsystems are reused. Except in reusing these subsystems, reusable software practice has not had the same level of success in specific application areas, with few exceptions. For domains such as command and control, communications, avionics, and shipboard systems, reusable software must address specific application requirements particular to the given domain. The development of a reusable air traffic control architecture by Thomson-CSF is an example of reuse that addresses the requirements of a specific application. [Andribet 90] The details of the architectures and components developed by Thomson-CSF remain within the company, and may have limited applicability for other organizations that develop similar systems but use alternate design strategies. The Common Ada Missile Packages (CAMP) project has also produced reusable software components, primarily for missile operational software, but this software has seen only limited application. [McNicholl 88]

An early look at defining variability requirements for system of systems platforms

In the commercial domain, platform-based approaches, in which a set of functions or services are bundled to form the basis of many products, have enabled efficient development of systems and their composition into systems of systems. A successful platform must balance sufficient commonality to support economical reuse, while also providing variability and extensibility to enable innovation in system and system of systems (SoS) capabilities. These commonality/variability tradeoffs for SoS platforms are frequently tacit decisions, since there are no accepted techniques for analyzing such decisions at the scale and degree of requirements uncertainty that characterize most SoSs. The objective of our work is to develop a method for analyzing decisions about requirements for common platforms for SoSs. The method begins with the requirements tasks of identifying and selecting appropriate variabilities (variation points, variation ranges, and variation decision binding times) to support immediate SoS needs, and also enable innovation and controlled evolution. We are currently conducting a workshop and interviews with SoS experts to define the essential technical problems in SoS common platform development and identify solution constraints. We will then define a simplified SoS with limited capability requirements to use as a model problem. We will use the model problem to assess the fit of existing scope, commonality, and variability methods from software product lines to the SoS context, and extend existing economic models using real options and probabilistic models to model uncertainty in evolution requirements. While it is too early to draw firm conclusions about the effectiveness of our approach, it is based on proven technologies from the mature field of software product lines and so we have confidence that we can build successful SoS techniques from this foundation.

Defining and validating a feature-driven requirements engineering approach

The specification of requirements is a key activity for achieving the goals of any software project and it has long been established and recognized by researchers and practitioners. Within Software Product Lines (SPL), this activity is even more critical owing to the need to deal with common, variable, and product-specific requirements, not only for a single product but for the whole set of products. In this paper, we present a Feature-Driven Requirements Engineering approach (FeDRE) that provides support to the requirements specification of SPL. The approach realizes features into functional requirements by considering the variability captured in a feature model. It also provides detailed guidelines on how to associate chunks of features from a feature model and to consider them as the context for the Use Case specification. The evaluation of the approach is illustrated in a case study for developing an SPL of mobile applications for emergency notifications. This case study was applied within 14 subjects, 8 subjects from Universitat Politecnica de Valencia and 6 subjects from Federal University of Bahia. Evaluations concerning the perceived ease of use, perceived usefulness, effectiveness and efficiency as regards requirements analysts using the approach are also presented. The results show that FeDRE was perceived as easy to learn and useful by the participants.

The Advanced Multiplex Test System (AMTS): A Product Line Approach for Army Aviation Maintenance

[Abstract] This paper discusses how the Communications-Electronics Life Cycle Management Command Software Engineering Center is addressing aircraft availability and readiness for the successful completion of battlefield missions. The approach includes the adoption of software product line engineering practices for the development of new software for the U.S. Army’s diagnostic products for avionics systems. The practices are used to facilitate production of avionics maintenance software products from a common architecture, using an asset base of common components and system-specific plug-ins. Development through this product line approach improves avionics field maintenance practices and performance, reduces sustainment costs, and increases aircraft readiness.

SCArVeS: services, clouds, and alternative design strategies for variant-rich software systems

Summary of Scarves workshop