2

I am interested in how a 3-tier network topology (web/app/data) provides improved security than a 2-tier topology (web-app/data). I understand the concept of a DMZ as the initial contact point with the world, and a place where server compromise may have less impact. But then what difference do I get with a web vs web-app in the DMZ? And what what I do with non-conforming apps (I could put in a dumb reverse proxy in the DMZ as the 'web', but again, what's the value-add?)

Steve M
  • 53
  • 3

3 Answers3

3

The way you are thinking about the problem is running you into trouble. It is not the DMZ or the tiers that improve security; it's the separation of the access and the data.

  • A DMZ is one way to separate access and data at the network level
  • 3-tier architecture is one way to separate access and data at the application level

So, thinking about it this way, you can start to evaluate your risks and your mitigation options in terms of layers of separation and the risks of not separating the layers.

If there is a risk of someone gaining access to the DMZ network (server-level access), then you need to place the high-risk assets behind the DMZ. If the "app" portion of your architecture is not where the high-impact assets reside, then you can be justified in deciding to place the app tier (or, similarly, the web-app tier) in the DMZ.

Your decision matrix is based on the questions:

  • "what is the impact if this control fails?"
  • "what other controls need to fail in order for this control failure to have an impact?"
  • "what is the likelihood of this combination of controls failing?"

A DMZ and a tiered architecture add layers of control that give you options in case a set of controls fail. Whether the layers of control will have an effect is entirely up to your risk assessment.

Security and risk management is about applying layers of controls to mitigate the likelihood and impacts of an adverse event from happening. If a control does not affect the likelihood or impact, then it is a waste of resources.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • I appreciate the answer, but it feels like "you make a risk assessment and decide what to do". I may simply need help to understand, but what what risk could eventuate with a 2-tier deployment that a 3-tier deployment would address? Or conversely, what additional risk am I exposed to by selecting a 2-tier deployment? – Steve M May 24 '19 at 12:42
  • You missed my point: it depends on the impact of having a lack of separation. There may be none. I don't know your application, your data or your risks. Do a threat modelling exercise as a starting point (although you might conclude that you do not need to perform a full threat modelling exercise to get value from it). If there is an unacceptable risk for having the app/app-logic combined with your front end, then you should separate. If there is a risk to having access to the app/app-logic from the network, place it behind the DMZ. – schroeder May 24 '19 at 14:17
1

In a nutshell the main capability that adding the app tier provides from a security perspective is more precise control over the access to the data. There are many different ways this can be implemented and achieved. An example may be illustrative:

Let's say you have a user table in your database that contains hashed passwords. In order to validate a user's login, you need to query the table for the hash that applies to the user in question.

Now consider how the web app in the DMZ handles user password validation:

  • In the 2-tier solution, the web-app connects directly to the DB and queries the table.
  • In the 3-tier solution, the web-app send the user id and password to the application layer and get's a yes/no answer.

Now consider what that means if the web-app is compromised. In the 2-tier solution, it may be possible to modify the query or create a new query that retrieves the entire user table with all the hashed passwords. In the 3-tier solution, you have only the specific capabilities provided by the application layer and (ignoring flaws in that layer) you lack access to the underlying tables.

Effectively, the app layer allows for controlled white-listing of what the web-app can do with regard to data access by removing direct access to the data store. To determine whether or not this is needed, see schroeder's answer.

JimmyJames
  • 2,956
  • 2
  • 16
  • 25
  • I like your example - Some stuff I never thought of! – Steve M May 25 '19 at 08:05
  • What's your take of using a reverse proxy in front of a traditional 2-tier app to make it into a 3-tier? I know lots of companies (especially banks) throw in a dumb reverse-proxy to make things into a '3 tier' model (when app is really 2 tier), but I really can't see the value of that... – Steve M May 25 '19 at 08:07
  • @SteveM Are you talking about having the reverse proxy in the DMZ and the web app? I guess it doesn't hurt. I look at the DMZ as being born of the network perimeter strategy. I don't think anyone would tell you to not bother but by itself, it's unlikely to be enough. It's like a fence. It really just slows people down and turns away the unmotivated. – JimmyJames May 28 '19 at 13:46
1

My understanding of the OP: 2-tier = logic running in web browser is light/UI, web server deals with presentation and business logic, second tier is a DB or data store. Could be a PHP performing CRUD on a backend DB and serving HTML. 3-tier adds a service/business layer between the web server (presentation) and the data store.

From architecture design and operations point of view, adding this middle tier has a lot of benefits: limits the responsibility of each tier, you don't have to upgrade the whole system each time, you scale horizontally the tier which is doing the heavy work, also business tier can be accessed by other webapps/apps.

From security point of view you get to tailor your security controls for each tier. The web tier is in DMZ and you want to limit the IPs it will communicate with in data center. The business tier on the other hand can connect to the authorization server, exception management system, DBs, ... You would apply your threat model: if web server was to handle business logic and cache/log the operations it might need to encrypt it because there is a risk of server compromise; whereas if there is a middle layer in data center then cache/log of business ops might be acceptable to store in clear.

00545LS
  • 83
  • 5
  • "From architecture design and operations point of view, adding this middle tier has a lot of benefits: limits the responsibility of each tier" I would argue that this limiting of responsibilities also has security implications e.g. [Principle of Least Privilege](https://www.owasp.org/index.php/Least_privilege) – JimmyJames May 28 '19 at 16:29