On Monday, January 25, 2016 11:56:19 AM Warren Young wrote:
On Jan 25, 2016, at 11:04 AM, Benjamin Smith lists@benjamindsmith.com
wrote:
We have a prospective client who is asking us what our policy is in the event of unauthorized access.
Tell them you use the Mr. Miyagi defense: “Don’t get hit.”
Your prospective client sounds like they’re expecting someone to have established procedures to deal with breaches. You know who has established procedures? Organizations that see the same problems again and again.
Selecting an information service provider based on which one is best at recovering from a hack attack is like hiring a football coach based on how skilled he is at setting bones or selecting a cargo ship captain based on how good he is at patching hull breaches.
Why is “We’ve been at this for 20 years and have never *had* to clean up after a hacking incident” not an excellent rejoinder?
Agreed! (although for us it has been 15 years.
what steps do you take to mitigate the effects of a breach? What is industry best practice?
You should not have to ask this. You should know it, because you are a professional and have been in this industry long enough.
Since you don’t, maybe you shouldn’t be bidding on this job.
I don’t mean to make this sound cabalistic, where only insiders know the secret handshakes, but rather exactly the opposite: this is information you should have been slowly absorbing for years:
- SSH instead of telnet and FTP
- HTTPS wherever possible over HTTP
- Always enable SELinux
- Prefer to surf default SELinux policies rather than override or
custom-craft - Know in your heart that deny-by-default firewalls are a good thing - Turn off unnecessary services…
- …then run “netstat -na | grep LISTEN” and justify each output line
- Understand chown and chmod effects implicitly
- Be able to read ls -l output at a blink
And much more.
Which I'd consider "best practices" and we do them. They are specifically asking about what to do *after* a breach. Despite all the best practices in place, there's *still* some risk.