Security/Meetings/2011-11-23

MozCamp Asia recap

• Great success all round
  • Smaller than Berlin from what I've heard, but lots of interactions nonetheless
• Gary's talk, "Fuzzing at Mozilla", was a success too
  • About 10-15 attended, ppl from China, Taiwan, Malaysia attended
  • Questions included:
    • Number of fuzzing machines
    • How do we restart the binaries after they have crashed
  • Call for help made

Security Interaction

• MDN articles?
  • http://developer.mozilla.org/en/Security is sparse
  • For example, we should have MDN articles about fuzzing
• suggested schedule
  • 1 Monday Mtg/mo
  • 1 Brownbag/mo
    • can be us but can also be outside speakers, need help for ideas and how to approach
    • is there a budget, e.g. for providing food, or travel for speakers? -> case by case basis
• [Jesse] I'd rather see more blog posts. They're more inclusive and provide better avenues for feedback. Talking at the Monday meeting just bores people.
  • [imelven] +1 to blog posts
  • [curtisk] if blog then these should be on our official blog - good point
• "hack of the month"
  • discuss the hack, the failure, how to avoid
• Ian could talk/write about the “team embedding” thing
• [decoder] Post puzzles/riddles for readers to solve`
• [action item curtisk]
  • get hack of the month in Dec for Jan
  • get puzzle by EOM Dec -> publish 1st week Jan
  • work with imelven on lightening talk
  • get list of possible sec blog topics be EOM Dec
• We're quieter than Microsoft and Google because we're behind on security features. Blogging more is not the solution to that problem.

Security Stats

• final update is out
• discuss visualizations
  • bar seems like the best representation
  • find a way to represent as days of risk (person days of work)

Feedback from Johnath re: Sec Reviews

• Improving the process
  • we want to maximize outcomes where actionable items are produced
  • can we have more teams fill out the sec review template independent of whether we call a review meeting?
  • We should try the questionnaire method that was mentioned by mcoates at the last joint meeting
  • Assumptions about the underlying security model and data flow models etc. could be gathered ahead of the meeting to give a better direction where the meeting should go
    • Could be done conditionally (based on template)
    • Could be assisted by someone from secteam ahead of meeting
    • Might save meeting time. If we know e.g. what the security model is and where the feature is located etc. then we don't need to ask these questions again.
  • we probably need to maintain better "discipline" about staying on-task during the meetings
    • In particular, avoid questioning the value of the feature (at least until we're done quantifying risk)

Lucas PTO

• stuff to cover while out
  • release criteria
  • Tanvi

Informational

Recent Security Reviews

Add-On Sync Remote Debug Android Sync