idnits 2.17.1 draft-handt-sacm-alternate-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3936 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Housley 3 Intended Status: Informational Vigil Securiy 4 Expires: January 16, 2014 S. Turner 5 IECA 6 July 15, 2013 8 sacm: Alternate Architecture 9 draft-handt-sacm-alternate-architecture-01 11 Abstract 13 This document proposes and alternate architecture for sacm (a 14 proposed working group at the time this draft was submitted). 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 Copyright and License Notice 33 Copyright (c) 2013 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 1. Introduction 48 [ID.waltermire-sacm-architecture] proposed an architecture for sacm. 49 This draft proposes an alternate architecture. 51 2. Initial Architecture 53 The initial proposed architecture is copied here for convenience: 55 +-------------+ +--------------+ 56 | | | | 57 | Evaluator |<---DF1--->| Content |<---DF1---------+ 58 | | | Repository | | 59 +-------------+ | | | 60 ^ ^ +--------------+ | 61 | | ^ | 62 | | | | 63 | | DF1 | 64 | | | | 65 | | V V 66 | | +--------------+ +----------+ 67 | | | | | | 68 | +-------DF2--->| Controller |<---DF2--->| Sensor | 69 | | | | | 70 | +--------------+ +----------+ 71 | | | 72 | | | 73 | DF3 | 74 | | | 75 | V | 76 | +-----------+ | 77 | | | | 78 +--------------DF4---->| Data |<-----DF3-alt-----+ 79 | Storage | 80 | | 81 +-----------+ 83 Figure 1 - Proposed sacm Architecture 85 The primary issue with the proposed architecture is its abstraction. 86 For those not in the know, it makes more sense to propose an 87 architecture in terms of actual boxes and protocols that flow as 88 opposed to a functional architecture. 90 3. Alternate Architecture 92 In the following figure: 94 o BPD is a Border Protection Device (BPD), which is a firewall and 95 IDS (Intrusion Detection System) all rolled in to one. 97 o Asset is either a host or a client. 99 o Evaluator determines whether the asset is allowed access to the 100 network. 102 enterprise network | wild, 103 | wild west 104 +-------+ +-----+ | 105 +->| asset |<-----+ +----->| BPD |<-|-> 106 | +-------+ | | +-----+ | 107 | | | ^ | 108 | | +----------|---------+ | 109 | | | | | 110 | +-------+ | B | | +-----+ | 111 +->| asset |<-----+---------------------+----->| BPD |<-|-> 112 | +-------+ | | | +-----+ | 113 | | | | ^ | 114 | | +----------|---------+ | 115 | | | | | 116 | +-------+ | | | +-----+ | 117 +->| asset |<-----+ | +----->| BPD |<-|-> 118 | +-------+ | +-----+ | 119 | C | ^ | 120 | +--------------------+ | 121 | | | 122 | V | 123 | A +-----------+ +------------+ | 124 +-------------------->| Evaluator |<-->| Repository | | 125 +-----------+ +------------+ | 126 | 128 Figure 2 - Alternate sacm Architecture 130 Lines marked A, flowing from the asset to the Evaluator, are NEA- 131 based protocols. The asset has a NEA client that performs posture 132 collection, posture brokering, and posture exchange with the 133 Evaluator. The evaluator has a NEA server that evaluates the 134 posture, posture brokering, and posture exchange with the asset. It 135 must be noted that the NEA client can have more than one collector 136 (e.g., one to collect OS information, one to collect IP information, 137 one to collect application information) and the NEA server can have 138 more than one evaluator. 140 The initial posture assessment is best done before the asset has 141 access to the network. [ID.draft-ietf-nea-pt-eap] provides one such 142 solution. After network access has been granted, posture should 143 continue to be maintained [RFC6876] provides on such solution to 144 convey updated posture attributes. 146 Lines marked B, flowing from the client to the BPD are network 147 traffic that occur after initial network access has been granted. 148 The BPDs provide a backstop to ensure that assets are acting 149 appropriately (e.g., a client is acting as a client and not a host). 150 These protocols are not in sacm's scope. 152 Lines marked C, flowing from the BPD to the (Evaluator or 153 Repository?) ensure that the BPDs know how the asset are supposed to 154 be acting. 156 [Question: Do BPDs interact with the database or the evaluator?] 158 [Question: Do BPDs need to talk to each other so that clients cannot 159 choose multiple egress points to hide their activity.] 161 [Question: How do external enterprises interact with this enterprise] 163 4. Security Considerations 165 By identifying the components and where those functions reside this 166 alternative architecture makes it easier to understand the required 167 protocol flows. 169 5. IANA Considerations 171 There are no IANA considerations present in this document. 173 6. References 175 6.1 Normative References 177 Nada 179 6.2 Informative References 181 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 182 Transport Protocol over TLS (PT-TLS)", RFC 6876, February 183 2013. 185 [ID.waltermire-sacm-architecture] D. Waltermire, "Security Automation 186 and Continuous Monitoring (SACM) Architecture", draft- 187 waltermire-sacm-architecture, work-in-progress. 189 [ID.draft-ietf-nea-pt-eap] Cam-Winget, N. and P. Sangster, "PT-EAP: 190 Posture Transport (PT) Protocol For EAP Tunnel Methods", 191 draft-ietf-nea-pt-eap, work-in-progress. 193 Authors' Addresses 195 Russ Housley 196 Vigil Security, LLC 197 918 Spring Knoll Drive 198 Herndon, VA 20170 199 USA 201 Email: : housley@vigilsec.com 203 Sean Turner 204 IECA, Inc. 205 3057 Nutley Street, Suite 106 206 Fairfax, VA 22031 207 USA 209 Email: turners@ieca.com