Addressing security concerns through BPM

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

http://improving-bpm-systems.blogspot.com/


• 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


• 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


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


• 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


• 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


• 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)


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


• 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


• 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


• 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


• 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


• 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


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


Time

Active availability

Creation

In-active availability

Publish

Long-term archive

Destroy

Edition 1 Edition 2 Edition 3Key:

Evolving document



A few versions case – typical for organisational documents


Document evolution during creation phase

Time

Publish

Version 1 Version 2 Version 3Key:

Evolving document


Frozen document (for long-time preservation)Document with no clearly defined destiny (preserve or destroy)

Version 4

© A. Samarin 2013

Creation in more details


Document evolution during creation phase

Time

Publish

Version 1 Version 2 Version 3Key:

Evolving document


Frozen document (for long-time preservation)

Version 4

Role B

Role A

Creation in more details – more roles

© A. Samarin 2013


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



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)

http://fr.slideshare.net/samarin/creating-a-synergy-between-bpm-and-electronic-archives



• 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)


• 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


• 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


• 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


• 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)


• 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


• 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


• 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

http://improving-bpm-systems.blogspot.com/2011/10/ea-view-on-enterprise-risk-management.html




THANKS

Addressing security concerns through BPM

Technology