Think Like An Attacker And Mitigate Cyber Threat

Organisations are being tasked to innovate all the time. Market pressures, changing buying habits and competition from new market entrants is putting increasing pressure on leadership teams to innovate, and on IT teams to deliver on this innovation. And it’s no longer just the IT team. Security, compliance, finance, line of business leaders and DevOps all hold pieces of the puzzle which make up the IT infrastructure of an organisation.

Sadly, these groups are often disjointed in their approach and, under pressure from the increasingly fast-paced nature of business, they look for quick wins, rather than working in tandem on consistent policies and processes.

The result is a complex quilt of tools to roll out applications and processes across the business, all with differing profiles, permissions and, most likely, levels of compliance. The ideal breeding ground for hackers to prosper. So where does security fit into the picture?

Sadly, the answer is often an afterthought for many in the business, and lots of teams are simply looking at the wrong things. For example, many DevOps people will think about software vulnerabilities and patch management. However, they also believe this responsibility sits within the scope of their security function. If you ask your DevOps team which security tools they use, they might say ‘terraform’, ‘github’ or ‘ansible; this demonstrates that they are not thinking beyond patches and vulnerabilities to consider the access control and privilege associated with access to their zero assets.

Crucially, the way that businesses often measure or prioritise their activity in terms of security is whether they will pass an audit. While it may be comforting to members of the business to meet these requirements, they often fall short of industry best practice, and significantly so. And let’s be honest – a hacker has no interest in whether an organisation has passed an audit, and neither will any customers impacted by a breach.

On the one hand, meeting regulatory guidelines is often a good starting point for putting in place a sensible approach to security and data. However, simply ticking the box of compliance could well open organisations up to a range of threats. Instead, by ensuring that basic procedures are in place, organisations can build a more comprehensive strategy. This encompasses all the elements needed to support a more complex IT infrastructure and the flexibility to adapt to future changes in the IT landscape.

So how can organisations get ahead? My advice would be to think like a hacker. It’s true that DevOps made the heart bleed easier, but the issue is far broader than this. IT, DevOps and security teams must come together to better understand the immediate threat from hackers, future trends and the gaps in their security policies. Only then can they build a strategy to effectively shut them out and restrict their movement, should they breach the organisation. Looking closely at the role of privileged credentials is a good place to start, as these can often be used by hackers to access the “crown jewels” of any organisation, cover their tracks and move laterally within an organisation without detection, for days or even months.

As organisations rush to innovate, new DevOps pipelines have emerged which don’t necessarily fit under the security umbrella applied to the rest of the organisation. In fact, our Threat Landscape report revealed that 75% of security professionals report no privileged account security strategy for DevOps within their organisation. Yet this is also where privileged credentials are often created, and rarely locked down. As such, this is where many new threats can emerge. With these credentials in mind, when rolling out any new strategy I would recommend starting with five key areas which are increasingly hacker hotspots, and targets that aren’t necessarily covered in a company audit. These feature throughout any development and rollout process at an organisation, highlighting the threat at every stage:

• Stage 1: Infrastructure code developer – Look out for hackers targeting cloud credentials, such as in GitHub
• Stage 2: Infrastructure source code – At this stage of the infrastructure build, phished admin credentials could easily lead to cloud access for any hacker – they could phish one DevOps and own your systems
• Stage 3: Build and test unit – Hijacking of IT resources is a common failure for businesses at this stage. Out of date libraries could also leave businesses at risk of attack
• Stage 4: Code review ahead of rollout – This stage is at risk of malware injection in test systems, which can then be rolled out to the organisation. At every stage, this could result in malicious activity and, ultimately, data loss for the business

These are just a handful of elements which organisations must be alert to at every stage as new elements of their IT infrastructure are spun up. It’s the responsibility of the IT, DevOps and security teams to work together and create a cohesive security plan which keeps in mind each stage of development, rollout and subsequent use by the wider company, and ensure that security isn’t just a tick box activity.

They either bring in the security teams to help them secure their toolchain or start thinking like attackers. This is the only way businesses can adapt to the new threats facing us.