BPM is a tool for improving business performance by providing a single description of business processes. Addressing security concerns requires linking actors, activities, and business objects dynamically. Business processes coordinate complex relationships between different enterprise artefacts like events, roles, rules and documents. Process and business object lifecycles must be aligned, with access control and permissions changing as work progresses through the lifecycles. Events can initiate changes in lifecycles or process instances.

1. Addressing security concerns
through BPM
Concept note
A. Samarin

2. About me
• 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
© A. Samarin 2013 Addressing security concerns through BPM v7 2

3. Agenda
• 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 Addressing security concerns through BPM v7 3

4. Typical security concerns
• 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 Addressing security concerns through BPM v7 4

5. Business Process Management (BPM) is a tool
for improving business performance
A natural evolution of BPR,
A multitude of tools
Lean, ISO 9001, 6 Sigma “handle” processes
The theory The tools
BPM as a disciplinehave a single
The aim is to BPM as software:
(use processes to business
description of BPM suite (BPMS)
processes:
manage an
- model in design
enterprise)
- input for project
planning and execution An enterprise portfolio
- executable program for of the business
coordination of work processes as well as
- documentation for all the practices and tools
staff members for governing the
- basis for management design, execution and
decisions evolution of this
The practice portfolio
Any process-centric enterprise has some BPM, but
how can we industrialise this BPM?
© A. Samarin 2013 Addressing security concerns through BPM v7 5

6. Process anatomy (1)
• 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
© A. Samarin 2013 Addressing security concerns through BPM v7 6

7. Process anatomy (2)
• 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)
© A. Samarin 2013 Addressing security concerns through BPM v7 7

8. Different enterprise artefacts
• Business artefacts
– Events
Human
– Processes “workflow”
Data structures
– Activities Roles
– Roles Documents
Events
– Rules Rules
Processes
– Data & documents Services
Audit trails
– Audit trails
KPIs
– Performance indicators
– Services
• Organisational and technical artefacts …
© A. Samarin 2013 Addressing security concerns through BPM v7 8

9. Be ready for common
(mis-)understanding about process
© A. Samarin 2013 Addressing security concerns through BPM v7 9

10. Business processes are complex
relationships between artefacts
• 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 Addressing security concerns through BPM v7 10

11. Practical Process Pattern: Double Check
(DC)
© A. Samarin 2013 Addressing security concerns through BPM v7 11

12. 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
© A. Samarin 2013 Addressing security concerns through BPM v7 12

13. Build security into business processes:
access control (1)
• Align access rights with the work to be done
Do something
Grant necessary rights to Revoke
an actor who will carry previously
out this activity to access granted rights
involved business
objects
© A. Samarin 2013 Addressing security concerns through BPM v7 13

14. Build security into business processes:
access control (2)
• Align security of a business object (e.g. an organisational
document) with the work progress (preparation of this
document)
Personal Group Committee Management
version drafting review approval
Private Confidential Secret Top-secret Public
© A. Samarin 2013 Addressing security concerns through BPM v7 14

15. Process and Business Object (BO) life-
cycle
• 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
BO1 BO2 BO3
Process instance 1
BO4
Time
© A. Samarin 2013 Addressing security concerns through BPM v7 15

16. Processes, BO life-cycles and events
• 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
BO1 BO2 BO3
Process instance 1
BO4
Time
© A. Samarin 2013 Addressing security concerns through BPM v7 16

17. Example: Document life-cycles
• 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 Addressing security concerns through BPM v7 17

18. One version case
Destroy
In-active
availability
Long-term archive
Active Formal
availability actions
including
records
Publish management
Creation
Time
Key:
Evolving document
Mature document (no further evolution)
Frozen document (for long-time preservation)
© A. Samarin 2013 Addressing security concerns through BPM v7 18

19. A few versions case – typical for
organisational documents
Destroy
In-active
availability
Long-term archive
Active
availability
Publish
Creation
Time
Edition 1 Edition 2 Edition 3
Key:
Evolving document
Mature document (no further evolution)
Frozen document (for long-time preservation) through BPM v7
© A. Samarin 2013 Addressing security concerns 19

20. Creation in more details
Publish
Document
evolution
during
creation
phase
Time
Version 1 Version 2 Version 3 Version 4
Key:
Evolving document
Mature document (no further evolution)
Frozen document (for long-time preservation)
Document with no clearly Addressing destinyconcerns through destroy)
© A. Samarin 2013
defined security (preserve or BPM v7 20

21. Creation in more details – more roles
Publish
Document Role B
evolution
during
creation
phase
Role A
Time
Version 1 Version 2 Version 3 Version 4
Key:
Evolving document
Mature document (no further evolution)
Frozen document (for long-time preservation)
© A. Samarin 2013 Addressing security concerns through BPM v7 21

22. A compound document case – typical for
business documents
Destroy
Historical
interest
Long-term
archive
Operational
interest
Publish or
Close
Active Time
Start of Finish of Finish of Finish of
business case business case retention 1 retention 2
Key:
Evolving document
Mature document (no further evolution)
© A. Samarin 2013 Addressing security concerns through BPM v7 22
Frozen document (for long-time preservation)

23. An electronic enterprise archive as a
BPM system (1)
• (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

24. An electronic enterprise archive as a
BPM system (2)
• 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

25. “Touch-points” for an activity (1) in
addition to the flow of control
• 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 Addressing security concerns through BPM v7 25

26. “Touch-points” for an activity (2) 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 Addressing security concerns through BPM v7 26

27. Relationships between activities (1)
• 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”
Role_2
Role_1
Carry out the work
Activity_B
Carry out the work
Validating the
work
Activity_A
© A. Samarin 2013 Addressing security concerns through BPM v7 27

28. Relationships between activities (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 Addressing security concerns through BPM v7 28

29. More information to be considered
• 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 Addressing security concerns through BPM v7 29

30. Technical risks involved
• 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 Addressing security concerns through BPM v7 30

31. Conclusions
• 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 Addressing security concerns through BPM v7 31

32. THANKS
© A. Samarin 2013 Addressing security concerns through BPM v7 32