Hacking Book | Free Online Hacking Learning

Home

sdl initial practice

Posted by harmelink at 2020-03-15
all

"In the software security development life cycle, the security requirements are not so good, with the characteristics of large input of manpower and not significant effect, but its role affects the security quality and cycle of the whole software. Before there is no systematic process, it can be tailored and necessary safety activities can be added according to the actual situation. "

01

-

Introduction

In order to reduce the loss caused by the safety problems and the cost caused by the rectification of the online safety problems, the safety work needs to be put in the front. In the stage of requirement analysis, the risk of software products should be evaluated to establish security requirements. Due to many factors such as multiple products and complex functions, project management not covering every business line, and fewer security team personnel, ROI is the most difficult problem. However, we can adjust measures to local conditions, with the help of defense in depth thought and implement it to this stage, to establish basic or general security requirements.

02

-

Safety target

The safety team shall publicize and implement the safety assessment process, put forward safety quality requirements and guide the output of safety requirements by participating in the project approval or requirement review meeting. So as to avoid the impact of security activities on the online release of business system, reduce and eliminate product security risks, and improve business security capabilities.

03

-

Safety activities

In the demand analysis stage, safety activities can include: safety assessment process publicity and implementation, putting forward safety requirements, and declaring safety and quality requirements.

1) Publicity and implementation of safety assessment process

The focus of project initiation is on product functions. At this time, it is not necessary to carry out detailed safety assessment process publicity and implementation. The members of the project team should be informed to focus on safety processes and nodes, especially the project (product) manager.

Safety inspection shall be included in each stage of self-study project

Security requirements > Security Design > Security Development > Security Test > release audit

There are set card points before the system is released and online

It needs to meet all safety requirements to be able to go online smoothly. Otherwise, it needs to go through a long process to find a number of principals and CTO to agree to take the green channel, but it needs to clarify the relevant principals and subsequent rectification plan.

2) Put forward safety requirements

△ safety requirements baseline

If it is not clear at the beginning how to establish a reasonable and effective baseline of safety requirements, the basic safety requirements can be summed up in reverse according to the "general" safety problems found in the subsequent safety activities, from the perspective of the difficulty of rectification and the long time to be invested, such as:

Domain name record No

HTTPS is mandatory for web system

Purchased products need to be delivered with safety related materials

△ analysis of security requirements for specific business scenarios

The analysis of security requirements in specific scenarios should be considered separately, and coverage issues will be involved here. Not all business scenarios need security requirements analysis. For example, the login and registration scenarios are common. In the case of no change, only a comprehensive security analysis is enough. The functions that do not involve sensitive operations and security requirements analysis do not need to be considered. For example, the functions that do not involve addition, deletion, modification, query and static display only need to be considered. The functions that usually cause security vulnerabilities need to be analyzed Focus on, such as file upload, personal information editing, etc.

3) Declare safety and quality requirements

Define the safety and quality requirements for the business system to be allowed to release online:

Internal system: it needs to meet the requirements of no high and medium risk loopholes in the host and no high and medium risk loopholes in the web;

External release system: it needs to meet the requirements of security design checklist, code audit, host missed scan, web missed scan and manual security test without high and medium risk vulnerabilities;

Externally purchased products: product safety certification materials shall be provided, and safety responsibility agreement and emergency stop loss after-sales service shall be included when signing the contract. Security certification materials generally refer to reports issued by third-party security companies, including code audit reports, mainstream scanner missed scans, penetration test reports and open source component lists (open source component types and version information on which the system depends).

04

-

Common difficulties

In the early stage of implementation, security needs will encounter more or less difficulties such as insufficient coverage and analysis points. Here are some common points for your consideration and discussion.

Insufficient business coverage

Although safety requirement analysis combines safety activities with project management, there are still cases that are not covered. Therefore, it is necessary to promote and assist the project management to solve the coverage problems (standardize the company's project approval process, increase personnel, etc.) or find other methods to make up the deficiencies, so as to ensure that all projects can be notified to the safety team.

New function point not covered

At present, only for new projects, there is no requirement for new function points or functional requirements changes of old projects. With the increase of subsequent team members and more mature automation scheme, it will be refined to function points on the basis of coverage.

Insufficient in-depth analysis of security requirements

It is mainly based on the common problems that need to be solved for a long time, and unified to the requirements analysis stage to make the safety requirements baseline. Specific to the safety requirements of each product is not deep enough, and subsequent pilot operation can be carried out for core products.

Long press identification QR code to communicate with me

More...

SDL initial practice

Opening chapter

Safety training

Infrastructure security construction

Automation function practice based on Fortress 1

Automation function practice based on Fortress 2

Automation function practice based on Fortress 3

Automation function practice based on Fortress 4

Enterprise safety construction

Enterprise safety construction demand

Brief introduction of enterprise security threat

Enterprise security architecture construction

Enterprise security project - Test Environment Intranet

Enterprise security project - GitHub information disclosure

Enterprise security project - SMS verification code security

Enterprise safety project - front end bypass special rectification

Another hidden danger of business security

Security risks of application release

Safety test in the eyes of Party A

Appreciation of security loopholes

Safe operation and maintenance of those holes

Security business holes

Emergency response: redis mining (Defense)

Emergency response: redis mining (attack)

Emergency response: redis mining (end)

Penetration testing techniques

That simple Threat Intelligence

Android app data storage security

Collect "technical work" in SRC information

Routine penetration bottleneck, divergent thinking breakthrough

Play snake series together

Python Arsenal

Vulnerability scanner asset handling

Python code audit weapon I

Python code audit weapon II

Nodejs code audit weapon

Learning approaches to fortify loopholes

Personal growth experience

C3 sense of participation in Security Summit

Secret script for improving cognitive efficiency