sbassett added a comment.
Hey all- We've received the security review request (T292110 <https://phabricator.wikimedia.org/T292110>) for this and will plan to include it within our review planning session this week (whether it's accepted for the quarter as-is or not is a separate matter to be determined). Responding to a few issues: In T285098#7262291 <https://phabricator.wikimedia.org/T285098#7262291>, @Joe wrote: > First of all, I want to say that IMHO things would have gone smoother if you asked SRE for an opinion about the plan before it was put in motion. Keep this in mind for the future. Same for the #security-team <https://phabricator.wikimedia.org/tag/security-team/>. The earlier we have some general idea of an architecture and code base, the better we can offer guidance on how to successfully get something through a security review. Even a simple RFS form submissions or email to security-help@ <https://www.mediawiki.org/wiki/Wikimedia_Security_Team#Contacting_Us> with a sketch of the project very early in the process can be helpful and hopefully avoid unpleasantness at a much later date, which is painful for everyone involved. And unfortunately, this has to be a proactive process for engineering teams, as our team literally cannot monitor every conversation that happens on Phab, gerrit, wikitech, meta or mediawiki.org. > Having said that, we don't usually allow any request to flow from production services to services running in WMCS for a few good reasons, regarding reliability, privacy, and security. I don't think we've ever made an exception to this rule, and I don't think we should make one in this case - but this is my own personal opinion. The #security-team <https://phabricator.wikimedia.org/tag/security-team/> would likely rate something like this {icon exclamation-triangle color=orange} **high risk** by default (requires c-level/leadership risk acceptance), without additional assurances and some type of mitigation plan. > I would say that **a security review cannot be skipped **... Confirmed. In T285098#7262893 <https://phabricator.wikimedia.org/T285098#7262893>, @Addshore wrote: > However tying this into the precedent mentioned above, I highly doubt that external services that we call get a security review of their code etc, but indeed perhaps for the requests & responses and general risk. The most they'd likely get in terms of a direct review is a supplier review <https://office.wikimedia.org/wiki/Security/Policy/Supplier_and_Partner_Security_Addendum> (apologies as I know most folks can't see that) and/or a third party review <https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Third_Party_Code_Review_Checklist>. But we would certainly look heavily into the contexts in which they were being used by Wikimedia production services, MediaWiki extensions, etc. e.g. a small amount of public, read-only data vs. read/write of sensitive data. > Services running on WMCS (the Service we want to use in A/B testing) and routine Gerrit changes (which were made to the property suggestor extension) are also listed as things unlikely to get a review https://www.mediawiki.org/wiki/Security/SOP/Security_Readiness_Reviews Correct, which is why we'd echo the advice of pursuing this as a proper Wikimedia production service. > To then run a 1 month A/B test and then turn the service off / undeploy it, evaluate the A/B result and potentially not deploy the service again. > Then I feel that we would have unnecessarily spent a whole lot of resources for the year and probably extended the timeline of this A/B test by 6 months or so (I could be wrong). The other side of this reasoning is that performing end-runs around processes put in place to get something into Wikimedia production exposes the Foundation, WMDE and the community to a much larger potential attack surface and greater risk profile. Our current risk management framework doesn't really want to be in the business of being a hard blocker for anything but rather pushes for their to be a proper understanding of risk and a thoughtful acceptance of risk at various levels across organizations and the community. > In T285098#7262378 <https://phabricator.wikimedia.org/T285098#7262378>, @Ladsgroup wrote: > >> (Not speaking on behalf of the team, completely personal): >> I see three way out that we could talk about and decide: >> >> - Get SRE/Security/Legal approval for a temporary deployment of reading for wmcs. One idea I have to ease and compromise is to have a fixed deadline. e.g. "This will stay in production no more than 30 days" This would reduce the risk. The actual number should be decided by PM and the rest. > > To me this seems quite reasonable, and probably a much smaller investment of people time into such an A/B test than trying to fulfil a full deployment to production that we may just undo. > I believe this is probably something like the process for previous such external calls (if we can frame a WMCS call as external) This might be possible, but it also feels like an exceptional path that a lot of other ad hoc projects will pursue once the precedent exists. TASK DETAIL https://phabricator.wikimedia.org/T285098 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: sbassett Cc: sbassett, WMDE-leszek, kostajh, karapayneWMDE, Joe, Ladsgroup, Ottomata, Lucas_Werkmeister_WMDE, Martaannaj, Michaelcochez, Michael, Addshore, Aklapper, Suran38, Biggs657, Invadibot, Lalamarie69, maantietaja, Juan90264, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, Iflorez, Kent7301, alaa_wmde, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Sjoerddebruin, Mbch331
_______________________________________________ Wikidata-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
