Vulnerability Management e-stream

Vulnerability Management e-stream

0x01 Preface

This article mainly aims to share and record some of your own growth. If something is not well written, I hope you can still make an ax. In the early days of Vulnerability Management, I personally felt quite disgusted. In particular, when various emails are sent and finally traced back to the security risks that have occurred in a system, the system is overwhelmed, and even the source email cannot be found... Then we have this article.

0x02 original method

The original method is quite painful. There are many problems and various delays. For example, R & D may ask if this vulnerability is serious. Why do we need to fix it immediately? For example, this vulnerability is a normal logic, and you need to modify it on the product side, or the vulnerability cannot be understood, or the information you provide is incomplete. It may take two to three days or even longer to fix a vulnerability due to these problems.


However, for us, this is 0 tolerance. So we need to push it. We waste a lot of saliva to explain to these people. If the title is relatively high, it may be better to operate. If it is just the most basic level, it may be .... There is another problem. I don't know if other friends have ever encountered it, that is, suddenly the system under your jurisdiction is cracked up one day, and then there may be many unknown risks inexplicably, then the leaders will talk to you and ask you what risks and records have occurred in this system? .... Then you can say that there are emails... Then the leader said, "let's figure out these things... Then: xx ^ & * ($ % ^ &

0x03 Improvement

After discovering this problem, I tried to change the current situation, starting from communication needs, consulting R & D, and the departments we need to serve. What should we do to achieve the best. Gradually, I began to design an automated approach to improve overall efficiency, including process issues. I initially think that this process does not need to be too complicated, and I think this is consistent with the concept of express delivery management, "must be reached 』. Just do what you want, and sort out the methods that I think are more qualified:


It is not difficult to think of achieving this goal. At least it is troublesome to get involved. However, if we can make this thing, it is also an achievement.

0x04 convert to code

Now that we know the target, we can try to simulate this scenario to achieve this effect. Of course, it is a great honor for you to get the support from the above questions. After sticking to your opinions, you have gained the greatest support.

My design is as follows:

When a vulnerability is detected and reported (by initiating a vulnerability through the security platform => R & D receives the vulnerability information email), he can log on to the platform to view the details or learn the details of the vulnerability by email. After confirming the vulnerability, click "known" to send a request to the API of the security platform and update the processing status of the vulnerability. (Security submission => platform sending => R & D)


After you click "know", R & D again receives an electronic stream initiated by the platform, prompting you that the vulnerability is being executed. After the vulnerability is fixed, R & D proceeds to the next step. (Platform development => R & D)


When you confirm that the vulnerability has been fixed, click "fixed" to go to the vulnerability review process. (Platform development => R & D)


After confirming that the vulnerability has been fixed, the security personnel review the vulnerability and launch the grayscale test environment. (Platform release => secure collection) Here, security personnel have two options: "confirm to fix" and "vulnerability recall". In some cases, vulnerabilities may not be completely repaired, as a result, it can be reused. Therefore, the vulnerability may be rejected. (Platform sending => secure receiving)


After the vulnerability test is completed, R & D or O & M will complete the Code Synchronization Based on the actual situation. After all, click "synchronized environment" to complete the vulnerability repair process. (Platform development => R & D/O & M)

The whole process is achieved through e-streams, and the mail method is also used, but it can be clearly seen that the entire vulnerability processing process is very clear and intuitive. At the same time, Mom no longer worries that the vulnerability history cannot be traced back. Data can be queried at any time. Visual Management ~

Shows what Vulnerability Management is like on the platform.



0x05

Token's validity period problem: first, if you send and send tokens by email, there will inevitably be a validity period problem. You need to set the token to a reasonable time range, based on your actual situation, I set the token to be valid within one day.

Risk Description problem: the above description is somewhat different from the actual version. After all, there is a need for confidentiality. You need to clearly communicate with R & D, O & M, and your own eldest brother, understanding how to do it is the most reasonable.

In terms of the risk processing time, it is best to establish an association in the system. For example, if the risk is not fixed after a certain period of time, a reminder should be sent to R & D in advance. After all, sometimes the risk may be forgotten, it is best to have a certain reminder function, which will be more friendly. (I still pay close attention to user experience)