3.2 Relevant Tasks Defined and Supported

For an open source security assurance program to operate effectively, all relevant tasks must be clearly defined and the necessary resources must be properly allocated. This is essential for securing the personnel, budget, and technical expertise needed to operate the program, and for supporting its continual improvement.

3.2.1 Access

Providing third parties with access to make enquiries about known vulnerabilities affecting an organization’s software is critical to increasing transparency, strengthening collaboration with the community, and quickly resolving potential security issues.

3.2.1.1 Publicly Visible Method for Vulnerability Enquiries

ISO/IEC 18974

• 4.2.1.1: Publicly visible method to allow third parties to make known vulnerability or newly discovered vulnerability enquires (e.g., via an email address or web portal that is monitored by program participants);
• 4.2.1.1 Publicly visible method to allow third parties to make known vulnerability or newly discovered vulnerability enquires (e.g., via an email address or web portal that is monitored by program participants)

Self-Certification Checklist

• We have a method to allow third parties to make Known Vulnerability or Newly Discovered Vulnerability enquires (e.g., via an email address or web portal that is monitored by Program Participants);
• We have a method to allow third parties to make known vulnerability or newly discovered vulnerability enquires (e.g., via an email address or web portal).

The organization shall make it possible to provide information about software vulnerabilities through a method that anyone can easily access. This can be implemented through the organization’s website, a dedicated security page, or a separate bug bounty platform. What matters is that the method for providing information is clear, easy to find, and continuously monitored.

Implementation Methods and Considerations

• Dedicated Email Address:
  • Create a dedicated email address for vulnerability reports, such as security@example.com, and publish it on the website.
  • The email address shall be continuously monitored by the security team or the relevant person in charge.
• Web-Based Reporting Form:
  • Provide a web-based reporting form where the information needed for a vulnerability report (e.g., software name, version, vulnerability description, reproduction steps) can be entered.
  • The reporting form shall be easy to use and include clear instructions.
• Security Page:
  • Publish a security page on the website that includes the organization’s security policy, vulnerability reporting procedure, and related contact information.
  • Provide a link on the website’s main page so the security page can be easily found.
• Bug Bounty Program:
  • Run a bug bounty program that encourages external security experts to test the organization’s systems and discover vulnerabilities.
  • A bug bounty program provides rewards for vulnerability reports and encourages researchers to participate.

Examples

• Post a statement on the website such as: “If you discover a security vulnerability in our company’s products, please contact us at security@example.com. For details, see the security page.”
• The vulnerability reporting web form includes the following fields:
  • Reporter information (name, email address)
  • Affected product and version
  • Vulnerability description
  • Reproduction steps
  • Supporting evidence (screenshots, log files, etc.)

Documentation Approach

Include content on security vulnerabilities when responding to external enquiries, as shown below, within the open source policy. (Reference: Open Source Policy Template)

3.2.1.2 Internal Procedure for Responding to Vulnerability Enquiries

ISO/IEC 18974

• 4.2.1.2: An internal documented procedure for responding to third party known vulnerability or newly discovered vulnerability inquiries.
• 4.2.1.2 An internal documented procedure for responding to third party known vulnerability or newly discovered vulnerability inquiries exists.

Self-Certification Checklist

• We have an internal documented procedure for responding to third party Known Vulnerability or Newly Discovered Vulnerability inquiries.
• We have documented the internal procedure for responding to external inquiries.

When a vulnerability enquiry is received from outside the organization, it is critical to have a procedure in place for responding to it in a systematic and efficient manner internally. This procedure covers the entire process of enquiry receipt, analysis, resolution, and reporting, and must clearly define the person responsible and the deadline for each stage. It must also account for information security and legal liability, so that sensitive information can be handled and shared securely.

Implementation Methods and Considerations

• Forming a Response Team:
  • Designate a responsible team or person in charge to receive and handle vulnerability enquiries.
  • The response team may include security experts, developers, and legal personnel.
• Defining the Process:
  • Document the entire process, including the stages of receiving, classifying, analyzing, resolving, and reporting vulnerability enquiries.
  • Clearly define the person responsible and the deadline for each stage.
• Severity Assessment Criteria:
  • Establish criteria for assessing the severity of a vulnerability.
  • The Common Vulnerability Scoring System (CVSS) score can be used to objectively assess the severity of a vulnerability.
• Response Procedure:
  • Establish different response procedures depending on the severity of the vulnerability.
  • Respond immediately to high-risk vulnerabilities, and consider monitoring or a long-term resolution plan for low-risk vulnerabilities.
• Communication Guidelines:
  • Establish guidelines on how to inform the person who reported the vulnerability of progress and how to request additional information.
  • Communication with the reporter shall be transparent and prompt.

Example of a Specific Procedure

1. Receipt: The security team confirms vulnerability enquiries received at security@example.com and assigns a case number.
2. Classification: The security team analyzes the type of vulnerability and the affected systems, and assesses its severity.
3. Analysis: The development team analyzes the cause of the vulnerability and explores resolution options.
4. Resolution: The development team modifies the code to resolve the vulnerability and performs testing.
5. Verification: The QA team confirms that the modified code contains no new vulnerabilities and verifies that the existing vulnerability has been resolved.
6. Reporting: The security team reports the vulnerability resolution results and updates the related documentation.
7. Notification: The security team notifies the person who reported the vulnerability of the resolution results.

Documentation Approach

Add a section on responding to security vulnerabilities to the external enquiry response procedure within the open source process. (Reference: Open Source Process Template)

3.2.2 Effectively Resourced

To successfully operate an open source security assurance program, simply establishing policies and procedures is not enough. For these policies and procedures to be truly effective, the personnel, budget, and technical expertise needed for the program must be properly secured and allocated. This is critical for ensuring the program’s sustainability and enabling it to respond effectively to a changing threat landscape.

3.2.2.1 Program Role Identification Document

ISO/IEC 18974

• 4.2.2.1: Document with name of persons, group or function in program role(s) identified;
• 4.2.2.1 Document with name of persons, group or function in program role(s) identified.

Self-Certification Checklist

• We have documented the people, group or functions related to the Program.
• We have documented the people, group or functions related to the program.

The program role identification document is a cornerstone for the successful operation of an open source security assurance program. This document helps all stakeholders participating in the program clearly understand their respective roles and responsibilities, and enables efficient collaboration and communication. It also clarifies accountability, preventing confusion and the avoidance of responsibility that can otherwise occur during program operation.

Implementation Methods and Considerations

1. Comprehensive Role Definition:
   • Identify all roles needed to operate the program, and clearly define the objectives, responsibilities, and authority of each role.
   • Consider various roles, such as program manager, security expert, legal personnel, developer, and operations personnel.
2. Responsibility Assignment:
   • Designate a person in charge or team suited to each role, and clearly assign responsibility and authority.
   • The person in charge shall have the expertise and experience required for that role.
3. Using a RACI Matrix (Optional):
   • A RACI (Responsible, Accountable, Consulted, Informed) matrix can be used to define the responsibilities of each role more clearly.
   • A RACI matrix clearly shows who is responsible, who is accountable, who is consulted, and who is informed for each task.
4. Documentation:
   • Document the role definitions, responsibility assignments, and the RACI matrix (optional) so that program participants can easily access them.
   • The document can be posted on the organization’s internal wiki, a shared document repository, or other collaboration tools.
5. Regular Review and Update:
   • The program’s role definitions may change with the organization’s structure, operating methods, and technical environment.
   • Therefore, the role definition document shall be regularly reviewed and updated to keep it current.

Example

Implementation Considerations

• The document shall be written concisely and clearly, so that all program participants can easily understand it.
• The document’s access permissions shall be properly managed to protect confidential information.
• The document shall be regularly reviewed and updated to keep it current.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

3.2.2.2 Proper Staffing and Funding of Program Roles

ISO/IEC 18974

• 4.2.2.2: The identified program roles have been properly staffed and adequate funding provided;
• 4.2.2.2 The identified program roles have been properly staffed and adequate funding provided.

Self-Certification Checklist

• We have ensured the identified Program roles have been properly staffed and adequate funding has been provided.
• We have ensured the identified program roles have been properly staffed and adequate funding has been provided.

No matter how well the program roles are defined, the program cannot operate properly if there is insufficient personnel to fill those roles or if the necessary funding is not properly provided. Therefore, the organization shall properly staff each role and provide sufficient funding for program operations. This is an essential condition for the successful operation of the program.

Implementation Methods and Considerations

1. Developing a Staffing Plan:
   • Accurately estimate the number of personnel needed for each role.
   • When estimating staffing needs, consider the scope of responsibility, workload, and required skill level for the role.
   • Forecast personnel needs from a long-term perspective, and develop a plan for hiring or reassigning internal personnel.
2. Developing a Budget Plan:
   • Identify all cost items needed to operate the program (personnel costs, training costs, tool purchase costs, consulting costs, etc.) and estimate the budget for each item.
   • The budget shall be estimated on a well-founded basis so that it can realistically be executed.
   • Develop a plan for securing the budget and obtain management approval.
