Step 1 – Start with an IOC

For this example, we’ll use a fictional IOC:

Domain: suspicious-example.test
IP: 203.0.113.50
SHA256: 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

These are test values, not real malicious infrastructure.

Step 2 – Ask AI to Convert the IOC

Instead of manually writing every rule, give the IOC to AI:

I'm working in an authorized security lab.

Convert these fictional IOCs into detection examples for:
1. Sigma
2. Suricata
3. YARA

IOC:
Domain: suspicious-example.test
IP: 203.0.113.50
SHA256: 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

For each rule:
- Explain what it detects
- Explain important fields
- Point out possible false positives

The AI can produce different rule formats depending on the tool you’re using.

For example, a Sigma rule might look conceptually like:

title: Suspicious Test Domain Access
status: test
logsource:
  category: proxy

detection:
  selection:
    url|contains: 'suspicious-example.test'

  condition: selection

level: high

Step 3 – Ask AI to Adapt the Rule

Different environments use different logging systems.

You can ask:

Adapt this detection logic for our web proxy logs.

Our domain field is called destination_domain.
Keep the detection logic the same.
Explain any changes you make.

This is much more useful than simply asking AI to “write a security rule.”

You’re providing the IOC + tool + log format + expected behavior.

Step 4 – Test Before Deployment

Never assume a generated rule is correct.

Test it against:

• known matching events
• known non-matching events
• similar but legitimate traffic
• unusual formatting

Then tune the rule to reduce false positives.

A Useful IOC Workflow

You can turn:

IOC
 ↓
AI
 ↓
Sigma / YARA / Suricata / SIEM Query
 ↓
Review
 ↓
Test
 ↓
Deploy

This makes AI useful as a security engineering assistant, rather than simply a tool for explaining cybersecurity concepts. The key is to provide enough context for AI to generate something that actually fits your environment.