A Novel SOA Security Model · 2015-02-25 · A Novel SOA Security Model 11 Assets Considerations:...

Workshop STV’12

A Novel SOA Security Model

Meryem Kassou and Laila Kjiri

ENSIAS , Université Mohamed V – Souissi, Rabat , Morocco

Introduction and Problem Statement

Background : SOA vs Security

SOA Security Challenges and Requirements

Defining SOA Security Cube Model

Using SOA Security model

Illustration Example

Conclusion

2A Novel SOA Security Model

Service Oriented Architecture (SOA) proposes amethodological framework to build open and flexibleInformation Systems (IS) that meet the enterprise’sdynamics

SOA implementation must overcome the challenges ofIS Security in a flexible, highly distributed and businessaligned context

Organization using SOA lack a reference tool that cansupport:◦ Identifying appropriate security requirement to implement◦ Evaluating their security posture◦ Having confidence before starting a collaboration


Approach to software development

•services provide reusablefunctionality with well-definedinterfaces;

•service infrastructure enablesdiscovery, composition andinvocation of services;

•applications are built usingfunctionality from availableservices

SO paradigm enables to :

•integrate existing application byexposing their functionality asservices,

•implement new business processmodels by utilizing existingsoftware assets,

•reduce the overall IT expenditureswhile improving the value ofexisting software assets.

SOA

SOA is an approach to bridge the gap between business models and software infrastructure and to

support changing business needs

Technical Perspective Business Perspective

From both perspectives


Service Registry

Service Consume

rService Provider

Service Description

Service

Service description

PublishFind

Bind and Invoke


Security concerns as a QoS issue need to be determined according to security concepts and to its relation with SOA

functional Layers and other cross-cutting Layers.

Layered Architecture representation supports consolidating and categorizing thevarious capabilities and building blocks that are required to implement a given SOA


Asset

Vulnerability

Threat

Control Type

Standard Control

SeverityScale

Control

Organization

ThreatOrigin

ThreatSource

Security Attribute

Owned by

Requires level

requires

Of Type Implementedby

Corresponds to

threatens

Gives rise to affects

Has source

Has origin

Exploitedby

Mitigatedby

Has severity

Vuln

erab

ility

on

Security definitions: •To protect assets and prevent unauthorized access to or modification ofinformation•To implement a suitable set of controls to ensure that the securityobjectives (confidentiality, integrity and availability) of the organization aremet


Many standards support the process of security evaluation of anorganization and identification of appropriate security controls

(ISO/IEC 27001 family of standards , Systems Security Engineering Capability Maturity Model (SSE-CMM),Common Criteria , NIST Performance Measurement guide )

These standards suffer from limitations inherent either to their generalpurpose, ambiguity or specialized nature.

an approach for tailoring and refining standard security controls to thecontext of Enterprise SOA can be helpful


The McCumber Cube methodology is astructured process that examinessecurity in the context of informationstates

It is based on decomposing the cubeinto the individual blocks that compriseit and using these blocks as thefoundation for determining theappropriate safeguards for eachinformation state

It can be used also as an evaluationtool or as a tool for definingorganizational responsibility forinformation security


Identification and Authentication: Verifying the identity of a user,process, or device, before allowing access to resources in aninformation system.

Authorization. The permission to use a computer resource,granted, directly or indirectly, by an application or system owner.

Integrity. The property that data has not been altered in anunauthorized manner while in storage, during processing, or intransit.

Confidentiality. Preserving authorized restrictions on informationaccess and disclosure, including means for protecting personalprivacy and proprietary information.

Auditing. All transactions are recorded so that problems can beanalyzed after the fact.


At the transport level: services are secured using the inbuilt security features of transport channel technologies such as HTTPS.

At the service communication protocol level: security at this level can be ensured using SOAP message based security that protects messages by encrypting and/or digitally signing the body, headers, attachments, and any combination or part thereof.

