Re: Network security manager

[Ted Zlatanov]

On Tue, 18 Nov 2014 17:15:09 +0100 Lars Magne Ingebrigtsen <address@hidden> 
wrote: 

LMI> Ted Zlatanov <address@hidden> writes:
LMI> Sure...  but since there's almost nothing human-readable (or something a
LMI> machine can transform into something human-readable), I'm not quite sure
LMI> what it should display...
>> 
>> The list of explicitly saved security exceptions.

LMI> But they are per sha1, so it's not really feasible to do anything about
LMI> it for a human.

That's how you implemented it.  It's not necessarily how it should be.

>> True, but I really don't see the harm in saving those in cleartext.

LMI> I don't like the information leakage.

Then the NSM is really a blob storage manager.

>> Like I said, I would use a .gpg file if I was worried about leaking
>> that data. With the current approach I think you'll see two problems:

LMI> GPG isn't feasible because nobody wants to type passwords.

Whuhh?

>> 1) cruft will accumulate, since you don't know what's what

LMI> Does it matter?

Yes!  Regular reviews are essential to actually managing security
exceptions.

>> 2) when servers change names or ports, you don't know what to remove

LMI> You don't have to remove anything.  No manual administration should be
LMI> necessary.  Unless you want to revoke a security exception.  And then
LMI> you might as well just delete the entire file.  It's not like it's a lot
LMI> of bother hitting the `a' key a couple times the next time you start
LMI> up...

Yes, it's a bother.  We're talking about potentially dozens or hundreds
of exceptions in a large enterprise.  But let's assume the `a' key is
large and easy to hit.

Scenario 1: you allow a compromised server accidentally.  You now can't
review the exception list to remove that compromise.

Scenario 2: someone allows a compromised server on purpose in a few
seconds.  You have no idea it happened.

I'm sure there are other scenarios, but please don't make this a
write-only data store.

Ted