Banking and Bookkeeping Tyler Moore CS 44136013 The

Banking and Bookkeeping Tyler Moore CS 4413/6013 The University of Tulsa Reading: Anderson Security Engineering, Ch. 10. 1 -10. 2 (313 -328) 1

Agenda • • • Why study banking systems? Bookkeeping principles Bookkeeping computer systems Clark-Wilson model Designing internal controls 2

Why study banking systems? • Banking systems include – ATM networks – Payment card processing systems – Interbank money transfer systems – Back-end bookkeeping systems 3

Why study banking systems? • Secure transaction processing is a prerequisite for secure e-commerce – Internal controls must often be enforced by information security policies and mechanisms – Regulations emanating from Gramm-Leach-Bliley and Sarbanes Oxley drive information security budgets in the private sector • Accounting has long been the computer industry’s “killer app” – Integrity and immutability of records matter more than confidentiality 4

Why study banking systems? • Transaction processing systems launched the commercial application of cryptography – Instructive mistakes first documented here – Interface between crypto and access control first studied here (in the open research community) • Banking systems require multilateral security aimed at authenticity, not confidentiality – Systems must prevent customers from cheating each other or the bank – Must prevent employees from cheating customers or bank – Evidence collected via audit trails must be robust 5

World’s 1 st Security Protocol? (8500 BC) 6

Double-Entry Bookkeeping • 2 books – Enter transaction as credit in one, debit in other • Example – Suppose firm sells $100 widget on credit – Posts $100 credit to Sales account, $100 debit to Receivables account – When customer pays, credit Receivables, debit Sales account – End of the day, the books should zero out • Books should be held by different clerks and must balance periodically 7

Security Implications of Double-Entry Bookkeeping • Let’s say a cashier wants to skim off the till – If the sales account is maintained separately (or in a computer program at the point-of-sale), then theft can be detected – Theft only works if there is collusion between both accounts • Implements separation of duty policy – Outside audits can identify collusion 8

Bookkeeping Computer Systems • By 1960 s-70 s, banks automated most back-office operations on computer systems (check processing, payroll services, bank account transaction management) • Most systems attempt to implement doubleentry bookkeeping – User interface – Underlying files may not have integrity controls – Even if they are, what might a root user do? • Laws mandate internal controls, which prompts security investments 9

Bank System Data Structures • Account master file: customer balance and recent transactions • Ledgers: track cash and assets moving through • Journals: hold transactions received from tellers, ATMs, etc. • Audit trail: records which staff did what when • Batch processing systems periodically move entries into journals to ledgers and to account master files • Ledgers must zero-balance 10

How to enforce bookkeeping goals? • Under conventional mandatory access control, systems enforce classification policies – Data: unclassified, top secret – Bell-La. Padula: No read up, no write down • But bookkeeping systems must enforce different rules – Separation of duty – Ledgers must zero-balance – Reliable audit trail

Clark-Wilson Integrity Model • Integrity defined by a set of constraints – Data in a consistent or valid state when it satisfies these • Example: Bank – D today’s deposits, W withdrawals, YB yesterday’s balance, TB today’s balance – Integrity constraint: TB = D + YB –W • Well-formed transaction move system from one consistent state to another • Issue: who examines, certifies transactions done correctly? Slides from Matt Bishop @ UC Davis 12

Entities • UDIs: unconstrained data items – Data not subject to integrity controls • CDIs: constrained data items – Data subject to integrity controls • IVPs: integrity verification procedures – Procedures that test the CDIs conform to the integrity constraints • TPs: transformation procedures – Procedures that take the system from one valid state to another Slides from Matt Bishop @ UC Davis 13

Entities for Bookkeeping Example • UDIs: unconstrained data items – Untrusted user input such as a bank deposit amount • CDIs: constrained data items – Bank account balances • IVPs: integrity verification procedures – Audit function, in which balances are checked and compared against external records • TPs: transformation procedures – Double entry bookkeeping procedure 14

Certification Rules 1 and 2 CR 1 When any IVP is run, it must ensure all CDIs are in a valid state CR 2 For some associated set of CDIs, a TP must transform those CDIs in a valid state into a (possibly different) valid state – Defines relation certified that associates a set of CDIs with a particular TP – Example: TP balance, CDIs accounts, in bank example UDI: unconstrained data items CDI: constrained data items IVP: integrity verification procedure Slides from Matt Bishop @ UC Davis TP: transformation procedure 15

Enforcement Rules 1 and 2 ER 1 ER 2 The system must maintain the certified relations and must ensure that only TPs certified to run on a CDI manipulate that CDI. The system must associate a user with each TP and set of CDIs. The TP may access those CDIs on behalf of the associated user. The TP cannot access that CDI on behalf of a user not associated with that TP and CDI. – System must maintain, enforce certified relation – System must also restrict access based on user ID (allowed relation) UDI: unconstrained data items CDI: constrained data items IVP: integrity verification procedure TP: transformation procedure Slides from Matt Bishop @ UC Davis 16

Users and Rules CR 3 The allowed relations must meet the requirements imposed by the principle of separation of duty. ER 3 The system must authenticate each user attempting to execute a TP – Type of authentication undefined, and depends on the instantiation – Authentication not required before use of the system, but is required before manipulation of CDIs (requires using TPs) UDI: unconstrained data items CDI: constrained data items IVP: integrity verification procedure TP: transformation procedure Slides from Matt Bishop @ UC Davis 17

