Institutional Investors Technology

1
Institutional Investors Technology Operations
ForumSecuring Master and Reference Data

• Michael Feldman
• Data Rite Systems Group

2
Why is Securing Data Important?

• Securing Infrastructure is not enough. Must go to
  the data level
• Mandatory disclosure laws are becoming more
  prevalent.
• Spending for IT security has decreased
• Not enough to stay one step ahead of the bad
  guys. Not appropriate to be in siege mode
• Reduce Audit obligations

3
Old Model Vs. New

• Defensive
• Manual Audit
• Securing Infrastructure

• Secure from start
• Automated Audit
• Secure Data

4
What is Master Data?

• Data that is central to an organizations
  operation.
• Data that is central to a relational database.
• For example
• Fund performance data
• Investor return data
• Investor statement data

5
What is Reference Data?

• Lookup tables
• Data that is connected to Master Data via
  relationships
• For example
• State table lookup
• Fund lookup
• Partner Lookup

6
Can they overlap?

• Master Data from one system can become Reference
  Rata in another system. (i.e., master data in a
  portfolio management system can become reference
  data in a reporting system.)
• Data can be exported from one system to another
  and the usage may vary between the two systems.
• The line between Master Data and Reference Data
  becomes blurred.
• Both are related and of equal importance.

7
What is meant by Data Security?

• Anything that leads to data being placed in a
  compromised situation
• Stolen Data
• Corrupted Data
• Unrecoverable data
• Inoperable data
• Data Integrity

8
Where do most breaches occur?

• In the age of intrusion detection, firewalls,
  complex passwords, card key security, how does
  data become insecure?
• Most financial applications are not compromised
  from the outside, they are the result of theft
  or embezzlement.
• According to OWASP (Open Web Application Security
  Project,) over 75 of data violations are inside
  jobs from employees or vendors.

9
How does data become insecure?

• Accidental data integrity violations.
• Vendors failing to lock down databases.
• Poor change management control.
• Bad database practices.
• Too many sources pulling from databases.
• Reference tables are directly accessed to create
  and modify data.
• Lack of or insufficient disaster recovery.
• Failure to test disaster recovery.
• Insufficient physical server security.
• Third-party add-ons.
• Poor database design

10
Common bad security practices

• Certain types of database queries require more
  open access to the database.
• Vendors often leave databases wide open in terms
  of security and rely on the organization to lock
  them down.
• Third-party add-ons often access data directly in
  the master database rather than a copy of the
  database.
• Allowing unbridled access to import/export tools,
  and ad-hoc query tools.
• The access in a hurry syndrome. Administrative
  rights are granted to fight a fire and never
  removed.
• Lack of encryption and identity management
• Lack of company policy. Who owns the data?

11
Reference data integrity

• Many organizations allow direct access to
  reference tables via querying utilities (i.e.,
  the knowing enough to be dangerous syndrome)
• Access to data via screens that were never set up
  to grant user access.
• Addition/Modification/Deletion of reference data
  can break data relations.
• Reference data is often seen as less important,
  but it can do serious damage as primary and
  foreign key relations can be broken. (i.e.
  integrity between master and reference data)

12
Common bad database practices

• Creating databases without proper key structure
  or any form or DRI.
• Creating a data structure that does not check for
  data integrity.
• For example a trade amount field may allow
• 1,200,000
• 1.2m
• 1,200k
• Failure to use encryption for sensitive data.
• Lack of change management controls.
• Lack of data audit logs.

13
Third-Party Tools

• Many organizations add-on to vendor
  applications and engage third-party consultants.
• Data must never be touched in the master
  database. Relevant tables should be exported out
  to a work database.

14
Physical security concerns

• Recently, a fund administrator had their backup
  tapes stolen en-route to their DR site.
• An OWASP study found that over 60 of the server
  rooms lacked proper air conditioning, locks and
  access levels.
• Tapes go bad! Over 30 of critical data restores
  from tapes fail.

15
What is to be done?

• Verify your data structure for soundness.
• Lock down the data as much as possible without
  hampering the business (taking small steps
  recommended).
• Only allow access to data from front-end programs
  (i.e., web pages or windows applications). No
  direct access to the data!
• Practice data restore of your database once a
  quarter.
• Put an Audit Log tool in place.
• Task someone in the organization as the database
  security expert. They should control security and
  change management, oversee vendors and
  third-party tools, and monitor for security
  trends.
• An independent audit of data create queries to
  check integrity.
• Use an online storage facility instead of tapes.
• Replicate database data real time to another
  facility.
• Encryption and identity management!

16
Thank You

• For more information
• Mike_at_dataritesys.com
• www.dataritesys.com
• 212 697-0207 x201