Definition of Security Requirements
Certification criterion
When introducing, developing, or changing an information system, secure coding methods shall be applied.
Key checkpoints
- Are coding standards for the safe implementation of information systems established and applied?
Detailed explanation
※ This item is a relaxed certification criterion (Annex 7-3) under the special provisions for information security management system certification. The certification criterion and key checkpoints above are the official relaxed/adjusted text; the detailed explanation, related laws, evidence, and nonconformity examples below are the "ISMS-P Certification Criteria Guide" content for Annex 7 [2.8.1 Definition of Security Requirements], which belongs to the same control domain (under the relaxed criteria, this content applies within the scope of the certification criterion and key checkpoints above).
When newly introducing, developing, or changing an information system, procedures must be established and implemented so that feasibility can be reviewed and acceptance can be carried out from the perspective of information security and personal information protection.
- When introducing a new information system (servers, network equipment, commercial software packages) and security systems, establish an introduction plan that includes an introduction feasibility analysis and related content
- Analysis of the utilization rate, usage, and capacity limits of current system resources
- Requirements for performance, stability, security, reliability, and compatibility and interoperability with existing systems
- Where a personal information processing system is applicable, compliance with the legal requirements required under the Personal Information Protection Act (including the Notice on Standards for Measures to Ensure the Safety of Personal Information) and other relevant laws
- Reflect information security and personal information protection requirements in the Request for Proposal (RFP) and use them as criteria when selecting a vendor or product
- Establish system acceptance criteria to determine whether to accept the information system
- Establish acceptance approval criteria that reflect the performance, security, and legal requirements defined when establishing the introduction plan
- Reflect the acceptance criteria in purchase contracts and other documents so that they are complied with during the system introduction process
When newly introducing, developing, or changing an information system, security requirements, including legal requirements and the latest vulnerabilities, must be clearly defined and reflected from the design stage.
- Legal requirements related to personal information protection: access rights, access control, encryption, access records, etc.
- Information security and personal information protection requirements in accordance with the regulations of higher-level agencies and internal regulations
- Technical requirements related to information security: authentication, development security, etc.
- The latest security vulnerabilities, etc.
Coding standards for the safe implementation of information systems must be prepared and applied.
- Prepare secure coding standards and conventions to minimize threats from known technical security vulnerabilities
- Include all relevant development languages and environments such as Java, PHP, ASP, web, and mobile
- Conduct training for developers on secure coding standards and conventions
※ Software development security methodology (example)
| Phase | Content |
|---|---|
| Requirements analysis | - Identification of security items among the requirements - Requirements specification |
| Design | - Threat modeling to derive threat sources - Security design review and preparation of the security design document - Establishment of security controls |
| Implementation | - Development in compliance with the standard coding definition document and the SW development security guide - Diagnosis and improvement of source code security weaknesses |
| Testing | - Diagnosis and improvement of security vulnerabilities through penetration testing or dynamic analysis |
| Maintenance | - Continuous improvement - Security patches |
<Source> Software Development Security Guide (Ministry of the Interior and Safety, KISA)
Related laws
No individual legal provision directly corresponding to this item is specified.
Evidence (examples)
- Information system acceptance criteria and procedures
- Information system introduction RFP (Request for Proposal) and purchase contract
- Development deliverables (project execution plan, requirements definition document, screen design document, security architecture design document, test plan, etc.)
- Secure coding standards
Nonconformity examples
- A case where security verification criteria and procedures are not prepared before accepting an information system
- A case where internal regulations are prepared to review the impact on the existing operating environment and security when introducing a new system, but for some recently introduced information systems, detailed criteria and plans for security requirements at acceptance were not established, and accordingly a security review was not conducted at acceptance
- A case where major security requirements related to development (authentication and encryption, security logs, etc.) are not defined in the internal development-related guidelines
- A case where the 'development standard definition document' specifies the use of insecure encryption algorithms (MD5, SHA1) for user passwords, failing to properly reflect the relevant legal requirements