wrt "Network Endpoint Assessment" (was: Re: Free Rootkit with Every New Intel Machine)

[Jeff.Hodges at KingsMountain.com]

of potential related interest is..

Network Endpoint Assessment (NEA): Overview and Requirements         
<http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt>

note term "remediate/remediation".

relevant snippage below. see also..

http://www.ietf.org/html.charters/nea-charter.html


=JeffH

<snip/>

1. Introduction 
    
    Today, most network providers can leverage existing standards-
    based technologies to restrict access to their network based 
    upon criteria such as the requesting system's user or host-based 
    identity, source IP address or physical access point.  However 
    these approaches still leave the network resident systems 
    vulnerable to malware-based attack, when an authorized but 
    infected system is admitted and the malware is able to spread 
    throughout the internal network. 
     
    As a result, network operators need a proactive mechanism to 
    assess the state of systems joining or present on the network to 
    determine their status relative to network compliance policies.  
    For example, if a system is determined to be out of compliance 
    because it is lacking proper defensive mechanisms such as 
    firewalls, anti-virus software or the absence of critical 
    security patches, there needs to be a way to safely repair 
    (remediate) the system so that it can be subsequently trusted to 
    join and operate on the network.  The NEA technology strives to 
    provide a mechanism to report the configuration of an endpoint 
    for evaluation against network compliance policy.  Such a 
    mechanism could offer a useful tool for the network operators'
    arsenal but should be recognized as not being a complete 
    endpoint compliance solution in and of itself.  
     
    NEA typically involves the use of special client software 
    running on the requesting system that observes and reports on 
    the configuration of the system to the network infrastructure.  
    The infrastructure has corresponding validation software that is 
    capable of comparing the system configuration information with 
    network compliance policy and providing the result to 
    appropriate authorization entities that make decisions about 
    network and application access.  Some systems may be incapable 
    of running the NEA client software (e.g. printer) or be 
    unwilling to share information about its configuration.  In 
    these cases the network infrastructure might decide to disallow 
    or limit access to the network. 
     
    In many cases, the admission decision is provisioned to the 
    enforcement mechanisms on the network and/or system requesting 
    access.  The decision might allow for no access, limited or 
    quarantined access (possibly to allow for remediation), or full 
    access to the network.  While the NEA Working Group recognizes 
    there is a link between an assessment and the enforcement of the 
    assessment decision, the mechanisms and protocols for 
    enforcement are not in scope for this specification. 
     
    Architectures, similar to NEA, have existed in the industry for 
    some time and are present in shipping products, but do not offer 
    interoperability.  Some examples of such architectures include: 
    Trusted Computing Group's Trusted Network Connect [TNC], 
    Microsoft's Network Access Protection [NAP], Cisco's Network 
    Admission Control [CNAC]).  These technologies assess the 
    software or hardware configuration of endpoint devices for the 
    purposes of monitoring or enforcing compliance to an 
    organization's policy.  These architectures are not 
    interoperable because they are implemented using primarily non-
    standards based technologies. 
     
    The NEA working group is working on defining standard protocols 
    so as to enable interoperability between devices from different 
    vendors allowing network owners to deploy truly heterogeneous 
    solutions. This document describes the requirements for NEA 
    candidate technologies and protocols.  
 
<snip/>

 4. Problem Statement 
 
    NEA technology may be used for several purposes.  One use is to 
    facilitate endpoint compliance checking against an 
    organization's security policy when an endpoint connects to the 
    network.  Organizations often require endpoints to run an IT-
    specified OS configuration and have certain security 
    applications enabled, e.g. anti-virus software, host intrusion 
    detection/prevention systems, personal firewalls, and patch 
    management software.  An endpoint that is not compliant with IT 
    policy may be vulnerable to a number of known threats that might 
    exist on the network. 
     
    Without NEA technology, ensuring compliance of endpoints to 
    corporate policy is a time-consuming and difficult task.  Not 
    all endpoints are managed by a corporation's IT organization, 
    e.g. lab assets and guest machines.  Even for assets that are 
    managed, they may not receive updates in a timely fashion 
    because they are not permanently attached to the corporate 
    network, e.g. laptops.  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.  This provides 
    the corporation an opportunity to check compliance of all NEA-
    capable endpoints in a timely fashion and facilitate endpoint 
    remediation potentially while quarantined where needed.  
    Endpoint that are not NEA-capable or choose not to share 
    sufficient posture to evaluate compliance may be subject to 
    different access policies. 
     
    The decision of how to handle non-compliant or non-participating 
    endpoints can be made by the network administrator possibly 
    based on information from other security mechanisms on the 
    network (e.g. authentication).  For example, remediation 
    instructions or warnings may be sent to the non-compliant 
    endpoint with a properly authorized user while allowing limited 
    access to the network.  Also, network access technologies can 
    use the NEA results to restrict or deny access to an endpoint, 
    while allowing vulnerabilities to be addressed before an 
    endpoint is exposed to attack.  The communication and 
    representation of NEA assessment results to network access 
    technologies on the network is out-of-scope for this document.  
     
    Re-assessment is an important part of NEA technology as it 
    allows for additional assessments of previously considered 
    compliant endpoints to be performed.  This might become 
    necessary because network compliance policies and/or endpoint 
    posture can change over time.  A system initially assessed as 
    being compliant when it joined the network may no longer be in 
    compliance after changes occur.  For example, re-assessment 
    might be necessary if a user disables a security protection 
    (e.g. host firewall) required by policy or when the firewall 
    becomes non-compliant after a firewall patch is issued and 
    network policy is changed to require the patch.  
      
    Another use of NEA technology may be to verify or supplement 
    organization asset information stored in inventory databases.   
     
    NEA technology can be used to provide posture assessment for a 
    range of ways of connecting to the network including (but not 
    limited to) wired and wireless LAN access, remote access via 
    IPsec[IPSEC] or SSL[TLS] VPN, or gateway access.   NEA 
    technology can also be used to check and report compliance for 
    endpoints when they try to access certain mission critical 
    applications within an enterprise by employing service 
    (application) triggered assessment.  

<snip/>

---
end

     

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com