Audit-based Compliance Control (AC2) for EHR Systems

Traditionally, medical data is stored and processed using paper-based files. Recently, medical facilities have started to store, access and exchange medical data in digital form. The drivers for this change are mainly demands for cost reduction, and higher quality of health care. The main concerns when dealing with medical data are availability and confidentiality. Unavailability (even temporary) of medical data is expensive. Physicians may not be able to diagnose patients correctly, or they may have to repeat exams, adding to the overall costs of health care. In extreme cases availability of medical data can even be a matter of life or death. On the other hand, confidentiality of medical data is also important. Legislation requires medical facilities to observe the privacy of the patients, and states that patients have a final say on whether or not their medical data can be processed or not. Moreover, if physicians, or their EHR systems, are not trusted by the patients, for instance because of frequent privacy breaches, then patients may refuse to submit (correct) information, complicating the work of the physicians greatly. \ud \ud In traditional data protection systems, confidentiality and availability are conflicting requirements. The more data protection methods are applied to shield data from outsiders the more likely it becomes that authorized persons will not get access to the data in time. Consider for example, a password verification service that is temporarily not available, an access pass that someone forgot to bring, and so on. In this report we discuss a novel approach to data protection, Audit-based Compliance Control (AC2), and we argue that it is particularly suited for application in EHR systems. In AC2, a-priori access control is minimized to the mere authentication of users and objects, and their basic authorizations. More complex security procedures, such as checking user compliance to policies, are performed a-posteriori by using a formal and automated auditing mechanism. To support our claim we discuss legislation concerning the processing of health records, and we formalize a scenario involving medical personnel and a basic EHR system to show how AC2 can be used in practice. \ud \ud This report is based on previous work (Dekker & Etalle 2006) where we assessed the applicability of a-posteriori access control in a health care scenario. A more technically detailed article about AC2 recently appeared in the IJIS journal, where we focussed however on collaborative work environments (Cederquist, Corin, Dekker, Etalle, & Hartog, 2007). In this report we first provide background and related work before explaining the principal components of the AC2 framework. Moreover we model a detailed EHR case study to show its operation in practice. We conclude by discussing how this framework meets current trends in healthcare and by highlighting the main advantages and drawbacks of using an a-posteriori access control mechanism as opposed to more traditional access control mechanisms

Modeling Support for Role-Based Delegation in Process-Aware Information Systems

In the paper, an integrated approach for the modeling and enforcement of delegation policies in process-aware information systems is presented. In particular, a delegation extension for process-related role-based access control (RBAC) models is specified. The extension is generic in the sense that it can be used to extend process-aware information systems or process modeling languages with support for processrelated RBAC delegationmodels.Moreover, the detection of delegation-related conflicts is discussed and a set of pre-defined resolution strategies for each potential conflict is provided. Thereby, the design-time and runtime consistency of corresponding RBAC delegation models can be ensured. Based on a formal metamodel, UML2 modeling support for the delegation of roles, tasks, and duties is provided. A corresponding case study evaluates the practical applicability of the approach with real-world business processes. Moreover, the approach is implemented as an extension to the BusinessActivity library and runtime engine

A Literature Survey of the Development Processes for Secure Software

