Various crosscutting aspects (also known as non-functional or quality characteristics) of systems are, actually, dependant on all the system elements and relationships between them. For example, the security design principle “weakest link” is saying that “in designing security for a system, focus should be put on the weakest components of the overall system” (see Goldratt E.M., Cox J. The Goal: A Process of Ongoing Improvement, Second Revised Edition, 1992).
The understanding of emergent nature of crosscutting aspects led to raising of requirements for addressing them “by-design”. The most noticeable example of “privacy by-design” is the General Data Protection Regulations (GDPR) from the European Union (see https://eur-lex.europa.eu/eli/reg/2016/679/oj ). The concept “a system characteristic by-design” may be defined as “taking into account the characteristic throughout the system entire lifecycle processes (e.g. architecting, engineering, construction, operating, etc.) as an essential emergent characteristic of the system”.
2 Security Risk Architecture Model (SRAM)
To “estimate” a relative value of a non-functional or quality characteristic of a system at any stage of the system life cycle, it is necessary to “spread” such characteristic over the system elements and relationships between them. Figure below shows, that by knowing:
the security-related paraments, i.e. threats, attacks and vulnerabilities (see oval “Security”) for each least granular system elements;
relationships between the system elements (see oval “Architecture”), i.e.
how a set of least granular elements forms a service,
how services are used in business processes,
how business processes contribute into results,
how results reflect goals,
how goals are important for the system;
adverse impact which is produced by problems with each system element;
it is possible to objectively evaluate system risks (see oval “Risk management”).
Considering that relationships between system elements are static or dynamic then the structure and behaviour of security will be covered. The same can be done for all crosscutting aspects: security, privacy, safety, reliability, resilience, performance, value, income, expenses and other emergent characteristics.
3 Enhancement practices
There are internal and external enhancement practices for each crosscutting aspect. The internal enhancements practices comprise various certifications and industry agreements which are aspect-specific and element-specific. The external enhancement practices depend on the treatment of an element as:
“white-box” with fully internal visibility and testability – some simulation, inspection and compliance external enhancement methods can be used;
“black-box” with no internal visibility and testability – use external enhancement points for data/information inputs and outputs, and external enhancement controls for leaks detection;
“grey-box” with partial internal visibility and testability – combining two previous options.
Typically, external enhancement methods are based on explicit relationships between elements (e.g. information flows). External enhancement points are based on digital archives and technologies similar to Security Information and Event Management (SIEM) tools. External enhancement controls are monitoring tools with some AI logic, for example, Data Loss Protection (DLP) tools.
For each relationship between elements, use external enhancement points for data/information flow starts and ends, and external enhancement controls for data/information transit.
The static relationships are expressed by any structural connection between elements, but dynamic relationships are expressed only by events (ECA and EPN techniques), processes (BPM techniques) and information flows (IFD techniques).
For example, a process model formally identifies all necessary enterprise enhancement points, methods and controls. (see figure below)
Add all external enhancement points.
Add all external enhancement controls for 4 activities which are “black-boxes”.
Add all external enhancement methods for 2 activities which are “white-boxes” and the process as the whole.
Add all the events and mitigation processes for some of them.
Thus, an explicit description of system elements and relationships between them provides a nomenclature of external enhancement practices, controls, points, and methods to be added to the system. Then they have to be linked to the risk management practices. All the information risk-related information sourced from various crosscutting aspects must be collected and treated together (see figure below).
Enterprise business functions should be enriched to generate the risk-related information.
Those risk-related data need to be collected at the enterprise data warehouse together with other business information.
Some business processes need to be updated to embed risk-related activities.
A set of risk-related rules, logic and risk-related knowledge should be able to use the risk-related and other business data to detect acceptable limits of risk as well as interdependencies and correlations between different risks.
Some business processes for risk mitigation maybe automatically activated.
A lot of risk-related indicators, alerts should be available in the form of dashboards and reports available for different staff members.
Staff members should be able to initiate business processes based on the observed risk-related information.
At present, there are many IT-related methodologies, technologies, tools and schools of thoughts which overlap and contradict each other. The best practices are actually the best only in particular situations. Often decisions about software-intensive solutions are taken on the in-complete and subjective base. All of this tremendously complicates the modern digital systems thus reducing their potential effectiveness and efficiency.
3 Objectives
The purpose of this course is to provide the basic knowledge and experience necessary to better understand how to deal with the increasing complexity of the information technologies to obtain the synergy between business needs and IT potentials.
4 The approach
The course is based on the practical use of Enterprise Architecture (EA) which a methodology and practice for architecting solutions. EA provides an overarching guideline for understanding a “problem space” and take necessary decision about the “solution space” to deliver which addresses the problem.
5 Learning outcomes
The trainees will
learn a systematic approach for architecting digital solutions;
learn about some modern information technologies;
learn how those technologies are working together for a systematic architecting, design, implementation, operations and evolution of digital systems;
carry out a practical architecting exercise.
6 Target audience
Bachelor and master level students specialising in IT.
7 Requested knowledge
General knowledge of IS/IT. General programming experience.
8 Layout of the teaching
Teaching will be given as six 1.5-hour lectures. The first 4 lectures will be about presenting some methodologies and technologies. Then the students will be asked to architect a solution based on a practical situation. The last session will be about presenting the student’s solution and wrapping up this mini-course.
Networking actors are humans, digital services, digital applications and systems interacting over the Internet.
Networking human actors: owner, manager, operator or customer.
Cyber-Physical System (CPS) is a system (comprises physical and computational discrete parts) that can interact with the physical world and networking actors.
Examples of CPS include autonomous automobile systems, process control systems, robotics systems, automatic pilot avionics, data acquisition and control systems for particle detectors at CERN, etc.
CPS for IoT is an CPS which makes a Thing as a System (TaaSy)which is accessible, programmable and collaborative via digital services.
Here is clarification of mentioned above characteristics of TaaSy:
Being a system, any TaaSy can carry out its essential functions without being rely on any other TaaSy(s).
Any TaaSy is a networking actor.
Any TaaSy provides some digital services for networking actors (as GUI for humans and as API for others).
Functioning of any TaaSy can be programmed (to some extent) by authorised networking actors.
TaaSy gateway: networks and connectivity adapter for various TaaSy devices which may use various networks (e.g. Bluetooth, cables, etc.). This gateway collects and homogenizes the various mechanical signals or network-based data streams into manageable data.
2 Essential views of Reference Architecture (RA)
2.1 Viable system model viewpoint
The Viable System Model (VSM) – see https://en.wikipedia.org/wiki/Viable_system_model – describes principal functions and flow of data between them for viable (i.e. autonomous) systems. A viable system is composed of five interacting subsystems which may be mapped onto aspects of organizational structure.
Viable system model
By applying the VSM for TaaSy, it is reasonable to say that Systems 4 and 5 are almost absent because they are carried out by the owner and the manufacturer of the Thing. Systems 2 is about of routine coordinating various activities and System 3 is about exceptions handling and performance management. Considering the digital nature of TaaSy, Systems 2 and 3 can be combined together as well as necessary support for System 4.
2.2 Functional domains viewpoint
TaaSy functional domains:
physical – the thing and all TaaSy devices;
device drivers to connect cyber parts with device-specific and network-specific equipment;
supporting to provide typical functionality of a digital system (e.g. logging, monitoring, etc.);
enabling to provide essential shared functionality (e.g. data handling, collaboration, process management, decision management, analytics, etc.);
purpose-specific to provide core business functionality,
IoT-specific to execute contracts between various networking actors, and
managerial to reconfigure the system; [look at COBIT, ITIL, IT4IT]
operational to maintain the proper functioning of the system. [look at ITIL, IT4IT]
Functional domains viewpoint
Standard networking (i.e. over the Internet) and commodity computing software and hardware parts are deliberately not discussed.
There are also several cross-domain functions which address typical quality requirements:
Such a platform comprises drivers, supporting and enabling functionality as well as a layer with TaaSy-specific functionality.
Solutions which are built on top of this platform are from the following functional domains: operational domain, managerial domain, purpose-specific domain and IoT-specific domain. Those solutions use patterns, tools, services available in the platform. Preferably, those solutions are assembled from microservices ( see http://improving-bpm-systems.blogspot.ch/2016/08/better-application-architecture-apparch.html ).
Application architecture viewpoint
This architecture is optimised for flexibility (quick delivery of new functionality), diversity (each TaaSy is different), uniformity (to avoid reinventing the wheel) and security (separation of functionality into units-of-deployment).
Such a platform may be deployed at the same
time in cloud-computing, local-computing and fog-computing environments. Of
course, different functions will be in different environments; on the contrary,
some software may be the same in all three environments.
Multi-environment usage of the platform
2.4 Processes (flow of control) viewpoint
Potential processes in operational and managerial domains are the following:
ITIL service design (partially)
ITIL service transition
ITIL service operations
ITIL CSI (partially)
COBIT DSS01 Manage Operations
COBIT DSS02 Manage Service Request and Incidents
COBIT DSS03 Manage Problems
COBIT DSS04 Manage Continuity
2.5 Services viewpoint
All functionality is available as digital services and microservices. All of them have APIs which are developed under the same guidelines.
3 TaaSy collaboration patterns in the IoT
The specific feature of IoT is the ability of TaaSy(s) to collaborate between them and other networking actors.
3.1 Point-to-Point (P2P)
The P2P collaboration pattern is about ad-hoc interactions between one networking actor and a particular TaaSy.
3.2 Majordomo
The majordomo collaboration pattern is about interactions between master (i.e. Majordomo TaaSy) and slaves (other networking actors but, primarily, TaaSy).
To manage the security of IoT, it is mandatory to define explicitly individual and collective behavior of Things. This is addressed in the proposed reference architecture by intensive used of processes, internally within a Thing-as-a-System and between them as digital contracts.
The recent IoT-based DDOS attack confirmed the urgent necessity for more serious and systemic integration of the IoT into our civilisation. At present, many devices from the IoT “world” act as wild animals thus being dangerous.
Each member in our civilisation has to follow many rules & regulations & laws depending on contexts and his/her roles as citizen, husband/wife, father/mother, driver, employee, etc. Those rules and laws are wrapped as, usually, time-bound contracts. Just using a taxi is a short-time contract with its rules for a passenger and a driver.
IoT as cyber-physical systems must follow some rules & regulations & laws to become a very useful member of our civilisation. The famous example of such laws is “The three laws of robotics”.
Let us apply this practice of contract-based rules & regulations & laws to the Internet of Things – let us teach Things to follow their contracts thus domesticate Things.
To behave correctly, the IoT needs following digital contracts ( see “Digital-contract-as-a-process enables business in the digital world” http://improving-bpm-systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html ). A digital contract is an explicit and machine-executable process between several business-parties, primarily, Things, Services and People.
2 External digital contracts
For example, a future household fridge will have, as minimum, five types of external contract simultaneously:
with People who are living a particular household;
with a producer of this fridge;
with a service company for maintenance of this fridge;
with some online shops to order various food, and
with some other Things within a particular household to achieve together some goals of energy consumption.
The fulfillment of some of those contracts requires the usage of the Internet. Thus, the Fridge must be able to “demonstrate” to the in-house network Router that the Fridge has rights to exchange data with some Internet-based services. Any data exchange with other internet-based services will be prohibited by the Router.
3 Internal digital contracts
In addition, being a cyber-physical system, a Thing must follow many internal contracts. Governance of all software components must be carried out as contracts for requesting a change, approval of a change, etc. Actually, all the typical IT governance and operations processes are already well-defined in COBIT, ITIL and IT4IT. They, being designed for IT departments, have to be scaled-down to the needs of Things. Even a minimalistic patch-management processes will be a huge improvement.
All the digital contracts, separate tasks, software components, messages, documents, workflows are notarized by blockchain.
Considering that, capabilities of particular Things may be rather different, some kind of a “majordomo” Service may be necessary to execute various digital contracts; Things will be participants in their workflows.
Also, in complex households some coordination between various digital contracts must be carried out (e.g. no preventative maintenance during receptions). This is a natural job for a “majordomo” Service. Obviously, it has its own digital contracts with the People who are living a particular household.
5 Conclusion
The proposed use of digital contracts, explicit governance and blockchain can make an impression that it will increase the complexity of IoT. Fortunately, this is not correct, because although more components will be necessary, the links between them become explicit.
- from “Complex” situation (in which the relationship between cause and effect can only be perceived in retrospect, but not in advance)
- to “Complicated” situation (in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge).
Of course, a lot of painful standardisation and regulatory work is necessary ahead, but, in accordance with a Russian proverb “volkov boyat'sya — v les ne khodit'”, no pain no gain.
An example of a Corporate Unified Business Execution (CUBE) platform.
This platform is architected from the several components. For each components, a set of capabilities was defined and then best-for-fit COTS products were selected.
This cloud-friendly application architecture opens the way to synergy between #BPM, #SOA, #cloud, #microservices, #IoT, #digital and #security.
2 Clarification of some terminology
2.1 Process
Many articles about microservices mentioned “process”. I believe they mean “computing process” (e.g. an instance of JVM) which should not be confused with “business process”.
O’Reilly book “Migrating to Cloud-Native Application Architectures” http://pivotal.io/platform-as-a-service/migrating-to-cloud-native-application-architectures-ebook says “The ESB becomes the owner of all routing, transformation, policy, security, and other decisions governing the interaction between services. We call this orchestration, analogous to the conductor who determines the course of the music performed by an orchestra during its performance. ESBs and orchestration make for very simple and pleasing architecture diagrams, but their simplicity is deceiving. Often hiding within the ESB is a tangled web of complexity.” I think, this is a wrong analogy. The conductor delivers only one symphony at a time. ESB delivers many symphonies at the same time. Not surprising that it such “centralised orchestration” is difficult.
In other articles, it means one of two BPMN ways to compose business processes – orchestration as a strong coordination and choreography as weak coordination. This orchestration is a domain bounded because it is carried out in the scope of a particular business process.
Microservices communicate with each other through language and platform-agnostic application programming interfaces (APIs). These APIs are typically exposed as Rest endpoints or can be invoked via lightweight messaging protocols such as RabbitMQ. They are loosely coupled with each other avoiding synchronous and blocking-calls whenever possible.”
The first of these two paragraphs says that each microservice is “independent” from other microservices and the second paragraph says “microservices communicate with each other” thus there is some dependency.
Certainly, microservices are interdependent by design and operationally-independent. It seems that microservices may refer to each other indirectly via a “naming service” (some kind of URI to URL mapper or like in CORBA). Therefore, a microservice may employ other microservices to complete its work. In extreme, a microservice may be an assembly of microservices. Article http://microxchg.io/2015/slides/02_01_DomainServiceAggregators.pdf provides an example of data aggregation with a business domain.
Yes, size in LOC does not matter. There is only one limit – SRP. Interesting, that no limitations on “size” of this single responsibility. Thus a microservice with a greater and single responsibility may be assembled from microservices with lesser and single responsibilities.
From https://genehughson.wordpress.com/2015/02/06/wait-did-i-just-say-knuth-was-wrong/ “In the comments, it was suggested that granularity was irrelevant as multiple granular microservices could be composed to form a coarser-grained microservice that would provide a more appropriate level of abstraction. My response was that while this is theoretically true, aggregating service calls in that manner risks issues due to network latency.”
In addition for my comments to that blogpost, I would like to add that designing microservices as distributed autonomous components (each with own computing process) is forcing to consider (up-front and not as refactoring) a proper error-recovery which is much more difficult than the error-handling when components are in the same computing process.
In general, a business capability is a cohesive set of processes (or cluster of processes in accordance with http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html ). Those processes are implemented as assemblies of microservices. Some of those microservices are unique for a particular process and for a particular cluster; others are shared between clusters.
From https://www.voxxed.com/blog/2015/01/good-microservices-architectures-death-enterprise-service-bus-part-one/ “Microservices and their granularity are ideal for the development and maintenance of the service. But that does push complexity more towards the app itself. A complexity that those apps cannot manage as they are often executed on platform with constrained resources (battery, network, CPU). Combining services in a higher level logic to serve the purpose of apps or business processes proves to be faster to develop and easier to maintain.”
Yes, assembling of microservices is the way to reduce complexity.
If application as a unit of deployment (even decomposed into a few tiers) is no more the physical boundary then boundaries becomes logical and they are coming from the business – business functions, business services and business capabilities. Note they are actually just different viewpoints – see “Common understanding of #bizarch (business architecture) and #BPM” http://improving-bpm-systems.blogspot.ch/2015/01/common-understanding-of-bizarch.html . Less IT applications and more business-process-centric solutions.
From http://nealford.com/memeagora/2015/03/30/architecture_is_abstract_until_operationalized.html “Continuous Delivery and the DevOps movement illustrated the pitfalls of ignoring the effort required to implement an architecture and keep it current. There is nothing wrong with modeling architecture and capturing those efforts, but the implementation is only the first step. Architecture is abstract until operationalized. In other words, you can’t really judge the long-term viability of any architecture until you’ve not only implemented it but also upgraded it. And perhaps even enabled it to withstand unusual occurrences.”
Correct, but slightly simplified observations – actually, 3 (three) major upgrades are necessary to demonstrate that architecture is good. Rationale: it is recommend leaving a solution team before the 3th major upgrade of this solution.
From http://www.infoq.com/articles/service-oriented-architecture-and-legacy-systems “Integration suites offer a complete stack that not only gives ESB capabilities but also more business-specific tools such as BPM (business process management), business activity monitoring, master data management, and a repository.”
As microservices become place-independent, it is necessary to have a good “naming service” (as we had in CORBA) to allow mapping of microservice’s URI to new URL. Such “naming services” is also known as discovery services.
At present, there is no synergy between microservices and API as illustrated by the following quotes:
From http://sdtimes.com/digging-into-microservices/ “The fundamental difference between microservices and APIs is that microservices are used to build applications, whereas APIs are used to integrate applications...”
From http://cloudramblings.me/2015/03/20/microservices-martin-fowler-netscape-componentized-composable-platforms-and-soa-service-oriented-architecture/ “Part of the problem with API management and micro-services or with the mediation / message broker middleware technologies is that these can impose a software layer that is burdensome on the micro-services architecture... Let us say an approach to implementing micro-services would be to put them into a traditional API Management service as offered by a number of vendors. There would indeed be an overhead introduced because the API Layers impose a stiff penalty of authentication, authorization, then load balancing before a message can be delivered. What is needed is a lightweight version of API Management for some trusted services behind a firewall that are low risk and high performance.”
From http://devops.com/blogs/containers-designed-antiquated-application-architecture/ “Cloud-scale applications by nature are stateless with any application state being managed by cache or database services. The compute unit of measure is the process not the CPU, which enables greater scalability. .... They scale across network architectures easily allowing businesses to run in private data centers and leverage cloud for excess capacity when needed.”
From http://12factor.net/backing-services “Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.” and “Treat backing services as attached resources”.
one persistency service (or backing service) for the state of the whole solution (even distributed solution)
predefined state which is created by embedding state into an individual containerized copy of the microservice (but the run-time knowledge about the context is mandatory)
idempotency
6.2 Performance
Potential techniques for performance improvement (primarily the network latency):
easy moving an individual containerized copy of the microservice between nodes (thus moving a microservice close to its consumer upto his/her mobile device)
on-demand creating an individual containerized copy of the microservice (but the run-time knowledge about the context is mandatory)
creating an individual containerized copy of the microservice for a particular consumer to diminish the security overhead (but the run-time knowledge about the context is mandatory)
6.3 Lightweight security
predefined state which is created by embedding security keys into an individual containerized copy of the microservice (but the run-time knowledge about the context is mandatory) thus achieving self-containment of PEPs
Let us look at the post “Architecting application architecture #apparch (inspired by #microservices)” http://improving-bpm-systems.blogspot.ch/2014/12/architecting-application-architecture.html and extend the described in it architecture to being cloud-friendly. In that blogpost, I introduced Autonomous Component (AC) with a note that at present, it is not possible to claim that ACs are microservices or services.
This architecture implements business solutions (instead of IT applications because the boundaries of IT applications are not relevant any more) as a coordinated collection of autonomous components. Each AC is a unit of functionality (as SRP) which can be executed in its own computing process (thus a unit of deployment which can be deployed in a separate host somewhere). An AC may be an assembly of several ACs. In general, ACs are structurally interdependent, behaviorally (or operationally) independent and contractually dependent.
Below, several typical ACs are described from the “being cloud-friendly” viewpoint through the following characteristics:
Contracting ACs: Use of some resource-access ACs and short-running ACs.
Example: Web-client or Fat-client for a document management system.
Note: Operation are usually short-running human and short-running automated ones.
Functional role-based portal (FRBP) AC to select a function and execute it with some data/documents as a user-facing AC. It provides two types of operations: 1) static list of functions what this role may do and 2) dynamic list of activities what this role has to do. A function is a set of activities.
Note: There are two types of operations: 1An operation may be short-running human, short-running automated and long-running one. The latter is a coordination of short-running ones and other long-running ones.
Human operation (HO) AC to interact with a human.
Cloud-friendly: stateless or stateful, multiple-place-independent, individual-instantiation.
Security techniques: RBAC, embedded.
Contracting ACs: May use some resource-access, resource-assembly-access and utility ACs.
Example: Interactive form.
Note: The state is kept in a solution-state persistence backing service.
Note: Human operation AC may be short-running and long-running.
Automated operation (AO) AC to transform some resources and/or solution-state data.
The cloud-friendly application architecture is demonstrated on video below to show how various ACs implement a typical process-centric solution (this video is inspired by http://improving-bpm-systems.blogspot.ch/2014/12/bpm-for-soaesbapi-and-cloud-paas-and.html ). Obvious, presented scenario may handle several process-centric solutions and several copies of the same solution (a copy per user) simultaneously.
The scenario has the following stages:
a) The functional-role-based-portal AC offers to a user some functions to initiate (as a static list). Each of functions is an explicit-coordination-operation AC which comprises several human-operation ACs and automated-operation ACs. Human-operations ACs are to be executed by users and they are dynamically listed for each users.
b) All explicit-coordination-operation ACs are implemented as DSL-script. The DSL-manager AC provides a list of functions which are offered for users. The DSL-processor AC provides a list of activities which have to be executed by some users.
c) A user executes a function which is implemented as a DSL-script; the DSL-manager AC instantiates an individual copy of this explicit-coordination-operation AC via the DSL-processor AC. (Covered by markers 1-3.)
d) The first of two operations within this explicit-coordination-operation AC is the automated-operation AC which uses several other ACs; the explicit-coordination-operation AC instantiates an individual copy of this automated-operation AC and individual copies of two of ACs used by it (“Utility” and “Resource assembly access”). Then the automated-operation AC is executed (Covered by markers 4-6.)
e) The second of two operations within this explicit-coordination-operation AC is the human-operation AC; the explicit-coordination-operation AC instantiates an individual copy of this human-operation AC and an individual copy of the other AC used by it. (Covered by marker 7).
f) The human operation AC must be completed by a user and it informs the explicit-coordination-operation AC. (Covered by markers 8 and 9).
g) The explicit-coordination-operation AC terminates.
and its static view
9 Conclusion
The cloud-friendly application architecture follows the business domain boundaries, processes, entities, documents, roles and rules.
The cloud-friendly application architecture reduces complexity by adding a structure among ACs:
long-running functions (actually, business processes)
short-running operations (actually activities or routines)
assembly of resources (actually, business entities or business objects)
resource (actually data and documents)
The cloud-friendly application architecture reinforces the information security by dynamics security for resources and embedded security for ACs
In the cloud-friendly application architecture the majority of ACs are cloud-friendly thus solutions based on this architecture are scalable.
The cloud-friendly application architecture covers majority of cross-cutting concerns : event handling, error recovery, persistence (state management), concurrency, security, interactions, distributed transactions, logging, monitoring and testing.
For the stable functioning of an enterprise, it is mandatory to define up-front WHO (person, system, role) can DO SOMETHING (e.g. read, update, delete) with WHAT (tangible or intangible asset or resource), WHEN (at a particular moment of time), WHERE (from which tool, environment), WHY (justification) and HOW to impose this.
There are two popular techniques:
Role-Based Access Control (RBAC) is about what role (WHO) can execute what operation (DO SOMETHING) on a particular object (WHAT).
Attribute-Base Access Control (ABAC) is about granting rights to users (WHO) through the use of policies which combine attributes together. The policies can use any type of attributes: user (WHO) attributes, resource (WHAT) attributes, environment (WHERE) attribute etc.
To provide a reasonable granularity, RBAC causes an explosion of roles and ABAC causes an explosion of rules. Both techniques are static and require a lot of work to handle compound resources.
2 Process-Based Access Control (ProBAC)
To reinforce the governance, management and operations over the classic access control techniques, it is proposed to consider the access control with the context of business processes.
The enterprise functioning is considered as business activity flows spanning systems, employees, customers and partners within and beyond the enterprise boundaries. Various roles as well as tangible and intangible resources are involved in each business activity. Some resources are read-only for some of those roles; other resources can be modified by some of these roles. (Of course, we remember, that for each activity, the RACI pattern may be applied).
The illustration below shows this in dynamic:
by default, the roles associated with a particular activity have no access to the resources associated to this activity;
an actor (a concrete staff member) who claimed this activity is granted necessary permissions to do something with the associated resources;
as the actor finished the activity, all given permission are revoked.
This is the principle. Of course, the activity life-cycle is more complex because of delegation, escalation, cancellation and un-claiming. Each change of activity’s state should
Enterprise functioning can be considered as business activity flows spanning the applications, employees, customers and partners within and beyond the boundaries of the enterprise. Staff as well as tangible and intangible resources are involved in each business activity. Ensuring of the information security implies the following characteristics of the enterprise functioning:
Any business activity is performed only as prescribed and any unintended use of information (e.g., access to information resources unrelated to the work performed) would be impossible in principle.
Organization and initial planning of business activities must be validated for the compliance with the formal rules of information security.
Execution and operational planning of business activities must be constantly validated for the compliance with the formal rules of information security.
In this blogpost, it is show how BPM can contribute into enhancing the information security.
Control of access to an informational resource along the process
In simple cases, the control of access to an informational resource can be rigidly connected to the phases of the life cycle of the resource. The latter can be implemented as a business process. Explicit and executable business process is convenient because the whole dynamic of control access is embedded in the process.
This allows better control of access rights change.
Control of access to an informational resource within an activity
In more complex cases, information resources linked to specific business activities. An employee, appointed for the carrying out of a particular business activity, gets access to the information resources required for the carrying out this business activity, only for the duration of this business activity.
Objective operational data collected, who has/had access to what information resources will increase the level of information security.
Separation of duty within a business process
In a simple form, the separation of duty is a check that the actual work to be done (“Do” in diagram below) and the validation of the result of this work (“Check” in diagram below) are always carried out by separate staff members.
Thus, business processes can detect potential cases for the separation of duty by establishing relationships between business activities.
Separation and imposition of duty among several business processes
In a general form, relationships between business activities should be established and formally registered. A non-inclusive list of such relationships is the following:
Other activities which validate the results of the given activity.
Other activities which define the governance for the given activity.
Other activities which do the handling exceptional situations for the given activity (error handling, escalations, send for review and delegate).
Other activities which audit the given activity (1st, 2nd and 3rd party audit).
Other activities which evaluate the risks before the given activity.
Other activities which evaluate the risks after the given activity.
Other activities which certify the given activity (1st, 2nd and 3rd party certification).
Other activities which do compensation (undo) for the given activity.
These relationships between activities define some limitations that roles and actors may carry out what activities: the same actor or a different actor from a different role or a different actor from the same role. For example, if the “Activity_B” validates the results of “Activity_A” then no actor should be in “Role_1” and “Role_2” simultaneously.
Thus, the separation of duty maybe formally validated at the design-time.
Management of risk along business processes
Managing any work by processes is the key business capability with allows to address the risk-related issues in a proactive manner. The risk is strongly related to how the business processes are carried out. By understanding a process (i.e. through being able to simulate it) the business may predict how the risk is changing during the execution of that process. The explicit description of processes permits to add a few “check-points” within any process to examine its risk-related “health”.
Business processes act as a skeleton to which the enterprise adds risk management (as shown on the picture below) – each usual activity is enriched by risk-related monitoring and evaluation.
The risk evaluation may initiate some risk mitigation processes. The risk evaluation may be as complex as necessary, and it may include simulations (e.g. value at risk and stress testing), and the conduct of statistical and scenario analysis.
QUOTE START
Problems occur in business processes when someone or some technology does something wrong whether intentional, mistakenly or as part of a targeted attack. We can only achieve true security when multiple actions and process can be detected simultaneously and in real time. New technologies are offering these capabilities in a time when we are rapidly expanding interconnected humans to intelligent machines that have capabilities that are so large we are having trouble even viewing these processes.
We need to start recognizing that authentication of a person no matter how accurate the techniques used are only the first level of cybersecurity. True security can only be achieved when combining prevention and detection technologies at the real time business or process input action level. Most security breaches occur quickly and are themselves an input process action. Using technology than can focus on these input actions is where we need to focus our efforts.
True cybersecurity will be obtained when we can effectively view, audit, correct and block organizational process actions. If you could have a technology that does this, then why not?
QUOTE FINISH
Maybe, instead of reactively "view, audit, correct and block processes" at run-time, proactively build-in the security into business processes at design-time?
A few examples of how BPM addresses security concerns are below.
As coordination can be carried out by an application or by a process engine, we have to be very careful to avoid the “double master” anti-pattern. At any moment in time there must be only one master responsible for the coordination of a particular process instance. (Of course, the coordination role may be delegated if appropriate.) This is analogous to a well-organised meeting where the chairperson decides who talks next.
Also well-coordinated work improves the security and integrity of data. It can be a useful design pattern to consider that only the person who has accepted a particular human activity can modify the business objects associated with that human activity. This is a dynamic granting/revoking of permissions which is synchronised with the process. Something like in the diagram below (which is not a valid BPMN as there are no "claim" and "unclaim" events defined).
The non-recognition of this anti-pattern can be very costly. We have observed a BPM solution which allowed the modification of data by a process engine, by an interactive application (i.e. by a human) and by a batch at the same time. The coordination of activities was based on data and, if necessary, the application or the batch could “correct” the process. The process engine was used mainly for the handling of three human activities, and the implementation of this solution (for a relatively simple business process) took several man-years.
In many cases, it is impossible to find a single ERM product which spans all business areas to be covers by ERM. So, it requires building an internal ERM platform on top of which different ERM-related applications will be built (following the PEAS enterprise pattern – see http://improving-bpm-systems.blogspot.com/2011/04/enterprise-patterns-peas.html ).
Business architecture view
Risk must be carefully monitored (through data collection), evaluated and acted upon. This means (see also the illustration below):
Enterprise business functions should be enriched to generate the risk-related data.
Those risk-related data need to be collected at the enterprise data warehouse together with other business data.
Some business processes need to be updated to embed risk-related activities.
A set of risk-related rules, logic and risk-related knowledge should be able to use the risk-related and other business data to detect acceptable limits of risk as well as interdependencies and correlations between different risks.
Some business processes for risk mitigation maybe automatically activated.
A lot of risk-related indicators, alerts should be available in the form of dashboards and reports available for different staff members.
Staff members should be able to initiate business processes based on the observed risk-related information.
Business-generic capabilities involved
The following business-generic capabilities are involved in the ERM platform:
Management by processes
Efficient data gathering channels
Single version of truth for data
Ingesting (into the data warehouse) of external information
Efficient dissemination channels
Effortless collaboration within groups / communities of practices
Formalized business logic
Supremacy of management by processes
Managing any work by processes is the key business capability with allows to address the risk-related issues in a proactive manner. The risk is strongly related to how the business processes are carried out. By understanding a process (i.e. through being able to simulate it) the business may predict how the risk is changing during the execution of that process. The explicit description of processes permits to add a few “check-points” within any process to examine its risk-related “health”.
Business processes act as a skeleton to which the enterprise adds risk management (as shown on the picture below) – each usual activity is enriched by risk-related monitoring and evaluation.
The risk evaluation may initiate some risk mitigation processes. The risk evaluation may be as complex as necessary, and it may include simulations (e.g. value at risk and stress testing), and the conduct of statistical and scenario analysis.
IT-generic capabilities involved
The following IT-generic capabilities are involved into the ERM platform:
Posts
