One of the important initiatives within the Runbook of knowledge and information shared among the skilled workers in a data center is to document data protection measures. Almost always de facto business rules will exist about who can and cannot view some or all of the data stored in organization’s databases. Recording these rules in the Runbook is a first step in documenting data protection measures.
At some point after the rules are recorded, it is vital to examine all known database access in the context of these business rules. A highly effective way to describe the multiple ways and means that data is accessed is by building a Data Bridge Catalog.
A Data Bridge is any complete logical path through which data can be moved in or out of the database. A Data Bridge will have 2 logical endpoints – a data store and a consumer – connected by a transport span.
There is no security context association for a Data Bridge. Security is applied within the data bridge context not over a Data Bridge context. There may be any number of security contexts within a Data Bridge. In fact examining the Data Bridge critically to uncover unintentional spans is one of the most interesting and value adding aspects of Data Bridge cataloging.
Just as road bridges have many designs, Data Bridges have many designs. So much so that critical Data Bridges can go unidentified or unattended and – usually as a result out of band or malicious acess to the organizations valuable data - is possible completely unbeknownst to the DBA and system administrators. In the same way that a road bridge might be exploited by the power company, the utility company, the bus and even the sewer department to get their product to the other side, good application designers and architects will look to existing infrastructure to get data from the database to the data consumer. Unfortunately, bad guys can use the same approach to move important data where it ought never go.
USB ports are a simple yet classic example of an endpoint that may not be considered when designing a database security architecture. Query results and even screen shots of confidential reports are easily moved without detection using these ubiquitous port. Its politically risky to say, but any one with administrator rights is another often overlooked and unmonitored enabler of illicit Data Bridges.
By now the reader has a good understanding of what makes up a Data Bridge. This rest of this article describes a collaborative thought project to identify and catalog the data bridges.
It is not realistic to expect to build a complete data bridg catalog in a week or a month. Expect this to be an ongoing and iterative initiative.
Security across the Data Bridge
As already mentioned, data security models can be defined in the context the Data Bridge. I would argue that without clearly defined encapsulation boundaries such as can be defined by the the Data Bridge it is not possible to get the security model right, Until someone has access to the data, it remains safe: a bridge to nowhere. From that point in time when access is granted, those given access to the data must be included in a principle-of-least-privledge based security scheme. All others must be explicitly excluded from access accross the Data Bridge if it to be secure.
The thought that one of the SPIDs connected to a SQL Instance may be the competition or the enemy gives a good DBA a seeminly instinctive impetus to take a backup. How else to keep that data safe? And then, given the opportunity to adequately contemplate the security, the DBA must realize that creating the backup creates one or more new and highly opaque Data Bridges. The file or tape image itself becomes a span component. Moreover, this span is outside the scope of the application layer security schemes and possibly even organizational permissioning schemes. From the time the backup is created, every security question asked about the database must also be asked about the backup file. And if a copy of the backup file is created or the the backup is restored to another SQL Instance, the once doubled security requirement is now tripled. From this is is apparent how quickly the risk of unintented exposure of data to outside world can snowball out of control.
A Data Bridge is a conceptual architectural element not a process label. Many processes may use a data bridge. Conversely, a data bridge can link several data bridges into an over arching conduit for data. By the way, such a linked collection of Data Bridges is collectively referred to as a Data Bridge.
Story Boarding the Data Bridge
The storyboard surface in [Image 1] depicts a conceptual representation of on organizational database environment. The surface is useful to describe data bridge connectivity scenarios. The storyboard serves as a visual queue to get the conversation started between the data team, system architects, security officers, the network administrators and the business stakeholders concerning unplanned/unintended data bridges. It also serves as a documentation of that conversation by adding notes and markings to explain the know endpoints as well as potential risks for the data bridge. (Some example post-conversation storyboards are shown later in the article.)
[Image 1]
A main goal of this article is to explore methodologies for cataloging of Data Bridges. Along the way, the exploration will also reveal why a data bridge catalog is vital to the data team and to the organization in the quest to secure the data assets. It is left to the reader to define the form and fit of the Data Bridge Catalog as it might be used in the reader’s scenario. There is no cookie cutter approach possible for documenting a Data Bridge. To wit; some catalogers may find it more useful to introduce the storyboard as an artifact created by many interested persons in a conversation while others may find it more useful to make personal notes during or after a conversation involving the data team members of data stakeholders. The storyboard need not be a part of the dialog as long as adequate information to define and recreate the Data Bridge is cataloged. The storyboard should not inhibit the concise description of the Data Bridge.
The Data Bridge catalog is not complete once it documents the known and intentional spans. That is only the beginning. From that basis of intentional data movement it is necessary to uncover all potential unintended or unexpected data bridging that can be secured as appropriate. At this stage, Data Bridge cataloging becomes primarilty an excersize in brain stroming can creativity. Bridge builders must think like bad guys. Typically, cataloging will at first be mostly a documentation effort. Over time, with continued scrutiny, review of the catalog may identy exposures and ways to proactively improve data security. And of course if the business discovers that data has actually moved across know bridges by malicious users, expect the evolution of the Data Bridge Catalog to accelerate. At least temporarily If behooves the Data Bridge builders to capture both the malicious use and the measures taken to secure the bridge into the ctalog documentation.
Nonetheless, even a somewhat out of date Data Bridge Catalog will provide data team experts with an eye toward data security an effective and suprisingly complete point of refernce for a methodical analysis provided each entry is adequately described. The more the team works with the conceptual building blocks of the Data Bridge catalog, the more likely any risks and exposures will be uncovered.
A completed Data Bridge story board will include a minimum of four fundamental pieces of information:
The data bridge - applications, scripts, tools or services used to connect Data Consumers to the store for that data. A complete defintion would include the technical detail or organization contact information necessary to install, configure, update, enable/disable, and uninstall each span in the identified Data Bridge.
The data consumer – the business interest or target of the data supplied by a Data Bridge. The consumer could be a user, organizational groups, database role, customer, client, domain, partner, system, etc. that a Data Bridge purposefully connects to the database. More than one Business Interest might have a legitimate use for the same data bridge. All data consumers, including those that can transparently piggyback on a data bridge purposefully built for another consumer, should be explicitly identified and cataloged. Think of the data consumer as the scope of intended trust for the data.
The data store - a concise functional collection of data. All narrowing attributes - those that aid in uniquely identifying a data store – should be included to correctly and accurately describe a data store (e.g. database NorthWinds, schema Sales, PROD1, etc.). Think of the data store as all data presented to the data bridge. It is not relevant to the data store if the consumer is actually using all accessible data at any given moment.
Exposures - Identified ways that the data can be used for other than the intended purpose or by any but the intended data consumers. It is not necessary to enter exposures when
a data store is cataloged. It is even possible that none exist I presume, though it is far more likely that exposures are difficult to detect than that there are none to be found
[Image 2] depicts the data bridge story board template as it might be loaded to OneNote as template or projected to a screen for collaborative use.
[Image 2]