[conspire] Servers and security

[Mark Weisler]

> On Mar 29, 2018, at 9:21 AM, Carl Myers <cmyers at cmyers.org> wrote:
> 
> It depends so much on your threat model and what you are trying to accomplish...
> this is my biggest pet peve about security.  People do things because some
> website or resource says "this is secure" but they have no clue why.  If you
> want to secure something, the first thing you have to do is figure out what you
> are securing it AGAINST.  Guess what?  You can have 100% foolproof unhackable
> security for your server, just disconnect it from the internet, turn it off,
> bury it in a deep grave in a field somewhere where nobody will ever find it.
> But that isn't very helpful is it?
> 
> A threat model outlines what threats you care about, and what threats you don't.
> For example, let's say I deem it possible someone has a way to use a bug in
> apache tomcat (the application server my service uses in this example) to
> execute remote code, how would I deal with that?  Well, I could have the
> application server run as an unprivileged user and harden things further with
> SELinux and other techniques to try to minimize the damage such a user can do.
> What if someone is capable of breaking encryption (P = NP)?  I consider that
> highly unlikely, and if someone could do that the security of my application is
> my last concern (oh no, my bitcoin!)
> 
> So the first step to security, IMO, is to decide what class of attackers you
               ^^^^^^^^^^.  The way I was taught is that the first step is to estimate the value of what it is you are trying to protect. That way, you invest in security in proportion to the value of what is at risk. So, one might invest less in security to protect a LAN file server containing recent newspaper photos than one would use to protect a bank wire transfer server.

I realize the thread was started as a learning vehicle so it might be useful to consider security as a spectrum of possibilities ranging from basic prudent practice up to extreme hardening (with probably a decrease in ease of use and access).


> care about, what they are capable of, and then how to best mitigate those
> attacks.

--
Mark Weisler
PGP Key ID 0x9E358F7B
PGP Key fingerprint  5969 3C77 AB25 B398 9E84  3FB5 0C30 D913 9E35 8F7B

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20180329/a34527fe/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20180329/a34527fe/attachment.pgp>