Your work over the next coming weeks will lead-up to your ability to represent an enterprise security architecture solution as a diagram or diagrams with annotations. The project involves depicting a Security Architecture for one of the following businesses: 

· Financial (Bank, brokerage, Insurer, etc.) 

· Hospital/Medical Services 

· Pharmaceutical/Chemical 

· Social Media Company 

· Energy Company (Electrical Utility, Oil Company, Solar, Wind, etc.) 

· Manufacturer (Automobile, Computer, Consumer Electronics, etc.) 

There are 2 milestone deliverables for the project: 

Milestone 1: Project Abstract, Goals and Approach (Words limit: 1000) APA format

· Identify the business type you have selected for your paper.

· Provide a brief overview of the business

· Provide the goals and approach to the project

Milestone 2: Architectural diagrams and annotations (Words limit: 1500-2000) APA format

· Milestone 2 will include all materials from Milestone 1 and 

· Architectural diagrams and annotations

Text Book:   

Schoenfield, Brook S.E. – Securing Systems: Applied Security Architecture and Threat Models, CRC Press,  2014 ISBN: 978-1-4822-3397-1

School of Computer & Information Sciences

ISOL-536 – Security Architecture & Design

Chapter 8: Business Analytics

Spring 2020

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.

School of Computer & Information Sciences

ISOL-536 – Security Architecture & Design

Chapter 7: Enterprise Architecture

Spring 2020

Chapter 7: Enterprise Architecture
7.1 Enterprise Architecture Pre-work: Digital Diskus
7.2 Digital Diskus’ Threat Landscape
7.3 Conceptual Security Architecture
7.4 Enterprise Security Architecture Imperatives and Requirements
7.5 Digital Diskus’ Component Architecture
7.6 Enterprise Architecture Requirements

Chapter 7: Enterprise Architecture – Cont.
When a security architect interacts with an enterprise architecture, the work is at a very strategic level. The ATASM process only loosely applies. There isn’t sufficient specificity in an enterprise architecture to develop a threat model. Once the architecture begins to be factored into components, it becomes an alternate, logical, and/or component view.
For the security architect concerned with building security systems, there is typically a need for an enterprise security architecture view. Or perhaps like the Open Group’s Reference Security Architecture, the strategic vision may be expressed as an enterprise reference security architecture.
Instead, at the enterprise level one can concentrate on the security features for major groups of users. Is there a need to keep identities? Identity must be kept for each of the different groups of users. For instance,
Customers
Internal analysts
Customer service and support
Administrative staff
Executives

Chapter 7: Enterprise Architecture – Cont.
Figure 7.1 reprises the enterprise architecture that was introduced in Chapter 3. Study it for a moment and consider the implications of each of the functions represented.
Figure 7.1 Enterprise conceptual architecture.

Chapter 7: Enterprise Architecture – Cont.
Enterprise architecture, whether concerned with security or not, is as much about vision and strategy as it is about documenting what should exist today. As you consider the questions posed above about the architecture presented in Figure 7.1, think not just about what might be needed today, but about how this architecture will need to be protected on into the future, as it grows and matures.
Thinking about the ATASM process, we do not know anything about the purpose of this enterprise architecture, or the organization that fields it. Although we can certainly make some guesses that help, the first step, as previously laid out, is to research the purpose of an architecture in the context of the organization’s objectives.
Even though analyzing an enterprise architecture in isolation from the organization is a relatively artificial situation, as a methodology for learning and practicing, let’s pretend that we, the security architects, have just encountered an enterprise architecture about which we know nothing.

7.1 Enterprise Architecture Pre-work: Digital
Diskus
This enterprise is called Digital Diskus. They design, manufacture, and sell networking routing equipment. Digital Diskus’ customers are medium and large organizations that must maintain extensive networking infrastructure. The company has a sales force, as well as channel partners—companies that provide networking equipment and networking expertise to their customers. These partners install, configure, and, perhaps, also run large and complex networks. Digital Diskus’ vision statement is, “Design and build the most dependable and the easiest to configure networking equipment.”
Digital Diskus’ sales are placed through the company’s Internet facing eCommerce site. Sales can be made directly by a customer via an online store front, through one of the partners, or through the direct sales force. The company tries to automate their supply chain as much as possible, so there is a need for automated interchange between the parties within the supply chain and throughout the purchasing ecosystem, just as there is within the sales process.
Digital Diskus’ goal is to provide highly dependable solutions in which customers can have great confidence. Quality is much more important than price. A prolonged mean time before failure (MTBF) is considered a competitive advantage of the company’s networking products.

7.2 Digital Diskus’ Threat Landscape
Since Digital Diskus’ products include encryption implementations, might one or more entities be interested in the cryptography implementations? What if the company’s products are deployed by governments, some of whom are hostile to each other? Might one or more of these nation-states be interested in manipulating or compromising cryptography in use within the networks of one of its enemies?
The attackers reportedly first gained access to Target’s system by stealing credentials from
an HVAC and refrigeration company, Fazio Mechanical Services, based in Sharpsburg,
Pennsylvania. This company specializes as a refrigeration contractor for supermarkets
in the mid-Atlantic region and had remote access to Target’s network for electronic
billing, contract submission, and project management purposes.
Digital Diskus staff are concerned with four major classes of threat agents:
Industrial spies
Cyber criminals
Cyber activists
Privileged insiders

