Upload
alexander-samarin
View
1.127
Download
2
Embed Size (px)
DESCRIPTION
Citation preview
Addressing security concerns through BPM
Concept note
A. Samarin
Addressing security concerns through BPM v7 2
• An enterprise architect
– From a programmer to a systems architect
– Experience in scientific, international, governmental and industry environments: CERN, ISO, IOC, BUPA, Groupe Mutuel, State of Geneva, EDQM, Bund ISB, AfDB
– Have created systems which work without me
– Practical adviser for design and implementation of enterprise architectures and solutions
• My main “tool” is a blend of:
– BPM, SOA, EA, ECM, governance and strategy
• Blog http://improving-bpm-systems.blogspot.com/
• PhD in Computer Graphics and 2 published books
About me
© A. Samarin 2013
Addressing security concerns through BPM v7 3
• Some security concerns
• Briefly about intersection of BPM and security
• Processes and business objects life-cycle
• Activity “touch-points”
• Relationships between activities
© A. Samarin 2013
Agenda
Addressing security concerns through BPM v7 4
• Confidentiality, Integrity, Availability
• Modern security techniques are good at the technical and application levels not at business level yet
• WHO can DO something with WHAT at particular WHEN and WHERE?
• Need to link ACTORS, ACTIVITIES, and BUSINESS-OBJECTS (data structures and documents)
• Such a linkage must be dynamic
• Also such a linkage must be explicit and executable:
– to analyse the security in design-time
– to anticipate security in run-time
© A. Samarin 2013
Typical security concerns
Addressing security concerns through BPM v7 5
Business Process Management (BPM) is a tool for improving business performance
The theoryBPM as a discipline (use processes to manage an enterprise)
The toolsBPM as software:BPM suite (BPMS)
The practiceAny process-centric enterprise has some BPM, but how can we industrialise this BPM?
A natural evolution of BPR, Lean, ISO 9001, 6 Sigma
The aim is to have a single description of business processes:- model in design- input for project planning and execution- executable program for coordination of work- documentation for all staff members- basis for management decisions
An enterprise portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio
A multitude of tools “handle” processes
© A. Samarin 2013
Addressing security concerns through BPM v7 6
• The business is driven by events
• For each event there is a process to be executed
• Process coordinates execution of activities
• The execution is carried out in accordance with business rules
Process anatomy (1)
© A. Samarin 2013
Addressing security concerns through BPM v7 7
• Each business activity operates with some business objects
• A group of staff member (business role) is responsible for the execution of each activity
• The execution of business processes produces audit trails
• Audit trails (which are very detailed) are also used for the calculation of Key Performance Indicators (KPIs)
Process anatomy (2)
© A. Samarin 2013
Addressing security concerns through BPM v7
• Business artefacts
– Events
– Processes
– Activities
– Roles
– Rules
– Data & documents
– Audit trails
– Performance indicators
– Services
• Organisational and technical artefacts …
© A. Samarin 2013 8
Different enterprise artefacts
KPIs
Processes Services
Events
Roles Data structures
Documents
Rules
Human “workflow”
Audit trails
Addressing security concerns through BPM v7© A. Samarin 2013 9
Be ready for common (mis-)understanding about process
Addressing security concerns through BPM v7 10
• WHO (roles) is doing WHAT (business objects), WHEN (coordination of activities), WHY (business rules), HOW (business activities) and with WHICH Results (performance indicators)
• Make these relationships explicit and executable
What you model is what you execute
© A. Samarin 2013
Business processes are complex relationships between artefacts
Addressing security concerns through BPM v7 11© A. Samarin 2013
Practical Process Pattern: Double Check (DC)
Addressing security concerns through BPM v7 12© A. Samarin 2013
Practical Process Pattern: Initial Process Skeleton (IPS)
Mandatory: different actors because of the separation of duties
Potentially: different actors because of performance impact – avoid assigning mechanical (low-qualified “red”) activities and added-value (“green”) activities to the same actors
Addressing security concerns through BPM v7
• Align access rights with the work to be done
13
Build security into business processes: access control (1)
Do something
Grant necessary rights to an actor who will carry out this activity to access involved business objects
Revoke previously granted rights
© A. Samarin 2013
Addressing security concerns through BPM v7
• Align security of a business object (e.g. an organisational document) with the work progress (preparation of this document)
14
Build security into business processes: access control (2)
Personal version
Committee review
Management approval
Group drafting
Private Confidential Secret Top-secret Public
© A. Samarin 2013
Addressing security concerns through BPM v7 15
• One process instance may handle many BOs life-cycle
• One BO life-cycle may be managed by many process instances
• IT understand better BO life-cycles
• Business understand better processes
• Many variants of duration process instance vs. BO life-cycle
© A. Samarin 2013
Process and Business Object (BO) life-cycle
Time
BO3BO2BO1
BO4
Process instance 1
Addressing security concerns through BPM v7 16
• Changes (e.g. evolving to next phase in life-cycle or starting of process instance) are initiated by events
• Events can be temporal, external, internal, spontaneous
• Events can be generated from processes and life-cycles
• Enterprise-wide “event-dispatcher” is necessary; thinking about Event Processing Network (EPN), Complex Event Processing (CEP) and decision management
© A. Samarin 2013
Processes, BO life-cycles and events
Time
BO3BO2BO1
BO4
Process instance 1
Addressing security concerns through BPM v7 17
• Typical phases: Creation, Dissemination, Use, Maintenance, Disposition
• For each phase, it is necessary to know:
– initiating / terminating events
– permissions for roles
– expected duration
– master repository
– copy or cache repositories
– volume (number of objects and size in Mb) estimation
– annual growth estimation
• Documents maybe multi-versioned and compound
© A. Samarin 2013
Example: Document life-cycles
Addressing security concerns through BPM v7 18
Time
Active availability
Creation
In-active availability
Publish
Long-term archive
Destroy
Formal actions including recordsmanagement
Key:Evolving document
Mature document (no further evolution)
Frozen document (for long-time preservation)© A. Samarin 2013
One version case
Addressing security concerns through BPM v7 19
Time
Active availability
Creation
In-active availability
Publish
Long-term archive
Destroy
Edition 1 Edition 2 Edition 3Key:
Evolving document
Mature document (no further evolution)
Frozen document (for long-time preservation)© A. Samarin 2013
A few versions case – typical for organisational documents
Addressing security concerns through BPM v7 20
Document evolution during creation phase
Time
Publish
Version 1 Version 2 Version 3Key:
Evolving document
Mature document (no further evolution)
Frozen document (for long-time preservation)Document with no clearly defined destiny (preserve or destroy)
Version 4
© A. Samarin 2013
Creation in more details
Addressing security concerns through BPM v7 21
Document evolution during creation phase
Time
Publish
Version 1 Version 2 Version 3Key:
Evolving document
Mature document (no further evolution)
Frozen document (for long-time preservation)
Version 4
Role B
Role A
Creation in more details – more roles
© A. Samarin 2013
Addressing security concerns through BPM v7 22
Time
Operationalinterest
Active
Historical interest
Publish or Close
Long-term archive
Destroy
Finish of business case
Start of business case
Finish of retention 1
Finish of retention 2
Key:Evolving document
Mature document (no further evolution)
Frozen document (for long-time preservation)© A. Samarin 2013
A compound document case – typical for business documents
• (from http://fr.slideshare.net/samarin/creating-a-synergy-between-bpm-and-electronic-archives)
• Events
– New record received
– Retention period of a dossier expired (security may change)
– Access to records requested
– ...
• Business objects
– Records
– Dossiers
– Documents
– Calendars
© A. Samarin 2013 Addressing security concerns through BPM v7 23
An electronic enterprise archive as a BPM system (1)
• Rules
– Retention calendar
– Classifications
– Naming conventions
– Filing plan
– ...
• KPIs (consider service level agreements)
– Yearly acquicition transfer from current to semi-current archive < 2 weeks
© A. Samarin 2013 Addressing security concerns through BPM v7 24
An electronic enterprise archive as a BPM system (2)
Addressing security concerns through BPM v7 25
• Doing the work
– ROLES to carry the work
– ROLES to be consulted (before the work is completed)
– ROLES to be informed (after the is completed)
– To which ROLES the work can be delegated
– To which ROLES the work can be send for review
• Sourcing the work
– Other ACTIVITIES to provide the input
– Other ACTIVITIES to check the input
• Validating the work
– Other ACTIVITIES to check the output (errors and fraud prevention)
© A. Samarin 2013
“Touch-points” for an activity (1) in addition to the flow of control
Addressing security concerns through BPM v7 26
• Guiding the work
– ACTIVITIES/BOs to provide the guidance (or business rules)
• Assuring the work
– other ACTIVITIES to handle escalations and exceptions
– other ACTIVITIES to audit (1st, 2nd and 3rd party auditing)
– other ACTIVITIES to evaluate the risk (before the work is started)
– other ACTIVITIES to evaluate the risk (after the work is completed)
– other ACTIVITIES to certify (1st, 2nd and 3rd party certification or conformity assessment)
• Some ACTIVITIES can be carried out by the same actor, some ACTIVITIES must not
© A. Samarin 2013
“Touch-points” for an activity (2) in addition to the flow of control
Addressing security concerns through BPM v7 27
• Those “touch-points” forms a base for establishing relationships between activities
• Example
– “Activitiy_B” relates to Activity_A as “Validating the work”
– No actors must be assigned to both “Role_1” and “Role_2”
© A. Samarin 2013
Relationships between activities (1)
Activity_A
Activity_B
Carry out the work
Carry out the work Validating the work
Role_1
Role_2
Addressing security concerns through BPM v7 28
• It is mandatory to guarantee that all “touch-points” are covered (MECE principle)
– By other activities and roles
– By explicit decisions
• Security provisions from some standards can be formally expressed and validated
– ISO 9000
– COBIT
– SOHO
– Basel ?
– PMI
– Prince 2?© A. Samarin 2013
Relationships between activities (2)
Addressing security concerns through BPM v7 29
• In addition to usual business objects (data and documents), it is necessary to secure all BPM artefacts
– Events
– Roles
– Rules
– Services
– Process templates
– Audit trails
– KPIs
– Process instances
– Archived process instances
© A. Samarin 2013
More information to be considered
Addressing security concerns through BPM v7 30
• Each BPM artefact is implemented as a service
• Such a service is implemented with technical artefacts (database, application, server, cloud, etc.)
• Such, security for BPM artefacts can be derived from the security of technical artefacts
© A. Samarin 2013
Technical risks involved
Addressing security concerns through BPM v7 31
• BPM (via explicit and executable processed) can address some security concerns
• BPMN is the base for enriching process models (similar to as HTML is enriched by CSS)
• Security can be evaluated at design-time (proactively) and run-time (actively)
• Thus BPM can facilitate the operational risk management (see http://improving-bpm-systems.blogspot.com/2011/10/ea-view-on-enterprise-risk-management.html)
© A. Samarin 2013
Conclusions
Addressing security concerns through BPM v7 32© A. Samarin 2013
THANKS