Change Details

Pre-setup ========= All members of all security teams must install and configure PGP/GPG software. All members must be ready to receive encrypted emails and keep those emails encrypted during discussion with members of the security alias or the reporter. All outbound emails from the security aliases to other parties must be signed. All members must generate or use a pre-existing key pair. Pre-existing keys must be at least RSA2048 or equivalent. New keys must be at least RSA4096 or equivalent. A member of security@trustedfirmware.org must generate new keys for all the security aliases. They must then securely deliver those keys (including private material) to the corresponding members of the teams. They should then arrange one or more key signing ceremonies so that all security team members sign each others' personal public keys and the security aliases' public keys. Each member of each security alias should also sign their personal public key with the key(s) of the security alias(es) they are a member of, but they should not sign other keys on behalf of the security alias. Following each signing ceremony, the newly signed keys should be uploaded to approprate key servers. It is desirable to further expand the web of trust by signing the security aliases' keys with other trusted members of the OSS community, but that is not a pre-requisite of this process. Triage ====== (All responses to reporter should cc security@trustedfirmware.org) 1. New incident comes into security@trustedfirmware.org. 2. Someone on security@trustedfirmware.org replies to the list as soon as possible to say they will be the triager for the incident. This should preferably be the representative for the relevant project but can be another member. 3. The triager analyses the incident as soon as possible and always within 3 working days (Monday to Friday) of the initial report. a. If the incident is obviously not a security vulnerability, the triager rejects it, giving the standard rejection response to the reporter with specific rejection reasoning. b. Otherwise the triager accepts the incident, giving the standard holding response to the reporter. They create a new "security-incident" task in Maniphest. They forward the incident to the appropriate <project>-security@trusted-firmware.org if not done already. In some cases the incident may affect more than one project; in such cases the triager should act as the reporter's point of contact for the incident. If the incident only affects one project, the project incident handler (see below) is the point of contact. If the relevant project(s) are not clear then the triager pulls in other members of security@trustedfirmware.org or the project security teams as appropriate until this is determined. 4. The triager is responsible for ensuring the relevant project security team is handling the process as defined here in a timely manner. They should also act as the reporter's backup point of contact if the project security team is not functioning properly. 5. The other members of security@trustedfirmware.org are responsible for picking up the duties of the triager if the triager becomes unavailable. Project handling ================ (All responses to reporter should cc <project>-security@trusted-firmware.org 1. New incident comes into <project>-security@trusted-firmware.org. 2. Someone on <project>-security@trusted-firmware.org immediately replies to the list to say they will be the project incident handler. Alternatively, if a task exists on Maniphest, they can self-assign the task. 3. The project incident handler analyses the incident as soon as possible and always within 7 days of receipt. They create a new "security-incident" task in Maniphest if not done already. They may pull in other project security team members or trusted contributors to the project to help with the analysis but they must ensure that any sensitive information^ the reporter provides is stripped out before communication outside the security teams. a. If the incident is deemed not a security vulnerability^^, the project indident handler rejects it, giving the standard rejection response to the reporter with specific rejection reasoning. If the incident is a normal bug, the project incident handler reports one via the project's normal bug reporting process. They close the "security-incident" task. b. Otherwise the project incident handler accepts the incident is (or may be) a security vulnerability and proceeds to the next stage. 4. The project incident handler consolidates the information gathered on the (potential) vulnerability so far and shares that information with the reporter^^^ and <project>-ess-notify@trustedfirmware.org (if applicable to project). As part of this communication, it's possible that the (potential) vulnerabilty is downgraded to a normal bug. For comfirmed vulnerabilities, the project incident handler arranges for someone to fix the vulnerability and as a lower priority, someone to begin drafting a security advisory. Again, they must ensure that any sensitive information^ the reporter provides is stripped out before communication outside the security teams. They should also request a CVE from Mitre at this stage if not already done by the reporter. 5. The project incident handler is reponsible for negotiating embargo/disclosure timelines with the reporter^^^ and stakeholders, and keeping them informed throughout the remainder of the process. Triggers for new updates include: new vulnerability fix available, new advisory draft available, fix/advisory becoming public, vulnerability status change (e.g. severity changed, new exploit found, change in disclosure plan, ...). 6. After a fix for the vulnerability is available, the project incident handler shares the fix with the reporter^^^ and <project>-ess-notify@trustedfirmware.org via email (unless the projects is not allowed to distribute the fix due to export control restrictions). If an embargo is agreed with an ESS, the primary embargo period starts. 7. After the primary embargo period (if applicable) ends, the project incident handler notifies <project>-trusted-stakeholder-notify@trustedfirmware.org with the latest information and keeps them informed throughout the remainder of the process. The secondary emabargo period starts. 8. When the secondary embargo period ends, the project incident handler arranges for the vulnerability fix to be made public. 9. The project incident handler circulates drafts of the security advisory with the reporter, ESSes and Trusted Stakeholders as they become available. 10. When the public embargo period ends, the project incident handler arranges for the advisory (and vulnerability fix if not done before) to be made public. ^ By default, sensitive information includes the reporter's identity, their organization and their organization's product information. The reporter may specify other sensitive information. ^^ Each project may have its own process for determining this. This may include a threat model, severity scoring of the bug and a bug bar for determining which bugs should be treated as security vulnerabilities. For projects that use severity scoring, CVSSv3 is preferred to align with Mitre CVEs. ^^^ Or triager for incidents that affect multiple projects since they are the point of contact.