Logging CR 4 All TPs must append enough information to reconstruct the operation to an appendonly CDI. – This CDI is the log – Auditor needs to be able to determine what happened during reviews of transactions UDI: unconstrained data items CDI: constrained data items IVP: integrity verification procedure TP: transformation procedure Slides from Matt Bishop @ UC Davis 18

Handling Untrusted Input CR 5 Any TP that takes as input a UDI may perform only valid transformations, or no transformations, for all possible values of the UDI. The transformation either rejects the UDI or transforms it into a CDI. – In bank, numbers entered at keyboard are UDIs, so cannot be input to TPs must validate numbers (to make them a CDI) before using them; if validation fails, TP rejects UDI: unconstrained data items CDI: constrained data items IVP: integrity verification procedure TP: transformation procedure Slides from Matt Bishop @ UC Davis 19

Separation of Duty In Model ER 4 Only the certifier of a TP may change the list of entities associated with that TP. No certifier of a TP, or of an entity associated with that TP, may ever have execute permission with respect to that entity. – Enforces separation of duty with respect to certified and allowed relations UDI: unconstrained data items CDI: constrained data items IVP: integrity verification procedure TP: transformation procedure Slides from Matt Bishop @ UC Davis 20

Visual Representation of Integrity Rules Clark, David D. ; and Wilson, David R. ; A Comparison of Commercial and Military Computer Security Policies; in Proceedings of 21 the 1987 IEEE Symposium on Research in Security and Privacy (SP'87), May 1987, Oakland, CA; IEEE Press, pp. 184– 193

UNIX Implementation • Considered “allowed” relation (user, TP, { CDI set }) • Each TP is owned by a different user – These “users” are actually locked accounts, so no real users can log into them; but this provides each TP a unique UID for controlling access rights – TP is setuid to that user • Each TP’s group contains set of users authorized to execute TP • Each TP is executable by group, not by world UDI: unconstrained data items CDI: constrained data items IVP: integrity verification procedure TP: transformation procedure Slides from Matt Bishop @ UC Davis 22

CDI Arrangement • CDIs owned by root or some other unique user – Again, no logins to that user’s account allowed • CDI’s group contains users of TPs allowed to manipulate CDI • Now each TP can manipulate CDIs for single user UDI: unconstrained data items CDI: constrained data items IVP: integrity verification procedure TP: transformation procedure Slides from Matt Bishop @ UC Davis 23

Examples • Access to CDI constrained by user – In “allowed” triple, TP can be any TP – Put CDIs in a group containing all users authorized to modify CDI • Access to CDI constrained by TP – In “allowed” triple, user can be any user – CDIs allow access to the owner, the user owning the TP – Make the TP world executable UDI: unconstrained data items CDI: constrained data items IVP: integrity verification procedure TP: transformation procedure Slides from Matt Bishop @ UC Davis 24

Problems with UNIX Implementation • 2 different users cannot use same copy of TP to access 2 different CDIs – Need 2 separate copies of TP (one for each user and CDI set) • TPs are setuid programs – As these change privileges, want to minimize their number – See https: //en. wikipedia. org/wiki/Setuid • root can assume identity of users owning TPs, and so cannot be separated from certifiers – No way to overcome this without changing nature of root UDI: unconstrained data items CDI: constrained data items IVP: integrity verification procedure TP: transformation procedure Slides from Matt Bishop @ UC Davis 25

Clark-Wilson Discussion • Unlike Bell-La. Padula, CW maintains state – Audit logs – To enforce dual control, must keep record of partially completed transactions in special file – So user info is now security state, expanding TCB • CW model is incomplete – Transformations must respect invariants (e. g. , balancing), but no protection against transfers to the wrong account 26

Clark-Wilson Discussion • Doesn’t deal with insider threat (dishonest staff) – CR 3 mandates separation of duty, but doesn’t specify how to achieve this – Design of internal controls matters, but these are expected as input to the model – Internal control design is hard and must evolve with changing systems and experiences of fraud 27

Designing Internal Controls • 2 ways to implement separation of duty policy 1. Dual control 2. Functional separation • Dual control: 2 or more staff must act together to authorize transaction – Nuclear C&C, also bank letters of guarantee • Functional separation: 2 or more staff act on a transaction at different points in its path – Corporate purchasing 28

Prevent-Detect-Recover • If detection is hard (or slow), then recovery may be hard. So emphasis should be made on prevention – Ex: using dual control to prevent corrupt bank guarantees • If prevention is hard, then detection should be fast and recovery feasible, in order to deter – Ex: bank tellers can always steal cash, so count money daily and identify who’s responsible 29

Implementing Dual Control • In theory, use crypto – Split signing keys among 2 or more users • In practice: end-to-end dual control is hard – Many system interfaces have single points of failure – Split-responsibility system administration can be tedious – Most sysadmins can carry out fraud, so focus on quick detection and recovery mechanisms – Also: minimize the number of sysadmins and pay them well 30

What Goes Wrong • Most frauds are carried out by insiders • Some examples not named Snowden – Password reset clerk at HSBC conspired to reset AT&T’s account password and sent $20 M offshore – Bank’s “suspense” accounts of unreconciled transactions trigger investigation after 3 days if non-zeroed; employee zeroed accounts by crediting boyfriend’s accounts; undetected for years 31

Lessons Learned [Anderson] • It’s not always obvious which transactions are security sensitive • Maintaining a working security system can be hard in the face of a changing environment • If you rely on customer complaints to alert you to fraud, you had better listen to them • There will always be people in positions of relative trust who can get away with a scam for a while • No security policy will always be completely rigid. There will always have to be workarounds for people to cope with real life • These workarounds naturally create vulnerabilities. So the lower the transaction error rate, the better 32