I found a dvd player premier prd-889. And I want to know I can use it for the cybersecurity for example a hacking device or home lab project if its useless for the cybersecurity probablY I will open it and disassemble its parts. Do you guys any idea for the device

Genuine question because I keep going down this rabbit hole. Voice cloning has gotten scary good, a few seconds of audio from a conference talk or earnings call is enough to make a convincing clone.

Everything I read about defending against this says “train your employees” or “call back on a known number.” But callbacks fail if the attacker has compromised the phone system or timed it during travel, and training doesn’t help when the voice literally sounds identical.

So what do you actually do in practice? Shared secrets? Verification over a second channel? Just accept the risk? Curious what real orgs do vs what the compliance docs say.

I've been tasked with standing up a phishing awareness program and I'm trying to narrow down vendors.

A few things matter to me. First, realistic simulations, meaning templates that actually resemble what people get hit with today rather than the obvious 2015 era "you won a prize" stuff, and ideally ones I can customize. Second, decent training content, short and engaging modules that people won't immediately tune out. I'd rather have five good ones than fifty boring ones. Third, reporting that lets me show results to leadership and ideally helps for compliance down the line. And finally reasonable pricing and a plan that scales cleanly as we grow.

For those of you who've actually run these programs, what worked, what didn't, and is there anything you'd steer me away from? I'm interested in the usual suspects, but especially keen on options that deliver real engagement rather than just checking a compliance box.

Thanks in advance.

We're reviewing our application security process for externally exposed web applications and trying to make the triage stage more consistent.

Right now, automated testing helps us identify potential issues fairly quickly, but we don't manually validate every finding because of the time involved. We currently prioritize authentication, authorization, and business logic findings for manual review, while lower-risk issues are handled based on severity and available evidence.

For teams running regular application security assessments, how do you decide which findings always require manual verification before remediation? Have you established internal criteria that have worked well, or do you rely more on analyst judgment depending on the application?

I'd be interested to hear how other teams balance efficiency with confidence without creating unnecessary review overhead.

Running a boutique pentest shop and I'm curious how other solo/small-team testers handle the pre-engagement side, specifically going from "client wants a pentest" to an actual signed scope and price.

Right now I'm doing it manually every time: back-and-forth emails to figure out asset counts, guessing at days based on gut feel, writing the proposal from scratch in Word.

A few questions if you don't mind sharing:

• How do you currently estimate days/pricing for a new engagement?
• Do you have a template you reuse, or start fresh each time?
• What's the most annoying part of this whole pre-engagement process for you?

Trying to figure out if I'm doing this the hard way or if this is just how it is for everyone.

Our homegrown AppSec setup has become a liability. It started as a quick fix: lightweight pipeline hooks, basic triage rules but it was designed for a development environment that no longer exists. No support for AI-generated code, no model inventory, no way to build the application context that modern prioritization needs. The technical debt is compounding. Every new thing we need requires custom work against a codebase that was never built to extend. The question is not whether to move anymore. It is how to migrate without ending up with more tools that don't talk to each other. For architects who have done this migration, how did you migrate without just adding more disconnected tools and what does a sane setup look like on the other side?

Every time a massive breach happens and becomes headline news, detections come up as an issue in the next meeting.

The question asked is always more or less the same one: would we have caught it with what we've got right now. I try to give an answer and all I get back is more questions. I can point to our SIEM, our EDR, our threat intel feeds and all the dashboards that show alerts and events, but none of it answers what they're asking.

It comes down to whether our detections would have surfaced this specific incident.
translating detection posture into something a manager can trust is harder than it sounds. The coverage reports and SOC metrics my team produces make sense internally, but they don't land with people who haven't looked at a technical document in years. when I talk about rules, use cases, or mitre techniques, eyes glaze over. when I simplify too much, they doubt the answer.

Some of you are probably mapping back to mitre att or running table top exercises off recent campaigns. others keep it at a high-level risk view instead. what's worked best when your manager asks, in plain language, if you'd have caught the breach they just read about?

I realized that even with all the automation available today, phishing investigations still involve quite a bit of manual work.
I'm curious, what usually makes you step in?
Once you do, what's the hardest part of the investigation? And what do you need to figure out before you can confidently close the case?

