From ndunbar at trustcorsystems.com Mon Aug 3 07:38:59 2020 From: ndunbar at trustcorsystems.com (Neil Dunbar) Date: Mon, 3 Aug 2020 15:38:59 +0100 Subject: [cabf_netsec] Draft Agenda for NetSec 2020-08-06 0900 PST/1200 EST/1700 BST/1800 CEST Message-ID: <2e9c1240-5053-fc54-c795-4f7c01f7aa6a@trustcorsystems.com> All, This is the planned agenda for this week's meeting. As alway, do let me know if any changes are required. Regards, Neil +------+-------+-------+------+--------------------------------+---------+ | Time | Start | Stop? | Item | Description??????????????????? |Presenter| +------+-------+-------+------+--------------------------------+---------+ | 0:02 | 17:00 | 17:02 |??? 1 | Review Agenda????????????????? |Neil???? | +------+-------+-------+------+--------------------------------+---------+ | 0:03 | 17:02 | 17:05 |??? 2 | Agree Minutes???????? ? ? ? ?? |Neil???? | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:05 | 17:09 |??? 3 | Pain Points Subgroup Update??? |David??? | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:10 | 17:15 |??? 4 | Threat Modelling SG Update???? |Mariusz? | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:15 | 17:20 |??? 5 | Document Structuring SG Update |Ben????? | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:20 | 17:25 |??? 6 | Account Management Ballot |Tobi???? | +------+-------+-------+------+--------------------------------+---------+ | 0:10 | 17:25 | 17:35 |??? 7 | Authentication (Lockout) Ballot|David | +------+-------+-------+------+--------------------------------+---------+ | 0:10 | 17:35 | 17:45 |??? 8 | Offline CA Ballot ????? |Ben | +------+-------+-------+------+--------------------------------+---------+ | 0:10 | 17:45 | 17:55 |??? 9 | Other Ballots ? ?? ???????? | | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:55 | 18:00 |?? 10 | Any Other Business???????????? |???????? | +------+-------+-------+------+--------------------------------+---------+ |????? |?????? | 18:00 |?? 11 | Adjourn??????????????????? ??? |???????? | +------+-------+-------+------+--------------------------------+---------+ From bwilson at mozilla.com Thu Aug 6 12:09:30 2020 From: bwilson at mozilla.com (Ben Wilson) Date: Thu, 6 Aug 2020 13:09:30 -0600 Subject: [cabf_netsec] SCXX: Offline CA Security Requirements In-Reply-To: References: Message-ID: Thanks, Pavan, Here is another draft: Replace 1.c. with " Maintain Root CA Systems in a High Security Zone and as Air-Gapped CA Systems, in accordance with Section 5;" Add definition of "Air-Gapped CA System" as " A system that is kept offline or otherwise air-gapped and separated from other systems used by a CA or Delegated Third Party in storing and managing CA private keys and performing signing and logging operations." Add a new Section 5 - 5. GENERAL PROTECTIONS FOR AIR-GAPPED CA SYSTEMS This Section 5 separates requirements for Air-Gapped CA Systems into two categories--logical security and physical security. *Logical Security of Air-Gapped CA Systems* Certification Authorities and Delegated Third Parties SHALL implement the following controls to ensure the logical security of Air-Gapped CA Systems: a. Review static configurations of Air-Gapped CA Systems at least on an annual basis to determine whether any changes violated the CA?s security policies; b. Follow a documented procedure for appointing individuals to Trusted Roles on Air-Gapped CA Systems; c. Grant logical access to Air-Gapped CA Systems only to persons acting in Trusted Roles and require their accountability for the Air-Gapped CA System's security; d. Document the responsibilities and tasks assigned to Trusted Roles and implement "separation of duties" for such Trusted Roles based on the security-related concerns of the functions to be performed; e. Ensure that an individual in a Trusted Role acts only within the scope of such role when performing administrative tasks assigned to that role; f. Require employees and contractors to observe the principle of "least privilege" when accessing, or when configuring access privileges on, Air-Gapped CA Systems; g. Require that all access to systems and offline key material can be traced back to an individual in a Trusted Role (through a combination of recordkeeping, use of logical and physical credentials, authentication factors, video recording, etc.); h. If an authentication control used by a Trusted Role is a username and password, then, where technically feasible require that passwords have at least twelve (12) characters; i. Review logical access control lists at least annually and deactivate any accounts that are no longer necessary for operations; j. Enforce Multi-Factor Authentication OR multi-party authentication for administrator access to Air-Gapped CA Systems; k. Identify those Air-Gapped CA Systems capable of monitoring and logging system activity and enable those systems to continuously monitor and log system activity. Back up logs to an external system each time the system is used or on a quarterly basis, whichever is less frequent; l. On a quarterly basis or each time the Air-Gapped CA System is used, whichever is less frequent, check the integrity of the logical access logging processes and ensure that logging and log-integrity functions are effective; m. On a quarterly basis or each time the Air-Gapped CA System is used, whichever is less frequent, monitor the archival and retention of logical access logs to ensure that logs are retained for the appropriate amount of time in accordance with the disclosed business practices and applicable legislation. n. Reserved for future use o. Reserved for future use *Physical Security of Air-Gapped CA Systems* Certification Authorities and Delegated Third Parties SHALL implement the following controls to ensure the physical security of Air-Gapped CA Systems: p. Grant physical access to Air-Gapped CA Systems only to persons acting in Trusted Roles and require their accountability for the Air-Gapped CA System?s security; q. Ensure that only personnel assigned to Trusted Roles have physical access to Air-Gapped CA Systems and multi-person access controls are enforced at all times; r. Implement a process that removes physical access of an individual to all Air-Gapped CA Systems within twenty four (24) hours upon termination of the individual?s employment or contracting relationship with the CA or Delegated Third Party; s. Implement video monitoring, intrusion detection, and prevention controls to protect Air-Gapped CA Systems against unauthorized physical access attempts; t. Implement a Security Support System that monitors, detects, and reports any security-related configuration change to the physical access to Air-Gapped CA Systems; u. Review all system accounts on physical access control lists at least every three (3) months and deactivate any accounts that are no longer necessary for operations; v. On a quarterly basis or each time the Air-Gapped CA System is used, whichever is less frequent, monitor the archival and retention of the physical access logs to ensure that logs are retained for the appropriate amount of time in accordance with the disclosed business practices and applicable legislation. w. On a quarterly basis or each time the Air-Gapped CA System is used, whichever is less frequent, check the integrity of the physical access logging processes and ensure that logging and log-integrity functions are effective. On Mon, Jun 29, 2020 at 2:47 PM Chander, Pavan wrote: > Hi Ben, > > > > I notice there aren?t any changes to 1.c in your diff. Just wanted to > check if that was a purposeful omission? > > > > Now that your proposed wording defines Offline CA Systems as air-gapped, > perhaps requirement 1.c about Root CAs being in either ?offline state OR > air-gapped? should be updated to either say ?offline AND air-gapped? or > something similar to ?Maintain Root CA Systems in a High Security Zone as > an Offline CA System?? > > > > Pavan > > > > *From:* Netsec *On Behalf Of *Ben Wilson > via Netsec > *Sent:* Monday, June 29, 2020 12:14 PM > *To:* CABF Network Security List > *Subject:* [EXT] [cabf_netsec] SCXX: Offline CA Security Requirements > > > > The Document Structure subgroup (Tim Crawford, David Kluge, and myself) > met this morning and finalized the following ballot. We need a proposer > and two endorsers: > > > > > https://github.com/cabforum/documents/compare/095fc4f7992dbd186503a4b0ec4e643ae4ea1624...BenWilson-Mozilla: > 99ea75f4ad19c58a7f9eb2829e63fb1678a838fa > > > > > Thanks, > > > > Ben > > *Confidentiality Warning:* > > *Deloitte refers to a Deloitte member firm, one of its related entities, > or Deloitte Touche Tohmatsu Limited (?DTTL?). Each Deloitte member firm is > a separate legal entity and a member of DTTL. DTTL does not provide > services to clients. Please see *www.deloitte.com/about* to learn more.* > > *This message and any attachments are intended only for the use of the > intended recipient(s), are confidential, and may be privileged. If you are > not the intended recipient, you are hereby notified that any review, > retransmission, conversion to hard copy, copying, circulation or other use > of this message and any attachments is strictly prohibited. If you are not > the intended recipient, please notify the sender immediately by return > e-mail, and delete this message and any attachments from your system. Thank > You.* > > *If you do not wish to receive future commercial electronic messages from > Deloitte, forward this email to *unsubscribe at deloitte.ca > > *Avertissement de confidentialit?:* > > *Deloitte d?signe un cabinet membre de Deloitte, une de ses entit?s li?es > ou Deloitte Touche Tohmatsu Limited (DTTL). Chaque cabinet membre de > Deloitte constitue une entit? juridique distincte et est membre de DTTL. > DTTL n?offre aucun service aux clients. Pour en apprendre davantage, voir * > www.deloitte.com/ca/apropos*.* > > *Ce message, ainsi que toutes ses pi?ces jointes, est destin? > exclusivement au(x) destinataire(s) pr?vu(s), est confidentiel et peut > contenir des renseignements privil?gi?s. Si vous n??tes pas le destinataire > pr?vu de ce message, nous vous avisons par la pr?sente que la modification, > la retransmission, la conversion en format papier, la reproduction, la > diffusion ou toute autre utilisation de ce message et de ses pi?ces jointes > sont strictement interdites. Si vous n??tes pas le destinataire pr?vu, > veuillez en aviser imm?diatement l?exp?diteur en r?pondant ? ce courriel et > supprimez ce message et toutes ses pi?ces jointes de votre syst?me. Merci.* > > *Si vous ne voulez pas recevoir d?autres messages ?lectroniques > commerciaux de Deloitte ? l?avenir, veuillez envoyer ce courriel ? > l?adresse *unsubscribe at deloitte.ca > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndunbar at trustcorsystems.com Tue Aug 18 01:18:21 2020 From: ndunbar at trustcorsystems.com (Neil Dunbar) Date: Tue, 18 Aug 2020 09:18:21 +0100 Subject: [cabf_netsec] Agenda for NetSec meeting 2020-08-20 0900 PST/1200 EST/1700 BST/1800 CEST Message-ID: All, This is the notional agenda for Thursday's meeting. I've left out the Threat Modelling section, since Mariusz's email suggesting recommencement in September, and added a discussion segment for "what would a Cloud CA look like from an NSR/audit perspective?" Any changes/suggestions/etc, let me know. Thanks, Neil +------+-------+-------+------+--------------------------------+---------+ | Time | Start | Stop? | Item | Description??????????????????? |Presenter| +------+-------+-------+------+--------------------------------+---------+ | 0:02 | 17:00 | 17:02 |??? 1 | Review Agenda????????????????? |Neil???? | +------+-------+-------+------+--------------------------------+---------+ | 0:03 | 17:02 | 17:05 |??? 2 | Agree Minutes???????? ? ? ? ?? |Neil???? | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:05 | 17:10 |??? 3 | Pain Points Subgroup Update??? |David??? | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:10 | 17:15 |??? 4 | Document Structuring SG Update |Ben????? | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:15 | 17:20 |??? 5 | Account Management Ballot |Tobi???? | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:20 | 17:25 |??? 6 | Authentication (Lockout) Ballot|David | +------+-------+-------+------+--------------------------------+---------+ | 0:10 | 17:25 | 17:35 |??? 7 | Offline CA Ballot ????? |Ben | +------+-------+-------+------+--------------------------------+---------+ | 0:20 | 17:35 | 17:55 |??? 8 | Cloud CA discussion?? ???????? |Neil | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:55 | 18:00 |?? 9 | Any Other Business???????????? |???????? | +------+-------+-------+------+--------------------------------+---------+ |????? |?????? | 18:00 |?? 10 | Adjourn??????????????????? ??? |???????? | +------+-------+-------+------+--------------------------------+---------+ From ndunbar at trustcorsystems.com Thu Aug 20 10:08:25 2020 From: ndunbar at trustcorsystems.com (Neil Dunbar) Date: Thu, 20 Aug 2020 18:08:25 +0100 Subject: [cabf_netsec] DRAFT minutes for NetSec meetings: 2020-08-06 and 2020-08-20 Message-ID: <71eaaea5-8211-db71-e59f-399a84cb55f0@trustcorsystems.com> All, I've drafted minutes for the meeting on the 6th August and from today's meeting. The 6th August one was compiled on the 7th August, but my swiss cheese brain forgot to actually send it to the list :-(. Anyway, as always, comments/adjustments gratefully received. Thanks, Neil ===============2020-06-08========================= Minutes of NetSec Meeting : 2020-08-06 Present: Neil Dunbar (TrustCor) [Chair] Corey Rasmussen (OATI) Tim Crawford (BDO) Daniela Hood (GoDaddy) Clint Wilson (Apple) Ben Wilson (Mozilla) Trevoli Ponds-White (Amazon) David Kluge (Google) Dustin Hollenback (Microsoft) Tobias Josefitz (Opera) Janet Hines (SecureTrust) Tomofumi Okubo (DigiCert) Aaron Poulsen (DigiCert) Apologies: Mariusz Kondratowicz (Opera) 1. Review Agenda The agenda was approved, although since Mariusz was absent, the Threat Modelling section was donated to Pain Points. 2. Agree Minutes The previous minutes were agreed. 3. Pain Points Subgroup Update David reported that the team had worked through their ballot backlog, with the authentication controls ballot being the only one requiring further work. The question which followed was "what next?", to see what areas required further attention. One item was an attempt to clarify the NSRs regarding critical vulnerabilities, following from a request from Entrust Datacard at the beginning of thePain Points team establishment. While a draft ballot was prepared, but not shared, the team were wondering if there was still interest in pursuing this area, or whether the team should move on. The next item considered was the definition of "firewall events". While ballot SC28 alleviates some of the definition challenges, the team wondered if it was possible to go a little further. The consensus was that it is very difficult to define what a "security firewall event" was or what their practical relevance was. The team further considered that it might be possible to take other approaches to firewall event logging, rather than looking for a priori "security events", to take a shorter window approach of logging everything, then overwriting after a time. [ND - presumably using the information written to detect anomalies in network behaviour?] After considering those tactical points, the team considered medium to long term strategies. One focus might be to look towards access management in detail, specifically how the principle of least privilege could be codified, as well as segregation of duties. The team then looked at the longer term vision of how a CA system should look in a few years time - specifically what a "Cloud CA" might look like and how that would integrate with the NSRs. Today, they would not, but there might be work to do in order to make such technology meet up with the requirements of the NSRs in the future. Neil commented that a lot of CAs use cloud providers at the moment, but maintain them at arms length, since a generic CA could not inspect a cloud provider's data centre and processes in order to pass the basic audit requirements. David agreed that many CAs use cloud services, like logging, databases and so on. The consideration was whether CAs could use container environments, and Cloud HSMs. For the moment, it's unthinkable - but in a few years time it might work. Neil said that it was a fascinating area to explore, but that the individual meetings were too infrequent to consider this, and perhaps a separate working document would be a good base point, asking the questions of "what stops us doing Cloud CA today" and then "what would be needed to make it happen". David said that he was happy for that approach to be taken. Neil said that it seemed like a long term project, which might not be a Pain Point. David agreed that it was more of a general CA architecture discussion than a true Pain Point. 4. Threat Modelling Subgroup Update This agenda item was skipped. 5. Document Structuring Subgroup Update Ben reported that there wasn't a lot of progress made so far. The Offline CA document is still in preparation - a comment had been received in June which needs to be addressed. David had asked for a little more time on to check some points before endorsing the ballot, but that he was now satisfied that it is ready to proceed. One comment that had been received was that in 1(c), we had proposed no modifications to the requirement that the CA maintain the CA equipment in High Security Zones in an offline and airgapped state. Ben wondered if we should make the change to assert that the requirement should be made to match in accordance with Section 5 (being the new Offline CA section) Neil asked whether we were using the term "offline" to be interchangeable with "airgapped", or did we mean it as being "normally powered down". Ben replied that it was indeed meant to mean "airgapped". Trev asked Neil if it might be better to use the term "airgapped" instead of "offline". Neil replied that he was simply asserting that there is confusion around that term, but that if the definition in the document is clear, he had no problem with its use. Trev advocated that we use airgapped, because it's clear what it means. Ben then asked to what degree we eliminate "offline" in the document, or do we use the defined term Offline to indicate airgapped. Neil pointed out that in 1(c), offline is specified as an alternative to airgapped, albeit that its not using a defined term. Ben said that we could amend 1(c) to say that "Root CAs shall be maintained as an Offline CA System in accordance with Section 5". Neil thought that currently 1(c) says that you could have Root CAs on a network but in a normally powered down state (as opposed to airgapped); he would be fine with a requirement to have Root CAs specified to be airgapped only. Trev said that offline equipment still comes with a need to periodically validate it, since it would not be amenable to continuous monitoring. Ben then asked if we should simply replace offline with airgapped. Tomofumi replied that offline was a term for the CA industry, whereas airgapped is a networking term. He thought we should keep "offline" but be clear that it encompasses a definition of "airgapped". Tim said that the more he thought about it, the less useful the term "offline" becomes, since to bring it online, you need to airgap it. Tomofumi suggested that "online" doesn't mean it's "on" - it means it's connected to the Internet, which is undesirable. Neil replied that "offline", to him, meant that there is no possible path to the equipment to a hostile network, and that offline meant that no connection to any other network other than its own local area is possible (whether via Bluetooth or some other method). Neil asked, for the purposes of understanding, given that Root CAs need to be in a offline state, was there any other CA system which would live in an offline, airgapped state. Ben replied that a CA using pathLen 1 could be an example of that. Trev asked if Neil was asking whether he was suggesting that we just use "Root CA System" rather than "Offline CA". Neil indicated that he was, but Ben replied that there are other CA systems which could live in that offline state. Trev then said we would be defining a Root CA by what its security controls were, rather than its function. Tomofumi said that it wasn't just root CA operations - generation of keys for intermediate CAs happens there, as well as signing their certificates. Neil asked if this were true - is there something which prohibits key generation for intermediate CAs on an online system? Ben then said that he was happy to change 1(c) as above, and then seek two endorsers. We held a straw poll to determine whether we should keep the term offline or use airgapped. The end result was a narrow majority in favour of "airgapped". There has been a little progress made on the eliminations of the Zone terminology. David also mentioned that was a provision on the logical security aspect which required further discussion. Ben replied that indeed, there had been a pivot towards a more logical security outlook with respect to the Zones ballot. Neil mentioned that, in respect of communications with Dimitris, what should be done with the pace of ballots, and that Dimitris had indicated that we might like to propose pre-ballots to the SCWG for discussion before they become formal ballots, to gain more insight on issues arising from proposed changes. The other proposal was to keep it in circulation in NetSec for longer, but that he (Neil) was not a fan, since it meant circling the drain a lot more, covering no new ground. Neil asked Ben what he wanted to do with the Offline CA ballot. Ben replied that he would consult the SCWG with the document as a pre-ballot. 6. Account Management Ballot Neil asked Tobi if the Account Management ballot was ready to go. Tobi thought that it was, although he noted Dimitris request. Neil said that ultimately, it was Tobi's ballot and he would support putting it forward. Neil thought that it was pretty small and self contained; although Tobi thought that it could be interpreted as being further reaching than it was. Neil said that the ballot didn't really impose new duties, other than to say that if a CA is performing continuous monitoring, that monitoring was required to cover account provision and decommisioning. Tobi said that while we in NetSec might know that, the document could do with a bit more explanation to cover misapprehension as to the duties imposed by the ballot. Neil asked Tobi if he could grab a ballot number from the wiki, since he had two endorsers. Tobi edited the wiki page and associated the ballot with SC34. 7. Authentication (Lockout) Ballot Neil asked David if we still needed a redline for that ballot. David agreed, but also needed endorsers. Neil said that he was still happy to endorse. Neil asked whether David could propose the ballot, if not the voting member for Google. After a short discussion regarding the term Voting Member, David said that it was fine, he could propose, but Ryan S would vote for Chrome. 8. Offline CA Ballot There was no need for further discussion. 9. Other Ballots There was no other ballots to discuss. 10. Any Other Business There was no other business. 11. Adjourn The meeting was adjourned and will recommence on 2020-08-20. ===============2020-06-20========================= Minutes of NetSec Meeting: 2020-08-20 Participants: Neil Dunbar (TrustCor) [Chair] Ben Wilson (Mozilla) Bruce Morton (Entrust Datacard) Dustin Hollenback (Microsoft) Tim Crawford (BDO) Trevoli Ponds-White (Amazon) Tobias Josefowitz (Opera) Aaron Poulsen (DigiCert) David Kluge (Google) Apologies: Mariusz Kondratowicz (Opera) 1. Review Agenda The agenda was agreed. 2. Agree Minutes Neil explained that owing to an oversight, the last minutes were not sent out (though they were prepared); they would be considered at the next meeting along with the current minutes. 3. Document Structuring Ben reported that the Offline CA document ready for pre-ballot discussion on the larger SCWG. He didn't have two endorsers, but both Trev and Neil commented that because it's a pre-ballot discussion, that's not needed. 4. Pain Points Ben and David confirmed that Threat Modelling team is being asked to consider equivalent network controls to avoid relaxation of rules in logical zoning versus physical zones, perhaps taking from the Cloud Security Alliance controls as indicated by comments by David in the Zone Removal document. David reported on the last Pain Points meeting. There was some discussion on the phishing revocation talk on mozilla.dev.security.policy, even if that wasn't strictly a pain point. David brought up the critical vulnerability discussion, which had begun with Tim, as to when the 96 hour window for remediation should start, and that the discussion had moved onto what the scope of the vulnerability scanning should be. Specifically "private" vs "public" IP addresses; it was considered that such a distinction might not be meaningful boundary from a security scanning perspective. The Authentication Lockout ballot now has a redline, so discussion can continue on this. 5. Account Management Ballot Tobi confirmed that he is ready to go with ballot SC34, but that he was double checking the GitHub rules so that the redline met all the guidelines for the SCWG process. Once this is done, he will be submitting the ballot for SCWG discussion. 6. Authentication (Lockout) Ballot This was covered in the Pain Points section. 7. Offline CA Ballot On the process of the Offline CA ballot, Ben did express some confusion with regard to the heartbeat rules, saying that it makes things easy to lose via the 21 day rule; but the old 7 day rule was too short. Bruce said that pre-ballot discussion was the method used in the past to avoid heartbeating, and the 7 day rule didn't impact as much because of the fact that the discussion had already taken place. Trev indicated that she would want to see at most one heartbeat, then things go into discussion. Neil said that on September 1, SC28 will go into a 7 day discussion phase followed by a 7 day voting period. Trev commented that the Byelaws were probably not meant to cope with pandemics. 8. Cloud CA Discussion Neil put forward a draft discussion document on the integration of CAs with Cloud Service providers. It is just a set of notes at this point, and needs structure; it is not meant as a ballot source, since there will be many views on even the desirability of running CA operations via cloud providers. The document is available on the Google Drive, and Neil asked for contributions and edits to help shape the discussion, and that he would leave discussion time open if the team decided it was worth taking this long term effort further. 9. Any Other Business There was no other business to discuss. 10. Adjourn The meeting was adjourned and will reconvene on 2020-09-03 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwilson at mozilla.com Mon Aug 24 09:45:15 2020 From: bwilson at mozilla.com (Ben Wilson) Date: Mon, 24 Aug 2020 10:45:15 -0600 Subject: [cabf_netsec] Invitation to Threat Modeling Discussion on Additional Network Security Controls Message-ID: For the reasons outlined below, we need each CA to send someone knowledgeable about network security to our next Threat Modeling subgroup meeting, to be held on Thursday, Sept. 3rd, at 1:00 p.m. Eastern Daylight Time (1700 UTC). Please send me and Mariusz the name of someone who can attend and we'll send them an invite. In recent meetings of the NetSec group and the Document Restructuring subgroup we have discussed the "Zones" Ballot. We have referred some discussion to the Threat Modeling subgroup. Specifically, how do we handle the replacement of NCSSR section 1.e., which currently reads, "Implement and configure Security Support Systems that protect systems and communications between systems inside Secure Zones and High Security Zones, and communications with non-Certificate Systems outside those zones (including those with organizational business units that do not provide PKI-related services) and those on public networks"? The proposed replacement ("Implement and configure Security Support Systems to secure communications and protect Certificate Systems from attacks emanating from non-trusted networks")has been criticized as too weak. Can we add additional controls to address this issue? 1 - We have discussed authentication and encryption as preventative measures, and continuous monitoring as a detective measure. (E.g. what is meant by "fully authenticated", "end-to-end encryption", etc., and are there standards that use similar language which might be helpful?) 2 - We hope to focus on cloud-based networking security controls and similar situations where a common internal network needs to protect highly sensitive CA processes. 3 - Aside from user authentication, I also have a concern about the authentication/system access by non-user system accounts and system processes. How do we protect them from being hijacked? Should this be part of the discussion, too? In sum, how can we modify section 1.e. so that it adequately protects against network-based attacks? Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwilson at mozilla.com Wed Aug 26 11:51:13 2020 From: bwilson at mozilla.com (Ben Wilson) Date: Wed, 26 Aug 2020 12:51:13 -0600 Subject: [cabf_netsec] Discussion of Draft of SC34 Ballot Account Management Message-ID: For those not aware, there is an ongoing discussion of the draft of Ballot SC34 Account Management here: https://github.com/cabforum/documents/pull/210 -------------- next part -------------- An HTML attachment was scrubbed... URL: