University of the Cumberlands School of Computer & Information Sciences ISOL-536 - Security Architecture & Design Chapter 8: Business Analytics 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. 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.

1. University of the Cumberlands
School of Computer & Information Sciences
ISOL-536 - Security Architecture & Design
Chapter 8: Business Analytics
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,

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

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

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

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

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

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

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

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

10. 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.
Chapter 8: Summary
END
University of the Cumberlands
School of Computer & Information Sciences
ISOL-536 - Security Architecture & Design
Chapter 9: Endpoint Anti-malware
Chapter 9: Endpoint Anti-malware
9.1 A Deployment Model Lens
9.2 Analysis
9.3 More on Deployment Model
9.4 Endpoint AV Software Security Requirements

11. Chapter 9: Endpoint Anti-malware
Figure 9.1 Endpoint security software.
For the business analytics example, we knew something about
the protections— both technical and process—that were applied
to the host and operating system upon which the core of the
business analytics system runs in that environment.
Consequently, we discounted the ability of an attacker to listen
in on the kernel-level communications, most particularly, the
“localhost,” intra-kernel network route. Additionally, if an
attacker has already gained sufficiently high privileges on the
system to control processes and perhaps even to access process
memory, “game over.”
9.1 A Deployment Model Lens
The user is installing antivirus software in response to the belief
that the machine is already compromised. In other words,
endpoint security software must assume that, very similar to
software exposed to the public Internet, it is being installed into
an aggressively hostile environment. Any assumptions about the
operating system being free of successful compromises would
cause the endpoint antivirus software, itself, to become a juicy
target. At the very least, assumptions about a safe environment
might lead security software makers to believe that they don’t
have to take the care with their security posture that, in fact, is
demanded by the real-world situation.
The foregoing leads us to two axioms:
Assume active attackers may be on the machine even at
installation time.
Assume that attackers will poke and prod at every component,
every input, every line of communication.

12. 9.2 Analysis
In consumer-oriented products, the user will have the ability to
turn security functions off and on. In corporate environments,
usually only system administrators have this power. The user
interface can take control of the security of the system. That, of
course, makes the user interface component an excellent target
for attack. Likewise, the AV Engine performs the actual
examination to determine whether files and traffic are
malicious. If the engine can be fooled, then the attacker can
execute an exploit without fear of discovery or prevention.
Consequently, a denial of service (DoS) attack on the AV
Engine may be a very powerful first step to compromising the
endpoint. To contrast this with the user interface, if the attacker
is successful in stopping the user interface the security services
should continue to protect, regardless. On the other hand, if the
attacker can stop the AV Engine, she or he then has access to an
unprotected system. Each of these components presents an
important target; the targets offer different advantages,
however.
Testing shows the presence, not the absence of bugs.
9.2 Analysis – Cont.
The AV engine itself will have to be written to be as self-
defensive as possible. Even if the AV engine validates the user
interface before allowing itself to be configured by the user
interface, still, those input values should not be entirely trusted.
The user interface may have bugs in it that could allow attacker
control. In addition, the user interface might pass an attack
through to the engine from external configuration parameters.
The AV engine has another input. In order to determine whether
files are malicious, they may have to be opened and examined.
Most certainly, in today’s malware-ridden world, a percentage

13. of the files that are examined are going to contain attacks.
There’s nothing to stop the attacker from placing attacks in
suspicious files that go after any vulnerabilities that may lie
within the file examination path. Thus, the AV Engine must
protect itself rigorously while, at the same time, examining all
manner of attack code. In fact, the entire path through which
evil files and traffic pass must expect the worst and most
sophisticated types of attacks. The file open, parse, and
examination code must resist every imaginable type of file-
based attack.
9.2 Analysis – Cont.
Figure 9.2 Endpoint security software with management.
In Figure 9.2, we can see that the system engages in
communications with automated entities beyond the endpoint
itself. Even if this were not true, a communicator might be
employed for intermodule communications within the system. In
this case, the simple, independently operating case, it would be
a matter of design style as to whether to abstract
communications functions into a separate module. The design
was chosen in this case, not only because the system does in
fact support inbound and outbound communications (as depicted
in Figure 9.2) but also for reasons of performance.
24
9.3 More on Deployment Model
To make matters more complex, the validity of the update must
be established such that it hasn’t been tampered with between

