Abstract—Heterogeneously-licensed systems pose new challenges to architects and designers seeking to develop systems with appropriate intellectual property rights and obligations. In the extreme case, license conflicts may prevent a system’s legal use. Our previous work showed that rights, obligations, and conflicts can be calculated. But architects benefit from fuller information than simply (for example) a list of conflicts. In this work we demonstrate an approach for presenting intellectual property results in terms of arguments supporting them. The network of argumentation provides not only an explanation of each conclusion, but also a guide to the tradeoffs available in choosing among design alternatives with different licensing results. The approach has been integrated into the ArchStudio software architecture environment. We present an illustrative example of its use. I.

Policy authors typically reconcile several different mental models and goals, such as enabling collaboration, securing information, and conveying trust in colleagues. The data underlying these models, such as which roles are more trusted than others, isn’t generally used to define policy rules. As a result, policy-management environments don’t gather this information; in turn, they fail to exploit it to help users check policy decisions against their multiple perspectives. We present a model of triangulating authoring environments that capture the data underlying these different perspectives, and iteratively sanity-check policy decisions against this information while editing. We also present a tool that consumes instances of the model and automatically generates prototype authoring tools for the described domain.

THE proliferation of computers in society has meant that organizational and personal assets are increasingly

The New Zealand government has proposed an identity management system, to provide an effective and convenient alternative for citizens to access online government information and services. The proposed system is branded as “igovt”, which offers two types of authentication services. The first service provides people and businesses with logon identities. The second service provides semi-anonymised identities to government agencies. Each semi-anonymised identity carries a strictly limited amount of information about a logon identity along with an assurance that it corresponds to a living New Zealand citizen or a registered business entity. The New Zealand government has carefully designed the system with clearlyarticulated policy principles. It has also conducted several privacy impact assessments and public consultations. However, the New Zealand government has not published any security analyses for igovt, and we are not aware of any unpublished ones. In this paper, we propose a lightweight methodology for the elicitation of security requirements of a complex but incompletely unimplemented system, such as igovt. We illustrate the use of our methodology by developing preliminary security specifications for a portion of the igovt system.

Abstract. Security is a major issue in developing software systems. It is widely recognized that security aspects must be considered in all the phases of the development process from the analysis of the organizational context to the final implementation of the software system. However, current approaches for designing secure systems only target particular security aspects at specific stages of the development process. A unified process combining these different approaches is still missing. This paper surveys several existing techniques and discuss the need of a general framework for integrating them into a single development process. 1

Abstract: Traditional risk analysis approaches are based on events, probabilities and impacts. They are complex, time-consuming, and costly, and have limitations regarding the data and assessment quality: First, security events have to be identified often without much methodological guidance, making the process prone to errors and omissions. Second, concrete probability values for these events usually have to be provided, and these are not available in practice to a satisfactory degree of precision and reliability. We propose an approach for risk analysis based on business process models enhanced with security requirements and information about critical processes as well as organizational and system boundaries. This approach bypasses these limitations: security risk events can be derived from the business process models together with the security requirements, and probabilities do not have to be provided. The approach is illustrated using a business process model derived from business practice.

Abstract. The elicitation of security requirements (SRs) is a crucial issue to develop secure information systems of high quality. Although we have several methods mainly for functional requirements such as goal-oriented methods and use case modeling, most of them do not provide sufficient supports to identify threats, security objectives and security functions. Security functions are closely related to architectural design of the information system, i.e. solution space, and knowledge from the solution space is necessary to elicit appropriate SRs of higher quality. This paper proposes the usage of Common Criteria and related knowledge sources to identify SRs from functional requirements through eliciting threats and security objectives. Our proposed technique can be combined with and embedded into any existing functional requirements elicitation methods. 1

The general security goals of a computer system are known to include confidentiality, integrity and availability (C-I-A) which prevent critical assets from potential threats. The C-I-A security goals are well researched areas; however they may be insufficient to address all the needs of the summative e-assessment. In this paper, we do not discard the fundamental C-I-A security goals; rather we define security goals which are specific to summative e-assessment security. 1.

In a service-oriented architecture, business processes are executed as composition of services, which can suffer from vulnerabilities. These vulnerabilities in services and the underlying software applications put at risk computer systems in general and business processes in particular. Current vulnerability analysis approaches involve several manual tasks and, hence, are error-prone and costly. Service-oriented architectures impose additional analysis complexity as they provide much flexibility and frequent changes within orchestrated processes and services. Therefore, it is inevitable to provide tools and mechanisms that enable efficient and effective management of vulnerabilities within these complex systems. Model-based security engineering is a promising approach that can help to fill the gap between vulnerabilities on the one hand, and concrete protection mechanisms on the other. We present an approach that integrates model-based engineering and vulnerability analysis in order to cope with the security challenges of a service-oriented architecture.

Abstract—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. Keywords-Confidentiality requirements; Outsourcing, Service level agreements; Risk assessment