Better architecting with - explicit #security

1 Addressing crosscutting aspects by-design

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:

1. the security-related paraments, i.e. threats, attacks and vulnerabilities (see oval “Security”) for each least granular system elements;
2. 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;
3. 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)

1. Add all external enhancement points.
2. Add all external enhancement controls for 4 activities which are “black-boxes”.
3. Add all external enhancement methods for 2 activities which are “white-boxes” and the process as the whole.
4. 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).

1. Enterprise business functions should be enriched to generate the risk-related information.
2. Those risk-related data need to be collected at the enterprise data warehouse together with other business information.
3. Some business processes need to be updated to embed risk-related activities.
4. 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.
5. Some business processes for risk mitigation maybe automatically activated.
6. A lot of risk-related indicators, alerts should be available in the form of dashboards and reports available for different staff members.
7. Staff members should be able to initiate business processes based on the observed risk-related information.

Additional security-related techniques are mentioned in https://improving-bpm-systems.blogspot.com/2014/04/ideas-for-bpmshift-delenda-est-vendor.html

4 Conclusion

Crosscutting aspects are desired emergent characteristics of a system. They must be addressed systemically.

Thanks,

AS


This blogpost belongs to the series https://improving-bpm-systems.blogspot.com/search/label/%23BAW

Smart Cities from the systems point of view

Thanks,
AS

#GDPR as an #BPM application

This blogpost explains how to implement the EU General Data Protection Regulation (GDPR) by design and by default via Business Process Management (BPM). This blogpost describes only a reference solution architecture without much implementation details. It focuses, primarily, on the artefacts such as capabilities, rules, roles, data-structures, documents, explicit coordination and audit trails.

1 Terminology in the GDPR

Although the information security domain is developed well, the GDPR document (see article 3) uses rather exotic terminology (sources are not provided). For example, many concepts, available from the standard privacy framework (ISO/IEC 29100) have different designations (terms). Another example is that the concepts “data” and “information” do not follow the DIKW “pyramid”.

Although a mapping between 16 terms of the GDPR and existing terminology is not difficult, it would be better to avoid such a mapping.

2 The main element

The main element of the GDPR is a data-structure object “Personally Identifiable Information” (PII) in the ISO/IEC 29100 terminology or “personal data” in the GDPR terminology. It must be explicitly and carefully protected:

• for its confidentiality, integrity and availability
• in rest, in transit and in use
• throughout its life cycle

Usually, the life cycle of PII objects is very simple and covered by 4 actions which are known as the CRUD pattern (although each update may create a new version of the PII object). 

3 The core processes

Those actions, namely, Create, Read, Update and Delete, must be presented as small processes (or workflows) to provide the design and execution traceability. Considering that any PII is owned by the “PII principal” (or a natural person to whom a set of personally identifiable information relates), he/she must approve some actions on his/her PII object.

For example, an PII principal must provide his/her consent to process his/her PII object and such a consent must be kept as a record by the “PII processor” (privacy stakeholder that processes personally identifiable information on behalf of and in accordance with the instructions of a “PII controller”).

4 Some supporting capabilities

The core (or life cycle) processes use several capabilities (services or processes) such as:

• identity management
• access management
• anonymization 
• encryption
• etc.

Also, some error- and exception-handling processes are necessary to properly handle privacy incidents.

5 Related roles

The essential roles are the following:

• “PII principal” in the ISO/IEC 29100 terminology or “data subject” in the GDPR terminology – the owner of the PII, 
• “PII processor” – persons or organisations who/which execute the GDPR processes,
• “PII controller” – authority which, alone or jointly with others, determines the purposes and means of the processing of personal data, and
• “Data Protection Officer (DPO)” – person who is the owner of the GDPR processes.

6 Rules

The execution of the GDPR processes is guided by numerous rules which are; actually, the majority of the GDPR documents. For example, if a PPI principal is a citizen of an EU countries then “PII processes” must follow the GDPR.

Unfortunately, it is unknown if these rules comply to the MECE principle (no overlaps and no holes). 

7 Complex scenarios

There are a few scenarios which involve more than one PII object. For example, split, merge, export, transportation, correlation, etc.

8 Conclusion

Use of BPM to implement the GDPR addresses all the GDPR concerns. Explicit and machine-executable processes are mandatory to achieve by design and by default the listed below key points.

• Compliance – all privacy-related activities and coordination between them can be easy analysed.
• Accountability – generated audit trails provide factual and objective information about why did what.
• Data protection officers (DPOs) – as a role which owns all the GDPR processes.
• Consent – is achieved by the design of the GDPR processes and records management.
• Enhanced rights for individuals – is achieved by the design of the GDPR processes.
• Privacy policies – all PII controllers and PII processors must analyse their privacy policies via the logic of explicit processes.
• International transfers – also become processes.
• Breach notification – as an integral part of the privacy incident GDPR processes.

Thanks,
AS