draft: Project-Based Learning in Software Modelling.

PBL:

Project Based Learning (PBL) experience is a self-sovereign teaching method in which the self learns by actively engaging in real-world and personally meaningful projects.

Title: “A Step-by-Step Guide to Conducting Formal Verification of a Software Product”

dApp Certification on Cardano PBL plan

Documentation review

Cardano Engineering Handbook

Audit/evaluation process is described: https://www.commoncriteriaportal.org/cc/index.cfm

https://github.com/cardano-foundation/CIPs

CIP-52 describes the audit process in general. CIP-96 describes the way to store and present certification information to all stakeholders. CIP-72 describes a standardised method for dApp developers to register their dApp(s) on-chain and for users to verify the claims made by dApp developers.

https://en.wikipedia.org/wiki/Requirements_analysis

https://iohk.io/en/blog/posts/2021/09/22/bringing-certified-dapps-to-cardano/ https://iohk.io/en/research/library/papers/translation-certification-for-smart-contracts-extended-abstract/

[ ] What are the auditors considerations: CTI, List of known vulnerabilities, Security advisories,
[x] How does the evaluation process fit into the the software development lifecycle?

https://github.com/cardano-foundation/CIPs/tree/master/CIP-0052

The evaluation of process typically involves several stages:

1. Requirements definition: This is where the project's objectives, functional requirements, and non-functional requirements (such as performance, reliability, and security) are defined. Common Criteria can be used to define these requirements in a standardized manner, ensuring that all stakeholders have a clear understanding of what needs to be achieved. 2. Design: During this phase, the system architecture is designed based on the requirements gathered earlier. The design should take into account various security aspects such as confidentiality, integrity, availability, and maintainability. Common Criteria can help in defining the assurance levels required for each component of the system to meet its security objectives. 3. Implementation: In this stage, developers write code based on the designed architecture. Throughout the implementation process, it is essential to perform regular testing and validation activities to ensure that the developed software meets the defined requirements and adheres to the Common Criteria assurance levels. This can be done using various techniques such as static analysis, dynamic analysis, penetration tests, and fuzzing. 4. Verification: Once the implementation is complete, verification activities are carried out to confirm whether the system satisfies its security objectives as defined in the requirements document. These activities may include threat modeling, vulnerability scanning, code review, and security testing. Common Criteria can be used during this phase to evaluate if the implemented security features meet the required assurance levels. 5. Validation: In this stage, the system is tested against real-world scenarios or use cases to ensure that it performs as expected in a production environment. This may involve user acceptance tests, performance testing, and stress testing. Common Criteria can be used during validation activities to provide evidence of the security features' effectiveness in meeting the defined assurance levels. 6. Maintenance: After deployment, continuous monitoring and maintenance are required to ensure that the system remains secure as new vulnerabilities emerge or existing threats evolve. Regular updates, patches, and improvements should be made based on feedback from users and security researchers. Common Criteria can also be used during this phase for periodic re-evaluation of the system's security features and compliance with updated standards.

Prompt: as a developer experience engineer and community architect describe how a project manager should approach product certification and quality assurance Response: As a Developer Experience Engineer (DXE) and Community Architect, I would recommend that a Project Manager approaches product certification and quality assurance in the following ways:

