Database Management Systems Security - PowerPoint PPT Presentation

Loading...

PPT – Database Management Systems Security PowerPoint presentation | free to download - id: 94515-MzA2Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Database Management Systems Security

Description:

Databases solve this problem by handling all data management issues. ... If required, ensure qualified developers are using it in a secure fashion. 20 ... – PowerPoint PPT presentation

Number of Views:58
Avg rating:3.0/5.0
Slides: 35
Provided by: me670
Learn more at: http://higheredbcs.wiley.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Database Management Systems Security


1
Database Management Systems Security
Raval Fichadia John Wiley Sons, Inc. 2007
  • Chapter Nine
  • Prepared by Raval, Fichadia

2
Chapter Nine Objectives
  • Learn the basic concepts of database management
    systems (DBMS) and associated terminology.
  • Understand the risks that impact DBMS and the
    controls to mitigate them.
  • Gain the skills to assess the security posture of
    a database infrastructure and make management
    recommendations.
  • Apply security principles and best practices to a
    database infrastructure.

3
The Big Picture
  • Elements of a database management system.
  • Some risks that impact the DBMS.

4
Database primer
  • Databases collection of related-data in an
    organized fashion that allows for easier access,
    management, and updates.
  • Applications need a place to store data. They
    could do so in application-specific files.
  • Doing so makes it extremely difficult to manage
    especially in keeping data synched across
    applications.
  • Databases solve this problem by handling all data
    management issues.
  • Examples of popular database management systems
    software includes Oracles Oracle DBMS,
    Microsofts SQL Server, and IBMs DB2 system.

5
Database primer
  • Databases collection of related-data in an
    organized fashion that allows for easier access,
    management, and updates.
  • Synchronizing files and updating all
    application-specific files is inefficient.

6
Database primer
  • Databases collection of related-data in an
    organized fashion that allows for easier access,
    management, and updates.
  • Synchronizing files and updating a common source
    is efficient.

7
Database primer
  • Databases Types of databases include
  • Hierarchical DBs that store data in an inverted
    tree form and each parent node has one or more
    child nodes.
  • Network DBs is similar to hierarchical, with no
    parent-child constraints.
  • Relational DBs store data in tabular format in
    rows and columns. Most popular database type.
  • Object-oriented DBs allow storage of binary
    and/or complex data types (BLOBs).
  • Examples of popular database management systems
    software includes Oracles Oracle DBMS,
    Microsofts SQL Server, and IBMs DB2 system.

8
Management concerns
  • Concerns about database system security typically
    include the following
  • Maximizing the database performance and
    availability for business transactions and
    queries.
  • Minimizing data redundancy and standardizing data
    management and access methods.
  • Keeping up with existing and upcoming security
    threats and implementing mitigating controls.
  • Having an effective backup, recovery, business
    resumption and a disaster recovery plan.

9
Risks and Controls
  • Authentication Process of validating a users
    identity to a database.
  • Users (or applications) have to prove their
    identity to the database before being able to
    access data from it.
  • This is typically done via user IDs and passwords
    or via a third-party authentication wherein a
    operating system authenticates a user and the
    database takes the OSs word for the users
    identity.
  • There are several ways that can expose
    authentication credentials.

10
Risks and Controls
  • Authentication risks
  • Default accounts with default passwords are often
    left unprotected by administrators. For example
    Oracle has well-known administrative user account
    sys with a password change_on_install. SQL
    server 6.5 has no password for the administrative
    sa account.
  • Database often have weak password management
    features (when compared to operating systems) in
    that they may not have intruder lockouts,
    periodic password change requirements, etc..
  • Database administrators often use batch scripts
    to perform administrative tasks. Often these
    scripts contain user IDs and password and are
    left unprotected.

11
Risks and Controls
  • Authentication risks
  • Administrators use utilities like
  • Database often have weak password management
    features (when compared to operating systems) in
    that they may not have intruder lockouts,
    periodic password change requirements, etc..
  • Database administrators often use batch scripts
    to perform administrative tasks. Often these
    scripts contain user IDs and password and are
    left unprotected.

12
Risks and controls
  • Authentication risks
  • Administrators use utilities like sqlplus to
    connect to database. UserIDs/passwords used as
    parameters to these utilities may show up in
    process listings which can be viewed by other
    users.

