Database Security Request for Proposal
Defending both Internal and Public Facing Databases against Known Vulnerabilities
How could a vulnerability that has been known and understood since 1998 still be included in the Top 10 list of vulnerabilities from the Open Web Application Security Project (OWASP) from 2010 to 2017? The issues are well known and understood, as are the mitigation and fix actions to harden database vulnerabilities. Database vulnerabilities remain persistent because of the proliferation of databases in many aspects of data storage and web applications, where the perceived value of the information in the database is high and the attack mechanism is easy. There are actually several database vulnerabilities, depending on the database employment, which expands the targets and, thus, the vulnerabilities. Individual databases holding organizational data have vulnerabilities, as do web application databases— with web application SQL injection being the most well-known vulnerability. The different database vulnerabilities and attacks can be analyzed through the differentiation between information security and cybersecurity vulnerabilities to better understand the taxonomy and operational semantics for targeted mitigation. The root cause of database vulnerabilities remains poor design and coding. Ultimately, there are multiple SQL injection attack detection methodologies being researched, but prevention through proper design and coding is the best defense. Thus, while a defense in depth is required, when implementing a database solution one of the most important aspects is creating and implementing a robust functional database vulnerability test plan within the request for proposal to ensure that the root cause is mitigated.
Copyright (c) 2019 Thomas Arthur Talmadge
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
All content on this site is copyright by Americas Institute for Cybersecurity Leadership (AICL). Authors retain ownership of submitted content, but AICL may redistribute or create derivative works with expressed consent from the author as part of the submission criteria.