Exercise A - Firewall Rule Optimizer

Exercise Metadata

Field	Value
Duration	~25 minutes
Type	Workflow Agent
Focus	Prompt engineering + Knowledge Stores

Scenario

Your network security team exports firewall rule reports periodically. These reports contain hundreds of rules accumulated over years, many of which are outdated, overly permissive, or redundant. Manual review is time-consuming and error-prone.

Objective

Build a Kindo Workflow Agent that ingests a firewall rule report, analyzes each rule against security best practices, and produces a structured cleanup report.

Output Categories

Category	Meaning	Example Indicators
RISKY	Significant security exposure	any-to-any rules, inbound to sensitive ports
OVER-PERMISSIVE	Broader than necessary	allow all ports, overly broad ranges
UNUSED	Zero or negligible hit counts	0 hits over 90+ days
REDUNDANT	Covered by another rule	traffic fully covered by higher-priority rule
COMPLIANT	Correctly scoped and actively used	specific source/dest, appropriate ports, healthy hit count

Prerequisites

• Kindo account with access to the training instance
• Sample firewall rule report: Download sample-firewall-rules.txt

About the Sample Data

The sample firewall rule report contains 40 rules representing a realistic corporate firewall accumulated over several years. The rules include a deliberate mix of:

• Clean rules that are correctly scoped and actively used (web server access, monitoring, security tooling)
• Risky rules with direct internet exposure to sensitive services (SSH, RDP, MySQL open to any)
• Over-permissive rules with overly broad scope (any-to-any permits, full internal subnet access)
• Unused rules with zero hit counts from decommissioned projects, expired contracts, or completed engagements
• Redundant rules whose traffic is already covered by broader rules at higher priority

As you iterate through the prompt engineering steps below, notice how your output quality changes — not just in formatting, but in whether the agent catches subtle issues like dev-to-prod database access or guest WiFi misconfigurations.

Step 1 - Create the Agent (3 min)

1. Open Agents in the left sidebar.
2. Click Create an Agent.
3. Select Workflow Agent.
4. Configure:
   • Name: Firewall Rule Optimizer
   • Description: Analyzes firewall rule reports and categorizes rules for cleanup.

Step 2 - Set Up the Knowledge Store (3 min)

1. In the Agent Configuration panel, click Add Knowledge Store.
2. Upload the sample firewall rule report (sample-firewall-rules.txt).

Tip

The Knowledge Store is the agent’s reference library. Structured and focused source files produce cleaner and more consistent analysis. CSV works well here because each row is a self-contained rule with consistent columns — the model can process it systematically.

Step 3 - Build the Analysis Prompt Iteratively (12 min)

This is the core teaching moment of the exercise. Instead of pasting a final prompt immediately, you will build it in three iterations and compare how each change affects output quality.

1. Click + to add a step and choose LLM Step.
2. Name the step: Analyze and Categorize Rules.
3. Use each iteration below, run it, and compare outputs.

Iteration 1 - Start Simple

Analyze the firewall rules in the knowledge store and identify which ones are risky or should be cleaned up.

What to observe

Run this and look at the output critically. You will likely see:

• Vague language — “this rule might be concerning” instead of a concrete verdict
• Inconsistent structure — some rules get a paragraph, others get a sentence
• Missing rules — the model may skip rules it considers “fine” without telling you
• No confidence signal — you can’t tell which findings the model is sure about versus guessing

Iteration 2 - Add Role and Structure

You are a senior network security engineer performing a firewall rule audit.

Analyze the firewall rule report in the knowledge store. For each rule, categorize it into exactly ONE of:
1. RISKY - Significant security exposure (e.g., any-to-any rules, inbound to sensitive ports)
2. OVER-PERMISSIVE - Broader than necessary
3. UNUSED - Zero or near-zero hit counts
4. REDUNDANT - Already covered by another rule
5. COMPLIANT - Correctly scoped, actively used, follows best practices

Output as a table with columns: Rule ID | Rule Name | Category | Recommendation

Why this works

Three changes made a big difference:

1. Role specification (“senior network security engineer”) sets the analysis depth and vocabulary
2. Explicit categories constrain the model to consistent buckets instead of freeform commentary
3. Fixed table format makes the output readable and usable downstream

Compare this output to Iteration 1. You should see every rule accounted for and consistently categorized.

Iteration 3 - Production Prompt

You are a senior network security engineer performing a firewall rule audit.

TASK:
Analyze the firewall rule report in the knowledge store. For each rule, categorize it into exactly ONE of the following:

1. RISKY - Rules that create significant security exposure (e.g., any-to-any rules, inbound access to sensitive ports from untrusted sources, rules allowing dangerous protocols)
2. OVER-PERMISSIVE - Rules broader than necessary (e.g., allow all ports when specific ports would suffice, overly broad source/destination ranges)
3. UNUSED - Rules with zero or negligible hit counts during the analysis period (0 hits over 90+ days = unused; <10 hits over 90 days = near-unused)
4. REDUNDANT - Rules whose traffic is already fully covered by another rule with equal or higher priority
5. COMPLIANT - Rules that are correctly scoped, actively used, and follow security best practices (specific source/destination, appropriate ports, healthy hit counts)

