In this context, where several components share the same host, how would you treat the communications between them? Should these communications be considered to traverse a trusted or an untrusted network? If Digital Diskus applies the rigor we indicated above to the management of the servers on which business analytics runs, what additional attack surfaces should be added from among those three components and their intercommunications when all of these share a single host?
Given that we already know that Digital Diskus requires and maintains a rigorous set of security standards for its administrative functions, how does this “infrastructure” influence the attack surfaces? This is one of those situations in which the architecture of the system under analysis inherits security capabilities from the infrastructure upon which it’s deployed. There are no standard users maintained on the hosts on which business analytics is running. There are only high-privileged users who were charged with keeping the host, as well as the applications running on that host, maintained, patched, and hardened—that is, all the administrative tasks that go into running industrial-strength enterprise systems. This situation is quite unlike a user’s endpoint system, which will be exposed to whatever the user chooses to do.
Please remember that Digital Diskus’ administrators are supposed to be sophisticated and highly trained individuals. Presumably, they have been issued separate, individual corporate systems on which to perform their usual, digital tasks: email, Web research, calendaring, documents, and spreadsheets. They do not use the servers they administer for these tasks; that would be against policy. Therefore, the only users that business analytics servers should be exposed to are the administrative staff. Although the administrative staff maintaining these hosts does have high privileges on the systems, it is assumed that they know how to protect these appropriately. Working within the strictures of appropriate separation of duties, these individuals would not have any rights to the interfaces of the business analytics system itself. That is, they shouldn’t have access to Reporter, Management Console, the processing module, or Data Gathering. They are not entitled to view the results of the business intelligence analysis. Still, despite the separation of duties that prevents administrative staff from being users of the business analytics system, they will have rights to the operating system that runs the applications and thus, they will inherit rights to all the data that is kept locally or mounted onto those servers. So, although the user interfaces of the system might not pose a potential attack surface for an insider attack, the data stores of the system most certainly do.
If I were analyzing this particular business analytics system placed within the context of the enterprise in which it is supposed to be run, I would not worry about the communications flows between the modules that are co-hosted. My reasoning is that the only access to these communications is via the high privileges of the administration accounts. If these accounts have been lost to an attacker, a great deal more than the intra-module communications is at stake. We have already stated that the privileges on these servers are protected by a number of controls. These controls are inherited by the business analytics system and will be taken into account in the threat model. The controls, if executed properly, are likely to prevent or significantly slow an attack to business analytics from its operating environment. However, you may note that we have opened up another attack surface that can come from one of our threats: rogue insider attack to the very sensitive data that business analytics produces.
Communications from the data gatherer to data sources will be of interest to many attackers. Before analysis, some of the raw data will be sensitive and proprietary. Even the internal network, considering the breath of the Digital Diskus business ecosystem, cannot be considered entirely trusted. Therefore, communications of sensitive data must have protection going over the network. The network communications to data sources are an attack surface. Which brings us to the agents.
The data gathering agents are located on various data stores or within the stores’ associated data access services. An agent is required in every instance in which a native data protocol cannot be used to pull data from the storage or application. An agent will be written for each proprietary, nonstandard access protocol. It might be written to parse an XML data format, or to read a proprietary file of one kind or another, for example, a Microsoft Word document or Excel spreadsheet. The agent must have rights to read the data source. In this instance, when a data-retrieval operation is instantiated, the data gatherer sends the credentials down to the agent for the operation. Credentials are not stored at agents.
If an attacker can retrieve the API and libraries, then use these to write an agent, and then get the attacker’s agent installed, how should Digital Diskus protect itself from such an attack? Should the business analytics system provide a method of authentication of valid agents in order to protect against a malicious one? Is the agent a worthy attack surface?
I would ask the business analytics vendor what protections they had placed in the protocol or interchanges between agent and data gatherer to preclude an attacker writing a malicious agent. The agent’s software is a target, in and of itself. With a rogue agent, an attacker can send data of the attacker’s choice to the business analytics system, as opposed to real data. Furthermore, a badly written agent, API, or libraries could open a vulnerability that could be misused by the attacker to take over whatever host the agent is running on. Therefore, the data gatherer must protect itself against malicious agents; there’s one attack surface. And each agent is potentially an attack surface introduced to the system on which it’s running.
The native access interchanges will be protected by whatever native defenses are available for that access method. These, then, would be out of the assessment scope of the business analytics system, by itself. However, this does not place out of scope the credentials used for those native access methods. These, like all of the other credentials, must be considered a prime attack surface of the business analytics system.
The management console has direct control over the configuration of all the other components. Indeed, credentials for each access method and data source will be input to Management Console. That makes Management Console, in its entirety, an attack surface: every input and every output.
Why should the output of Management Console be considered an attack surface?
Previously, the point was made that all inputs should be considered attack surfaces. However, when the outputs of the system need protection, such as the credentials going into the business analytics configuration files and metadata, then the outputs should be considered an attack surface. If the wily attacker has access to the outputs of Management Console, then the attacker may gain the credentials to many systems. Further, the attacker will know which data sources exist and, quite possibly, the access methods for those data sources (because the protocol and/or agent for each access must be configured). Because of the foregoing, this particular set of outputs contains critical and sensitive information that affects the security posture not only of the business analytics but of many other systems, as well, and should be considered an attack surface.
Naturally, the configuration files are also a prime target themselves, as stated above. What may be less obvious is that when Management Console reads the configuration files, this also creates an attack surface at Management Console. If the attacker can insert attack code to exercise a vulnerability in the configuration file processing routines, the attacker might gain Management Console, or even privileges on the host that runs it. Remember, Management Console is running on a separate host in this implementation. That server is, of course, a target that inherits the protections of the administration function at Digital Diskus. But a subversion of Management Console itself might give access to all the functions that Management Console controls, which are, of course, sensitive.
Access controls to Management Console itself, authentication and authorization to perform certain actions, will be key because Management Console is, by its nature, a configurator and controller of the other functions, a target. Which brings us to Figure 8.4.
Figure 8.4 Business analytics user interactions.
Figure 8.4 returns to a higher level of abstraction, obscuring the details of the business analytics modules running on the host.* Since we can treat the collection of modules as an atomic unit for our purposes, we move up a level of granularity once again to view the system in its logical context. Management Console has been broken out as a separate component requiring its own defenses. The identity system has been returned to the diagram, as has the security monitoring systems. These present possible attack surfaces that will need examination. In addition, these will become part of the defenses of the system, as we shall see.
The foregoing indicates that business analytics web code must resist all the usual and well-known Web attack methods. Further, the reporting module interface must be coded with care to disallow attacks against the data through the interface, such as SQL injection attacks. The interfaces are attack surfaces, and, specifically, they are Web attack surfaces.
Beyond a malicious agent, there is another attack surface in Data Gathering.  In order to process many different kinds of data in different formats and presentations, some part of the business analytics will have to normalize the data and put it in a form that can be correlated. The data will have to be parsed and perhaps reformatted. Data will certainly have to be normalized. There is a fair amount of preprocessing that any correlation system must perform before data from different sources in different formats can be brought together into a holistic picture. From an attack perspective, this preprocessing means that the data will have to be read, its context and metadata (field names, etc.) understood, and then the data will be rewritten into some form that is reshaped (normalized) into a standard format. If attackers can exercise a vulnerability that exists in the data processing routines, they may be able to use that vulnerability to subvert the data preprocessing or even go beyond that to the operating system.
Depending upon the vulnerability, Data Gathering at the very least might be caused to simply stop functioning (denial of service—“DOS”), which would halt all business intelligence operations. Without accurate data updates, the results become stale, or perhaps even false. But what if the attacker can cause the data to change? Then false information will go to Digital Diskus decision makers. Poor or perhaps even disastrous decisions might result. The decision makers are dependent upon the accuracy of the business analytics.
An overflow condition as data are being processed could cause the data gathering module to exit into the operating system and give escalated privileges to an attacker. In order to exercise this sort of vulnerability, the attacker must present the exploit code encapsulated within the data that’s being processed.
How might an attacker deliver such a payload? The obvious answer to this question will be to take over a data source in some manner. This, of course, would require an attack of the data source to be successful and becomes a “one-two punch.” However, it’s not that difficult. If the attacker can deliver a payload through one of the many exposed applications that Digital Diskus maintains, the attack can rest in a data store and wait until the lucky time when it gets delivered to the business analytics system. In other words, the attacker doesn’t have to deliver the payload directly to Data Gathering. She or he must somehow deliver the attack into a data store where it can wait patiently to be brought into the data gathering function.
You may remember from the architecture examination that Data Gathering is running concurrently with the business analytics processing system? This means that a data gathering compromise might affect much of the core business analytics system due to the manner in which business analytics has been deployed at Digital Diskus. Each of the three modules running concurrently and in parallel on the processing server becomes an avenue to take over not just the server, but the other two modules. In other words, the security posture of each of the three modules running on that core server profoundly affects the security posture of all three.
The reporting module primarily presents a user interface. To do so, Reporting reads data that’s been processed by the business analytics system. As such, it certainly has an attack surface in its user interface. And one could make a case that an attacker might get through all the processing that takes place within Data Gathering and the analysis engine, thus delivering an attack into the results store. However, there’s a great deal of processing that happens between Data Gathering and processing. The data will have been read, preprocessed, and continuously manipulated in order to produce results. It is far more likely that an attack will have an effect on either the Data Gathering or processing so long as the reporting module does not take data in any native format. In this system, the reporting module does not handle data from any sources. Its input is strictly limited to the processed results. In Figure 8.3, you can see that Reporting’s arrow points towards the processing store—this indicates a read operation initiated from Reporting.
The architecture, as described, leaves the system dependent on the defenses that are built into Data Gathering. If it doesn’t do its job to protect the entire system from malicious or bad data, an attack could slip through into the processing module. An attack might even make it all the way through into the results, at least hypothetically.
If I were designing the business analytics system, I would place my defenses within the data gathering module (“Data Gathering”). However, Digital Diskus has purchased the business analytics system and thus has little or no control over the innate protections that have been built into the system. With no further information, an assessment would have to mark as a significant risk malicious payloads within data. We can, at the very least, count Data Gathering as one of our attack surfaces for further investigation into what mitigations may exist to protect the business analytics system. I would have important questions for the programming team of the business analytics vendor.
A further investigation over which Digital Diskus does have direct control will be into the protections that the source data systems provide against a malicious payload aimed at business analytics. If an assessment cannot, with some certainty, mitigate an attack surface, the assessment can move outwards to other protections that lie beyond the system under assessment, that is, what protections exist within the connected systems (in this case, the data sources). Or, failing there, move continuously outward through the chain of interactions and perimeters to build a set of defenses. Perhaps it is actually rather difficult for an attacker to get a payload into any data source due to the layers of defense surrounding the data sources?
If there is high confidence that the protections are in place around and within data sources, then the likelihood of a successful attack through Data Gathering will lower significantly. Since business analytics is a third-party system, the best defense will be to find the attack surfaces leading to primary attack surfaces of the business analytics and to secure these. These other systems are under direct control, as compared to this third-party system, business analytics.
There still remains a possible attack surface in the processing store. If an attacker can introduce a payload to the reporter, they may be able to compromise that module, or even compromise the core system. Although we have noted that passing an attack through all the processing that takes place from data source to the processed results should be fairly difficult if business analytics is written defensively, if the permissions to the data store are not set correctly, this would allow an attacker to drop an attack to the Reporter “from the side,” that is, by compromising the results store directly. The results most certainly present an attack opportunity if the permissions on the results store are not set defensively, which, in this case means:
- • Processing store is only mounted on the host that runs Processing and Reporter
- • Write permission is only granted to Processing
- • Read permission is only granted to Reporter
- • Only a select few administers may perform maintenance functions on the processing data store
- • Every administrative action on processing store is logged and audited for abnormal activity
In Figure 8.3, you can see an arrow from Reporter to Processing. This is a command and control channel allowing users to initiate processing and analytics while they are viewing results. This is, of course, an additional attack surface to Processing. If an attacker can either gain control of processing or slip a payload through the reporting module’s inputs specifying processing actions, then a payload might be delivered to the processing module. As we noted above, the communications between the two modules are taking place entirely through the machine, that is, the localhost network that is entirely contained within the kernel of the operating system on the host. In order to subvert these communications, an attacker would already “own,” that is, would have completely compromised the superuser privileges, the underlying host’s operating system. At that point, the attacker has complete control and, thus, has no reason to prosecute another exploit. There is no additional attacker value to subverting the localhost communications, as these and the process execution space of all three modules are under attacker control.
There are two other systems whose connections with business analytics we have not yet examined. The identity system provides authentication to the various interfaces of the business analytics system. And you will see that there is a security event monitoring system that collects events of interest from business analytics, as it does from many systems within the enterprise architecture.
Because business analytics was written as an enterprise-grade system, not only does it have an integral authorization mechanism, but it can also make use of either of two typical enterprise group membership functions: Microsoft Active Directory or an LDAP directory. Since Active Directory can also function as an LDAP, systems requiring authentication and group membership (pseudo authorization) services can leverage either or both of Active Directory’s supported protocols. It is rare that an enterprise- grade system does not, at the very least, support the LDAP protocol. Organizations that manage their identities through Active Directory can make use of that identity system for the whole enterprise rather than programming authentication and authorization information into each application. This is precisely the case with this business analytics system at Digital Diskus. Digital Diskus maintains Active Directory as a foundational enterprise infrastructure system.
Consolidating various identity systems that had become unmanageable through organic accretion some years ago, Digital Diskus collapsed customer, partner, and employee identities into its Active Directory. Therefore, at the company, there is a single identity system that the other applications may make use of. Indeed, the company makes broad use of Active Directory groups such that membership in a group may be used to give rights to the various applications that make use of Active Directory Although not a true role-based access (RBAC) system, this approach is quite common. Before permission for access is granted, membership in the appropriate group is consulted, providing a fairly simple approach to enterprise authorization. Digital Diskus has provided a self-service interface for group creation and maintenance. In addition, some of the most coarse-grained groups, such as employee, partner, or customer, are automatically populated; membership in one of these enterprise-wide groups depends upon which relationship the identity has with Digital Diskus.
The details of identity management are beyond the scope of this book. However, security architects typically have to have a fair sense of how identities are managed, what systems are employed for identities, how identities get populated if groups are being used, and which groups get populated through automation and which groups are populated manually. Furthermore, the system for granting permissions and group membership should also be understood, as, obviously, if an attacker can gain membership to a restricted group, they then gain those privileges inappropriately.
The business analytics management console and the business analytics reporting console restrict users based on authentication to the active directory. In addition, rights to the coarse-grained roles within the system, such as user, executive, and administrator, are granted through group membership. Membership in the appropriate group is granted through an approval process. Not every employee or any other class of identity type is summarily granted access to the sensitive system. There is an approval process; for the purposes of this example assessment, we don’t need to go into the details of that approval process. Nevertheless, in this type of assessment in a real organization, the assessor should understand the group membership process since it must be considered as a part of the system’s defenses.
An interesting question poses itself when considering these two systems, both of which are considered very sensitive by the company. Which system provides an attack vector to the other? When the business analytics system requests an authentication, is it possible that an attack could be promulgated from the Active Directory backwards in the response? When the business analytics system requests a determination on group membership, likewise might a response contain an attack?
On the other hand, can Active Directory be attacked through authentication and authorization requests?
The answers to each of these questions I believe would be, “Yes.” Each system is at risk of attack from the other. There are two mitigating factors that may be considered. Active Directory is a trusted system to every other system that makes use of the authentication and authorization services. If Active Directory fails, many other systems that are dependent upon it will also fail. Identity systems such as Active Directory are typically considered to be among the “crown jewels” of any organization’s data and systems. Consequently, an organization that doesn’t sufficiently protect its identity system has already degraded its security posture dramatically. The subject of identity system protections, just as identity systems themselves, can and should be an entire book by itself.
Indeed, the identity system, though interacting with our business analytics system, is out of scope. Identity systems are typically regarded as part of the infrastructure. As we know, the strengths and the weaknesses of the infrastructure are inherited by the systems that are deployed upon them. And any system that is foundational to customer interaction, the business ecosystem, and the internal business systems must be regarded as highly sensitive. Nevertheless, the identity system does not depend upon the business analytics but rather the reverse. That will be a key factor in answering the question about which system poses a danger to the other.
Data Gathering most certainly presents an attack surface when it reads the identity stores: to gather data about the various entities, such as employees, partners, and customers, whose identities are maintained by Active Directory. Similar to any data source, the identity data might contain an attack to the data gathering function. Since data from identity are gathered via native Active Directory protocols, business analytics must maintain credentials that have privileges to read this data.
As we have noted above, Active Directory is highly protected by this organization. Therefore, although we have uncovered an attack surface, attack from this data source, as compared to the many other data sources from which Data Gathering must collect, is probably unlikely. However, the astute assessor will note that business analytics now becomes part of the Active Directory security posture because Data Gathering must have privileges to the identity store in order to correlate other business data with identities and identity metrics. Although Active Directory as a system is outside of scope, because Active Directory is at such a deep level of sensitivity, risk for the identity system would have to be noted because of the rights that the business analytics system must maintain in order to access identity formation from Active Directory. In other words, business analytics significantly poses an attack vector to Active Directory, as opposed to the other way around.
As we have underscored repeatedly, security assessment must be done holistically. And further, if the assessment has a due diligence responsibility to uncover risks for the organization, the dependence of Active Directory’s security posture upon the posture of business analytics would have to be noted as a part of the threat model for Active Directory at Digital Diskus.
Irrespective of the scope of this particular assessment, systems interconnect. When they do, the security posture of each system can significantly affect or alter the security posture of the other systems to which it connects. In this case, business analytics must become a part of the tight security posture around the identity system. In addition, the security requirements for business analytics must match those of this very sensitive identity system, at least for the credentials.
It should be noted that, most certainly, Microsoft understands the criticality of Active Directory as a foundational part of many organizations’ infrastructures. There’s no doubt that they take the security posture of the system quite seriously. It’s a safe bet that Microsoft attempts as rigorous a set of protections as they can implement, knowing full well that entire enterprise architectures are dependent upon the security posture of Active Directory. With that in mind, let’s assume, for the purposes of this assessment, that Active Directory is in fact protectable, in general, and, in this instance, has been configured to be sufficiently protected. With this assumption, we can be satisfied that it will be very difficult to launch an attack through the Active Directory to our business analytics system.
The foregoing analysis hopes to answer the question posed earlier: Which of the two systems affects the security posture of the other? Theoretically, the answer is that influence is bidirectional. However, we concern ourselves with how business analytics affects the security posture of Active Directory and not, for this analysis, the other way around.
There is another system that interacts with business analytics: the security monitoring system. The security monitoring system will monitor the activities and changes on the hosts that support business analytics modules. This would be a normal part of the security of a mature administration function, as we have previously described. Importantly for this assessment, changes to the configuration file are logged; those change logs are audited for suspicious events. In this way, if an attacker does manage to breach the protections around the configuration files, hopefully, such anomalous activities will be noted quickly. The goal of this sort of monitoring is to stop any malicious activity before it can do serious damage. A further goal is to let administrators know that someone is independently paying attention to events. This type of monitoring is typical and would be described in any number of security standards covering the security of administrative activities.
Does security monitoring pose an attack surface for either business analytics or the security monitoring system? Typically, the security monitoring system gathers change logs that are output by a system and by the operating system. Usually, the logs sit on disk until collected, at which point they may be archived or deleted. Similar to the data gathering activities of the business analytics system, the security monitoring system will be at some risk to attacks embedded within the logs. And it would be very difficult to sell a security monitoring and event correlation system if it was easy to compromise the monitoring system. Although such weaknesses have been discovered in security monitoring systems, vendors depend upon the rigorousness of their processing defenses so that they can successfully sell their systems.
The security monitoring and correlation system will also be considered part of the security infrastructure. Furthermore, a security monitoring system will operate as one of the most sensitive systems an organization maintains. Therefore, all due care should be taken in purchasing and implementing as bulletproof a system as humanly possible. One of the differences between a security event managing system and other systems will be that a security system expects to be attacked and should be built with industrial-strength defenses. When implementing such a system, all due diligence should be taken to make sure that purchased components have many integral defenses, that these defenses are in depth, and that the implementation instance takes advantage of all of the defenses possible.
We have yet another situation where a highly sensitive system, security monitoring, might be profoundly affected by the security of business analytics, just as the identity system, Active Directory, was affected by business analytics. Let’s assume, for the moment, that the security monitoring system is a rigorous, industrial-strength security system that protects itself very carefully from malicious data in logs and other event sources.
In this situation, the monitored outputs coming from business analytics are not the system’s analysis results, but rather, come from the application about its activities. At least some of this output would be the result of the programming logic steps of the application. Items like data accesses, the size of the access, maybe even details about the data retrieved, might get logged by Data Gathering. In this way, a retrieval of data not consistent with the intentions of the programmers of the system might show up as anomalous activity that would then fire a security alert for further investigation.
However, in order to debug systems, application programmers will typically send events about internal processing steps and similar to logs, as well. In more than one system, I have seen user or other credentials that then get exposed in unprotected ways. Thus, the log files themselves might be an attack surface, not to subvert the business analytics system but rather to gain valuable information that probably shouldn’t have been logged at all. Application logs tend to be quite uncontrolled compared to other types of system outputs. If the vendor of the business analytics system was foolish enough to have placed data within the logs that contains possible attack value, that would be yet another conversation with the vendor about software security.
Nevertheless, if the log files contain juicy data about the workings of the business analytics system, or even worse, hints about the nature of the analytics results, then these would constitute a significant attack surface. One of the investigations that should be conducted would be to discover exactly what goes into the logs, ascertaining just how sensitive the information, log item by log item, or when aggregated, might be. Thus, the very act of logging data for the security monitoring system uncovers yet another attack surface.
The logs might be an attack surface against the security monitoring system, including all the mitigations that are in place against log file tampering as well as protections against attacks contained within log items. Since the logs originate solely in the business analytics application, and can only be written by business analytics for read only by security monitoring, this is a fairly long shot for the attacker. Presumably, the only people with access to business analytics code are those authorized to change it. How do they even know which security systems one of their customers may use (attacks are usually quite specific to application and execution environment)?
But the logs themselves may constitute a target if the data they contain is useful. In this case, these are simply flat files on disk. Technically, these are not a part of the formal architecture of the system but rather an output that must then be managed properly. Nevertheless, a prudent assessment would ascertain the data contained in the log files. And a prudent assessment would consider the log files as a possible target.
At this point, I urge you to consider the diagrams of business analytics once again. Do you see an attack surface that hasn’t been discussed? As far as I know, given the constraints and background information that has already been described, all the relevant attack surfaces have been uncovered.
One of the biggest mistakes that I’ve made has been overlooking a detail during assessment. That’s why I make liberal use of peer review in my assessments, because it’s easy to miss something important. I ask you, the reader, to be my peer reviewer. Have I missed anything? This is not a trick question. Pretend that I’ve performed an assessment and that now I’m asking you to peer review my work.
Another advantage of a peer review is a diversity of opinion. Each of us has a unique sense of risk, and each of us favors a unique security posture. As such, I believe it’s important to consider alternate views when prioritizing attack scenarios. I’ve given my views on several of the attack scenarios presented in this analysis that should be de-prioritized. What’s your opinion? Do you agree with me, or would you change the prioritization to raise an attack surface or attack vector or to lower one that I’ve considered important?
I suggest that you take some time and imagine yourself as the security architect responsible for the enterprise architecture of Digital Diskus. If you were implementing the business analytics system for this enterprise and enterprise architecture, how would you protect the business analytics system and the systems with which it interacts?
The following section comprises a list of the attack surfaces that have been uncovered during this analysis.
Attack Surface Enumeration
- • Data gathering credentials store
- • Data source credential inputs
- • Data gathered from sources
- • Business analytics message bus listeners
- • Analytics results store
- • Analytics results presentation (“Reporter”)
- • Configuration files and system metadata
- • Management console inputs
- • Management console configuration outputs
- • Management console host
- • Processing module input from Data Gathering
- • Processing input from Reporter (commands)
- • Processing module configuration file
- • Data Gathering module
- • Data Gathering module configuration file
- • Data Gathering inputs, especially from data sources
- • Data source agents
- • Communications with data sources
- • Reporting module user interface
- • Reporting module configuration file
- • Business analytics activity and event log files
-  hough, most certainly, each native protocol should be considered within the larger scope ofthe organization’s security posture.
-  * “Host” in this instance means a “logical” host. here will be several of these servers to scalethe processing and for redundancy, in case of failure.
-  Data Gathering is shown in Figure 8.3.