found id
The Corporate Information Factory (CIF) has grown over time from applications and data warehousing. Different components of the CIF have appeared: data marts, DSS applications, alternative storage, data mining warehouses, and ODS. Each serves different communities and purposes. This basic structure is illustrated in Figure 1.
Figure 1
The different components of the Corporate Information Factory evolved for a variety of reasons, each separate and apart from the others. It should come as no surprise that each also has different security requirements and considerations.
The conversation about CIF security needs to begin with a discussion of from whom it is to be protected.
There are at least two threats to security: external and internal. External threats are those outside the enterprise that would misuse information found inside the Corporate Information Factory. Traditionally, this external path is through the Internet. Access is granted or is surreptitiously obtained and the external party goes to work against the data. Unless the external party has intimate knowledge of the structure and contents of the CIF, finding one’s way around there can be very confusing. Data is found inside DBMS and OLAP technology and, as such, is naturally protected by the very technology that houses the Corporate Information Factory. In addition, the relationships between different types of data are often somewhat off-hand and arcane. Only an experienced database administrator or a systems programmer would be able to decipher the meaning of relationships. Nevertheless, it is possible that the external threat can breach the structures and conventions of the Corporate Information Factory. Once that is done, the information therein lies at the mercy of the external threat.
The second kind of threat is internal. The internal threat is someone inside the organization who is familiar with the structure and the workings of the Corporate Information Factory, and unauthorized access is made. Internal threats seldom come over the Internet; instead, they come from direct or indirect access to data lying inside the CIF. Often times the internal threat will have some knowledge of the internal workings and structure of the Corporate Information Factory.
Observation has taught us that external threats are much less common than internal threats.
The discussion of threats centers around the likelihood and the ease with which one can be realized. Some threats are very, very unlikely; others are likely to happen. Some threats are easy to accomplish; others are very difficult. The security administrator needs to focus on likely threats that are easily realized. Other categories are not ignored but are less important.
Another important issue to discuss relates to the consequences of a security breach. Some data is quite safe with no special security measures. If someone broke in and found out how to access that sort of data, there would be no foreseeable consequences. But other data presents a unique perspective. Financial data, human resource data, and medical data require special care and handling. There is a different and serious consequence for the breach of each of these kinds of data.
At the outset, the data architect needs to look at the different kinds of threats to CIF data and assess the consequences of a security breach.
The type and extent of security is commensurate with the consequences of a security breach and the likelihood or ease with which it can happen. In almost all cases, multiple types of security will be employed. The security measures may be anything from firewalls, to encryption, to password protection. The degree and type of security is matched against the threat and the consequences of a breach.
These assessments are made at the outset of building the different components of the Corporate Information Factory. Because the CIF is built over time and the components change periodically in terms of size and function, assessments are an ongoing effort.
The center of the Corporate Information Factory is the data warehouse, which contains much detailed and historical data. Access to the data warehouse must be guarded. But, ironically, summary data derived from the data warehouse needs to be guarded more closely than the data found in the data warehouse. For example, suppose a corporation stores the details of the sales revenue that have been made in the data warehouse. Is it a security breach if it is found out that a part has been sold to General Motors for $350 on January 15? Is this a problem when there are 10,000 other sales that have been made? It is hard to imagine a problem arising from the inadvertent disclosure of a single sale. But if all the sales for the quarter are added up and it is discovered that sales are 10% below the expected amount, then that piece of news can be used in a harmful manner.
Of course, update and creation of data in the data warehouse must be controlled in a rational manner. The data warehouse must be loaded with legitimate data.
The data warehouse is usually a large central facility serving many different parts of the corporation. As such, the data warehouse belongs to the central IT organization that protects the data warehouse through standard system facilities, such as network monitors, firewalls, and standard operating systems facilities. If there is a need for a deep level of security, there are further opportunities for security at the DBMS and even the application level.
Data marts are the departmental component of the Corporate Information Factory. Different data marts are built by different departments such as finance, sales, and marketing. As a rule, the level of security needed in the data mart is at a much higher level than that needed by the data warehouse. The data mart contains very sensitive data such as forecasts, summary information, tracking of KPIs, and so forth. Data mart information is very close to the heart of the business. The information found in finance, sales and marketing could be very injurious if allowed to escape beyond the boundaries of the corporation, and in many cases beyond the boundaries of the department itself.
The data mart environments are usually owned and managed by the departments themselves. For example, accounting will own its own data mart – the hardware, the software, and the data. The approaches to security to data marts will vary by the department itself. For example, finance will have its own security measures; sales will have its own security measures and so forth.
The measures taken for security that are employed by each department for its data mart are the same – in miniature – as those found in the data warehouse environment. The department can use firewalls, network security, DBMS security and operating system security. The difference is that each department tailors its security to its peculiar needs. In a very real sense the granularity of security is much lower and much more customized at the data mart level because of the change of ownership and control of the data and systems that comprise the data marts.
The exploration warehouse and data mining warehouse requires probably the least security of any of the components of the Corporate Information Factory. The exploration warehouse and data mining warehouse is built on a temporary basis and is owned by an analytical organization. As such, care is taken from the outset for the ownership and the tending of the exploration warehouse and data mining warehouse. In addition, it is built at the lowest level of detail. Only information derived from the exploration warehouse and data mining warehouse is really sensitive in most environments. And in many cases this data is stored in an exotic manner, such as a token based technology. Once stored in such technology the data is naturally encrypted by that technology.
For these reasons and more, there is probably less of a requirement for security in an exploration warehouse and data mining warehouse than there is elsewhere. Of course, there is the case where the detailed data being examined is truly sensitive data, even at the detailed level. In this case, the data being analyzed in the exploration warehouse and data mining warehouse needs to be protected at the same level as the data found in the data warehouse.
The ODS presents a special case across the Corporate Information Factory in terms of its needs for security. Data inside the ODS needs to be protected at the detailed level more so than data inside the data warehouse. This is because data inside the ODS is used for online decision-making at the detailed level. The ODS contains data that is available in a truly online mode and data that can be updated. Therefore the ODS has at least as high a level of security as data found in the operational transaction environment. In addition the ODS can contain organizationally integrated data. Therefore, the needs for security are at the absolutely highest level throughout the entire Corporate Information Factory.
The ODS is usually built and maintained by the central IT organization. The central IT organization is charged with the protection of the data in the same way that the central IT organization protects standard operational data and processing.