KEEP YOUR DATA SAFE


vulnerabilities at the code level. One approach to prevent vulnerabilities is to


have a professional code review of your software to identify and address coding security issues when it’s possible, especially if you developed the application in-house. Many times, legacy applications are being used, so it’s almost impossible to change anything. Of course, reviews are only as good as the reviewers, and no one should ever review their own code. It’s much too easy to overlook – or hide – one’s own mistakes. An additional and important approach is to


update all the applications in use and to harden your web and database servers. For example, one Oracle update release included 78(!!) security updates. Another option is to use a signature-based approach to spot and then quarantine this kind of attacks. Each application level attack has a “signature” or typical way of operating that identifies it. A comparison of web-application firewalls (WAF) shows that some are more effective than others, but none is perfect.


The Database Level Concerns in the online gaming and casino industry revolve around handling customers’ private details and compliance with PCI/DSS. Databases are the core of your business, one of your most important assets. The database level is most critical as it is vulnerable not only to external threats but also to threats from those you know and trust. Most companies have at least three databases or at least three types of information in databases: financial information, employee information and customer information. Many times we mistakenly don’t think of what the database contains and don’t take into consideration the layers that are part of the database. The database is a very smart application, but it’s still an application running on an operating system. The operating system includes an endless number of attack vectors, such as file sharing, remote desktop and access, and third-party applications. If any of these attack vectors are exploited all your information will be stolen. You won’t even know it just by viewing the database logs. You have to see the full picture.


One of the main issues is being able to grant


access to database administrators (DBAs), developers and QA engineers without access to core sensitive data. The developers need to have the system up and running, but they shouldn’t have privileges to view highly sensitive business and customer data. In today’s world, the line between employees and outside contractors is often blurred, and many employees are only conditionally loyal to their organizations. Furthermore, intentional attacks can come


from outside, but through existing users. Weak and reused passwords and incorrect database configuration can result in outside access. For example, some of the popular databases contain default users and administrators with default passwords. If such default settings are not changed on installation, an attacker can gain inside access and use it for additional types of access if separation of duties is not appropriately enforced. One online gaming company is working with a specific outsourced contractor because the company is an industry leader, even though the same contracting firm is being used by a direct competitor. What happens without security in that situation?


need to grant access to partial data while masking sensitive columns so the programmers and DBAs can do their jobs. You’ll also need to be able to audit the system to identify any unusual behavior. Properly defined and enforced separation of


duties provides safeguards against a variety of security breaches and potential data leaks in organizations. It’s important to distinguish the different roles:


• The person in charge of separation of duties • Developers and programmers • Database administrators • Quality assurance personnel • Operating system administrators • Network and security administrators • Contractors


Duties can be separated by creating:


Protection against Internal Threats


Separation of Duties: Real


Separation of duties is essential for anyone who is using the database within your organization. Separation of duties as a front end to databases allows you to assign appropriate privileges so that anyone with access to a database can perform his specific roles and those roles only. Lack of separation of duties allows users with some level of access to a database to perform functions they would not normally be allowed to do, such as copying large amounts of data, which could ultimately be removed from the organization. A DBA should be able to perform only administrative tasks without the option to retrieve sensitive information, and vice versa; the application developer should have the option to view data structures and masked data but should never have the option to execute administrative commands. You’ll need to limit access to specific sensitive columns and block commands from database users. You’ll also


• Users and user groups • Access method: apps, direct commands, etc. • Masking rules • Commands allowed for specific types of user • Commands allowed by type of commands • Times and days when access is allowed • Source of request: specific IP addresses, within network, etc. • Source of application: specific application name allowed.


Overall Requirements This translates into the following security


system requirements: dynamic data masking protection against SQL injection complete compliance and auditing features. Your security system must be easy to deploy and use, while being completely scalable and not interfering with the user experience. Of course, having minimal IT support requirements would be an added bonus. To make sure your information assets are


protected, your best bet is to use an integrated database security solution that is non- disruptive to existing software and databases, and provides extensive management reporting and audit trails, all without degrading responsiveness to users. You can find effective security protection at a reasonable price. Just make sure you do your homework.


JULY/AUGUST 2013 53


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60  |  Page 61  |  Page 62