At the service description level: security properties are published in the interface description contract for other services to invoke upon.

At the service level: Service-level security includes all security mechanisms that are coupled directly with the application logic whether coded into the service component or delegated to security-specific services.

At the Business Process Level: Related work reviewed from literature focused on three points: ◦ Languages to specify business process and related security constraints ◦ techniques to generate security implementations from abstracted security requirements◦ enriching contracts description with security semantics to enable dynamic discovery binding and

negotiation of security properties.


Assets Considerations: Asset-level security refers to protecting any assets used by and encapsulated in the service like application data, devices and capabilities but also information describing the services, policy repositories, etc.

Policy considerations: Security requires a language for describing quality of service (QoS) requirements and capabilities associated with services

Service discovery considerations: ◦ The user should be able to authenticate the service discovery service. ◦ The service discovery also should be able to verify the authenticity of the user

requesting a list of services and restrict the items seen on the list according to the authorization of the user.

◦ The service discovery must only list the services that have been verified as legitimated services.

Management considerations: ◦ To build secure SOA applications, the engineering process should take the security

considerations into design, implementation, management and maintenance, etc. ◦ Other management considerations are related to the monitoring, logging and audit of

Security incidents.

Application front end’s considerations: ◦ It is unclear, how information provided to a frontend, is used in the following services

and what reaches the backend systems. ◦ This brings with it security implications that could impact services interacting with the

application.12A Novel SOA Security Model

SOA Security solutions and measures can be grouped in domains which purpose are :

◦ Message Protection: to ensure that messages traversing the network are not viewed or modified by attackers.

◦ Resource Protection: to ensure Asset-Level Security, i.e to protect any asset used by and encapsulated by the service or Infrastructure.

◦ Security properties specification: to ensure that appropriate security annotation, syntax and tools are available to specify security properties associated with services in order to facilitate discovery and negotiation.

◦ Security Management: Engineering process that should be considered when developing SOA Artifacts, administration Tools and procedures that supports the monitoring of Security.

We can notice that these SOA Security measures that we have grouped in security domains concern different security attributes (confidentiality, authentication, etc) and different SOA Layers ( service layer, process layer, etc).


This model attempts to analyze security issues and vulnerabilities of an SOA Enterprise environment from the Service, Integration, Process and Consumer Layers

This model helps in identifying and categorizing related security requirements.

Security Domain

SOA Layers

Security Attribute

Integration Layer

Security Managem

entSecurity Property

Specification

Service Layer

Resource ProtectionM

essage Protection

Process Layer

Consumer Interface Layer


Security Domain Attribute Security High Level requirement

Message Protection

Authentication Transport Level Authentication

Authorization Transport Level Authorization

Audit Transport Level Audit

Confidentiality Transport Level Confidentiality

Integrity Transport Level Integrity

Resource Protection

Authentication Service Data Access Authentication

Authorization Service Data Access Authorization

Audit Service Data Access Audit

Confidentiality Service Data encryption

Integrity Service Data Integrity

Security Properties specification All Security properties in service description

Security Management All Training, education, awareness



Message Protection

Authentication Message Level Authentication

Authorization Message Level Authorization

Audit Message Level Audit

Confidentiality Message Level Confidentiality

Integrity Message Level Integrity

Resource Protection

Authentication Service Description Access Authentication

Authorization Service Description Access Authorization

Audit Service Description Access Audit

Confidentiality Service Description Access Confidentiality

Integrity Service Description Access Integrity

Security Properties specification All Security properties in registry

Security Management AllMonitoring of Infrastructure and service Access effectiveness



Resource Protection

Authentication Service Security Policy Access Authentication

Authorization Service Security Policy Access Authorization

Audit Service Security Policy Access Audit

Confidentiality Service Security Policy Access Confidentiality

Integrity Service Security Policy Access Integrity

Message Protection

Authentication Process Information exchange Authentication

Authorization Process Information exchange Authorization

Audit Process Information exchange Audit

