Subject: Re: [sacm] minor comments on draft-lin-sacm-nid-mp-security-baseline-03

From: "Linqiushi (Jessica, CSPL)" <[email-masked]>
Date: Tue, 24 Jul 2018 02:24:51 +0000

Hi Ben, Adam and Jarrett,

Thanks a lot for raising your concerns.

Please see my comments inline.

Best Regards,
Jessica

-----邮件原件-----
发件人: sacm [mailto:[email-masked]] 代表 Benjamin Kaduk
发送时间: 2018年7月24日 2:01
收件人: [email-masked]
主题: [sacm] minor comments on draft-lin-sacm-nid-mp-security-baseline-03

> During Jessica's talk I noticed a couple things I wanted to mention, 
> but that didn't seem to merit getting up to the mic:

> There's a container for 'telnet' admin access; my understanding is 
> that there are not any applications out there that could be called 
> "telnet" and are actually secure these days (but maybe I'm missing
> some!); e.g., kerberized telnet mostly only uses single-DES and a 
> lousy cipher mode, with a vendor-specific option for triple-DES, which
> is deprecated as of my document that's currently at the RFC Editor. 
> So we may want to have some text clarifying the situation and
> disrecommending its use (or even remove it entirely, if that's feasible).

The "telnet" admin access listed in the current draft is not meant to suggest the use of Telnet. In some legacy scenarios that the insecure channel like Telnet has to be used, some configuration such as changing the source port is recommended. We mentioned to disable the insecure channel, but didn't clarify it in details in the draft.
You're right. The security baseline is intended to be a minimal set of security controls and should be up-to-date. We'll remove it and other similar security controls in the next version of draft. 

> Similarly, there's a pwd-sec-policy container that describes password
> security policies.  While it's definitely true that password policies
> and mandatory change intervals are currently widely deployed, it's
> less clear whether their usage should still be considered useful or a
> best current practice -- I think I've seen some research go by that
> suggests that not requiring character classes or frequency of change
> can be just as secure (and, of course, if passwords can be avoided entirely that can also help).

As password security policy is the currently widely deployed mechanisms and devices support it,maybe we can make it optional, such as a feature? 
Currently the devices support this kind of feature, then it can be checked whether this policy is enabled.

>So, perhaps there is room for some qualifying text here as well.

> -Ben
> (with no hats)
_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm

---

From: Sherif Mansour <[email-masked]>
Date: Tue, 24 Jul 2018 07:08:30 +0100

Hey Everyone,

I second Adam's idea for a "baseline registry".
1) It's easier to change a registry vs a draft
2) Organizations might want to customize their own registries with their
own content - I will give two examples based on the thread above:

As mentioned before some legacy systems only support Telnet, I remember a
few years ago a business still had some Vax/Alpha systems running and they
needed telnet. As a compensating control, we placed network restrictions
around those systems, placed a bastion hosts in front of it with an SSL web
terminal, that way secure communication took place between the rest of the
environment and the hardened host and then telnet to the legacy systems,
but at least the issue is contained in a small environment.