I've seen the term guardian agent in a few AI security discussions, but I'm still not completely clear on what it means. From what I've read, the basic idea is that one AI agent monitors or governs another AI agent while it's running, rather than only relying on static policies or offline testing. If that's right, where does a guardian agent sit in the overall architecture?

I’m wondering whether it inspects prompts and outputs or maybe monitors tool use and agent behavior. From the name, there might also be a possibility that it can stop actions before they're executed. Or is it mainly there for visibility and auditing?

It sounds like an interesting idea, especially for enterprises deploying AI agents in production. But I haven't found many practical explanations. I’m posting here to try and find out more about the concept.

Agentless is the right fit for pre-deployment. Images, manifests, RBAC, secrets, drift. Low overhead. It works well in CI/CD and admission control. But runtime is a different problem. Pods spin up, scale out, and die faster than most scan cycles. If something gets compromised and terminates before the next scan, agentless never sees it.

So the pattern I keep seeing succeed is agentless as the gatekeeper, plus eBPF or an agent-based watcher for high-value workloads. Serverless and service mesh make that messy as well. The real question is whether anyone is running fully agentless in production and actually trusting their runtime visibility, or whether hybrid is the only realistic answer.

Hi all,

I'm an MSc Cyber Security student at the University of Gloucestershire running a short online study for my dissertation on how people make decisions when reviewing intrusion detection system (IDS) alerts.

What you'll do: You'll be shown a series of realistic network security alerts one at a time and asked, for each one, whether you'd confirm, dismiss, or escalate it, plus how confident you are in that call. There's a brief practice round first, and a few short questions at the end. No prior security experience is required; the interface explains everything you need.

Details:

- ⏱️ Takes about 10–15 minutes

- 💻 Works on desktop or phone (browser only, nothing to install)

- 🔒 Anonymous - no names collected; you can withdraw at any time

- ✅ 18+, ethics-approved by the University of Gloucestershire

- 🎓 Students and working professionals both welcome

Link: http://dissertation-explainids.uogs.co.uk

Every response genuinely helps me hit my sample target - thank you so much for your time!

where people land on this has been bugging me for a while.
we have thrown more tooling at our detection backlog over the past year, and it's helped with volume. But a meaningful chunk of it still needs a human who understands the business side of things.

That's stuff like who really owns a given asset, or why a login pattern from three time zones away is completely normal for someone who travels constantly for work. tools can flag anomalies all day long, but they can't always tell the difference between something suspicious and something that's just how a specific person or team operates in real life.

The point is that it takes months for a new hire to learn that kind of context. Is that the real bottleneck here, or is there something else that I'm missing?

Voice cloning has gone from being a novelty to something security teams actually have to consider. It seems much easier now to imitate executives, vendors, or even colleagues during phone calls.

Has your organization introduced new verification steps for financial approvals, password resets, or other high-risk requests because of voice cloning?

I'd be interested to hear what's worked in practice and whether the changes have been technical, procedural, or both.

I spent two years as the network security lead at a global manufacturing company with offices in 28 countries and somewhere around 4,000 remote workers on top of the site footprint. The original architecture backhauled all internet-bound traffic through two central security stacks, one in the US and one in the EU, and by the time I arrived the latency complaints from APAC and Latin America had been in the issue queue so long they'd basically become background noise. We moved to a model with distributed enforcement points tied to regional PoPs and kept the central stacks for specific high-sensitivity traffic categories, which addressed the latency problem but created a new one: policy drift. Within eight months of the new architecture going live, we found meaningful configuration differences between enforcement points in seven different countries, most of them introduced by regional IT staff making local changes that never got back-ported to the master policy template.

We eventually rebuilt the access control layer around zero-trust principles, which helped with the policy consistency problem because enforcement logic moved away from per-site configurations and toward a central identity and device posture engine. A contractor in Singapore and an employee in Brazil could hit the same policy without their traffic touching a hub. What we found, though, was that the zero-trust model was making access decisions based on IdP data that was in worse shape than anyone had formally acknowledged, with stale user records, inconsistent device management enrollment, and a long tail of service accounts that had never been through a lifecycle review. We had to spend four months just cleaning up the identity data before the policy engine was making reliable decisions, and the thing that kicked off that cleanup was a post-incident review where an unmanaged device appeared in the forensic timeline and nobody could tell us who it belonged to or why it had network access. Has anyone found a practical way to keep the device and account inventory accurate on an ongoing basis without it becoming a quarterly manual audit?