ANALYSIS GUIDELINES:
- Consider source, destination, service/port, action (permit/deny), and hit count
- For RISKY: any rule allowing inbound traffic from "any" to critical infrastructure ports (22, 3389, 1433, 3306, 5432) should be flagged
- For OVER-PERMISSIVE: compare against the principle of least privilege
- If a rule could belong to multiple categories, choose the highest-risk category

OUTPUT FORMAT:
| Rule ID | Rule Name | Category | Confidence | Risk Level | Recommendation |

CONFIDENCE LEVELS:
- HIGH - Clear indicators support the categorization
- MEDIUM - Some ambiguity but categorization is likely correct
- LOW - Insufficient data; manual review recommended

After the table, provide:
1. Summary count of rules per category
2. Top 5 highest-priority rules to remediate immediately
3. Recommended next steps

Key learning

Compare this output to Iteration 2. The improvements come from:

• Explicit thresholds (hit count numbers, specific port lists) remove ambiguity
• Analysis guidelines tell the model how to evaluate, not just what to look for
• Confidence levels support triage decisions — auto-remediate HIGH confidence findings, manually review LOW confidence ones
• Structured follow-up sections make the output actionable for a security operations manager

Every constraint you add improves actionability. This is the core prompt engineering lesson: precision in, precision out.

Step 4 - Add the Report Formatting Step (5 min)

Add a second LLM step named Format Cleanup Report.

Why a second step?

Separating analysis from formatting is a key workflow pattern. The first step focuses on accuracy (getting the categorization right). The second step focuses on presentation (making it useful for a specific audience). This separation also lets you swap the formatting step for different audiences — executive summary, CSV export, or Jira ticket templates — without re-running the analysis.

You are formatting the firewall rule analysis into an executive-ready cleanup report.

Take the categorized rule analysis from the previous step and produce:

SECTION 1 - EXECUTIVE SUMMARY
- Total rules analyzed, breakdown by category (count and percentage)
- Overall risk assessment (Critical / High / Medium / Low)
- Estimated effort to remediate

SECTION 2 - IMMEDIATE ACTION ITEMS
Top 10 highest-priority rules, sorted by risk:
- Rule ID and name
- Why it's flagged
- Recommended action (remove, tighten, merge, review)
- Estimated impact if left unaddressed

SECTION 3 - CATEGORY DETAIL
For each category, list all rules sorted by confidence level (HIGH first).

SECTION 4 - RECOMMENDATIONS
- Quick wins (high confidence, low effort)
- Rules requiring manual review (low confidence)
- Suggested review cadence going forward
- Integration recommendations (e.g., connect to CrowdStrike for threat-informed prioritization)

Keep the tone professional and direct. This report goes to the security operations manager.

Step 5 - Run and Review (5 min)

1. Click Generate or Run.
2. Validate output quality using the checklist below.
3. Re-run with one prompt tweak and compare.

Quality Checklist

• Categorization accuracy: categories align with the underlying rule evidence (e.g., FW-019 MySQL from any should be RISKY, not just OVER-PERMISSIVE)
• Confidence calibration: HIGH items are clearly supported, LOW items are truly ambiguous
• Executive utility: summary is actionable without reading every row
• Recommendation specificity: concrete next actions instead of generic language like “review this rule”
• Completeness: all 40 rules are accounted for — none silently skipped

Iterations to Try

• Lower the UNUSED threshold and compare volume shifts
• Add a new category such as EXPIRED for rules past a decommission date
• Request output as JSON or CSV instead of markdown table
• Upload a second file (a network security policy document) to the Knowledge Store and see if the agent references it during analysis

What You Learned

Concept	Where You Used It
Knowledge Stores	Uploaded the firewall CSV as a reference for analysis
Prompt engineering	Iterated from vague to production-quality through three versions
Role specification	Set the model’s expertise level and vocabulary
Output structuring	Controlled format with explicit tables, categories, and sections
Confidence levels	Added calibration signals for downstream triage
Multi-step workflows	Separated analysis from formatting for reusability

Discussion Points

• Which prompt iteration had the biggest impact on output quality, and why?
• What additional guardrails are needed before using this in production?
• Where could you connect ticketing or trigger automation to close the loop (e.g., auto-create a Jira ticket for each RISKY rule)?
• How would you adapt this pattern for a different security domain — vulnerability scan results, IAM policy reviews, or cloud security posture?

Troubleshooting

Issue	Likely Cause	How To Fix
Output is vague and inconsistent	Prompt lacks role, constraints, and schema	Move from Iteration 1 to Iteration 3 prompt structure
Most rules marked as RISKY	Categories are underspecified or rule data is sparse	Add explicit category definitions and confidence rules
Missing rules in output	Model hit context limits or skipped rows	Ask for chunked analysis (for example, 100 rules at a time) and merge results
Confidence levels all HIGH	Prompt does not define evidence standards	Keep the explicit HIGH/MEDIUM/LOW criteria block
Recommendations are generic	Formatting step not included	Add Step 4 report formatter and require prioritized actions

Next Exercise

Continue to Exercise B - Universal Security Triage Agent.