idnits 2.17.00 (12 Aug 2021) /tmp/idnits48778/draft-handt-sacm-alternate-architecture-00.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 11, 2013) is 3235 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-nea-pt-eap has been published as RFC 7171 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 12, 2014 S. Turner 5 IECA 6 July 11, 2013 8 sacm: Alternate Architecture 9 draft-handt-sacm-alternate-architecture-00 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 those to lazy to 54 go read the other draft. 56 +-------------+ +--------------+ 57 | | | | 58 | Evaluator |<---DF1--->| Content |<---DF1---------+ 59 | | | Repository | | 60 +-------------+ | | | 61 ^ ^ +--------------+ | 62 | | ^ | 63 | | | | 64 | | DF1 | 65 | | | | 66 | | V V 67 | | +--------------+ +----------+ 68 | | | | | | 69 | +-------DF2--->| Controller |<---DF2--->| Sensor | 70 | | | | | 71 | +--------------+ +----------+ 72 | | | 73 | | | 74 | DF3 | 75 | | | 76 | V | 77 | +-----------+ | 78 | | | | 79 +--------------DF4---->| Data |<-----DF3-alt-----+ 80 | Storage | 81 | | 82 +-----------+ 84 Figure 1 - Proposed sacm Architecture 86 The primary issue with the proposed architecture is its abstraction. 87 For those not in the know, it makes more sense to propose an 88 architecture in terms of actual boxes and protocols that flow as 89 opposed to a functional architecture. 91 3. Alternate Architecture 93 In the following figure: 95 o BPD is a Border Protection Device (BPD), which is a firewall and 96 IDS (Intrusion Detection System) all rolled in to one. 98 o Asset is either a host or a client. 100 o Evaluator determines whether the asset is allowed access to the 101 network. 103 enterprise network | wild, 104 | wild west 105 +-------+ +-----+ | 106 +->| asset |<-----+ +----->| BPD |<-|-> 107 | +-------+ | | +-----+ | 108 | | | ^ | 109 | | +----------|---------+ | 110 | | | | | 111 | +-------+ | B | | +-----+ | 112 +->| asset |<-----+---------------------+----->| BPD |<-|-> 113 | +-------+ | | | +-----+ | 114 | | | | ^ | 115 | | +----------|---------+ | 116 | | | | | 117 | +-------+ | | | +-----+ | 118 +->| asset |<-----+ | +----->| BPD |<-|-> 119 | +-------+ | +-----+ | 120 | C | ^ | 121 | +--------------------+ | 122 | | | 123 | V | 124 | A +-----------+ +------------+ | 125 +-------------------->| Evaluator |<-->| Repository | | 126 +-----------+ +------------+ | 127 | 129 Figure 2 - Alternate sacm Architecture 131 Lines marked A, flowing from the asset to the Evaluator, are NEA- 132 based protocols. The asset has a NEA client that performs posture 133 collection, posture brokering, and posture exchange with the 134 Evaluator. The evaluator has a NEA server that evaluates the 135 posture, posture brokering, and posture exchange with the asset. It 136 must be noted that the NEA client can have more than one collector 137 (e.g., one to collect OS information, one to collect IP information, 138 one to collect application information) and the NEA server can have 139 more than one evaluator. 141 The initial posture assessment is best done before the asset has 142 access to the network. [ID.draft-ietf-nea-pt-eap] provides one such 143 solution. After network access has been granted, posture should 144 continue to be maintained [RFC6876] provides on such solution to 145 convey updated posture attributes. 147 Lines marked B, flowing from the client to the BPD are network 148 traffic that occur after initial network access has been granted. 149 The BPDs provide a backstop to ensure that assets are acting 150 appropriately (e.g., a client is acting as a client and not a host). 151 These protocols are not in sacm's scope. 153 Lines marked C, flowing from the BPD to the (Evaluator or 154 Repository?) ensure that the BPDs know how the asset are supposed to 155 be acting. 157 [Question: Do BPDs interact with the database or the evaluator?] 159 [Question: Do BPDs need to talk to each other so that clients cannot 160 choose multiple egress points to hide their activity.] 162 [Question: How do external enterprises interact with this enterprise] 164 4. Security Considerations 166 By identifying the components and where those functions reside this 167 alternative architecture makes it easier to understand the required 168 protocol flows. 170 5. IANA Considerations 172 There are no IANA considerations present in this document. 174 6. References 176 6.1 Normative References 178 Nada 180 6.2 Informative References 182 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 183 Transport Protocol over TLS (PT-TLS)", RFC 6876, February 184 2013. 186 [ID.waltermire-sacm-architecture] D. Waltermire, "Security Automation 187 and Continuous Monitoring (SACM) Architecture", draft- 188 waltermire-sacm-architecture, work-in-progress. 190 [ID.draft-ietf-nea-pt-eap] Cam-Winget, N. and P. Sangster, "PT-EAP: 191 Posture Transport (PT) Protocol For EAP Tunnel Methods", 192 draft-ietf-nea-pt-eap, work-in-progress. 194 Authors' Addresses 196 Russ Housley 197 Vigil Security, LLC 198 918 Spring Knoll Drive 199 Herndon, VA 20170 200 USA 202 Email: : housley@vigilsec.com 204 Sean Turner 205 IECA, Inc. 206 3057 Nutley Street, Suite 106 207 Fairfax, VA 22031 208 USA 210 Email: turners@ieca.com