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

[Sherif Mansour <[e-mail]>]

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

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

> Thanks for the pointer, Sherif - will look at it.
>
>
> On Jul 25, 2018, at 6:57 AM, Sherif Mansour <[e-mail]>
> wrote:
>
> 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
>>
>>
>>
>>
>>
>>
>