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

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) <
linqiushi@huawei.com> wrote:

> Hi Ben, Adam and Jarrett,
>
> Thanks a lot for raising your concerns.
>
> Please see my comments inline.
>
> Best Regards,
> Jessica
>
> -----邮件原件-----
> 发件人: sacm [mailto:sacm-bounces@ietf.org] 代表 Benjamin Kaduk
> 发送时间: 2018年7月24日 2:01
> 收件人: sacm@ietf.org
> 主题: [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
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm
>