meta: scope the sig-security presentations to the security model and let the assessor do the presentation?

[ficcaglia]

This is just a raw "meta" dump after the OPA presentation.... it seems to me that during OPA presentation the project prez was more about features. many of the questions were about specific use cases or various corner case behaviors, and the mechanisms of how OPA works in these specific cases.

IMHO neither was really focused on the security model (threats, defenses, etc) of OPA, as-is, per se.

certainly all these specific use cases and behaviors can and should inform the security model and assessment, but I think given the limited time for the group presentation, for future projects perhaps we should be more tightly focused on what the security boundaries are, the security responsibilities the project accepts as in-scope (and what they don't consider in scope), and the various threats and defenses that have been employed? rather than a discussion on how things might be differently designed or implemented.

It seemed to be at times more a debate about the pros and cons of OPA's functionality vs. the security of the already existing functionality. Should the security assessment be a debate about whether the project does a good job at X, or, given it already does X, is it doing X securely. I guess it's a question of whether the assessment is meant to debate the project itself as a useful tool for security in the CN environment, or is the assessment meant to assess the security of the project as-is, regardless of whether the as-is features are the features we as security folks would choose to implement (arguably the larger community has spoken and determined that project X is worthy of use).

Overall I expected to have more time to debate how OPA implements (or not) defenses to mutually agreed in-scope threats, but in the presentation we barely got past the high level use case/feature discussion. I felt that the document (and available supplemental slides or videos from k8s conferences, etc) explained the use cases and features sufficiently, and that everyone attending the presentation would have previously digested these so that any functionality questions are handled offline, before the prez.

I would be so bold as to suggest that perhaps the assessor present - not the project team. I think that will narrow the focus on the security aspects and the assessor's concerns, or commendations, and less the demo of the project functionality and debate about utility/design/approach of the feature set.

Not trying to be negative, though --- I thought the OPA discussion was highly useful overall, and again, this is more meta than critical commentary on OPA or the OPA assessment, per se.

[pragashj]

This is a useful feedback and we have a guide for assessment. It would be useful to have your comments/contribution to make it better there.

[JustinCappos]

I can see the merit in this. Perhaps we can try this approach for one of the upcoming assessments and see if we think it works better. I know I would have struggled to provide some of the context Ash gave about OPA because I do not know the overall project that well.

[ultrasaurus]

In todays OPA Assessment presentation (10/1) we're going to try out a process where project lead presents "left side" (e.g. goal, design, core security analysis, maturity) and a security reviewer presents the "right side" (security risks & recommendations)

(Realize this issue was focused on presentation to SIG-Security, but figured this was relevant to the discussion) I think the format went well today.

[ficcaglia]

I thought it worked very well!

…

On Wed, Oct 2, 2019 at 3:53 AM Sarah Allen ***@***.***> wrote: In todays OPA Assessment presentation (10/1) we're going to try out a process where project lead presents "left side" (e.g. goal, design, core security analysis, maturity) and a security reviewer presents the "right side" (security risks & recommendations) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#162>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACCHAOVL6O6JXZJJ4XVBGNTQMNUPFANCNFSM4HNF3JEA> .

[stale]

This issue has been automatically marked as inactive because it has not had recent activity.

[lumjjb]

This is no longer relevant due to new revamped process: #488