investigative powers and power of intervention for dlt ... · investigative powers and power of...

Investigative powers and Power of intervention for DLT applications

Presented by Trevor Sammut

#DLTm

Public DLT/blockchain applications(i) Run over multiple machines (called nodes); (ii) connected in an ad hoc manner; (iii) typically anonymous; (iv) redundant data i.e. blocking a number of machines does not affect it; (v) the network is dynamic (nodes may appear or disappear at will).

Public DLT/blockchain applications(i) Run over multiple machines (called nodes); (ii) connected in an ad hoc manner; (iii) typically anonymous; (iv) redundant data i.e. blocking a number of machines does not affect it; (v) the network is dynamic (nodes may appear or disappear at will).

Public DLT/blockchain applications(i) Run over multiple machines (called nodes); (ii) connected in an ad hoc manner; (iii) typically anonymous; (iv) redundant data i.e. blocking a number of machines does not affect it; (v) the network is dynamic (nodes may appear or disappear at will).

Public DLT/blockchain applications(i) Some of the nodes may be running under Maltese jurisdiction, but not necessarily; (ii) remember that stopping these nodes does not stop the execution of the application.

Maltese jurisdiction

Users of the application(i) May interact by sending transactions to any node; (ii) users are typically also anonymous; (iii) although who the user is may not be known, all transactions to and from a user-address is visible and cannot be modified.

Maltese jurisdiction

Users of the application(i) Users may be operating from Malta or outside; (ii) through a node located in Malta or beyond.

Users of the application(i) For simplicity of use, many DLT applications are accessed via mobile apps or websites; but (ii) this does not stop users from accessing it directly through the DLT; (iii) for these users, the decentralized network can be seen as a monolithic database but which is immune to individual attacks.

Users of the applicationThe server may have access to certain information about access to the DLT application which is normally not available on the DLT nodes themselves e.g. IP address of user. Enforcement here shares options and challenges as when enforcing activity on normal websites. The architecture of any system NEEDS TO BE UNDERSTOOD CAREFULLY first.

MDIA Certified DLT ApplicationsITAs require (i) a Forensic Node in Malta; and (ii) a Technical Administrator based in Malta who is responsible for maintaining and giving access to the forensic node to the relevant authorities.

Maltese jurisdictionForensic nodeTechnical

Administrator

Forensic NodeThe Forensic Node keeps an audit trail of all that is happening on the application be it (i) on the DLT (e.g. transactions); (ii) web site (e.g. IPs of users); (iii) website back-end (e.g. any KYC/AML checks done by the service provider to white list users); and (iv) mobile app (e.g. relevant user interaction).

Maltese jurisdictionTechnical

Administrator Forensic node

Power-of-InterventionThe Forensic Node must also contain the logic to be able (where and when possible) to use the information stored in the node audit trail to intervene when things go wrong (e.g. when a court decides that a certain transaction should be reversed). This can be invoked by the technical administrator. The data must be handed over in a traceable form to investigative authorities (ex: Police). Full details are in the Forensic Node Guidelines by MDIA.

Maltese jurisdictionTechnical

Administrator Forensic node

Investigation and Intervention (I)Keep in mind that intervening on the DLT itself is impossible. Intervening at the website/server-level is also useless since the application can still be accessed by users.

Maltese jurisdictionTechnical

Administrator Forensic node

Investigation and Intervention (II)If the Forensic Node is seized and blocked, the functionality of the DLT application is not impaired, and will proceed nonetheless.

Maltese jurisdictionTechnical

Administrator Forensic node

Investigation and Intervention (III)Even worse, if the Forensic Node is seized and its functionality stopped for investigative reasons, power-of-intervention may be impaired e.g. if an application is performing illegal transactions, and the FN is stopped, information about transactions taking place after would NOT be kept for PoIicing purposes.

Maltese jurisdictionTechnical

Administrator Forensic node

Investigation and Intervention (IV)If the Forensic Node contains multiple copies of the database, certified by the MDIA to be identical, it would suffice to seize one of the servers storing all the data, but allow the Forensic Node to proceed unhindered thus not compromising power-of-intervention.

Maltese jurisdictionTechnical

Administrator Forensic node

Thank YouQ&A

On Scams, User Exploitation, Phishing and the innovative technologies that cybercriminals can employ with criminal intent.

website: https://www.mdia.gov.mt

DLT Guidelines Link: https://mdia.gov.mt/ita-guidelines/

AI Guidelines (Consultation Drafts to be finalised soon): https://mdia.gov.mt/consultation

Email: Trevor.Sammut@MDIA.gov.mt

New Technologies …Different Risks?

Timothy J. ZAMMITInspector of Police

Cyber Crime Unit#DLTm

Never ever have I said or thought …

Updates slowthings down ..

better avoid them!

It will neverhappen to me ..

He’s an expert cos he’s always got the latest smartphone

I don’t need the user manual!

It does what it’s supposed to do .. I

don’t need to know how it works!

If it’s not broken ..don’t change it!!

Case Study: Chain of Events (1)• A computer server is found damaged. ICT support agency believes

that it is a technical fault. Computer server is formatted and a newoperating system is installed.

• Another computer server belonging to same company starts actingsuspiciously. Once again, ICT support agency blames it down to atechnical fault.

• Two other servers indicate an intrusion with files modified ordeleted.

Case Study: Chain of Events (2)• Police are called in after data on servers is restored from back-ups.

• Remaining logs indicate an intrusion. Analysis indicates a commonIP address in two of these instances.

• Information is obtained from ISPs establishes a suspect ..

Case Study: Findings• Suspect is an ex-employee who was recently sacked. Motive is

revenge.

• Login information and passwords were never returned or changed.

• Suspect was authorized to administer all systems remotely.

• Remote access was always available and not monitored.

No policies in place = a recipe for disaster!

Some Examples …

SUPPORT ENDED IN APRIL 2014

SUPPORT ENDED IN JANUARY 2020

A risk based approach

A risk based approach

• How important is this information?

• Why should I protect it?

• Who am I engaging to protect it?

• What technical measures should I put in place?

• Are users informed too?

• What should be done when something goes wrong?

A risk based approach

• Account Settings

• Password policy

• Control over personal data

• Logs and auditing mechanisms

• Updated software (operating system, browsers, etc).

• Updated technical security measures (firewall, anti-virus, etc)

A risk based approach

• What information am I sharing and how can this be used?

• Do you know who you’re dealing with?

• Can information provided be independently verified?

• What remedial action is available?

• Are you aware of the latest risks?

A risk based approach

Thank You For Your Attention

Timothy J. ZAMMITInspector of Police

Cyber Crime UnitMalta Police Force

(+356) 2294 2231 - 2

timothy.zammit@gov.mtcomputer.crime@gov.mt

#DLTm