Desktop version

Home arrow Computer Science arrow Securing Systems Applied Security Architecture and Threat Models



As you consider the attack surfaces in the list above, what security controls have already been listed?

I have stressed the importance of industry-standard administrative and system management controls as they apply to the business analytics system. Because of the importance and sensitivity of the system's configuration files, the temporary results and analytics results files, these two storage areas require special attention beyond the usual and typical that we have already stressed. As was already explained, each of these storage areas represents an opportunity not only to control the business analytics system, but perhaps to have far-reaching consequences for the entire enterprise architecture. Due to this sensitivity and the comprehensive consequences of a successful attack to either of these areas and data, particular attention must be paid to the execution of access restrictions and the separation of duties.

Essentially, no matter how particular and careful Digital Diskus is about the implementation of access controls, some administrator, at least one, is going to have access rights to each of these areas. That’s because there will need to be someone who can execute those tasks that require superuser privileges. Unfortunately, modern operating systems require someone who, at the very least, has privileges to firefight during a crisis.

Let’s suppose that a junior engineer makes a grand mistake by corrupting a couple of key operating system shared libraries on several of the business analytics hosts. Let’s suppose that it’s an honest mistake; the engineer thought that he was executing a script designed to check the validity of packages, mistyping the command line parameters to the script at a time when he had sufficient privileges to damage the systems. And let’s suppose, just for the sake of an example, that the mistaken script causes several systems to reboot in a state from which the system cannot recover. Usually, operating systems survive such unexpected crashes without damage. But to give an example in which firefighting capabilities might be required on a critical system, let’s suppose that several of the redundant processing module hosts come up with damaged operating system files that can no longer execute. This is not a far-fetched example. Such crashes do occasionally happen; someone has to come in and get the systems up and running. Often, in these situations, there may very well be significant management pressure demanding that the systems are fixed as quickly as possible. This could especially be true at a time when financial records are being closed or at some other business inflection point.

With the kind of pressure described in the example above and the criticality of the business analytics systems, solutions to such situations often take a very senior engineer with much system experience and deep understanding of the application, as well. This individual must “smoke jump” the problem by using superuser privileges to rebuild the operating system.

The questions that then will be asked for this type of critical system that maintains highly sensitive data will be something like, “Who should have these privileges and how many people need them?”

Oftentimes, the easiest and most manageable solution to who and how many people need high privileges is to give everyone who may have to alter the system the ability to work at the highest privilege level. In a situation in which there are only three system administrators, the tactic of giving everyone high privileges may make a good deal of sense? After all, on a small team, if someone makes a significant error or, worse, is dishonest or downright malicious, one or both of the other two people are likely to notice.

However, organizations that field large administrative staff cannot rely upon a system based upon personal checks and balances over the actions of any particular individual. If there are 100 administrators spread out globally in different time zones, who knows who’s performing what actions at any particular time? Furthermore, what if most of those administrators are responsible for every machine on the network, so that the administrative duties can be handled around the clock, 365 days per year? Many individuals may be given very similar duties, so that the absence of any single individual will not be missed. This is very typical in organizations that administer hundreds or even thousands of machines across the globe.

Generally, system administrators are among the most trusted staff at any organization. They have to be: They can bring systems up or down, and they certainly have access to at least some of the critical files and data of the organization. Indeed, it’s easier on everyone if privileges and access controls are kept simple. Generally, it’s prudent to eliminate as many special cases as possible in order to reap the rewards of economies of scale and efficiencies of task.

Competing against simplicity and economies of scale are the differences in data sensitivity and system criticality. In the case of business analytics, there appears to be a clear need to protect the configuration files and the results files as carefully as possible leaving as small an attack surface as can be managed. That is, these two sensitive locations that store critical organizational data should be restricted to a need-to-access basis, which essentially means as few administrators as possible within the organization who can manage the systems effectively and continuously.

A typical requirement for this kind of system would be to limit the number of administrators who have access to it to a small number. What that number is will need to be determined by taking the factors of global, round-the-clock support and appropriate levels of personnel redundancy into account. There is no hard and fast number that will work for every organization. One of the factors influencing the decision will essentially be the number of individuals who have the experience and proven trust to execute the task. If there are seven of these, that may be a better decision than a smaller number simply because the difference between six and seven poses no or little additional risk to the organization. I would avoid attempts to pull a number out of the air since, in my experience, no such perfect number exists. And time may be wasted and relationships hurt if the number question turns into a tug-of-war between four versus seven, a tug-of-war between system administrators and security.

