Arguing satisfaction of security requirements

This chapter presents a process for security requirements elicitation and analysis, based around the construction of a satisfaction argument for the security of a system. The process starts with the enumeration of security goals based on assets in the system, then uses these goals to derive security requirements in the form of constraints. Next, a satisfaction argument for the system is constructed, using a problem-centered representation, a formal proof to analyze properties that can be demonstrated, and structured informal argumentation of the assumptions exposed during construction of the argument. Constructing the satisfaction argument can expose missing and inconsistent assumptions about system context and behavior that effect security, and a completed argument provides assurances that a system can respect its security requirements

Contextualizing Secure Information System Design: A Socio-Technical Approach

Secure Information Systems (SIS) design paradigms have evolved in generations to adapt to IS security needs. However, modern IS are still vulnerable and are far from secure. The development of an underlying IS cannot be reduced to “technological fixes” neither is the design of SIS. Technical security cannot ensure IS security. Generations of SIS design paradigms have evolved, all with their own sets of shortcomings. A SIS design paradigm must meet well-defined requirements, yet contemporary paradigms do not meet all these requirements. Current SIS design paradigms are not easily applicable to IS. They lack a comprehensive modeling support and ignore the socio-technical organizational role of IS security. This research introduced the use of action research in design science research. Design science paradigm was leveraged to introduce a meta-design artifact explaining how IS requirements including security requirements can be incorporated in the design of SIS. The introduced artifact CSIS provided design comprehensiveness to emergent and changing requirements to IS from a socio-technical perspective. The CSIS artifact meets secure system meta-design requirements. This study presented a secure IS design principle that ensures IS security

An artifact based approach to the accounting recognition of assets, particularly intangible assets

The International Accounting Standards Board is currently reviewing its conceptual framework and, as regards assets, the epistemological focus is upon revisions to the definition of an asset. The asset recognition criteria presented in this paper break free from this narrow definitional perspective to offer an alternative view based on the recognition of artifacts and the related notion of separability

Evaluation Framework for Software Security Requirements Engineering Tools

Tarkvaraarenduses on nõuded kui süsteemi vundament, mis vastutavad ka ebaõnnestumiste eest. Valed nõuded võivad viia tarkvara eripäradeni, mis tegelikult ei vasta spetsifikatsioonidele. Sel põhjusel peetakse nõuete koostamist kõige keerulisemaks ja olulisemaks sammuks tarkvaraarenduse elutsükli kõikide protsesside jooksul. Tänapäeval, kus küberrünnakud on \n\rtavalised, mängivad turvalisuse nõuded väga olulist rolli tarkvaraarenduse protsessis. On levimas uut tüüpi tööriistad, mille kasutamist peetakse kõige efektiivsemaks meetodiks turvalisusnõuete väljatöötamisel. Lisaks võimaldavad need tööriistad lahendada turvalisusega seotud küsimusi kasutajal endal, hoides märgatavalt kokku inseneride aega. Siiski on nende tööriistade \n\rareng alles algstaadiumis ning neid ei ole tarkvarainseneride poolt massiliselt kasutusele võetud. Põhjus on väga pikas uue tarkvara õppimise ja sellega kohanemise protsessis, mis põhjustab ajakadu arendusprotsessis ning lisab projektile kulusid. Projekti jaoks konkreetse tööriista valimisel võib tutvumine ja katsetamine võtta inseneridel hulgaliselt aega. Lisaks sellele võib struktureerimata valikuprotsess viia vale tööriista kasutuselevõtmisele, mis raiskab omakorda kõigi aega ja pingutusi. Selles uurimuses kavatseme me koostada struktureeritud lähenemise, mis aitab insenere turvaliste tööriistade valimisel. Protsessile kaasaaitamiseks saavad analüütikud ja arhitektid hinnata tarkvara omadusi, mida nad enda seisukohast olulisimateks peavad. Sellest lähtuvalt saavad nad valida kindlate tööriistade vahel ning teha parima valiku. \n\rAntud uurimustöös konstrueeritud lähenemisega on võimalik säästa aega, vaeva ja kulutusi. Uurimuse koostamise käigus uurime me tarkvaraarenduse turvaprotsesse, meetodeid ja tööriistu ning püüame luua raamistikku, mis oleks inseneridele turvalisusnõuete tööriistade hindamisel abiks.In software development requirements are considered as building blocks of software system, which also are considered to be responsible in event of failure. Bad requirements can lead to software features that are not to the specifications. For that reason requirement gathering process is considered as the most sensitive and complicated process among all software engineering lifecycle processes. In current age where cyber-attacks are common security requirements also comes into place and plays a very important role in software development process. In order to elicit security requirements new type of tools are begin to form a shape called security engineering tools which help in eliciting security requirements. That considered being the most efficient way of eliciting security requirements. Moreover these tools empower users with artifacts specifically to cater security needs, which save time and efforts for engineers in return. Nevertheless these tools are still at their infantry and are lacking mass adoption by software security engineers. Reason because these tools have steep learning curve which can add-up to development time and end up pushing more cost to the project. In order to decide which tool to select for a particular project require engineers to use these tools which in return will consume tremendous amount of time. Moreover using unstructured tool selection process can also leads to wrong tool selection which will be the waste of time and efforts. In this research work we are going to construct structured approach which will help engineers in security engineering tool selection process. In order to aid this process analysts and architects will be able to rate the features they want the most in a particular security engineering tool. In return from this process they will be able to choose between security engineering tools and select the best one. Finally using approach constructed in this research work will save time, efforts, and costs. In our approach we will analyze security engineering processes, methods and tools, to construct a framework that will help aid engineers in security engineering tool evaluation process