13
Risks and controls
  • Authentication risks
  • Password hashes arent often well secured. For
    e.g. Oracles dba_users view, if unprotected,
    can disclose hashes. SQL server at times stores
    the password hashes in the Windows registry. At
    times, setup and log files have password hashes.
  • Controls
  • Default accounts should have their password
    changed and/or be disabled.
  • Companies should upgrade to newer versions of
    DBMS that have more robust password management
    features.

14
Risks and controls
  • Controls
  • Batch files, setup files or log files should
    either be deleted or protected via stronger ACLs.
  • Administrators should be educated to not pass
    credentials via command line to prevent them
    showing up in process listings.
  • ACLs on tables, views, registries that contain
    password hashes should be tightened and
    periodically reviewed.

15
Risks and Controls
  • Trust relationships DBs can be configured to
    trust operating systems for authenticating users.
  • Companies prefer reducing the number of user IDs
    and passwords a user has to remember.
  • Hence most DBs allow a pass-through
    authentication feature wherein the DB asks the OS
    for the users identity. For example, Oracle
    allows for two types of accounts
  • External account User accounts that have been
    authenticated by the OS. The DB relies on the OS
    for the users identity.
  • Internal account Users that belong to a
    particular group (dba) can access the DB with
    administrative rights. The DB relies on the OS
    to ensure user belongs to administrative group.

16
Risks and controls
  • Trust relationships risks
  • Trusting a client OS is a really bad idea since
    the end user can create any account say
    oracle on the client OS and the DB will trust
    the user to be oracle.
  • Use of Internal account causes a loss of
    accountability since all users access the DB as
    the same account.
  • Controls
  • Company should ensure that DBs rely on a trusted
    OS typically the server OS, not the client OS.
  • Disable the use of Internal account.

17
Risks and Controls
  • Networking within DBs and to OSs Pathways from a
    database to other databases or to operating
    systems.
  • Databases can be linked with other databases so
    that a users can access data from either DBs.
    This is done via links. For example, Oracle
    allows two types of links
  • Public links that allow all users of a DB to
    access the linked DB.
  • Private links that allows only specific users of
    a DB to access the linked database.
  • Databases can also allow users access to the
    operating system hosting the database or
    certain features thereof. For example, SQL server
    has several stored procedures such as
    xp_cmdshell that allows shell access within
    an operating system.

18
Risks and controls
  • Networking within DBs and to OSs risks
  • Links have embedded credentials (with which the
    remote DB is accessed). Views that display these
    are often not secured.
  • Links to OS or DBs allows intruders to explore
    more areas to find weaknesses. The higher the
    privileges of the embedded credentials, the
    greater opportunity for the intruders.
  • Remote databases are accessed via the credentials
    stored with the link. Hence, accountability of
    end users actions is lost.
  • Use of xp_cmdshell features makes the impact of
    SQL injection type attacks much worse (since the
    malicious SQL can now impact not only the DB, but
    the OS also).

19
Risks and controls
  • Controls
  • Company should avoid links as far as possible.
  • If required, private links should be used rather
    than public links.
  • The credentials used to access linked DBs should
    be as minimal as possible.
  • Limit pathways into OS as far as possible. If
    required, ensure qualified developers are using
    it in a secure fashion.

20
Risks and Controls
  • Insecure DB application designs Applications
    often use database as back-end tiers.
  • Databases often store application-related data,
    transaction information, user credentials, etc.
  • If the DB applications arent properly designed,
    the database contents can be compromised.
  • Poor designs can lead to bypass of application
    controls, identity spoofing (impersonation), and
    privilege escalation.

21
Risks and Controls
  • Insecure DB application designs Bypass of
    application controls.
  • Developers often design a client application that
    talks to a back-end database.
  • This client application often has several
    controls embedded in them (edit checks, content
    check, etc.) to ensure that the data reaching the
    DB is proper.
  • However this approach mistakenly assumes a user
    cant talk to the DB directly.
  • Skilled users can submit SQL commands directly to
    the database, leading to a bypass of the controls
    embedded in the client application.

22
Risks and controls
  • Insecure DB application designs Bypass of
    application controls.
  • Relying on front-end GUI for controls is not
    enough.

