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