Understand the Product: The first step is to have a deep understanding of the product being developed or maintained. This includes its features, functionalities, user interface, underlying architecture, and any existing certifications it has received. It's also important to understand the target audience for this product and their expectations from the product in terms of quality, functionality, and usability.
Define Quality Standards: Once you have a clear understanding of the product, define what constitutes "quality" for that product. This could be based on industry standards, customer feedback, or internal guidelines. These standards should cover all aspects of the product including functionality, performance, security, usability, and maintainability.
Establish Quality Assurance Processes: Develop a set of processes to ensure that quality is maintained throughout the development lifecycle. This could include code reviews, unit testing, integration testing, system testing, user acceptance testing, and performance testing. These processes should be well-documented and communicated to all team members involved in the project.
Certification Preparation: If certification is a requirement for your product, start preparing early. This could involve creating test cases based on the quality standards defined earlier, training team members on how to perform these tests, and identifying any gaps that need to be addressed before the certification process begins.
Certification Execution: Once you are ready for the certification process, execute it according to the plan developed in step 4. This could involve submitting your product to a third-party testing organization or conducting self-certification based on established standards. Ensure that all necessary documentation is provided and any required fees are paid.
Post-Certification: After certification, continue monitoring the quality of the product through regular audits and reviews. This will help ensure that the product continues to meet the defined quality standards over time. Also, communicate the results of the certification process with stakeholders including customers, management, and team members involved in the project.
Continuous Improvement: Use feedback from the certification process (if applicable) or internal reviews to identify areas for improvement. This could involve updating quality standards based on new industry trends, improving testing processes, or providing additional training to team members. Continuously strive to improve the product and its development processes to ensure it remains competitive in the market.

In summary, a Project Manager should approach product certification and quality assurance by understanding the product, defining quality standards, establishing QA processes, preparing for certification, executing the process, monitoring post-certification, and continuously improving based on feedback and industry trends.

Documentation: This is a crucial part of the evaluation process as it provides detailed information about the product's security features, design, implementation, and testing results. The following documents are typically required:
- Product documentation: A comprehensive description of the product, including its functionality, architecture, interfaces, and security mechanisms.
- Protection Profile (PP): A high-level specification that defines the security requirements for a specific type of product or system. It serves as a reference point during the evaluation process.
- Target of Evaluation (TOE): A detailed technical description of the evaluated product, including its security features and implementation details. The TOE should be aligned with the Protection Profile to ensure that all required security requirements are addressed.
- Security Target (ST): This document provides a complete assessment of the product's compliance with the specified security requirements in the Protection Profile. It includes an analysis of the design, implementation, and testing results for each evaluated security requirement.
Evaluation Assurance Levels (EALs): EALs are used to measure the confidence that can be placed on a product's security evaluation based on the rigor and thoroughness of the assessment process. There are 7 EAL levels, ranging from EAL1 (Informal Methods) to EAL7 (Formal Development and Verification). The higher the EAL level, the more stringent the requirements for validation and verification become. To achieve a specific EAL rating, an evaluation team must demonstrate that they have met all required criteria in the relevant CC documentation.
Testing Artifacts: These are the results of security testing conducted during the product evaluation process. They serve as evidence to support the claims made in the Security Target document and help validate the effectiveness of the implemented security mechanisms. The following artifacts are typically generated:
- Test Cases: A set of test scenarios designed to verify that the TOE meets its specified security requirements, including functional testing, penetration tests, and vulnerability scans.
- Test Reports: Detailed documentation of the results from each test case, highlighting any issues found during testing and their resolution. This includes information on false positives, false negatives, and other relevant findings.
- Attack Scenarios: Descriptions of potential attacks against the TOE, along with an assessment of the product's ability to mitigate or prevent these threats.
- Configuration Management Records: Documentation that tracks changes made to the evaluated product during the evaluation process, ensuring consistency and traceability throughout the evaluation lifecycle.

