A rule of boolean logic that describes how negation distributes across grouped conditions. In query languages, it changes the way combined expressions are evaluated, which can materially alter results when parentheses and not equal operators are used together.
What De Morgan’s Law Means in Boolean Logic
De Morgan’s Law explains how negation changes grouped boolean conditions. A NOT applied to an AND becomes an OR over the negated parts, and a NOT applied to an OR becomes an AND over the negated parts.
This matters because the same logic can be written in different ways while preserving meaning, but only if the grouping and negation are transformed correctly. In security and data work, that distinction affects filters, policy statements, and query results.
Why It Changes Query Results
In practice, De Morgan’s Law becomes visible when a query language evaluates parentheses, exclusion conditions, and compound predicates. A seemingly small rewrite can change which rows, records, or events are returned, especially when mixed with inequality checks, null handling, or operator precedence.
For example, a rule written as NOT (A OR B) does not mean the same thing as NOT A OR NOT B. The first excludes anything matching either condition, while the second admits many cases the original would block.
Common Places It Shows Up
De Morgan’s Law appears in database filters, search queries, policy engines, access-control logic, SIEM queries, and code that evaluates conditions. It is especially important anywhere a practitioner translates business intent into machine-readable boolean expressions.
The law is also useful when simplifying complex expressions for review. Rewriting a condition into a clearer equivalent form can make it easier to test, audit, and reason about, as long as the transformation preserves the original grouping.
Practical Implications for Security and Analysis
Because security logic often relies on exclusions and compound conditions, incorrect application of De Morgan’s Law can create false positives, false negatives, or policy gaps. A detection rule may over-alert if negation is distributed incorrectly, or miss activity if an exclusion is broadened too far.
Careful handling of boolean logic is part of reliable security engineering. When reviewing a query or rule, the safest habit is to verify the transformed expression against the original intent, not just whether it compiles.
Risk and Threat Considerations
Incorrect boolean transformation can silently change the meaning of a security control, query, or policy. In detection and access rules, that can produce coverage gaps, overbroad access, or misleading search results that are hard to notice during routine review.
Failure mechanism: A negated grouped condition is rewritten without preserving the original parentheses or operator scope, so the resulting expression evaluates a different set of records or events.
Impact: Security teams may miss relevant activity, flag the wrong events, or enforce an incorrect allow or deny decision at scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V2 — Validation and Business Logic | Boolean condition handling directly affects application logic correctness and security decisions. |
| Recommendation — Validate complex predicates with test cases to preserve intended business logic under negation. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Correct expression parsing and input handling help prevent logic errors in security-relevant queries. |
| Recommendation — Validate security-relevant inputs and expressions before they drive control decisions. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Query and policy logic are part of application security when they control security outcomes. |
| Recommendation — Review and test logic-bearing application expressions before deployment. | ||
Practitioner Guidance
What to watch for: Treat every rewrite of a compound negated condition as a logic change that needs validation. The safest review is to compare the original and transformed expressions against known test cases, especially when exclusion logic is used in queries, rules, or controls.
Practitioner takeaway: If a boolean expression is safety-critical, test both the intended and transformed forms before relying on it in production.
