Any organisation serious about security has already taken steps to effectively secure their environment from external attack. Whilst this forms the fundamental basis of security in today’s world, it does not cover the insider threat.
What is the insider threat ?
The insider threat is the term used to explain the danger of an attack originating from the inside of your network. Whilst security is often very strong at the perimeter, it is often very weak on the inside. Any organisation that does not take the necessary steps to address this increasing threat could well find themselves breached unexpectedly.
The risks identified so far include data leakages and information breaches, but actually extend well beyond this initial scope to form a realm of possibilities. Those with privileged access to systems should be regularly audited – a practice which is commonplace, yet not adopted by many organisations. Privileged access is any enhanced or elevated permissions to a system or it’s underlying data, outside of the scope of what is considered standard user access. Such an example of this elevated access is the administration function.
All networks need administrators, but what happens when one goes rogue ?
Identify insider threat risk
If there are no controls in place that check for suspicious activity on a regular basis, then how do you know what to look for, and where to look ? The response here is that you don’t. You may have a very good idea of where your key assets and intellectual property reside, but unless you are regularly monitoring these, do you really know everything about who or what is interacting or interfacing with these systems ?
If you take a step back and think for a moment, who has access to that system, and what level of access do they have ? Is it necessary and / or appropriate for that user to have the access level granted to them ? If the answer to any of these questions is no, then the time to formulate a response to this issue is now.
If you are not at least checking access requests to any systems, or performing any regular reviews of access levels, and who is using them, you are exposing your organisation to unprecedented risk of internal abuse – and potential theft of information. Virtually all organisations employ at least some form of policy for the creation and deletion of user accounts, and changes to access levels provided to resources and assets. However, a policy does not serve as a barrier to prevent changes to your system – it is merely a mechanism that defines the process to be followed when doing so.
Any CISO who believes that the policy prevents the modification of access rights to systems and associated infrastructure is in for quite a shock – there is nothing stopping anyone with enhanced permissions from abusing this, and obtaining sensitive information as a result. This data could then be leaked, and your organisation breached as a result.
Performing regular reviews of access permissions and account modifications (including creations, deletions, additions to security groups etc) provides the first basic step of identifying a level of access granted to infrastructure or an individual without authorisation, and could severely limit the impact or damage level if detected early.
As an example, any rogue administrator could create fake accounts that have domain admin access to infrastructure and resources. As the account is created internally, it is not likely to be questioned unless it is seen by another diligent member of staff who in turn requests justification for the account, or the level of access granted. This activity is not limited to creating new accounts – any existing account could be elevated with new access rights.
Why does the insider threat pose such a risk ?
The rogue administrator often fits one of the following scenarios
- Disgruntled employee
- Asked to leave owing to misconduct
- Is the subject of an inquiry by their employer
The first scenario is the most dangerous. The disgruntled employee often bears a grudge against their employer for a variety of reasons, and if they are of a certain disposition, may decide to exact revenge after they leave the organisation. They may part on reasonable terms, although the threat they pose is very real. Dependant on the type of organisation, if the employee has enhanced access, and announces their desire to leave active employment, this access should immediately be revoked, and the affected staff member placed on garden leave.
This is certainly the case for large financial institutions and government agencies, and is clearly adopted as a strategy to minimise the potential risk. However, smaller organisations may not adopt this same approach, and are placing themselves at odds with their security policy.
What are the common insider threats ?
Insider threats vary in complexity, and also lean heavily on the skill set of the threat actor. Those who possess superior knowledge are capable of much more than those in lesser roles, or those with a reduced knowledge level. However, anyone with enhanced access who you consider to have the lesser skill set represents exactly the same threat as an individual who excels technically.
Why is this ? It’s all about the access level. A simple Google search will provide sufficient information on what type of attack can be performed on a network. The only real probability is that an individual may be discovered doing this, or inadvertently makes themselves stand out as a result of their guarded nature, or minimising all windows if they see you approach their desk.
The most common insider threats are borne out of a variety of reasons. You can’t spot a threat just by looking at a person, and you certainly can’t make random assumptions or accusations against any individual if they have no foundation.
What do I look for ?
There are numerous mechanisms that can be employed that significantly reduce the risk of an insider threat. Such examples are below
- Perform regular checking of windows event logs. Pay particular attention to accounts created, deleted, and modified. Also verify each permission change for approval. No approval means it shouldn’t be there in the first place. A regular justification exercise should also be performed for all accounts that are considered to be more than just domain user.
- Check for what appears to be scripted permissions. For example, an account that is being used to elevate another which is outside of the expected activity. This could be an account that has elevated permissions, but is used for services, and not typically for administration. In this instance, it should be checked.
- Keep a record of scheduled tasks that run in your organisation. If you already have several tasks that run across your organisation, and do not have a mechanism to document these, and which account is running them, then this is a significant risk. Any one of these tasks could be hijacked and injected with extra commands if they run with enhanced privileges. Scheduled tasks should be regularly reviewed for content, and should also have an approval process in place. The approval only permits the code signed off at the time – any changes without approval are considered a risk.
- Check all servers and workstations for services that are not approved or permitted. An access elevation could be masquerading as a service. Similarly, document all services in terms of where they run, and what accounts they run under. You should be using the least privilege model, and any service without necessary authorisation should be removed.
- Check firewall and remote access mechanism logs to ensure that policies are being used correctly, and do not provide access which is beyond what is needed to host any service. Firewall policies should be regularly checked, with justification provided for each one. Change control and authorisation processes should be in place to prevent access changes without approval. If a firewall policy is created or modified, and there are no checks in place, data can leave your organisation freely without being questioned.
These are only a selection of policies and procedures that should already be in place. Even if your environment is locked down like Fort Knox, a rogue administrator can still find a way of bypassing security whilst remaining under the radar. You may be asking “why” and “how”, and you’d be right to do so.
The main issue here is that an administrator in any form posesses intricate and precise knowledge of your infrastructure. From the patching panel to the firewall or edge router, a rogue administrator can employ a variety of techniques to sidestep any type of security that has been implemented
The rogue administrator may have been involved in the initial design and implementation of your network, and by definition, will have an enhanced awareness of what will work and what will not in terms of a potential breach. Whilst you are focusing on windows servers, the rogue administrator could be using a printer as the origin. A printer ?? Yes – they contain web servers and a shell by default, and provide a good hiding place in the process.
You’d think that your security alerting mechanism (IDS, IPS etc) would see this and fire off a warning. This is where again you can fall on your own sword. These mechanisms all have one thing in common – they are pattern based. An alert will only trigger if the activity being performed matches that pattern. If it doesn’t, then you should already know what is coming next.
The end point this – monitor your administrators closely but silently – don’t make them feel as though they are being scrutinised and cannot be trusted as this will have exactly the opposite effect. Perform regular security reviews across the board, and pay particular attention to those who appear to be unhappy or disgruntled.
Administrators hold they keys to your kingdom, and this could work against you if you are not prepared to address a situation before it is too late.