Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 

Recently I stumbled upon a training about product security, where the topic of privileged users (sure this is not only an admin) was discussed. The simple objective of this training was that you need to trust a privileged user and thus it makes no sense to protect the system from malicious behavior of such a person. There is some truth in that, you need to trust people to do their job diligently. But there is more to that than just trust. Two things come to my mind immediately a) the old security phrase “prevention is key, detection is a must”, and b) the good old story of “segregation of duty”.

Yes, I need to trust the admin, but that does not mean I should look away what he is doing. In contrast there should be a control if an admin is not conducting malicious behavior. The simple control for that is logging. If you know and the admin knows that his tasks are logged in a secure log that he cannot tamper with, the barrier for committing malicious actions surely will raise.

On the other hand, do I need to trust the admin without any limits? No, of course not, even if the reality in many circumstances is like that. You have the option to segregate duties in many cases, unfortunately not in all cases as for example it is a bit harder to segregate duties if you IT staff is very small. But you just need to look in bigger organizations (financial institutes are a good example). There you will typically find a very fine grained segregation of duties. I have even seen models, where the database admin (DBA) was excluded from accessing the business data, using a complex to database instance setup.

And there is even more we can do, for critical things we can for example send an automated email to a different person or we could apply dual control for critical tasks (think about rocket launching 😉 ). And I am sure there are further measures to protect us from the admin beyond trust.

So the good news is that we do not need to trust the admin blindly. The bad news is that we need to take care for the admin in threat modeling as well.

OK, let’s assume we have a server infrastructure where the role of an admin is defined. The conservative approach is to give the admin full blown access rights. As such the admin can do anything, he can start and stop the system, she can change any configuration or network settings, she can deploy applications, and she can manage all the users and so forth. Is there a risk? Without looking at the details I would say yes, but let’s dive deeper.

My standard example for the risk is as follows. You run a web shop but dare to run the payment part of it. You instead outsource it to a card provider or online payment company. With that you have outsourced all the nasty security aspects of the payment handling itself. Almost. Because your hook into the payment provider likely is at least a URL maybe including authentication information. Again let’s put on the black hat: Ouh, a URL, what happens if I change it? I could easily point site visitors to a site where they get a drive-by malware infection. Or I could set up my own payment server pretending to be card provider XYZ (you do not even need an appropriate domain name). As such I log in as the admin, change the URL from time to time to my fake web site, and collect some credit card numbers. If I am clever I can blame the credit card provider for a few of the customer complaints.

If we look at the “prevention is key, detection is a must” paradigm, the first thing we do is take a closer look at logging. Will we find out that the admin has changed the URL and will we find out which values the URL had before it was changed? If not, we might better improve the logging. With this we are not preventing that but might be able to nail down the malicious guy afterwards. To prevent we consider again dual control or other means, which gets a bit trickier and costlier to implement. To be able to decide on our action we need to understand the risk.

Looking at the credit card example, the impact is credit card fraud. I am pretty sure you do not want to see your web shop in the press with a credit-card-fraud headline. As such I would estimate the risk as severe (our highest impact category). You might remember that we are not looking at the likelihood as the second dimension (where do we get realistic data for this?) but on the ease of attack. Admin and ease of attack? We figure out that the required trust is back in the game. For the admin the attack would be fairly easy, but we can balance that with the trust factor. As such we typically map admin attacks to our complex attack category. Severe x complex = high risk. Unfortunately, nothing changes if we have solid logging, as the impact is not affected and the ease of attack is also not increased. You could argue that probability goes down as your admin knows that you know … As such you could move the risk to the category “very complex”, which we typically reserve for extremely well-funded and skilled hacking organizations (I think you know whom I am targeting). If we do so we still end up with “medium” risk, but maybe that is something we can live with.

We could now try to reduce the impact, but that will be hard as it is a business function we likely need (at least once). Further measures will increase attack complexity, for example dual control would require the collaboration of two people… And thus we likely stick with the medium risk for the time being. At least according our internal scheme.

I think it is worth discussing risk evaluation in more detail. To keep it short you can do a more complex scheme, which likely also has downsides, or you try to keep it simple and partially vague. How do you evaluate risk, I would be very interested in that?