12 Nov 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?
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?
Answer the question with a short paragraph, with a minimum of 300 words. APA formatting but do not include a title page, abstract or table of contents. Body and references only in your post.
A minimum of two references are required. One reference for the book is acceptable but multiple references are allowed. There should be multiple citations within the body of the paper. Note that an in-text citation includes author’s name, year of publication and the page number where the paraphrased material is located.
University of the Cumberlands School of Computer & Information Sciences
ISOL-536 – Security Architecture & Design
Chapter 7: Enterprise Architecture
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.
Figure 7.2 Enterprise component architecture.
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.
Figure 7.3 Enterprise component flows.
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.
Chapter 7: Summary
END
image4.emf
image5.emf
image6.emf
image1.emf
image2.emf
