background:
At present and in the future, there are three sources of safety requirements review
1. The line of business to implement SDL: requirements review is a link of sdl
2. The business party has requirements on safety and hopes to conduct a safety review and give safety advice
3. Important projects, although SDL is not implemented, the safety team still has safety requirements for them, and safety reviews are required;
(The coexistence of the three sources is also due to the lack of sufficient human resources and insufficient maturity of security capabilities (such as automation, operations, etc.). SDL cannot cover all lines of business, so there will be the above sources;
Purpose and outlook
Among them, the second kind of "business line is going to be safe, let us do a safety review, give safety advice" The communication cost is still a little high, we have not many resources
If there is an online mouth similar to a work order, it will be more convenient and efficient, reduce costs, and will certainly attract more people and projects that are willing and willing to conduct safety reviews;
After the tools, processes, systems, and culture are mature, all three sources can be aggregated and online;
Implementation plan:
The existing common places that can be realized are:
1. Jira: Under the security requirements project, each business party will describe the needs and scenarios that need to be reviewed, and the security personnel will perform the scheduling and review operations:
Advantages: Intuitive progress and overall review requirements
Disadvantages: The content template needs to be generated, and the fields cannot be conveniently "required" in the template;
However, new properties can be considered;
2. Work order: Use the existing work order,
Advantages: field constraints are optional, notifications are associated with spikes, and timely
Disadvantages: overall and progress statistics are not intuitive;
Work Order Design
1. Provide entrance in ticket
2. The work order field is designed according to the needs of the review,
Requirement name, link, description, remarks
(Need to be constantly improved and added)
3. Workflow: Approval (application of demand-side employees to fill out-corresponding leader review confirmation and submission)-acceptance (security requirements review interface person acceptance)-processing (security requirements review resource allocation, confirmation reviewer-reviewer acceptance- -Reviewer processing) -Complete-Notification (the above personnel are notified)
It can be simpler in the early stage, and the person who fills it needs to fill in-"Security personnel review-" Security personnel accept processing-"Feedback
4. Script synchronization:
- In the approval process, after the leader reviews and confirms, the work order script is simultaneously synchronized to the directory set by the wiki (security requirements review-demand pool, the new file name is "requirement name (to be reviewed)")
- After accepting, create a new task tracking on jira
Follow up
Review automation:
Docking threat modeling tool, automatically generate threat list
According to the threat list, corresponding to the security knowledge base, remediation plan, etc., a preliminary security review and recommendations are automatically generated
Security recommendations / programs can be reused-"Automatically given + manual review
---------------------
After effect:
After being realized in the form of work order, it saves unnecessary inquiry time, directly mentions the demand, and communicates vaguely