1. Banking and Bookkeeping
Tyler Moore
CS7403 University of Tulsa
Reading: Anderson Security Engineering, Ch ( )

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

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

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

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

6. World’s 1st Security Protocol? (8500 BC)
“Bookkeeping appears to have started in the Neolithic Middle East in about 8500 BC, just after the invention of agriculture [1122]. When people started to produce surplus food, they started to store and trade it. Suddenly they needed a way to keep track of which villager had put how much in the communal warehouse. To start with, each unit of food (sheep, wheat, oil, . . .) was represented by a clay token, or bulla, which was placed inside a clay envelope and sealed by rolling it with the pattern of the warehouse keeper. (See Figure 10.1.) When the farmer wanted to get his food back, the seal was broken by the keeper in the presence of a witness. “

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

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

9. Bookkeeping Computer Systems
By 1960s-70s, banks automated most back-office operations on computer systems (check processing, payroll services, bank account transaction management)
Most systems attempt to implement double-entry 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

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

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

12. 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 UC Davis

13. Slides from Matt Bishop @ UC Davis
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 UC Davis

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

15. Certification Rules 1 and 2
CR1 When any IVP is run, it must ensure all CDIs are in a valid state
CR2 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
Slides from Matt UC Davis

16. Slides from Matt Bishop @ UC Davis
Enforcement Rules 1 and 2
ER1 The system must maintain the certified relations and must ensure that only TPs certified to run on a CDI manipulate that CDI.
ER2 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)
ER1 example: prohibit any changes to bank balances that are not part of a TP
ER2 example: any changes to bank balances via TP must be associated with a user who carried out the TP
Slides from Matt UC Davis

17. Slides from Matt Bishop @ UC Davis
Users and Rules
CR3 The allowed relations must meet the requirements imposed by the principle of separation of duty.
ER3 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)
CR3: not possible to carry out TPs by one user alone
Slides from Matt UC Davis

18. Slides from Matt Bishop @ UC Davis
Logging
CR4 All TPs must append enough information to reconstruct the operation to an append-only CDI.
This CDI is the log
Auditor needs to be able to determine what happened during reviews of transactions
Slides from Matt UC Davis

19. Handling Untrusted Input
CR5 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. TPs must validate numbers (to make them a CDI) before using them; if validation fails, TP rejects UDI
Slides from Matt UC Davis

20. Separation of Duty In Model
ER4 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
Separate roles of certifier and executor
Slides from Matt UC Davis

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

22. Slides from Matt Bishop @ UC Davis
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
Slides from Matt UC Davis

23. Slides from Matt Bishop @ UC Davis
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
Slides from Matt UC Davis

24. Slides from Matt Bishop @ UC Davis
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
Slides from Matt UC Davis

25. 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
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
Slides from Matt UC Davis

26. Clark-Wilson Discussion
Unlike Bell-LaPadula, 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

27. Clark-Wilson Discussion
Doesn’t deal with insider threat (dishonest staff)
CR3 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

28. Designing Internal Controls
2 ways to implement separation of duty policy
Dual control
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

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

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

31. 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 $20M 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

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