Assignment#4

 Briefly respond to all the following questions. Make sure to explain and backup your responses with facts and examples. This assignment should be in APA format and have to include at least two references.

Figure 8.1 Business analytics logical data flow diagram (DFD).

Consider the data flow “octopus,” as shown in Figure 8.1. How can the analysis system gather data from all these sources that, presumably, are protected themselves?

Minimum 600 words

urgentNo PlagiarismAPA Format

University of the Cumberlands
School of Computer & Information Sciences

ISOL-536 – Security Architecture & Design

Chapter 8: Business Analytics

Spring 2020

Dr. < your name >

Chapter 8: Business Analytics
8.1 Architecture
8.2 Threats
8.3 Attack Surfaces
8.3.1 Attack Surface Enumeration
8.4 Mitigations
8.5 Administrative Controls
8.5.1 Enterprise Identity Systems (Authentication and Authorization)
8.6 Requirements

8.1 Architecture
Data science is a set of fundamental principles that guide the extraction of knowledge from data. Data mining is the extraction of knowledge from data via technologies that incorporate these principles.
Like many enterprises, Digital Diskus has many applications for the various processes that must be executed to run its business, from finance and accounting to sales, marketing, procurement, inventory, supply chain, and so forth. A great deal of data is generated across these systems. But, unfortunately, as a business grows into an enterprise, most of its business systems will be discreet. Getting a holistic view of the health of the business can be stymied by the organic growth of applications and data stores.
The system shown in Figure 8.1 (next slide) comprises not only the business analytics and intelligence but also the many enterprise systems with which analytics must interact. In order to consider the entire system, we must understand not only the architecture of the business analysis system itself, but also its communications with other systems.

8.1 Architecture – Cont.
Figure 8.1 Business analytics logical data flow diagram (DFD).

8.1 Architecture – Cont.
Figure 8.2 Business analytics data interactions.
Figure 8.2 is a drill down view of the data gathering interactions of the business analytics system within the enterprise architecture. Is the visualization in Figure 8.2 perhaps a bit easier to understand? To reiterate, we are looking at the business analysis and intelligence system, which must touch almost every data gathering and transaction-processing system that exists in the internal network. And, as was noted, business analytics listens to the message bus, which includes messages that are sent from less trusted zones.

5

8.2 Treats
Figure 8.3 Business analytics system architecture.
As we move to system specificity, if we have predefined the relevant threats, we can apply the threats’ goals to the system under analysis. This application of goals leads directly on to the “AS” of ATASM: attack surfaces. Understanding your adversaries’ targets and objectives provides insight into possible attack surfaces and perhaps which attack surfaces are most important and should be prioritized.
It’s useful to understand a highly connected system like business analytics in situ, that is, as the system fits into its larger enterprise architectural context. However, we don’t yet have the architecture of the system itself. Figure 8.3 presents the logical components of this business analytics system.
There are five major components of the system:
1. Data Analysis processing
2. Reporting module
3. Data gathering module
4. Agents which are co-located with target data repositories
5. A management console

6

8.3 Attack Surfaces
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?
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?
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.

7

8.3 Attack Surfaces – Cont.
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.
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.

8

8.3 Attack Surfaces – Cont.
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.
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

9

8.3.1 Attack Surface Enumeration

10

8.4 Mitigations
As you consider the attack surfaces in the list on the previous slide, what security controls have already been listed?
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?”
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.
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.

11

8.5 Administrative Controls
Access will be restricted to a need-to-know basis. As we have noted, changes to the systems are monitored and audited. At the application level, files and directories will be given permissions such that only the applications that need to read particular files or data are given permission to read those files. This is all in accordance with the way that proper administrative and operating system permissions should be set up. The business analytics systems and tools don’t require superuser rights for reading and executing everything on the system. Therefore, the processing unit has rights to its configuration files and data gathering module files. The reporting module reads its own configuration files. None of these can write into the configuration data. Only Management Console is given permission to write data into the configuration files. In this way, even if any of the three processing modules is compromised, the compromised component cannot make use of configuration files to compromise any of the other modules in the system. This is how self-defensive software should operate. Business analytics adheres to these basic security principles, thus allowing the system to be deployed in less trusted environments, even less protected than what Digital Diskus provides.

12

8.5.1 Enterprise Identity Systems (Authentication
and Authorization)
Authentication via the corporate directory and authorization via group membership still remain two of the important mitigations that have been implemented.
Having reviewed the available mitigations, which attack surfaces seem to you to be adequately protected? And, concomitantly, which attack surfaces still require an adequate defense?

13

8.6 Requirements
In order to prevent an attacker from obscuring an attack or otherwise spoofing or fooling the security monitoring system, the business analytics activity and event log files should only be readable by the security monitoring systems. And the log files permissions should be set such that only event-producing modules of the business analytics system may write to its log file. Although it is true that a superuser on most operating systems can read and write any file, in this way, attackers would have to gain these high privileges before they could alter the log files that will feed into the security monitoring system.
Table 8.1 (next slide) summarizes the additional security requirements that Digital Diskus will need to implement in order to achieve the security posture required for this sensitive system, the business intelligence and analytics system.

14

8.6 Requirements – Cont.
Table 8.1 is not intended as a complete listing of requirements from which the security architecture would be designed and implemented. As I explained above, when I perform a security architecture analysis, I try to document every requirement, whether the requirement has been met or not. In this way, I document the defense-in-depth of the system. If something changes during implementation, or a security feature does not fulfill its promise or cannot be built for some reason, the requirements document provides all the stakeholders with a record of what the security posture of the system should be. I find that risk is easier to assess in the face of change when I’ve documented the full defense, irrespective of whether it exists or must be built.

15

Chapter 8: Summary
The architect (or peer reviewing architect team) must decide the scope of the risk’s possible impact (consequences). The scope of the impact dictates at what level of the organization risk decisions must be made. The decision maker(s) must have sufficient organizational decision-making authority for the impacts. For instance, if the impact is confined to a particular system, then perhaps the managers involved in building and using that system would have sufficient decision making scope for the risk. If the impact is to an entire collection of teams underneath a particular director, then she or he must make that risk decision. If the risk impacts an enterprise’s brand, then the decision might need to be escalated all the way to the Chief Operating Officer or even the Chief Executive, perhaps even to the Board of Directors, if serious enough. The scope of the impact is used as the escalation guide in the organizations for which I’ve worked. Of course, your organization may use another approach.