Hi Eric
Thank you for reviewing this within ST. Regarding the class of vulnerability the security team will handle, this is determined by each project's threat model and is outside the scope of the process I'm trying to define. For TF-A and TF-M, Arm has internal threat models, which we hope to make public in due course. Similarly for Mbed TLS when that migrates over. I'm not sure of the threat model status for OP-TEE. These threat models are limited to the generic nature of the tf.org projects and users should supplement them with more specific threat models covering the product context in which the projects are used and the additional product code with which they are integrated.
In general, for TF-A at least, the code tries to protect itself against software-based side channels (e.g. cache probing attacks like Spectre or timing attacks) but not attacks that require special hardware (e.g. probing on-chip memory or power glitching).
You've reminded me that I haven't responded to Joakim's mail below – I'll do that now!
Regards
Dan.
From: Eric FINCO eric.finco@st.com Sent: 16 March 2020 11:38 To: Dan Handley Dan.Handley@arm.com; tsc@lists.trustedfirmware.org Subject: RE: [TF-TSC] Proposed tf.org security incident handling process (v0.5)
Hi Dan and all,
We have had an ST internal review of the processes (internal and external) I did not hear any significant remarks from my colleagues on the processes themselves but one question related to the implementation of the processes: Obviously, any suspected security flaw can be reported to the TF security team using the dedicated email defined. However, can we have (for information only ) a view on the class of vulnerability the security team will handle ? For instance will they analyze and look for a fix to side channel attack or even hardware attack ?
Regards,
Eric Finco
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5] Eric FINCO | Tel: +33 (0)2 4402 7154 MDG | Technical Specialist
From: TSC <tsc-bounces@lists.trustedfirmware.orgmailto:tsc-bounces@lists.trustedfirmware.org> On Behalf Of Joakim Bech via TSC Sent: lundi 2 mars 2020 14:52 To: Dan Handley <Dan.Handley@arm.commailto:Dan.Handley@arm.com> Cc: tsc@lists.trustedfirmware.orgmailto:tsc@lists.trustedfirmware.org Subject: Re: [TF-TSC] Proposed tf.org security incident handling process (v0.5)
Hi Dan, all,
I've read the updated version(s), I'm happy with them as they are written here in the 0.5 version (that implies that Linaro is happy with them).
External process: - It'd be nice at some point to complement the text with a graphical timeline showing the boundaries at each step.
Internal process: - CVSSv3 or something else to identify the severity? I know OP-TEE isn't using CVSSv3. I'd be happy to change OP-TEE to align with other TF projects. - Regarding people on op-tee-security@trustedfirmware.orgmailto:op-tee-security@trustedfirmware.org, for now I think it's sufficient to have Jens + the global address (security@trustedfirmware.orgmailto:security@trustedfirmware.org).
Maniphest: - I have no experience, but that'll probably get the job done as any other tools would have done.
Regards, Joakim
On Wed, 19 Feb 2020 at 19:00, Dan Handley via TSC <tsc@lists.trustedfirmware.orgmailto:tsc@lists.trustedfirmware.org> wrote:
Hi TF TSC
This is a v0.5 update to the proposed tf.orghttp://tf.org security incident handling process, which I sent previously.
Changes:
* Expanded the Trusted Stakeholder embargo request period to 3 working days (in their timezone).
* Expanded the ESS definition to include suppliers to ESSes (e.g. distros).
* Allowed projects to optionally use severity scoring (CVSSv3 preferred but not mandated).
* Allowed for flexibility in disclosure plan to accommodate reporter's disclosure plan.
* Allowed for the fact that some projects cannot deliver vulnerability fixes to a restricted audience for export control reasons.
I've also included an internal facing process for the first time, mainly aimed at members of the security team(s) so they know how to execute the process.
I propose the next steps are:
* Discuss the latest changes in the 20th Feb TSC meeting.
* Set a date for approval of the external process (e.g. mid-March).
* Identify the right people to be on the security teams.
* Work with tf.orghttp://tf.org infra people and each project's security teams to propose a plan for when this process can be made active. Should we try to make this active for all projects at the same time or as each project is ready?
Regards
Dan.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TSC mailing list TSC@lists.trustedfirmware.orgmailto:TSC@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tsc IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
