Enterprise Search Sourcebook 2008

If you wonder if your company is at risk for exposing private content, try searching for the word “confidential” on your company’s search box. Most search engines support the concept of collections, also referred to as “repositories,” “sources,” or “document sets.” One of the easiest and reasonably effective control techniques is to simply segregate data by security requirements: Public data is grouped into one section, restricted data into a second, highly confidential data into a third, and so on. Search engines can limit the search to one or more of these collections. Once the credentials and access level of an individual user are determined, the appropriate collections are enabled for their search. Where documents already have access-level security provided by a file system or a content management system (CMS), search security can be applied at the document level. This method of securing data will feel very familiar to those with a database background—certain groups or users can see certain documents. Databases and CMSs have had this technology for a very long time, and enterprise search engines are quickly catching up. Whether you talk about “record,” “document,” or “web page,” to a full-test search engine they are all retrievable units of data. Complexity of Document-Level Security One of the complexities with document-level security is the rendering of the results list. Typically a document or record will be well-secured, but the search engine has indexed all of the content and is displaying lists of titles and summaries in a results list. It’s not enough to secure the actual document; the results list should not display even the title or summary from a document that the user cannot see. Often even a title or summary can convey important (potentially confidential) information. For example, a title of “Indictment of John Smith Expected Tomorrow” would 60 ENTERPRISE SEARCH SOURCEBOOK 2008 tip off John Smith, regardless of whether he can read the entire document or not. A more subtle detail of the secured results list is the display of the number of matching documents and the links that allow users to page through a long results list. A simple engine might display the total matching count of documents, whereas a highly restricted user may only have access to 10% of those records, so the count is quite misleading. Beyond cosmetics, the engine needs to have an accurate idea about what documents that user can see when it is offering links to pages 2, 3, and 4 of the results list. An even more subtle detail, but one which can still be a requirement in highly secure systems, is the confirmation of whether certain terms appear in the document index at all. As seen in the John Smith example, searches for terms like “layoff,” “indictments,” or the names of specific people can partially confirm the presence of information, even if no document titles are shown. A highly secure search will not confirm or deny the presence of terms in its index outside the context of what the user is allowed to search. A more common example may be to not confirm the presence of obscenities or defamatory terms in nonaccessible content. Access Control at the Subdocument Level The theory of controlling access at the subdocument level is that different users can see different portions of the same document. Here are a couple of common examples of this method: • Some sites that charge for content allow users to see the title of documents in their results list, and perhaps a summary, but the user must then pay to see the entire text of the article. • All managers can see summaries of sales documents, but only VPs, finance, and sales can see the specific financial terms. • Partners can see the text of bug reports but can’t see the company that logged the issue. In these cases, document-level security must give way to subdocument level security. Needless to say, implementation details can get a bit sticky. Detecting and removing certain parts of unstructured documents can prove difficult. Broadly, there are three levels of difficultly associated with subdivision of documents. The easiest level includes Search engines can limit the search to one or more collections. Once the credentials and access level of an individual user are determined, the appropriate collections are enabled for their search.

Table of Contents Feed for the Digital Edition of Enterprise Search Sourcebook 2008

Enterprise Search Sourcebook 2008 Contents Editor’s Note Publisher’s Note Findings and Figures Why Enterprise Search Will Never Be Google-y Searching for Search Usability Your Users Are Talking to You What’s Your Search Story? Search Is Dead—Now What? Delivering on the Promise of Enterprise Search Taming Multiple Search Engines in Your Organization Enterprise Search: Trends for 2008 Enterprise Search Seen From the Inside Open Source Search: Elixir or Poison? Avoiding the Big Mistakes in Search Semantic Search Takes Root in the Enterprise E-Discovery Essentials: The Rules You Need to Know SharePoint Search: An Enterprise Contender? Integrating Security Into Your Enterprise Search Infrastructure Engineering a Better Search Infrastructure Letting End Users Ask the Questions, Stat! The Power of Knowledge Legal Research Using Enterprise Search: A Developer’s View From Treading Water to Full Steam Ahead Pulling Out All the Stops With Midas A Natural Search Solution An Incremental Approach to Improving Enterprise Search The Enterprise Search Sourcebook Showcase Directory Index to Advertisers and Companies Mentioned

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.