DB Security, Nov 11, Database Security S. Sudarshan Computer Science and Engg. Dept I.I.T. Bombay

DB Security, Nov 11, Database Security Database Security - protection from malicious attempts to steal (view) or modify data.

DB Security, Nov 11, Importance of Data in Databases Bank/Demat accounts Salary Income tax data Credit card University admissions, marks/grades

DB Security, Nov 11, Levels of Data Security Human level: Corrupt/careless User Network/User Interface Database application program Database system Operating System Physical level

DB Security, Nov 11, Levels of Security Outside of Database Physical level Traditional lock-and-key security Protection from floods, fire, etc. Remote backup for disaster recovery Operating system level Operating system administrators (also known as super-users) can do anything they want to the database! Good operating system level security is required Windows viruses allow intruders to become “super- users”!

DB Security, Nov 11, Security (Cont.) Network level: must use encryption to prevent Eavesdropping: unauthorized reading of messages Masquerading:  pretending to be an authorized user or legitimate site, or  sending messages supposedly from authorized users

DB Security, Nov 11, Security at the Database/Application Program Authentication and authorization mechanisms to allow specific users access only to required data Authentication: who are you? Prove it! Authorization: what you are allowed to do

DB Security, Nov 11, Database vs. Application Application authenticates/authorizes users Application itself authenticates itself to database Database password Database Application Program

DB Security, Nov 11, User Authentication Password Most users abuse passwords. For e.g.  Easy to guess password  Share passwords with others Smartcards Need smartcard + a PIN or password Bill Gates

DB Security, Nov 11, Authorization Different authorizations for different users Accounts clerk vs. Accounts manager vs. End users

DB Security, Nov 11, Authorization Forms of authorization on (parts of) the database: Read authorization - allows reading, but not modification of data. Insert authorization - allows insertion of new data, but not modification of existing data. Update authorization - allows modification, but not deletion of data. Delete authorization - allows deletion of data

DB Security, Nov 11, Application Authorization Applications authenticate end users and decide what interfaces to give to whom Screen level authorization Central authentication systems allow users to be authenticated centrally LDAP often used for this Single sign-on: authenticate once, and access multiple applications without fresh authentication Microsoft passport, PubCookie etc

DB Security, Nov 11, Application Security Applications are often the biggest source of insecurity Poor coding of application may allow unauthorized access Application code may be very big, easy to make mistakes and leave security holes

DB Security, Nov 11, Insider vs. Outsider Attack Most people worry about outsider attack Most organizations are also highly vulnerable to insider attacks E.g. Indira Gandhi Luckily most programmers are honest souls!

DB Security, Nov 11, Almighty Application Programmers/Administrators Have password to database, can update anything! Digital signatures can help in some situations  E.g. low update rate data such as land records, birth/death data More people with access  more danger Application program has database password Anyone who manages to seize control of the application programme can do anything to the database.

DB Security, Nov 11, Dealing with Insider Attacks Audit trails: record of all (update) activity on the database: who did what, when Database needs to ensure these can’t be turned off, and turned on again after doing damage Supported by most commercial database systems Sys-admin should periodically review audit trail Don’t give database password to development team, keep it with a few system administrators Multiple copies for security

DB Security, Nov 11, Anecdotes SQL/Slammer Attacked SQLServer, brought our network down, luckily no data lost/stolen Database security workshop at IIT Bombay Careless coding exposed database password to outside world Academic office application at IIT Bombay Working on “check-sum” technique to ensure grades/marks are not changed Database will accept requests only from machine running application programme Other security loopholes no doubt exist

DB Security, Nov 11, Summary Data security is critical Requires security at different levels Several technical solutions But human training is essential

DB Security, Nov 11, Acknowledgments Pictures in this talk stolen from various web sources!

DB Security, Nov 11, Extra Slides

DB Security, Nov 11, Network Security All information must be encrypted to prevent eavesdropping Public/private key encryption widely used Handled by secure http - Must prevent person-in-the-middle attacks E.g. someone impersonates seller or bank/credit card company and fools buyer into revealing information  Encrypting messages alone doesn’t solve this problem  More on this in next slide

DB Security, Nov 11, Site Authentication Digital certificates are used to prevent impersonation/man-in-the middle attack Certification agency creates digital certificate by encrypting, e.g., site’s public key using its own private key  Verifies site identity by external means first! Site sends certificate to buyer Customer uses public key of certification agency to decrypt certificate and find sites public key  Man-in-the-middle cannot send fake public key Sites public key used for setting up secure communication

DB Security, Nov 11, Secure Payment Three-way communication between seller, buyer and credit-card company to make payment Credit card company credits amount to seller Credit card company consolidates all payments from a buyer and collects them together  E.g. via buyer’s bank through physical/electronic check payment Several secure payment protocols E.g. Secure Electronic Transaction (SET)