Cyber Decoy Deployment Guidance; CISA Weekly Bulletin Discontinued After September

Deception (“Honeypots”) is one of these ideas that keeps coming back about once every 10 years. Companies get started, and excitement builds around the idea until it fades away again. The biggest problem with deception is that it does not produce enough false positives. It is too easy to forget about the sensor, and quiet sensors are often considered of "lower value," but the opposite is true. I like CISA's approach to suggest a framework around deploying deception. This may help it gain traction in enterprise environments that have dismissed deception as more of a research or ad hoc technique rather than an integrated part of enterprise defense.

I am a big fan of cyber decoys, as they can be very effective in alerting you to an intruder. However, I would caution that they are not tools you can simply fire and forget. Cyber decoys need to be deployed, isolated, and monitored carefully to ensure that, should they be compromised, an attacker cannot use them as a platform to attack other systems within your organisation or indeed systems belonging to other organisations.

As a pentester, I'm only slightly embarrassed telling you that I 100% have fallen for decoys. Active defense/decoys/deception tech is a low-cost, high signal-to-noise ratio strategy that is horribly underused in the industry. You can start at canarytokens.org and generate a decoy file, URL, QR code, AWS key pair, etc.

Honeypots remain a valid part of your protection strategy. As part of a model where we assume compromise, strengthen that by having something to compromise and observe. Use the guidance to setup your decoy environment optimally.

I’ve always loved the concept of honeypots and deception for multiple reasons. For starters, I think they are a powerful and simple means for detection. Since these systems/tokens have no legitimate use, any interaction with them is suspect by default. However, for small to medium-sized business I really think the value stops there. I do not see a need for organizations to be deploying deception technologies if they are still struggling with the fundamentals (MFA, VulnOps, etc.). On the flip side, for organizations that have the resources and value in using more advanced deception technologies, AI can take deception to a whole new level for interacting with cyber attackers. Of course, this brings up the situation where we have defensive AI technologies interacting with and attempting to deceive offensive AI attacking technologies.

One question I always asked when clients would ask about deploying honeypots: How mature are your current processes/staff skills for dealing with your existing volume of alerts, and what is your Time to Respond to that load? After all, honeypots are really a form of host-based intrusion detection that if done right *should* only issue high-priority alerts. But if you are already having high-priority alerts get missed or mishandled, then (no matter the size of your organization) you are not going to see positive ROI on deploying honeypots. The CISA/MITRE guidance is a bit light on this aspect (see “Decoy Operation Process: Scenario”). One major disagreement with that guidance: The first thing to do if you see "Several executives have repeatedly failed phishing simulations, indicating elevated risk" is to drive use of strong authentication/MFA before spending on honeypots.

So we are going back to deception and honeypots? Maybe this time we can add more realism by using a digital twin. It doesn't always have to be new and novel to work.

It’s a given that everyone's infrastructure is constantly being tested for weaknesses. While cyber decoys add a layer of defense, it's far more prudent to spend tight cybersecurity budgets on essential hygiene first. Until you are fully confident in your patching, configuration, and monitoring, cyber decoy guidance can wait.

I really like the contrasts between Lance and Adrian in their comments here. I think they're both right. If an organization is struggling with MFA and basic vulnerability management, an elaborate deception platform probably isn't where I'd spend the next dollar. But useful deception doesn't have to be elaborate or expensive. A well-placed honeytoken or tar pit can generate an extraordinarily high-confidence alert precisely because nobody legitimate should touch it. The technique may be sophisticated, but the implementation doesn't have to be.

A lot of us are struggling to identify vulnerabilities that matter. The KEV mentioned by CISA is a good start, but it is a bit too reactive in my opinion. I think exposure management is the first step, but no external vulnerability feed will help you solve that problem. Instead, this is something you need to customize to your own situation, and vulnerability feeds are still needed to make the exposure data actionable.

It is time to review your subscriptions. If you're not already subscribed to the KEV, you may find it fills in a lot for the now-deprecated lists. Remember we're going _risk-based_, not _fix everything_. That requires some preparation on your part to make sure everything is identified and prioritized for timely application of patches and fixes.

This is a welcome move by CISA, especially since the bulletin had turned into a catch-all list. For organizations, staying current on vendor software updates remains the ultimate defense. More than anything else, that is what keeps attackers out.

To be useful, intelligence must be action oriented. It is the responsibility of the intelligence provider, not the user, to ensure that the signal-to-noise ratio is high. This reads to me as an attempt to reduce noise to highlight signal.

Yet another secure email gateway flaw. The reason that these systems (not just Cisco) tend to be dangerous is that they apply numerous third-party parsers to untrusted content. Vulnerabilities are almost a given in a system like this, and they need to be architected with these vulnerabilities in mind. Proper isolation and containerization go a long way to minimize the impact of some of these issues. Running the entire codebase as root is, of course, just the opposite of that but leads to more exciting and interesting compromises.

There is a certain irony when the systems designed to protect your organisation become the route attackers use to compromise it. Email security gateways and identity management systems are particularly attractive targets because of their privileged position within the network. Organisations should therefore treat vulnerabilities affecting security infrastructure as priority incidents, particularly when exploitation is already taking place. Patch quickly, but also follow Cisco's advice to review logs for evidence of compromise. Installing the patch closes the vulnerability, but it does not remove an attacker who may already be inside.

When we talk about sanitizing input we mean everywhere. Cisco was parsing an email, which is valid, but forgot to treat it as untrusted. Apparently a well-crafted email gets you admin privileges. This leaves us with two assignments: first, apply the updates; second, hunt for the IOCs. These are in the logs of your Cisco environment. As the exploit can be used to remove the on-device logs, go to your central log server to make sure nothing is overlooked. Target getting to ISE 3.5 patch 5 or beyond — don't take a chance on being unsupported.

