ietf
[Top] [All Lists]

RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)

2006-10-11 14:08:13
Hello Ted

Comments inline as appropriate.

Ted Hardie wrote:
At 7:55 PM +1000 10/11/06, Darryl \(Dassa\) Lynch wrote:
I run a very closed network, ports are closed and not opened unless
there is a validated request, external drives are disabled etc etc.
A contractor comes in with a notebook and needs to work on some
files located on our internal secure network.  A trusted staff
member rings in with the request to open a specified port.  The
port is opened and the contractor hooks up the laptop to it.  NEA
does it's thing and if the laptop doesn't match the requirements of
the internal network policy it is directed to a sandbox network for
remediation. 

One of the points that has been made here several times is
that the rosy promise of a sandbox for remediation has a
number of thorns, even in the case where a posture
assessment method has identified a potential issue. As it
stands, there are commonly multiple ways to work around a
vulnerability, including base-levels upgrades (from OS Foo
v3 to v4) specific patches (either to the OS or to the
application), and, in some cases, configurations (turning off
functionality BAR). Assessing those is difficult; offering
remediation is trickier yet, especially when one or more of the
systems which may need remediation may not even been active at the
time of attachment. As I have expressed before, I have serious
doubts that the standardized parameters will be sufficient to do any
reasonable assessment, and the same carries through in
spades for remediation, since that involves a check that
none of the remediations has already been applied.

Very true, any remediation is difficult.  It may be there will be options
provided so once a system fails to meet NEA compliance they are offered a
number of options instead of remediation, perhaps limited access, no access
or intervention by IT staff, all this is beyond the scope of NEA at this
stage IMHO.

Maintaining a valid, *current* set of patches, OS upgrades,
and the like for remediation is going to be a very big task;
managing the licensing on it a nasty problem; and handling
the potential liability of applying the *wrong* remediation
a nightmare.  Handling unknown states (even for those
running recognized assessors) is an even more problematic
issue, but you may not care that some folks run development
drops of OSes and applications, since you can always
remediate them by offering a downgrade.

What is the difference to maintaining the network nodes already on the
system.  They all have to be maintained and kept in compliance already.  NEA
just provides some information on what may be needed.

In your example, the contractor presumably also agrees to
your mucking with their laptop configuration as part of the
contract, but the number of cases in which this is going to
be wise is clearly a subset of all cases and it may be a
tiny subset.  If I came into your network and offered to
work with you, my corporate IT folks would be upset if I
allowed you to do any of the updates discussed above, so the
sandbox is effectively a denial of network access.
That's a policy decision you are welcome to make (it's your
network), but it's a complex and risky way to make it.

If they don't agree to the network policy then alternatives would need to be
available such as providing a trusted system for them to use.  Hackers and
theives wouldn't agree to abide by any policy in place but that doesn't mean
I have to provide methods to make their life easier :).

I continue to think that the core of this work (passing an
opaque string prior to attachment) has some benefits

I don't disagree.

<snip>

Just another tool to give network administrators information and
systems they can use to ensure the majority of users get their
requirements met in a reasonable and timely manner.

And I believe others agree with your "tool in the toolkit"
view.  But if you advertise a saw as a hammer, someone is going to
get cut. 

Most accidents occur in the home.  People do have to take some
responsibility for themselves.

Darryl (Dassa) Lynch 


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf