A security mechanism for component based systems
Download
1 / 30

A Security Mechanism For Component-Based Systems - PowerPoint PPT Presentation


  • 259 Views
  • Updated On :

A Security Mechanism For Component-Based Systems. Mark Grechanik, Dewayne E. Perry, and Don Batory. Component-Based Systems. They are built from various components based on some existing architecture

Related searches for A Security Mechanism For Component-Based Systems

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'A Security Mechanism For Component-Based Systems' - Jims


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
A security mechanism for component based systems l.jpg

The Product-Line Architecture Research Group

Empirical Software Engineering Lab

A Security Mechanism For Component-Based Systems

Mark Grechanik, Dewayne E. Perry, and Don Batory


Component based systems l.jpg
Component-Based Systems

  • They are built from various components based on some existing architecture

  • Components and program clients may be located on different computers and interact via some component infrastructure

    • A Java program client invokes methods of some Enterprise JavaBean (EJB) interface via an EJB infrastructure

    • A C++ program invokes method of a CORBA-based component via a Mico CCM infrastructure

The University of Texas at Austin


Large scale component based systems l.jpg
Large-Scale Component-Based Systems

  • A generic representation of component-based systems is a clique

    • Circles mean components of a software system

    • Arrows mean channels by which messages that invoke interface methods are passed

We need a scalable security mechanism for large-scalecomponent-based systems!

C1

Cn

C2

C3

C4

The University of Texas at Austin


Partitioning component based systems l.jpg
Partitioning Component-Based Systems

  • Enterprises partition their computing environments based on different criteria to secure the flow of information

C1

Cn

C2

C3

C4

The University of Texas at Austin


Partitioning component based systems5 l.jpg
Partitioning Component-Based Systems

  • Enterprises partition their computing environments based on different criteria to secure the flow of information

    • Geographic locations of departments

    • Security policies regulating the flow of information between different departments

  • VPN uses a protocol called IPSec that encrypts application messages on the IP level

    • Unencrypted communications between applications within the same security partition

The University of Texas at Austin


A challenge l.jpg
A Challenge

  • A company purchases and installs two or more applications produced by competing companies within a single security partition and even on the same computer

    • These applications use the same generic components

  • It is possible for these applications to interfere with one another by means of using these generic components

  • Competing companies often demand that their applications should run in their own security partitions

    • Prevent other competing applications from eavesdropping on them to understand their interworkings

The University of Texas at Austin


What about vpn l.jpg
What About VPN?

  • Installation and configuration of a VPN is a serious technical exercise

  • Once installed it is rarely reconfigured

  • Reconfiguring VPN every time a different application is installed and run is impractical

  • When a component-based system should be partitioned within a single computer, VPNs and similar security systems cannot even be used

The University of Texas at Austin


How to secure a partitioned component based system l.jpg
How to Secure a Partitioned Component-Based System?

  • Programmers add separate security mechanisms (e.g., encryption) to existing applications

  • Invocations of methods exposed by component interfaces are encrypted and decrypted

The University of Texas at Austin


Complexity of security solutions l.jpg
Complexity of Security Solutions

  • Encrypting and decrypting communications even for small-size computing systems results in a significant performance drawback

  • A fundamental problem of applying standard security mechanisms based on encrypting algorithms to component-based systems is that the resulting secure systems are nonscalable

The University of Texas at Austin


The problem l.jpg
The Problem

  • How to adapt security partitions to business requirements without affecting the scalability and while preserving security properties of the resulting component-based system

  • Our goal is to provide a security mechanism that enables users to change partitions dictated by the business needs dynamically and securely

The University of Texas at Austin


Software fortresses l.jpg
Software Fortresses

  • Software fortresses is an approach for modeling large enterprise systems as sets of self-contained entities

  • Each entity is called a fortress

    • It makes its own decisions about the underlying platform, data storage, and security mechanisms and policies

The University of Texas at Austin


Software fortress architecture l.jpg
Software Fortress Architecture

  • Software fortress architecture is an enterprise architecture consisting of a series of

    • self-contained

    • mutually suspicious

    • marginally cooperating software fortresses

  • These fortresses interact through carefully crafted and meticulously managed treaty relationships

  • All communications that originated inside a fortress and are designated to entities located inside the same fortress are approved by default

The University of Texas at Austin


Security of software fortresses l.jpg
Security of Software Fortresses

  • The walls of a fortress are collectively called a security perimeter of the system inside a fortress

  • All communication requests come into the fortress through approved channels called drawbridges

  • Treaties are the formal agreements between fortresses that define how fortresses work together

The University of Texas at Austin


Our hypothesis l.jpg
Our Hypothesis

  • In component-based systems a large percentage of components service requests of clients within the same security perimeter

  • Based on multiple observations

    • GUI components and their clients are almost always located within the same security perimeter

    • In general, components and their clients are rarely separated by security boundaries