Instead, it may be more fruitful to examine individuals’ past history and expertise, management chains, line management capabilities, and other direct factors that will influence the ability of the individuals to carry out the duties and carry this burden of responsibility successfully.

The requirement would read something like, “superuser privileges may only be granted to high trust, master administrator-level personnel on a need-to-know and need-to-support basis.” Keep requirements like these at a high enough level that those charged with execution can implement them without being micro-managed or blocked, as conditions and technologies unfold and develop.[1]

There are tools readily available (but sometimes expensive and nontrivial to implement) that can help to control high-privilege access, especially in situations as confronted by Digital Diskus’ implementation of business analytics. These tools grant privilege levels only for the duration of the session or task. When the task is completed or the designated period ends, the privileges are revoked and must be requested from the system once again.

Access can be granted in a granular manner by tools of this type. That is one of the primary functions of a server access and change management system. Implementing a server administrative privilege control tool would allow the extensive administrative function at Digital Diskus to provide one level of access across most of the servers, while reserving critical server access to a limited, higher-trust set of individuals, precisely as required for the business analytics system.

Such an access and change control tool will also log actions taken by administrators on systems (remember that all actions on the systems are being monitored by the security monitoring system). Consequently, every action taken can be audited, both for malfeasance and for inevitable human mistakes. Typically, a tool controlling highly privileged access can also dole out permissions in such a way that for some systems or some operations, only the most highly trusted individuals are granted permission.

If Digital Diskus hasn’t deployed an administrative access control tool, the implementation of business analytics might be seen as an opportunity to upgrade the security controls across the administrative functions. In other words, new complexities to an enterprise architecture often present opportunities for building an architecture that better meets those complexities rather than trying to simply accept additional risk due to the way “things have always been done.” Another typical response would be to jerry-rig current systems with high-maintainance manual processes in order to meet the challenge. Although either of these responses may be the appropriate organization decision, an architecture inflection point at which new requirements foster new capabilities is usually an opportunity to discuss strategy as well as any available tactical solutions.

I will point out that since the organization already has a robust implementation of Active Directory groups, an interim solution might be to employ a group membership as a way to restrict access to these two particular storage areas. Such a solution would depend upon the operating system on which business analytics runs and the operating environment for storage areas (both of which are currently undefined) and whether these can make use of Active Directory groups for authorization to particular storage areas.

If we were actually implementing the system, we might have to engage with the operational server management teams to construct a workable solution for everyone. For our purposes in this example, we can simply specify the requirement and leave the implementation details unknown.

The actual data that is pulled into the business analytics system might contain attacks. Some of this data originates from applications that are hosted on the exposed network, the DMZ. Those applications, of course, will be under fairly constant probing and attack. Although Digital Diskus makes a concerted effort to build resistant and self-protective applications, no security measure is perfect. It should be assumed that, at least occasionally, hopefully rarely, a sophisticated attack will breach the protections, input validations, and messaging rewrites that we’ve already noted have been built into the exposed applications. That is, a strong defense must assume that an attack will come through.

If an attack makes it through, it may lay in wait in data storage until the business analytics system pulls the data that contain the attack and then attempts to process it. At that point, any authentication or communication encryption that is used will provide no defense whatsoever to the stored attack; the attack will be gathered up as a part of the data that’s being processed. The business analytics system must be as selfprotective and securely programmed as external applications are expected to be. It is important to note that one of the inputs into Data Gathering is from messages that originate from external applications as they pass over the message bus. So an attack that makes it through the external applications might be processed by the business analytics processing module before the attack data are stored. Data Gathering must be robust and rigorous in throwing away any data that is invalid or poorly formed, no matter the source or the timing of the collection.

However, in a system that must process many different forms of data, that processing must be very “plastic.” Generalized data format processing must be very data driven so that it can accept just about any form of data imaginable, as the processing code is going to have to process data in many forms and presentations. There is a significant conflict between rigorous input validation and normalization and the processing of many varied data presentations and types. This is what they call in computer design “a nontrivial problem.” As has been stated previously, but should be noted again, the implementation and coding of the business analytics system is not within the control of Digital Diskus. What is the best way for Digital Diskus to mitigate the risk from overly generalized data processing?

In Chapter 3, where we examined the art of security architecture, holistic analysis was discussed at some length. The risk of an attack coming through one of the data streams is a good example of how a system’s security posture shouldn’t be confined to the system itself, but rather, enlarged to include all the systems with which it connects. In this case, the cleanliness of the data, the protection of the data processing module, depends upon a strong defense against malformed data in applications that were likely built without any concern for the business analytics system. In this case, which is a typical timeline for adding a business intelligence to an organization, the business analytics system has been implemented after many of the applications that produce the data to be analyzed were built. Nevertheless, business analytics depends upon those applications’ defenses against malicious data. Part of the defense of the business analytics system will be how thoroughly the data is cleaned before it is allowed to pass inwards and onwards to the systems that the business analytics will touch.

