The Transport Layer Security (TLS) protocol aims to provide confidentiality and integrity of data. It is based on X.509 Certificates. Our previous research showed that popular Web Browsers exhibit non-standardized behaviour with respect to the certificate validation process [1]. This paper extends that work by examining their handling of OCSP Stapling. We also examine several popular HTTPS interception products, including proxies and anti-virus tools, regarding their certificate validation processes. We analyse and compare their behaviour to that described in the relative standards. Finally, we propose a system that allows the automation of certificate validation tests.

A Public Key Infrastructure (PKI) is considered one of the most important techniques used to propagate trust in authentication over the Internet. This technology is based on a trust model defined by the original X.509 (1988) standard and is composed of three entities: the certification authority (CA), the certificate holder (or subject), and the Relying Party (RP). The CA plays the role of a trusted third party between the certificate holder and the RP. In many use cases, this trust model has worked successfully. However, we argue that the application of this model on the Internet implies that web users need to depend on almost anyone in the world in order to use PKI technology. Thus, we believe that the current TLS system is not fit for purpose and must be revisited as a whole. In response, the latest draft edition of X.509 has proposed a new trust model by adding new entity called the Trust Broker (TB). In this paper, we present an implementation approach that a Trust Broker could follow in order to give RPs trust information about a CA by assessing the quality of its issued certificates. This is related to the quality of the CA’s policies and procedures and its commitment to them. Finally, we present our Trust Broker implementation that demonstrates how RPs can make informed decisions about certificate holders in the context of the global web, without requiring large processing resources themselves.

Separation of duties (SoD) is a key security requirement for many business and information systems. Role based access controls (RBAC) is a relatively new paradigm for protecting information systems. In the ANSI standard RBAC model both static and dynamic SoD are defined. However, static SoD policies assume that the system has full control over the assignment of all roles to users, whilst dynamic SoD policies assume that conflicts of interest can only arise during the simultaneous activation of a user's roles. Unfortunately neither of these assumptions hold true in dynamic virtual organisations (VOs), or in business processes that span multiple user sessions, or where users only partially disclose their roles at each session. In this paper we propose multi-session SoD (MSoD) policies for business processes which include multiple tasks enacted by multiple users over many user access control sessions. We explore the means to define MSoD policies in RBAC via multi-session mutually exclusive roles (MMER) and multi-session mutually exclusive privileges (MMEP). We propose an approach to expressing MSoD policies in XML and enforcing MSoD policies in a policy controlled RBAC infrastructure. Finally, we describe how we have implemented MSoD policies in the PERMIS privilege management infrastructure.

An effective network security requirement engineering is needed to help organizations in capturing cost-effective security solutions that protect networks against malicious attacks while meeting the business requirements. The diversity of currently available security requirement engineering methodologies leads security requirements engineers to an open question: How to choose one? We present a global evaluation methodology that we applied during the IREHDO2 project to find a requirement engineering method that could improve network security. Our evaluation methodology includes a process to determine pertinent evaluation criteria and a process to evaluate the requirement engineering methodologies. Our main contribution is to involve stakeholders (i.e., security requirements engineers) in the evaluation process by following a requirement engineering approach. We describe our experiments conducted during the project with security experts and the feedback we obtained. Although we applied it to evaluate three requirements engineering methods (KAOS, STS and SEPP) in the context of network security, our evaluation methodology can be instantiated in other contexts and other methods.