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

[Sherif Mansour <[e-mail]>]

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 <[e-mail]>
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) <[e-mail]> 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.
>
> 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:[e-mail]
> <[e-mail]>]
> *发送时间:* 2018年7月25日 3:34
> *收件人:* Sherif Mansour <[e-mail]>
> *抄送:* Linqiushi (Jessica, CSPL) <[e-mail]>; Benjamin Kaduk <
> [e-mail]>; Jarrett Lu <[e-mail]>; Xialiang (Frank,
> Network Integration Technology Research Dept) <[e-mail]>;
> [e-mail]
> *主题:* 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.
>
>
>
> 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 <[e-mail]>
> wrote:
>
>
>
> 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) <
> [e-mail]> wrote:
>
> Hi Ben, Adam and Jarrett,
>
> Thanks a lot for raising your concerns.
>
> Please see my comments inline.
>
> Best Regards,
> Jessica
>
> -----邮件原件-----
> 发件人: sacm [mailto:[e-mail]] 代表 Benjamin Kaduk
> 发送时间: 2018年7月24日 2:01
> 收件人: [e-mail]
> 主题: [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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
>
>
>
>
>
>