In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-27 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Network Security >
Share
Shulou(Shulou.com)06/01 Report--
I. Preface
From the point of view of the product manager, this paper analyzes the safety responsibility of the product manager, the connotation of product-driven safety, the working content, the working method, the required safety resources, and the safety workload of the product manager. It is hoped that all product managers will have goals, methods and resources to promote product safety construction without psychological burden.
Second, background
Security is a part of the natural attribute of software products. "No security is not financial". For financial software products, security is particularly important, because customers can always associate their financial asset security and personal information security from various security loopholes. In the past, I occasionally heard colleagues complain at some security salons or summits, "Information security is important to say, secondary to do, and don't be busy." The reason behind the complaint is very complicated, one of which is that the product manager has weak safety awareness and is not clear about how to promote product safety construction. for example, do not pay attention to product safety attributes, product safety requirements are not clear, product safety resources are insufficient, product safety construction is impossible to start, and so on. From the point of view of the product manager, this paper discusses how to promote the safety construction of the product from the dimension of the ability of the product manager.
As we all know, security is a natural attribute of software products. From the point of view of product definition and planning, product managers have an unshirkable responsibility for product safety, but how to perform their own security duties? the industry has not yet given a clear and feasible action plan.
At present, the security requirements of software products are usually based on the professional common sense of developers and security personnel, such as the five-element analysis method of sensitive information commonly used in the industry:
This method is simple and easy, but it often does not cover all sensitive information, such as
The user's multi-system user data association ID (Super ID). Multimedia data such as audio and video in the process of transaction. A variety of unstructured document data, such as contract scanners. Content such as user behavior profile data and so on.
This information is valuable and sensitive data, which obviously does not fall within the scope of the above-mentioned sensitive data, but there are often no clear protection requirements. Starting from a specific business scenario, the product manager has the most say in the scope of sensitive data and its business value.
Third, the embarrassment of the security department
The above-mentioned five-element analysis method of sensitive information is a typical safety-driven product method, that is, the security department promotes the safety work of the product-related teams. This model has many disadvantages, such as:
The safety requirements may be incomplete, and professional common sense cannot replace the in-depth analysis of specific business scenarios; the safety work resources of each team of the product cannot be guaranteed, and the R & D team has reason to believe that the safety team interferes with the R & D plan. when the R & D progress and resources remain the same, the additional workload is increased; the security department usually does not have the opportunity to participate in the formulation of the R & D plan, and the product R & D plan is out of touch with safety. Security teams are highly dependent on the right to speak, and mandatory drivers are often in a dilemma.
(figure 1 Security driven products)
Numerous safety practices show that there are many drawbacks in the ideas and methods of safety-driven products. If, on the contrary, product-driven safety allows product managers to clarify their own safety responsibilities and actively promote product safety construction, it will have a contrasting effect.
Fourth, the rationality of product-driven safety
Product-driven safety does not mean that the product manager plays a single role in promoting product safety construction, but that the product manager actively assumes the corresponding product safety responsibility and actively works with the safety department to promote product safety construction. from single-wheel drive of safety-driven product to two-wheel drive of product drive safety. As shown in the following figure:
(figure 2 product-driven safety)
Security is a natural attribute of software products and part of the responsibility of product managers. At the same time, as the baton of product planning evolution and R & D resource investment, the product manager can ensure the appropriate investment of the R & D team in safety. Through simple analysis, it should be a very reasonable logic for product managers to assume product safety responsibility and actively promote product safety construction.
How does the product drive safety
Product managers are willing to do a good job in product safety and may ask the following questions:
In terms of content, what kind of safety work does the product manager need to do; in terms of ability, what kind of safety capability does the product manager need to have in order to complete these tasks; in terms of methods, how to do these safety work? can not only take into account the product business function research and development and safety, but also keep the R & D agility and project management process unchanged Security resources, what kind of safety support can be obtained from the security department and other departments to improve the efficiency and effectiveness of their own and R & D team's safety work, and reduce the ability threshold of safety work; work burden, will safety work make product managers work hard and affect their quality of work and quality of life.
For the product manager to solve the above problems and eliminate their worries, it is possible for the product manager to embrace safety and fundamentally solve the contradiction between R & D and safety.
VI. Safety work of the product manager
The safety work of the product manager is roughly as follows:
Identify product safety requirements; ensure safety R & D resources, set safety work in R & D plan, and allocate sufficient safety R & D resources; promote the safety capacity building of R & D team to ensure the implementation of safety work in R & D plan; integrate surrounding safety resources to ensure that the safety work in the R & D plan is in place.
(figure 3 the safe work of the product manager)
6.1 identify product safety requirements
Product security requirements refer to the data security requirements, business compliance requirements and business continuity requirements that software products need to meet from a business point of view, which is a part of business security requirements. The product safety requirements described in this article usually include:
The security protection requirements of business data carried by products are mainly concerned with the confidentiality and integrity of business data. Safety supervision requirements of product-related information, such as grade protection, industry information security supervision and so on. The business continuity requirements of the product carrier. Since the task is usually led by the data center or the operation and maintenance department, this article will not describe this content.
(figure 4 Product safety requirements)
6.2 Product data security requirements
The security requirement of product data means that the system security system should ensure that the right users access the right data in the right way at the right time and place, and ensure the confidentiality, integrity and availability of the data they carry. That is, the system security system should ensure that the list of legitimate access behaviors similar to the whitelist, as long as the behaviors that fall within the scope of the list are legal, and the behaviors outside the whitelist are inappropriate data access behaviors by default, which requires security measures to prevent, which is called blacklist behavior in this paper.
Because the blacklist behavior is usually heikegongji behavior, the analysis and listing of its typical behavior requires a strong gongfang technical background, which is not within the scope of the ability of business personnel and product managers, and needs safety experts to analyze according to the product running environment. Therefore, this paper requires that the product manager's clear product safety requirements are usually the whitelist part, and the blacklist part requires the product manager to organize safety experts and R & D experts to cooperate clearly. The main goal of the various security measures included in the product design is to ensure that the whitelist behavior must be successful and that the blacklist behavior must be prevented, monitored and audited.
From the perspective of business security, after defining the legitimate data access behavior, we also need to have data access behavior audit means to help the business ensure the correctness of the access behavior and audit the illegal data access behavior.
(figure 5 Product data security requirements)
Based on the above analysis, the clear whitelist behavior list can be achieved only by knowing the relevant information of the business model, and there is no ability threshold for the product manager. The data that the product manager needs to be clear during the process includes:
In the process of defining the above information, the product manager should follow the following two principles:
The designer can design the permission management and access control model according to the whitelist, and the tester can use the whitelist as the data security test baseline. Any test that violates the whitelist is found to be the system's security bug, such as:
Sensitive data has not been desensitized. Extra data manipulation rights. Horizontal or vertical data access ultra vires. The log trace of the key behavior is missing. 6.3 Compliance requirements
Compliance requirements refer to the restrictive requirements on service delivery model, data security and business continuity due to the location of the system, the service network and the relevant departments of the customer's region or country. The main regulatory requirements currently faced by the company's system include:
In 2019, the relevant state departments put forward a series of regulatory requirements related to the collection of personal information by App:
After the product manager lists the compliance requirements and the Ministry of Security gets the authoritative explanation from the relevant departments, communicate with the product line to suggest the design of various safety measures, which will meet the IT safety compliance requirements to a large extent. The related requirements of grade protection are common requirements for all systems, which do not need to be listed by the product manager, and can be explained directly by the Ministry of Security.
The author will explain the definition and maintenance methods of specific security requirements through other articles.
VII. Analysis and Construction of Safety ability of Product Manager
The main test of analyzing the safety work of a product manager comes from four lists that identify business security requirements. The analysis of related security capabilities is shown in the following table:
The capabilities required by the product manager for other security development work are analyzed as follows:
To sum up, if the product manager wants to perform the relevant safety duties, the necessary ability and quality is to have a high safety awareness, to be able to understand the relevant safety basic concepts, and there is no too high ability threshold, through certain safety training, the product manager can fully meet the corresponding ability requirements.
VIII. Product safety research and development methods
In view of the current general situation of agile development and DevOps development, security development should not stick to the outdated experience of combining waterfall development. Because of the long development cycle and sufficient resources of the waterfall, arranging some sporadic security activities in the complicated planning activities will not cause obvious delay pressure and resource pressure. While agile development and DevOps development require rapid response to user requirements, while taking into account the quality and efficiency of development, if overweight security development activities are set in the iterative plan, iteration and development are easy to lose agile characteristics.
In order to implement the concept of secure development in agile and DevOps development, the following principles are recommended:
Security development activities are lightweight. Lightweight can be achieved through instrumentation and automation to minimize labor-consuming and time-consuming security development activities; security development activities are decentralized. Those security development activities that can not be lightweight in the short term are decomposed and dispersed into multiple iterative cycles; security development activities are parallelized. Parallel security development-related activities with other activities, such as shentou testing is usually arranged in the last part of the test, to avoid a single round of shentou testing can not cover those parallel repair points, of course, shentou testing can also be multiple rounds to make up for this situation, but usually resources are not allowed. In fact, the problem that this synchronous repair leads to the decline of shentou test coverage can be made up for through good communication and team culture construction. Optimize the existing agile development processes and tool platforms related to DevOps, so that security experts can fully participate in the project, improve the efficiency of security development communication, and quickly obtain security feedback. It is everyone's responsibility to integrate security experts into agile development and the construction of DevOps culture. Security experts can give full play to the roles of coaches and goalkeepers, so that everyone on the team has the ability to perform their own security duties. Security experts control the quality of safety deliverables at the right time. Planning and layout of security infrastructure in advance, such as identity and rights management system, SSO system, encryption and decryption platform and SDK, log analysis and monitoring platform, full traffic detection platform, etc., to standardize, service and platform security measures, reduce the capability threshold of security design and coding, and replace most of the security tests of applications carried by the facilities. It can effectively reduce the workload of security testing.
Examples of scheduling for some security development activities are as follows:
The term "multi-iteration execution" in the above table refers to the execution of multiple iterations at intervals in accordance with certain requirements. Security activities for multi-iterative implementation require the establishment of an implementation baseline, which has no standards to refer to and needs to be gradually explored and adjusted according to the actual situation of each product line.
The trigger scenarios and baselines of security activities are not fixed, and with the improvement of team security capabilities, automation and instrumentalization, multi-iterative security activities may be transformed into each iteration; not all identified security activities must be carried out, all based on controlling major security risks and not dragging the iterative project back. Usually, the security team will communicate with all product managers and project management many times, and propose a multi-party basically recognized security activity trigger scenario and baseline table for product managers' reference.
IX. Product managers get support from security resources
When performing various safety duties, the product manager needs the security services and support provided by the surrounding departments including, but not limited to:
Analysis of safe work pressure of Product Manager
The safety work stress analysis of product manager is shown in the following table:
The above table describes the main tasks that a product manager may encounter, but not all of them. On the whole, it will increase the workload of the product manager, but it will not cause obvious work pressure.
Summary
The product manager is responsible for product safety, indicating product safety objectives by defining the whitelist of product safety requirements, establishing safety research and development plans, promoting team safety capacity-building and coordinating surrounding safety resources to achieve product safety landing.
After a brief safety training, the relevant work is within the scope of the product manager's ability, the workload will not cause psychological pressure on the product manager, and the flexible safety activity trigger standard will not affect the agility of research and development. The author sincerely hopes that all product managers will embrace safety boldly and bravely, and continue to push product safety to the new best part together with the Ministry of Security.
XII. Perception
In the author's work experience, in order to promote the safety work, the security department always wants to "hug the thigh" legally, hoping to promote the safety work with the help of external forces, but does not notice the product manager's "thigh" and only needs to awaken its safety consciousness. this "thigh" is not only strong and powerful, but also has a strong motivation to actively embrace safety.
In cooperation with product managers, it is easy for the Department of Security to establish a regular safe landing mechanism based on iteration and development, while cooperation with other departments, such as compliance or legal, often promotes the landing of specific security work only at specific stages. It is recommended that you apply security peers and product managers to communicate more, because: product managers are the "thighs" that our security department needs to embrace most!
Author: Wei Guohong Guo Jianwei
Source: Yixin Institute of Technology
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.