This one we can do in one page
- How the crime is committed
- What the industry can do to prevent
One of the recurring themes that has come up in places I have worked is pretty much
- The simplicity of design with applications makes stealing very easy
- Trust is situational
I’m a good employee on the trust side, this is why
Places I have worked giving me Admin Access
I explain to them why I am not the exception to the rule just because “It is easier if I do it”
This is a recurring theme for places I have worked, more often than not I end up in some sort of ongoing BAU role as part of my day job.
Sometimes my job requires it, there are occasions where I am at a higher level of IT and I need this type of action to function in my day job.
But when I work as a tester, BA, Project manager, trainer, whatever it may be, I end up with a level of digital expertise substantial around the applications, along with having to help the users with day to day issues.
Whether it is changes to email templates on a live application or pricing and rating change to a PRE, or configuring new products on a live application, this is something where a keen, often over zealous, young person on the project, naive to the world, will ask me to do something and at the same time they give the application admin credentials, which for some reason are being shared around.
At this point, I explain to them that while I will help someone else do it, they now need to go and change those passwords. I then explain to them what the admin password for an application is used for, and why that is quite frankly the worst thing they can give to me, especially when that account is on a windows administered and secure active directory.
Often they then come back with “I spoke to someone, they said it is ok for you to have this”
I reply with “like i said, I will help you or someone else do it but given how readily you gave this to me, I don’t want to be accused down the line of committing fraud when you hand this out to anyone just because it is easier”
In short, the password for that application will likely have a windows account that is likened to a tier 3 IT administrator account. There is usually only 1 or 2 people who should be aware that the admin account for this application even exists.
When companies do this, they create an uncomfortable situation for someone with the expertise, because they know what can be done on that application with significant ease. If the application made such things difficult, it may be different story.
So, I’m going to give you a very high level example of a common and recurring mistake that people make in application design for convenience over security, how with about 2 minutes of access this can result in days of income going into a bank account of my choosing before you notice that something has gone wrong.
I want to stress at this point, this is JUST AN EXAMPLE, there are usually a lot more things that can be done, but this one requires little to no digital expertise.
How the crime is committed
Well, we have a common scenario above, that is my access.
Either someone gives me their account, a shared account, or they increase my account privileges too much.
Either way, provided I am not greedy I have about 25 days to play with on any given month. This is the probable time it would take for something to go wrong and for someone to notice, if I do it right, then you may never know or just think that it is a “defect” or “let it go”.
It all depends how greedy I get and how obvious I am.
Now, I am giving the way I would eventually get caught, not the way I would not get caught. Reason being, the solution to both problems is the same, but one equates to training criminals, the other equates to ‘stating the bleeding obvious’ which does escape some people.
So far, this has been an issue pretty much every place I have worked, both the application design and the way security is handled, this is a clear and obvious method to deploy.
Easy access for accounts
Now, in a lot of systems, what you will find is the following
Integration with 3rd parties is so easy, you can do it yourself, all you need to do is enter certain credentials from your provider. The rest of it is configured to work.
Obvious now isn’t it
Getting a payment account with someone isn’t the most complicated thing in the world, payment service providers is what I am registering with, it all depends how good I am at other methods of fraud, but their service sign up is relatively straight forward, especially where there is a certain limit of how much you take during a day as you can then use that to guide your approach.
Point is though, I can get an account with these services, yes I probably need to go through setting up a business, setting up a business bank account, etc. But I just did this, I can’t see anything that would stop someone else from doing this in my name, it was really easy and straight forward to do, there was little to no security involved.
It is all automated, it is all easily done, so let’s not question how I go about pretending to be a business or setting payment services.
Now, if you can get to a point where you have set up the same payment service that your employer uses, what you will find is that you have matching credential formats.
Now with enough knowledge of the application, batch runs especially, you will know how, when and at what times it is ok to replace the applications standard payment details with your own.
So here are the problems I have seen with applications
- You can configure the payment services from the front end of the application
- You can do this with an easy to use menu
- It it often requires is your details to validate with the payment provider
- The existing details are often visible in the system, if not, then they are visible within the requests the system makes (log files and the such)
- You can put new details in really easily
- There is often nothing that would email out to the accounts team and high ranking employees that these details have been amended.
So more often than not, that enables anyone to do it.
Even with some of these things in place, it is not impossible to work around if you have the knowledge of the application and the infrastructure.
But at a high level (without training out the rest of the method) this is what would happen.
- Use payment service details for a couple of hours per day
- Put it back to the originals for the rest of the day
Basically, provided I am not greedy, this is unlikely to flag up until reconciliation time.
So all I have really done here is replace something like your ‘Datacash’ service with my ‘Datacash’ service, the payments will funnel through to my account instead of your account.
The reason this is possible is due to
- Poor application design for convenience over security
- Poor education within the company
What businesses can do about it
One recurring theme, educate your employees.
Now a lot of people will approach the above issues around “But we need to trust our employees”
What you have to understand is, when you have these poor designs you are putting your trusted employees in bad situations.
So you can trust an employee with a high level of security, but you should implement it in a way that it protects them.
So for me, when someone ‘gives’ me advanced privileges or knowledge of certain accounts, it makes me uncomfortable, not because of what I won’t do with it, I’m an honest employee (given all I can do, you know I am honest as I don’t live in a mansion with a trophy wife, or have a tower named after myself….) but I’m uncomfortable because if these details are used because it serves convenience, I know what I could be accused of further down the line when fraud does happen and my skill set makes me the perfect patsy.
If there were certain provisions in place within the application and infrastructure, then I wouldn’t have so much of an issue with it.
So let’s have a look
1. Application admin accounts are not shared accounts
This is the account that basically has a matching active directory account of equally high privileges in order to operate on your network effectively.
Nobody should be using this account.
2. Education is a matter of “is that individual protected” as oppose to “do I trust them”
If you are a good employer, you shouldn’t be putting your employees in that position in the first place.
So, if you are giving out shared admin accounts, what you are doing there is putting trusted employees in an exposed situation.
The same applies when you increase their privileges within an application.
Whether you trust them or not is irrelevant, don’t do that to your staff without having reasonable measures in place to help protect them.
The ones that know what can be done you make feel incredibly awkward when they tell they don’t want it.
The ones that don’t tell you they don’t want it should definitely never have access to it. Not because you cannot trust them, but because they don’t understand the problems that are caused by this level of access.
There are usually one or two exceptions to this, even in the biggest of companies, as somebody does need to know the account exists. But then their visibility of this account and administration of this account is controlled by the active directory.
3. Alarm monitoring and dual authorisation
This is a way where you can protect your employees who do have higher privileges.
Certain things in applications, including when they are configured for use, require two users to authorise changes and this should extend to the admin levels but often they don’t.
It is not everything, workflow and products for example, you wouldn’t need two people to approve it, but things like Direct Debit payment services, Credit Card payment services, amending and entering credentials should involve at least 2 people.
- One person to do it
- One person to authorise the change
That is a pretty simple notion.
The other part of this is, when changes are made by administrative users there is a notification sent out to certain people.
True Admin users have no real reason to use an application regularly, when their accounts are logged in it is a security risk.
The trust issue here is simply “send an email to their boss and their own email” at the very least, this gives them more comfort that they would know if someone else has logged in as them.
This isn’t a basic application support user, again, there should only be a handful of people this applies to, simply because they have no reason to enter the front end of the application.
Then, finally, when certain things are changed you should have a distribution list, including the new functionality you just added that notifies certain people when there are certain changes. This includes when certain users of a high enough privilege level have their password reset.
4. Don’t use logs and backups as an excuse for laziness
So many times people make this mistake, we would have it in the logs, the logs get backed up.
This is one thing I cannot go into, the reason why in my current method I would get caught.
I need you to trust me that this is not a solution, otherwise I can only explain by providing education to the level that people would not have (against my rules for publishing articles), but fundamentally it is a user friendly exercise to workaround.
5. When defining security, protect against me, not your staff
I have no degree, no formal IT education, no qualifications.
I had access to MS-DOS, Windows 3.1, ZX-Spectrum from the age of 4 years old.
There is nothing on paper that would tell you I am who I am, nothing to back up my technical expertise.
My ability is not in what I know, my ability is in how quickly I pick something up that I don’t know. Technology is second nature to me.
I could be working in your company as a UAT tester, or as a member of your sales team, or as a trainer, or a Telecoms expert. The job I do seldom reflects my digital expertise.
The biggest security threat is the person you underestimate.
Like I said above, I can only publish the method here that would result in me being caught.
But then, I’m only getting caught dependent on the skills of your employees or my lack of knowledge around the application.
It is dependent on the application in place, but the way some applications make this so easy it makes it easy for anyone really.
That coupled with shared admin accounts, again very easy.
Other advanced knowledge that is at the employees disposal means that they can effect this without you ever knowing they did it (point 4 above around the logs and backups).
A slight change of approach to
“Should we be doing this to our staff” will help you guide security in this particular area.
So is it fair to your staff that I can come to work for you, and you provide me with the means to do what I want, ultimately enabling me to commit fraud while another one of your staff members gets blamed for it?
Not very fair is it.
Anyway, nice quick issue there, most people who have admin access to an application will be able to see if these issues apply, they would get the trust aspect vs the situation you put trusted employees in as a valid argument.
If you are not sure, ask you application developer.
Thanks for reading, links below for other issues