Due tomorrow 7/12/2021 at 8:00pm No plagiarism Develop those five critical thinking indicators. 1) effective communication 2) Logical and Intuitive 3) Thinking ahead 4) Realistic and Practical 5) confident 1. the paper must clearly define five critical thinking indicators. 2. The paper includes a complete and thoughtful explanation of why you chose these indicators. 3. The paper must describe a thoughtful and appropriate response to the case study scenario that clearly incorporates critical thinking skills to make decisions. 4. Must have case study for each point or indicators 5. The paper clearly and accurately identifies which of the previously defined critical thinking indicators were used in addressing the case study. 6. Factors that supported and that impacted the ability to think critically were identified and described clearly. 7. Strategies for future improvement were clear and appropriate for the scenario. 8. The paper is in APA format, and all writing is clear and professional, with sources cited and references provided in all cases needed. University of the Cumberlands School of Computer & Information Sciences ISOL-536 - Security Architecture & Design Chapter 8: Business Analytics Spring 2020 Dr. Yehia Mohamed 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 ...

1. Due tomorrow 7/12/2021 at 8:00pm
No plagiarism
Develop those five critical thinking indicators.
1) effective communication
2) Logical and Intuitive
3) Thinking ahead
4) Realistic and Practical
5) confident
1. the paper must clearly define five critical thinking indicators.
2. The paper includes a complete and thoughtful explanation of
why you chose these indicators.
3. The paper must describe a thoughtful and appropriate
response to the case study scenario that clearly incorporates
critical thinking skills to make decisions.
4. Must have case study for each point or indicators
5. The paper clearly and accurately identifies which of the
previously defined critical thinking indicators were used in
addressing the case study.
6. Factors that supported and that impacted the ability to think
critically were identified and described clearly.
7. Strategies for future improvement were clear and appropriate
for the scenario.
8. The paper is in APA format, and all writing is clear and
professional, with sources cited and references provided in all

2. cases needed.
University of the Cumberlands
School of Computer & Information Sciences
ISOL-536 - Security Architecture & Design
Chapter 8: Business Analytics
Spring 2020
Dr. Yehia Mohamed
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)

3. • 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).

4. 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.
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.

5. • 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
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

6. 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 wi ly
attacker has access to the outputs of
Management Console, then the attacker may gain the credentials
to many systems.
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.

7. • 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.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

8. audited for abnormal activity
8.3.1 Attack Surface Enumeration
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 possibl e 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

9. implementation details unknown.
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.
8.5.1 Enterprise Identity Systems (Authentication
and Authorization)

10. • 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?
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.
8.6 Requirements – Cont.

11. • 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.
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

12. in the organizations for which I’ve worked.
Of course, your organization may use another approach.