| Solution |
The primary purpose of enabling Extended Log is enhanced forensic visibility. When Extended Log is disabled (the default), the DLP log entry only tells:
- That a DLP rule was triggered.
- The filename (if applicable).
- The matched DLP sensor and rule name.
- Basic session info (source, destination, user, etc.).
When Extended Log is enabled, the log entry includes the actual content snippet that triggered the match. This is invaluable for:
- Verification and Tuning: Confirming the match was accurate and not a false positive. Can see the exact text, credit card number, or pattern that caused the alert.
- Forensic Investigation: Understanding the full context of the incident, specific data being exfiltrated, and the email body or attachment content.
- Compliance and Auditing: Providing concrete evidence of what data was detected, which may be required for internal audits or regulatory compliance reports.
- Rule Development: When creating custom DLP dictionaries or regex patterns, seeing the matched content is essential for testing and refinement.
When the Extended Log in security profile should be used:
Enable it in these scenarios, typically for a limited set of high-criticality rules:
- Pilot or Testing Phase: When first deploying a new DLP rule or sensor, enable it to verify it's working as intended and catching the right data.
- High-Severity, Low-Volume Rules: For rules designed to catch the most critical data (e.g., source code, CEO's personal data, specific project codenames, exact customer IDs) where every incident is a serious event requiring full investigation.
- Forensic Investigation: proactively investigating a suspected data leak, temporarily enabling it on relevant rules provides the evidence needed.
- Regulated Data Types: For data covered by strict regulations (e.g., specific medical records, financial account numbers), where the compliance team demands proof of what was detected.
- Custom Dictionary/Regex Rules: Always enable it when tuning a new custom pattern to see what it's actually matching.
- Best Practice: Create a separate, high-severity DLP sensor with Extended Log enabled for most critical rules. Apply this sensor to sensitive user groups or channels (e.g., executives, R&D network, external email).
Where should not Enable Extended Log (or Use with Caution).
When it should be disabled (use default logging) :
- High-Volume, Broad Detection Rules: Rules that match very common data patterns (e.g., a generic "Credit Card" rule on all internet traffic and the "Confidential" keyword on all webmail). Enabling Extended Log here would:
- Severely impacts performance: Logging large amounts of data is CPU and disk I/O intensive.
- Consume massive log storage: The log messages become huge, filling up FortiAnalyzer/FortiGate disk space rapidly.
Create 'noise' that obscures critical events.
- Privacy Concerns: The logs will contain snippets of actual user data (PII, emails, messages). This creates a secondary data repository that itself must be protected, potentially under GDPR, HIPAA, etc. must ensure these logs are secured and access-controlled.
- Default/Baseline Policies: For general DLP monitoring on broad user populations, where looking for trends and major incidents, not granular forensic details.
- Performance-Critical Environments: On very high-throughput interfaces (e.g., data center core), the overhead of extended logging can become noticeable.
Summary: Key Considerations Before Enabling.
| Factor |
Extended Log ENABLED |
Extended Log DISABLED (Default) |
| Log Detail |
Includes matched content snippet. |
Only metadata (rule name, file name, action). |
| Forensic Value |
High (can see what data was detected). |
Low. ( event occurred, but not the exact content). |
| Performance Impact |
Higher (CPU, disk I/O). |
Lower. |
| Log Storage Use |
Significantly higher. |
Efficient. |
| Ideal Use Case |
Critical incidents, rule tuning, and targeted forensic sensors. |
Broad monitoring, high-volume rules, baseline policies |
Practical Recommendation.
- Start Disabled: Deploy most DLP rules with extended logoff.
- Targeted Enablement: Create specific, high-severity rules for 'crown jewel' data assets. Place these rules in a dedicated sensor with Extended Log enabled.
- Use Filters: Apply the sensor with Extended Log to targeted firewall policies (e.g., only for specific users, to specific high-risk destinations like cloud storage or personal webmail).
- Monitor Performance: Keep an eye on FortiAnalyzer storage and FortiGate CPU when Extended Log is active.
- Secure the Logs: Ensure access to these detailed logs is strictly controlled, and the logs themselves are encrypted.
By following this selective approach, the critical forensic gains the benefits ofthe Extended Log where it matters most, without overwhelming the systems or violating privacy norms.
Steps to enable the extended logs on the DLP profile:
config dlp sensor
edit test2
set feature-set proxy
config filter
edit 1
set name filebanned
set severity critical
set proto http-get http-post ssh
set filter-by regexp
set regexp /startrek/i
set action block
next
end
set extended-log enable ----> By default, it is disabled.
set full-archive-proto http-get http-post ssh
next
end
|