Turvalise tarkvara arendusprotsessidel on tähtis roll turvalise tarkvara kavandamisel, aga erinevate arendusprotsessidel vahel on rakse valikut teha ilma nendevahelie võrdluseta. Veel enam peale arendusprotsessi rakendamist tuleb valida meetodid, mida kasutada selle arendusprotsessi rakendamisel. Meetodite valikul tekib aga probleem, sest arendusprotsessides ei ole öeldud, milliseid meetodeid tuleks kasutada, et täita vajalikud tegevused turvalise tarkvara arendamiseks. Selle töö raames me võrdleme kolme erinevat turvalise tarkvara arendusprotsessi: Microsoft Security Development Lifecycle, OWASP CLASP ja Cigital’s Security Touchpoints. Järgmisena me keskendume valitud arendusprotsesside faasile, mis käsitleb turvariskide haldust ja viime läbi uuringu, et teada saada, mis on tänapäevased turvariski meetodid. Me anname nendest meetoditest lühikokkuvõtte ja võrdleme neid omavahel, mis loodetavasti lihtustab nende vahel valimist. Me koostame veel leitud meetoditest ühise vaate, mis aitab kaasa kõigi arendusprotsesside poolt pakutud tegevuste täitmisele selle faasis. See on vajalik, sest riskihaldus mängib suurt rolli turvalise tarkvara arendamisel ja erinevate riskihaldus meetodite kombineerimist saab kasutada, et avastada rohkem riske loodavast tarkvarast ja hiljem neid riske korrektselt leevendada.Secure software development processes are critical part of designing secure software. However, it is hard for the various stakeholders to make the decision about which software development process to choose without a comparison between them. Even further, after choosing the process, stakeholders have to decide which methods and techniques to use to fulfil activities required to develop secure software development processes. This is a problem, because there are a number of methods a stakeholder could use to fulfil these activities, but no explicit links between a method and development process. In this thesis firstly we perform comparison of three secure system development approaches namely Microsoft Security Development Lifecycle, OWASP CLASP and Cigital’s Security Touchpoints. In the next step we focus on step within these approaches, namely the security risk management and carry out an analytical survey to find out current methods for security risk management. We give a short overview and comparison between found methods, which potentially will help stakeholders to select their approach for designing secure software with the focus on security risk analysis. We also provide them with opportunity to perform all activities required in risk analysis phase of the development by giving them an aggregate view of risk management methods. This is essential, because risk analysis is a major part of developing secure software and combining different techniques can be used to discover and mitigate more risks in software under development

Modeling Security Risks at the System Design Stage Alignment of Mal Activity Diagrams and SecureUML to the ISSRM Domain Model

Turvatehnika disain on üks olulisi süsteemiarenduse komponente. Ta peaks läbima tervet süsteemiarendusprotsessi. Kahjuks pööratakse talle paljudel juhtudel tähelepanu ainult süsteemi arendamise ja haldamise ajal. Paljud turvalise modelleerimise keeled (näiteks Misuse Case, Secure Tropos) aitavad turvariskejuba nõuete analüüsi etapil hallata. Käesolevas magistritöös vaatleme modelleerimisvahendeid (pahateoskeemid ja SecureUML), mida kasutatakse süsteemi disainil. Täpsemalt, me uurime, kuivõrd need vahendid toetavad infosüsteemide turvariskide haldust (Information Systems Security Risks Management, ISSRM). Töö tulemuseks on tabel, mis seab pahateoskeemid ning SecureUML-keele konstruktsioonid ISSRM domeeni mõistetega omavahel vastavusse. Me põhjendame oma analüüsi ning valideerime saadud tulemusi mitmel illustratiivsel näitel. Me loodame, et saadud tulemused aitavad arendajatel paremini aru saada, kuidas turvariske süsteemi disainietapil arvesse võtta. Peale selle, nende keelte analüüs ühisel kontseptuaalsel taustal annab tulevikus võimaluse neid keeli korraga kasutada ning loodud mudeleid ühest keelest teise teisendada.Security engineering is one of the important concerns during system development. It should be addressed throughout the whole system development process; however in many cases it is often dealt only during system development and maintenance. There are several security modeling languages (e.g, Misuse case, Secure Tropos) that help dealing with security risk management at the requirements stage. In this thesis, we are focusing on the modeling languages (e.g. Mal activity diagrams and SecureUML) that are used to design the system. More specifically we investigate how these languages support information systems security risks management (ISSRM). The outcome of this work is an alignment table between the Mal activity diagrams and SecureUML language constructs to the ISSRM domain model concepts. We ground our analysis and validate the received results on the number of illustrative examples. We hope that our results will help developers to understand how they can consider security risks at the system design stage. In addition we open the way for the interoperability between different modeling languages that are analysed using the same conceptual background, thus, potentially leading to the transformation between these modeling approaches

Behavioral types in programming languages

A recent trend in programming language research is to use behav- ioral type theory to ensure various correctness properties of large- scale, communication-intensive systems. Behavioral types encompass concepts such as interfaces, communication protocols, contracts, and choreography. The successful application of behavioral types requires a solid understanding of several practical aspects, from their represen- tation in a concrete programming language, to their integration with other programming constructs such as methods and functions, to de- sign and monitoring methodologies that take behaviors into account. This survey provides an overview of the state of the art of these aspects, which we summarize as the pragmatics of behavioral types