Investigative powers and Power of intervention for DLT applications #DLTm Presented by Trevor Sammut
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.
Users of the application (i) Users may be operating from Malta or outside; (ii) through a node located in Malta or beyond. Maltese jurisdiction
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 application The 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 Applications ITAs 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. Technical Forensic node Administrator Maltese jurisdiction
Forensic Node The 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). Technical Forensic node Administrator Maltese jurisdiction
Power-of-Intervention The 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. Technical Forensic node Administrator Maltese jurisdiction
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. Technical Forensic node Administrator Maltese jurisdiction
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. Technical Forensic node Administrator Maltese jurisdiction
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. Technical Forensic node Administrator Maltese jurisdiction
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. Technical Forensic node Administrator Maltese jurisdiction
Email: Trevor.Sammut@MDIA.gov.mt Thank You Q&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
New Technologies … Different Risks? Timothy J. ZAMMIT Inspector of Police Cyber Crime Unit #DLTm
Never ever have I said or thought … Updates slow If it’s not broken .. It will never things down .. don’t change it!! happen to me .. better avoid them! It does what it’s He’s an expert cos supposed to do .. I I don’t need the he’s always got the don’t need to know user manual! latest smartphone how it works!
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 new operating system is installed. • Another computer server belonging to same company starts acting suspiciously. Once again, ICT support agency blames it down to a technical fault. • Two other servers indicate an intrusion with files modified or deleted.
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 common IP 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
Timothy J. ZAMMIT Inspector of Police Cyber Crime Unit Malta Police Force (+356) 2294 2231 - 2 timothy.zammit@gov.mt computer.crime@gov.mt #DLTm Thank You For Your Attention
Recommend
More recommend