14. manufacturer and download at the endpoint (integrity). In fact,
most security vendors don’t want the threat agents to have the
details of what’s been prevented nor the details of how
protections work. At the least, these proprietary secrets are best
kept such that uncovering them requires a significant work
factor. Defense is better if the attacker doesn’t have the precise
details of the strategy and tactics. The foregoing general
requirement suggests that communications should be
confidential. This is particularly true when the communications
must cross untrusted networks. If updates are coming from
servers across the public Internet, then the network would not
only be untrusted but also hostile.
A working concept, when considering the security of customer
premise equipment, is to understand that different customers
require different security postures. Systems intended for
deployment across a range of security postures and approaches
will do best by placing security decisions into the hands of the
deployers. Indeed, no matter the guidance from the vendor for a
particular piece of software, customers will do what is
convenient for their situation. For instance, regardless of what
guidance is given to customers about keeping the management
console for our endpoint system off of untrusted networks,
customers will do as they wish.
9.3 More on Deployment Model – Cont.
Before deploying new software, whether the updates are to the
running modules or to the malware identification mechanisms
used by the engine, the validity of the updates must be
established. However updates are obtained for dispersal by the
management console, whether by download from the software
maker’s website, or through some sort of push outwards to the
management console, attackers attempting to insert malicious
code must be prevented. This validation could be done with a

15. standard binary hash and signature. The hash value can be
checked for validity. The signature will be made with the
private key that can be checked against the public key for
validity. This is the standard approach for this problem.
For most organizations, any system having to do with the
organization’s security will be considered sensitive and critical.
As such, the parts of the security system implementing
management of the system are typically considered need-to-
know, restricted systems and interfaces. In particular, any
system, such as this management console, that can change the
security posture of other systems requires significant protection.
9.4 Endpoint AV Software Security
Requirements
Events and data flow from kernel driver to AV Engine only
(never from engine to kernel).
Only the AV engine may open the kernel driver, and only on
system startup. “Open” is the only control operation allowed
from user mode to kernel driver. No other component may
communicate with the kernel driver.
The kernel driver startup and initialization code must validate,
sanitize, and put into canonical form inputs from AV engine.
Kernel driver initialization and startup must occur during the
operating system startup sequence and must complete before
users are allowed to log on to the system.
Kernel driver initialization must complete before user logon to
the system.
Kernel driver initialization must occur as early as is possible
during operating system startup.
Before communications are allowed to proceed between any two
or more modules in the system, validation must be performed on
the identity and integrity of the calling process/module/binary.
The preferred mechanism is validation of a digital signature

16. over the binary. The signature must be signed by the private key
of the software manufacturer.
Every other component except the kernel driver must run in user
mode.
9.4 Endpoint AV Software Security
Requirements – Cont.
Installation should confine the reading and writing of the
configuration files to the User Interface only.
The system must have the ability to encrypt communications
from/to the management console. This must be system
administrator configurable.
The management console must contain a user authentication
system.
The management console must contain a user authorization
system.
The management console must be able to authenticate to an
LDAP.
Management console authorization must be able to be performed
by LDAP group membership.
The administrator must be able to configure the management
console to use any combination of:
Local authentication
LDAP authentication
Local authorization
LDAP group membership
The user interface must re-authenticate the user before allowing
changes.
The management console will be able to run in a hardened state.
There will be a customer document describing the hardened
configuration. Hardening is configurable at customer discretion.

17. 9.4 Endpoint AV Software Security
Requirements – Cont.
Input validation coding must be implemented on every system
input, with particular care to file parsing and examination path,
the reading of the configuration files, and inputs from
Communicator.
The file and event handling paths through the code must be
rigorously fuzzed.
All components of the system must be built using a rigorous
Security Development Lifecycle (SDL), with particular
emphasis on secure coding techniques, input validation n, and
rigorous proof of the effectiveness of the SDL (i.e., security
assurance testing for vulnerabilities).
Vulnerability testing before product release must be thorough
and employ multiple, overlapping strategies and tools.
Chapter 9: Summary
As was noted, the list of requirements presented here cannot be
taken as a complete list, since some of the requirements refer to
previous discussions and are not reiterated here. For a real-
world system, I would list all requirements, so as to create a
complete picture of the security needs of the system. The
architectures presented in this book, I'll reiterate, should be
taken as examples, not as recipes.
Chapter 9: Summary
END
image4.emf
image5.emf
image6.emf

18. image7.emf
image8.png
image9.png
image10.emf
image11.emf
image1.emf
image2.emf