A process framework for characterising security properties of component-based software systems

Khan, Khaled M.; Han, Jun

doi:10.1109/aswec.2004.1290489

Cited by 5 publications

(5 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…These approaches have no particular focus on component-based specification. One approach that has a particular focus on component security is the security characterisation framework proposed by Khan and Han [14] to characterise and certify the security properties of components as a basis for deriving system-level risks during the deployment phase. These methods focus on specifying security properties of systems which is orthogonal to what we do.…”

Section: Related Workmentioning

confidence: 99%

A Semantic Paradigm for Component-Based Specification Integrating a Notion of Security Risk

Brændeland

Stølen

2007

Formal Aspects in Security and Trust

View full text Add to dashboard Cite

Abstract. We propose a semantic paradigm for component-based specification supporting the documentation of security risk behaviour. By security risk, we mean behaviour that constitutes a risk with regard to ICT security aspects, such as confidentiality, integrity and availability. The purpose of this work is to investigate the nature of security risk in the setting of component-based system development. A better understanding of security risk at the level of components facilitates the prediction of risks related to introducing a new component into a system. The semantic paradigm provides a first step towards integrating security risk analysis into the system development process.

show abstract

Section: Related Workmentioning

confidence: 99%

A Semantic Paradigm for Component-Based Specification Integrating a Notion of Security Risk

Brændeland

Stølen

2007

Formal Aspects in Security and Trust

View full text Add to dashboard Cite

show abstract

“…Based on our approaches reported in [5,6], in this paper we attempt to characterise the systems-level security of the entire composite system. A systems-level security contract (SsC) is characterised on the basis of the ultimate functionalities that a composite system offers to the external world.…”

Section: Motivationmentioning

confidence: 99%

“…We call such security properties as systems-level security contracts (SsC). Several CsCs contribute to the establishment of an SsC [6].…”

Section: Security Characterisation: An Overviewmentioning

confidence: 99%

“…Software composers perceive such a federated system not as a collection of components but as a single component. The security characterisation of such a 'composite component' can also be specified with the same structure and principles defined in [5,6] for the characterisation of atomic components' security. Software composers can use such a 'composite system' as a single component with their application.…”

Section: Ssc From Software Integrators Perspectivementioning

confidence: 99%

“…Identifying the Rs and Es of the composite system can be a problem because the configuration of the composite system changes as components are assembled and disassembled with the system. In order to derive the correct required and ensured properties of the composite system, we propose the following algorithms based on our earlier work [6]. Figure 2 indicates the algorithms used to compute the SsC.…”

Section: Compositional-level (Csc) System-level (Ssc) Believe Sees(pmentioning

confidence: 99%

See 2 more Smart Citations

Deriving Systems Level Security Properties of Component Based Composite Systems

Khan

Han

2005 Australian Software Engineering Conference

Self Cite

View full text Add to dashboard Cite

MotivationIn component-based software engineering, an application system is composed of several stand-alone software components developed by third parties. These components are readily available from various distributed sources for runtime execution. However, the paramount security concerns of these 'third-party' software components and their compositions with large scale systems over the Internet have become a major challenge. In a highly fluid distributed environment, software integrators are virtually forced to compose systems with third-party components of which they have only partial or no knowledge about their underlying security properties. When components are acquired from the Internet and composed with an application system, it is unclear what type of ultimate security can be achieved with these components for the enclosing system. The entire composite system from time to time may require different types of functionality and accordingly, the composition of the security contracts between components needs to be re-characterised to match the re-configuration requirements of the system in order to support systems security evolution. In a component-based system, we need to achieve both the security compatibility between interacting components and the security objectives for the entire system. When the entire composite system is running and providing meaningful services to the users, the systems-level security properties need to be characterised.To illustrate the main focus of this paper, we consider the following systems scenario. A number of individual healthcare components provide independent services to their environments. The services include keeping patients information, providing diagnosis reports based on test data, offering specialists advice based on the diagnosis reports, quoting prices for prescribed medicines and so on. Each of these services are independent and catered by different individual stand-alone components. We can compose a complete healthcare system by integrating the individual services provided by different components. Such a composite system is considered as a collaboration of different components which provide services in a seamless and secure way. These service providing individual components deal with a whole range of sensitive issues related to patient information such as diagnostic reports, MRI/CT-Scan images, pathological test results, diagnosis reports and prescriptions. For example, a component offering pathological services may advertise its services as providing confidentiality through secure storage of test results. On behalf of its patients, another component offering general medical services (e.g., GP practices) may require such confidentiality provided at a particular level (as guaranteed by specific encryption schemes with specific key lengths). The pathol-

show abstract