The Cisco Email Gateway bug is a particularly nasty one in that it is SQL injection through email, which is exactly what the system is supposed to scan for. If you are running this box, patch it now; many of these systems sit at the edge of the network. As for Cisco ISE, this one looks like it could add users, and a system re-imaging could take the network down. Patch quickly on this one also.

In last week's NewsBites, I wrote that patch volume has become a systems problem. Here's the next chapter: Sometimes the patch itself becomes an operational incident. Testing, staged deployment, health checks, rollback, and rapid out-of-band remediation are all critical elements of your VulnOps process. In other words, your patching process itself needs resilience too for when things go wrong, as they inevitably will. Plan for it.

It appears rapid detection and automated generation of fixes has found limits. One of our challenges as we leverage AI to find and address flaws remains having appropriate human oversight to ensure fixes are complete and robust. This approach doesn't care how big or small you are — it's about making sure that digital intern is really fixing the whole problem and not causing further harm.

Less visible, but Apple is also starting to deploy more kernel monitoring and protection in the 27 branch of iOS. Apple has already released a beta for iOS 27.2, which includes additional kernel modules that may be used to better monitor processes in memory and identify common exploit techniques. I think that, moving forward, these types of mitigating controls will become increasingly important as patching falls behind, given the flood of vulnerabilities. The number of vulnerabilities Apple has patched has increased significantly, but not at the same rate as for companies like Microsoft and Oracle.

macOS 27 marks the end of an era. It marks the first macOS which doesn't support Intel/x86 hardware. Make sure that you have devices with Apple Silicon so you continue to keep things running the most current OS. While you're running that down, have your team do that too, and make sure they are also rolling the released updates across the board. That Apple moved away from Intel is not news; that's been in the works and announced. What is news is the lack of Intel support in their latest macOS. You should already be rolling out hardware replacement.

While these are implementation-induced vulnerabilities and many involve code that is common to macOS and iOS, those in macOS are more likely to be exploited because of the difference in fundamental security models.

So Oracle has made it easier by releasing quarterly updates, intended for rapid low-risk deployment. And like with everyone else, the quantity of fixes is increasing due to the use of AI to find and create fixes. While 800+ unique CVEs seems like a lot, there are likely fixes for Oracle products you don't have. Breaking this down, there are 159 patches for the e-business suite, 153 for Fusion middleware, 102 for Hyperion, 63 for Siebel CRM, 50 for Analytics, 31 for Communications, 19 each for Supply Chain & Virtualization, and lastly 16 for PeopleSoft. Many of the flaws are exploitable remotely, so it’s critical to make sure you're using layered defenses to protect/defend solutions implemented using these products.

Many of our readers were not even born when Oracle was announced with great claims for security.

Last week in NewsBites, I praised the FBI’s emphasis on "disrupt and impose cost." Operation PowerOFF is another example of what that looks like over time. DOJ says related US actions have charged 12 defendants and seized more than 100 DDoS-for-hire domains over the past eight years. One takedown will not end this market, but sustained disruption and international cooperation, including the FBI and the RCMP, can keep raising the cost and risk of running and buying these services, making cyber criminals miserable (as SANS's James Lyne likes to say). Keep at it, folks!

The ultimate goal in fighting cybercriminals is to arrest them and have them put in jail. A close second is causing as much pain and disruption as possible to increase their costs and reduce their profits. Disrupting platforms such as this therefore matters not simply because it takes infrastructure offline, but because it makes cybercrime that little bit harder and more expensive for those wishing to use it.

I may be easy to please, but I get excited to hear another malicious service for sale bites the dust. This was one of the largest DoS services, used to launch hundreds of thousands attacks across the Internet. Even with this shutdown, you still need to maintain DDOS protections.

Kudos to the US and partners for moving the needle on organized crime! Here's hoping the FBI's new cyber strategy (https://www.fbi.gov/investigate/cyber/cyber-strategy) increases the pace of these wins.

Finding out that you may have been breached because criminals are advertising your data for sale on the dark web is not where you want your incident response process to begin. I recommend reviewing this breach to see what lessons you may be able to learn from it to improve your own intrusion detection and alerting capabilities, so that you can detect an attacker before they have the opportunity to steal data or cause significant damage.

External facing systems being compromised and then used to go after peer system weaknesses. I keep coming back to the same questions: Are your internet-facing systems in best working order? Have you exposed them to the smallest set of systems possible with limits on what can approach?

CenterPoint says customer data was obtained through an external-facing system, while electric and gas delivery remained operational and undisrupted. That distinction matters. A breach at a utility is serious, but it does not automatically mean operational technology or the delivery of critical services was compromised. Some people see “CYBERATTACK ON ENERGY COMPANY” and immediately picture somebody hacking the grid. We must be precise about which part of the organization was affected. Defenders need that precision, and so does the public.

The International Meteor Organization is a nice reminder that cybersecurity impact does not scale neatly with an organization’s budget. This nonprofit supports a global scientific community, and the attack has left much of its site offline with weeks of partial downtime expected. We need to always take the so-called "Cyber Have-Nots" into account when we propose industry-wide initiatives and solutions. Smaller organizations often provide important, difficult-to-replace services without having enterprise-sized security teams and budgets. Risk follows mission, not revenue.

While I haven't seen anyone taking credit for the attack, IMO is focused on recovery. In this case, they are undertaking acceleration of existing plans to replace hardware and software, and to provide updated modernizations to services offered. It’s like they're changing the tires while setting a new speed record. Hopefully they'll be able to implement any fixes determined.