ITSO

ITSO Composition Oracle Reference Architecture (ORA)

Architecture principles Covers wide range of things in tech architecture from middleware

to hardware Drawn from best practise by Oracle SMEs

Enterprise Technology Strategies (ETS) Enterprise Solution Design

ORA Management & MonitoringOracle Reference Architecture - Management and Monitoring E16583-03September 2010Section 3 has several class diagrams to illustrate composition and relationshipsFigure 4.2 and 5.3 provide excellent viewsChapter 6 shows the product overlay

Challenges Different tools for different roles

Perspectives Event mgmt Help desk Network mgmt Mgmt and monitor

Gap between bottom up technical view and holistic user supporting views

Bottom up approach promotes silo'd thinking Systems more distributed and composition based Only monitoring e2e means you can't see which component could

be source of problems & where that component might be in other solutions

Move from IT mgmt thinking to end user perspective Mitigate lost revenue from losing users Reduce support costs by reduced call centre volumes Faster problem resolution of poor performance Adapt to business needs thru identifying trends Adapt to meet customer preferences Value of resources in terms of contributing to effective

execution Increasing need to enforce regulatory compliance and corporate

policy Security Policy such as PCI & SOX Dependence on manual enforcement within IT Server config drift from what is required for compliance Make compliance enforcement proactive - alerting etc Increasing heterogeneous networks

Key capabilities of a unified solutionchapter 3need to look at a top down perspective in addition to the classic bottom up

Service management

business capability composite of services catch service level issues - so business dont see impact view at different levels - all services to specific service svc mgmt phases - cycle of

define enforce & execute monitor report

Concept:Service service can be composed on 0 or more services service may have an SLA service is either SOA Service or Application

Infrastructure relationship service supported by system system is grouping of 1 or more infrastructure

components infrastructure component can be ..

Identity Manager Application Server Cache Host Virtual Server Service Bus BPEL Process Manager Web App

infrastructure elements may also have SLAs presentation of...

trand change dashboarding alerting measure against goals

Performance management

manage performance or atleast report given a business context

drill down into the details for analysis comprehensive picture from end user experience

perspective examine the e2e process e.g. find a product and

make a purchase e2e measure allows determination of weakest link take into account remote location factors to monitor

from locations as users would

can be defined as monitoring perspective referenced by 0 or more

services a generalisation of

infrastructure component transaction network

data correlation will help determine root cause still perform infra monitoring etc Infra most critical record session stats as provide powerful insights and

performance indicators

Lifecycle management Life cycle

2 rotationsFig 3.6 lifecycle management lifecycle

Provision Install Test & approve Deploy & configure Report back test or out to deactivate Deactivate Uninstall

Patch Patch advisory Analyse & acquire Test & approve Apply Verify

Automation can enable determination of what patches and where inc risk/impact of patch

Central repository of patches and information is a foundation of the lifecycle mgmt

Configuration management

Well known challenge is ability to manage consistency and compatibility across a stack

Without mgmt can get config drift, security vulnerabilities occurring etc

Config mgmt lifecycle Discover

Common element of capability to discover infra

Harvest the configuration of each element Analyse

Understand relationship between infra and components such as JVMs

Necessary to ensure suitable patching Monitor

Realtime monitoring of configuration changes So able to understand and reconcile

differences Are changes legitimate or not Reporting on differences so whether action

needed of not Assess

Have policies to work against so Ensure security Configuration is managed QoS is ensured

Policy management life cycleFig 3.8

Attachment Deployment Assessment Report Remediation Authoring

Policy types can be represented as Infrastructure component has 0 or

more policies Policies can be ...

Business Configuration Security Management Reliable messaging

Policies can map to support industry standards such as

SOX PCI ITIL COBIT

Action Should be possible to automate actions

against alerts Ideally corrective actions not noticed by users

as are proactive Report

Unified reporting through a single platform Groupings

Aggregation of logical elements, can described as

A group made up of 0 or more groups

A group contains 1 or more components

A job executes against a component

A job is executed against a group

A job is an automated run task Jobs can very against the number of

component instances Policy management (vertical along side 1-4) Administration & management (along side 1-4)

Standards SNMP

Std defined by IETF Java

JMX JEE

JSR 77 (J2EE Management)Just.org/en/JSR/summary?id=77

Inc map pings to Common Information Model (CIM)

mapping to SNMP Management Information Base (MIB)

Deployment defined in JSR 88 (EE Application Deployment)

Uses JSR 77 WS-Policy can include QoS attributes

WS-MTOM policy optimised MIME WS-RM - reliable

ITIL - define best practiseWww.itil-official site.com

COBIT - Control Objectives for Information and related TechnologyWww.isaca.org

