← Back to context

Comment by saalweachter

1 day ago

I think "good security/engineering practices" still has a chance.

Things like--

  * Minimizing attack surfaces by not running lots of software on the same server and not bloating feature sets beyond the minimum 
  * Limiting access so that most things can't be done by most users, there are *no* super-users, and escalating access is temporary ans requires multiple accounts to authorize
  * Encrypting data at rest

All software has flaws and it's now easier than ever to find and exploit them, but this disproportionately hurts people who were only putting on a show of security and relying on a single layer or two of defense instead of developing a robust insider threat model (which helps with both insider threats and threats that get inside) and defense in depth.

Completely agree there is lots you can do to shut down exposed surface area.

Is encrypting data at rest useful when the app must have access to decrypt the data? What sort of scenarios do you use it for and where do the keys live?

Full zero trust internally. Both inbound and outbound proxies (different machines) to carefully limit access, and provide a place to mitigate attacks. Etc.

If your plan is to quickly apply upstream patches, your plan is bad.

  • > Full zero trust internally

    I try so hard for this, but don't even get approval to change an internal site to use https instead of http.

    I get we gotta keep the new features and workflows coming, but a single resource dedicated to low hanging fruit of security could fix a lot in a very short time.