吾以人工智能之器，解Datadog、AWS、Cloudflare、Sysdig、PagerDuty之SOC实战难题，器为AI runner，且设本地AI之辔，其选模型之术，颇费周章
摘要
吾始以SOC之实问题为基：构AI之SOC分析师，使于M1 MacBook Pro本地运行，助日常安全之务，于既有之云原生监测警讯之栈也
环境已具周密之遥测与警讯之覆盖矣。
- AWS云踪
- AWS安全中心(AWS Security Hub)
- Route53 VPC DNS Firewall(路由53虚拟私有云DNS防火墙)
- 社会经济发展(Social Economic Development)
- 社交网络服务
- 云flare之记录
- 应用日志
- GitHub审计日志爬虫
- Datadog云安全检测
- Datadog 监 Kubernetes 与 AWS 之度
- Datadog 之仪表，涵 SOC 多般之用
- Sysdig 定 Kubernetes 之运策
- PagerDuty 之警通导引
此非无日志或警报之患。其真难，乃分析师之劳作也。SOC犹需一可复行之法，以审警报，合证物，撮要旨，辨缺境，成日安，而毋每时手动跃诸器。
工作之解，遂成地方人工智能系统分析之范式。
Ollama Local model runner
llama3.2:3b Stable default model for M1 daily SOC work
qwen3:8b Optional larger model for focused deeper analysis
Python harness SOC workflow, prompts, guardrails, and integrations
AI runner CLI Analyst-facing command-line interface
Datadog Primary log, signal, dashboard, and monitoring source
PagerDuty Alert and incident routing source
Sysdig Separate runtime policy signal source
Human analyst Final decision authority
要义在焉，唯模型非全解也。实效之方，乃合乎宜之模型、受控之桎梏、有界之提示、案例驱动之析理，及对本地MacBook硬件之切合预期。
原始之困
其志在构设基于本地AI之SOC分析师于M1 MacBook Pro。
其主脉络若此：
AWS CloudTrail
AWS Security Hub
Route53 VPC DNS Firewall
SES
SNS
Cloudflare logs
Application logs
GitHub audit logs crawler
|
v
Datadog
|
v
Datadog Cloud Security rules
Datadog monitors
Datadog dashboards
|
v
PagerDuty
Sysdig独立于众：
Kubernetes runtime activity
|
v
Sysdig runtime policies
|
v
PagerDuty
此别非小。Datadog乃日志、检测、监控、仪表盘之中枢。Sysdig未将日志送至Datadog，故其警报须视为独立之运行时安全信号路径。
所期之解非泛泛之本地聊伴。所期之解乃可复之本地社控助士，能佐：
- 日 SOC 复查
- 警讯分诊
- 云踪分析
- AWS安全中心发现审查
- Route53 DNS Firewall活动审查
- SES与SNS活动之检视
- ）GitHub审计日志审阅（
- ）应用日志审阅（
- ）PagerDuty事件概要（
- ）Sysdig运行时警报审阅（
- ）SOC笔记草拟（
- ）建议后续查询（
- ）关键设计决策：人工智能不可替代检测（
）
吾等早有要旨，谓本地之AI模型，勿为探测器。
Datadog与Sysdig已担此任：
- Datadog 收录日志与指标。
- Datadog Cloud Security 规则生发安全之讯。
- Datadog之监控器，能察运营及Kubernetes相关问题。
- Sysdig之运行时规约，可察 Kubernetes 运行时规约之违犯。
- PagerDuty 引警自 Datadog 与 Sysdig。
当是时，本地之 AI 应据于诸系统之上，为裁定与分析之层。
此谓 AI 之助，以应诸问：
- 何事发生？
- 何人、何务、何 IP、何服务、何帐户、何库藏、何 API 与之相关？
- 此变易，其势可恶乎？可期乎？可赘乎？可善乎？可误乎？
- 何证据之阙？
- 何查询应次第运行于Datadog？
- 此当升格乎？
- SOC之注当书何言？
- containment可取乎？抑或需人首肯？
此使权界清整。检测仍属Datadog与Sysdig，告警则归PagerDuty。本土AI助分析师速行，善问，致文牍之察察如一。
终局之构
终成之工架，本意简朴。
+------------------------------+
| AWS / Cloudflare / GitHub |
| Apps / SES / SNS / DNS FW |
+---------------+--------------+
|
v
+---------+
| Datadog |
| Logs |
| Signals |
| Metrics |
| Monitors|
+----+----+
|
v
+---------+
|PagerDuty|
+----+----+
+------------------+ +---------+
| Sysdig Runtime |------->|PagerDuty|
| Policies | +---------+
+------------------+
|
v
+------------------------------+
| Local AI SOC Analyst |
| M1 MacBook Pro |
| |
| Ollama |
| llama3.2:3b / qwen3:8b |
| Python SOC Harness |
| AI Runner CLI |
+------------------------------+
此本地人工智能分析师，初设唯读之功能。
其能撮要、会通、荐引、草拟。然不可自作生产之变。
凡如：
- 禁用IAM用户
- 更替访问之钥
- 阻绝IP于全域
- 改易Cloudflare WAF之行止，皆须人力核准。
- 禁用 Datadog 监控
- 处理 PagerDuty 紧急事件
- 调整 Sysdig 策略
- 隔离 Kubernetes 工作负载
- 变更生产设施
此乃要义，盖因误用自动化隔离之策，或致事态扩大，成更巨之运营之患，较之原初警报尤甚
AI Runner 之行事
人工智能之跑者，乃分析师所对之命令行界面也。
此乃吾辈日常操持之物也。
例如：
python ai_runner.py triage-json samples/sample_cloudtrail_delete_trail.json \
--use-case UC-006.3-cloudtrail-logging-disabled
python ai_runner.py security-signals --hours 24
python ai_runner.py pagerduty --hours 24
python ai_runner.py daily --hours 24 --out reports/daily_soc_report.md
跑者协理其事：
- 引安全之数据于所设之源。
- 择适SOC之提示。
- 构有界之事件束。
- 送提示与证物于Ollama。
- 受本地模型之结构化分析。
- 印其果或撰其报.
- 使事之序可复.
此役者非智之层也。其值在纪律之操。防析者手抄其录，手择其示，手整其出，手存其果，无时或怠.
此器何为
轭乃模型之控层也.
此乃聊天机器人与SOC工作流之别也.
轭所司者：
- Datadog API之用
- PagerDuty API之用
- 可选之Sysdig API之用
- 案例特定之提示
- SOC输出之结构
- 情境大小之限也.
- 模型超时配置
- 证之以事而析之
- 日报之撰
- 唯读操作行止
- 可复用之命令人构
轭具为模型设界。
若行 SOC 之务，此乃要义。本地 AI 模型，不可使其接续无涯之日志，而询曰：“有无不善之事？”此必致弱效，增幻象之患。
宜以精问相询，其式若此：
- 剖析此 CloudTrail 之变，察其或可规避之策。
- 撮要 Datadog 安防之讯，自昨日至今朝。
- 检视 PagerDuty 之事件，辨其于安全之关联.
- 据有限之证，草拟每日 SOC 之报.
- 察证之阙，拟后续之问.
模型思辨，具鞍者控其务.
模型选择之策
初，或择较大之模，如qwen3:8b 之貌可观，盖因事涉云日志、安理之思、结构之析也。
此诚善之始基也。若事束微而问需深悟，则大模尤效。
然目标之机乃 M1 MacBook Pro，非专司 GPU 之工位。是故实答有变。
试之，初小分诊流程成，然机渐怠。后重日报败，因地Ollama时序超限。
ReadTimeout: HTTPConnectionPool(host='127.0.0.1', port=11434): Read timed out. (read timeout=300)
彼误有用，盖示之：
- Python之具已行。
- 缰绳达奥拉玛于本机。
- Ollama 正處理此請求。
- 模型未於設置之超時內完成。
故此非 SOC 設計之過，乃本地推理負載之故：模型之巨細、提示之長短、超時之限，及硬體之疆界。
遂調整模型之策略：
| 任務 | 模型 | 何故 |
|---|---|---|
| 煙測 | llama3.2:3b |
迅捷而稳于M1 |
| 日 SOC 报告 | llama3.2:3b |
更可靠于每日之有限报告 |
| 潜心深究 | qwen3:8b |
当事件束较小时，颇为有用。 |
| 众源相系 | 若非谨慎节制，勿用之于M1。 | 或致迟滞与时限逾越 |
终为默认：
SOC_MODEL=llama3.2:3b
SOC_FAST_MODEL=llama3.2:3b
此乃适切之策。
小而可靠之模，胜于大而常冻或超时之模。
器物之限：M1 MacBook Pro 之重也
M1 MacBook Pro可运行有用之本地AI工作流，然此工作流必调适之。
主要之限，在：
- 本地模型冷启动时间
- 記憶之壓
- 更易其用
- 大字提示
- 寿考之期久
- Ollama超时
- 二十四时日志束
其解非弃地方法也。其解在使流程更小而更制：
Use a smaller default model.
Limit daily prompt size.
Start with 6-hour reports.
Increase to 24 hours after validation.
Increase the Ollama timeout where needed.
Avoid sending excessive raw logs to the model.
Use focused use-case prompts.
此乃使方案可用之由也。
吾辈所遇之困厄及其解法
一。ollama ps显无物
查何模型在运。ollama ps 乃无所得。
此非恒示有弊。
ollama ps 显内存中所载之模。若模已毕而卸，或显无物。
有益之检：
ollama list
显已装之模。
ollama ps
进入全屏模式
ollama run llama3.2:3b
手动启动模型
此区分有助于避免将正常的Ollama状态误判为失败
7. Mac卡顿
运行本地模型后，Mac变得迟缓
其故盖因地之推论负荷，尤若所用者乃大模也。
其解在于先运小模也。
SOC_MODEL=llama3.2:3b python ai_runner.py triage-json samples/sample_cloudtrail_delete_trail.json \
--use-case UC-006.3-cloudtrail-logging-disabled
为稳，Ollama亦可限之：
export OLLAMA_NUM_PARALLEL=1
export OLLAMA_MAX_LOADED_MODELS=1
export OLLAMA_KEEP_ALIVE=30m
七日报告之期已至
日常之命失，盖模型未于设时之限内返也。
ReadTimeout: HTTPConnectionPool(host='127.0.0.1', port=11434): Read timed out. (read timeout=300)
其修有三者：
- 用之
llama3.2:3b为日报之用。 - 减省日示之量。
- 宜增本地模型之超时。
更安全之初次运行也：
SOC_MODEL=llama3.2:3b python ai_runner.py daily --hours 6 --out reports/daily_soc_report.md
乃缩之：
SOC_MODEL=llama3.2:3b python ai_runner.py daily --hours 24 --out reports/daily_soc_report.md
课则：日报当撮要界证，毋纳无涯原牍于地模。
首获SOC分诊成功
首试之成，用云迹样本一。StopLogging事也。
此乃一意蕴深长之试，盖欲阻 CloudTrail 记录者，或示防御规避，或显非授权之管理活动，抑或凭证已遭窃取也。
人工智能生成高风险之SOC式结果，类此：
{
"severity": "High",
"confidence": 85,
"disposition": "true_positive",
"summary": "Suspicious attempt to stop CloudTrail logging...",
"suspicious_indicators": [
"StopLogging event by IAM user 'svc-deploy'",
"Source IP 203.0.113.45",
"User agent python-requests/2.32"
]
}
此证其核之务也。
Local venv works.
Dependencies are installed.
AI runner executes.
Harness builds the prompt.
Ollama receives the request.
Local model returns SOC-style analysis.
次进者，乃严定所期之效，使模常涵遗证，并荐后续诘问。于生产之SOC用，此域甚要，盖因之使析者据实立根。
例：社会大众熟知之品牌/产品名（如 iPhone、iPad、Google、Microsoft、Apple、Android、iOS、Windows、Linux、GitHub、Twitter/X）直接保留原名，不翻译。其他品牌名、产品名、网站名、公司名、人名等专有名词翻译为中文后在括号中保留原文，例如"IT Home(IT之家)"。
云踪日志已禁
用例：
UC-006.3-cloudtrail-logging-disabled
目的：
探查云踪可能之篡改或防御规避
示例指令：
python ai_runner.py datadog-query \
--query 'source:cloudtrail @evt.name:(StopLogging OR DeleteTrail OR UpdateTrail OR PutEventSelectors)' \
--hours 24 \
--use-case UC-006.3-cloudtrail-logging-disabled
续证当含：
- 演员之身份
- 源IP
- 用户代理
- 我有权限
- 更易车票
- 事毕之後，蹊徑之狀
- 相关 IAM 变更
- 安危枢要之见
- 同账户或身份之其他Datadog信号
身份權限提升
使用案例：
UC-007-iam-privilege-escalation
示例命令：
python ai_runner.py datadog-query \
--query 'source:cloudtrail @evt.name:(AttachUserPolicy OR PutUserPolicy OR CreateAccessKey OR UpdateAssumeRolePolicy OR PassRole)' \
--hours 24 \
--use-case UC-007-iam-privilege-escalation
人工智能應助辨此舉為預期之行政操作、自動部署之行為，抑或可疑之權限提升。
云锋防火墙活动
用例：
UC-011-cloudflare-waf-attack
示例指令：
python ai_runner.py datadog-query \
--query 'source:cloudflare (@action:block OR @action:challenge OR @security_action:block)' \
--hours 24 \
--use-case UC-011-cloudflare-waf-attack
人工智能当总括源流分布、所攻路径、防火墙之举措、突增之态，及有无流讯绕过防护。
路由53域名防火墙活动
应用场景：
UC-010-route53-dns-firewall-blocks
示例命令：
python ai_runner.py datadog-query \
--query 'source:route53resolverdnsfirewall OR source:route53 @action:block' \
--hours 24 \
--use-case UC-010-route53-dns-firewall-blocks
人工智能当助辨诡域，察损工役，究常客，辨阻事之属，乃 malware、误设，抑或期试耶？
GitHub 审计风险
用例：
UC-014-github-audit-risk
例令：
python ai_runner.py datadog-query \
--query 'source:github (@action:*deploy_key* OR @action:*repo* OR @action:*workflow* OR @action:*branch_protection*)' \
--hours 24 \
--use-case UC-014-github-audit-risk
人工智能当专注于风险库藏之变，作业流程之变，部署钥钥之动，分支保护之变，及非常之行政行事.
所举诸案，仅其一二。其机甚巨。若能循其架构，则成事可期.
日课之作业流程
稳当之作业已成：
起Ollama
ollama serve
2. 激活项目环境
cd /Users/tariqual/Documents/local_ai_soc_analyst
source .venv/bin/activate
3. 确认模型可用
ollama list
4. 运行烟雾测试
python ai_runner.py triage-json samples/sample_cloudtrail_delete_trail.json \
--use-case UC-006.3-cloudtrail-logging-disabled
五、先行安日报
SOC_MODEL=llama3.2:3b python ai_runner.py daily --hours 6 --out reports/daily_soc_report.md
六、安报既成，乃行全日报
SOC_MODEL=llama3.2:3b python ai_runner.py daily --hours 24 --out reports/daily_soc_report.md
七、分析师当察其出
该报告应审阅如下：
- P0及P1之品
- 云踪行政之变
- 安危枢要之重或高见
- 云flare攻防之术
- Route53 DNS Firewall(路由53DNS防火墙)阻隔
- 社交网络滥用征兆
- GitHub审计活动
- PagerDuty事件
- Sysdig运行时警报
- 证物缺失
- 推荐Datadog查询
- 升级行动或控制建议
日报乃分析师之助，非自动事故之告。
何以此法为效
终解之效，在于其既循SOC之流程，复重硬件之实。
不欲使本地模型独任其事。
乃善用既有之安全架构：
Datadog detects and stores telemetry.
Sysdig detects runtime policy violations.
PagerDuty routes alerts.
The local AI harness gathers and structures evidence.
The model reasons over bounded context.
The analyst makes the final decision.
此乃切合实际之AI安全运营模式。
所得之识
1. 模型仅解之万一耳
强模型无流程则化身为闲谈之器。小模型配以精良之具则可成有益之SOC助人。
二、地之器宜形其制
M1 MacBook Pro可支持有用之本地AI工作流，然模型之大小与提示之大小必当节制。
三、日常 SOC 报告需摘要，非原始日志倾泻
大则缓，时则延。其善者，当询之，减之，撮要之，而后报之.
4. 首读其独，乃安之正道
智工可荐其制，然产之变，须待人可之.
5. 证之有法，方为要务
所察之事、所存之想、所缺之证、所荐之行，当分而述之.
6. 机器之控，即其运作为本。
此控能致周而复始，设限以御，示警以引，融源以通，构文以出。此乃其术之用也.
终局之效
吾等已得本地AI SOC分析师之解，合乎原设之题。
终解如下：
- 于M1 MacBook Pro本地运行。
- 以Ollama为本地模型运行器。
- 以
llama3.2:3b为稳定默认模型。 - 俟机器可堪，允
qwen3:8b以专注深析。 - 以 Python 之具，驭提示、境域、流程之变。
- 借 AI 运行器 CLI，行可复之 SOC 命令。
- 协 Datadog、PagerDuty，兼可择 Sysdig 之合。
- 容 CloudTrail、Security Hub、Route53 DNS 防火墙、SES、SNS、Cloudflare、GitHub 审计、应用日志、Kubernetes 相关警讯之审。
- 能生有益之鉴别，日供 SOC 报告。
- 避不安全之自动化，持制令以人可。
至大之成，非独使模型得于地。成在化地 AI 为可控之 SOC 工作流，虽器有局限而能行。
此乃引入人工智能于安全之实路也：始于真问题，持简架构，控爆半径，调适硬件，善分析师之流程。