Beyond Monotonicity: The Importance of "Delete" and "Destroy" in Cybersecurity
Cybersecurity due to its non-stationary and non-ergodic nature requires a periodic re-evaluation of foundational assumptions. One such assumption is monotonicity, which posits that once privileges are granted, they cannot be revoked.
1. The Monotonicity Fallacy: A Theoretical Oversight
In 1976, Harrison, Ruzzo, and Ullman (HRU) introduced the access matrix model, establishing a framework for analyzing system safety. Their proof relied on the assumption of monotonicity, simplifying safety analysis but neglecting the dynamic nature of access control.
Flaw Identification:
Tripunitara and Li (2013) revisited HRU's work, revealing that excluding "delete" and "destroy" operations—actions that revoke privileges—results in flawed safety conclusions. They demonstrated that a system could transition from a secure state to one where privileges are re-granted, leading to unauthorized access, which would be incorrectly classified as "safe" under the monotonicity assumption.
2. Practical Implications: JPL C Coding Standards
The Jet Propulsion Laboratory (JPL) has established stringent C coding standards to enhance software safety. These standards implicitly advocate for a non-monotonic security approach, particularly concerning memory management:
- Dynamic Memory Risks: The
delete[]operator can lead to dangling pointers and use-after-free vulnerabilities, creating exploitable security gaps. - Recommended Practices: JPL guidelines promote static memory allocation, custom memory pools, and garbage collection to mitigate these risks.
These practices reflect an understanding that software systems are dynamic, necessitating careful control over state changes to prevent vulnerabilities.
3. Traditional Attack Graphs: A Monotonicity Oversight
Attack graphs visualize potential attack paths but often fall victim to the monotonicity fallacy.
Standard attack graphs typically emphasize privilege escalation while neglecting Privilege Revocation (actions that remove previously gained privileges, such as patching vulnerabilities), Vulnerability Patching (ongoing remediation efforts that render prior exploits ineffective) and System Remediation (restoring systems to secure states post-attack.
4. Case Study: AWS S3 Bucket Access Control
Amazon S3's complexity in access control exemplifies these challenges. Misconfigured S3 buckets have led to numerous data breaches, highlighting:
- Scale and Complexity: Managing access in cloud environments is inherently challenging.
- Shared Responsibility: Security is a joint effort between AWS and its customers, with human error being a significant vulnerability source.
Tools like Amazon's Zelkova, an SMT solver, can formally verify access control policies, accounting for dynamic permission changes and identifying vulnerabilities.
5. Real-World Case Study: SolarWinds
The 2020 SolarWinds attack serves as a compelling real-world example of the necessity for non-monotonic security principles. In this incident, attackers exploited a vulnerability in a widely-used software management tool to gain access to numerous government and private organizations. They maintained persistence by leveraging "zombie accounts," highlighting the risks associated with the assumption that privileges are permanent.
6. CMMC 2.0: Non-Monotonicity in Practice
The Cybersecurity Maturity Model Certification (CMMC) framework addresses non-monotonic security controls:
- AC.2.007: Account Management: Mandates controlling the creation, modification, disabling, and removal of user accounts, addressing the "destroy" operation.
- AC.2.014: Permissions and Authorizations: Requires processes for granting, modifying, and revoking access permissions, emphasizing the dynamic nature of permissions.
CMMC 1.0 lacked these specific requirements, but CMMC 2.0 reflects an evolved understanding of non-monotonic security.
References
[1] CMMC Accreditation Body. (n.d.). Cybersecurity Maturity Model Certification (CMMC). Retrieved from https://www.cmmc-ab.org/
[2] Gartner. (2020). Top Security and Risk Management Trends. Retrieved from https://www.gartner.com/en/newsroom/press-releases/2020-01-14-gartner-identifies-top-security-and-risk-management-trends-for-2020
[3] Harrison, M. A., Ruzzo, W. L., & Ullman, J. D. (1976). Protection in operating systems. Communications of the ACM, 19(8), 461-471.
[4] Tripunitara, M. V., & Li, N. (2013). The foundational work of Harrison-Ruzzo-Ullman revisited. IEEE Transactions on Dependable and Secure Computing, 11(1), 54-63.
[5] Feyzabadi, M. S., & Foster, J. S. (2019, May). Zelkova: A SMT-Based Analyzer for AWS IAM Policies. In 2019 IEEE Symposium on Security and Privacy (SP) (pp. 514-531). IEEE.
[6] JPL Institutional Coding Standard for the C Programming Language. (2015). Retrieved from https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
[7] CyberSheath. (2024). Cybersecurity Report 2024. Retrieved from https://pdflink.to/CyberSheath-Merrill-Report-2024/
postscriptum
The October 2024 CyberSheath report reveals a concerning disconnect between perceived and actual cybersecurity readiness within the Defense Industrial Base (DIB). While many US DoD contractors believe they are compliant, their low average SPRS scores (with 76% of DIB contractors surveyed believing they were compliant despite an average SPRS score of dismal -12 out of 110) and inadequate implementation of key DFARS requirements paint a different picture. This highlights a critical need for improved understanding of CMMC 2.0, particularly its emphasis on dynamic security practices like account removal and permission revocation.