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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf