Events

Views Navigation

Event Views Navigation

Today

    • AI in the SOC: Separating the Tools That Actually Work From the Ones That Add More Noise

    Every security vendor now claims AI capabilities. For SOC teams already processing thousands of alerts per day, the promise is appealing: automated triage, intelligent prioritization, faster investigations. The reality is more complicated. Poorly implemented AI can generate its own layer of noise, create false confidence in automated decisions, and introduce opaque reasoning that analysts cannot validate or trust.

    The SOC teams seeing real results from AI are the ones asking the right questions before deploying it. They are auditing data quality first, defining what “automated” should and should not mean for their environment, and measuring whether AI is reducing time-to-resolution or just shifting where analysts spend their time.

    Getting this right requires alignment across detection, triage, investigation, and automation layers of the SOC – from SIEM and XDR to SOAR, MDR, and AI-driven analytics platforms.

    Topics include:

    • Evaluating AI-driven SOC tools based on measurable outcomes, not vendor claims
    • Addressing data quality and pipeline readiness before deploying AI-powered detection
    • Defining the right division of labor between automated triage and human investigation

    Join us for an honest look at where AI is delivering real value in security operations and where it is falling short.

    Topics:
    , , , , , , ,

    Living-Off-the-Land Attacks Dwell for Months. Here’s Why Your Detection Stack Keeps Missing Them.

    Living-off-the-land (LOTL) attacks do not drop malware, install backdoors, or trigger signature-based detections. They use the tools already present in your environment: PowerShell, WMI, legitimate remote administration utilities, and valid credentials. Nation-state groups and sophisticated criminal operators favor this approach because it blends seamlessly with normal administrative activity. Some LOTL intrusions dwell for months or even years before discovery.

    Most detection stacks were built to find things that should not be there. LOTL attacks invert the problem by using things that should be there. As a result, organizations are being forced to rethink how detection, identity, and behavioral signals work together across the stack to distinguish legitimate activity from attacker behavior.

    Addressing LOTL techniques requires coordination across endpoint, network, identity, and behavioral analytics capabilities – from EDR and XDR to ITDR, NDR, UEBA, and deception technologies.

    Topics include:

    • How LOTL attackers exploit native tools and legitimate credentials to evade detection
    • Why signature-based and file-based detection strategies fail against fileless techniques
    • Building a detection posture around behavioral analysis, credential monitoring, and assumed compromise

    Discover how to close the detection gaps that LOTL attackers are counting on and build defenses designed for threats that look like normal operations.

    Topics:
    , , , , , , , , , ,

    • AI-generated Code Is Shipping to Production. Is Your AppSec Pipeline Ready for What Comes Next?

    Eighty-one percent of organizations knowingly shipped vulnerable code in the past year. That number is about to get harder to manage. AI-assisted coding tools are accelerating output across engineering teams, and Gartner projects that by 2027, at least 30% of AppSec exposures will result from AI-driven "vibe coding" practices. The code patterns are different, the release cadences are faster, and the security assumptions baked into traditional testing tooling were not built for what AI produces. Organizations are deploying AI-generated code at a pace that outstrips their ability to review it.

    The challenge is not whether to allow AI-generated code. That decision has already been made by most engineering teams, with or without security's blessing. Addressing this requires rethinking how static and dynamic testing, software supply chain security, runtime protection, API security, and developer-native tooling work together across an AI-accelerated pipeline. Security teams that do not adapt their tooling and processes now will spend the next two years in reactive mode.

    Topics include:

    • New vulnerability patterns introduced by AI-generated and AI-assisted code
    • Adapting AppSec pipelines to handle accelerated release cycles without creating bottlenecks
    • Securing the AI-driven software supply chain, from dependencies and secrets to runtime behavior

    Explore how AppSec teams are retooling their programs to keep pace with AI-accelerated development before the gap becomes unmanageable.

    Topics:
    , , , , , , , ,

    Your Security Team Is Five People. The Threat Landscape Doesn't Care. What Managed Services Actually Solve.

    Most SOCs consist of two to ten full-time analysts. That number has not changed since the SANS Institute started tracking it in 2017. What has changed is the scope of coverage: cloud environments, SaaS platforms, remote endpoints, OT networks, and now AI workloads. The attack surface grew by orders of magnitude while headcount stayed flat. For mid-market and resource-constrained organizations, the math stopped working years ago.

    Managed security services are no longer a concession. They are an architectural decision. The question has shifted from "can we afford outside help?" to "can we afford not to extend coverage into the environments we currently cannot see?" Addressing this requires evaluating options across MDR, MSSP, XDR, and platform-driven co-managed models to find the right fit for each organization's risk profile and operational maturity. The organizations making managed services work are the ones that define clear boundaries: what stays internal, what gets co-managed, and what gets fully outsourced, while retaining control over incident response decisions and strategic direction.

    Topics include:

    • Defining which security functions to keep in-house, co-manage, or fully outsource
    • Extending detection and response coverage into cloud, SaaS, and hybrid environments with lean teams
    • Evaluating managed service providers based on transparency, integration, and measurable outcomes

    Learn how resource-constrained security teams are extending their coverage and capabilities through managed services without giving up control.

    Topics:
    , , , , , ,

    AI Regulations Are Moving Faster Than Your Compliance Framework. A Practical Catch-up Plan.

    The EU AI Act is in effect. NIST and ISO frameworks are expanding to cover machine identity hygiene and AI decision-making transparency. The SEC now requires public companies to disclose material cybersecurity incidents within four business days. And most GRC teams are still operating frameworks that were designed for a slower, more predictable regulatory cycle. The gap between what regulators expect and what compliance programs can deliver is growing with every new mandate, and AI adoption across the enterprise is accelerating the timeline.

    This is not just a documentation problem. AI introduces compliance challenges that existing GRC workflows were never designed to handle: models trained on data with unclear provenance, automated decisions that need audit trails, and AI deployments that span business units with no centralized oversight. Addressing this requires coordination across GRC platforms, data security tooling, AI governance solutions, and risk quantification approaches to build programs that keep pace with regulatory change. Organizations that treat AI governance as a future initiative rather than a current requirement are accumulating risk that becomes harder and more expensive to remediate with each quarter that passes.

    Topics include:

    • Mapping current GRC frameworks against emerging AI-specific regulatory requirements
    • Building audit trails and governance structures for AI-driven decisions and data usage
    • Moving from periodic compliance reviews to continuous assurance models

    Join us for a practical look at how GRC teams are updating their programs to keep pace with the regulatory demands of enterprise AI adoption.

    Topics:
    , , ,

    AI Models Are Trained on Your Sensitive Data. Who's Watching What Goes In and What Comes Out?

    Three-quarters of organizations now run AI in production environments. Ninety-nine percent reported at least one attack on their AI systems within the past year. The data flowing into and out of these models, training datasets, fine-tuning inputs, prompt histories, and generated outputs, represents a category of data exposure that most security programs were never built to monitor. When a large language model is fine-tuned on customer records, internal strategy documents, or proprietary code, the question of who can access what the model learned becomes urgent.

    AI pipelines create data exfiltration paths that blend into legitimate business operations. A model query that returns sensitive information is not a traditional data breach, but the impact can be identical. Addressing this requires coordination across DSPM, DLP, SaaS security, cloud security, and AI data governance platforms to build visibility into what data feeds AI systems, what those systems can reveal through inference, and whether access controls exist at each stage of the pipeline. The data security perimeter has expanded, and the tools designed to protect structured databases and file shares are not sufficient for the unstructured, dynamic data flows that AI depends on.

    Topics include:

    • Gaining visibility into what sensitive data enters AI training pipelines and inference endpoints
    • Extending data loss prevention and SaaS security strategies to cover AI-specific exfiltration vectors
    • Building governance frameworks for AI data flows across development, staging, and production

    Discover how organizations are closing the data security gap created by enterprise AI adoption before it becomes their next breach headline.

    Topics:
    , , , , , ,

    Your OT Network Wasn't Built for Cyberthreats. Attackers Know That Better Than You Do.

    Ransomware attempts against industrial operators jumped 46% in a single quarter. New threat groups are specifically targeting operational technology environments, and OT-specific malware is being sold on dark web forums with multi-protocol support and anti-forensics capabilities. The uncomfortable truth is that most OT and ICS environments were engineered for reliability and uptime, not cybersecurity. Legacy systems run outdated operating systems that cannot be patched, use protocols that lack encryption or authentication, and were never intended to be connected to enterprise IT networks or the internet.

    That isolation is gone. Digital transformation, IT/OT convergence, and the need for real-time data from the plant floor have connected these systems to corporate networks and cloud platforms. Dual IT/OT attacks now average $4.56 million per incident, and plant managers routinely bypass patching windows to meet production targets. Addressing this requires coordination across network visibility, segmentation, threat detection, and OT-specific vulnerability and asset management platforms to reduce cyber risk without introducing operational disruption or safety hazards. Security teams responsible for these environments need approaches built for the constraints of industrial operations, not IT playbooks adapted after the fact.

    Topics include:

    • Building comprehensive asset visibility in converged IT/OT environments
    • Deploying segmentation and threat detection tuned for OT protocols and operational baselines
    • Addressing legacy ICS vulnerabilities through compensating controls and risk-based prioritization

    Learn how industrial organizations are building cybersecurity programs that protect operational technology without compromising the uptime and safety these systems were designed to deliver.

    Topics:
    , , , ,

    Supply Chain Attacks Are Getting Worse. Your Questionnaire-based TPRM Program Can't Keep Up.

    More than one-third of data breaches now involve a compromised vendor or third party. A single compromised supplier can expose customer data, halt operations, and trigger regulatory penalties. And most organizations are still managing this risk through annual questionnaires and static spreadsheets that produce a snapshot of a vendor's security posture at a single point in time. Between assessments, vendors change their infrastructure, suffer incidents, and introduce new risks that are invisible until the next review cycle.

    The questionnaire model is breaking down from both sides. Vendors are overwhelmed by repetitive, duplicative assessments from every customer, and the resulting delays mean risk teams are making decisions on incomplete data. Meanwhile, regulatory frameworks are raising expectations: continuous oversight, documented remediation, and faster disclosure timelines are becoming standard requirements. Addressing this requires coordination across assessment automation, continuous monitoring, external risk intelligence, and vendor risk platforms to build TPRM programs that match the speed and scale of today's supply chain threat landscape.

    Topics include:

    • Supplementing point-in-time questionnaires with continuous external monitoring and risk intelligence
    • Automating vendor risk assessment workflows to scale oversight without proportional headcount increases
    • Aligning TPRM programs with evolving regulatory expectations around continuous third-party oversight

    Explore how organizations are modernizing their TPRM programs to match the speed and scale of today's supply chain threat landscape.

    Topics:
    , , , ,

    Context Lives in Five Different Tools. That's Why Your Incident Response Takes Hours Instead of Minutes.

    The average enterprise deploys 28 security monitoring tools. Each one generates its own alert stream, uses its own console, and stores context in its own format. When an incident occurs, analysts do not start by investigating. They start by assembling. They pull logs from the SIEM, check the EDR console, cross-reference the firewall, open the ticketing system, and manually piece together a timeline. This context-switching burns time, introduces errors, and extends incident response from minutes to hours. The tools designed to improve security are, in practice, fragmenting the information analysts need most.

    The organizations with the fastest response times are not necessarily using better tools. They are using fewer consoles, shared context, and automated enrichment that presents a unified investigation surface. Addressing this requires coordination across SIEM, XDR, SOAR, MDR, security analytics, and data enrichment platforms to collapse the distance between alert and decision. When an alert arrives pre-correlated with asset data, user context, threat intelligence, and historical activity, analysts skip the assembly phase and go straight to decision-making. That is the difference between a 15-minute investigation and a three-hour one.

    Topics include:

    • Reducing context-switching by consolidating investigation workflows across security tools
    • Automating alert enrichment with asset, identity, and threat intelligence context at the point of triage
    • Building incident response workflows that prioritize speed-to-decision over tool-by-tool investigation

    Learn how SOC teams are cutting investigation time by unifying the context that is currently scattered across their security stack.

    Topics:
    , , , , , ,