I have been studying all I can about Software Development Security. There seems to be a principal that appears obvious to me, but it is left out of any of the literature I have seen.
This principle is related to the principles of Least Privilege, Least Common Mechanism, and Never Assuming that Your Secrets Are Safe. (For descriptions of the principles see: https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles.html ). This principle I would like to call Use Least Required Data.
The idea is simple. Limit the amount of data an attacker can obtain without a complete compromise to the data store of your system. As such you should only request the data from the data store that is necessary to respond to the user input.
Each level of the application might have different requirements to meet this need.
An abstract example:
- On the data store (database) level you might have different views set up so that confidential information is hidden from the database user that the application connects as.
- On the data access layer you don't use generic selects (e.g. select * from table) but use specific selects that return only the data needed to process the request from the end user.
- On the business rules layer you only copy the information you need from the data access layer to process the request.
- On the display layer you only show what is needed to show.
A concrete example of an n-tier web application.
For the purposes of this example, the payment processor (the process that takes payment information and sends it to the bank for processing) is separate from the web application and is instantiated through a trigger in the database itself. The web server also does not connect to the database directly, but through a proxy server that exposes a limited number of functions. The request this example is responding to is in the middle of the checkout process of the shopping cart where stored credit card info is displayed to the user.
- The database has some views set up so that the proxy server can only read from those views . Stored credit card numbers are not shown in the view, only the last four digits of the credit card number (the obfuscated number).
- The proxy server reads from the view the obfuscated credit card numbers based on the expiration date not being past.
- The web server does not need to process the credit card list, it can just request the data needed to build the webpage.
- The web page displays only what is needed for the user to make a decision.
In the concrete example there is no reason at all for the stored credit card number to be sent to the browser, to the web server, or to the proxy server. The payment processor reads the stored credit card info directly from the database and sends it to the bank for processing, so the view did not need it. The view needed to contain the expiration date so that the proxy could select non-expired cards. However the proxy did not need to read the expiration dates because they are not displayed to the user. The web server did not need to do any processing of the credit card data so it just requests what the web page needs to display.
In this concrete example if the web server is compromised, no credit card information can be gleaned from watching legitimate transactions. Even if the proxy server is compromised, no credit card information can be obtained. Only a full compromise of the database can get credit card information.
Many current mitigation techniques like using views, etc. fall under this principle. However, as far as I can determine these techniques were conceived of without an encompassing guiding principle. I submit the principle of Use Least Required Data as a guiding principle for secure software development.
I consider "Confidentiality" a pillar of Software Development Security. Pillars are general classes of ideas that are not measurable, where "Use Least Required Data" is an actionable, measurable principal that falls under the pillar of "Confidentiality".