For the passwords it depends as well for an org e.g. for app to app
credentials vs. human to app Or even customer to eCommerce app.

   - Take Google for example, for their staff to limit the impact on
   phishing they have issued U2F secure tokens to their staff (See Link
   <https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/>).
   The password policy itself might be different as a result.
   - Others like Apple have rolled password managers to all their staff (see
   link
   <https://appleinsider.com/articles/18/07/10/apple-looking-to-deploy-1password-company-wide-may-buy-out-apps-developer>).
   This is addition to password complexity - and in a way make it easier to
   manage.
   - For app to app communication you want this to be seamless with
   automated key rolling as well as "Break glass" functionality leveraging a
   secrets vault such as https://www.vaultproject.io/ is an option.
   - For customer facing sites, password policy might not be enough, thus
   checking for password re-use, adding anomaly detection/brute-force
   mitigation, 2factor such as U2F tokens, as well as graceful recovery might
   be part of the policy.

Having a baseline registry would help as the threat landscape changes for
existing technology or the ability to replicate similar baselines to new
technologies without the need for too much re-work.

-Sherif

On Tue, Jul 24, 2018 at 3:24 AM, Linqiushi (Jessica, CSPL) <
[email-masked]> wrote:

> The "telnet" admin access listed in the current draft is not meant to
> suggest the use of Telnet. In some legacy scenarios that the insecure
> channel like Telnet has to be used, some configuration such as changing the
> source port is recommended. We mentioned to disable the insecure channel,
> but didn't clarify it in details in the draft.
> You're right. The security baseline is intended to be a minimal set of
> security controls and should be up-to-date. We'll remove it and other
> similar security controls in the next version of draft.
>
> As password security policy is the currently widely deployed mechanisms
> and devices support it,maybe we can make it optional, such as a feature?

---

From: Adam Montville <[email-masked]>
Date: Tue, 24 Jul 2018 14:34:19 -0500

For these "baseline" drafts, could we call them baseline data models instead? To me, just calling them baseline is problematic - it's an overloaded term.

Moving on from that... I have a couple of follow-on questions related to the idea of a data model registry... 

We are already considering the adoption of a draft known as the ROLIE configuration checklist information type. Presumably, such configuration checklists would be comparable to the data models expressed in this registry right? Then, from that, would ROLIE be a suitable mechanism for the data model registry, or would we want to reference data models in a different way?

Thoughts on any of that?

Given that there seems to be some interest, I'll volunteer to draft something containing ideas about how such a registry could work, and why it'd be important.

Adam

> On Jul 24, 2018, at 1:08 AM, Sherif Mansour <[email-masked]> wrote:
> 
> Hey Everyone,
> 
> 2) Organizations might want to customize their own registries with their own content - I will give two examples based on the thread above:
> 
> As mentioned before some legacy systems only support Telnet, I remember a few years ago a business still had some Vax/Alpha systems running and they needed telnet. As a compensating control, we placed network restrictions around those systems, placed a bastion hosts in front of it with an SSL web terminal, that way secure communication took place between the rest of the environment and the hardened host and then telnet to the legacy systems, but at least the issue is contained in a small environment.
> 
> For the passwords it depends as well for an org e.g. for app to app credentials vs. human to app Or even customer to eCommerce app. 
> Take Google for example, for their staff to limit the impact on phishing they have issued U2F secure tokens to their staff (See Link <https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/>). The password policy itself might be different as a result.
> Others like Apple have rolled password managers to all their staff (see link <https://appleinsider.com/articles/18/07/10/apple-looking-to-deploy-1password-company-wide-may-buy-out-apps-developer>). This is addition to password complexity - and in a way make it easier to manage.
> For app to app communication you want this to be seamless with automated key rolling as well as "Break glass" functionality leveraging a secrets vault such as https://www.vaultproject.io/ <https://www.vaultproject.io/> is an option.
> For customer facing sites, password policy might not be enough, thus checking for password re-use, adding anomaly detection/brute-force mitigation, 2factor such as U2F tokens, as well as graceful recovery might be part of the policy.
> Having a baseline registry would help as the threat landscape changes for existing technology or the ability to replicate similar baselines to new technologies without the need for too much re-work.
> 
> -Sherif
> 
> On Tue, Jul 24, 2018 at 3:24 AM, Linqiushi (Jessica, CSPL) <[email-masked] <mailto:[email-masked]>> wrote:
> 发件人: sacm [mailto:[email-masked] <mailto:[email-masked]>] 代表 Benjamin Kaduk
> 发送时间: 2018年7月24日 2:01
> 收件人: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 24 Jul 2018 19:39:08 -0500

> You're right. The security baseline is intended to be a minimal set of security controls and should be up-to-date. We'll remove it and other similar security controls in the next version of draft. 

That would be fine with me.

> Currently the devices support this kind of feature, then it can be checked whether this policy is enabled.

I think that's the sort of thing I had in mind.

Thanks!

-Ben

---

From: "Xialiang (Frank, Network Integration Technology Research Dept)" <[email-masked]>
Date: Wed, 25 Jul 2018 03:12:13 +0000

Hi Adam,
Totally agree with you.
Our draft is just a data model for baseline, which describes the structured configuration parameters and status attributes for the network device’s security baseline.
Right now, we choose the YANG data model since it’s widely used for the network device, and the new defined YANG push mechanism is very suitable for the large scale security posture collection.

In regard to ROLIE, it’s good and well suitable for the security incident information exchange. But ROLIE currently only supports the xml or json scheme, how to combine the ROLIE and YANG data model? Maybe you can give more clarification.
Anyway, we are interested with this direction, and looking forward to more discussion and the new draft for it.

Thanks!

B.R.
Frank

发件人: Adam Montville [mailto:[email-masked]]
发送时间: 2018年7月25日 3:34
收件人: Sherif Mansour <[email-masked]>
抄送: Linqiushi (Jessica, CSPL) <[email-masked]>; Benjamin Kaduk <[email-masked]>; Jarrett Lu <[email-masked]>; Xialiang (Frank, Network Integration Technology Research Dept) <[email-masked]>; [email-masked]
主题: Re: [sacm] minor comments on draft-lin-sacm-nid-mp-security-baseline-03

Thoughts on any of that?

Adam

On Jul 24, 2018, at 1:08 AM, Sherif Mansour <[email-masked]<mailto:[email-masked]>> wrote:

Hey Everyone,

  *   Take Google for example, for their staff to limit the impact on phishing they have issued U2F secure tokens to their staff (See Link<https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/>). The password policy itself might be different as a result.
  *   Others like Apple have rolled password managers to all their staff (see link<https://appleinsider.com/articles/18/07/10/apple-looking-to-deploy-1password-company-wide-may-buy-out-apps-developer>). This is addition to password complexity - and in a way make it easier to manage.
  *   For app to app communication you want this to be seamless with automated key rolling as well as "Break glass" functionality leveraging a secrets vault such as https://www.vaultproject.io/ is an option.
  *   For customer facing sites, password policy might not be enough, thus checking for password re-use, adding anomaly detection/brute-force mitigation, 2factor such as U2F tokens, as well as graceful recovery might be part of the policy.
Having a baseline registry would help as the threat landscape changes for existing technology or the ability to replicate similar baselines to new technologies without the need for too much re-work.

-Sherif

On Tue, Jul 24, 2018 at 3:24 AM, Linqiushi (Jessica, CSPL) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ben, Adam and Jarrett,

Best Regards,
Jessica

-----邮件原件-----
发件人: sacm [mailto:[email-masked]<mailto:[email-masked]>] 代表 Benjamin Kaduk
发送时间: 2018年7月24日 2:01
收件人: [email-masked]<mailto:[email-masked]>
主题: [sacm] minor comments on draft-lin-sacm-nid-mp-security-baseline-03

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

---

From: Adam Montville <[email-masked]>
Date: Wed, 25 Jul 2018 06:29:54 -0500

Right, that’s a good point. I suppose that we could encode the YANG in CDATA or the JSON equivalent, though I’m sure that would end up being messy. YIN comes to mind, and then if we really wanted to do JSON, I think there’s a way to convert from XML to JSON, though I’m not sure it preserves everything that would need to be preserved.

Still, I’m not sure ROLIE would be the “right” solution for a baseline data model registry. It’s just something that came to mind as a possible solution.

Adam

> On Jul 24, 2018, at 10:12 PM, Xialiang (Frank, Network Integration Technology Research Dept) <[email-masked]> wrote:
> 
> Hi Adam,
> Totally agree with you.
> Take Google for example, for their staff to limit the impact on phishing they have issued U2F secure tokens to their staff (See Link). The password policy itself might be different as a result.
> Others like Apple have rolled password managers to all their staff (see link). This is addition to password complexity - and in a way make it easier to manage.
> For app to app communication you want this to be seamless with automated key rolling as well as "Break glass" functionality leveraging a secrets vault such as https://www.vaultproject.io/ is an option.
> On Tue, Jul 24, 2018 at 3:24 AM, Linqiushi (Jessica, CSPL) <[email-masked]> wrote:

---

From: Sherif Mansour <[email-masked]>
Date: Wed, 25 Jul 2018 12:57:12 +0100

I would also consider looking into
https://avro.apache.org its versitle enough and has been battle tested in
large environments.

On Wed, 25 Jul 2018 at 12:29 pm, Adam Montville <[email-masked]>
wrote:

> Right, that’s a good point. I suppose that we could encode the YANG in
> CDATA or the JSON equivalent, though I’m sure that would end up being
> messy. YIN comes to mind, and then if we really wanted to do JSON, I think
> there’s a way to convert from XML to JSON, though I’m not sure it preserves
> everything that would need to be preserved.
>
> Still, I’m not sure ROLIE would be the “right” solution for a baseline
> data model registry. It’s just something that came to mind as a possible
> solution.
>
> Adam
>
> On Jul 24, 2018, at 10:12 PM, Xialiang (Frank, Network Integration
> Technology Research Dept) <[email-masked]> wrote:
>
> Hi Adam,
>
> Totally agree with you.
>
> Our draft is just a data model for baseline, which describes the
> structured configuration parameters and status attributes for the network
> device’s security baseline.
>
> Right now, we choose the YANG data model since it’s widely used for the
> network device, and the new defined YANG push mechanism is very suitable
> for the large scale security posture collection.
>
>
>
> In regard to ROLIE, it’s good and well suitable for the security incident
> information exchange. But ROLIE currently only supports the xml or json
> scheme, how to combine the ROLIE and YANG data model? Maybe you can give
> more clarification.
>
> *发件人:* Adam Montville [mailto:[email-masked]
> <[email-masked]>]
> *发送时间:* 2018年7月25日 3:34
> *收件人:* Sherif Mansour <[email-masked]>
> *抄送:* Linqiushi (Jessica, CSPL) <[email-masked]>; Benjamin Kaduk <
> [email-masked]>; Jarrett Lu <[email-masked]>; Xialiang (Frank,
> Network Integration Technology Research Dept) <[email-masked]>;
> [email-masked]
> *主题:* Re: [sacm] minor comments on
> draft-lin-sacm-nid-mp-security-baseline-03
>
>
>
> For these "baseline" drafts, could we call them baseline data models
> instead? To me, just calling them baseline is problematic - it's an
> overloaded term.
>
>
>
> We are already considering the adoption of a draft known as the ROLIE
> configuration checklist information type. Presumably, such configuration
> checklists would be comparable to the data models expressed in this
> registry right? Then, from that, would ROLIE be a suitable mechanism for
> the data model registry, or would we want to reference data models in a
> different way?
>
>
>
> Thoughts on any of that?
>
>
>
> Given that there seems to be some interest, I'll volunteer to draft
> something containing ideas about how such a registry could work, and why
> it'd be important.
>
>
>
> Adam
>
>
>
>
>

---

From: Adam Montville <[email-masked]>
Date: Wed, 25 Jul 2018 07:51:15 -0500

Thanks for the pointer, Sherif - will look at it.

> On Jul 25, 2018, at 6:57 AM, Sherif Mansour <[email-masked]> wrote:
> 
> https://avro.apache.org <https://avro.apache.org/> its versitle enough and has been battle tested in large environments.
> 
> On Wed, 25 Jul 2018 at 12:29 pm, Adam Montville <[email-masked] <mailto:[email-masked]>> wrote:
> On Jul 24, 2018, at 10:12 PM, Xialiang (Frank, Network Integration Technology Research Dept) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi Adam,
>> 
>> Totally agree with you.
>> 
>> 发件人: Adam Montville [mailto:[email-masked] <mailto:[email-masked]>] 
>> 发送时间: 2018年7月25日 3:34
>> 收件人: Sherif Mansour <[email-masked] <mailto:[email-masked]>>
>> 抄送: Linqiushi (Jessica, CSPL) <[email-masked] <mailto:[email-masked]>>; Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>; Jarrett Lu <[email-masked] <mailto:[email-masked]>>; Xialiang (Frank, Network Integration Technology Research Dept) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> On Jul 24, 2018, at 1:08 AM, Sherif Mansour <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>  
>> 
>> Hey Everyone,
>> 
>>  
>>

---

From: Sherif Mansour <[email-masked]>
Date: Wed, 25 Jul 2018 14:04:30 +0100

No problem FYI its used in Kafka and Hadoop as well.

On Wed, 25 Jul 2018 at 1:51 pm, Adam Montville <[email-masked]>
wrote:

> On Wed, 25 Jul 2018 at 12:29 pm, Adam Montville <
> [email-masked]> wrote:
>
>> Anyway, we are interested with this direction, and looking forward to
>> more discussion and the new draft for it.
>>
>>
>>
>> Thanks!
>>
>>
>>
>> B.R.
>>
>> Frank
>>
>>
>>
>>    - For customer facing sites, password policy might not be enough,
>>    thus checking for password re-use, adding anomaly detection/brute-force

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 25 Jul 2018 08:18:36 -0500

> Right, that’s a good point. I suppose that we could encode the YANG in CDATA or the JSON equivalent, though I’m sure that would end up being messy. YIN comes to mind, and then if we really wanted t…

I'm probably confused (not interacting with YANG very much), but isn't
there a native XML encoding for YANG (e.g., the various "XML Mapping Rules"
sections of RFC 6020)?  Similarly RFC 7951 for a JSON mapping of YANG.

-Ben

---

From: Adam Montville <[email-masked]>
Date: Wed, 25 Jul 2018 08:20:19 -0500

> On Jul 25, 2018, at 8:18 AM, Benjamin Kaduk <[email-masked]> wrote:
> 

I'm sure I'm the one who is confused here - being completely new to YANG. I thought that YIN was the name given to the XML encoding for YANG. I was unaware of RFC 7951.

---

From: "Xialiang (Frank, Network Integration Technology Research Dept)" <[email-masked]>
Date: Thu, 26 Jul 2018 01:03:15 +0000

Me too~~

Thanks for pointing it out, Ben. I will look at it.

-----邮件原件-----
发件人: Adam Montville [mailto:[email-masked]] 
发送时间: 2018年7月25日 21:20
收件人: Benjamin Kaduk <[email-masked]>
抄送: Xialiang (Frank, Network Integration Technology Research Dept) <[email-masked]>; Sherif Mansour <[email-masked]>; Linqiushi (Jessica, CSPL) <[email-masked]>; Jarrett Lu <[email-masked]>; [email-masked]
主题: Re: [sacm] minor comments on draft-lin-sacm-nid-mp-security-baseline-03

>>> 抄送: Linqiushi (Jessica, CSPL) <[email-masked]>; Benjamin Kaduk 
>>> <[email-masked]>; Jarrett Lu <[email-masked]>; Xialiang 
>>> (Frank, Network Integration Technology Research Dept) 
>>> <[email-masked]>; [email-masked]
>>> 主题: Re: [sacm] minor comments on 
>>> 主题: [sacm] minor comments on 
>>>> During Jessica's talk I noticed a couple things I wanted to 
>>>> mention, but that didn't seem to merit getting up to the mic:
>>> 
>>>> lousy cipher mode, with a vendor-specific option for triple-DES, 
>>>> which is deprecated as of my document that's currently at the RFC Editor.
>>>> Similarly, there's a pwd-sec-policy container that describes 
>>>> password security policies.  While it's definitely true that 
>>>> password policies and mandatory change intervals are currently 
>>>> widely deployed, it's less clear whether their usage should still 
>>>> be considered useful or a best current practice -- I think I've 
>>>> seen some research go by that suggests that not requiring character 
>>>> classes or frequency of change can be just as secure (and, of course, if passwords can be avoided entirely that can also help).
>>>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 26 Jul 2018 11:05:06 +0200

Hello all,

this thread starts to mix quite a few topics now :) Maybe we should try 
to segregate them?

* pro & con wrt to registry (incl. potential spec required, expert 
review, etc.) and or I-D

* YANG Push, which depends heavily on the upcoming development in 
NETCONF in the next months

* encoding (there is e.g. I-D.ietf-core-yang-cbor)

* terminology (as always) is difficult: "baseline data model" wrt to 
"security" could imply the existence of guidance how to derive the 
nominal values and BP (aka a framework that helps the reader to make use 
of the data model). That is not the case, right?

A small comment on encoding: If anyone wants to try to do a canonical 
mapping of XML structures to JSON or CBOR structures (and vice versa), I 
am happy to help. Please mind, that this would be an independent effort 
to representing YANG-modeled data in JSON or CBOR as that is already 
being done.

Viele Grüße,

Henk

On 07/26/2018 03:03 AM, Xialiang (Frank, Network Integration Technology

---

From: Adam Montville <[email-masked]>
Date: Fri, 27 Jul 2018 07:03:09 -0500

Splitting one of the threads I think I have something to say about for the time being :-)

I'm working on an example I-D for a registry, stay tuned on this front. My goal is to have something submitted far enough in advance for people to review *prior* to our yet-to-be-solidified September virtual interim.

Kind regards, 

Adam

> On Jul 26, 2018, at 4:05 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hello all,
> 
> this thread starts to mix quite a few topics now :) Maybe we should try to segregate them?
> 
> * pro & con wrt to registry (incl. potential spec required, expert review, etc.) and or I-D
> 
> * YANG Push, which depends heavily on the upcoming development in NETCONF in the next months
> 
> * terminology (as always) is difficult: "baseline data model" wrt to "security" could imply the existence of guidance how to derive the nominal values and BP (aka a framework that helps the reader to make use of the data model). That is not the case, right?
> 
> A small comment on encoding: If anyone wants to try to do a canonical mapping of XML structures to JSON or CBOR structures (and vice versa), I am happy to help. Please mind, that this would be an independent effort to representing YANG-modeled data in JSON or CBOR as that is already being done.
> 
> Viele Grüße,
> 
> Henk
> 
> On 07/26/2018 03:03 AM, Xialiang (Frank, Network Integration Technology Research Dept) wrote:
>> Me too~~

---

From: Adam Montville <[email-masked]>
Date: Fri, 27 Jul 2018 07:08:42 -0500

Splitting out another thread....

> <snip>

You'll have to define BP for me. Baseline Profile? British Petroleum? I'm just not so astute this morning.

I'm not sure that the term necessarily implies the existence of nominal value guidance. To me, the baseline data model, in the SACM context, is simply an enumeration of the security-relevant attributes for the subject technology. Ideally, the nominal value guidance, and a way to get at the framework you mention, would exist, but I don't think the existence of one implies the existence of the other. In fact, I think decoupling these is better than not.

Perhaps I'm misunderstanding what you're driving at, Henk?

Kind regards,

Adam