[Nea] REQ: Section 4
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Nea] REQ: Section 4
NEA technology may be used for several purposes. One use ...
One use is documented, I can't find others. Maybe re-assesment? But
that's just part of NEA, and not a different purpose. The purpose of
NEA could be stated simply: knowing who is on the network, and knowing
what they are running. (Since remediation is out of scope)
Without NEA technology, ensuring compliance of Endpoints to
corporate policy is a time-consuming and difficult task.
What about normal OS updates, as Bernard pointed out? A toy idea for
implementing NEA would be an software integrated with a client-side
firewall that downloaded software updates every time the system
connected to a network.
I understand that much of the on-list discussion happened while the
authors were busy writing the requirements document, but the points
raised are serious enough to warrant a response from the authors. Is
there *ever* a need in NEA for anything other than "get me all of the
latest updates"? Why would a system *ever* ask for less than all of the
updates? At most, I could see the updates being version dependent
(updates for OS v1.2.3 versus OS v2.3.4). But once that information is
propagated to the machine sourcing the updates, the next step is *still*
"download all updates".
... With NEA technology, the network is
able to assess an Endpoint as soon as it requests access to
the network or at any time after joining the network
So we're assuming that the network will control what software is
running on the endpoint, but won't keep track of that information? Why
bother asking the Endpoint what it has, when the network could simply
consult it's database, and say "machine X isn't up to date", and then go
tell it "download all of the latest updates".
The assessment SHOULD NOT include querying. I have not seen a
scenario where querying of endpoints is useful. In fact, querying is
extremely inefficient, compared to simply telling the endpoint "download
all updates".
Of course, the net result of that design is that most of the
complexity of NEA gets pushed into the remediation network, but that's
not necessarily a bad thing.
... This
provides the corporation an opportunity to monitor compliance
I don't understand "monitor compliance". If a machine does NEA when
it connects, it is compliant. If later changes mean a connected machine
is no longer compliant to the new policy, the network MUST know, or MUST
have a way to tell the machines to become compliant. "monitoring
compliance" to me seems to indicate pro-active querying of machines, as
in "are you still compliant?". Such querying is inefficient and
unnecessary.
The decision of how to handle non-compliant Endpoints can be
made by the network administrator ...
s/can/MUST/, or s/can/can only/
... For example, re-assessment
may be triggered by a NEA Client if a User disables a security
application such as a host firewall on the Endpoint.
I don't understand that. If the network policy says he MUST run a
firewall, disabling the firewall MUST result in being kicked off of the
network. I don't see why re-assessment is necessary: the user has
declared he is no longer in compliance.
... Re-
assessment also assists in keeping Endpoints connected to the
network up to date with fixes and patches published by
security application vendors.
As opposed to simple downloads of the updates? It's a lot easier for
many endpoints to periodically query a server, than it is for a server
to poll many endpoints.
Performing re-assessment to me indicates that NEA won't scale.
... Another use of NEA technology
may be to supplement information in inventory databases.
Is this a charter goal? If not, why are we discussing it? NEA *may*
result in additional information being available to the network admin,
but the maintenance and use of that information is out of scope of NEA.
... In
organizations that attempt to keep track of their assets,
inventory databases tend to be incomplete and out-of-date.
NEA technology may be used to verify or supplement information
stored about an organization's assets.
I suggest deleting that text entirely.
... NEA
technology can also be used to monitor and report compliance
for Endpoints when they try to access certain mission critical
applications within an enterprise by employing application
triggered Assessment.
Why? The endpoint knows what posture it satisfies, and the network
admin knows the same thing if he caches the posture assessment from the
initial network access. If the application knows what posture it
requires, why ask the potentially compromised host, when can instead ask
a trusted source: the network admin? This approach could also catch the
case of lying endpoints. If the network determines that an endpoint is
lying (i.e. by observing network traffic), it can update it's view of
the endpoints posture, and inform others on the network that the device
is not to be trusted.
Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.