I'm currently conducting a due-diligence review of a technical system. The system is a classic distributed, two-tier system with data held centrally and business-logic delegated to an application tier. I've been asked to perform a security analysis as part of my review. I can't tell you anything about the project itself, for confidentiality (and security) reasons, but I thought I'd share some of the thought processes behind what I've been doing.
Reviewing security
The foremost rule of security assessment is to include the entire system. Don't just look at technical aspects of security but also at non-technical risks. Here's an example: a password is a common technical security measure, but if steps aren't taken to prevent users from posting their passwords on the Internet, then the password is useless, even if it regularly expires and uses strong password controls.
There is a similar problem when security is not appropriately applied. When there is a too restrictive or misunderstood technical security requirement, individuals will look for and often find a way round the problem, often by disobeying the very policies that are critical non-technical security measures.
The solution? Security measures must be appropriate, proportionate, understood and trusted. If you don't get the buy-in of your users then these measures have no or else limited value.
Understanding the threats
The second rule of security assessment is to address the organisation's blind-spots. Legitimate users of systems are also potential attackers, sometimes intentionally, sometimes maliciously and sometimes they are simply applying their own pragmatism, "surely the business doesn't want me to spend all that time jumping through these policy hoops? I can save the company money if I do it like this...".
Create buy-in
Next, make sure that you employ security measures that your legitimate users are willing to employ. There is no value in creating 60 character random passwords. Your users will never remember them and so they'll write them down. Probably, they'll leave them next to the computer as well...
Implement Defence-In-Depth
Defence-In-Depth is the principle of checking security at each component of a system. It ensures that a breach in an outer component doesn't automatically gain unrestricted access to the assets at a deeper level. In my analysis I found that this principle had not been applied and that meant that a breach at the outermost level could result in unrestricted access to substantially more data than a user was normally entitled to.
Another resulting effect of the Defence-In-Depth approach is that it allows for clear security boundaries to be applied. Within the data centre the organisation has effective security capabilities but once the data has left this secure area the degree of control is reduced.
So how does Defence-In-Depth compare in a two-tier system?
Without Defence-In-Depth
In this scenario, all security checks are performed only once at the application layer, the communication layer or the data layer. Let's look at the implication of each option in turn:
1. Controls at the application layer only
In this case, if a user can breach the communication mechanism or the application code, then the user gains total access to all data in the system. This presents some major difficulties from a security perspective as it can be relatively easy to break one or both of these using reverse-engineering or eavesdropping approaches.
2. Controls at the communication layer only
Securing the communication layer alone allows users to have complete access to the data and to do anything with it. This provides no protection whatsoever from the insider, and that includes anyone who manages to break into the environment.
3. Controls at the data layer only
In this case, the access to data can be secured, however the data may be misused or transferred outside of the application. The security at the data layer must be substantially hardened to prevent malicious users from causing unintended behaviour. Once the data has left the data centre, the organisation no longer has any control over it.
With Defence-In-Depth
The Defence-In-Depth approach is pessimistic. It chooses to secure all three layers used in this system:
1. Controls at the application layer first
This limits those allowed to use the application. If it is breached, the user still has to break both the communication layer and the data layer security mechanisms.
2. Controls at the communication layer
This provides two added benefits. Firstly, it limits the potential to break the application because the application's communications are encrypted. Correct protocols can also prevent replay attacks and man-in-the-middle attacks.
Secondly, it enables the data layer to only allow access through this secure medium, limiting its exposure to other systems.
3. Controls at the data layer
The data layer ensures that the application only has access to the data that the application's user is entitled to. This limits the exposure of data. Because the other two layers have hardened the access mechanism, the data layer is less susceptible to direct attacks using otherwise valid credentials.
Conclusion
Applying Defence-In-Depth won't solve all your problems, and it will introduce additional design complexity. However, it should be applied to distributed systems where security is an imperative.
Metadata