The University of Texas at Austin


Empirical study l.jpg
Empirical Study

  • We analyzed the source code for medium to large-scale projects that were developed in seven different companies by different groups of engineers

  • We partitioned the project by security perimeters identifying each software fortress

  • Then we calculated the percentage of the channels that do not cross any security perimeter

The University of Texas at Austin


Clustering l.jpg
Clustering

The University of Texas at Austin


Linearity l.jpg
Linearity

The University of Texas at Austin


Summary of our empirical study l.jpg
Summary of Our Empirical Study

  • The percentage of channels that are located within security perimeters is high and close to 80% on average

  • The correlation coefficient for the dependency between the number of channels and the percentage of these channels that do not cross any security perimeters is 0.75

    • It suggests a strong tendency for components to interact with larger percentage of their clients within the same security perimeters as the number of their clients grows

  • These experimental results effectively confirms our hypothesis that a large percentage of components service requests of clients within the same security perimeter

The University of Texas at Austin


Our solution l.jpg
Our Solution

  • We explore the knowledge about the locality of components within a software fortress

    • If two interacting components are located within the same security perimeter then we do not need to allocate keys and use encryption to secure their interaction

  • We explore the key pattern of interactions between components via a component infrastructure

    • We only allocate one key for each fortress to communicate with component infrastructure

    • We offer a protocol that ensures the consistency of communications between components

The University of Texas at Austin


A star topology l.jpg

F1

A Star Topology

Fm

The number of fortresses, m

is much smaller than

the number of components, n

m << n

The University of Texas at Austin


Core strategy l.jpg
Core Strategy

  • Instead of creating a key to enable secure communications between each possible pair of components, let’s utilize the star topology of the component deployment model

  • Since each component and its clients interact with the component infrastructure directly, we create a key for each fortress thereby reducing the number of keys to nf instead of nc

The University of Texas at Austin


Cassia l.jpg
CASSIA

  • Component Adaptive Scalable Secure Infrastructure Architecture (CASSIA) is a comprehensive scalable security solution for large-scale component-based applications

  • Basic idea: if two communicating components are located within the same security perimeter, then no encryption and decryption of communications are necessary

The University of Texas at Austin


Cassia algorithm and configuration l.jpg
CASSIA Algorithm and Configuration

<fortress name=”A”>

<component ID=”1”/>

<component ID=”2”/>

</fortress>

<fortress name=”B”>

<component ID=”3”/>

</fortress>

<treaty>

<fortress name=”A”/>

<fortress name=”B”/>

<protocol>OpenSSL<protocol/>

</treaty>

CASSIA( Ci, Cj, boolean encrypt )

Begin

Fi = Fortress( Ci );

Fj = Fortress( Cj );

if( Fi != Fj ) then

Tij = Treaty( Fi, Fj );

Pij = Protocol( Tij );

if( encrypt == true ) then

encrypt( Ci, Cj, Pij );

else

decrypt( Ci, Cj, Pij );

endif

endif

End

The University of Texas at Austin


Implementation l.jpg
Implementation

  • We implemented the CASSIA adaptive algorithm for Mico CORBA Component Model (CCM)

    • MICO recursively expands to MICO Is CORBA

    • MICO has been branded as CORBA compliant

  • OpenSSL is used as a low-level cryptographic protocol

  • We maintain a configuration table within Mico CCM in an XML format

  • Keys are located in a protected storage and maintained using our protocol

The University of Texas at Austin


Case study l.jpg
Case Study

  • We implemented the Pet Store application for MicoCCM based on the Java Pet Store demo that is a sample application developed by the Java BluePrints program at Java Software, Sun Microsystems

  • We produced five implementations of the Pet Store application

    • Its first implementation consisted of twelve components

    • We increase the number of interfaces in each subsequent implementation approximately twice

  • We tested each implementation four times with different number of channels crossing security boundaries

The University of Texas at Austin


Throughput of cassia l.jpg
Throughput of CASSIA

The University of Texas at Austin


Average time per transaction l.jpg
Average Time Per Transaction

The University of Texas at Austin


Slide28 l.jpg

Speedups With CASSIA

The University of Texas at Austin


Slide29 l.jpg

Overhead of CASSIA

The University of Texas at Austin


Conclusions l.jpg
Conclusions

  • We conducted an empirical study where we found that 80% of interactions between components and their clients occur within the same protected security boundaries

  • We successfully implemented CASSIA, a novel scalable security mechanism for component-based systems

  • We conducted CASSIA’s performance evaluation case study that confirms its scalability and showed its very small overhead

  • We proposed and implemented a Secure COmponent Protocol (SCOP) that incorporates our scalable security mechanism into a component infrastructure

The University of Texas at Austin


ad