Emphasis regularity compliance Sarbanes Oxley - SOX PCI DSS

www.pcisecuritystandards.org build & maintain a secure network protect card holder data vulnerability mgmt program strong access control measures monitor & test networks maintain info security policy

Service Management Service Management cycle

3.1 of guide Define Enforce & Execute Monitor Report

Service definition

Can be composed of more services A service can be a SOA Service or an application Service can have none, one or more SLAs

Infrastructure components can be mapped to a service Performance Management

Manage both service & infrastructure Monitoring has business context Ability to drill into measures to detect the IT issue sources Needs to include measurement of end user experience A service has 0-many MonitoringPerspectives A perspective is made up of

Infrastructure component Lifecycle Management

As result of the previous sections it is possible influence or define policies that support monitoring etc

Use a standards based integration Extensible - allowing monitoring and mgmt to handle new

or updated components Be service aware Discoverable Manage & monitor as one Externalise management Proactive

Auto provisioning etc Compliant

Could extrapolate a high level conceptual view of User interaction Management

Separate from monitoring to support idea of 'separation of concerns'

Consolidation & centralisation Monitoring

Define, model, capture and consolidate Integration

ProductsFigure 6-1 overlays the oracle products

Oracle Enterprise Manager OEM Service Level Management Pack OEM Diagnostic Pack for Middleware OEM Diagnostic Pack for Non Middleware OEM Management Pack for Coherence BI Management Pack management pack plus for SOA Management pack for Webcentre suite Management pack for Websphere portal Management pack for web logic server VM management pack Plugins and connectors real User Experience insight (RUEI)

Webservices manager Deployment

Client tier Management tier Managed target tier

ROI of SOAPractitioner Guide - ROI of SOA through Reuse Release 3.0 E14487-3

Intro Excel spreadsheet available to aide calculation Estimate level of usage (in hours) --> hours saved x rate --> gives

reuse value Inventory of available assets --> effort to build reusable asset -->

estimate to build for single use --> estimate time to use asset Valuation should start with core services e.g. Common security

components A full model should also take into account run cost savings Emphasis on development savings Approach of estimating value of service portfolio

EstimatingEstimation values come from research such as Managing Software Reuse by Wayne C. LimSoftware reuse myths ACM SIGSOFT Software Engineering Notes

Re-usable assets Services - web, data etc Business processes Architecture models Applications Frameworks Components WSDLs Schemas

Cost of effort saved by reuse referred to as 'predicted net hours saved'

Effort to build once - effort to use existing asset = predicted net hours saved

Building inventory can be significant effort - therefore approach incrementally

Categorise assets to help incremental process ITSO classifications of assets

Services Assets exposed through service contracts Considered to have higher production costs e.g. Time

to gather generalised requirements, parameterize, broader testing needs

Greatest potential source of savings as reduced design/dev time once interface understood

Potential reduction in instances - therefore maintenance etc

OFRA SOA Foundation for more info

Black box code assets Unlike a service this is incorporated into a wider

solution e.g. Library As incorporated into wider solutions has greater

number of deployed instances (typically) Interfaces provided and defined Development effort comparable to a service BUT can

have slightly lower test costs as can be part of test cost of using code

Code not visible often obscured by obscurification tools

White box code assets Code is visible to end user - therefore can be

modified Visibility of code raises risk of customisation to each

case in which it is used Risk of customisation increases testing need in each

use Estimation framework provides space to estimate each step of

delivery lifecycle for services Lifecycle phases...

Requirements Identification & analysis Release planning Definition Design Implementation Test

Recommendation estimation adopts conservative value if estimate is in a range

Even if initial targets are low hanging fruit re-use can build up savings quickly

Building for re-use costs more than single use - overhead known as Production Investment

Costs include Documentation Packaging Extended testing

Cost weightings Service 200% Blackbox 200% White box 100-200%

Consumption factor cost to use Services 5% Back box 20% Domain specific black box 5% White box 40% (<25% code mods) White box 90% ( >25% code mods)

White box costs relate back also to the effort involved in determining whether existing functionality can be refactored and re-used

Predicted Net Hours Saved represents the dev effort saved through reuse

Prioritisation As investment planning is reflected on an annual effort - look at

reuse opportunities within a budgetting cycle to determine best return

SOA InfrastructureE14479-03Builds upon ORA SOA Foundations

BasicsAka introduction

Based on standards so can plugin from other vendors Data management

Support trace and audit of transactions between systems

Avoid data duplication of necessary replication is the responsibility of the demanding app not the middleware

Infrastructure capabilities Must provide the ability to

Deploy Publish Discover Invoke Monitor Manage

Services leverage the connectivity and recovery capabilities provided

