<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <font face="Cambria">FYI: <br>
      <br>
      ETSI TR 103 456 V1.1.1 (2017-10) Implementation of the Network and
      Information Security (NIS) Directive<br>
      <br>
<a class="moz-txt-link-freetext" href="http://www.etsi.org/deliver/etsi_tr/103400_103499/103456/01.01.01_60/tr_103456v010101p.pdf">http://www.etsi.org/deliver/etsi_tr/103400_103499/103456/01.01.01_60/tr_103456v010101p.pdf</a><br>
      <br>
      Thanks,<br>
      M.D.<br>
    </font><br>
    <div class="moz-cite-prefix">On 10/20/2017 2:39 AM, Ben Wilson via
      Netsec wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:SN1PR14MB0175DECD54FCF6DDA7EEC1A4F1420@SN1PR14MB0175.namprd14.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin-top:0in;
        margin-right:0in;
        margin-bottom:8.0pt;
        margin-left:0in;
        line-height:106%;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:8.0pt;
        margin-left:.5in;
        mso-add-space:auto;
        line-height:106%;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst
        {mso-style-priority:34;
        mso-style-type:export-only;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        mso-add-space:auto;
        line-height:106%;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle
        {mso-style-priority:34;
        mso-style-type:export-only;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        mso-add-space:auto;
        line-height:106%;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast
        {mso-style-priority:34;
        mso-style-type:export-only;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:8.0pt;
        margin-left:.5in;
        mso-add-space:auto;
        line-height:106%;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1664888408;
        mso-list-type:hybrid;
        mso-list-template-ids:590899142 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level3
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level4
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level5
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level6
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level7
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level8
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level9
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">In Attendance:  Ben Wilson, Fotis Loukos,
          Travis Graham, Xiu Lei, Robin Alden, Wayne Thayer, Dimitris
          Zacharopoulos, Tim Hollebeek, Neil Dunbar, Tobi Josefowitz,
          Ryan Hurst, Kefeng Chen, Rick Agarwala, Patrick Milot, Colin
          McIntyre<o:p></o:p></p>
        <p class="MsoNormal">Ben noted that the last call was before the
          F2F.  During the F2F, we recapped our progress and explained
          why we are working on what we are.  He explained that we were
          going to try and go to the next item to discuss in the Network
          Security Requirements, but that it might be based on what
          topic was easier to tackle, rather than on the prioritized
          list.<o:p></o:p></p>
        <p class="MsoNormal">Dimitris gave an update on the work of the
          subgroup that has been discussing the threat/risk assessment
          and CA system architecture. Dimitris explained that it was
          hard to participate during the F2F based on technical
          difficulties.  The group has started listing the risks and
          some of the mitigating factors.  The subgroup would like more
          participation.  The subgroup will consider simplifying next
          steps by just documenting basic vulnerabilities and threats
          and omitting the compensating controls for now.  <o:p></o:p></p>
        <p class="MsoNormal">Neil suggested that the subgroup begin
          meeting weekly.  Weekly meetings on Wednesdays (Fridays?) were
          proposed.  Dimitris said that weekly meetings would be fine to
          gain momentum, and then the group could fall back to bi-weekly
          meetings. 
          <o:p></o:p></p>
        <p class="MsoNormal">Tim had proposed that we do threat modeling
          of the CA system with a high-level view of the
          architecture—maybe have two architectures, one for traditional
          and one for cloud and third-party data center arrangements. 
          Neil noted that if a root CA is supposed to be offline, then
          having it cloud-based is virtually impossible. There was
          general agreement that we were really talking about
          third-party data center arrangements, however, Tim said that
          portions of a CA system could be cloud-based.  He said that
          when doing a threat modeling exercise, you have to have an
          adequate description of the system, but when we check with
          CABF members, we’ll likely find that they are some operating
          in a corporate data center where others are operating in
          someone else’s data center, and the properties are somewhat
          different.  There was discussion of the two types of
          environments, and it was agreed that we need to come up with a
          model that works for both corporate data centers and
          collocated facilities.  Dimitris said that they would be
          proceeding with a traditional model first.  Dimitris said at
          the end of the exercise, we’d need to map the current network
          requirements and see how they fit into this architecture.  Ben
          wondered whether  some other group has written up / documented
          what the CA environment is, so that we don’t have to re-create
          the wheel?  Dimitris said it isn’t as important how we sketch
          it out, at the end of the day we’ll be discussing the same
          problems, such as, how do you transfer data, update operating
          systems/software, etc., and that physical security is probably
          the easier part.  Neil said the main issue for him has always
          been, how do you know the state that the system is in when you
          are patching, or whatever.  How do you know that what you did
          to the system had the desired effect?  How do you audit that? 
          Do you have vulnerability scanning for a system that is
          completely offline?  That is unlikely, etc.<o:p></o:p></p>
        <p class="MsoNormal">The group then prioritized the list of work
          items – green (easy to work on), yellow (moderate difficulty),
          and red (difficult), as follows:<o:p></o:p></p>
        <ol style="margin-top:0in" start="1" type="1">
          <li class="MsoListParagraphCxSpFirst"
            style="margin-left:0in;mso-add-space:auto;mso-list:l0 level1
            lfo1">
            Defining "Root CA System", "Offline" and "Air-Gapped" and
            clarifying associated requirements
            <o:p></o:p></li>
          <li class="MsoListParagraphCxSpMiddle"
            style="margin-left:0in;mso-add-space:auto;mso-list:l0 level1
            lfo1">
            <span style="background:lime;mso-highlight:lime">Defining
              terms like "workstation", "account", "zone", "CA System,"
              and "Issuing System" (easy)<o:p></o:p></span></li>
          <li class="MsoListParagraphCxSpMiddle"
            style="margin-left:0in;mso-add-space:auto;mso-list:l0 level1
            lfo1">
            <span style="background:yellow;mso-highlight:yellow">Clarifying
              log review, "human review" of logs vs. automated reviews
              (moderate)<o:p></o:p></span></li>
          <li class="MsoListParagraphCxSpMiddle"
            style="margin-left:0in;mso-add-space:auto;mso-list:l0 level1
            lfo1">
            <span style="background:red;mso-highlight:red">Defining
              "Critical Vulnerability" and "Critical Security Event" and
              clarifying actions to take and clarifying action to take
              within 96 hours of detecting a vulnerability not otherwise
              addressed by CA's procedures (difficult)<o:p></o:p></span></li>
          <li class="MsoListParagraphCxSpMiddle"
            style="margin-left:0in;mso-add-space:auto;mso-list:l0 level1
            lfo1">
            <span style="background:red;mso-highlight:red">Providing
              guidance on the criteria for acceptable penetration tests
              and vulnerability scans (difficult)<o:p></o:p></span></li>
          <li class="MsoListParagraphCxSpMiddle"
            style="margin-left:0in;mso-add-space:auto;mso-list:l0 level1
            lfo1">
            <span style="background:red;mso-highlight:red">Including
              mitigating factors and compensating controls in the NCSSR
              (difficult)<o:p></o:p></span></li>
          <li class="MsoListParagraphCxSpMiddle"
            style="margin-left:0in;mso-add-space:auto;mso-list:l0 level1
            lfo1">
            <span style="background:yellow;mso-highlight:yellow">Penetration
              tests after changes the CA determines are "significant</span>"
            (moderate)<o:p></o:p></li>
          <li class="MsoListParagraphCxSpMiddle"
            style="margin-left:0in;mso-add-space:auto;mso-list:l0 level1
            lfo1">
            <span style="background:yellow;mso-highlight:yellow">Clarifying
              audit documentation requirements for network/system
              configurations (1.f, g, and h) (moderate)
              <o:p></o:p></span></li>
          <li class="MsoListParagraphCxSpMiddle"
            style="margin-left:0in;mso-add-space:auto;mso-list:l0 level1
            lfo1">
            <span style="background:red;mso-highlight:red">Addressing
              software development vulnerabilities and processes
              (difficult)<o:p></o:p></span></li>
          <li class="MsoListParagraphCxSpMiddle"
            style="margin-left:0in;mso-add-space:auto;mso-list:l0 level1
            lfo1">
            <span style="background:lime;mso-highlight:lime">Modifying
              2.j. "review all system account configurations every 90
              days" (easy)<o:p></o:p></span></li>
          <li class="MsoListParagraphCxSpMiddle"
            style="margin-left:0in;mso-add-space:auto;mso-list:l0 level1
            lfo1">
            <span style="background:yellow;mso-highlight:yellow">Addressing
              wireless security vulnerabilities (moderate)<o:p></o:p></span></li>
          <li class="MsoListParagraphCxSpMiddle"
            style="margin-left:0in;mso-add-space:auto;mso-list:l0 level1
            lfo1">
            <span style="background:lime;mso-highlight:lime">Timeframes
              in which to disable system access of former employees
              (currently within 24 hours)</span> (easy)<o:p></o:p></li>
          <li class="MsoListParagraphCxSpLast"
            style="margin-left:0in;mso-add-space:auto;mso-list:l0 level1
            lfo1">
            <span style="background:yellow;mso-highlight:yellow">Password
              rules (currently 12 characters, OR 8 characters + changes
              every 90 days, OR a documented policy) (moderate).<o:p></o:p></span></li>
        </ol>
        <p class="MsoNormal">Ben noted that we could talk about 2.,
          ("workstation", "account", "zone", "CA System," and "Issuing
          System”), but that  it likely falls within the
          architectural/threat modeling.  It was agreed that this issue
          would fit in within the work of that subgroup.<o:p></o:p></p>
        <p class="MsoNormal">Ryan suggested we talk about passwords
          today, 2.g.  There were lots of opinions about the quality of
          passwords required, 8 characters being insufficient, how the
          password provision applies/doesn’t apply to other
          authentication mechanisms, etc.  Ryan suggested we look at
          anti-hammering mechanisms, lockouts, etc.  Dimitris noted that
          the Network Security Requirements already mention lockouts (2g
          and 2k).  Ryan noted that Windows login and TPMs have these
          mechanisms to slow down failed login attempts.  He noted that
          these can cause denial of service, which is OK in a local
          system, but might not be OK as mechanisms with a remote
          system. Ryan suggested that we provide a lot of examples,
          rather than be overly specific so that people can choose
          better solutions. Ben asked whether this meant that we should
          provide more guidance and fewer requirements.  Ryan said that
          there has to be more flexibility in which mechanisms are
          used. 
          <o:p></o:p></p>
        <p class="MsoNormal">Ben noted that discussions of passwords
          might take a lot of time, and maybe we should break this
          discussion off into a subgroup.  Ryan suggested that for
          topics like passwords, subgroups could come back to the group
          with recommendations.  Tim said a useful piece of homework for
          passwords would be for people to read section 5.1.1 of NIST
          800-63b (<a
            href="https://pages.nist.gov/800-63-3/sp800-63b.html"
            moz-do-not-send="true">https://pages.nist.gov/800-63-3/sp800-63b.html</a>). 
          Volunteers for the subgroup included Ryan, Ben, Tim, Robin and
          Fotis.  <o:p></o:p></p>
        <p class="MsoNormal">The group turned its attention to audit
          logging and manual log review.  Sections 3.b to 3.e. were
          reviewed.  Ryan and Ben noted that these sections could be
          reworded so that provisions in 3.c. would encompass parts of
          3.e. (the responsibility for making sure things are
          functioning correctly).   Logging can stop functioning for a
          variety of reasons, e.g. disk failure, and it’s important to
          have processes in place to catch that, but the human review,
          when auditors have interpreted this, they have taken it to
          mean human review of the actual log with an eye to finding
          anomalies.  It’s not realistic for humans to find patterns in
          the data.  So it’s one thing organizations do, but not because
          it adds value.  You need systems in place to identify
          patterns, as stated in subsection c., but you don’t want to
          have humans doing that.  <o:p>
          </o:p></p>
        <p class="MsoNormal">Tobi asked whether the design of subsection
          e. might have been to catch things like classes of messages
          that are not being forwarded to your logging architecture. 
          Ryan said you could have periodic reviews of the design, and
          if that’s the intent, then the requirement should be that you
          have yearly reviews of your logging strategies to ensure they
          are capturing the right things vs. a monthly review of logs. 
          What ends up happening is the new guy is assigned the task of
          doing manual log reviews, which provides no value.  Tobi said
          that he interprets e. to mean that he could glance over the
          log to see that it is operating properly and could spot
          anomalies.  Ryan said that for Let’s Encrypt, with millions of
          log entries daily, you’re never going to see it.  Tobi said
          that he wouldn’t expect to see a single one, but if there is a
          whole class of warnings he would definitely notice them.  That
          was countered with arguments that anomalies would be buried in
          systems where hundreds of subsystems are logging.<o:p></o:p></p>
        <p class="MsoNormal">Ryan said that he thought there ought to be
          someplace in the requirements where we address these issues,
          but that he didn’t think a manual review of an at-scale system
          logs is valuable.  There should be a requirement for
          automation that captures security-sensitive events.  <o:p></o:p></p>
        <p class="MsoNormal">Ben said that e. is really two
          requirements.  One requirement is that the system has
          integrity and the other requirement is to have some human
          review of the log (with the use of an in-house or third-party
          audit log reduction and analysis tool), and maybe we should
          split them up into e. and a new subsection f.   One way to
          edit e. would be to remove language so that it would read,
          “Ensure that application and system logs have integrity and
          are operating properly.”  Then f. could read, “Conduct a human
          review of logs once a month using an in-house or third-party
          audit log reduction and analysis tool.”  However, he said he
          didn’t know whether the latter, human review, was necessary. 
          We want to make this easy, practical and realistic.  If we
          think that this is covered in the previous subsections a-d, we
          could make that edit and just move on.<o:p></o:p></p>
        <p class="MsoNormal">Dimitris said his interpretation of
          subsection e. is that you just have to make sure your systems
          are logging. It doesn’t say anything more about drilling in
          and trying to find if there are any security alerts hidden in
          the logs.  You just need to check once a month that all of
          your critical systems are actually logging, and you can
          automate this process.  Tobi said that you can obviously tell
          if something is not working.  Dimitris said it doesn’t say you
          have to find attacks or any weird activity, which is described
          under subsection c.  <o:p></o:p></p>
        <p class="MsoNormal">Ben said that Dimitris’ reading of e. is
          the logical conclusion, but then e. has stuff about human
          review and log reduction analysis tools, which confuse the
          interpretation.  As the drafter of these requirements, he
          knows that there was an intent to require human review of logs
          using automated tools, but that he isn’t arguing that it was
          the right thing to do, especially when it is causing this
          confusion. By making Ben’s suggested changes, it would ensure
          that Dimitris’ interpretation is carried forward—that the
          system has integrity and is operating properly.  Ben then said
          that if we wanted to, we could go on and talk about human
          review of an audit log using analytical tools, which is an
          extra step that is a lot of work.  Tobi said he didn’t think
          that anyone was expecting anyone to sit down and go through
          massive amounts of log entries—that makes no sense. 
          <o:p></o:p></p>
        <p class="MsoNormal">Ben asked whether we add in a new f. a
          monthly review or do we make the assumption that if you  have
          continuous monitoring, etc., in b. and c. that you have
          already covered what would be provided by a monthly review? 
          Dimitris said he thought we have covered those under b. and
          c., and they are already mandatory.  There was a question as
          to whether we should define what “integrity” means?  Tobi said
          that integrity means that you are getting what you think you
          are getting.  It was then noted that CAs have been asked to
          hash logs, sign logs, stamp logs, etc.  Ryan said he didn’t
          interpret integrity as Tobi did but that integrity means that
          it has not been modified since it was put there, which is
          different than what you put there is what you expected you put
          there.  The word “integrity” was highlighted and it was
          decided that we would pick up again when we reconvened talking
          about the meaning of integrity.<o:p></o:p></p>
        <p class="MsoNormal">Meeting adjourned. <o:p></o:p></p>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Netsec mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Netsec@cabforum.org">Netsec@cabforum.org</a>
<a class="moz-txt-link-freetext" href="http://cabforum.org/mailman/listinfo/netsec">http://cabforum.org/mailman/listinfo/netsec</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>