The world’s largest cybersecurity conference, RSA, concluded its 32nd edition a few weeks ago in San Francisco. Among the myriad of highlights, Kevin Mandia, CEO of Mandiant at Google Cloud, delivered a keynote addressing the current state of cybersecurity. Mandia posited:
“Beyond common safeguards and security tools, organizations can take decisive steps to bolster their defenses and enhance their chances of detecting, averting, or mitigating attacks […] Honeypots, or bogus accounts deliberately left unutilized by authorized users, serve as effective means to detect intrusions or malicious activities that security products can’t avert”.
Mandia’s advice for organizations to “Build honeypots” was one of his seven pointers to evade the attacks that might necessitate the involvement of Mandiant or similar incident response companies.
For clarity, honeypots are decoy systems designed to attract attackers and distract them from their real targets. Primarily used as a security measure to detect, deter, or scrutinize attackers’ attempts at unauthorized network access, honeypots can accumulate information about the attack and the attacker’s tactics, techniques, and procedures (TTPs) once they interact with it.
In a digital era marred by an escalating frequency of data breaches despite mounting annual security budgets, Mandia underlined the importance of a proactive stance to limit data breach impacts. This necessitates flipping the script on attackers, hence the renewed interest in honeypots.
Fishing Lures to Fishing Nets: The Analogy# Despite being an effective tool for tracking attackers and preventing data pilferage, honeypots have not seen widespread adoption due to their setup and maintenance complexities. For a honeypot to attract attackers, it must appear legitimate and isolated from the real production network, making them difficult for a blue team to set up and scale for developing intrusion detection capabilities.
The complications do not end there. In the contemporary world, the software supply chain is intricate, with numerous third-party components like SaaS tools, APIs, and libraries often sourced from different vendors and suppliers. These components are integrated at every level of the software building stack, challenging the concept of a “safe” perimeter that requires protection. This shifting line between what is internally controlled and what is not could undermine the purpose of honeypots. In this DevOps-centric world, source code management systems and continuous integration pipelines are the real lures for hackers, which traditional honeypots cannot mimic.
To ensure their software supply chain’s security and integrity, organizations need novel approaches like honeytokens. To honeypots, honeytokens are as fishing lures are to fishing nets: they demand minimal resources but are highly effective in detecting attacks.
Decoy Credentials: Honeytokens# Honeytokens, a subset of honeypots, are designed to resemble legitimate credentials or secrets. Upon use by an attacker, a honeytoken instantly triggers an alert, enabling defenders to respond promptly based on the indicators of compromise such as IP address, timestamp, user agents, source, and logs of all actions performed on the honeytoken and adjacent systems.
In the case of honeytokens, the bait is the credential. Upon system breach, hackers typically look for easy targets to escalate privileges, move laterally, or steal data. Programmatic credentials like cloud API keys, being recognizable pattern-wise and often containing valuable information for the attacker, are an ideal scanning target. Therefore, they become the preferred target for attackers to seek out and exploit during a breach. As such, they also become the easiest bait for defenders to disseminate, capable of being hosted on cloud assets, internal servers, third-party SaaS tools, as well as workstations or files.
On average, a data breach takes 327 days to identify. By distributing honeytokens across multiple locations, security teams can detect breaches within minutes, thereby boosting the security of the software delivery pipeline against potential intrusions. The simplicity of honeytokens negates the need for developing an entire deception system, allowing organizations to create, deploy, and manage honeytokens at an enterprise scale, securing thousands of code repositories simultaneously.
Intrusion Detection: The Future# The field of intrusion detection has remained understated for too long in the DevOps realm. The ground reality is that software supply chains have become prime targets for attackers who have realized that development and build environments are significantly less protected than production ones. Enhancing the accessibility of honeypot technology is vital, and it needs to be made easier to deploy at scale using automation.
GitGuardian, a code security platform, recently introduced its Honeytoken feature to fulfill this mission. As a leading entity in secrets detection and remediation, the company is uniquely poised to turn a problem, secrets sprawl, into a defensive advantage. The platform has long advocated for shared security responsibility between developers and AppSec analysts. Now, the objective is to “shift left” on intrusion detection by enabling a wider population to generate decoy credentials and place them strategically across the software development stack. This is made possible by providing developers with a tool to create honeytokens and place them in code repositories and the software supply chain.
The Honeytoken module also automatically identifies code leaks on GitHub. When users place honeytokens in their code, GitGuardian can determine if they have been leaked on public GitHub and where they did, considerably reducing the impact of breaches like those revealed by Twitter, LastPass,
