Agenda

• Security

• Retrieving a document’s ID only

• Uniform Resource ID for integrations

Materials

Open

Participants

Discussion

Security

• Ideas and suggestions from the discussion:

  • Potentially useful term: “elevating best practices” puts more emphasis on the best practices coming from elsewhere.

  • Regularly ask the community about what they’re seeing in operations, gather reports, curate, share back with the community. To the extent that people are comfortable sharing about their deployment topologies.

  • Workgroup of security officers from the states?

• Rate limiting

  • Also, unintentional (not malicious) Denial of Service from vendors.

  • Can the Discovery API show the rate information? Vendors only hear informally from states what the expected rates are.

  • TEA is the only one with the token rate limiting.

  • Vendors don’t want several different ways of handling rate limiting.

  • But there is a distinction: TEA is throttling for performance reasons. For security reasons, would not want to publish rate limits. Imagine a bad actor who slows their attack to just under the detection rate.

  • Opportunity to provide more guidance & best practices on handling rate limiting on both sides of the equation.

• Large scale implementations often have federated sign-ins, where the hosting agency does not have control over enforcing MFA on the source system authentication providers.

• Certification

  • Yes from one person: ask how vendors are obfuscating credentials, in both storage and display. Some source systems allow users to see and copy the Ed-Fi API credentials.

  • Comment that Admin API helps automate quick replacement of credentials when they are compromised.

  • Would there be different requirements for MSPs and integration partners? Maybe additional badging around SOC-2, FedRamp, TexRamp, penetration testing?

    • SOC-2 needs verifiable reporting, not just self assertion.

  • Certification should ask for a bare minimum level of security, and make it clear that this is truly “bare minimum” - less than what is actually recommended.

  • Are you protecting your own application’s credentials with proper hashing? Are you cycling your own tokens rather than trying to use tokens forever?

    • Editor’s note: good questions… as these are more about the security of the partner’s systems, not just protection of the Ed-Fi integration, do they go too far?

  • Rate limit is a best practice, not a certification topic.

  • Multiple source system vendors spoke encouragingly about this notion of asking security questions during certification.

  • What type of mechanisms could alert the broader community of threats others have run into (perhaps recurring?)

• Provide a security checklist for integrators?

  • CIS benchmarks

• Monitoring

  • Any logging stack should ideally have database errors in addition to the application logs.

  • Nice to have logging tied to credentials to identify individual integrations that may be “misbehaving.”

ID only retrieval

• Field selectors as an alternative: harder to code for arbitrary field selectors.

• Recommendation: make this is a different endpoint instead of a query string parameter, since the response has a different shape. i.e. GET /ed-fi/students/identifiers?<same query string parameters>

UniformID

• Decentralized Id’s (DIDs) - which take advantage of zero knowledge proofs.

• There might be something here, but need a more clear understanding of the pieces and how to utilize them.