Business Intelligence Security Steps into the Spotlight
Pop quiz: A bank employee “misplaces” a laptop containing highly sensitive data. What do you do? What do you do?
A bank employee “misplaces” a laptop which contains highly sensitive data, perhaps in the form of social security numbers and name and address information. Odds are, the data in question resides in a spreadsheet stored on the laptop’s hard disk drive. There’s also a good chance the data was sourced from a data warehouse, either as the local cache of an Excel-based reporting front-end, or as the by-product of Excel-powered ad hoc query and analysis.
Either way, the bank has a problem. So, too, do the thousands—and potentially millions—of users whose names, addresses, and social security numbers have been compromised. At a high level, this is a security and compliance issue—the bank should have implemented appropriate safeguards to ensure that such data was never stored on the laptop hard disk in the first place—but at a low level (and in the practical world), it’s a business intelligence issue, too. Why? Because the unavoidable fact of the matter is that sensitive data is inevitably going to be exposed in situations like this (e.g., cached or exposed in some form on laptop or client workstation hard disk drives) and that data warehousing and BI professionals must figure out ways in which to safeguard it.
“There’s this huge trade-off between convenience and control,” says veteran industry watcher and TDWI director of education Wayne Eckerson. “Most [data warehousing pros] agree that there is no lock that you can create that cannot be picked, so there’s no security that you can implement that cannot be breached, and the biggest breaches happen internally. So you have to come up with an equation, you have to understand at what level is the company comfortable in the trade-off between security and convenience.”
This doesn’t mean companies should tolerate the proliferation of local caches of spreadsheet data, of course. This approach—the “spreadmart-ing” of enterprise data—is one of Eckerson’s particular bêtes noires.
“Spreadmarts are a big security issue, so you can add one more problem to the list of problems that spreadmarts cause,” he explains. “[Customers] will be moving more and more to thin client access, but that’s going to take a long time, and there’s obviously a lot of convenience with just being able to export data [from the spreadsheet] to [a local cache on] the hard drive.”
Thin client access, encryption over the wire, and support for single sign-on authentication are three areas in which most of the big BI vendors currently do a fairly good job, Eckerson says. At the same time, however, few BI vendors (outside of better-than-spreadsheet spreadsheet vendors such as Actuate Corp. or Applix Inc) pointedly emphasize the importance of these and other native security features. This is in spite of the fact that Business Objects SA, Cognos Inc., Hyperion Solutions Corp., Information Builders Inc. (IBI), MicroStrategy Inc., and SAS Institute Inc., among others, are today delivering products which support all three features, along with (in a growing number of cases) role-based access (on a per-report or per-dashboard basis) to data.
“My sense is that from the tool and application perspective, it’s fairly robust,” Eckerson continues. “I believe most of the leaders do have the encryption capabilities, most integrate with directories and third-party LDAP providers—things like that. It gets slightly complicated for BI vendors to provide good security, because a lot of people rely on the tool to do role-based filtering of information, and that obviously requires more sophisticated security, because otherwise you’re creating separate reports for every individual. That said, most of the vendors now offer role-based security, too, although it’s not clear to me why they haven’t done more to promote [these capabilities].”
Blame it on a slow news cycle, but Cognos Inc. this week did precisely that, trumpeting the results of a new audit of its Cognos 8 BI platform by Symantec Corp. According to the Symantec report, Cognos 8 is based on a “robust architecture” that’s conducive to secure reporting and analysis. Symantec researchers also concluded that Cognos “understands sound security practices and has surpassed industry best practices by designing a secure architecture and framework for reporting and analysis applications.”
The Symantec audit was, of course, commissioned by Cognos. Nevertheless, it’s a singular case of a prominent BI vendor pulling out a number of stops to trumpet the security feature set of its bread-and-butter business intelligence platform.
Cognos senior director of product marketing Harriet Fryman says customers are starting to place more emphasis on securing their BI toolsets. In a lot of cases, she argues, encryption, single-sign on, role-based information access, and other integrated security features have even become checklist requirements for Cognos customers. “There’s increased market attention around security, especially [when] it comes to BI. Whether the increased focus is because of prominent cases of laptop theft, or ID theft, customers realize this is something they need to pay more attention to,” she comments. “So we’ve gone to Symantec and submitted Cognos 8 to their evaluation audit process, and they’ve concluded that Cognos understands sound security practices. We’ve also published our five foundational building blocks, which we believe give us a great foundation [on top of] which customers can feel comfortable expanding their BI use.”
Louis Barton, an executive vice-president with Frost Bank who has designed BI applications for executives, operations, and employees, says the big BI vendors are starting to more aggressively trumpet their advanced security feature sets. “BI vendors have started to emphasize the extent to which their tools support role-based access to information,” he points out, noting that Frost Bank’s primary BI partner, at least, has done so. “We have one BI vendor and we are able to provide role-based access in a fashion that meets our internal security requirements while meeting the needs of the users.”
Frost Bank’s BI solution—which Barton declines to name—also supports single sign-on capabilities, too. “No additional sign-ons are needed beyond the original authentication [to the company network],” he explains.
On the whole, Barton concludes, the security capabilities supported by Frost Bank’s primary BI vendor actually outstrip its requirements.
“Our BI vendor provides the capability we require based on how we administer security. They also provide additional capabilities that we do not require in our current security model,” he indicates. “[They] appear to get everything right in terms of meeting our specific requirements. What was lacking in previous versions—[and which has] now [been] corrected in the just announced release—was an audit trail capability that provides adequate reporting on user access. We have seen the new solution and think that it is satisfactory.”
In the final analysis, Eckerson cautions, you’re only as secure as the weakest padlock in your BI kingdom. To the extent that organizations continue to countenance spreadmarts—or any kind of unencrypted local cache (e.g., flat files)—there’s the potential for disaster. “The transition [among customers] to thin client access will take time, and even then, the temptation [to export data to a local spreadsheet] will always be there. After all, even though performance for thin clients is getting better, you do actually have to be connected [to get at data],” he points out. As a result, Eckerson says, while thin client connectivity (with centralized security and on-the-fly encryption over the wire) might be ideal from a security perspective, organizations are going to have to balance this ideal with the needs of roaming users, who need anytime/anywhere access to data. “This is why you might see [BI vendors] starting to place more emphasis on encryption [of local data] as well as other capabilities”—such as integration with biometric, ID card, and other client security mechanisms.
About the Author
Stephen Swoyer is a Nashville, TN-based freelance journalist who writes about technology.