Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "DB Security, Nov 11, 20031 Database Security S. Sudarshan Computer Science and Engg. Dept I.I.T. Bombay."— Presentation transcript:

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

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

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

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

5 DB Security, Nov 11, 20035 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”!

6 DB Security, Nov 11, 20036 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

7 DB Security, Nov 11, 20037 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

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

9 DB Security, Nov 11, 20039 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

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

11 DB Security, Nov 11, 200311 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

12 DB Security, Nov 11, 200312 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

13 DB Security, Nov 11, 200313 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

14 DB Security, Nov 11, 200314 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!

15 DB Security, Nov 11, 200315 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.

16 DB Security, Nov 11, 200316 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

17 DB Security, Nov 11, 200317 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

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

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

20 DB Security, Nov 11, 200320 Extra Slides

21 DB Security, Nov 11, 200321 Network Security All information must be encrypted to prevent eavesdropping Public/private key encryption widely used Handled by secure http - https:// 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

22 DB Security, Nov 11, 200322 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

23 DB Security, Nov 11, 200323 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)


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

Similar presentations


Ads by Google