Many industry observers have noticed that deception approaches are re-emerging in the collective attention of the operational [as opposed to research] security industry and community (“cyber”- community?). We even have a paper to prove it [Gartner access required].
Frankly, I’ve been working on this post for a long time – and it has been tearing at my soul. Let me first explain why – please treat this section as my “self-psycho-analysis by blog.” :–) As you know, I’ve been involved with The Honeynet Project since 2002 and deception approaches are very dear to my heart. On the other hand, I am well aware that many organizations’ security teams can barely keep their heads above water in such “strategic” activities as patching Windows and cleaning up infected machines – and they are in no shape to engage the attackers with deception approaches.
So, I am torn – do I write about deception and again only make a handful of security 1%-ers happy or do I focus on topics that are realistic to a majority of the organizations out there?
Let me try to do both – so the focus on DECEPTION AS DETECTION. For now, let’s forget about the sneaky deception tools and advanced high-interaction honeypotting tactics and think “can deception make our threat detection better?”
Why, yes, it can happen! Here is how:
- Honeypots [if deployed right] may give better detection signal/noise ratio since all activity there is either malicious or at least unintentional, so you can hope for some low “false negative” signal [in theory]
- Those who are failing to implement comprehensive monitoring can instrument a few “super-monitored” locations – honeypots – and hope that the attacker may touch them at some point while wandering around your environment
- In particular, most organizations have really bad internal network visibility, and a few “honey-sensors” may provide a small boost to such visibility – by detecting the internal recon activities, funky SMB sessions, other lateral movements, etc
- Honeytokens present a similar “crutch” for poorly monitored data locations: while it would be nice to monitor all data access, if you can monitor access to those planted records, you have some chance of detecting badness [so, the idea is ‘touch this – means bad; touch any other server — we have no idea what it means and have no time to investigate’]
- It is also easy to use a honeypot to create [admittedly, a mediocre] internal threat intel factory: automatically capture malware, extract indicators, and rapidly shove them into other detection tools, such as SIEM, EDR, etc [you may sometimes beat your threat intelligence vendor by hours if not days with this method]
Of course, “honey-things” and deception can also help you learn more about the attackers’ tools and tactics, gather other rich context information about their behaviors, degrade their situational awareness (so cool!) and do great many other fun things– however, those actually require hard work and are most definitely NOT for everybody….
P.S. My more astute readers will notice that every bullet point above contains “may”, “hope” and other weak words. This is by design! All of these honeypot / deception benefits may give you a boost to detection and you can hope to catch threats faster – unlike, say, the approach of “monitor / analyze everything” that will give you a boost and enable better threat detection…
P.S. Mr honeytoken inventor, got anything to add?
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
17 Comments
Check out OpenCanary (https://github.com/thinkst/opencanary).
Thanks — I am aware of this tool. Hoping to learn more about it soon.
Bottom line it all comes down to three points:
1. Can deception be viable for most organizations, as opposed to highly mature ones?
2. Can deception be easily deployed, at scale?
3. When put to the test, does it work?
That is exactly what Cymmetria has been doing and I believe it is no longer time for ifs and maybes, it has arrived and anyone can try it out for themselves rather than take my word for it.
Thanks a lot for the comment, Gadi. Exactly correct – but to me the #1 (“Can deception be viable for most organizations, as opposed to highly mature ones?”) really is the #1 question…..
We discussed the difference between a commercial EDR and FOSS EDR recently. I believe the hurdle for deception systems is a similar one: it is painful for orgs to wrap their heads around obfuscation/misdirection versus principled security. In EDR, obfuscation to a security strategist means that agents should be able to be modified with self-modifying code, hidden, ever-changing, and that their activities (e.g., analysis) are even hidden from potential adversaries.
The primary principle of security is “The enemy knows the system” and related to obfuscation/misdirection is the secondary principle, “Don’t rely on security by obscurity”. However, in other circles (perhaps even the IETF), the sentiment is, “Security through obscurity considered dangerous”. With military deception, and through many papers on denial and deception (or advanced forms of it, such as simulation and dissimulation). There is some confusion about obfuscation (e.g., showing the false or hiding the real) and obscurity (e.g., using a protocol or technology process to purposefully gain trade-secret advantage).
For deception systems, we have a few additional problems related to terminology that we must overcome. I think the first is the use of the word `honey’. It’s time to move on from it. I much prefer calling the technology what it really is: the underlying truth. There are two primary deception systems assets: deception engagement servers and deception engagement credentials. OpenCanary also provides web-beacon image technology that can be embedded in a service, such as a web app or mobile app (although, how would this work for Web Services?).
Another primary issue I feel that is not met in deception systems technology is that vendors and FOSS leaders do not include them in OS distributions by default. The closest we get is auditd, especially via SELinux. SELinux, however, is not a distro — it’s also typically turned off either during or right after installation. Commercial solutions won’t fix this problem.
Frameworks also do not include information by default about deception systems. You don’t see them spoken about in the NISF CSF and they aren’t any of the controls in IT COBIT or ISO 27001 and 27002. I believe it is because the industry has not yet built a framework around deception-systems terminology and approach.
Let’s face it; without a framework we cannot and will not defeat our adversaries (N.B., who are masters of deception). Adversaries have strategic capabilities. They link their tactics and goals to defender current-running strategy — not the other way around. Let’s say that an org such as JPMorganChase or Sony Pictures implements deception systems. What’s to stop the adversaries from knowing that these are implemented, how they are implemented, and how to cause massive misattribution? We already had misattribution issues with both of those real-world scenarios! Many leading-experts did not agree.
In these situations, there may be legal, contractual, political, and PR backlash against deception systems — just as there was against attribution itself. A false positive that leads to a quarantine by a deception system can violate laws against surveilling Europeans, employees, partners, and/or lawfully-abiding citizens. We have poor anomaly detectors today — they must support defender strategic goals in order to prove valuable. Can we detect indicators of deception using anomaly-based evidence today? Definitely not.
Threat intelligence is having a difficult enough time integrating into SOCs and the like. Defenders don’t understand adversaries because they don’t even understand themselves (summon Sun Tzu here). Yes, some SOCs have DFIR tools. Some have visibility into all or most malware distribution networks. Some even share threat intelligence. However, I have not seen a SOC that engages this information historically or as a trend (e.g., via Splunk Enterprise Security SA-Splice) and support that intelligence analytically enough to also observe or analyze deception systems (N.B., I believe that may be the final step, though — so some orgs, the top-tier, are almost there).
However, for the many who do not have the basics covered, especially ability to map adversary TTPs that include deception-based TTPs (to additionally include adversary counterdeception TTPs) — deception systems should likely remain a non-starter. This is why deception systems are considered an advanced technique in cyber. Through frameworks and OS defaults, I believe that deception systems will be promoted and integrated — however for even the most-strategic this may be another 3 years from now or longer.
Thanks a lot for the comments, as insightful as ever [if not more so :-)] Deception in security frameworks (ISO, NIST CYber, etc) will take years, if it will happen at all. But a separate framework for deception …this does sound tempting to create…
Re: SOCs, the more mature SOC *do* use TI well , including TTPs, etc , so I’d say your point was unnecessarily pessimistic [well, it really wasn’t since such mature SOCs are a tiny minority]
Deception as distraction could be a “force multiplier” for an organization with limited resources.
An example is real world case:
A TOP-10 company in Russia hired a leading audit consultancy to deliver penetration test to it’s regional branches. Dozens of branches were in scope, but the vendor failed just once. Branches were different – some had security teams of 5, some of 3, but “unhackable” branch had just one security admin. The admin configured honeypots, and the vendor just spent available time inside it.
THanks for the comment. A great story indeed! But I am sure this branch had other controls, not just honeypots, right?
These (i.e., your `controls’ and `honeypots’) are separate control categories though. When you speak of controls, you mean it only in the classic sense (e.g., IT COBIT) not in ways that we understand modern cyber risk (i.e., OpenGroup FAIR).
In FAIR, vulnerability controls help very little to reduce the Loss Event Frequency, while deterrence controls (which affect Probability of Action) and avoidance controls (which affect the Contact Frequency — both variables affecting the Threat Event Frequency) can provide a ton of actual influence over the variables. This is especially true when orgs Understand the Adversaries (link — https://www.mitre.org/sites/default/files/pdf/12_3795.pdf ). This is why deception systems (and deception / counterdeception frameworks) go hand-in hand with threat intelligence. It’s interesting to note that they do not have to go along with counterintelligence — regular intelligence analysis, such as strategic warning, can benefit from deception and counterdeception practices.
Honeypots, or deception engagement servers, provide an avoidance control that affects the Contact Frequency and reduces the Threat and Loss Event Frequencies.
>Honeypots, or deception engagement servers, provide an avoidance control
Well, they *may* provide that, but the challenge of getting the attacker there is [IMHO] very hard. So, I see more people realizing the detection benefits, but probably not much of deterrence… well…not for the most orgs maybe?
BTW, I did use “control” in the old sense [=any security measure], not necessarily Prevention/Detection/Response only. So avoidance or deterrence control will qualify then as controls
I appreciate that we are all influenced by our experiences and mine are heavily biased by the discussions and customer wins that are being seeing for deception as a line of defense against attackers.
Based upon Attivo sales results and daily prospect discussions, the marketplace is showing much more interest in deception than you imply. Interest is also not limited to large organizations since deployment can be completed in 30 minutes and because of deception’s inherent efficiency, which negates the need for additional IT staff for ongoing operations.
Customers are adopting deception for 4 primary reasons. 1) Visibility into what has bypassed other prevention systems, including insider threat actors 2) Efficiency. Alerts are based on actual substantiated engagement, no dependency on signatures or data base look up, and are not prone to high false positives as seen with monitoring and big data solutions. (Why additional resources are not required.) 3) Time. Deception deceives and distracts the attacker, giving organizations the opportunity and real-time alert to thwart an attack. Today’s average detection time is 4 months without deception. 4) Risk management. Zero day attacks, CryptoLocker, Phishing Stolen Credential, and the list goes on of attack vectors that bypass other solutions. Deception is in many cases the last and final defense before data is exfiltrated or damages done.
Lawrence Pingree stated in an earlier report that deception would be seen by 10% of enterprises by 2018. Based on the results we are seeing, his estimate is more aligned and arguably conservative. I would encourage organizations to read his research and give deception a try, if for no other reason, but to know what is lurking in your network… just because you don’t know doesn’t mean that it won’t hurt you.
Carolyn, thanks a lot for the comments. Indeed, you present a good case for using more deception. I am fully on board with your items 1) and 2); I question the 3) for most organizations [it is true for the “top shelf” guys, for sure] and I don’t understand the 4) argument at all (after all, most security measures are “risk management”).
Also, deception *MAY* see threats that bypassed other controls, but of course there are no guarantees that the attacker will stumble upon the sensor/honeypot, even if enticed…
Indeed, we will be seeing more deception, I agree. The exact percentages are not known to me at this time, but IT inertia is a VERY powerful force 🙁
Anton, thanks for engaging in the comments and dialogue. Seems like we are aligned on 1-3 noting that a fair amount of Attivo customers are not Fortune level which I assume you put in the “top shelf” category. They adopted for the core reason that they don’t have large IT staff/ the resources to chase large numbers of alerts.
For number 4) the point was centered on the growing number of attack types that get through even the best prevention systems. Once inside the network, what other solutions can reliably detect attacks without known attack patterns/signatures, can detect lateral movement, and don’t generate a large volume of false positives. Stolen credential and insider attacks also go undetected by these other methods. This is why I highlight deception as an approach that detects all types of attacks and covers the gaps left by other solutions.
There are no guarantees, though deception techniques are highly advanced and Attivo has passed through rigorous testing with prospects. We are extremely confident that deception is effective.
I agree that Inertia is a very powerful force, that said, the need to do everything possible to protect a company’s most valuable assets and brand is a pretty powerful force too… one that we see is rapidly gaining budget approvals and customer adoption.
Ultimately, I should let our customers do the talking and would be happy to make the connections.
@anton: Deception-based solutions ARE changing the landscape. Different vendors implement and innovate it differently and there’s real market need (as proved by each company). I believe that there are some segments that will adopt it faster due to the reasons that you listed. For example, in those locations where other solutions can’t provide visibility or detect breaches. We are beyond the 1%…
Thanks a lot for the comment — I am happy to hear that the popularity of deception measures is growing. Do you have some data on comparative motivations/drivers and use cases for different companies?
@anton: I do not have data that I cam share publicly. There are many anecdotal stories indicating that adoption of deception technologies is fast, comparing to other, at their time, ground breaking technologies like stateful inspection, WAF or DAM technologies which I was fortunate enough to witness first hand. RSA conference is only weeks away. It would be a great opportunity to meet end-users and get their feedback….
Thanks for the comment — looking forward to continuing the discussion at RSA or elsewhere.