All too often people hide behind what they ‘want’ to believe is true. Unfortunately, your personal beliefs and opinions will not prevent a ruthless individual from ransacking your network’s filing cabinets. The easy road is not necessarily the secure one so, rather than wait for a hacker or malicious insider to burst your bubble, here’s what misguided individuals tell me far too frequently.

Myth #1: We passed our regulatory compliance audit – so our network is safe

If I had a brick for every time I heard this one I could build a wall around the equator a mile thick and two miles high. Just because you passed an audit does not mean you are hack proof – far too many large organisations on both sides of the Atlantic are testament to this fact.

There are a number of reasons for this. The most common is that IT departments will pull out all the stops to hit a certain number of audits per year, and forget about compliance on all the days in between. Another big concern is auditors may not always know where to look for the holes so they can be steered in another direction.

I give you fair warning – hackers won’t make an appointment to come ‘check’ your systems! Neither will they stumble accidentally across vulnerabilities in your enterprise. They know what they’re looking for and will strike on their terms.

Myth #2: Our passwords change regularly in line with regulatory mandates – so our network is safe

I’m sorry to be the bearer of bad news but, in my experience, this is unlikely to be accurate. While user login credentials might be automatically prompted for change, it is the highly privileged administrator accounts that fall outside most automated solutions and therefore rarely altered. Of course, some of you may be thinking that you’ve got that one covered because your IT staff secures these privileged identities manually. All too often that simply isn’t possible. While not rocket science, the sheer magnitude of the task is to blame.

Someone physically connecting to machines, or even using scripts, to change passwords to comply with regulatory mandates is fraught with complications. Think of all the services running on machines with privileged credentials, including any interdependent services, which have to be appropriately stopped before a change can be made, then restarted. It’s a daunting technical task, prone to errors – not to mention time and labour intensive.

Myth #3: Our systems administrators don’t share their privileged logins – so our network is safe

Who are you kidding? The reality is convenience wins out over security. Although I can’t name the company, a large US insurance provider believed its privileged logins weren’t shared but soon discovered that this perception was misguided. A branch office had been given the privileged login details to resolve a routine IT administrative issue.

But, since the privileged password was never changed, staff at the branch office were free to change settings on their machines and install software at will for many months. And this wasn’t an isolated case. Others within the organisation had also been given these ‘keys’ to the network, and had gone on to share them with more employees, allowing the spread to creep around the entire enterprise.

Myth #4: Our IT team know who has access – so our network is safe

Okay, this one has a couple of threads to unravel. Passwords for highly privileged accounts are often hardwired into applications, or given to contractors and outsourcers to use. Because these logins are shared it’s impossible to pinpoint exactly who, or even what, is behind the connection. Similarly, as we’ve already alluded, these passwords infrequently change, meaning someone who is no longer employed or contracted by the organisation could hijack these credentials and gain access.

In the case of administrative accounts, these exist in droves and, again, they too get shared. Because everyone uses the same common credentials to get into a machine and make changes at a highly privileged level you never really know who is responsible for alterations, or even has had access to sensitive data. A final issue is people changing job roles within the organisation. If their credentials haven’t been changed then they may still have access to information or services that they no longer need.

Myth #5: Our existing Identity Access Management software is controlling users – so our network is safe

This is a common misconception. As we’ve already said, most organisations have no processes to control highly privileged administrator logins typically used for emergency firecall or routine administrative access. To spell it out, all existing security solutions – firewalls, IAMs etc. don’t track and control privileged identities. The truth is that, unless it’s a specialised solution, it can’t!

Now, how many of you thought you were safe prior to reading this article? While the majority of organisations are ignorant to the reality of the security within their enterprises, ignorance is not an excuse should your systems be breached. Instead, regain control of your enterprise by following these five rules:

  • Don’t focus purely on passing an audit. Instead remember that your end goal is continuous compliance. You can achieve positive results by viewing each potential security hole as something to investigate and mitigate rather than a crack to be papered over
  • Ensure all default passwords are changed before deploying any new devices or programs in a networked environment. This can be easier said than done – as there could be more published default logins and developer back doors on your network than anyone might know
  • Configure all privileged accounts to require password changes every 60 days at the most – using unique, complex passwords for each account in the network
  • Store all passwords in an encrypted format, only accessible with delegated and audited super-user privileges
  • Employ automated tools that will inventory all privileged accounts, monitor for anomalous behaviour, audit all activities and control their management consistent with the FDCC (federal desktop core configuration) standard.