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

From: Ted Hardie <[email-masked]>
Date: Wed, 11 Oct 2006 10:06:05 -0700

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.

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.

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.

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

<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.

				regards,
					Ted

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "Darryl \(Dassa\) Lynch" <[email-masked]>
Date: Thu, 12 Oct 2006 07:04:59 +1000

Hello Ted

Comments inline as appropriate.

Ted Hardie 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