Always consider both security and convenience
Kanbe: What is your company's business and security operational structure?
Matsuda: Sansan is used by more than 7,000 companies, and Eight is used by about 2.8 million people based on profile registrations. Sansan is used by over 7,000 companies, and Eight is used by about 2.8 million people based on registered profiles. The service is 100% cloud-based, with more than 1,000 servers running behind the scenes.
I myself am in charge of managing company-wide security as a CSIRT, but each division has members who are dedicated to the operation and management of infrastructure. We have an organizational structure that ensures security by having infrastructure members concurrently serve as CSIRTs depending on their missions.
Kanbe: By working together with the members of the product team, you are getting them to see security as their own business.
Matsuda: Yes, we are a company with a strong commitment to security and convenience. Our corporate philosophy is "to combine security and convenience. Whenever we start something new on the product side, we would like to build a relationship where we can ask, "What do you think of CSIRT?" I would like to build a relationship with them so that they can ask me "What do you think of CSIRT? By doing so, we can formulate CSIRT strategies based on the movements in the field, and the field will be able to understand the CSIRT's policy.
Kanbe: Your company started using FutureVuls when the person in charge of infrastructure was using the open source Vuls. After that, we introduced the standard plan of FutureVuls to one of our divisions, and two years ago, when the CSIRT plan was created, we moved to a company-wide implementation.
Matsuda: Over the past few years, as the company has become more well known, the risk of becoming a target of attacks has also increased. we started using FutureVuls on the spontaneous initiative of a member in charge of infrastructure in our business unit, and we installed the standard plan in that business unit. After all, if you don't put a lot of effort into security at the beginning and make sure that standards and operations are in place, it can be extremely costly to do it later. So we moved to the CSIRT plan because the CSIRT is responsible for vulnerability management throughout the company.
Kanbe: FutureVuls Standard Plan is designed for vulnerability management within a specific team. When we developed the CSIRT plan, we received a lot of input from Mr. Matsuda.
Matsuda: Mr. Kanbe and the other members of your company listened carefully to our requests. I requested that they implement such things as triage functions, notification methods, and the ability to instantly centralize and display which software is on which server when something happens. Moreover, the speed with which they implemented these features was very fast, and I was impressed by their development capabilities. In fact, that was one of the key factors in our selection. Recently, when I requested that the authenticity of the attack code of a detected vulnerability be displayed on the screen, they implemented it immediately. I think the fact that this kind of feedback from the field level goes directly to the developers is one of the great things about FutureVuls.
Kanbe: To make the service more convenient for our users, we are constantly developing for improvement, and we are releasing version upgrades on a monthly basis. We will continue to evolve our services in the future.
Improved internal crisis management awareness and workload from 3 hours to 10 minutes
Kanbe: What changes have you actually seen since implementing the CSIRT plan?
Matsuda: Before FutureVuls, we were working very hard to gather information on vulnerabilities. Now, the quality of the work itself has improved, and the work hours have also been reduced considerably. Thanks to FutureVuls, we are now able to use our time properly, focusing on planning and formulating security strategies, which is what we should be doing as a CSIRT.
Also, although not 100%, I think the awareness of vulnerabilities among employees, developers, and engineers has changed. We now receive questions from engineers such as, "I found this vulnerability, is it safe?" I have also started to receive questions from engineers, such as "I found this vulnerability, is it safe?
Kanbe: I am glad to hear that. How about the effect of reduced workload?
In the division where we first implemented FutureVuls, we would have spent three hours a day on vulnerability management operations. If we had done that in all divisions, it would have taken even more man-hours. But with the introduction of the CSIRT plan, one of us in the CSIRT department only needs to spend about 10 minutes a day on it. That is how much more efficient it has become. In terms of specific work, thanks to the use of various functions, I would say that out of the 1,000 or so vulnerabilities we had before, we were able to eliminate about 900 of them in an instant. The remaining 100 vulnerabilities are prioritized and scrutinized, but the information necessary for the scrutiny is already displayed on the FutureVuls screen, so we can use that as the basis for our response, and there is no burden on us.
Kanbe: You have been using it quite effectively, and the CSIRT plan's auto-hide and auto-triage features automatically cross off the list of vulnerabilities based on rules determined by the CSIRT, so you can focus on priority, high-risk cases.
Efficient vulnerability management is essential in the accelerating age of change.
Kanbe: How do you operate on a day-to-day basis?
Matsuda: Basically, CSIRT members take the lead in checking vulnerabilities, but accounts are also issued to CSIRT members in charge of infrastructure in each division, so that the urgency of response and reference information can be shared at any time. In implementing FutureVuls in each division, we divide vulnerability management into two processes. First, we ask division members to always apply patches, and FutureVuls confirms this.
Kanbe: Tracking is also easy for the CSIRTs because they can instantly see on the tracking screen whether the patch has been properly applied.
Matsuda: The operational rules have also been designed to reduce the workload, so depending on the content of the notification, we may check for vulnerabilities every morning, or not look at them for a week. We have a flow. It is now much easier to determine whether a vulnerability needs to be addressed today, or whether it can be addressed at the next scheduled maintenance.
Kanbe: Finally, what kind of company would you recommend FutureVuls to?
Matsuda: I believe the key to vulnerability management is how to build a system that does not overburden daily operations. What I mean by that is, looking back over the past 10 years, the number of software applications has increased dramatically. This means that the number of vulnerabilities is much greater today than it was then, and by 2030, there will be even more software and even more vulnerabilities. In 2030, there will be even more software and even more vulnerabilities, and if the current management is too much, the operation will fail in the future. Therefore, I believe that the essential issue for vulnerability management is how to deal with vulnerabilities efficiently without spending too much time and effort. I think that many Japanese companies that are doing vulnerability management properly are still devoting a lot of time to management. However, considering the accelerating pace of change in this era, it is essential to reduce the burden as much as possible and create a system now that can be operated on a daily basis. I believe that FutureVuls is the most effective way to create such a system. I think the appeal of FutureVuls is that it is properly addressing the issues facing Japanese companies today.