However, the defense of business analytics shouldn’t rest solely with the quality of applications and other data sources. Below, in the discussion of user interface imports, we will add another assurance step for determining the quality of the business analytics systems’ defenses themselves.

There are several user interfaces that require restricted access. When we developed our threat model, the reporting module’s user interface and that of Management Console were called out as a likely attack surface. Furthermore, within each of these interfaces, certain inputs were called out as particularly sensitive: the interface provided in order to input credentials for data sources and the interface where the analytics results are displayed.

• Management console inputs

° Data source credential inputs

• Reporting module user interface

° Presentation of analytics results (“Reporter”)

The data source credential values will be input into a subset of Management Console’s user interface. Likewise, the presentation of results is a subset of inputs and outputs within the user interface of the reporting module. Depending upon the granularity of authorization permissions, it should be possible to isolate each of these sensitive areas from the general user interface in a granular manner. That granularity of access and restriction must be finer than a role that is given broad access[2] to a number of functions or even the entire interface. Fine-grained access in this case may mean single pages, collections of pages, or access that has been confined to individual fields. One of the requirements would then be a fine-grained authorization mechanism.

This business analytics system includes coarse-grained roles, such as system administrator, analyst, and executive, as shown in Figure 8.4. (These are examples and do not comprise an exhaustive list of system roles. Such a list isn’t needed for this analysis.) But the system also allows the super administrator to assign privileges in a finegrained manner. For instance, there can be any number of “administrators” who can add analysts or executives to the system in order to perform typical, day-to-day user management. But each of these administrators should not be given permission to edit credentials that will be used by the system.

This, however, cannot be the entire protection for these sensitive interfaces. Even though all due care must be observed in granting access on a strictly need-to-know basis, it has already been stated that Digital Diskus is concerned about insider attack. The system must implement protections against the various attacks that can be exploited through user interfaces (from web weaknesses to memory handling errors, and so forth). But, as was noted, Digital Diskus doesn’t have control over the programming of the system. Has the maker implemented the appropriate input validation and sanitization routines in order to protect the code from user input-based attacks?

From Digital Diskus’ viewpoint, since they do not have direct control over business analytics’ implementation, they have two (industry-standard) activities that they may use as a risk treatment: study the vendor’s security practices, with particular emphasis on software security, and test the system itself for vulnerabilities and attack resistance.

Let us assume that Digital Diskus’ security department has conducted a thorough analysis of the vendor’s software security practices, with particular emphasis on how the system is built and how the vendor finds and fixes vulnerabilities during the vendor’s Secure Development Lifecycle (SDL). Further, a thorough attack and penetration test (A&P or “pen test”) was performed by Digital Diskus security personnel on the system before it went into production. Although the pen test did find a few minor issues, no major issues were uncovered. Therefore, Digital Diskus has some confidence in the system’s ability to resist attack to its inputs. “Inputs” for the pen test included the user interfaces, the configuration file processing functions, and the data gathering inputs.

Because Digital Diskus’ internal network cannot entirely be trusted as a sole control to restrict access because of the broad range of people and organizations that participate in the Digital Diskus business ecosystem, communications from users to the business analytics system and between data sources as data is gathered should be protected in transit. In other words, the network cannot be completely trusted. The business analytics system has the ability to present its user interfaces via HTTPS. HTTPS will meet the requirement to protect user interactions with the system across the less than completely trusted network. And any data gathering access that supports Transport Layer Security (TLS) should be configured to do so. This aspect of the communications is somewhat dependent upon the capability of the data source. To facilitate secured communications, the data agent API and libraries support TLS. Generally, native data gathering protocols pull data from the source. When this is the case, if the data source can act as a TLS server, Data Gathering is capable of being a TLS client. Consequently, in all instances that support a TLS capability, TLS is being employed across Digital Diskus’ internal network.

  • [1] Steve Acheson taught me to keep my requirements at sufficient specificity to be implementablebut not so specific such that implemented cannot adjust to changes without rewriting therequirement.
  • [2] he authorization mechanism could be a native business analytics role or membership withinan Active Directory group, as we explored above.
Found a mistake? Please highlight the word and press Shift + Enter  
< Prev   CONTENTS   Next >

Related topics