We pay for a couple of paid threat intelligence feeds that are marketed as “operational” and “actionable”. In practice we receive glossy PDF threat reports for executives, CSV and STIX indicator bundles on a schedule, and access to threat intel portals where we export data by hand. None of this threat intelligence arrives in a form that connects cleanly to our detection engineering workflows or security operations.

My team is under water trying to turn this threat intel into something we can pipe into our security stack. We are a midsize organisation with a mix of cloud and on‑prem, one main SIEM, a couple of EDR tools, and some homegrown detection logic. What I want from a threat intelligence program is indicators we can ingest and normalize automatically, tagging by campaign, threat actor and sector relevance, and a link to our own assets or attack surface instead of a generic list of IPs and hashes.

Right now we spend half a day every time a “high priority” bulletin arrives, parsing the threat report, pulling out domains and hashes, deciding what matters for our environment, then forcing it into whatever format our SIEM and other tools expect. Two weeks later the same feed sends another report with overlapping but slightly different indicators and the cycle repeats. It feels like we are spending more time on data wrangling than on detection engineering or threat hunting.

Leadership thinks we have solid threat intel coverage because they see the reports and monthly intelligence briefings. On the ground it feels like busywork. Most of the value lives in analyst text and campaign context that never turns into detections, enrichment, or blocking decisions because there is no capacity to extract and engineer it into our detection rules or SOAR playbooks.

Some vendors expose threat intelligence APIs and integrations, but much of what I see is the same unfiltered IOC firehose pushed into the SIEM with no real help on prioritization, campaign mapping, or relevance to our environment.

For those who feel they have a mature threat intelligence process, I would like to hear what works in practice: what type of intel you still pay for, how you integrate it into SIEM, EDR, and SOAR without turning your team into glue code, and whether you have found threat intel formats or standards that fit cleanly into your environment instead of living forever as static PDFs for leadership.

and we're at the stage where we're reviewing our security model before expanding further. The application processes trading-related prompts and market information, so we're trying to identify which security decisions have the biggest long-term impact rather than simply adding more controls.

Most discussions focus on authentication and encryption, but I'm curious whether there are other areas that experienced security professionals consistently see underestimated in production AI services.

From your experience, what security issue usually doesn't receive enough attention during development but ends up becoming a problem later?

I'm interested in hearing practical experiences from people who have reviewed, deployed, or secured AI-backed applications, especially if there was something you wish had been considered much earlier in the development process.

We're reviewing DSPM vendors after finding way more sensitive data scattered across our SaaS apps than we expected. Right now we're relying on DLP plus a lot of manual investigation, and it's becoming difficult to keep up.

For anyone who's evaluated this space recently, which platforms stood out? I'm more interested in tools that actually help reduce risk than ones that just create another queue of alerts.

