week 7
can you please do my assignment of
1page of discussion on:
This assignment should be in APA format and have to include at least two references.
Your initial posting should be a minimum of 400words
How should cache handling be accomplished in order to minimize the ability of the attacker to deliver a payload through the cache?
—-
and assessment of 2 pages
—
total 3 pages along with references
University of the Cumberlands
School of Computer and Information Sciences
Instructor: Dr. < Your Name >
Class: ISOL536-Security Architecture and Design
Assignment: Week 7 Individual Assignment 6
Length: Minimum of 600 words
Total points: 40 points
Due date: Sunday, February 23, 2020
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.
As you consider the reputation service and the needs of customers or individual consumers, as well as, perhaps, large organizations that are security conscious like our fictitious enterprise, Digital Diskus, what will be the expectations and requirements of the customers? Will consumers needs be different from those of enterprises? Who owns the data that is being served from the reputation service? In addition, what kinds of protections might a customer expect from other customers when accessing reputations? University of the Cumberlands
School of Computer & Information Sciences
ISOL-536 – Security Architecture & Design
Chapter 12: Patterns and Governance Deliver Economies of Scale
Spring 2020
Dr. Vululleh
Chapter 12: Patterns and Governance Deliver Economies of Scale
12.1 Expressing Security Requirements
12.1.1 Expressing Security Requirements to Enable
12.1.2 Who Consumes Requirements?
12.1.3 Getting Security Requirements Implemented
12.1.4 Why Do Good Requirements Go Bad?
12.2 Some Thoughts on Governance
Summary
Chapter 12: Patterns and Governance Deliver Economies of Scale
A well-known result from rigid, standardized processes and heavy governance of those processes is a slowdown in delivery. When due diligence (i.e., security architects) resources are highly constrained, and there exist rigid processes that require those shared resources to assess everything, due diligence will become a severe bottleneck rather quickly. On the face of it and simplistically, it may seem intuitive to enact a law and order and/or command and control process. Make everyone behave properly. But anyone whos read the legendary book, The Mythical Man-Month: Essays on Software Engineering, by Frederick P. Brooks, Jr.,1 and similar studies and essays, knows that the more administration and bureaucracy an organization installs, the less work actually gets done.
Chapter 12: Patterns and Governance Deliver Economies of Scale Cont.
One classic problem is how to deal with systems that will be exposed to the public Internet. We know, without a doubt, that the public Internet is hostile and that hosts on the public Internet will be attacked. To counter this omnipresent attack level, there are typical solutions:
Firewall allowing traffic only to the designated public interface that will be exposed
Bastion, HTTP/S terminating host (or the equivalent, such as a load balancer or virtual IP manager)
Access restriction to and protection of management and administrative interfaces
Network and protocol restrictions between traffic terminators and application logic, between application logic and storage or databases. That is, multiple tiers and trust levels
Security configuration, hardening, patching of known vulnerabilities, and similar
Authentication between layers of the automated processes and between trust levels
Restriction to and protection of the networking equipment.
Chapter 12: Patterns and Governance Deliver Economies of Scale Cont.
Management of administrative access to the systems that may be exposed to potentially hostile traffic is a fairly well documented body of practice. For those example architectures in which rigorous management was among the security requirements, in this book I have consistently cited NIST 80053 as a reference to the body of practices that would fulfill this requirement. The citation is not to suggest that an organization shouldnt create its own standards. Nor do I mean to suggest that the NIST standard is the one and only best standard. It is simply well known and relatively widely accessible. At this point in information security practice, I see no need to regurgitate these table stakes requirements. There isnt much mystery or contention about what robust system management entails.
12.1 Expressing Security Requirements
Applications rarely have clear security requirements over and above the vague injunction to follow all corporate security policies. The architect is left groping in the dark when confronted with the question, Does this product support the context in which security appears within my application?
Indeed, there is a significant conflict between empowering intelligent, skilled people to be creative and innovative against the necessity to make sure that certain steps are followed and, particularly, that the important, high-priority security requirements get addressed. I believe that it is impossible to Simultaneously empower people to think for themselves and also order the same people to do as they are told. When people think for themselves inevitably they are going to form their own opinions. Even more so, highly capable peoples divergent opinions might just be correct.
12.1.1 Expressing Security Requirements to Enable
One of the key skills that can help is writing requirements at the correct level at which the requirements will be consumed. This is often a difficulty for engineers who are used to expressing a technical matter in as much detail as possible. For any but an inexperienced or unskilled implementer, this will be a mistake. There has to be enough specificity that the security requirement can be implemented somehow, that the goal of the requirement can be met. But generally, a requirement shouldnt be written such that it hamstrings the implementers to exactly one particular and narrow implementation.
12.1.2 Who Consumes Requirements?
The maxim for getting requirements to the right level of specificity is, just enough to deliver an implementation that will meet the security goals. In this example, the security architect is not really concerned so much with how the restrictions are implemented but rather that it will be difficult for an attacker to use the terminating network (DMZ) as a beachhead to attack the application server. The security architect is interested in preventing a loss of control of the bastion network (for whatever reason) to cause a loss of the entire environment, starting with the application server. That means traffic to the application server must be restricted to only those systems that should be communicating with it, with traffic originating from termination to application server, never the other way around. Thats the goal. Any networking method employed to achieve the goal is sufficient.
Consider a requirement that specified MD5 at a time when it was still considered sufficient protection. Not only would every system that had implemented MD5 be subject to change, but all requirements specifying MD5 would suddenly become obsolete. What if MD5 were specifically called out in a corporate standard or, even worse, in a policy? In large organizations, policies are only rarely changed, and only with approval at a fairly high level in the organization, often with several stakeholder organizations (for instance, a Legal Department). In response to the loss of a particular cryptography algorithm that has been specified in a policy, changing the policy and all the requirements to meet that policy becomes quite an expensive proposition.
12.1.2 Who Consumes Requirements? Cont.
When requirements cannot be met, for whatever reason, a risk analysis will help decision makers to prioritize effectively. Its useful to remember that different stakeholders to a risk decision may need to understand the impacts expressed in terms of each stakeholders risks. We covered this topic somewhat in the chapter on risk (Chapter 4). Although there are many places in the security cycle where risk may need to be calculated and expressed, the prioritization of security requirements against resource constraints, budgets, and delivery schedules remains one of the most common. This is typically a place where the security architect, who has a fundamental understanding of risk and organizational risk tolerance, can offer significant value. When decision makers have built trust that the security function has a method for rating risk in a consistent and fair manner, they may come to depend upon those risk ratings in their decision-making process.
12.1.3 Getting Security Requirements
Implemented
In todays fast-paced, often agile software development, how can the secure design be implemented? In my experience, tossing requirements, architectures, and designs over the wall and into the creative, dynamic pit of Agile development is a sure road to failure.
Three things, not mutually exclusive by any means, are likely to occur:
Artifacts injected into an Agile methodology from the outside will be ignored because the documents appear to be irrelevant.
Developments, learnings, and changes during development will cause elements to change, even for assumptions to get invalidated, causing security elements to change drastically or not get accomplished at all.
If the Agile team members attempt to adhere strictly to artifacts brought in from the outside and not directly generated by the Agile process, this blind adherence will cause team velocity and creativity to fall, even to stagnate.
10
12.1.3 Getting Security Requirements
Implemented Cont.
Its important that the security assessor has good reasons for each requirement. Data on attack levels, types of attacks, well-known compromises, and the like bolster the reasoning for the requirement. At one job, I learned that our web interfaces received seven million attacks each day. When I had to drive a web security requirement, mentioning that statistic often removed resistance, once people understood that attack was reasonably certain.
A big mistake is to issue a security requirement that forces another group to interrupt the way it works, the flow that has been carefully crafted over time. In the above example, every solution proposed required the IT team to lose some of their efficiency.
11
12.1.4 Why Do Good Requirements Go Bad?
One or more requirements may not be implementable as written, possibly not buildable at all. There are many reasons why requirements dont actually get built that have nothing to do with how well the requirements are written. For instance, there may be changes in the business context that cause schedule, budget, or resource shifts. Or assumptions that a design has been built upon may turn out to be incorrect, invalidating requirements based upon those design assumptions.
12
12.2 Some Thoughts on Governance
Governance is introduced into an SDL or system delivery process not to ensure that everything is perfect, but so that these hard decisions dont slip under the radar and are not made for the convenience of those charged with on time, under-budget delivery. These people have a built-in conflict of interest and may not have the security and sufficient computer risk background to effectively make these sorts of decisions.
In order to keep velocity high, the governance check had to be very, very lightweight. Eventually, IT people responsible for deployment were given the project list so that the security engagement check didnt even require a security person (junior or not). It was simply a part of the woodwork. Governance of this nature works best, I think, when it is almost invisible, except for those projects that are out-of-process. And in the certain knowledge that there is a check, both for web vulnerabilities and engagement, only the very brave and/or the foolhardy attempted an end run outside of the process. We let everyone know that these checks were in place.
13
Chapter 12: Summary
Where there is resistance, having concrete examples helps stakeholders understand the reasoning that gives birth to each security requirement. Sometimes, a single, pithy statistic or particular attack example will help others jump on the security bandwagon. For those instances in which there is outright resistance, identifying what is being protected or some other solvable pain point can turn enemies into allies.
No matter what happens, in complex, highly dynamic organizations there must be some governance that security requirements are being fulfilled. This is necessary even when there is a great deal of security buy-in, because there always seems to be at least one clever person who will attempt shortcuts to delivery. There has to be a method that catches these attempts even when they are rare. Otherwise, the defense of other systems may be impacted; theres a due diligence responsibility to ensure that requirements are met or risks raised to decision makers. University of the Cumberlands
School of Computer & Information Sciences
ISOL-536 – Security Architecture & Design
Chapter 11: Cloud Software as a Service (SaaS)
Spring 2020
Dr. Vululleh
Chapter 11: Cloud Software as a Service (SaaS)
11.1 Whats So Special about Clouds?
11.2 Analysis: Peel the Onion
11.2.1 Freemium Demographics
11.2.2 Protecting Cloud Secrets
11.2.3 The Application Is a Defense
11.2.4 Globality
11.3 Additional Requirements for the SaaS Reputation Service
Chapter 11: Cloud Software as a Service (SaaS)
11.1 Whats So Special about Clouds?
Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.
In the mobility example, we represented the management of the mobility clients and the reputation service as servers in the cloud. Of course, these services require far more architecture than a single or even a horizontally scaled set of servers.
11.2 Analysis: Peel the Onion
From our perspective, we need to know that data are pulled and received from many sources via a data-input function. That function, like the Data Gatherer in the business analytics example, must normalize and parse many different types of data so that the data may be kept in a unitary fashion that can be processed for reputations. One logical function, therefore, is the receipt and initial processing of the various data types. Neither of the figures of the SaaS architecture in this chapter portray reputation data collection.
Figure 11.1 SaaS Reputation Service architecture (in the cloud).
Figure 11.1 represents the cloud service as it may look, logically, from the users, that is, the mobility security softwares, perspective. The cloud means that the service has multiple points of presence across the globe to be queried. Cloud also implies large scale to support thousands, even millions, of clients. The mobile device software doesnt need to understand any of the details behind that service. In other words, the details of data retrieval, processing, rating, and responding to queries are entirely opaque to the querying software.
11.2.1 Freemium Demographics
One standard method for dealing with the fact that authentication does not protect against all attacks is to log the actions taken on the system by the authenticated entity. Logging system activity is a typical additional control. Monitoring is often employed so that, at the very least, malicious actions can be tied to a user of the system. In order to monitor, the activity first must get logged. At best, instantiation of malicious action will be noticed and can be stopped before serious damage takes place. For social media sites, logging of action sequences is critical to identifying malicious users and ejecting them from the system before they can harm other users or the system itself.
Since for the reputation service we understand that attackers can gain access, all actions taking place on the service by each device are logged. Anomalous sets of activities trigger an investigation from the 247, around-the-clock security monitoring team.
In Figure 11.2, you will see the authentication service. As in the eCommerce example, the architecture has placed the authentication service within its own highly restricted network segment. Only the web front end may issue authentication requests. In this way, the authentication service cannot be attacked from the Internet. First, the front end would need to be compromised.
11.2.2 Protecting Cloud Secrets
There are certificate chaining validation methods that address this problem. And Indeed, if each enterprise customer requires a separate signing key (and most will!), then our cloud reputation service will have to employ a fairly sophisticated certificate signing and validation implementation that accounts for multiple certificate signing keys. Still, messages from the service may be signed with the same private key (so that every device can employ the public certificate/key to validate).
11.2.3 The Application Is a Defense
Even the best, most security-conscious development teams occasionally allow a serious security vulnerability to leak out into production software. So how can a service like the reputation service ensure that all non-valid input is rejected? Security software testing is beyond the scope of this book. Still, it may be worth mentioning that a typical testing strategy is to fuzz inputs that are likely to receive malformed messages (or other input data). When we examined the file processing chain in the endpoint security example, fuzzing was one of our recommended security controls. That software must be made to withstand poor inputs; it will be examining malicious files. In a similar way, the reputation service front end, which must receive requests from possibly malicious sources, will benefit from rigorous fuzz testing. In order to protect services further within the chain of processing, the reputation service vendor will want the front end to be as bulletproof as possible. Fuzzing is an accepted test methodology to assure a robust input defense.
11.2.3 The Application Is a Defense Cont.
The sequencing of processing goes something like this:
A device requests a reputation for an object.
The query response process (front end) requests a reputation from the reputation processor.
The reputation is returned to the device.
It is also placed in the cache for rapid retrieval, should a subsequent request for the same information be made.
New data come in about the object.
In the back-end data store, the object reputation changes.
The reputation change triggers the reputation processing component to check the cache for the presence of the reputation.
If found (i.e., its still in the cache), the reputation in the cache is deleted, forcing the front end to refresh the reputation when it is next queried.
11.2.4 Globality
In Figure 11.2, you will see that the back-end is actually not discrete but connected and replicated to all the points of presence across the globe. This is very typical for a global SaaS service. Its desirable to keep processing as close to the consumer as possible. Consequently, all the reputations must be replicated to each point of presence. This means that across the globe, in each data center that hosts the service, the front end, the processing service, and the reputation data are duplicated. If the reputation service is to be accurate everywhere, this replication of data has to be very fast so that a reputation query in Singapore is as accurate and up-to-date as a query in London or Hawaii. This need for the rapid dissemination of updates and rigorous duplication of data everywhere implies that the back-end can be thought of as one global system rather than discrete points. At the back-end, all the systems are connected, as they must be to achieve the performance and accuracy required from a global cloud service.
11.2.4 Globality Cont.
There are three architecture patterns that seem to be emerging to provide sufficient tenant data protection.
Encrypt data as it enters the service; decrypt data when it exits Encryption as data enter the service and decryption at exit is the preferred solution from the customers perspective, as long as the keying materials are held by the customer or the customers trusted third party.
Separate processing within the infrastructure Each customer essentially receives distinct infrastructure and processing. Separation at the infrastructure layer is very popular with services that offer a platform and infrastructure, that is, Platform as a Service (PaaS) or Infrastructure as a service (IaaS).Each customer essentially receive distinct infrastructure and processing.
Encapsulate data such that it remains segregated as it is processed – If the vendor requires economies acquired from building a highly shared application (many SaaS vendors try to reap these economies) then the simple, obvious solutions will not work.
11.3 Additional Requirements for the SaaS
Reputation Service
The following list of requirements focuses on the different, cloud aspects of this architecture. Earlier chapters covered in some depth other aspects, such as endpoint requirements, web requirements, and administrative needs.
The calculation processor will not read from the reputation cache. A message will be sent from the calculation processor to the cache to execute a delete of all references to an object in the cache. Failure of the deletion will be logged. No acknowledgment will be returned by the cache in response to the deletion message.
Reputation request messages must be constructed by the web front end. Only the queried object will be passed to the calculation processor.
The front end will sanitize and validate messages from the mobile device. Any message that fails validation in form or data must be rejected.
Before reputation requests will be received, a device certificate, signed by the private key of the reputation service, must be validated by the reputation front end. Certificate validation failure must cease all further communications.
11.3 Additional Requirements for the SaaS
Reputation Service Cont.
All customer reputation requests and request histories will be encapsulated with an unpredictable token. The token will be related to a cryptographic hash. The hash is the only value to be associated to service tenants. The hash-to-client relationship must be kept in a separate network segment, under separate administrative control (different team) from the application administrative team and from the storage and data administrators. Hash-to-token correlation will be done by a separate process running in the back-end, unexposed to any processing outside the internal back-end networks. Wherever stored, tenant reputation histories will be tagged with the token only. No mention of customer identity can be placed within that administrative domain or network segment.
Reputation data will be pushed from the data farm on the internal network to each reputation data instance.
Reputation data instances will exist on a segregated network that only receives requests from the reputation calculation and processing module.
There will be four distinct layers, as shown in Figure 11.2:
a. The DMZ, bastion layer containing the web service termination. Authentication of device certificates will take place before a reputation request may be made.
11.3 Additional Requirements for the SaaS
Reputation Service Cont.
There will be four distinct layers, as shown in Figure 11.2:
The DMZ, bastion layer containing the web service termination. Authentication of device certificates will take place before a reputation request may be made.
A front end module that validates requests before any processing may occur. Requests will be
regenerated before they are passed on to subsequent layers. Objects about which a reputation query
is made may only be passed from the front end after careful validation and format check. The
reputation cache is placed in this segment. It receives requests only from the front end.
The reputation calculator/processor, which only receives reformed requests from the front end.
The local reputation instance for a point of presence, which will only receive requests for data from the calculation module.
The front end request processing input must pass rigorous fuzz testing before release.
The calculation modules request handling processing chain must pass rigorous fuzz testing before release.
An HSM will be employed at each node to perform certificate, message, and data signing operations. Multiple private keys, including customer specific keys, must be supported. Every node must validate every device certificate.*
Chapter 11: Summary
An architecture specific to global cloud products with many points of presence is the network interconnection. One way to achieve this is to establish a series of connections using VPN or IPsec tunnels over the Internet. For a performance sensitive SaaS, the vagaries of Internet routing will influence transmission times. Hence, although essentially secure across the hostile Internet, such an architecture is likely to be unsuitable for this purpose. Instead, where performance and security must both be served, a private network is often the better choice.
