Page MenuHomePhabricator

Risk Assessment AHT CU Dev Wiki
Open, MediumPublicSecurity

Description

AHT Checkuser Wiki RA as noted in the current risk register

Event Timeline

chasemp triaged this task as Medium priority.Dec 10 2019, 9:50 PM
chasemp created this task.
chasemp created this object in space Restricted Space.
chasemp created this object with visibility "All Users".
Restricted Application added a project: User-chasemp. · View Herald TranscriptDec 10 2019, 9:50 PM
Restricted Application changed the subtype of this task from "Task" to "Security Issue". · View Herald Transcript

This report will be investigated ASAP or during the next the next weekly triage meeting depending on initial severity interpretation.

chasemp moved this task from Incoming to In Progress on the Security-Team board.Dec 10 2019, 9:51 PM
chasemp shifted this object from the Restricted Space space to the S1 Public space.Dec 12 2019, 5:48 PM

proposed a sync meeting with latest notes at hand. It's unclear to the security team folks the why of some of the requirements.

Aklapper changed the visibility from "All Users" to "Public (No Login Required)".Feb 4 2020, 7:51 PM

We had a meeting today to discuss the possible outcomes and challenges the AHT team is facing here and risks associated with various paths. Scott and I communicated the challenges of not being able to test with mock data, and/or having a 'test harness' ability to populate deterministic patterns of expected user artifacts for QA or integration testing. My understanding is the AHT team now sees the potential need for mocking data, but mocking only reaches a level of QA certification that encompasses known known and not known unknown in the greater realm of functionality.

The technical hurdles to maintaining long lived static point in time copies of large wikis when combined with the privacy policy concerns of long lived sensitive data sets are large. The tentative proposal may involve a distinct global group with limited membership that has access to a feature flag restricted set of functionality. Along with the understanding that audit is an integral part of preserving the integrity of our PP and of nonrepudiation requiring the usual logs for any discovery or search may be the best plan of action here. In part this depends on the expected maturity level of code involved at the time of deployment as a frontend to protected data, overall maturity model, and the effectiveness of gating controls.

Action items:

  • Update the in-progress RA doc with newer info
  • schedule followup meeting to discuss more specifics if questions remain (Expected)

Action items:
Update the in-progress RA doc with newer info
schedule followup meeting to discuss more specifics if questions remain (Expected)

email to trust and safety

tdlr; Got time for a meeting to talk about CU usage in regards to CU dev efforts regarding appropriateness the feasibility of audit and who would be the best person to talk with?
The Security Team is currently performing a risk assessment on future plans for AHT=>CU development and improvement. At some point in the maturity cycle CU checks are required on prod wikis. It's my understanding some of this is being done on test wiki now by staff, and that individual wiki communities may have their own sub-norms about the usage of CU.
Does anyone from Trust and Safety have a few minutes to talk this out with me to ensure that the plans building momentum are going to be tenable? I worry about increased CU traffic making the current audit procedures more expensive, and other inadvertent possibilities for violations of community norms. My sense is this can all be worked out but I wanted to get your perspective on things early.

chasemp updated the task description. (Show Details)Feb 24 2020, 7:16 PM

trusa meeting scheduled for 2/26/2020