Must be scalable, scale measures include ... Performance Response time Availability Network connections Capacity

Principles Avoid tight coupling Support best of breed approach Support all services with standards based interfaces

regardless of tech OS, implementation language, hardware not be a

constraint to consumer Best of breed Support all services with standards based interfaces Support liable messaging - JMS, WS Reliable etc

Able to measure, monitor from a single location Performance is managed through SLAs

SOA Infrastructure Conceptual viewDetailed in ORA SOA Foundation

SOA Infrastructure Capabilities Some products may overlap in capability - therefore need

reference architecture Ref architecture drives usage consistency - consistency raises

chance for reuse Getting infra well aligned to business goals will help increase

speed to market Dependent on basic infra capabilities Mediation

Message exchange patterns Transport mediation Security mediation defined as resolving the differences between two or more

systems in order to integrate seamlessly Message transformation

Definition - ability to manipulate message to and from source and destination forms

Service routing Defined as the ability to direct traffic to the right end point Content routing by body or header attributes Loose coupling means routing without awareness of end

points Usage agreements aka consumer contracts

Definition of service qualities that dictate engagement

Dynamic binding Defined as runtime connecting source and target including

determination of which producer and consumer Error handling Policy enforcement

Defined as allows standardisation through decoupled policy definition. Policies can cover

Regularity compliance Business policies Security policies SLA policies Validation rules

Governance Asset management

Manage meta data of variety of assets - É.g. Contracts, policies, and schemas

Portfolio management Overhead of lifecycle maintenance Formality & complexity of controls

Asset lifecycle management Asset version management Usage tracking

Design time - usage intent Audit of execution use

Policy management Policy deployment isolated from implementation Separation allows alternate setups of same services

Dependency analysis As service catalog grows need to understand

dependencies - u derby and impact of details like service retirement

Impact analysis can then be performed Service discovery

Management Defined as - configuration of SOA infrastructure to control

Funtime aspects of deployment SLA management

Avg processing time Processing volume No. Errors, security violations, schema validation

errors Logging and monitoring Version support

Handling different payload versions Consumers want different versions

Resource browsing Environment propagation

Monitoring Runtime service usage tracking Exception management Performance management SOA dashboard

User interactionOracle RA User Interaction r3-0-359326

Overview Goal

User centric Feature rich Intuitive Tailored to needs of each end user

Interaction capabilities needed

Rich internet apps Provides rich desktop like experience Not got the deployment & maintenance issues Combination of JavaScript & browser plugins allows

for richness Collaboration