7.3 Conceptual Security Architecture
Typically, a conceptual architecture is trying to diagram gross functions and processes in relationship to each other in as simple a manner as possible. Simplicity and abstraction help to create a representation that can be quickly and easily grasped—the essence of the enterprise is more important than detail. An enterprise architecture tend stoward gross oversimplification.
Although it is possible to build one single presentation layer through which all interactions flow, if legacy applications exist, attaining a single presentation layer is highly unlikely. Instead, the diagram seeks to represent the enterprise as a series of interrelated processes, functions, and systems. A great deal of abstraction is employed; much detail is purposely obscured.
This architecture is intended to underline that business processing must not make its way into the presentation layers of the architecture. Presentations of digital systems should be distinct from the processing; systems should be designed such that they adhere to this architectural requirement.

7.4 Enterprise Security Architecture Imperatives
and Requirements
As we explored earlier, industrial espionage actors may employ sophisticated attack methods, some of which may have never been seen before. And, espionage threat agents’ attacks can span multiple years. They will take the time necessary to know their quarry and to find weak points in the systems and people who constitute the target. Therefore, at the enterprise level, decision makers will have to be prepared to expend enough resources to identify “low and slow” intrusions.
In previous Figure 7.1 you saw that almost every function is connected to the integration systems. Whereas all applications, or least most of them, are integrated through technologies such as a message bus, one of the architectural imperatives will be application to application and application-to-message bus access control. That is, each contained set of functionalities is allowed only to integrate through the controlled integration system (the message bus) on an as-needed and as-granted basis. No application should have unfettered access to everything that’s connected to the integration system (here, the message bus and other integration mechanisms).

7.4 Enterprise Security Architecture Imperatives
and Requirements – Cont.
By analyzing the conceptual enterprise architecture, taking into account Digital Diskus’ mission and risk appetite, and in light of the relevant threat landscape, we have uncovered the following conceptual requirements:
Strict administrative access control.
Strict administrative privilege grant.
Mature administrative practices (cite NIST 800-53 or similar).
Robust and rigorous monitoring and response capabilities (external and internal).
Strict user access controls (authentication and authorization).
Access control of automated connection to integration technology, especially the enterprise message bus.
Policy and standards preventing unfettered send or receive on the message bus, coupled to strict, need-to-communicate, routing on the bus.
Application message recomposition when a message is sent from external to internal systems.
Encryption of message bus communications.

7.5 Digital Diskus’ Component Architecture
Figure 7.2 begins the process of separating the conceptual architecture given in Figure 7.1 into its constituent components. We continue to operate at the enterprise level of granularity, that is, view the architecture at a very abstract level. Individual technologies and implementations are ignored. This view seeks to factor the concepts presented previously into parts that suggests systems and processes. We have taken the liberty to also introduce a distinction in trust levels and exposure by separating the internal from the external, web presences from business ecosystem connections (the “extra-net” cross hatching in the upper right), and to even distinguish between cloud services and the Internet.

7.5 Digital Diskus’ Component Architecture – Cont.
Figure 7.3 adds data flows between the components depicted on the enterprise components view. Not every component communicates with every other. However, functions such as process orchestration will interact with many applications and many of the databases and data repositories. Each instance of a particular orchestration will, of course, only interact with a select few of the components. However, at this gross level, we represent orchestration as a functional entity, representing all orchestrators as a single component. Hence, you will see in Figure 7.3 that Process Orchestration interacts with a wide variety of the internal systems. In addition, Orchestration has access to the Message Bus, which pierces the trust boundary between internal and external systems, as described above.

7.5 Digital Diskus’ Component Architecture – Cont.
Figure 7.3 then becomes too “busy,” or “noisy,” to be useful, even if this figure does represent in some manner, flows between components. At this point in an assessment, the architecture should be broken down into subsystems for analysis. Hence, we will not continue the assessment of this enterprise architecture any further. Even using a gross component view at the enterprise level, an assessment focuses upon the general security strategy for the enterprise:
Threat landscape analysis
Organizational risk tolerance and posture
Security architecture principles and imperatives
Major components of the security infrastructure (e.g., identity and security operations)
Hardening, system management, and administrative policies and standards

7.6 Enterprise Architecture Requirements
At the enterprise level, security requirements are generally going to devolve to the security infrastructure that will support the enterprise architecture. That is, the conceptual “security services” box in the enterprise conceptual diagram will have to be broken out into all the various services that will comprise those security services that will form an enterprise security infrastructure.
Therefore, we assume for the relevant subsequent assessment examples that a security infrastructure is in place and that it includes at least the following:
Firewalls that restrict network access between network segments, ingress, and perhaps, egress form the enterprise architecture.
An ability to divide and segment sub-networks to trusted and untrusted areas that define levels of access restriction.
An administrative network that is separated and protected from all other networks and access to which is granted through an approval process.
A security operations Center (SOC) which monitors and reacts to security incidents.
An intrusion detection system (IDS) whose feeds and alerts are directed to the SOC to be analyzed and, if necessary, reacted to
The ability to gather and monitor logs and system events from most if not all systems within the enterprise architecture.
An audit trail of most if not all administrative activities that is protected from compromise by administrators
An enterprise authentication system
Some form of enterprise authorization

Chapter 7: Summary
Once an organization grows to a complexity that requires an enterprise view, this view usually includes existing systems while at the same time expressing a vision for the future architecture. There will be a mix of existing systems and functions, based upon an existing infrastructure while, at the same time, articulating how the goals of the organization can be accomplished in a hopefully cleaner and more elegant manner.
Enterprise architecture, whether concerned with security or not, is as much about vision and strategy as it is about documenting what should exist today.