🛡️ Easiest Reg S-P breach notice intake for external services?

[JFWooten4]

We need a 72-hour service-provider breach notice procedure for Regulation S-P compliance under 17 CFR § 248.30(a)(5)(i)(B). The procedure should define when a service provider must notify BlockTransfer of a qualifying breach, how the 72-hour deadline is measured, who receives and escalates the notice, and how BlockTransfer initiates its incident response program after receiving vendor notice.

Subsection (a)(5)(i): Service-provider oversight

A covered institution's response program prepared in accordance with paragraph (a)(3) of this section must include the establishment, maintenance, and enforcement of written policies and procedures reasonably designed to require oversight, including through due diligence and monitoring, of service providers, including to ensure that the covered institution notifies affected individuals as set forth in paragraph (a)(4) of this section.

The policies and procedures must be reasonably designed to ensure service providers take appropriate measures to:

a. Protect against unauthorized access to or use of customer information; and

b. Provide notification to the covered institution as soon as possible, but no later than 72 hours after becoming aware that a breach in security has occurred, resulting in unauthorized access to a customer information system maintained by the service provider. Upon receipt of such notification, the covered institution must initiate its incident response program adopted pursuant to paragraph (a)(3) of this section.

With that basis out of the way, this issue does a couple things:

1. Track progress as I track through the existing arrangements we use, such as [AWS Artifact] Document AWS Reg S-P compensating controls #8.
2. Formulating means of automating notice uptake without a central secretarial role.
3. Place for discussion on initial configuration of remediation action and people.

[JFWooten4]

For 2. - I'd like to think there would be an easy endpoint that's exposed by the major cloud service providers. We could hook that up to a simple bot that makes a new issue somewhere important upon notice (and possibly pings something or someone...).

For smaller or less technical services like email, I think we should refit our operations to remove such service providers from a central chain of investor information. Everyone has the setup now for direct ties through either the investor app, SEP-12 standards, or IssuerLink backend FTP to keep PII or even basic docs out of email or file storage. The latter investor content will need new architecture to drop into S3 processing so we can get the Artifact notice guarantee.

There is some discussion to be had here about whether or not it's a good idea to post a GitHub issue every time one of our service providers has a problem. I think it's a good idea, and here's why:

• Lets the community know when specific providers are falling behind, giving everyone access to the same needed information to propose a replacement or other actions.
• Allows for the public discourse of breach remediation in 🛡️ Add breach assessment procedures #10.
  • This may look a little bad for PR's sake, but it shouldn't risk any investor information as long as logs stay in cloud perms.
  • I agree it is easier to just not let the world know about internal issues, but I also think it's disingenuous to issuer stakeholders who'd have no other way to hold us accountable for something like that.
  • If we use GitHub as the main means of communication, I'm not sure how else we would even chat about something like this.
• Expands the reviewable surface area of action.
  • Consider the alternative of having a group email inbox that pings people from a central service provider.

There's some more to think about here since notice emails could have PII. In our arrangements, we could (i) have them send a general infra email to a specific GitHub bot while specifics go to an internal team member or (ii) specify that they are to create a GitHub issue in X repos even upon a breach. I don't like the former option since it still relies on central operations, and it shouldn't be a problem since the CRONs work is already disclosing database names and cross-configurations.

On the last point, these PRs for Regulation S-P: File No. S7-05-23 Adoption should publicly diagram the operating environments anyway, too. Some of that was submitted confidentially during the review, and initial chats with James show no problem expanding the disclosure ops. We just need to harden the information around who has database keys, separate from the Findering medium-weight signers.

And then having them make an issue is possible, albeit a little dreamy. I could see that route working better with smaller service providers, but we in-house most of the minor roles. Maybe the mail agent or log searching, but I don't think it makes a lot of sense cost-wise to force it onto a large cloud provider who will have standardized systems in place already which are composable with a reliable bot.