23
Risks and Controls
  • Insecure DB application designs Identity
    spoofing and privilege escalation.
  • Developers may design a database application
    relies on a the clients operating system to
    establish clients identity (third-party-based
    authentication).
  • This leads to single-sign on users logged onto
    their PCs dont have to re-authenticate to the DB
    application.
  • In addition, the DB application doesnt have to
    program for managing clients user ID and
    passwords.
  • This approach often fails because the clients
    operating system is not trust-worthy end users
    can easily create accounts of their choice on
    their machines.

24
Risks and controls
  • Insecure DB application designs Identity
    spoofing and privilege escalation.
  • Relying on client OS for user credentials is a
    bad idea.

25
Risks and controls
  • Insecure DB application designs SQL injection
    attacks.
  • Applications, typically web-based, with back-end
    databases are susceptible to these attacks.
  • These applications convert user supplied input
    into SQL commands that are processed by the
    database.
  • Attackers can craft special input that make the
    SQL commands malicious in nature.
  • The database processes these malicious SQL
    commands and end up disclosing sensitive data or
    running sensitive database commands.

26
Risks and controls
  • Insecure DB application designs SQL injection
    attack example 1.
  • Consider, a web application, that allows users to
    change their password and asks for following
    inputs
  • UserID pankaj
  • Old password reuse99
  • New password simplify87
  • The resulting SQL executed by the database then
    is
  • UPDATE usertable SET pwd'simplify87' WHERE
  • userid'pankaj'
  • This changes the pwd value in the usertable for
    the user pankaj

27
Risks and controls
  • Input manipulation SQL injection attack example
    1 contd.
  • Now consider, if the user provides the following
    special input
  • UserID pankaj' OR userid 'administrator'--
  • Old password reuse99
  • New password simplify87
  • The resulting SQL executed by the database then
    is
  • UPDATE usertable SET pwd'simplify87' WHERE
  • userid'pankaj' OR userid 'administrator'--'
  • This changes the pwd value in the usertable for
    the user administrator!!
  • (the - - ask the database to ignore any
    characters that follow)

28
Risks and controls
  • Insecure DB application designs SQL injection
    attack example 2.
  • Consider, a web application, that allows users to
    type in a keyword to search a particular product
    type by asking
  • Product keyword antique
  • Say, the resulting SQL executed by the database
    is
  • SELECT product FROM product_table
  • WHERE product_description like antique
  • This query results in showing all products from
    the product_table that have the keyword antique
    in it.

29
Risks and controls
  • Input manipulation SQL injection attack example
    2 contd.
  • Now consider, if the user provides the following
    special input
  • Product keyword antique UNION SELECT
    username, password FROM dba_users WHERE username
    like
  • The resulting SQL executed by the database then
    is
  • SELECT product FROM product_table
  • WHERE product_description like antique
  • UNION SELECT username, password
  • FROM dba_users WHERE username like
  • This results in display user IDs and password
    hashes for all users in addition to the
    products!!

30
Risks and controls
  • Insecure DB application designs risks
  • Intruders can exploit poor application designs to
    bypass controls, spoof identities, escalate
    privileges, and compromise database security.
  • Controls
  • Application developers should be educated in the
    art of design secure applications.
  • Applications that have DB controls built into the
    client portion should ensure end users cant
    directly connect to DBs (typically by obfuscating
    user credentials that are needed to connect to
    the database).

31
Risks and controls
  • Controls contd
  • Application should never rely on third-parties
    that arent controllable and trustworthy.
    Instead, rely on third parties such as server OS
    or domain credentials that arent in users
    control.
  • Protect against SQL injection attacks by
  • Sanitizing user inputs by rejecting known bad
    data/characters, accepting only valid data, and
    cleaning bad data.
  • Not using dynamic SQL. Instead use bind
    variables or parameterized SQL.
  • Minimizing privileges of the database application
    user. This will limit the damage if SQL
    injection succeeds.

32
Assurance considerations
  • An audit to assess database management system
    security should include the following
  • Ensure quality user ID and password management
    techniques are used for databases.
  • Review authentication methods, user accounts and
    their privileges.
  • Assess the patch deployment process. All
    necessary patches for databases are implemented.
  • Ensure that the database applications have
    mechanisms to filter out untrusted user inputs.

33
Assurance considerations
  • Determine the business needs of links between
    databases. Public links should not be used.
  • Evaluate the need and security of all file
    shares.
  • Ensure that functional plans for backup and
    recovery, business resumption, disaster recovery
    are in place.

34
Recap
About PowerShow.com