The Banno group deals with a lot of sensitive information. As we process customer information for financial institutions, we must ensure that the code we write is secure and that we’re keeping our users’ data from being compromised.
Credentials must be stored in secure databases
In order to access and send user account information, we usually need some form of user credentials. These must always be stored in Vault and sent encrypted across the wire. This means no credentials of any kind are stored directly in code, on github, in gists, etc.
Default to denial
For any given functionality, your default case should be denying a request. This means that a request must have proper authentication to execute, and we never assume that a user has been validated elsewhere. This includes preferring whitelists to blacklists.
Validate input
We sometimes need to communicate with untrusted, third party sources. As such, we must validate all input before executing any requests using that input.
Principle of least privilege
Every process should execute with the least set of privileges necessary to complete the job. Any elevated permission should be held for a minimal time.
Use the simplest designs possible
Minimize the chance for error and holes in your code by using the simplest design that will meet your needs.
Fail securely
Failure will happen. Ensure that when we fail, we handle it gracefully and do not offer up sensitive information.
Log inconsistencies
If your system sees anything unexpected, ensure that a record is kept to allow later identification of vulnerabilities.
Log securely
Your system’s log messages should be kept free of sensitive information, in particular PII (Personally Identifiable Information). For more details, see JHA’s Information Classification Policy, available in the Policy Center.
Defense in depth
Do not trust another layer to handle security. Ensure that if one layer of security is compromised, the next layer will catch it.