<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>SOC on Nsdd</title>
    <link>https://nsdd.club/tags/soc/</link>
    <description>Recent content in SOC on Nsdd</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 07 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://nsdd.club/tags/soc/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Before Handing Security Alerts to AI: Engineering a Defensive AI Agent</title>
      <link>https://nsdd.club/post/2026/08/07/defensive-ai-agent-engineering-en/</link>
      <pubDate>Fri, 07 Aug 2026 00:00:00 +0000</pubDate>
      
      <guid>https://nsdd.club/post/2026/08/07/defensive-ai-agent-engineering-en/</guid>
      <description>The starting point for this project was simple: a SOC rarely lacks alerts. What it lacks is the time, context, and consistency required to turn alerts into decisions.
WAF sees request characteristics, RASP sees runtime call stacks, HIPS sees host behavior, NDR sees network connections, and SIEM turns only part of that material into an event. The data is plentiful, but fields, timelines, evidence strength, and response language differ. During a peak, the work that consumes an analyst&amp;rsquo;s attention is often not discovering an entirely new attack.</description>
    </item>
    
    <item>
      <title>把安全告警交给 AI 之前：Defensive AI Agent 的工程化实践</title>
      <link>https://nsdd.club/post/2026/08/07/defensive-ai-agent-engineering/</link>
      <pubDate>Fri, 07 Aug 2026 00:00:00 +0000</pubDate>
      
      <guid>https://nsdd.club/post/2026/08/07/defensive-ai-agent-engineering/</guid>
      <description>这个项目的起点很朴素：SOC 从来不缺告警，缺的是把告警变成判断所需的时间、上下文和一致性。
WAF 看到请求特征，RASP 看到运行时调用栈，HIPS 看到主机行为，NDR 看到网络连接，SIEM 再把其中一部分拼成事件。数据并不少，但字段、时间线、证据强度和处置口径各不相同。高峰期里，分析师最耗精力的工作往往不是发现一个从未见过的攻击，而是重复完成以下步骤：理解厂商日志、补齐证据、寻找相似事件、写研判意见、列处置项，再确认哪些动作需要审批。
Defensive AI Agent 想解决的正是这一段工作。它不是替代安全设备，也不是给日志系统加一个聊天窗口；它更接近一个位于检测产品与响应流程之间的“研判网关”：统一接入证据，让模型承担归纳、关联和假设生成，再用确定性代码、人工复核与审批系统约束模型能把事情推进到哪里。
AI 正从回答问题走向参与流程 过去两年，安全领域使用大模型的方式已经有了一次明显迁移。最早的需求大多是解释一条日志、生成一段查询语句或总结一份报告；现在更有价值的方向，是让模型在受控工具和明确状态机中持续工作：读取 Case、提出调查计划、补查证据、修正假设，最后生成可执行但尚未执行的响应方案。
这个变化也带来新的工程要求。模型一旦从“回答者”变成“流程参与者”，问题就不再只是答案是否准确，还包括它看到了什么、调用了什么、是否越权、失败后告警去了哪里，以及一条错误经验会不会污染后续判断。
NIST Cyber AI Profile 的初步草案把 AI 与网络安全的交叉点概括为三个方向：保护 AI 系统、用 AI 增强防御、应对 AI 增强的攻击。Defensive AI Agent 主要落在第二个方向，但要真正用于安全运营，前两个方向的控制也必须同时进入设计。换句话说，不能一边让 AI 帮忙防御，一边把它本身做成新的高权限入口。
OWASP 对 Agentic AI 的讨论则更直接：工具误用、身份与权限滥用、目标劫持、记忆与上下文污染，都是 Agent 获得行动能力以后才会被放大的风险。Excessive Agency把根因归纳为功能过多、权限过大和自主性过强。我们的设计几乎是反着这三点展开的：工具做窄、权限只读、高影响动作交给独立审批。
真正难的不是接一个模型 API 第一版原型很容易做：收到 JSON，拼出 Prompt，请求模型，再把结果显示在页面上。真正进入联调后，难点很快从模型调用转向了系统工程。
   现场问题 如果只做“日志问答” 项目中的处理方式     五类产品字段与语义不同 Prompt 为每个厂商不断加例外 Mapping Profile 转换成稳定数据契约   模型慢、限流或暂时不可达 请求超时，告警状态不明 持久 Inbox、退避重试、deferred 与 DLQ   原始日志包含凭证、Cookie、个人信息 整段日志直接进入模型上下文 原文留在本地，模型只接收脱敏语义投影   同类告警反复到达 每条告警生成一套重复结论 按实体、规则与时间窗聚合 Case   模型结论听起来合理但证据不足 依赖分析师阅读后自行发现 Validator 独立检查证据、输出与权限   误报经验需要复用 把历史结论直接塞进 Prompt 分层记忆、人工晋升、范围与过期治理   建议动作可能影响生产 模型直接调用封禁或隔离接口 调查、审批、执行三层分离    项目由此形成了四条一直没有妥协的原则：事实与模型意见分开保存；概率分析与确定性门禁分开实现；调查与执行分开授权；模型故障时可以延迟处理，但不能悄悄换一种分析口径。</description>
    </item>
    
  </channel>
</rss>