Remember WWW history and CERN Ability to participate (from blogging to site

commenting ref'd as Web 2.0) Mobile

Different interface resolutions to traditional desktop Desktop apps Single sign-on Application access Work lists

Automated to-do lists Automated workflow Metrics e.g. Work list too long

Content access Not only content availability Ability locate relevant content

Notifications Channels for notification rss, email etc Solicited and unsolicited approaches Remove the need to check for new content

Personalisation Interface tailored to users preferences Auto tailoring by understanding demographics, role

etc Conceptual view of modern UI

Display devices Unified user interface

Rendering of presentation adapts to platform Decoupled from logic

User interface services Logic for the client provided in a client independent

manner Access and incorporations

Access management e.g. LDAP Data and backend access layers

Backend systems Complementary technologies

Enterprise 2.0 Web 2.0 in the enterprise context Change from publish to participate ideas The tech here is addressed separately

Content management Includes content life cycle Approval processes

Capture Processing Archival View content management as something integrated

into the user interfaceMore information in the content management ETS

SOA Is a solution enabler

BPM Process modelling State management Human workflow

Interactive voice response (IVR) Voice recognition Touchpad / tone interfaces

Identity management Enabler

Interaction principles Display device support Interaction adaptability Unified user experience Physical separation Secure interactions Development for disparate display devices Rapid development Access to functionality Mets data support Performance

Industry standards W3C standards

HTTP URI HTML, XHTML, CSS AJAX Java standards

JSR 227 - standard data binding & data access facilit for J2EE

JSR 245 - Java server pages 2.1 JSR 286: portlets spec 2.0 JSR 314 Java Server Faces 2.0 JSR 315 Java servlet 3.0 JSR 329 portlet 2.0 2.0 bridge for JSF 1.2 JSR 333: content repository for Java technology API

2.1 JSR 339: JAX-RS 2.0 Java API for RESTful web svc

OASIS standards WSRP 2.0 CMIS

Other standards

MIME Types Atom RSS 2.0

Reference architecture Logical view

Display devices Client tier

Controller State management Rendering Composition Data management Security container Communication services

Standard communication protocols Service tier

Service invocation Personalisation Customisation Collaboration Search Notification Tagging Process participation Social networking Syndication Page flow Portal framework Presence & location Administration multi-channel delivery Federation Analytics Connectivity

Resources Content Databases BI Applications Business services Remote providers

Development tools IDE Declarative development UI frameworks Visual development

Meta data repository Security

Access management Credentials management

Identity propergation Message security

Development view Mac pattern Modular programming Federation

Process view Simple user request Search request

Software EngineeringSoftware Engineering Release 3.0 E16772-03

Application Infrastrcture FoundationApplication Infrastructure Foundation Release 3.0E14479-03

Maturity ModelMaturity Model Release 3.0 E14485-03

Identifying and Discovering ServicesIdentifying and Discovering Services Release 3.0E14487-03

SOA based requirements managementAlso see Software Engineering in an SOA Environment

Classic requirements mgmt - covering project view Need to have foresight to ask questions that ensure gaps

are addressed Acquire NFR requirements Recognise and capture all functional needs

To be effective in requirement capture need to look at Existing app requirements Inflight project requirements Proposed projects

Iteratively work through project requirements to refine into enterprise requirements

Tradition requirements gathered Iterative refinement to enterprise class requirements Extend business function model with refined requirements Classify the requirements against the business function

model Tooling used to publish and manage approach to realisation

Challenge of SOA will have different lifecycle to projects SOA requirements must also consider the following to link

enterprise perspective enterprise perspective Create business function model Classification of requirements and models Link project requirements to enterprise requirements

Construct business function model Build out business model as needed Building full model 1st could create significant delay in

programme APQC Process Classification Framework

https://www.apqc.org/pcfhttps://www.apqc.org/pcf

Requirement decomposition Functional requirement decomposition

Can be viewed as top down approach Approach - review material taking key verbs and

associated nouns Separate what from the who, when & how Use business terminology Results look like: complete expense request; transfer

funds Application decomposition

Is a bottom up approach Examine existing functionality to determine sources

of functionality Risk of getting wrong service granularity Get caught up with integration thinking rather than

wider service values Business process decomposition

Take existing business processes and decompose Do not include technology specific tasks

Data requirement mgmt Goal understand key business entities Position entities relative to...

Semantic communities Authorities Data sources

Allow data to be classified and communicated Once identified and classified can see how data fits

into the organisation - CRUD matrix Classification applied by both business and delivery/SOA

function and xrefd Service candidate identification & discovery (SCID&D)

Provides agreed procedures and guidelines for identifying shared service candidates

Shared service candidates viewed from ... Realised in the form of a shared service Potential candidate for shared second

Outcome is list of business function can be recommended for re-use

May not map 1-1 with services - as candidate could be built from collection of smaller services

Service discovery - identify service from existing capabilities If process performed standalone insufficient info will be available

to effect good answer Connected methodology for this in Software Engineering in an SOA

Environmenthttp://www.oracle.com/technetwork/topics/entarch/oracle-pg-soa-sw-engineering-r3-0-176714.pdfhttp://www.oracle.com/technetwork/topics/entarch/oracle-pg-soa-sw-engineering-r3-0-176714.pdf

Analyse business requirements and functionality in repository

Analysis may show ... Complete service overlap - service linked to 1

or more shared services for all coverage Partial service overlap - not all reqs satisifed No service overlap

Identify service candidates Look at business entities to identify characteristics of

potential candidates Service justification

Chapter 4 Determine whether service is shared or Not Services defined/proposed using a standardised manner Have an associated lifecycle common definition Should have common attributes including

Name Have an enforced convention for naming Use SOA governance to enforce convention Naming consistency will help prevent duplication

Scope (public/enterprise/LoB) etc Classification (e.g. Presentation, business process, business

activity, data, connectivity, utility etc)See ORA SOA Foundation for more on classification and scope

Once identified - review against a balanced scorecard to determine if appropriate to build as a second

Service criteria framework Cover both pros and cons factors in eval Suggested pros (benefits) criteria

Scope Reuse Agility Compliance Enablement

This the leveraging of existing assets for delivering the service

Suggested cons (inhibited) criteria Skill set impact Project impact Technology capability QOS feasibility

Balanced score card should be viewed as an indicator rather than an absolute

Service reuse validationChapter 5See also A Framework for SOA Governance

Means to examine potential for re-use of a service Before confirming service can be re-used should have a service

consumption request Service consumption request details expected usage details such

as Expected and maximum loads expected on the service Measure of how often/much the service is expected to be

used - É.g. Invocations per hour Usage scenarios including when those scenarios might

occur ( days of week etc) It is possible a service may not offer everything needed -

therefore consider proposal for extn or new svc using the existing service

Review should consider both functional & non functional needs - will the implementation approach support all requirements eg

QOS Interface design Security policies

Is the service capacity required available? If not can then ... Capacity be expanded

Service boundary analysisChapter 6

Expect a single service definition having a single contract but may end up with multiple contracts

Consider boundaries by looking at influencing factors including ... Scope of requirements

Requirements with different scope for different consumers - consider separate boundaries

Clarification of service candidates Requirements cross service classifications - may

mean several services needed Security polices

If policy needs differ then offer services via different contracts

Message exchange patterns Variances in MEP are an indicator of boundary

differences MEPs usually have differing QOS needs Indicative of functional differences

Quality of service Differences in QOS may mean different

infrastructure requirements Service concepts Function modelling Data modelling Naming guidelines Related - further reading Service portfolio mgmt

SecurityDrawn from Oracle Rference Architecture - Security r3.1 E15630-03

Context Reduction of silo thinking as a result of SOA etc increased security

challenge Distrusted systems can increase vulnerability Tools & strategies available are diverse including:

Physical security - badges, locks, human security Network perimeter security such as firewalls, network

partitioning, prevention tools for DOS attacks Desktop security covering authentication and malware

prevention Vulnerability management - patch management and

deployment Security assurance - security development principles to

avoid errors that allow attack vectors Platform security - ensuring platforms configured securely Content management - access to content and content life

cycles Transport layer security - identity management and

encryption Application security - authentication, authorisation and

audit (AAA) Message or content level security -message encryption,

signing, data redaction Database security - access control, encryption, data masking

Federation - single sign on, making it easier to proper gate and map roles

Identity management - manage and provision users, roles, entitlements etc

Needs to be customised to meet context CIA

Confidentiality Restrict access to appropriate people

Integrity Asset data change is done by authorised people

Availability Ensure systems are available when needed

To support this you need to classify users and resources Principle of least privilege Just enough access to do their job rather than all or

nothing In addition to dealing with threats also need to deal with

legislation Application security

Consider type of application, threats open to including security capabilities

Classifying applications sensitivity will indirectly classify their data Types of considerations factored into security architecture and

classification scheme Types of application

Needs network or not legacy terminals hard wired, now using IP,

and that can be used wirelessly or via public nets

Locations of access Internal (intranet), public (Internet), partner (VPN)

Staying within physical structures offers obvious security measures

If exposed to partners then non-repudiation and auditing become important considerations

Public facing have to assume will be subject to continuous attack

Public protection via firewalls, network address translation, reverse proxies, code & env hardening etc

Web 1.0 & 2.0 Web 1 with actives or Java Web 2 greater client side capabilities.g RIA

characteristics. Use Ajax etc - more threat vectors as a result

Self contained Manage own security data, policies and

services

Mitigates fraudulent user in IDAM, password breaches in SSO

Shared identity means shared risk, but also shared benefit in terms of maintenance and benefit

Attesting regulatory compliance becomes harder when shared

Legacy, packaged & leased apps Solution may not be compatible with

preferred security architecture Can mitigate by layering security around the

system to provide a fit into the broader security approach

SOA services Access needs to be RBAC in nature Service needs to adhere to data classification

restrictions as users might have different restrictions

Monolithic vs composite/distributed Distributed solutions require more effort to

secure Monolithic solutions only need to worry

about entry points Security between distributed components

needs to be taken into account Wi services need to take into account that

services might call services and that chain doesn't break because of varying access rights

Cloud computing Risks and threats

Interruption and unavailability - DoS etc Compromised control Fraudulent transaction processing

E.g. Maliciously injected service requests False invoices etc

Unauthorised access A range of data related threats

Classifications Understand data value is to classify it Can be done by classifying solution importance to

the organisation Understanding types of users for different systems

will help understand classification importance Classification approaches

Users Network exposure Information confidentiality Application of law e.g. HIPAA

Business criticality Ownership

Who has authority over data security - person/department

Owners can drive policy Data security

Types of data Structured or unstructured Structured data will have a data model

Data states In motion/in flight At rest In memory

Threats to data Disclosure - lack of confidentiality Alteration (lack of integrity) Destruction

Data classification Not all data is equal Some data maybe in public domain Varying degrees of sensitivity Classification scheme by confidentiality

Section 1.2.3 tables 1.1 Top secret Highly confidential Proprietary Internal use only Public

Classification via integritySection 1.2.3 table 1.2

Guaranteed Verified Audited Managed As-is

Lifetime When should data end Regulatory concerns such as tax data

retention, personal data law, value to BI During lifetime data migrates from

operational to reporting environments Once no longer needed for BI maybe retained

offline for legal requirement duration Data termination processes should be defined Termination can be done through processes

such as digital shredding (encrypt with a key and destroy all record of the key)

Physical destruction as well through overwriting, and destruction

Ownership vs stewardship Owner defines life cycle of data etc Steward provides execution allowing

processes to be aligned Privacy and PII Regulatory concerns

PII PCI DSS Data loss disclosure Information integrity - e.g. SOX Data retention for considerations such as PII,

tax etc Users

User classifications Help with confidentiality and integrity Could be by org relationship e.g

Contractor Staff Partners Customers

Classify by grade/rank in the org - can be ineffective because of diversity

Better to use roles. Each job then performs a number of roles

Attacker classifications Enthusiasts

Motivated by thrill/challenge/ curiosity- goal to beat the security

Threat low but may cause damage by accident

Vandals Cause destruction to the site and/or

information Goal of notoriety- so impact Very

visible Spies

Focus on profit Access and exploitation of information Group more likely to be an insider

with knowledge of systems, networks, DBAs etc

Organised crime High risk as determined and access to

resource for major harm Probably external but will gather

intelligence Klutzes

Unintentional attackers Data loss through making mistakes

Policy considerations Principle of least privilege Separation of duties Vacation, job rotation, and transfer

New face may spot irregularities Rotation and risk of follower seeing

abuse acts as a deterrent Trust

Trust between users and systems System to system Of organisational behaviour Access control mechanisms an increase trust

in systems Use of audit reports to help further cement

trust, particularly between internal and external auditors

Authentication can help with trust of systems Watermarking for authenticity Security measures and auditing for inter

organisation Training to build security awareness Trust lost with breaches etc

Common security strategies End to end security

Information centric view In a web app context starts at the browser

and ends at the DB Data is secure at all times - inflight and at rest Cane use studs such as XML encryption,

signature and s/mime Challenge of encryption preventing routing

etc Lesser solution is point to point security

Default position when in unsecured environment

Position used as default when running over minimal security

Often behind firewalls security not applied - result in vulnerabilities

Perimeter security Defence in depth

Multiple independent and mutually reinforcing security controls

Combination of mechanisms, procedures, policies at different layers make hard to bypass

Applied to all zones not just the perimeter Complimentary strategies

Security concepts & capabilities

Identity, verification, assertion & propagation Authentication

Confirm who or what they claim to be Used to incorporate authentication into every app Strong authentication means solutions beyond user

name and password e.g Random password tokens Smart cards Multi factor authentication

Human factors such as retinal or fingerprint

Personal factors - some additional information you know

Technical factors - so there held such as smart app or swipe card

Multi factor reduces probability of fraud Multi factor authentication without additional

steps can be by tracking the device being used - so a previously approved device doesn't dem,and multifactor

SSO - single Sign On

Only need to authenticate once to sign into multiple systems

Typically work at web tier or network perimeter

Web solutions involve using a trusted party to vouch for authentication d.g. App proxy

Can occur at the cross domain and desktop contexts

SSO process 1.User attempts to access secure

resource via a proxy

Gateway intercepts request to determine if resource is protected

Challenge for credentials if needed

Credentials presented to access server for validation

Access server compares presented credentials with repository such as LDAP

If validation good gateway authorise request

Policies etc fetched from directory svc and authorisation determined

Valid authorisation allows request to be passed on with security token

Application verifies token

User receives response with token which is used with future requests

Typically SSO token put in a cookie when in web context.for this to work all web svr said need to be in same cookie domain

Kerberos

web.mit.edu/Kerberos Designed to support SSO In basic form consists of a Key Distribution

Center (KDC) made up of Authentication server (AS) Ticket granting server (TGS)

Process

User authenticates against AS

AS issues ticket to talk with TGS, ticket known as (TGT) Ticket Granting Ticket which has limited life

User talks with TGS to get ticket which will be allowed against app service

Federated SSO For cross domain need to overcome cookie

constraint

Pass token back and forth in requests or URI for example

Cross domain trust frameworks SAML 2 takes on board lessons from

Liberty Alliance Shibboleth project WS-Federation

Desktop SSO Works on desktop to handle authentication

challenges Logging into desktop initiates logging onto

required resources Helps limit the number of credentials a user

needs to remember Can help address logging into systems not

geared towards perimeter based security e.g. Legacy packages, mainframes etc

Increases need to keep desktop secure Desktop password needs to match or exceed

the min requirement of the most secure system

Identity Propagation

Similar to SSO in so far as identity may be needed across multiple systems/components

SOA as a distributed solution will need credentials sharing

J2EE identity represents identity is represented as a principal

Identity can be represented as a standardised security token, such as

SAML assertion X.509 certificate

Identity can be passed at different levels of he stack Transport - HTTP auth Message header - SOAP/WS Security In the message body Additional request parameter

Propergating a single assertion is susceptible to man in the middle attacks e.g. Token captured and then used for malicious calls. Mitigations can be:

Invalidate assertion after each request (will require to be revalidated on every request )

Keep the life of the token very short (protects against man in the middle but not replay attacks)

Require certificate for trusted service consumer as well.

Fraud Detection & Prevention Forms of fraud

Phishing Trojan horses Password theft Man in the middle attacks - mitigations can

include systems performing

Logins without repeating the typing of password or pins

Changing validation information DG asking different questions

Encrypting and signing transmissions from the clients to back end systems

Detect replays by using transaction ids and time stamps

Provide proof to the user that the website is authentic

Authorisation (access control) Types of access control

Discretionary Access Control (DAC) - access at owners discretion

Mandatory Access Control (MAC) - access control is always required, rules defined to determine right of access

Role Based Access Control (RBAC) Attribute Based access Control - e.g. Having achieved

goals can access more resources Course grained access control - operation level

controls e.g. Grant role x to perform function y Fine grained access control - when factors finer than

group or role level to determine access. E.g.cashier might only be able to process cash transactions during working hours to a limited value within the own branch

Rules San be defined using the XACML standard

XACML allows rules to be imported, exported and enforced by different systems

Such rules used to be expressed within business logic - making maintenance higher, particularly if used across multiple services

Rule based access control - similar to fine grained but control defined by rules in policies rules may refer to each other e.g. You can do something if you have permission to do both A&B or perhaps can do if you can't do A - works well for division of interests

DataField Level Access Control - Data Redaction - prevent site of attributes based on roles, rather than demand multiple services because of permissions to see different attributes e.g. Hiding SSN

Access Control Categories Preventative - control forms a barrier Detective - controls record all activities are passive

in nature won't prevent access but will allow detection e.g. Audit logging

Deterrent - mechanisms intended todos courage attack, are highly visible e.g. Warning messages of consequences of breaking security

Corrective - take effect as soon as security event has occurred so repeat events don't occur

Recovery- like corrective, take place after the event. Sim to restore systems to normal state r.g. Data restoration after deletion

Compensating - when full capabilities do not support the required policies. Compensation policies can range from technical to managerial

Access control theoretical models Bel LaPadula (BLP) model

Uses mandatory access control Objects labelled with a security classification Subjects labelled with a clearance level Subject with lower clearance can't read object

of higher level Higher level clearance can't send information

to a lower level Described as "Read Down - Write Up"

Biba Integrity model Uses object classification & subject clearance

in same way as BLP Differs to BLP as integrity is defined

information origination and dissemination Read access if the security level is lower or

equal to the object Write access if the security level is equal or

higher to the object Described as "Read Up - Write Down"

So users of lesser clearance can't overwrite higher level information

Access control matrix Privileges defined as a 2d matrix 1 dimension for subject types (users, groups

etc) Other dimension represents objects Intersection describes level - read, write,

read/write, approve etc May include fine grained access control

Brewer Nash (Chinese Wall) Designed to prevent conflicts of interest -

subjects might ordinarily have access to information from unrelated competing resources

Restrictions are dynamically setup so wall erected only info from source is accessed

RBAC in distributed contexts Definition of different aspects of access based on app and

deployment Differing times and locations for defining access can cause

access problems - therefore hand off to 3rd party Confidentiality

Relates to the ability to protect data from being seen by unapproved entities whilst inflight or at rest

Sensitive data in a fully locked down environment Encryption

Symmetric and asymmetric cryptography Symmetric key (secret key) Asymmetric key (public key)

Transport and message layer encryption

Encryption can be applied at multiple levels of the stack

Transport Layer Security (TLS) replacing SSL (Secure Socket Layer) addressed TCP level includes

HTTP FTP

Telnet Uses public key cryptography to secure

sessions Persistence encryption

Integrity and authenticity Digital signatures

Asymmetric keys Digital digest attached to msg built with 1 way hash

of part of message Non-repudiation / KPI

Proof of origin Can utilise digital signatures and encryption to help

Public key infrastructure Means to generate, distribute, validate & revoke key

certificates Self regulated key management - pretty good privacy

(PGP) Use of a certificate authority

Integrity - data at rest or inflight have not been modified Authenticity - the source of data or change is legitimate

Auditing Audit user activities

Transaction watermarking - link transactions to a single request

Audit privileged user activities Auditing database admin activity Auditing security admins

Federation Establishing trust between domains Credential mapping

Web service security policies Policy specification Policy discovery Policy conformance Policy enforcement

Security administration and management Identity management Identity provisioning Role management Entitlements management Attestation Policy management Runtime threat detection and analysis Data security management

Common Security Standards

IP based security TLS & SSL

www.ietf.org/html.charters/tls-charter.html HTTP/HTTPS Kerberos

web.mit.edu/kerberos/ XML security

XML Signaturewww.w3.org/TR/xmldsig-core/

XML Encryptionwww.w3.org/Encryption/2001/

SAML Assertions

Authentication assertion Attribute assertion Authorisation decision assertion

Protocols Authentication request protocol Single logout protocol Assertion query and request protocol Artefact resolution protocol Name identifier management protocol Name identifier mapping protocol

Bindings HTTP Redirect binding HTTP Post binding HTTP Artifact binding SAML SOAP binding Reverse SOAP (PAOS) binding SAML URI binding

Profiles Web browser SSO profile Enhanced client and proxy (ECP) profile Identity provider discovery profile Web browser SSO profiles

XACML Rules

Architecture

PEP - policy enforcement point PDP - policy decision point PRP - policy retrieval point PIP - policy information point PAP - policy administration point

SPML Web Service Security

WS-Security WS-Trust WS-SecureConversation WS-Policy & WS-SecurityPolicy

WS-PolicyAttachment WS-SecurityPolicy

WS-I Standards Interoperability Basic security profile Reliable secure profile

Identity Governance Framework AAPML CARML

Java security standards JCA and JCE JAAS JSSE, JGSS and Java SASL

Regulatory & Governance Standards Information Technology Infrastructure Library (ITIL) Control objectives for information and related technology

(COBIT) Committee of Sponsoring Organizations (COSO) International organisation for standards and international

electrotechnical Sarbanes-Oxley Payment Card Industry Data Security Standards (PCI-DSS)

Security Conceptual View Common framework need

Many concepts not new Addressed in different ways Challenge is to do it manner that supports the business Silo'd security means inconsistency impacting

Productivity Risk of errors Close productivity

Difficulties caused and lead to disabling security or reducing it

Purpose Master data management of security data Mapping of resources and roles to have clear view of

privileges Manage access rules - ideally fine grained Ideally propagation of master data to points

enforcing security Detect data inconsistencies and flag Offer security as a service Interoperability across security domains Be a value add to existing infra security

Architecture principles Defence in depth Least privilege Security as a service Authentication as a service Authorisation as a service SSO and Identity federation across domains Secure web services Secure management of security information Active threat detection and analysis Secure and complete audit trail Data security System availability

Framework & services

Comprising of Platform containing business solutions - will support

security or incorporate own elements of security capability

Shared infrastructure providing security services, security data mgmt etc

Common platform services Authentication Authorisation Role mapping (users against roles) Credential mapping (systems and roles) Auditing Encryption

Use of local interfaces Need for performance (avoid remote calling etc)

Overcome through pushing security data to local store or cache

Challenge of ensuring data secure locally Framework supports local platform by including ...

Master version of security information Services to act on security data Management and admin capabilities

Security information layer Users and identity Credentials Attributes (such as work location to perform

attribute or rule based authentication) Groups (model hierarchical structures) Roles Entitlements (aka authorisation rules) - what

privileges to what resources in what conditions Authentication rules Federated identities WSS Policies - storage of policies for WS-Security Audit logs - not only end systems but audit of

changes in security data Certificates and keys - management of keys etc,

particularly if own CA Security services - common security capabilities and

services offered Not the same as SOA services Limited value in service description and

discoverability unlike SOA May involve propriety protocols and interfaces Where possible use industry standard protocols etc Authentication Single sign-on Federation Authorisation Self service - allow end users to manage their

information rather than need to be done by admin WSS Policy - enforce policies on service requests Audit - collection of data from various sources and

ability to report on the data PII -managed access to PII data Key management - ability to register and resolve

keys. Management PKI at org or domain level Credential mapping - supplying other services with

suitable credential information Information virtualisation - PII data maybe held

across several physical servers,info virtualisation pulls together for a single view

Fraud detection - monitoring of services Encryption

Identity management & administration Delegated administration - partition administration

for different roles and responsibilities Identity management Role management Authentication and policy management Access policy management WSS Policy management Key and certificate management Provisioning processing - tasks such as creating

users, group management etc Approvals - management the approvals of changes -

closely linked to provisioning Attestation & reporting - ability to demonstrate

security configuration to address regulatory control Risk analysis- processing of logs etc to determine

risks OS Security & integration - keeping OS etc sync'd Information dissemination & sync - ensure changes

in security data is distributed and in sync across systems

Change detection and alerts Changing auditing Dynamic assignments - security access changes

based on circumstances Computing platform should insulate business logic from

security platform

Logical View

Interaction A is perimeter authentication Interaction B identity federation Interaction C application client authentication Dashed lines reflect behind scenes security flows