A Model-Driven Methodology Approach for Developing a Repository of Models

International audienceTo cope with the growing complexity of embedded system design, several development approaches have been proposed. The most popular are those using models as main artifacts to be constructed and maintained. The wanted role of models is to ease, systematize and standardize the approach of the construction of software-based systems. In order to enforce reuse and to interconnect the process of models’ specification and the system development with models, we promote a model-based approach coupled with a repository of models. In this paper, we propose a Model-Driven Engineering methodological approach for the development of a repository of models and an operational architecture for development tools. In particular, we show the feasibility of our own approach by reporting some preliminary prototype providing a model-based repository of security and dependability (S&D) pattern models

A POS Tagging Approach to Capture Security Requirements within an Agile Software Development Process

Software use is an inescapable reality. Computer systems are embedded into devices from the mundane to the complex and significantly impact daily life. Increased use expands the opportunity for malicious use which threatens security and privacy. Factors such as high profile data breaches, rising cost due to security incidents, competitive advantage and pending legislation are driving software developers to integrate security into software development rather than adding security after a product has been developed. Security requirements must be elicited, modeled, analyzed, documented and validated beginning at the initial phases of the software engineering process rather than being added at later stages. However, approaches to developing security requirements have been lacking which presents barriers to security requirements integration during the requirements phase of software development. In particular, software development organizations working within short development lifecycles (often characterized as agile lifecycle) and minimal resources need a light and practical approach to security requirements engineering that can be easily integrated into existing agile processes. In this thesis, we present an approach for eliciting, analyzing, prioritizing and developing security requirements which can be integrated into existing software development lifecycles for small, agile organizations. The approach is based on identifying candidate security goals, categorizing security goals based on security principles, understanding the stakeholder goals to develop preliminary security requirements and prioritizing preliminary security requirements. The identification activity consists of part of speech (POS) tagging of requirements related artifacts for security terminology to discover candidate security goals. The categorization activity applies a general security principle to candidate goals. Elicitation activities are undertaken to gain a deeper understanding of the security goals from stakeholders. Elicited goals are prioritized using risk management techniques and security requirements are developed from validated goals. Security goals may fail the validation activity, requiring further iterations of analysis, elicitation, and prioritization activities until stakeholders are satisfied with or have eliminated the security requirement. Finally, candidate security requirements are output which can be further modeled, defined and validated using other approaches. A security requirements repository is integrated into our proposed approach for future security requirements refinement and reuse. We validate the framework through an industrial case study with a small, agile software development organization

The Effects of the Quantification of Faculty Productivity: Perspectives from the Design Science Research Community

In recent years, efforts to assess faculty research productivity have focused more on the measurable quantification of academic outcomes. For benchmarking academic performance, researchers have developed different ranking and rating lists that define so-called high-quality research. While many scholars in IS consider lists such as the Senior Scholar’s basket (SSB) to provide good guidance, others who belong to less-mainstream groups in the IS discipline could perceive these lists as constraining. Thus, we analyzed the perceived impact of the SSB on information systems (IS) academics working in design science research (DSR) and, in particular, how it has affected their research behavior. We found the DSR community felt a strong normative influence from the SSB. We conducted a content analysis of the SSB and found evidence that some of its journals have come to accept DSR more. We note the emergence of papers in the SSB that outline the role of theory in DSR and describe DSR methodologies, which indicates that the DSR community has rallied to describe what to expect from a DSR manuscript to the broader IS community and to guide the DSR community on how to organize papers for publication in the SSB

Research Perspectives: The Anatomy of a Design Principle

This essay derives a schema for specifying design principles for information technology-based artifacts in sociotechnical systems. Design principles are used to specify design knowledge in an accessible form, but there is wide variation and lack of precision across views regarding their formulation. This variation is a sign of important issues that should be addressed, including a lack of attention to human actors and levels of complexity as well as differing views on causality, on the nature of the mechanisms used to achieve goals, and on the need for justificatory knowledge. The new schema includes the well-recognized elements of design principles, including goals in a specific context and the mechanisms to achieve the goal. In addition, the schema allows: (1) consideration of the varying roles of the human actors involved and the utility of design principles, (2) attending to the complexity of IT-based artifacts through decomposition, (3) distinction of the types of causation (i.e., deterministic versus probabilistic), (4) a variety of mechanisms in achieving aims, and (5) the optional definition of justificatory knowledge underlying the design principles. We illustrate the utility of the proposed schema by applying it to examples of published research