Architecting digital systems security

Architecting
digital
systems
Module 3
Security
Alexander Samarin

– 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

• 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.
Security basics (1)

• 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]
Security basics (2)

• 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]
Security basics (3)
More generic
concept is
necessary in
the digital age

• 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
Security basics (4)

Big picture:
security
Attack
Vulnerability
Asset
can succeed or
exploit
has consequence on
Threat causes
Security
Harm
causes

• 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]
Risk basics (1)

• risk assessment
– process of identifying, estimating, and prioritizing information
security risks [NIST Special Publication 800-30 Revision 1, fig 2]
Risk basics (2)

• 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)
Risk basics (3)

• 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.
Risk basics (6)

• 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]
Risk basics (7)

• 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).
Risk basics (8)

• 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).
Risk basics (9)

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

• 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]
Risk assessment dependencies
Adverse impact is system-of-interest dependent and very difficult to objectively
evaluate

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
Business processes
Services
Outcomes
Objectives
slow down
underperforming
missing
exposing to
Digital system architecture
helps to evaluate adverse
impact for each asset (least
granular and composite)

Security services classification (1)

Security services classification (2)

Security services reality

• 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
Information security basics (1)
[SOURCE: IEC Guide 120]

• [NIST 800-160]

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

Example of dependences
Threats (yellow) vs attacks (blue)

Risk management basics

Multi-tiered risk management

• [NIST Special Publication 800-39, fig 3]
Tier two risk assessment —mission/business
process view

• 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.
Risk management standards

mission &
business
needs
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
…

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
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]

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.
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]

• NIST draft cybersecurity framework
– 23 Category
– 107 Sub-categories
– 401 fragments from many international and industry standards
There is an enormous amount of good
information about security

• 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
Example: security and safety

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/

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)
ISO/IEC Guide 51

• resilience
– the capacity to recover quickly from difficulties; toughness.
Resilience
Expected
capacity
loss
Recovery time

• 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?
Improving security (1)

Attack
Vulnerability
Least granular
assets
Riskscan succeed or
exploit
has consequence on
Threat causes
Security
impact x
likelihood
Harm
causes
has
Adverse
Impact
Likelihood
Business processes
Services
Outcomes
Objectives
slow down
underperforming
missing
exposing to
helps to evaluate adverse
impact for each asset (least
granular and composite)

• 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
security measureResidual risk
Widely acceptable risk Acceptable risk Unacceptable risk

• 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

• 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
Systems approach to security (5)

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

• 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

• 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

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

• 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

Separate networking zones

• Services for actors (people, organisation, groups, tools)
– enrolment
– authentication (confirmation of claims)
– identification (not mandatory)
– and everything else from their life cycle
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

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

• 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
• ….
Various roles

Some security-related concepts

• 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”
Example:
security for IoT devices (1)

• 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
Example:

• 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
Example:

• 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
Example:

• 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
Example:

• Use business processes to invoke security and risk
controls
Advantages of explicit and machine-
executable business processes (1)
Risk monitoring
and evaluation
Risk mitigation
Normal operations

• Risk must be carefully monitored, evaluated and acted
upon with the pace of business processes
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.

Do something
• Align access rights with the dynamic of work to be done
Grant necessary
rights to a person
who will carry out
this activity to
access involved
business objects
Revoke
previously
granted
rights

• Align security of a business object (e.g. an organisational
document) with the work progress (preparation of this
document)
Personal
version
Committee
review
Management
approval
Group
drafting
Private Confidential Secret Top-secret Public

Responsible Accountable
Consulted Informed
• Static separation of duties (the same person must not
carry out “DO” and “VALIDATE”)

• 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”
Activity A
Activity B
Carry out the work
Carry out the work
Validating the
work
Role 1
Role 2

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

• 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.
EU GDPR overview (2)
http://www.theinquirer.net/inquirer/analysis/3005509/gdpr-how-to-prepare-your-business-for-incoming-eu-data-laws

• 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
How to satisfy the “privacy” requirement

• 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
Improve GDPR for the digital age

• blockchain
– multi-sourced (many owners of information) and
– distributed (many owners of data-set copies) record storage with
– excellent level of integrity and availability
About blockchain (1)

• 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

• 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

• 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?
Blockchain from the system point of view (1)

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

• 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

• 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.
Electronic Health Records (EHR)
implementation

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

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

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

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

Questions?

Architecting digital systems security

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Architecting digital systems security

Semelhante a Architecting digital systems security (20)

Mais de Alexander SAMARIN

Mais de Alexander SAMARIN (20)

Último

Último (20)

Architecting digital systems security

Notas do Editor