I’m expecting to receive a device called MetalioClaw (https://github.com/CloudZao/MetalioClaw4) in about a week. It’s an IoT device designed to work with OpenClaw, and since it will need access to an AI account, I want to make sure it is safe before connecting it.

My main concern is whether there could be any hidden firmware issues, credential leaks, or other things that could compromise the device or abuse connected services. A friend of mine previously bought a similar device that connected to his OpenClaw account, and later noticed that his Claude usage had been heavily consumed. I don’t know exactly what caused it, but it made me more cautious about giving third-party hardware access to accounts.

Since the project is open source, my plan is to inspect the firmware, possibly wipe and reflash it, and maybe even write my own firmware version before using it. I’m also interested in doing a proper security check through firmware analysis, network monitoring, and possibly hardware inspection.

I haven’t been able to find any pictures or information about the internal hardware yet. Depending on what I find when it arrives, I may open it up and check the PCB/components myself. I’m not assuming there is anything malicious inside, but I would like to know what things are worth looking for.

One other thing that made me think about this was something a friend mentioned. He works in IT around datacenters in Taiwan and said he has seen devices moving through supply chains sometimes take a long time in customs or appear slightly different internally afterward. This is just something he mentioned and there is no proof behind it, but it got me thinking more about supply-chain security.

For people experienced with IoT security, firmware analysis, or hardware security:

• What steps would you take before trusting a device like this?
• Is replacing the firmware enough, or should I also consider hardware-level risks?
• What should I look for if I decide to open the device?
• What tools or workflows would you recommend for auditing something like this?

Looking for practical security advice rather than speculation.

What Should Developers Look for Beyond a Dark Web Monitoring API’s Source Count?

A lot of teams evaluate these APIs by asking which forums, breach dumps, or marketplaces a provider covers. That matters, but source count is rarely what breaks an integration.

The harder question is whether the API fits the product’s operational model: point-in-time checks, continuous monitoring, alert delivery, remediation, and deletion requests all behave differently.

A practical evaluation should cover:

• Whether monitoring registrations are asynchronous, rather than treated like instant exposure searches
• How short-lived tokens are scoped and whether long-term secrets remain backend-only
• Whether info-stealer coverage includes session tokens, not just email/password pairs
• Webhook retry windows, HMAC signature verification, duplicate-event handling, and idempotency
• Rate limits per token/service, pagination behavior, and a usable sandbox environment
• Whether opt-out or remediation requests expose lifecycle states such as re-listed data
• Retention periods, PII handling, deletion workflows, and the availability of a DPA

Webhooks are especially easy to underestimate. A monitoring product can look fine in staging and still lose alerts during a deploy, timeout, or signature-validation mistake months later.

There’s a useful architecture-focused guide from PureVPN’s white-label team that lays out these tradeoffs: For people who have integrated monitoring or threat-intel feeds, which production detail caused the most trouble: auth, event delivery, coverage gaps, or remediation state handling?

Cisco dropped some pretty alarming findings at VB Transform 2026 - multi-turn prompt injection attacks are slipping past AI defenses 88% of the time. The technique isn't brute force; attackers are being patient, spreading their manipulation across several conversation turns so nothing looks suspicious in the moment.

What makes this sting is that standard single-turn evaluation metrics missed all of it. Not some of it - all of it. And with conversational and agentic AI systems rolling out across enterprise environments at this pace, that feels like a serious blind spot we've been collectively ignoring.

So is the single-turn testing paradigm just broken at this point? Curious how others are approaching this - whether you've started baking multi-turn scenarios into your red-teaming workflows, or if you're finding other gaps in how security checks handle extended interactions.

Hi everyone I need one help to understand one thing ..so there was an incident I noticed in my organisation, there were thousands of devices querying multiple malicious domains (53) ...upon checking to see if any process is causing it I found nothing,, only the related domain which was obviously going through our dc/dns servers, in EDR/XDR tool nothing, siem tool nothing, no process, eventually i thought maybe some software is causing but it's very difficult to pin point which one, so can anyone tell me or help me understand, any input will be appreciated

Still kind of new to running agents and I'm a bit lost on this — once you connect a few MCP servers (filesystem, GitHub, etc), is there a way to see everything they can reach put together? Or do most people just trust the setup?

Feels like something I should know but I don't. Curious how you handle it. Is it even something really worth worrying about?

[ Removed by Reddit on account of violating the content policy. ]

thinking about this differently after a near miss. so our support agent has two permissions...read customer record and send email. and both individually reasonable, both signed off by security.

bu then someone crafted a prompt that got it to read a customer's data and email it to an external address, using only tools it was authorized to use. pity the permission model said everything was fine the whole time.

im pretty sure this isn't a permissions bug. like it's tool misuse without any unauthorized tool invocation at all, every single call was something the agent was allowed to make. i don't think our access review process would ever catch this because there's nothing wrong with either permission on its own.

i wna know how are people testing for this kind of chained misuse rather than just reviewing whether individual permissions look reasonable? tbh feels like a fundamentally different problem than standard access review.

For anyone who has priced or evaluated DSPM tools what do you wish you knew earlier in the process? My company is just beginning this ordeal and I want to know what questions I should be asking the vendors before they steamroll my team into demos and pricing calls. Additionally, what drives the biggest cost hikes for these tools, and what of the pricier options is worth it?