Understand the Product: The first step is to have a deep understanding of the product being developed or maintained. This includes its features, functionalities, user interface, underlying architecture, and any existing certifications it has received. It's also important to understand the target audience for this product and their expectations from the product in terms of quality, functionality, and usability.
Define Quality Standards: Once you have a clear understanding of the product, define what constitutes "quality" for that product. This could be based on industry standards, customer feedback, or internal guidelines. These standards should cover all aspects of the product including functionality, performance, security, usability, and maintainability.
Establish Quality Assurance Processes: Develop a set of processes to ensure that quality is maintained throughout the development lifecycle. This could include code reviews, unit testing, integration testing, system testing, user acceptance testing, and performance testing. These processes should be well-documented and communicated to all team members involved in the project.
Certification Preparation: If certification is a requirement for your product, start preparing early. This could involve creating test cases based on the quality standards defined earlier, training team members on how to perform these tests, and identifying any gaps that need to be addressed before the certification process begins.
Certification Execution: Once you are ready for the certification process, execute it according to the plan developed in step 4. This could involve submitting your product to a third-party testing organization or conducting self-certification based on established standards. Ensure that all necessary documentation is provided and any required fees are paid.
Post-Certification: After certification, continue monitoring the quality of the product through regular audits and reviews. This will help ensure that the product continues to meet the defined quality standards over time. Also, communicate the results of the certification process with stakeholders including customers, management, and team members involved in the project.
Continuous Improvement: Use feedback from the certification process (if applicable) or internal reviews to identify areas for improvement. This could involve updating quality standards based on new industry trends, improving testing processes, or providing additional training to team members. Continuously strive to improve the product and its development processes to ensure it remains competitive in the market.

How?

Common Criteria is an internationally recognized set of guidelines for evaluating information technology security products. It provides a standardized approach to assessing the effectiveness of security measures and ensuring that they meet specific requirements. The following are some common control types that may be employed within a Web3 company: 1. Access Controls: These controls limit access to sensitive resources based on user identities, roles, or permissions. In a Web3 context, this could involve requiring multi-signature authentication for transactions or restricting access to specific wallet addresses. 2. Data Confidentiality and Integrity: Encryption techniques are used to protect data at rest (stored) and in transit (communicated). This ensures that sensitive information is not easily accessible by unauthorized parties, and any modifications made to the data can be detected. 3. Audit Logs and Monitoring: Regularly reviewing logs of system activities helps identify suspicious behavior or potential security breaches. Implementing intrusion detection systems (IDS) and other monitoring tools allows for early detection of threats and rapid response in case of an attack. 4. Security Patch Management: Keeping software up-to-date with the latest patches is crucial to mitigate known vulnerabilities that could be exploited by malicious actors. This includes updating smart contracts, blockchain nodes, and other related infrastructure components. 5. Disaster Recovery and Business Continuity Planning (DR/BCP): In case of a security incident or system failure, having well-defined DR/BCP procedures ensures minimal downtime and data loss while maintaining business operations. This includes offsite backups, redundant systems, and failover mechanisms. 6. Security Awareness Training: Educating employees about cybersecurity best practices helps reduce the likelihood of human error leading to security breaches. Regular training sessions should cover topics such as phishing attacks, strong passwords, and safe browsing habits. 7. Penetration Testing and Vulnerability Assessments: Periodically conducting penetration tests and vulnerability assessments can help identify potential weaknesses in the system before they are exploited by attackers. This allows for timely remediation of any issues found during these evaluations. By implementing a combination of these controls, Web3 companies can effectively minimize risks associated with digital assets while ensuring that their users' data and transactions remain secure.

Motivation

As Cardano Builders our primary responsibility is to ensure that our users' data, transactions, and digital assets are secure. We emphasize the importance of risk management and security measures to protect the assets from potential threats such as theft, fraud, or unauthorized access. To minimize risks associated with the assets, we impose risk controls in accordance with [the standard](https://github.com/input-output-hk/Certification-working-group/pull/34)

Background: Common Criteria

The Common Criteria Recognition Arrangement covers certificates with claims of compliance against Common Criteria assurance components of either: - a collaborative Protection Profile (cPP), developed and maintained in accordance with CCRA Annex K, with assurance activities selected from Evaluation Assurance Levels up to and including level 4 and ALC_FLR, developed through an International Technical Community endorsed by the Management Committee; or - Evaluation Assurance Levels 1 through 2 and ALC_FLR.

dApp certification

