From nobody Sun Jan 31 22:32:13 2016 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21431ACED4; Sun, 31 Jan 2016 22:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1pgsYl9M-Cp; Sun, 31 Jan 2016 22:32:10 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCD61ACED7; Sun, 31 Jan 2016 22:32:10 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:a8fc:d6dc:8732:faaf]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u116W809021503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Feb 2016 06:32:08 GMT (envelope-from joelja@bogus.com) To: IETF Meeting Session Request Tool , session-request@ietf.org References: <20160106134508.485.55787.idtracker@ietfa.amsl.com> From: joel jaeggli Message-ID: <56AEFBE8.1050107@bogus.com> Date: Sun, 31 Jan 2016 22:32:08 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <20160106134508.485.55787.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ffPGxjkxbcnTqa3TIjmj9Mjgh7exRGMt5" Archived-At: Cc: opsec@ietf.org, opsec-chairs@ietf.org Subject: Re: [OPSEC] opsec - New Meeting Session Request for IETF 95 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 06:32:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ffPGxjkxbcnTqa3TIjmj9Mjgh7exRGMt5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks eric. On 1/6/16 5:45 AM, "IETF Meeting Session Request Tool" wrote: >=20 >=20 > A new meeting session request has just been submitted by Eric Vyncke, a= Chair of the opsec working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: Operational Security Capabilities for IP Network In= frastructure > Area Name: Operations and Management Area > Session Requester: Eric Vyncke >=20 > Number of Sessions: 1 > Length of Session(s): 1 Hour > Number of Attendees: 30 > Conflicts to Avoid:=20 > First Priority: saag v6ops > Second Priority: 6man acme opsarea opsawg sidr > Third Priority: dnsop dnssd homenet mif >=20 >=20 > Special Requests: > =20 > --------------------------------------------------------- >=20 --ffPGxjkxbcnTqa3TIjmj9Mjgh7exRGMt5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlau++gACgkQ8AA1q7Z/VrL+jgCdFjaMriTL+m3oW5j2hXnmYwMb VfMAniDZZjg2ASXAAOHcfjFsHbobMSBA =JjDd -----END PGP SIGNATURE----- --ffPGxjkxbcnTqa3TIjmj9Mjgh7exRGMt5-- From nobody Sun Jan 31 22:37:55 2016 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1C81AD09F; Sun, 31 Jan 2016 22:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pzydaom02QD4; Sun, 31 Jan 2016 22:37:51 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD811AD09D; Sun, 31 Jan 2016 22:37:50 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:a8fc:d6dc:8732:faaf]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u116bkNt021557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Feb 2016 06:37:49 GMT (envelope-from joelja@bogus.com) To: "opsec@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA6BE9F6C7@AZ-FFEXMB04.global.avaya.com> <9DDB58C939D0974CAEB9F2A0A0FC15C109DD9470@G2W2529.americas.hpqcorp.net> From: joel jaeggli Message-ID: <56AEFD3A.1030109@bogus.com> Date: Sun, 31 Jan 2016 22:37:46 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TmGeIj5Q5fXM7cpbAPK8WFObWsUg1dwrl" Archived-At: Cc: "sacm@ietf.org" Subject: Re: [OPSEC] [sacm] Feedback on the SACM Vulnerability Assessment Scenario X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 06:37:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TmGeIj5Q5fXM7cpbAPK8WFObWsUg1dwrl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Trimmed opsawg since this seems most appropiate to opsec / sacm https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/ got a signficant change associated with the sacm usecase alignment. that seems like a signficant effort borne out of this feedback. joel On 12/2/15 9:21 AM, Haynes, Dan wrote: > Hi Josh, >=20 > Thanks for the feedback!=20 >=20 > =20 >=20 > Comments inline below. Please let me know if I am misunderstanding > anything. >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > Danny >=20 > =20 >=20 > =20 >=20 > *From:* sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Stevens, Jos= h > (Cyber Security) > *Sent:* Thursday, November 19, 2015 10:37 PM > *To:* Romascanu, Dan (Dan) ; opsec@ietf.org; > opsawg@ietf.org > *Cc:* sacm@ietf.org > *Subject:* Re: [sacm] Feedback on the SACM Vulnerability Assessment Sce= nario >=20 > =20 >=20 > Hi Dan, >=20 > =20 >=20 > Agreed, this does help focus the work for this SACM Working Group. > After reading the draft-coffin-sacm-vuln-scenario, I had some initial > feedback from an enterprise defense perspective that might be > incorporated. Here are my contributions: >=20 > =20 >=20 > 1. In the abstract, a vulnerability report is referenced, however= > it=92s not clear whether an authenticated or unauthenticated vulnerabil= ity > scan report (or both) is being referred to. If it can consume both, I > would call that out. If what=92s being referred to is actually a recurr= ing > industry standard vulnerability report from a vendor, that could also > clear up the abstract prior to the scope statement where the > vulnerability report is defined. >=20 > =20 >=20 > [danny]: the intent is a vulnerability report is that it is published b= y > a vendor (e.g. security advisory) in some un-prescribed format from > which the relevant data can be extracted from it in some un-prescribed > way. That is, the vulnerability report is not necessarily an industry > standard (at least not in the context of this document). We can try to= > clarify this a bit. >=20 > =20 >=20 > 2. In the abstract, there isn=92t a reference to the endpoint bas= ed > approach that is detailed in the next section. Ideally, instead of =93I= t > begins with an enterprise ingesting a vulnerability report and ends at > the point of identifying affected endpoints=94, this could be better > summarized as =93Endpoint data is pushed to a central point for compari= son > with vulnerability criteria to enable posture assessment.=94 =20 >=20 > =20 >=20 > [danny]: we can try to clarify this. =20 >=20 > =20 >=20 > 3. 3.3 A few comments on page 7, paragraph 4 =93The attributes > could be manually entered into a CMDB by a human, This would include an= y > attributes that cannot be collected programmatically.=94 I believe the > intent here is to leave fields open for the user to define and leverage= > as needed, however I'm not sure we want to advocate manual entry? > Ideally, if we can use a common set of algorithms that can be *manually= * > adjusted to provide exception based rules to the overall effort. If we= > give a user the chance to mangle data sets, they probably will - I'm in= > favor of providing additional fields that can be interfaced with other > security API's where automation is the default workflow choice. Here > are some alternatives to manual entry for these three categories: >=20 > a. Location - for a global organization consider the DNS sub > domain infrastructure, for a smaller organization consider SIEM events > that stamp the closest proximity security infrastructure into an event > (zone based), others might be ARP cache, DNS cache, etc. >=20 > b. Role - compare with external maps to identify external facing > endpoints, fingerprint web server packages with a local agent, scrape > local process table to gauge TCP connections to the web server (is it > really a web server), etc. >=20 > c. Criticality - analytics on logins, active sessions, user > account counts and net flow will provide a strong enterprise criticalit= y > score >=20 > =20 >=20 > [danny]: I don=92t think allowing users to manually enter attributes in= to > the CMDB necessarily means mangled data sets. For example, an > organization could define a schema that defines what the information > should look like. While it wouldn=92t likely be standardized, I think > that is ok given this type of information would most likely be > organization-specific anyways. What do others think? >=20 > =20 >=20 > With that said, I think this other information and the algorithms to > process this information would be useful as well. Does anyone have any= > thoughts on this approach? >=20 > =20 >=20 > 4. 5.1 If the authenticated or unauthenticated data sets do get > merged or compared, a decision tree will have to be pre-established - > does the authenticated/agent based score override a more recent but > unauthenticated scan finding? >=20 > =20 >=20 > [danny]: I don=92t think I know the answer at this time. It depends o= n > how the WG ends up defining the assessment logic. Maybe it is somethin= g > that can be configured in the evaluation guidance or maybe authenticate= d > data always takes precedence over unauthenticated data. With that said= , > authenticated/unauthenticated sounds like it would be a good piece of > information to capture about an attribute in the information model (e.g= =2E > similar how we want to capture if an attribute can be used for > designation/identification or if it is has privacy concerns). Do other= s > have thoughts on authenticated vs. unauthenticated attributes impacting= > assessments? >=20 > =20 >=20 > 5. For Appendix B: Priority should include cyber intelligence and= > campaign based vulnerability scores. For example, in 2013 - CVE's > leveraged by the "Red October Advanced Cyber Espionage Campaign > targeting Diplomatic officials" should be prioritized well above the > CVE's used in Conficker , etc. How can this standard be directed or > modified to accept industry standard Indicator of Compromise (IOC)=92s = and > provide intel driven posture assessments? >=20 > =20 >=20 > [danny]: agree, it probably makes sense to say something about cyber > intelligence information in determining scores and priorities. What do= > others think?=20 >=20 > =20 >=20 > When you say =93standard=94 are you referring to the vulnerability > assessment scenario draft? SACM in general? Or, something > else? =20 >=20 > =20 >=20 > 6. Other general comments: >=20 > =20 >=20 > o Are mutex string acquisition, DLL fingerprinting, IOC processing an= d > auto remediation out of the scope for the current Working Group? In > addition, to Vulnerability assessment, these would all go nicely > together as part of a standard endpoint spec for vendors to communicate= > through. I=92ve seen email traffic from the group on several of these > related topics. >=20 > =20 >=20 > [danny]: Remediation is currently out-of-scope for SACM. Regarding > mutex string acquisition, DLL fingerprinting, and IOC processing, I > think it depends on what is required to collect the data. If we can > collect the data by looking at something on the endpoint (e.g. file > hashes, registry keys, etc.), I suspect it would be in scope. If we > have to do more detailed analysis (e.g. dynamic malware analysis) that > require specialized tools and sandboxes, I suspect that would be > out-of-scope. With that said, the output of this more detailed analysi= s > could produce information that would serve as input into creating > guidance to assess endpoints for IOCs at which point I think it would > fall within the scope of SACM.=20 >=20 > =20 >=20 > o Section 3. The multiple references to CMDB make some potential > assumptions about managed vs. unmanaged endpoints >=20 > =A7 It=92s possible that unmanaged endpoints won't be found in a CMDB,= does > this model account in any way for those? >=20 > =A7 An alternative is to consider continuous netflow analytics updatin= g a > repository / data lake >=20 > =20 >=20 > [danny]: We didn=92t really think of CMDB at that level. We simply use= d > CMDB to mean a place to store guidance, data, results, etc. Basically,= > anything that is input or output with respect to an assessment. With > that said, as SACM begins to define what it needs in a repository (and > its data stores), these are definitely questions that need to be asked.= >=20 > =20 >=20 > o Is Rogue Device Detection under consideration as a data point or > even an Endpoint Type? >=20 > o Discovering neighboring endpoints >=20 > o ARP as sensor data=20 >=20 > o Once a rogue device has been detected, a detailed (or secondary) > vulnerability assessment should begin automatically. >=20 > =20 >=20 > [danny]: in previous discussions, there was mention of managed vs. > unmanaged endpoints, on the network, in the context of BYOD. Managed > endpoints are those owned/controlled by the organization whereas > unmanaged would be endpoints that are not owned nor controlled by the > organization (i.e. personal laptop, etc.). Would your definition of a > rogue endpoint align with an unmanaged endpoint? =20 >=20 > =20 >=20 > Hope this helps. >=20 > =20 >=20 > Josh Stevens >=20 > Hewlett Packard Enterprise >=20 > =20 >=20 > *From:* sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Romascanu, > Dan (Dan) > *Sent:* Thursday, November 19, 2015 7:51 AM > *To:* opsec@ietf.org ; opsawg@ietf.org > > *Cc:* sacm@ietf.org > *Subject:* [sacm] Feedback on the SACM Vulnerability Assessment Scenari= o >=20 > =20 >=20 > Hi, >=20 > =20 >=20 > I am reiterating a request that I made at IETF 94 in the OPSAWG meeting= , > and also sent to the mail lists of opsec and opsawg. The SACM WG is > considering a document > https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/ that > describes the operational practice of vulnerability reports, which we > believe is an important use case in the security assessment life cycle.= > We are requiring feedback from operators about the scenario describe in= > this document =96 does it make sense? Is it similar with what you do in= > operational real life? Are you using similar or different methods for > vulnerability assessment in your networks? A quick reading and short > feedback would be greatly appreciated. >=20 > =20 >=20 > Thanks and Regards, >=20 > =20 >=20 > Dan >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 --TmGeIj5Q5fXM7cpbAPK8WFObWsUg1dwrl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlau/TsACgkQ8AA1q7Z/VrK9wgCeNPRUusGtpVmqSZqTYXOy8meE yVYAni46sXUxThSae1IGISVKdVrSLMeX =Ntuw -----END PGP SIGNATURE----- --TmGeIj5Q5fXM7cpbAPK8WFObWsUg1dwrl--