Ayse Morali

Technical action research as a validation method in information systems design science

Current proposals for combining action research and design science start with a concrete problem in an organization, then apply an artifact to improve the problem, and finally reflect on lessons learned. The aim of these combinations is to reduce the tension between relevance and rigor. This paper proposes another way of using action research in design science, which starts with an artifact, and then tests it under conditions of practice by solving concrete problems with them. The aim of this way of using action research in design science is to bridge the gap between the idealizations made when designing the artifact and the concrete conditions of practice that occur in real-world problems. The paper analyzes the role of idealization in design science and compares it with the requirements of rigor and relevance. It then proposes a way of bridging the gap between idealization and practice by means of action research, called technical action research (TAR) in this paper. The core of TAR is that the researcher plays three roles, which must be kept logically separate, namely of artifact developer, artifact investigator, and client helper. Finally, TAR is compared to other approaches of using action research in design science, and with canonical action research.

Risk-based Confidentiality Requirements Specification for Outsourced IT Systems

Today, companies are required to be in control of their IT assets, and to provide proof of this in the form of independent IT audit reports. However, many companies have outsourced various parts of their IT systems to other companies, which potentially threatens the control they have of their IT assets. To provide proof of being in control of outsourced IT systems, the outsourcing client and outsourcing provider need a written service level agreement (SLA) that can be audited by an independent party. SLAs for availability and response time are common practice in business, but so far there is no practical method for specifying confidentiality requirements in an SLA. Specifying confidentiality requirements is hard because in contrast to availability and response time, confidentiality incidents cannot be monitored: attackers who breach confidentiality try to do this unobserved by both client and provider. In addition, providers usually do not want to reveal their own infrastructure to the client for monitoring or risk assessment. Elsewhere, we have presented an architecture-based method for confidentiality risk assessment in IT outsourcing. In this paper, we adapt this method to confidentiality requirements specification, and present a case study to evaluate this new method.

Risk and business goal based security requirement and countermeasure prioritization

Companies are under pressure to be in control of their assets but at the same time they must operate as efficiently as possible. This means that they aim to implement “good-enough security” but need to be able to justify their security investment plans. Currently companies achieve this by means of checklist-based security assessments, but these methods are a way to achieve consensus without being able to provide justifications of countermeasures in terms of business goals. But such justifications are needed to operate securely and effectively in networked businesses. In this paper, we first compare a Risk-Based Requirements Prioritization method (RiskREP) with some requirements engineering and risk assessment methods based on their requirements elicitation and prioritization properties. RiskREP extends misuse case-based requirements engineering methods with IT architecture-based risk assessment and countermeasure definition and prioritization. Then, we present how RiskREP prioritizes countermeasures by linking business goals to countermeasure specification. Prioritizing countermeasures based on business goals is especially important to provide the stakeholders with structured arguments for choosing a set of countermeasures to implement. We illustrate RiskREP and how it prioritizes the countermeasures it elicits by an application to an action case.

IT confidentiality risk assessment for an architecture-based approach

Information systems require awareness of risks and a good understanding of vulnerabilities and their exploitations. In this paper, we propose a novel approach for the systematic assessment and analysis of confidentiality risks caused by disclosure of operational and functional information. The approach is based on a model integrating information assets and the IT infrastructure that they rely on for distributed systems. IT infrastructures enable one to analyse risk propagation possibilities and calculate the impact of confidentiality incidents. Furthermore, our approach is a mean to bridge the technical and business- oriented views of information systems, since the importance of information assets, which is leading the technical decisions, is set by the business.

Extended eTVRA vs. security checklist: Experiences in a value-web

Security evaluation according to ISO 15408 (Common Criteria) is a resource and time demanding activity, as well as being costly. For this reason, only few companies take their products through a Common Criteria evaluation. To support security evaluation, the European Telecommunications Standards Institute (ETSI) has developed a threat, vulnerability, risk analysis (eTVRA) method for the Telecommunication (Telco) domain. eTVRA builds on the security risk management methodology CORAS and is structured in such a way that it provides output that can be directly fed into a Common Criteria security evaluation. In this paper, we evaluate the time and resource efficiency of parts of eTVRA and the quality of the result produced by following eTVRA compared to a more pragmatic approach (Protection Profile-based checklists). We use both approaches to identify and analyze risks of a new SIM card currently under joint development by a small hardware company and a large Telco provider.

CRAC: Confidentiality risk assessment and IT-infrastructure comparison

CRAC is an IT-infrastructure-based method for assessing and comparing confidentiality risks of distributed IT systems. The method determines confidentiality risks by taking into account the effects of the leakage of confidential information (e.g. industrial secrets), and the paths that may be followed by different attackers (e.g. insider and outsider). We evaluate its effectiveness by applying it to a real-world outsourcing case.