A product evaluation based on the Common Criteria (CC) framework requires the following deliverables to be completed in order to assess and certify the security level of an information technology product or system: - [ ] #32

Prompt: you are a software verification expert, describe what you need to know to write a Protection Profile with compliance with the Common Criteria

Responses

Response: To write a Protection Profile (PP) that complies with the Common Criteria (CC), one must have a deep understanding of the following concepts and requirements: 1. The Common Criteria: Familiarize yourself with the CC, which is an internationally recognized standard for evaluating information technology security products. It provides a framework to assess whether a product meets specific security objectives based on its functionalities and assurance levels. 2. Protection Profile (PP) Structure: Understand the structure of a PP document, including its sections and requirements. A typical PP consists of an introduction, security objectives, functional requirements, assurance requirements, and appendices. Each section has specific guidelines that must be followed to ensure compliance with CC standards. 3. Security Objectives: Identify and define the primary goals or purposes for which a product is being developed or acquired. These objectives should address the protection of information assets, systems, and services from potential threats. 4. Functional Requirements: Outline the specific functions that a security product must perform to achieve its security objectives. These requirements are organized into different categories such as access control, identification and authentication, confidentiality, integrity, availability, accountability, etc. Each functional requirement should be clearly defined with examples of how it can be satisfied by the evaluated product. 5. Assurance Requirements: Establish the level of confidence that a security product will perform its functions effectively and reliably. This involves defining the assurance objectives (e.g., robustness, survivability) and specifying the evaluation methods and criteria to assess whether these objectives are met. The assurance requirements should be aligned with the target Evaluation Assurance Levels (EALs), which range from EAL1 (functional testing) to EAL7+ (high-assurance evaluation). 6. Security Target: Develop a Security Target (ST) for the evaluated product, based on the PP's security objectives and functional requirements. The ST is a detailed description of how the product meets each requirement and provides evidence that supports its compliance with CC standards. 7. Evaluation Process: Understand the evaluation process for CC-compliant products, which includes selecting an accredited certification body to perform the assessment, submitting the PP and ST for review, and undergoing a formal evaluation against the defined security objectives and functional requirements. 8. Documentation Standards: Ensure that all documentation related to the Protection Profile (including its development process) adheres to CC standards and guidelines. This includes proper formatting, use of terminology, and referencing relevant international standards or specifications. 9. Continuous Improvement: Stay updated with any changes in the Common Criteria standard, as well as emerging security threats and technologies. Regularly review and update your Protection Profile to ensure its relevance and effectiveness in addressing evolving security challenges. Response: To create a Protection Profile (PP) for compliance with the Common Criteria, there are several key elements that I would need to consider. Here's an overview of these elements and what they entail: 1. **Scope Definition**: This is where you define the system or product that will be evaluated against the Common Criteria. The scope should clearly outline all components included in the evaluation, including hardware, software, and any other relevant aspects. It's important to ensure that the scope accurately represents what is being evaluated. 2. **Security Requirements**: This section outlines the security requirements for the system or product. These are based on the functional and assurance levels defined in the Common Criteria framework, which provide a standardized approach to evaluating security. The security requirements should be specific, measurable, achievable, relevant, and time-bound (SMART). 3. **Protection Profiles**: Protection Profiles are predefined sets of security controls that can be used as a basis for creating custom PPs. They provide a standardized approach to addressing specific types of threats or vulnerabilities. You would need to select the appropriate protection profiles based on your system's needs and ensure they align with the scope definition. 4. **Security Assurance Level**: This is a measure of how well the security requirements are met, ranging from Evaluation Assurance Level (EAL) 1 (basic self-certification) to EAL 7 (formal verification by an independent third party). The choice of assurance level depends on the system's importance and potential impact if it were compromised. 5. **Security Functional Requirements**: These are specific security features or capabilities that must be present in the system to meet the security requirements. They should align with the protection profiles selected and address all relevant threats identified during the risk assessment process. 6. **Risk Assessment**: This involves identifying potential threats and vulnerabilities that could compromise the system's security, as well as evaluating their likelihood and impact. The results of this assessment should inform the selection of appropriate protection profiles and security functional requirements. 7. **Testing and Evaluation Methodology**: This outlines how the evaluation will be conducted to ensure that the system meets all security requirements. It includes details on testing methodologies, tools, and techniques for evaluating the system's security controls. 8. **Documentation Requirements**: The PP must include a detailed description of the system or product being evaluated, including its components, architecture, and interfaces. This information is necessary to ensure that all aspects of the system are considered during the evaluation process. 9. **Common Criteria Compliance Claims**: These are statements made about how well the system meets the Common Criteria security requirements. They should be clear, concise, and supported by evidence from the testing and evaluation process. 10. **Glossary of Terms**: This section defines any technical terms or acronyms used in the PP to ensure clarity for all stakeholders involved in the evaluation process. Remember that creating a Protection Profile is a complex task requiring expertise in both security and software engineering. It's essential to follow best practices, stay up-to-date with Common Criteria guidelines, and seek advice from experienced professionals when necessary.

Prompt: you are a software verification intern. Describe the artifacts you need to create a security target for a given product that is compliant with the common criteria

Response:

As a software verification intern, I would follow these steps in creating a security target for a given product that is compliant with the Common Criteria (CC): 1. Understand the Product: Firstly, it's important to understand the product thoroughly and its functionalities. This will help in identifying potential risks and vulnerabilities associated with the system. 2. Identify Security Objectives: Based on the understanding of the product, I would identify the security objectives that need to be addressed for the given product. These objectives should cover all aspects of the product's functionality, such as data protection, access control, and secure communication channels. 3. Analyze Threat Scenarios: Next, I would analyze potential threat scenarios that could exploit vulnerabilities in the system. This includes identifying possible attack vectors, analyzing their impact on the system, and determining the likelihood of these threats occurring. 4. Create Security Target Documentation: Based on the analysis above, I would create a security target document which outlines the security objectives for the product, along with the identified threat scenarios and mitigation strategies. This document should be detailed enough to provide a clear understanding of how the system addresses its security requirements. 5. Align with Common Criteria Requirements: The next step is to align the security target documentation with the CC requirements. This involves ensuring that all necessary elements, such as security functional and assurance requirements, are addressed in the document. 6. Review and Update: Once the initial draft of the security target has been created, it should be reviewed by relevant stakeholders for feedback and suggestions. Based on their input, I would update the document to ensure that all concerns have been adequately addressed. 7. Evaluation Plan: After finalizing the security target documentation, an evaluation plan needs to be developed. This plan outlines how the product will be evaluated against the CC requirements, including details about the testing methodology and resources required for the evaluation process. 8. Submission of Security Target Documentation: Finally, I would submit the completed security target document along with the evaluation plan to relevant authorities or certification bodies responsible for evaluating products under the Common Criteria framework. By following these steps, a comprehensive security target can be created that is compliant with the Common Criteria and addresses all necessary security requirements for the given product.

Prompt: you are a software verification specialist, describe steps you would take to create a security target that is compliant with the common criteria for a product that is a decentralized application

Response:

As a software verification specialist, I would follow these steps to create a security target for a decentralized application (dApp) that is compliant with the Common Criteria: 1. Understand the requirements of the Common Criteria: The first step in creating a security target is understanding the specific requirements and guidelines set by the Common Criteria framework. This includes familiarizing yourself with the evaluation assurance levels (EALs), which range from EAL1 to EAL7, indicating increasing levels of assurance for security. 2. Identify the functional and non-functional requirements: Determine the key features and functionality of the dApp that need to be addressed in the security target. This includes understanding user authentication, data encryption, access control mechanisms, smart contract security, and other relevant aspects. 3. Conduct a threat analysis: Analyze potential threats and vulnerabilities that could affect the decentralized application. Consider both internal (e.g., developers) and external (e.g., hackers) sources of risk. Identify possible attack vectors such as denial-of-service attacks, phishing, smart contract exploits, and other security concerns related to blockchain technology. 4. Develop a mitigation strategy: Based on the threat analysis, develop a comprehensive plan for addressing identified vulnerabilities. This may include implementing secure coding practices, utilizing encryption algorithms, employing access control mechanisms, and conducting regular security audits. 5. Create a security target document: Draft a detailed security target document that outlines the dApp's security objectives, functional requirements, non-functional requirements, threat analysis, mitigation strategy, and any other relevant information needed for compliance with the Common Criteria framework. This document should be clear, concise, and easily understandable by both technical and non-technical stakeholders. 6. Review and refine: Share the security target document with internal and external stakeholders to gather feedback and ensure that all requirements are accurately addressed. Revise the document as necessary based on input received during this review process. 7. Submit for evaluation: Once the security target is finalized, submit it along with the dApp's source code and other relevant documentation to a certified Common Criteria evaluator. The evaluator will assess the application against the defined security objectives and provide an EAL rating based on the level of assurance achieved. 8. Address any issues identified during evaluation: If the evaluator identifies any gaps or areas for improvement in the dApp's security, work with them to address these concerns and make necessary changes to achieve compliance with the Common Criteria framework. 9. Maintain and update: Once the dApp is deemed compliant with the Common Criteria, continue to monitor its security posture by regularly updating the security target document to account for new threats, vulnerabilities, or changes in technology. This will help ensure that the decentralized application remains secure over time. By following these steps, you can create a security target for your dApp that is compliant with the Common Criteria framework and demonstrates a high level of assurance for its security.

a chunk:

As Cardano Builders our primary responsibility is to ensure that our users' data, transactions, and digital assets are secure. We emphasize the importance of risk management and security measures to protect the assets from potential threats such as theft, fraud, or unauthorized access. To reduce such risks controls must be imposed on the software artifacts we produce as well as on the process by which we produce these artifacts.

Audit is one such control. An audit is a comprehensive investigation of a DApp that provides an in-depth analysis on bugs, vulnerabilities, code quality and correctness of implementation. The process of audit on Cardano is described in CIP-52, with additional information available through CIP-72, CIP-96 and articles published on IOHK.io. CIP-52 recommends that a developer should contact an auditor when they have a final working version of a DApp or fragment of a DApp that they want to have audited. It is also recommended to reach out to the potential auditor as early as possible so as to mitigate any design issues which may be very hard if not impossible to fix.

Audit process on Cardano is modeled after the Common Criteria. Common Criteria (CC) is an international standard for computer security certification, developed to ensure that products and systems meet a pre-defined security standard for government deployments. It is a framework in which computer system users can specify their security functional requirements (SFRs) and security functional assurance requirements (SARs) using Protection Profiles (PPs). CC certification is given to security products that have successfully passed the testing and Common Criteria evaluation performed by an accredited Testing Laboratory.

The top-level design goals were as follows:

Soundness. Verification results should be sound—that is, trustworthy for all compilers and target machines. Sufficient completeness. Verification of non-trivial properties should offer a tolerably low false-alarm rate. Formality. The language should be amenable to the development of an unambiguous formal definition. Scalability. Verification should scale to industrial code bases in reasonable time. Modularity. Verification of incomplete programs should be possible during their development. Expressiveness. The language should be usable for building embedded, real-time, and critical software systems, not limited to "toy" examples. The verification system should allow the specification of non-trivial correctness properties, not just a list of "common errors."

https://m-cacm.acm.org/magazines/2024/3/280078-co-developing-programs-and-their-proof-of-correctness/fulltext

input-output-hk / Certification-working-group

draft: Project-Based Learning in Software Modelling. #37

PBL:

Documentation review