3. Securing and Allocating Resources:
   • Secure the necessary personnel through hiring or the reassignment of internal personnel.
   • Appropriately allocate the secured budget across each item.
   • When allocating resources, consider the program’s priorities and objectives.
4. Regular Review and Adjustment:
   • Regularly review the adequacy of the staffing and budget plan, and adjust it as needed.
   • Update the plan considering program operation status, budget execution status, and changes in the external environment.

Example

• Personnel:
  • Hire two open source security experts for the security team to handle vulnerability analysis and response for open source components.
  • Designate one open source license expert on the legal team to support legal review when using open source.
• Budget:
  • Allocate an annual budget of KRW 50 million for purchasing open source security tools (SCA, SAST, etc.).
  • Allocate an annual budget of KRW 10 million for running the open source security training program.
  • Allocate an annual budget of KRW 20 million for external security consulting costs.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

3.2.2.3 Identifying Expertise to Resolve Known Vulnerabilities

ISO/IEC 18974

• 4.2.2.3: Identification of expertise available to address identified known vulnerabilities;
• 4.2.2.3 Identification of expertise available to address identified known vulnerabilities.

Self-Certification Checklist

• We have ensured expertise available is to address identified Known Vulnerabilities;
• We have ensured expertise available is to address identified known vulnerabilities.

When a known vulnerability is discovered in an open source component, personnel with expertise in that vulnerability are needed to resolve it quickly and effectively. This expertise can be secured from internal personnel or obtained with the help of external experts. What matters is building a system that can secure and apply the necessary expertise in a timely manner.

Implementation Methods and Considerations

1. Identifying the Required Areas of Expertise:
   • Identify the technical areas of expertise needed to operate the program.
   • Examples: web security, cryptography, network security, systems administration, and open source licensing.
   • Clearly define the level of knowledge and experience required for each area of expertise.
2. Compiling a List of Internal Experts:
   • Compile a list of personnel within the organization who have knowledge and experience in the relevant areas of expertise.
   • Record each expert’s area of expertise, career background, and contact information.
   • The expert list shall be kept up to date.
3. Planning for External Resources:
   • Develop a plan to use external experts or consulting firms in preparation for issues that are difficult to resolve internally.
   • Secure trustworthy external resources and clearly define the contract terms.
4. Establishing an Access Procedure:
   • Establish a procedure so that program participants can easily access the expertise they need.
   • Examples: how to consult an internal expert, how to use an external consulting firm.
   • Document the access procedure so that all program participants are familiar with it.

Specific Examples

• Vulnerability Analysis:
  • If a SQL injection vulnerability is found in a specific open source component, a web security expert is asked to analyze it and identify the attack path and scope of impact.
• Licensing:
  • If interpretation of the obligations of a specific open source license is needed, an open source license expert is asked to conduct a legal review.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)

3.2.2.4 Procedure for Assigning Internal Responsibility for Security Assurance

ISO/IEC 18974

• 4.2.2.4: A documented procedure that assigns internal responsibilities for security assurance.
• 4.2.2.4 A documented procedure that assigns internal responsibilities for security assurance.

Self-Certification Checklist

• We have a documented procedure that assigns internal responsibilities for Security Assurance.
• We have a documented procedure that assigns internal responsibilities for security assurance.

A procedure is established to clearly assign internal responsibility for the effective operation of the open source security assurance program. This procedure is as follows:

1. Party Responsible for Assignment:
   • The Open Source Program Manager (OSPM) leads the internal responsibility assignment procedure.
2. Assignment Procedure:
   • The OSPM convenes an annual responsibility assignment meeting.
   • The OSPM consults with each department head (legal, IT, security, development, quality, etc.) to select a person responsible for each security assurance activity.
   • The list of selected persons in charge is submitted to the OSRB (Open Source Review Board) for final approval.
3. Documentation:
   • The approved responsibility assignment results are drawn up as an official document.
   • The document specifies each security assurance activity, the person responsible, their role, and the required competence.
   • The completed document is registered in the company’s document management system and version-controlled.
4. Assignment Criteria:
   • Define the skills and experience required for each role, and select suitable personnel accordingly.
   • Link responsibility performance to performance evaluations to provide motivation.
5. Regular Review and Renewal:
   • Review the status of responsibility assignments at least once a year and adjust as needed.
   • Update immediately whenever there is a major change, such as an organizational restructuring or personnel transfer.
6. Training and Awareness:
   • Provide the necessary training to newly assigned persons in charge.
   • Share the responsibility assignment results with the entire organization to raise awareness.

Documentation Approach

Include the following content in the open source policy. (Reference: Open Source Policy Template)