Security threats exist against your data warehouse (DW), whether it is accessible through the Internet or buried deep within your internal network and available only to authorized users. The increasing prevalence of Web-enabled applications accessing the DW compounds this threat by spanning the enterprise infrastructure and the Internet. Vendors supplying applications for DW environments are being pressured by users to quickly provide more functionality and performance to the marketplace, outpacing the competition while sacrificing security. Do you really think your DW implementation is still secure?
This is the first of a three-part series on security vulnerabilities in the DW environment. This installment discusses the origination of security risks, and subsequent columns will examine actual exploit types and measures that can be applied to increase the security and minimize your risk of exposure.
One common misconception is that security attacks originate from outside of the company or DW environment. Not all security threats originate from outside hackers. Consider, for example, the following two possible scenarios:
1. A department manager logs onto the corporate intranet site to review time and attendance (T&A) reports from the corporate data warehouse for his particular department. He navigates to the month-end T&A summary and selects the particular report for execution. After a few seconds, the report appears in his browser with data pre-selected based on his logon ID. The returning URL contains a long string of mixed characters and numbers. Through simple decoding of this string, the manager's user ID and report number are extracted. Through systematic trial and error, the manager substitutes the user ID of the business unit's vice president, a different report ID number and encodes them into the string portion of the URL. The eventual returning report displays the vice president's view of the current month-end revenue sharing forecast showing the manager, his manager and their peers' information.
2. A user logs onto to his personal account on a financial Web site. The user selects access to his personal account summaries. The user is challenged by the site to enter valid authentication information. The user enters his personal ID and password, which allows him to access the summary section of the site. The user selects a summary of preceding month's activity for his account. The site returns with the listing showing account transactions. The browser's URL address shows a long directory path name from the Web server, an execution query string and a numeric filename and extension. Through systematic substitution of the filename with alternate number strings, the user is able to obtain account summaries and other personal information for other users of the site. Through further URL manipulation and testing, the user is eventually able to retrieve a listing of all processed summary reports for all users stored on the Web server.
Many DW administrators believe that properly controlling and maintaining user and access privileges of the DW applications alone will provide adequate security. Commonly, these applications, built or bought, were evaluated primarily on the basis of providing functionality and performance, not security. For example, some DW applications still employ encoding techniques in their URL strings and/or header variables to prevent unauthorized access. Encoding methods, such as base64, do not provide the same security as encrypting and can easily be reverse-engineered to reveal contents. Another example is delivery applications that allow DW information to exist in a persistent state on the hard drives of a Web server as an unencrypted cache or temporary file. This data is used to increase performance response of recurring user requests to the warehouse at the expense of security. This also applies to the supporting components of the infrastructure (Web, application and database servers) which are interconnected to the warehouse environment. These components are shipped to provide the most functionality out of the box, not necessarily the most security. This presents other possible avenues of exploitation to your DW environment and its information resource unless configurations are modified to maximize security.
Often, the groups in a company that are qualified to evaluate application and infrastructure implementations for security are excluded from the decision process until the DW is about to go into production. In the best case, this can lead to delays in warehouse implementation or redesign of front-end delivery methods due to security risks. Worst case, due to insufficient time for security analysis, implementations go live without fully recognizing the possible compromise that has been made to corporate or personal information from the warehouse. Even if your DW implementation has been through an internal or external security vulnerability assessment, any change to any underlying component requires notification to appropriate support personnel for analysis of the component modification and possible effect to the overall infrastructure. Increasing use of portals, XML, messaging, Web services and wireless in data warehouse applications will provide additional points of possible exploit against this information.
Today, DW environments face an increasing threat of possible security exploits. The use of Web applications and complex infrastructures makes elimination or mitigation of these security exploits more difficult. Evaluations of DW applications, bought or built, need to consider security features at the same level as functionality and performance features.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access