Background
In the practice of enterprise SDL (Security Development Lifecycle), security requirements are crucial. In the software development lifecycle, requirement collection and requirement analysis occupy a core position. Product managers need to ensure that the product requirements collected and summarized through various channels are complete. In the requirement analysis stage, they also need to combine product functional characteristics, their own professional experience, and other aspects to screen valuable requirements and distinguish between true and false requirements.
Especially in the process of enterprise SDL (Security Development Lifecycle) construction, a key point that needs to be added to the requirement collection and requirement analysis stage is Security. If the product only considers the functional implementation of the product during the initial requirement collection and requirement analysis stage and ignores the security requirements or the security issues of the requirements themselves, various security issues will emerge as time goes by after the product is launched. This may lead to significant losses to the product, or even require the product to be taken offline and rebuilt.
The management of the security development lifecycle is an important measure to ensure the normal operation of internet enterprise business and is directly related to the security of enterprise online business operations. The potential security risks involved in enterprise office security are more complex and diverse, including data leakage, personnel violations, external intrusion, and physical security issues.
Security requirements inSDLIn practice, it is to ensure that the software product meets the security requirements throughout the entire process from design to launch, thereby reducing potential security risks and protecting the interests of enterprises and users.
Goals
The main goal of SDL (Security Development Lifecycle) security requirements is to help developers build more secure software, meet security compliance requirements, and at the same time reduce development costs.
Security Considerations
1. Legal and RegulatoryIn the stage of software requirement analysis, it is necessary to pay attention to the legal and regulatory requirements that may be involved. This includes ensuring that the software complies with relevant industry regulations and protecting user privacy and data security. For example, software in the financial industry may need to meet the requirements of financial regulatory agencies; for software involving personal information of users, relevant data protection regulations must be followed.
2. Privacy SecurityIn the stage of software requirement analysis, it is necessary to fully consider the privacy and security issues that users may encounter when using software products. This includes encrypting the storage and transmission of user data, and protecting sensitive information. For example, SSL/TLS protocols can be used to encrypt data transmission, and hash algorithms can be used to encrypt and store user passwords.
3. Business SecurityIn the stage of software requirement analysis, it is necessary to pay attention to the security issues of the software's own business function design. This includes conducting a security assessment of the software's business logic to ensure that there are no security vulnerabilities and potential attack risks. For example, it is possible to check the legality of the software's input and output to prevent common security vulnerabilities such as SQL injection and cross-site scripting attacks.
Note: This discussion is limited to the security issues involved in the software development process and does not involve issues such as host security, middleware security, and deployment security. In the actual development process, attention also needs to be paid to other aspects of security requirements to ensure the overall security of the software.
Security activities
1. Promotion of security assessment process: When the project is initiated, the security team needs to promote the product security assessment process. Although the focus is mainly on the functionality of the product, the promotion of the security assessment process is still very important. Especially for project (product) managers, this step is to ensure that all relevant personnel understand and understand how to consider and implement security issues throughout the software development process.
To ensure the security of self-developed projects, security checks are added at all stages. This includes:
Security requirements analysis: During the requirements analysis phase, the security team needs to propose specific security requirements and ensure that these requirements are fully considered.
Security design: During the design phase, the security team needs to work with the development team to ensure that the design of the software meets all security requirements.
Security development: During the development phase, the development team needs to follow the security coding standards to ensure that the implementation of the software meets all security requirements.
Security testing: During the testing phase, the security team needs to conduct detailed security testing to ensure that the software does not have any security vulnerabilities.
Release audit: Before the release, the security team needs to conduct a final review of the software to ensure that it meets all security requirements.
In addition, checkpoints should be set before the system is released online to ensure that the software meets all security requirements before it can be smoothly launched. If the software does not meet the security requirements, a series of processes need to be followed to obtain the agreement of multiple responsible persons and the CTO, and to go through the green channel. During this process, it is necessary to clarify the relevant responsible persons and the subsequent rectification plan.
2. Propose security requirements: Based on the understanding of possible threats and risks, the security team needs to propose specific security requirements. These requirements should clearly indicate what security functions or features the software must have to prevent potential attacks or misuse.
- Security requirements baseline
The security requirements baseline is the minimum security guarantee of an information system, that is, the basic security requirements that the information system must meet. It is to find a reasonable balance point between the cost of security investment and the security risks that can be tolerated.
The full baseline = security capabilities + security strategies configured on security capabilities, which is the security capabilities used to meet the business availability, confidentiality, and integrity requirements, as well as the security strategies configured for business systems. For example
For internal systems, the security requirements baseline may include host vulnerability scanning and web vulnerability scanning to ensure there are no medium or high-risk vulnerabilities.
For the external release system, in addition to meeting the security requirements of the internal system, it also needs to meet the requirements of security design checklist, code audit, and manual security testing, etc.
For externally procured products, suppliers need to provide product safety proof materials, and include security responsibility agreements and emergency loss mitigation after-sales service clauses in the contract.
In addition, different organizations or companies may have their own security requirements baseline. For example, Huawei has refined its own security baseline based on the past ten years of experience in managing product security and referring to a wide range of external regulations, technical standards, and regulatory requirements. These baselines, together with other governance mechanisms, effectively ensure the security, credibility, and high quality of products.
- Business security requirements
The security requirement analysis of business scenarios needs to be determined according to the specific business environment and operations. For example, for business functions involving file uploads, personal information editing, and so on, it is usually necessary to focus on and analyze these functions, as these functions often have security vulnerabilities.
When conducting security requirement analysis, it is first necessary to clarify the main input factors. These factors may come from outside, such as cybersecurity regulations issued by the national or industry sectors of the enterprise; or they may come from inside, such as the security objectives of the enterprise's business processes and information systems.
In terms of analysis methods, commonly used ones include misuse and abuse cases, abuse frameworks, anti-models, cross-cutting threats, and security quality requirement engineering (SQUARE). Among them, the misuse case method mainly analyzes potential security vulnerabilities from the text descriptions of functional use cases and identifies corresponding threats, establishes threat cases, and builds security requirement cases for threat cases. The abuse case method is mainly used to capture threats produced by the interaction between attackers and the system, emphasizing the description of attackers, and mainly assessing the attackers' intentions and attack capabilities.
3. Declare security quality requirements:The security team also needs to declare the security quality requirements before the software is finally launched. These requirements can help the development team clarify their work goals and ensure that the software they develop meets all security standards.
- Internal systems:
- Host vulnerability scanning: Ensure that hosts do not have medium to high-risk vulnerabilities.
- Web vulnerability scanning: Ensure that web applications do not have medium to high-risk vulnerabilities.
- Systems for external release:
- Security design checklist: Follow the security design checklist to ensure the security of the system.
- Code audit: Conduct code audit to identify and fix potential security issues.
- Host vulnerability scanning: Perform vulnerability scanning on hosts to ensure there are no medium to high-risk vulnerabilities.
- Web vulnerability scanning: Perform vulnerability scanning on web applications to ensure there are no medium to high-risk vulnerabilities.
- Manual security testing: Conduct manual security testing to identify and fix potential security issues.
- External procurement products:
- Provide product safety proof materials: The supplier is required to provide product safety proof materials, including reports from third-party safety companies, code audit reports, mainstream scanner vulnerability scans, penetration test reports, and an open-source component list (the types and version information of open-source components dependent on the system).
- Security responsibility agreements and emergency stop-loss after-sales service: Include security responsibility agreements and emergency stop-loss after-sales service clauses in the contract to clarify the security responsibilities and response measures of both parties.
Common issues and challenges
In the SDL (Security Development Life Cycle), the security requirements phase is indeed a complex and challenging part.
- **Depth of security requirements exploration**: Sometimes, it may be difficult to accurately define and identify all security requirements for certain projects. This is because security requirements may be intertwined with business requirements, functional requirements, or other non-functional requirements, making it difficult to clearly separate and define.
- **Understanding and consensus on security requirements**: Within the team, there may be misunderstandings or inconsistent understanding of security requirements. It is crucial to ensure that all relevant parties, including developers, testers, project managers, and other stakeholders, have a unified and clear understanding of security requirements.
- **Requirement collection and analysis**: In the requirement collection and analysis phase, difficulties may arise because it is necessary to deeply explore product requirements to understand the security risks and threats involved. In addition, how to integrate security requirements with other types of requirements (such as performance, availability, etc.) is also a major challenge.
- **Change management**: In the subsequent stages of the project, there may be changes in requirements that may affect the original security requirements. How to properly handle these changes and ensure that they do not have a negative impact on security is a concern.
To effectively address these issues and challenges, the following measures are recommended:
- **Continuous security promotion and training**: Ensure that team members have a full understanding of the importance of security and regularly update their knowledge and skills.
- **Clear roles and responsibilities**: Set clear roles and responsibilities for the team to ensure that everyone knows their responsibilities in the security requirements phase.
- **Work closely with stakeholders**: Work closely with project managers, business analysts, designers, and other stakeholders to ensure that security requirements are considered and defined from multiple perspectives.
Summary
The SDL (Security Development Life Cycle) security requirements phase is a complex and critical process that requires a comprehensive analysis and organization of the system, full communication and cooperation with stakeholders, while considering the requirements of regulations and standards as well as the best practices in the industry.
评论已关闭