Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mini-course at VFU - Architecting modern digital systems - 3

28 views

Published on

A small source for IT students at the VFU, Varna.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Mini-course at VFU - Architecting modern digital systems - 3

  1. 1. Architecting digital systems Module 3 Security Alexander Samarin
  2. 2. – Personal security – Physical security – Information security – Corporate governance – Compliance and ethics programs – Crime prevention and detection – Fraud deterrence – Investigations – Risk management – Business continuity planning (resilience) – Crisis management – Environment, safety and health © A. Samarin 2018 Architecting digital systems - Module 3 2 Corporate security
  3. 3. • People or enterprise, you have goals. The key is to achieve these goals. A goal can be to acquire a new asset, to then use it to achieve a bigger goal. • You use your assets (tangible or intangible) to achieve your goals. • Plans tell you how you will use your assets to achieve your goals. A plan is an asset as well. • Threats work to prevent your achieving goals. Threats may be criminals, governments, natural. © A. Samarin 2018 Architecting digital systems - Module 3 3 Security basics (1)
  4. 4. • threat potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm [SOURCE: IEC Guide 120, 3.15] • Threats are materialized as threat events or attacks or hazardous events • attack assault on a system that derives from an intelligent threat – i.e., an intelligent act that is a deliberate attempt (especially in the sense of a method or technique) to evade security services and violate the security policy of a system [SOURCE: IEC Guide 120, 3.2] © A. Samarin 2018 Architecting digital systems - Module 3 4 Security basics (2)
  5. 5. • Threats and attacks are feasible because an asset may have some security vulnerabilities • vulnerability flaw or weakness in a system’s design, implementation, or operation and management that could be exploited to violate the system’s security policy • Each attack causes harm to an asset • harm injury or damage to the health of people, or damage to asset or the environment [ISO/IEC Guide 51, 3.1] © A. Samarin 2018 Architecting digital systems - Module 3 5 Security basics (3) More generic concept is necessary in the digital age
  6. 6. • security condition that results from the establishment and maintenance of protective measures that ensure a state of inviolability from hostile acts or influences [SOURCE: IEC Guide 120, 3.13] – Note: Hostile acts or influences could be intentional or unintentional © A. Samarin 2018 Architecting digital systems - Module 3 6 Security basics (4)
  7. 7. © A. Samarin 2018 Architecting digital systems - Module 3 7 Big picture: security Attack Vulnerability Asset can succeed or exploit has consequence on Threat causes Security Harm causes
  8. 8. • Risk is a relative measure of the extent to which an asset is threatened by a potential circumstance • risk combination of the probability of occurrence of harm and the severity of that harm – [SOURCE: IEC Guide 120, 3.11] • Information security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (i.e., mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation. [NIST SP 800-30] © A. Samarin 2018 Architecting digital systems - Module 3 8 Risk basics (1)
  9. 9. • risk assessment – process of identifying, estimating, and prioritizing information security risks [NIST Special Publication 800-30 Revision 1, fig 2] © A. Samarin 2018 Architecting digital systems - Module 3 9 Risk basics (2)
  10. 10. • Risk models define the risk factors to be assessed and the relationships among those factors. • Risk factors are characteristics used in risk models as inputs to determining levels of risk in risk assessments. • Simple approach (from CRAMM) © A. Samarin 2018 Architecting digital systems - Module 3 10 Risk basics (3)
  11. 11. • NIST SP 800-30 approach - typical risk factors include – threat (or threat source), – attack (or threat event), – vulnerability, – level of adverse impact (or severity of harm) – likelihood (or occurrence of harm), and – predisposing condition. © A. Samarin 2018 Architecting digital systems - Module 3 11 Risk basics (6)
  12. 12. • Each harm is evaluated by its severity of harm or adverse impact • The adverse impact from an attack is the magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability • impact positive or negative change to society, economy or the environment, wholly or partially resulting from an organization’s past and present decisions and activities – [SOURCE: ISO 26000:2010, 2.9] © A. Samarin 2018 Architecting digital systems - Module 3 12 Risk basics (7)
  13. 13. • The occurrence of harm is a weighted risk factor based on an analysis of the probability that a given threat is capable of exploiting a given vulnerability (or set of vulnerabilities). © A. Samarin 2018 Architecting digital systems - Module 3 13 Risk basics (8)
  14. 14. • In addition to vulnerabilities, organizations also consider predisposing conditions. A predisposing condition is a condition that exists within an organization, a mission or business process, enterprise architecture, information system, or environment of operation, which affects (i.e., increases or decreases) the likelihood that threat events, once initiated, result in adverse impacts to organizational operations and assets, individuals or other organizations. • Predisposing conditions include, for example, the location of a facility in a hurricane- or flood-prone region (increasing the likelihood of exposure to hurricanes or floods) or a stand-alone information system with no external network connectivity (decreasing the likelihood of exposure to a network-based cyber attack). © A. Samarin 2018 Architecting digital systems - Module 3 14 Risk basics (9)
  15. 15. © A. Samarin 2018 Architecting digital systems - Module 3 15 Big picture: security and risk Attack Vulnerability Asset Risks can succeed or exploit has consequence on Threat causes Security impact x likelihood Harm causes has Adverse impact Likelihood Predisposing conditions
  16. 16. • An example of a risk model including the key risk factors discussed above and the relationship among the factors • [NIST Special Publication 800-30 Revision 1, fig 3] © A. Samarin 2018 Architecting digital systems - Module 3 16 Risk assessment dependencies Adverse impact is system-of-interest dependent and very difficult to objectively evaluate
  17. 17. © A. Samarin 2018 Architecting digital systems - Module 3 17 Big picture: security, risk and architecture Attack Vulnerability Least granular assets Riskscan succeed or exploit has consequence on Threat causes Security impact x likelihood Harm causes has Adverse Impact Likelihood Predisposing conditions Business processes Services Outcomes Objectives slow down underperforming missing exposing to Digital system architecture Digital system architecture helps to evaluate adverse impact for each asset (least granular and composite)
  18. 18. © A. Samarin 2018 Architecting digital systems - Module 3 18 Security services classification (1)
  19. 19. © A. Samarin 2018 Architecting digital systems - Module 3 19 Security services classification (2)
  20. 20. © A. Samarin 2018 Architecting digital systems - Module 3 20 Security services reality
  21. 21. • information security preservation of confidentiality, integrity and availability of information – Note: In addition, other properties, such as authenticity, accountability, non-repudiation, and reliability can also be involved. • confidentiality property that information is not made available or disclosed to unauthorized individuals, entities, or processes • integrity property of accuracy and completeness • availability property of being accessible and usable upon demand by an authorized entity © A. Samarin 2018 Architecting digital systems - Module 3 21 Information security basics (1) [SOURCE: IEC Guide 120]
  22. 22. • [NIST 800-160] © A. Samarin 2018 Architecting digital systems - Module 3 22 Information security basics (2)
  23. 23. • privacy right of an entity (normally an individual or an organization), acting on its own behalf, to determine the degree to which the confidentiality of their private information is maintained [SOURCE: IEC Guide 120, 3.10] • Privacy is very important because of EU General Data Protection Regulation (GDPR) © A. Samarin 2018 Architecting digital systems - Module 3 23 Information security basics (3)
  24. 24. © A. Samarin 2018 Architecting digital systems - Module 3 24 Example of dependences Threats (yellow) vs attacks (blue)
  25. 25. • [NIST Special Publication 800-30 Revision 1, fig 1] © A. Samarin 2018 Architecting digital systems - Module 3 25 Risk management basics
  26. 26. • [NIST Special Publication 800-30 Revision 1, fig 4] © A. Samarin 2018 Architecting digital systems - Module 3 26 Multi-tiered risk management
  27. 27. • [NIST Special Publication 800-39, fig 3] © A. Samarin 2018 Architecting digital systems - Module 3 27 Tier two risk assessment —mission/business process view
  28. 28. • Related publications – ISO/IEC 31000, Risk management – Principles and guidelines; – ISO/IEC 31010, Risk management – Risk assessment techniques; – ISO/IEC 27001, Information technology – Security techniques – Information security management systems – Requirements; and – ISO/IEC 27005, Information technology – Security techniques – Information security risk management systems. © A. Samarin 2018 Architecting digital systems - Module 3 28 Risk management standards
  29. 29. mission & business needs © A. Samarin 2018 Architecting digital systems - Module 3 29 Systems architecting: concerns, needs and requirements asset protection needs concern, constrains risk tolerance life cycle concepts Stakeholder’s high- level requirements System high-level requirements System detailed requirementsstories, expectations domain outline, influencing factors Reference model Reference architecture high-level use cases detailed use cases Solution architecture asset loss consequences system concerns Problem space Solution space trade concerns Domain Security, safety, privacy Systems Mixture …
  30. 30. STAKEHOLDER viewpoint • Assets • Mission or business needs • Security objectives • Concept of operations • Laws, regulations, policies • Organizational constraints SYSTEM viewpoint • System assets • Architecture, design, and implementation decisions • System self-protection • Secure system management TRADES viewpoint • Engineering • Requirements • Risk treatment trades • Engineering trades © A. Samarin 2018 Architecting digital systems - Module 3 30 Protection needs: input and output Security requirements • Functional • Non-functional (quality) • Assurance Security policy • Security policy objectives • Organisational policy • System-level policy All input sources can be potentially harmed because of their vulnerabilities [Source NIST 800-160]
  31. 31. Business or Mission - Environment of operation of the business or mission; - Processes, procedures, and interactions associated with the business or mission; - Data and information; - Proprietary/sensitive data and information; - Roles, responsibilities, and interactions of personnel; - Interactions with other organizations; - Business or mission functions and function interaction; - Criticality ranking and prioritization of business or mission functions; Normal, abnormal, and transitional modes, states, and conditions of business or mission operations. System Use - Method of using the system to support the organization across all planned business or mission modes of operation and system modes of operation including operation in contested environments; - Interactions with other systems and services within the organization; - Interactions with other external organizations, systems, services, and infrastructures; and - Placement of the system within the organization (i.e., physical or logical placement). Intellectual Property - Identification of intellectual property assets that include data, information, technology, and methods associated with the system throughout its life cycle. Trustworthiness - Policy, legal, and regulatory requirements and mandates; - Processes to be followed (e.g., acquisition, development, production, manufacturing, risk management, verification and validation, assurance, assessment, authorization); and - Agreements, arrangements, and contracts for services provided to or received from external organizations. © A. Samarin 2018 Architecting digital systems - Module 3 31 Some artefacts to be considered Information - Identification of information required to support the business or mission; - Method of using information to support the business or mission; - Sensitivity of information and concerns associated with its use and dissemination; - Identification of legal, regulatory, privacy, or other requirements that address information protection, use, and dissemination; - Information criticality and prioritization in supporting the business or mission; and - Impact to the business or mission, organization, or other organizations if the information is compromised, damaged, or becomes inaccessible. Enabling Systems and Other Systems of the System-of-Interest - Identification of systems, services, or infrastructures used to support the business or mission; - Method of use for systems, services, or infrastructures supporting the business or mission; - Criticality of systems, services, or infrastructures supporting the business or mission; and - Impact to the business or mission, the organization, or other organizations if the systems, services, or infrastructures are compromised, damaged, or become inaccessible. Disruptions, Threats, and Hazards - Threat and hazard information associated with all system life cycle processes and concepts; - Identification of potential threat and hazard sources to include, but not limited to, natural disasters, structural failures, cyberspace and physical attacks, misuse, abuse, and errors of omission and commission; and - Plans, doctrine, strategy, and procedures to ensure continuity of capability, function, service, and operation in response to disruptions, threats, hazards, and inherent uncertainty. [Source NIST 800-160]
  32. 32. • NIST draft cybersecurity framework – 23 Category – 107 Sub-categories – 401 fragments from many international and industry standards © A. Samarin 2018 Architecting digital systems - Module 3 32 There is an enormous amount of good information about security
  33. 33. • Car security is about protecting the car and it's contents from criminal activity. • Car safety is about protecting people by making the car less likely to be involved in an accident and including features that mean people are less likely to be injured if there is an accident. • safety freedom from risk which is not tolerable © A. Samarin 2018 Architecting digital systems - Module 3 33 Example: security and safety
  34. 34. © A. Samarin 2018 Architecting digital systems - Module 3 34 Organizational Diagram of Safety Standards ISO/IEC Guide51 Basic Safety Standards Safety of machinery – General principles for design - Risk assessment and risk reduction (ISO12100) Fundamental concepts, principles and requirement with regard to general safety aspects applicable to a wide range of products and systems Product Safety Standards This comprises safety aspects applicable to several products or systems, or a family of similar products or systems, making reference, as far as possible, to basic safety standards. Group Safety Standards This comprises safety aspects for specific products or systems, or a family of similar products or systems, making reference, as far as possible, to basic safety standards and group safety standards. System safety (ISO 13849-1) Safety related parts of control systems (ISO 13849-2) etc. Electrical equipment of machines (IEC60204-1) Functional safety of electrical/ electronic/programmable electronic safety-related systems (IEC61508) etc. http://www.keyence.com/ss/products/safetyknowledge/introduction/system/
  35. 35. safety measure Safety Residual risk Widely acceptable risk Acceptable risk Unacceptable risk Risk (large)Risk (small) Safety = Tolerable Risk • Accepted risk under given circumstances based on values of society of that era • Residual risk exists even within safety http://www.mukaidono.jp/kouen/files/130217kennsagijutu.pdf (in Japanese/ Translated from this document) © A. Samarin 2018 Architecting digital systems - Module 3 35 ISO/IEC Guide 51
  36. 36. • resilience – the capacity to recover quickly from difficulties; toughness. © A. Samarin 2018 Architecting digital systems - Module 3 36 Resilience Expected capacity loss Recovery time
  37. 37. • Threats and vulnerabilities are universal • There is a registry for publicly known information-security vulnerabilities and exposures https://cve.mitre.org/ • The level of adverse impact from an attack depends on the architecture of the system-of-interest • Security and risk can be objectively link by architecture • But how to use all this information to architect systems with security, safety and privacy by design and by default? © A. Samarin 2018 Architecting digital systems - Module 3 37 Improving security (1)
  38. 38. © A. Samarin 2018 Architecting digital systems - Module 3 38 Improving security (2) Attack Vulnerability Least granular assets Riskscan succeed or exploit has consequence on Threat causes Security impact x likelihood Harm causes has Adverse Impact Likelihood Predisposing conditions Business processes Services Outcomes Objectives slow down underperforming missing exposing to Digital system architecture Digital system architecture helps to evaluate adverse impact for each asset (least granular and composite)
  39. 39. • Architecture must know all the relationships between all the artefacts (technical assets, services, processes, etc.) to statically evaluate risks • If the implementation of a system is based on business processes then it can dynamically evaluate risks • Knowing the level of risk, one can implement a set of changes to reduce this level to acceptable one © A. Samarin 2018 Architecting digital systems - Module 3 39 Improving security (3) security measureResidual risk Widely acceptable risk Acceptable risk Unacceptable risk
  40. 40. • Each system element (tangible assets, intangible assets, peoples) must be explicitly protected – for its confidentiality, integrity and availability – in rest, in transit and in use – throughout its life cycle (within the system-of-interest life cycle) • Relationships between system elements are used to know how changes in one system element effects other system elements – those relationships must be protected as well – ideally, those relationships are explicit and machine-executable • B2B partners and service providers have to be secured as well © A. Samarin 2018 Architecting digital systems - Module 3 40 Improving security (4)
  41. 41. • 3 groups of system’s elements: – some system elements are treated as black-boxes by defining for them required functionality, interfaces, performance, security assurance, etc. – some system elements are treated as grey-boxes by defining also their internal structure (e.g. as illustrative processes) – some system elements (which act as system-forming ones) are treated as white-boxes by defining their (reference) implementation © A. Samarin 2018 Architecting digital systems - Module 3 41 Systems approach to security (5)
  42. 42. Systems approach to security (6) Managerial group (white-box) Operational group (white-box) Primary group (black-box) Coordination group (system-forming) Supporting group (system-forming) IoT device bay (white-box) Networked actors API+UI IoT Platform IoT device A IoT device B IoT device Z… Security group (system-forming) © A. Samarin 2018 Architecting digital systems - Module 3 42 •IoT device bay to connect the platform and various IoT devices •Supporting group to provide functionality shared within a digital system (e.g. logging, monitoring, data handling, collaboration, process management, decision management, analytics, etc.) •Security group to provide security functionality •Primary group to provide core business functionality •Coordination group to execute digital contracts between various networking actors, IoT devices and platform itself; •Managerial group to reconfigure the platform •Operational group to maintain the proper functioning of the platform
  43. 43. • Use of existing good IT practices – suggestion: use (partially) methodologies from ITIL (ISO/IEC 20000), ISO/IEC 27000, CoBIT (ISO/IEC 38500) and IT4IT – rationale: many processes and practices for managing IT are already defined • All managerial and operational activities as well as contracts are defined via explicit processes – suggestion: use machine-executable processes and BPM; blockchain may be considered for multi-organisational records management – rationale: such processes are validatable and they allow extra security enforcement points; digital contracts can be used for security enforcement © A. Samarin 2018 Architecting digital systems - Module 3 43 Systems approach to security (7)
  44. 44. • The system must be protected from undesirable behavior of its system elements by the explicit definition of their desired behavior as a contract between the system-in-interest and each its system element – contract must be explicit and machine-executable (thus digital contract) with veritable processes and rules – contracts must be protected as well • Permanent monitoring of all system elements is mandatory • Predictive analytics on all system elements is highly desirable © A. Samarin 2018 Architecting digital systems - Module 3 44 Systems approach to security (8)
  45. 45. • Risk assumptions (e.g., assumptions about the threats, vulnerabilities, consequences/impact, and likelihood of occurrence that affect how risk is assessed, responded to, and monitored over time); • Risk constraints (e.g., constraints on the risk assessment, response, and monitoring alternatives under consideration); • Risk tolerance (e.g., levels of risk, types of risk, and degree of risk uncertainty that are acceptable); and • Priorities and trade-offs (e.g., the relative importance of missions/business functions, trade-offs among different types of risk that organizations face, time frames in which organizations must address risk, and any factors of uncertainty that organizations consider in risk responses). © A. Samarin 2018 Architecting digital systems - Module 3 45 Systems approach to security (9)
  46. 46. • Minimize trusted network zones – suggestion: consider “internal” clouds (each application may be in such an “internal” cloud); all networking actors are considered from the Internet (i.e. endpoints are treated as Internet nodes) – rationale: threats from insiders and outsiders are equally dangerous http://www.visualcapitalist.com/cybersecurity-threat- insiders-outsiders/ • Align the reference information among all system elements and connected systems; consider blockchain as a potential solution • Align the records management among all system elements and connected systems; consider blockchain as a potential solution © A. Samarin 2018 Architecting digital systems - Module 3 46 Systems approach to security (10)
  47. 47. © A. Samarin 2018 Architecting digital systems - Module 3 47 Separate networking zones
  48. 48. • Services for actors (people, organisation, groups, tools) – enrolment – authentication (confirmation of claims) – identification (not mandatory) – and everything else from their life cycle © A. Samarin 2018 Architecting digital systems - Module 3 48 Systems approach to security (11) IAM Authentication Process BPMN Process Model - Level 3: Common Executable Version: 1.0 Author: Mauro Bennici Last Modified: 12/08/2014 FAME Customer ExternalApplication IAMServiceFAMEUI Click external application link Check user data Generate Token Open new browser instance with the token as querystring parameter Login Request Read token from querystring and decrypt it Check token validity Unauthorized access Invalid token Check FAME user mapping User logged-in User known User Login or New account creation User unkwon FAME user mapping process Token
  49. 49. • Services for access management – roles – role membership – operations – business objects • Role – a set of responsibilities obtained as rights (authority to perform) or duties (required to do as part of one’s job) • Responsibility – 1) a permission to execute a particular operation on a particular object with particular parameters and 2) a prohibition to execute the same operation on the same object with particular parameters. • WHO (roles) can/cannot do WHAT (operations) with WHAT (objects) WHEN (timing) and WHERE (location) © A. Samarin 2018 Architecting digital systems - Module 3 49 Systems approach to security (12) Authentication basics
  50. 50. • Organisational role (a manager) • Organisational group (everyone from a department) • Hierarchical group (all managers) • Functional pool • Process role (Process-Owners, Process-Initiators) • Activity role ( Activity-Workers, Activity-Supervisors) • Expertise pool • Project role (Project-Manager) • Security group • …. © A. Samarin 2018 Architecting digital systems - Module 3 50 Systems approach to security (13) Various roles
  51. 51. © A. Samarin 2018 Architecting digital systems - Module 3 51 Systems approach to security (14) Some security-related concepts
  52. 52. • At present, many devices from the IoT “world” act as wild animals thus being dangerous in the our world • As in our world, we, people, follow contracts, let us consider rules / regulations / laws for IoT as cyber- physical systems to tame IoT • But we need something more simple and more concrete than the famous “The three laws of robotics” • Let us consider “digital contracts” © A. Samarin 2018 Architecting digital systems - Module 3 52 Example: security for IoT devices (1)
  53. 53. • Each digital contract is a set of explicit and machine- executable processes between Things, Services and Persons 1. Vendor and Buyer: Engage a “digital” lawyer via a standard digital contract 2. Vendor: Propose contract 3. Digital lawyer: Validate contract 4. Buyer: Accept contract 5. Digital lawyer: Seal contract Activities during the contract execution phase: 6. Buyer: Transfer money to escrow 7. Digital lawyer: Announce payment to vendor 8. Vendor: Deliver goods 9. Buyer: Announce acceptance of goods 10. Digital lawyer: Transfer money to vendor Activities during the contract closure phase: 11. Digital lawyer: Close the contract © A. Samarin 2018 Architecting digital systems - Module 3 53 Example: security for IoT devices (2)
  54. 54. • The fridge has several contracts with: – Persons who are living in a particular household – a producer of this Fridge – a service company for maintenance of this Fridge – some online shops to order various food – some other Things within a particular household to achieve together some goals of energy consumption • Note: The in-house network Router knows that this Fridge has rights to connect only to a few external sites; any other contacts will be blocked by the Router © A. Samarin 2018 Architecting digital systems - Module 3 54 Example: security for IoT devices (3)
  55. 55. • The “point-to-point” pattern can be implemented by simple processes – master-slave processes – co-processes • The “majordomo” pattern is about interactions between one master (major-domo, castellan, concierge, chamberlain, seneschal, mayor of the palace, maître d'hôtel, head butler and chief steward) and many servants; several coordination techniques are mandatory: – shared calendars – event-processing – resource allocation, levelling and balancing – processes and cases © A. Samarin 2018 Architecting digital systems - Module 3 55 Example: security for IoT devices (4)
  56. 56. • Because group functioning depends on sharing data and information (including certificates, ID, etc.) their security must be enhanced by a solid records management • Blockchain-based implementations may be considered for more secure records management © A. Samarin 2018 Architecting digital systems - Module 3 56 Example: security for IoT devices (5)
  57. 57. • Use business processes to invoke security and risk controls © A. Samarin 2018 Architecting digital systems - Module 3 57 Advantages of explicit and machine- executable business processes (1) Risk monitoring and evaluation Risk mitigation Normal operations
  58. 58. • Risk must be carefully monitored, evaluated and acted upon with the pace of business processes © A. Samarin 2018 Architecting digital systems - Module 3 58 Advantages of explicit and machine- executable business processes (2) Enterprise data warehouse Risk-related rules, logic and knowledge Risk-related events, reports, alerts, indicators, etc.        Enterprise document management and collaboration 1. Enterprise business functions should be enriched to generate the risk-related data. 2. Those risk-related data need to be collected at the enterprise data warehouse together with other business data. 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.
  59. 59. Do something • Align access rights with the dynamic of work to be done © A. Samarin 2018 Architecting digital systems - Module 3 59 Advantages of explicit and machine- executable business processes (3) Grant necessary rights to a person who will carry out this activity to access involved business objects Revoke previously granted rights
  60. 60. • Align security of a business object (e.g. an organisational document) with the work progress (preparation of this document) © A. Samarin 2018 Architecting digital systems - Module 3 60 Advantages of explicit and machine- executable business processes (4) Personal version Committee review Management approval Group drafting Private Confidential Secret Top-secret Public
  61. 61. Responsible Accountable Consulted Informed • Static separation of duties (the same person must not carry out “DO” and “VALIDATE”) © A. Samarin 2018 Architecting digital systems - Module 3 61 Advantages of explicit and machine- executable business processes (5)
  62. 62. • Dynamic separation of duties • Example – “Activity B” is about validating “Activity A” – These activities may be in different processes – No actors must be assigned to both “Role 1” and “Role 2” © A. Samarin 2018 Architecting digital systems - Module 3 62 Advantages of explicit and machine- executable business processes (6) Activity A Activity B Carry out the work Carry out the work Validating the work Role 1 Role 2
  63. 63. © A. Samarin 2018 Architecting digital systems - Module 3 63 EU GDPR (1) http://ec.europa.eu/justice/data-protection/reform/files/regulation_oj_en.pdf • GDPR applies for all companies that process data on EU residents • GDPR is about demonstrating compliance • GDPR expects you to record the purpose of collecting personal data • GDPR demands an integrated approach to privacy-by-design • GDPR requires Data Protection Impact Assessments • GDPR forces you to report data breaches within 72 hours • Non-compliance to GDPR results in big penalties
  64. 64. • Accountability - crucially, those caught will be required to show compliance e.g. (i) maintain certain documents; (ii) carry out Privacy Impact Assessments; (iii) implement Privacy by Design and Default (in all activities), requiring a fair amount of upfront work. • Data protection officers (DPOs) - in many circumstances, those caught by the GDPR will also need to appoint DPOs and so thought will need to be given as to whether this applies and, if so, who that person or persons might be. • Consent - new rules are also introduced relating to the collection of data, e.g., consent must be "explicit" for certain categories. Existing consents may no longer therefore be valid and consents obtained should be purged going forward. • Enhanced rights for individuals - new rights are introduced around (i) subject access; (ii) objecting to processing; (iii) data portability; and (iv) objecting to profiling, amongst others. • Privacy policies - fair processing notices now need to be more detailed, e.g., new information needs to be given about these new enhanced rights for individuals. Policies will need updating therefore. • International transfers - Binding Corporate Rules for controllers and processors as a means of legitimising transfers are expressly recognised for the first time and so should be considered as a transfer mechanism. • Breach notification - new rules requiring breach reporting within 72 hours (subject to conditions) are introduced and so processes in place (or not) will need to be revisited to accommodate these rules. © A. Samarin 2018 Architecting digital systems - Module 3 64 EU GDPR overview (2) http://www.theinquirer.net/inquirer/analysis/3005509/gdpr-how-to-prepare-your-business-for-incoming-eu-data-laws
  65. 65. • Challenges of the GDPR – privacy by design and by default – EU citizen is the new data owner – explicit confidentiality and sensitive data protection – very process-driven – data protection officer • In general, no problems with the GDPR compliance – Use of explicit and machine-executable business processes – Request GDPR compliance from all partners – Use digital contracts © A. Samarin 2018 Architecting digital systems - Module 3 65 How to satisfy the “privacy” requirement
  66. 66. • At present, GDPR is very difficult https://www.linkedin.com/pulse/how-eus-gdpr-general- data-protection-regulation-your-karl-walter/ • Formal definition of primary objects • Their life cycles (including phases) • Various events pertinent to GDPR • How the life cycle of the object A is linked with the life cycle of the object B • Machine-executable rules • Explicit processes to change phases within life cycles • Reference implementation • Test cases and scenarios © A. Samarin 2018 Architecting digital systems - Module 3 66 Improve GDPR for the digital age
  67. 67. • blockchain – multi-sourced (many owners of information) and – distributed (many owners of data-set copies) record storage with – excellent level of integrity and availability © A. Samarin 2018 Architecting digital systems - Module 3 67 About blockchain (1)
  68. 68. • records unit-of-information • blocks list of records • consensus procedure to approve new blocks • cryptographic hash a special class of hash function that has certain properties which make it suitable for use in cryptography • timestamp securely kept track of the creation and modification time © A. Samarin 2018 Architecting digital systems - Module 3 68 About blockchain (2)
  69. 69. • ledger or distributed ledger blockchain with records about economic transactions measured in terms of a monetary unit of account • miner actors forming and proposing blocks for adding them to the blockchain • Then all depends on an application on top of blockchain • For example, bitcoin may contain wrong information! • And bitcoin already contains some illegal information © A. Samarin 2018 Architecting digital systems - Module 3 69 About blockchain (3)
  70. 70. • It is all about some cryproasset – example: token, cryptocurrency, etc • Questions about cryptoasset: legal status? what is its life cycle? operations? rules? double spending? • Transactions with this cryptoasset – an instance of buying or selling some cryptoasset(s) • Questions about transactions: typology, formal description (input, output, actors, rules) of each type? • Questions about records: typology? format? • Questions about miners: contract? SLA? • Questions about consensus: more economical? © A. Samarin 2018 Architecting digital systems - Module 3 70 Blockchain from the system point of view (1)
  71. 71. • Questions about users: anonymity? privacy? KYC obligations? AML obligations? • Questions about rules: validity of transactions? integrity of ledger • Questions about risks: for investors? for buyers? for sellers? • What elements of any blockchain are centralised? – architecture – rules – software • Current intermediator is dead! Long life new intermediator! © A. Samarin 2018 Architecting digital systems - Module 3 71 Blockchain from the system point of view (3)
  72. 72. • smart contract computer protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of a contract. Smart contracts allow the performance of credible transactions without third parties. • An smart contract is a separate activity in a process between business parties. Thus a high level of validation of smart contracts is not possible. • Use digital contracts © A. Samarin 2018 Architecting digital systems - Module 3 72 Blockchain from the system point of view (4)
  73. 73. • Person’s EHR is a set of all the health-related records of a particular person which are available in some digital formats • Each person is the owner of his/her health records • Any other people must explicitly ask a permission to use some health records • Person’s privacy must be enforced. © A. Samarin 2018 Architecting digital systems - Module 3 73 Electronic Health Records (EHR) implementation
  74. 74. Architecting digital systems - Module 3 Record keeping Record Private storage for content and metadata Public storage for digital signatures Hashing Owner’s private key Owner’s public key Record owner Metadata Metadata.DS_URL © A. Samarin 2018 74
  75. 75. Architecting digital systems - Module 3 Record exchange Original anonymised record Record owner Its metadata Annotations Personalised record Its metadata Recipient’s public key Record recipient Owner’s private key © A. Samarin 2018 75
  76. 76. Request some patient’s records Doctor Arrange a visit to a doctor Patient Send the requested records to the doctor Patient Receive and file the requested records Doctor Visit Both Send new records to the patient Doctor Receive and file new records Patient Patient private storage Doctor private storage Deposit box Public storage ❶ ❷ ❸ ❺ ❹ ❻ From Patient to Doctor © A. Samarin 2018 Architecting digital systems - Module 3 76
  77. 77. Request some patient’s records Doctor Arrange a visit to a doctor Patient Send the requested records to the doctor Patient Receive and file the requested records Doctor Visit Both Send new records to the patient Doctor Receive and file new records Patient Patient private storage Doctor private storage Deposit box Public storage ❶ ❷ ❸ ❺ ❹ ❻ From Doctor to Patient © A. Samarin 2018 Architecting digital systems - Module 3 77
  78. 78. © A. Samarin 2018 Architecting digital systems - Module 3 78 Questions?

×