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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf