DETAILED SCOPE. description of the practice Design: Define an event collection and reporting mechanism suitable to the context: Standardization of traces Completeness of information Development: At each event, update -- and verify the updating of -- trace files: add the error type, severity, and transaction ID in the appropriate fields. Operation: Analyze the trace files and determine the cause of the failure P.S.: at this point we manage technical errors only, not application errors Content: The diagnosis of incidents shall follow two major themes: Setting up of supervision indicators for both tracking activity and detecting any abnormal behaviour: drop in daily data/transaction volume, change in average response times, etc. The trace details errors with in particular: standardized error logging (format, tools), explicit error messages about the type of error and the execution context. In the logging system, each transaction shall have a unique ID across all runtime modules, in order to enable detailed tracking. Thus it is necessary to include a field in the log files indicating the transaction ID. At every step in a transaction, traces shall systematically include a field indicating the transaction ID. Means/resources: Tools: Log collector (GES), Syslog, Surveillance tools, Automatic analysis tools (e.g. Webalyzer, HDC Syslog). Audit table Automatic alert tool (e.g. sendmail) Resources: Architect: design (rule definitions), validation of development Developer: Implementation of the rules Operator Check: Prepare a test plan including scenarios related to the presence of this ID in the traces Results of the technical acceptance testing: Verification that each possible case of a technical error results in the requested trace The acceptance testing phase shall not simply test passing cases. Each potential error case identified shall have a specific acceptance test sheet. Application behaviour during operation and diagnosis associated with an incident 6.17. BPS # CIS-17 – PKI-BASED TRACEABILITY Practice summary Comply with traceability requirements related to Identity and Access Management (IAM) based on a Public Key Infrastructure (PKI). Purpose The objectives cover the following: 1) Identification and Authentication 2) Role Information assignment to the subject or object 3) Audit Logs CIS Integrity Usability requirement(s) concerned Availability Performance Capacity Maintainability Resilience Security Project phase(s) concerned Development Process: Requirements analysis Architectural design Detailed design Coding and unitary testing Testing and integration Operation Process: Operational testing System operation User support Maintenance Process: Problem and modification analysis Modification implementation Maintenance review/acceptance Migration Related Security Policy deliverables Certificate Policy Certificate Practice Statement Operating Plan: backup and recovery procedures Documents relating to Target Of Evaluation (TOE) for each device or software supporting a qualified or certified process based on ISO/IEC 15408 with Protection Profiles or Security Target. Economic impact Initial costs: High Medium Low On-going costs: High Medium Low Risks if practice not applied High Medium Low Detailed description of the practice Prerequisites: Refer to or develop a Security Policy Refer to or develop a “Certificate Policy” and “Certificate Practice Statement” as a whole based on RFC 3647 Context: The general context is taken from the reference document “Certificate Issuing and Management Component (CIMC), Family of Protection Profiles that defines requirements for a PKI.” Definition: A PKI is a security infrastructure that creates and manages public key certificates to facilitate the use of public key cryptography. To achieve this goal, a PKI shall perform two basic tasks: generate and distribute public key certificates to bind public keys to other information after validating the accuracy of the binding; and maintain and distribute certificate status information for unexpired certificates. CP: Certificate Policy: a CP is a document that describes the measures an organization will use to validate the identity of a certificate’s subject. Validation might require a requestor-provided account and password combination submitted to the organization’s directory or photo identification and submission to a background check through a registration authority (RA) process CPS: Certificate practice statement: a CPS is a public document that describes how a certification authority (CA) is managed by an organization to uphold its security and certificate policies. A CPS is published at a CA and describes the operation of the CA CRL: Certification Revocation List OCSP: Online Certificate Status Protocol The PKI systems themselves shall be compliant with CIS best practices, in particular: Security: The main aspects of these tasks are relevant to the trustworthiness of the PKI and consequently rules and techniques ensuring strong Identity Management are essential to set up a secure information systems. For critical and sensitive applications all facets of information security shall be addressed, such as confidentiality, integrity, availability and non-repudiation. Organisations shall have Risk Management Plan in place if identity is compromised. Availability: Resource availability is essential for operating Certificate Services and Identification & Authorisation modules in order to ensure business continuity. For example, to enhance the availability of Certificate Services, two or more issuing Certification Authorities shall share the enrolment process and provide verification services on certificate status (OCSP and CRL). This prevents Certificate Services from being unavailable due to a single point of failure. Performance: Agreements shall be developed and implemented between end- users, application service providers, and credential issuers. These agreements will specify the various obligations and remedies for the participants in respects of liabilities, dispute solution, privacy and operational performance. Focus: Identification and Authentication Role Information Audit Logs Ensure appropriate “track and trace” procedures implementation. Ensure archiving of identity and access management related data. Ensure compliance with CP, CPS or other applicable requirements (e.g. Common Criteria). 6.18. BPS # CIS-18 – EXTERNAL SECURITY AUDIT Practice summary Run security audits carried out by external experts. Purpose To guarantee sufficient coverage of system security requirements. Tools that are needed: hardware and software systems to prevent intrusion in the system security testing tools CIS requirement(s) concerned Integrity Usability Availability Maintainability Performance Resilience Capacity Security Project phase(s) concerned Development Process: Operation Process: Requirements analysis Operational testing Architectural design System operation Detailed design User support Coding and unitary testing Maintenance Process: Testing and integration Problem and modification analysis Modification implementation Maintenance review/acceptance Migration Economic impact Initial costs: High Medium Low On-going costs: High Medium Low Initial costs and on-going costs are depending on the level of security desired (level of Common Criteria). Risks if practice not applied High Medium Low Detailed description of the practice A prerequisite to auditing the security requirements is to have defined those requirements: Do a complete risk analysis of your system and its environment. Define or describe the security policy relevant for your system including the security objectives for your system and its environment. Describe the security requirements refined from the security objective (if possible use the Common Criteria at this stage to obtain a security target compliant with them). Design the system and establish the mapping with the security requirements to argue how the threats are covered. Test security functions when the system is developed (if possible perform a security evaluation following the Common Criteria). The goal of the audit is to verify that the organisational security procedures meet the organisational security requirements. In order to ensure proper coverage, it is essential that the external security experts/auditors be independent from the people who are building the system. The system being testing shall be very relevant compared to the operational system. Penetration tests shall be carried periodically (every 6 months or at least every year). The process described above shall be maintained to follow system evolution.
Appears in 1 contract
Sources: Cen Workshop Agreement
DETAILED SCOPE. description of the practice Design: Define an event collection and reporting mechanism suitable to the context: ▪ Standardization of traces ▪ Completeness of information Development: At each event, update -- and verify the updating of -- trace files: add the error type, severity, and transaction ID in the appropriate fields. Operation: Analyze the trace files and determine the cause of the failure P.S.: at this point we manage technical errors only, not application errors Content: The diagnosis of incidents shall follow two major themes: Setting up of supervision indicators for both tracking activity and detecting any abnormal behaviour: drop in daily data/transaction volume, change in average response times, etc. The trace details errors with in particular: ▪ standardized error logging (format, tools), ▪ explicit error messages about the type of error and the execution context. In the logging system, each transaction shall have a unique ID across all runtime modules, in order to enable detailed tracking. Thus it is necessary to include a field in the log files indicating the transaction ID. At every step in a transaction, traces shall systematically include a field indicating the transaction ID. Means/resources: Tools: ▪ Log collector (GES), ▪ Syslog, ▪ Surveillance tools, ▪ Automatic analysis tools (e.g. Webalyzer, HDC Syslog). ▪ Audit table ▪ Automatic alert tool (e.g. sendmail) Resources: ▪ Architect: design (rule definitions), validation of development ▪ Developer: Implementation of the rules ▪ Operator Check: Prepare a test plan including scenarios related to the presence of this ID in the traces Results of the technical acceptance testing: Verification that each possible case of a technical error results in the requested trace The acceptance testing phase shall not simply test passing cases. Each potential error case identified shall have a specific acceptance test sheet. Application behaviour during operation and diagnosis associated with an incident 6.17. BPS # CIS-17 – PKI-BASED TRACEABILITY CEN/ISSS WORKSHOP Practice summary Comply with traceability requirements related to Identity and Access Management (IAM) based on a Public Key Infrastructure (PKI). Purpose The objectives cover the following: 1) Identification and Authentication 2) Role Information assignment to the subject or object 3) Audit Logs CIS Integrity Usability requirement(s) concerned Availability Maintainability concerned Performance Capacity Maintainability Resilience Security Project phase(s) concerned Development Process: Requirements analysis Architectural design Detailed design Coding and unitary testing Testing and integration Operation Process: Operational testing System operation User support Maintenance Process: Problem and modification analysis Modification implementation Maintenance review/acceptance Migration Related Security Policy deliverables Certificate Policy Certificate Practice Statement Operating Plan: backup and recovery procedures Documents relating to Target Of Evaluation (TOE) for each device or software supporting a qualified or certified process based on ISO/IEC 15408 with Protection Profiles or Security Target. Economic impact Initial costs: High Medium Low On-going costs: High Medium Low Risks if practice not applied High Medium Low Detailed description of the practice Prerequisites: Refer to or develop a Security Policy Refer to or develop a “Certificate Policy” and “Certificate Practice Statement” as a whole based on RFC 3647 Context: The general context is taken from the reference document “Certificate Issuing and Management Component (CIMC), Family of Protection Profiles that defines requirements for a PKI.” Definition: A PKI is a security infrastructure that creates and manages public key certificates to facilitate the use of public key cryptography. To achieve this goal, a PKI shall perform two basic tasks: generate and distribute public key certificates to bind public keys to other information after validating the accuracy of the binding; and maintain and distribute certificate status information for unexpired certificates. CP: Certificate Policy: a CP is a document that describes the measures an organization will use to validate the identity of a certificate’s subject. Validation might require a requestor-provided account and password combination submitted to the organization’s directory or photo identification and submission to a background check through a registration authority (RA) process CPS: Certificate practice statement: a CPS is a public document that describes how a certification authority (CA) is managed by an organization to uphold its security and certificate policies. A CPS is published at a CA and describes the operation of the CA CRL: Certification Revocation List OCSP: Online Certificate Status Protocol The PKI systems themselves shall be compliant with CIS best practices, in particular: Security: The main aspects of these tasks are relevant to the trustworthiness of the PKI and consequently rules and techniques ensuring strong Identity Management are essential to set up a secure information systems. For critical and sensitive applications all facets of information security shall be addressed, such as confidentiality, integrity, availability and non-repudiation. Organisations shall have Risk Management Plan in place if identity is compromised. Availability: Resource availability is essential for operating Certificate Services and Identification & Authorisation modules in order to ensure business continuity. For example, to enhance the availability of Certificate Services, two or more issuing Certification Authorities shall share the enrolment process and provide verification services on certificate status (OCSP and CRL). This prevents Certificate Services from being unavailable due to a single point of failure. Performance: Agreements shall be developed and implemented between end- users, application service providers, and credential issuers. These agreements will specify the various obligations and remedies for the participants in respects of liabilities, dispute solution, privacy and operational performance. Focus: Identification and Authentication Role Information Audit Logs Ensure appropriate “track and trace” procedures implementation. Ensure archiving of identity and access management related data. Ensure compliance with CP, CPS or other applicable requirements (e.g. Common Criteria). 6.18. BPS # CIS-18 – EXTERNAL SECURITY AUDIT Practice summary Run security audits carried out by external experts. Purpose To guarantee sufficient coverage of system security requirements. Tools that are needed: hardware and software systems to prevent intrusion in the system security testing tools CIS requirement(s) concerned Integrity Usability Availability Maintainability Performance Resilience Capacity Security Project phase(s) concerned Development Process: Operation Process: Requirements analysis Operational testing Architectural design System operation Detailed design User support Coding and unitary testing Maintenance Process: Testing and integration Problem and modification analysis Modification implementation Maintenance reviewCEN/acceptance Migration Economic impact Initial costs: High Medium Low On-going costs: High Medium Low Initial costs and on-going costs are depending on the level of security desired (level of Common Criteria). Risks if practice not applied High Medium Low Detailed description of the practice A prerequisite to auditing the security requirements is to have defined those requirements: Do a complete risk analysis of your system and its environment. Define or describe the security policy relevant for your system including the security objectives for your system and its environment. Describe the security requirements refined from the security objective (if possible use the Common Criteria at this stage to obtain a security target compliant with them). Design the system and establish the mapping with the security requirements to argue how the threats are covered. Test security functions when the system is developed (if possible perform a security evaluation following the Common Criteria). The goal of the audit is to verify that the organisational security procedures meet the organisational security requirements. In order to ensure proper coverage, it is essential that the external security experts/auditors be independent from the people who are building the system. The system being testing shall be very relevant compared to the operational system. Penetration tests shall be carried periodically (every 6 months or at least every year). The process described above shall be maintained to follow system evolution.ISSS WORKSHOP
Appears in 1 contract
Sources: Cen Workshop Agreement