Confidentiality Process Information exchange Confidentiality

Integrity Process Information exchange Integrity

Security Properties specification All Define Security properties in service security Policy

Security Management AllUse of Techniques to Generate security implementations from abstracted security requirements



Resource Protection

Authentication Front end's application Access Authentication

Authorization Front end's application Access Authorization

Audit Front end's application Access Audit

Confidentiality Front end's application Access Confidentiality

Integrity Front end's application Access Integrity

Security Properties specification All Define Security properties in SLA

Security Monitoring All Monitoring of Security rules Compliance to SLA


Step 4 : Exploit Measurement PlanUse the assessment result to start enhancements by deriving

security requirement in order to achieve a desired security goal

Step 3 : Develop Measurement Plan

To assess security measures according to security metrics

Step 2 : Identify Measurement goalsSelect Security goals ( security requirements from the Cube

model) and their related metrics

Step 1 : Characterize Environment of Assessment

Use a questionnaire to evaluate SOA context and Risk Context


Context

Companies A and B want to implement a business capability to cross-sell and want to have a sign of confidence before starting

Cross-Selling requires a technical capability to have a common shareable set of data, where the data is from different systems in each enterprise.

This in turn requires the ability to transport, mediate, and share data from the disparate systems in a common “enterprise” form.

Assumptions for Step1:

Particularly among these data are: ◦ Financial Information : Payment details, Pricing Rules, etc◦ Commercial Information : nb of Articles, their description, etc

Both companies have the same Risk classification of their data: to keep financial information confidential and to protect commercial information from alteration.

For the sake of brevity, let us focus on the integration Layer and on financial data.


Step 1: SOA Context and Risk Contextto ensure Financial Data confidentiality when transporting them in SOA Infrastructure.

Step 2: Identify Measurement Goals Message Confidentiality at Message Level (for financial information)

Step 3: Develop Measurement Plan To develop metrics that support the assessment of the effectiveness of security practices related to encryption of service messages.

For instance : Metric1 : nb of message access control incidents; Metric2: % of services with weak authentication technique

Step 4: Exploit measurement plan Assurance : Business capability (cross-selling) between companies A and B can start safely Because there is confidence that appropriate security requirements are in placeEnhancements :Business capability cannot be started unless the assessed security requirement (message confidentiality at message level) is in place


Metric1 : nb of message access control incidentsImplementation evidence:1- Are messages protected from unauthorized access with appropriate access

control mechanisms? Answer : Yes or No2- Does the organization collect and review audit logs associated with unauthorized

access to messages? Answer : Yes or no3-How many incidents related to unauthorized access to messages were logged

within the reporting period? Answer : (number)Target: the measure should be as low as possible; target defined by the

organization

Metric2: % of services with weak authentication techniqueImplementation evidence:1- Are strong levels of authentication controlling access of messages from publicly

accessible networks? Answer: Yes or no2- How many services are in the inventory? Answer : ( number)3- How many services use weak authentication techniques? Answer : (number)Formula: Number of services with weak authentication techniques/Number of

services in the inventory *100Target: the measure should be low percentage defined by the organization.


Contribution :

◦ A Security Model adapted from McCumber Model that supports the process of security assessment and Security requirement definition in the context of Enterprise SOA

◦ This Model proposes high level security requirement according to : specific SOA Layers from Layered SOA architecture Security domains that are logical grouping of security mechanisms Security Attribute

Perspectives :

◦ An improvement of this research work is to provide the appraisal tool that will support the assessment process for defining security requirements.

◦ Another perspective is to provide a more detailed security requirement by adding in the Cube Model a security capability dimension that can provide guidance to a more mature security practice.


Thank you for your attention!


A Novel SOA Security Model · 2015-02-25 · A Novel SOA Security Model 11 Assets Considerations:...

Documents

Transcript of A Novel SOA Security Model · 2015-02-25 · A Novel SOA Security Model 11 Assets Considerations:...