[dns-operations] 10% was Re: .mm ....

[Edward Lewis]

On Jan 18, 2013, at 12:18, Dobbins, Roland wrote:

> 
> On Jan 18, 2013, at 11:05 AM, Edward Lewis wrote:
> 
>> Adding security to an existing system will, inherently, make it more brittle. 
> 
> I strongly disagree with this statement.  Increasing resilience under duress should be a key goal of any security enhancement; if it doesn't do this, then it hasn't been designed/implemented properly.

(Perhaps the second half of the message should be first...meaning I think the issue is in what I meant by "adding".)

This was the proof offered to me (about the impact of bolting-on/retrofitting - as I meant "adding") years back:

Take an existing (vulnerable) system and model it as a state machine.  States can be classified as "safe", "perilous", and "unsafe."  Perilous states are those which are safe but have an arc into an unsafe state.

The act of "adding" security on to the system has the effect or preventing the system from entering unsafe states and perilous states, in the effort to prevent falling into unsafe states.

What is lost then, is any transition from a "safe" to "perilous" to "safe" states which per se is not a problem but is no longer permitted.  This is the brittleness I refer to.

Looking back on this proof - I suppose if there were no safe-perilous-safe state transitions, there's no increase in brittleness.  KInd of a degenerate case in the proof.

>> So trimming failed validations by removing brittleness is a good place to start.
> 
> I agree with this statement, and most everything else you say, 100%.  Perhaps 'adding security' wasn't really what you meant in the first sentence?

"Adding security" maybe the trip up.  Maybe I should have used the term I normally use "bolted-on security."  When I wrote "adding" I had in mind the kind of addition like DNSSEC on DNS - which is a case of "bolted-on" security.  It was a discussion over that where I was given the above proof.

"Adding security" as an ingredient in the initial architecting of a solution won't make the system more brittle.  (Well, if the solution is "new" - it can't be "more" anything. ;) )

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130118/62b9f591/attachment.html>