You can use GnuPG for pgp setup. Following page has list of downloads for various platforms.Pre-setup [[https://gnupg.org/download/index.html]]========= Various plug-ins are available for email clients,All members of all security teams must install and configure PGP/GPG software. All members must be ready to receive encrypted emails and keep those emails encrypted during discussion with members of the security alias or the reporter. please install one suitable for your setupAll outbound emails from the security aliases to other parties must be signed. If you are part of a security list, you will have received associated private key,All members must generate or use a pre-existing key pair. sign your personal public key by this private keyPre-existing keys must be at least RSA2048 or equivalent. This helps the reporter in establishing trust when communicating to youNew keys must be at least RSA4096 or equivalent. A member of security@trustedfirmware.org must generate new keys for all the security aliases. They must then securely deliver those keys (including private material) to the corresponding members of the teams. They should then arrange one or more key signing ceremonies so that all security team members sign each others' personal public keys and the security aliases' public keys. Each member of each security alias should also sign their personal public key with the key(s) of the security alias(es) they are a member of, but they should not sign other keys on behalf of the security alias. Following each signing ceremony, the newly signed keys should be uploaded to approprate key servers. It is desirable to further expand the web of trust by signing the security aliases' keys with other trusted members of the OSS community, but that is not a pre-requisite of this process. Triage ====== (All responses to reporter should cc security@trustedfirmware.org) 1. New incident comes into security@trustedfirmware.org. 2. Someone on security@trustedfirmware.org replies to the list as soon as possible to say they will be the triager for the incident. This should preferably be the representative for the relevant project but can be another member. 3. The triager analyses the incident as soon as possible and always within 3 working days (Monday to Friday) of the initial report. a. If the incident is obviously not a security vulnerability, the triager rejects it, giving the standard rejection response to the reporter with specific rejection reasoning. b. Otherwise the triager accepts the incident, giving the standard holding response to the reporter. They create a new "security-incident" task in Maniphest. They forward the incident to the appropriate <project>-security@trusted-firmware.org if not done already. In some cases the incident may affect more than one project; in such cases the triager should act as the reporter's point of contact for the incident. If the incident only affects one project, the project incident handler (see below) is the point of contact. If the relevant project(s) are not clear then the triager pulls in other members of security@trustedfirmware.org or the project security teams as appropriate until this is determined. 4. The triager is responsible for ensuring the relevant project security team is handling the process as defined here in a timely manner. They should also act as the reporter's backup point of contact if the project security team is not functioning properly. 5. The other members of security@trustedfirmware.org are responsible for picking up the duties of the triager if the triager becomes unavailable. Project handling ================ (All responses to reporter should cc <project>-security@trusted-firmware.org 1. New incident comes into <project>-security@trusted-firmware.org. 2. Someone on <project>-security@trusted-firmware.org immediately replies to the list to say they will be the project incident handler. Alternatively, if a task exists on Maniphest, they can self-assign the task. 3. The project incident handler analyses the incident as soon as possible and always within 7 days of receipt. They create a new "security-incident" task in Maniphest if not done already. They may pull in other project security team members or trusted contributors to the project to help with the analysis but they must ensure that any sensitive information^ the reporter provides is stripped out before communication outside the security teams. a. If the incident is deemed not a security vulnerability^^, the project indident handler rejects it, giving the standard rejection response to the reporter with specific rejection reasoning. If the incident is a normal bug, the project incident handler reports one via the project's normal bug reporting process. They close the "security-incident" task. b. Otherwise the project incident handler accepts the incident is (or may be) a security vulnerability and proceeds to the next stage. 4. The project incident handler consolidates the information gathered on the (potential) vulnerability so far and shares that information with the reporter^^^ and <project>-ess-notify@trustedfirmware.org (if applicable to project). As part of this communication, it's possible that the (potential) vulnerabilty is downgraded to a normal bug. For comfirmed vulnerabilities, the project incident handler arranges for someone to fix the vulnerability and as a lower priority, someone to begin drafting a security advisory. Again, they must ensure that any sensitive information^ the reporter provides is stripped out before communication outside the security teams. They should also request a CVE from Mitre at this stage if not already done by the reporter. 5. The project incident handler is reponsible for negotiating embargo/disclosure timelines with the reporter^^^ and stakeholders, and keeping them informed throughout the remainder of the process. Triggers for new updates include: new vulnerability fix available, new advisory draft available, fix/advisory becoming public, vulnerability status change (e.g. severity changed, new exploit found, change in disclosure plan, ...). 6. After a fix for the vulnerability is available, the project incident handler shares the fix with the reporter^^^ and <project>-ess-notify@trustedfirmware.org via email (unless the projects is not allowed to distribute the fix due to export control restrictions). If an embargo is agreed with an ESS, the primary embargo period starts. 7. After the primary embargo period (if applicable) ends, the project incident handler notifies <project>-trusted-stakeholder-notify@trustedfirmware.org with the latest information and keeps them informed throughout the remainder of the process. The secondary emabargo period starts. 8. When the secondary embargo period ends, the project incident handler arranges for the vulnerability fix to be made public. 9. The project incident handler circulates drafts of the security advisory with the reporter, ESSes and Trusted Stakeholders as they become available. 10. When the public embargo period ends, the project incident handler arranges for the advisory (and vulnerability fix if not done before) to be made public. ^ By default, sensitive information includes the reporter's identity, their organization and their organization's product information. The reporter may specify other sensitive information. ^^ Each project may have its own process for determining this. This may include a threat model, severity scoring of the bug and a bug bar for determining which bugs should be treated as security vulnerabilities. For projects that use severity scoring, CVSSv3 is preferred to align with Mitre CVEs. ^^^ Or triager for incidents that affect multiple projects since they are the point of contact.