“Attackers put in the time to know the network and the devices better than the defenders. That’s how they win.” It was a throwaway comment* from NSA’s Head of Cybersecurity Rob Joyce on Twitter, but this pithy soundbite – from someone at arguably the world’s best resourced information security colossus – was an important one.
Red Teamers (security professionals authorised to attack a network to reveal its weaknesses) have flagged the same point in a different way to The Stack on several occasions; regularly also noting that they use widely available tools that too often are unknown by network defenders; but which could also be used defensively.
That’s sometimes because they are not aware such tools exist; sometimes because they are not licensed to use them; or even more frequently, particularly in smaller organisations, because they are too busy putting out fires or playing helpdesk, database administrator and security professional all rolled into one underappreciated package — and tinkering with offensive tools in a rare window of downtime is playing with fire.
We asked a handful of cybersecurity professionals for their views on Rob Joyce’s comments.
Know the network and the devices best, or…
Phil Robinson, principal consultant and founder of Prism Infosec, the cybersecurity consultancy was quick to shoot down Joyce statement as overly broad. As he put it: “I’ve worked with many organisations that have a strong understanding of their IT estate and a decent awareness of their environment who have implemented robust defences that have met or exceeded industry best practice across their technology stacks.
“That doesn’t mean to say they won’t be compromised.
“Security breaches occur for a number of reasons. These range from a lack of coverage (OS and app patching), competence (configuration weaknesses), staff awareness (password insecurity), budget (holes in defence tech), or just plain bad luck (exploiting windows of opportunity) – not just ‘attacker time’. In the industry, you’ll hear a lot about Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) which are used to hawk security solutions but the truth is you need people and process – not just technology – to keep one step ahead of the attacker. There is no single solution or tool that can be deployed to protect against the possibility of a security breach, however there is a top five list of ‘common sense’ practices.
“My top five would be:
- Staff/User Awareness – regular security awareness training which covers the dangers of common attacks (spear phishing etc), what to look for and how to report quickly. Implement a “no blame” culture and encourage reports. You don’t want people covering their tracks for fear of reprisals from management.
- Device Security – ensure that devices (such as workstations and servers but also mobile devices and other networking hardware) are configured to be as secure as possible, with users having a low level of privilege, effective Anti-Virus (AV) and/or Endpoint Detection and Response (EDR) software deployed. Remove unnecessary software, follow best practice guides on hardening (e.g. NCSC and CIS) and limit execution of unknown executables and scripts (e.g. Microsoft Defender Application Control).
- Centralised Management – wherever possible use a centralised security management solutions (such as Mobile Device Management, centralised AV/EDR consoles and centralised patch management tools).
- Logging and Event Reporting – in the absence of a SOC or SIEM solution, wherever logs and events can be enabled across the technology stack, make sure these are set-up and tuned. Ensure coverage at firewall, network device (switch/router), workstations, servers, applications and cloud services. Ensure that logging is not overwhelming to prevent alert fatigue and that key events are prioritised (e.g. multiple password failures, AV/EDR alerts, unexpected privilege escalation)
- Robust Authentication – many breaches (particularly for Internet-based services) occur due to weak passwords combined with a lack of additional controls such as MFA or password lockouts. Review all login interfaces (prioritising Internet-facing) and ensure that as many as possible support these controls.”
Shadow IT remains a risk…
Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Centre adds: “When we hear the refrain of ‘attackers know the network better than defenders,’ what that [often] really means is an attacker is in a better position to identify software running on a network that operates outside of the normal IT world. Things like shadow IT efforts, developer labs, BYO devices, and even IT managed devices that aren’t viewed as “software,” but rather as “hardware” such as CCTV cameras and security door strikes.
He adds: “Software is everywhere, and if IT doesn’t know what purpose it serves, who is responsible for it, how to patch it and how it should be configured, then that knowledge gap represents an opening for an attacker. While it’s easy to focus attention on tooling and services to help bridge the gap, a few simple steps can go a long way in identifying gaps. The starting point is to identify all the software that is supposed to be running in the business, where it came from and how it’s patched. The next step is to identify any device that wasn’t part of that initial inventory – a task that is made easier with a mapping of IP address from DHCP to device.
“The final stage of information gathering is to identify which cloud services are used within the business – a task made harder with remote work due to COVID. From there a series of threat models can be created, but the key is to focus on what damage an attacker might do if they were to gain access to the data being processed on the device, or to the device itself. Armed with the inventory, and some basic threat models, it then becomes possible apply lessons from frameworks like MITRE ATT&CK. Ultimately, you’re trying to address concerns like being unable to patch software you don’t know you’re running or manage data access to unprotected data sources.”
*With apologies to Rob Joyce, who was warned we were going to take his (important, if obviously truncated) Tweet and build something more substantial around it but abstained from getting involved.