Build security in from the start
Redeploy the infra/cloud/config frequently
Don't allow manual access/change to infra/config/deployments
Assume your code will be used maliciously, so give it minimal permissions
Your front end / public interface / app WILL get hacked. Plan for how you protect the back end data/services once this occurs.
Agree with @david_cheal - build Security from the start and at the core - not as an "add-on".
Generally speaking, look for edge cases. When it comes to security, they are your killer.
@andrey_mi also has an excellent point: if you're happy with what you have in terms of security, then you are vulnerable.
Run regular pen testing.
And add a note in your "Security" website section encouraging security breach hunters - within reasonable / legal limits. It works, and it's quite useful.
Something worth considering. You'll know if you are making some progress with security if you get a lot of complaints from ops and dev staff. Secured platforms are a pain in the ass to work with ;)
Security means no shady bastion/jump boxes. No ssh tunnels to the SQL server, no manual deployments via FTP, no ANY/ANY rules in firewalls from the office IP, no manual config change etc.
Everything has to be designed, configured via code and deployed via CICD. So if you're not getting complaints, odds are its not secure.
I would suggest the following:
- Treat everyone (even yourself) as a potentially harmful person, so strip permissions for every infrastructure possible;
- Log all important actions (sign ins, errors, failed deploys) in an environment (most of them do have it but some might have it disabled by default);
- Do not send credentials in chats/emails/tickets/etc. (duh);
- Set up as much automation as possible to eliminate human error;
- Sharpen your saw with the new techniques;
- If you need someone to help you with the tasks, create a new user with the rights specific for that task (even if that is you);
- do not allow to push directly to master (do a pull request instead);
- do not hardcode credentials in code - usually there is a possibility to use environmental variables (on the server or in the docker container);
* If you have specific questions, happy to chat about that :)
Sorry for the gross advertising here - but we're full OSS so I hope you don't mind too much ;)
Run driftctl to track your infrastructure drift and make sure that your code matches the reality of your cloud resources & check that no permissions or roles were manually changed without you knowing.