INTERNET-DRAFT R. Housley Intended Status: Informational Vigil Securiy Expires: January 12, 2014 S. Turner IECA July 11, 2013 sacm: Alternate Architecture draft-handt-sacm-alternate-architecture-00 Abstract This document proposes and alternate architecture for sacm (a proposed working group at the time this draft was submitted). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Housley & Turner Expires January 12, 2014 [Page 1] INTERNET-DRAFT sacm: Architecture July 11, 2013 1. Introduction [ID.waltermire-sacm-architecture] proposed an architecture for sacm. This draft proposes an alternate architecture. 2. Initial Architecture The initial proposed architecture is copied here for those to lazy to go read the other draft. +-------------+ +--------------+ | | | | | Evaluator |<---DF1--->| Content |<---DF1---------+ | | | Repository | | +-------------+ | | | ^ ^ +--------------+ | | | ^ | | | | | | | DF1 | | | | | | | V V | | +--------------+ +----------+ | | | | | | | +-------DF2--->| Controller |<---DF2--->| Sensor | | | | | | | +--------------+ +----------+ | | | | | | | DF3 | | | | | V | | +-----------+ | | | | | +--------------DF4---->| Data |<-----DF3-alt-----+ | Storage | | | +-----------+ Figure 1 - Proposed sacm Architecture The primary issue with the proposed architecture is its abstraction. For those not in the know, it makes more sense to propose an architecture in terms of actual boxes and protocols that flow as opposed to a functional architecture. Housley & Turner Expires January 12, 2014 [Page 2] INTERNET-DRAFT sacm: Architecture July 11, 2013 3. Alternate Architecture In the following figure: o BPD is a Border Protection Device (BPD), which is a firewall and IDS (Intrusion Detection System) all rolled in to one. o Asset is either a host or a client. o Evaluator determines whether the asset is allowed access to the network. enterprise network | wild, | wild west +-------+ +-----+ | +->| asset |<-----+ +----->| BPD |<-|-> | +-------+ | | +-----+ | | | | ^ | | | +----------|---------+ | | | | | | | +-------+ | B | | +-----+ | +->| asset |<-----+---------------------+----->| BPD |<-|-> | +-------+ | | | +-----+ | | | | | ^ | | | +----------|---------+ | | | | | | | +-------+ | | | +-----+ | +->| asset |<-----+ | +----->| BPD |<-|-> | +-------+ | +-----+ | | C | ^ | | +--------------------+ | | | | | V | | A +-----------+ +------------+ | +-------------------->| Evaluator |<-->| Repository | | +-----------+ +------------+ | | Figure 2 - Alternate sacm Architecture Lines marked A, flowing from the asset to the Evaluator, are NEA- based protocols. The asset has a NEA client that performs posture collection, posture brokering, and posture exchange with the Evaluator. The evaluator has a NEA server that evaluates the posture, posture brokering, and posture exchange with the asset. It must be noted that the NEA client can have more than one collector (e.g., one to collect OS information, one to collect IP information, one to collect application information) and the NEA server can have Housley & Turner Expires January 12, 2014 [Page 3] INTERNET-DRAFT sacm: Architecture July 11, 2013 more than one evaluator. The initial posture assessment is best done before the asset has access to the network. [ID.draft-ietf-nea-pt-eap] provides one such solution. After network access has been granted, posture should continue to be maintained [RFC6876] provides on such solution to convey updated posture attributes. Lines marked B, flowing from the client to the BPD are network traffic that occur after initial network access has been granted. The BPDs provide a backstop to ensure that assets are acting appropriately (e.g., a client is acting as a client and not a host). These protocols are not in sacm's scope. Lines marked C, flowing from the BPD to the (Evaluator or Repository?) ensure that the BPDs know how the asset are supposed to be acting. [Question: Do BPDs interact with the database or the evaluator?] [Question: Do BPDs need to talk to each other so that clients cannot choose multiple egress points to hide their activity.] [Question: How do external enterprises interact with this enterprise] 4. Security Considerations By identifying the components and where those functions reside this alternative architecture makes it easier to understand the required protocol flows. 5. IANA Considerations There are no IANA considerations present in this document. 6. References 6.1 Normative References Nada 6.2 Informative References [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture Transport Protocol over TLS (PT-TLS)", RFC 6876, February 2013. Housley & Turner Expires January 12, 2014 [Page 4] INTERNET-DRAFT sacm: Architecture July 11, 2013 [ID.waltermire-sacm-architecture] D. Waltermire, "Security Automation and Continuous Monitoring (SACM) Architecture", draft- waltermire-sacm-architecture, work-in-progress. [ID.draft-ietf-nea-pt-eap] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods", draft-ietf-nea-pt-eap, work-in-progress. Authors' Addresses Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA Email: : housley@vigilsec.com Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA Email: turners@ieca.com Housley & Turner Expires January 12, 2014 [Page 5]