Translated from 日本語 • View original 
"5.7 Threat Intelligence"
"We must collect and analyze information related to information security threats and build threat intelligence."
How do you gather information about potential threats and take action?
Here is an example of what I have considered and implemented.
IPA, Automated Posting of Security News
We automatically collect product vulnerability information and warnings from IPAs such as phishing and share them openly with the entire company. I think this is the first place to start.
Various patches will also be applied at this time.
News about ransomware and information leakage damage can also be used as examples.
Dark Web Monitoring
Check if your domain is under threat.
We contracted with a dedicated service and checked for leaks of our own domains by running APIs regularly.
If a problem occurs, take measures such as changing the password.
Vulnerability Management
This is the most troublesome measure.
The number of CVEs in FY2024 exceeded 40,000, making it difficult to monitor and apply them to your own assets every day. Here are some of the measures we are taking.
- Alert response with Dependapo
If you enable Dependabot on Github and get a security alert, you will automatically post it to the chat tool.
We determine the priority based on CVSS scores, KEV information, and the importance of our assets, which is called triage. - Vulnerability response from external sources
We collect and analyze manufacturer releases, alerts from IPAs and other organizations, and more recently, CVE trends called Intruder. Triage is also carried out here.
Once the priority is determined, ask the person responsible for each project to take action.
Regular progress checks are also important.
ASM(Attack Surface Management)
This is a method of investigating your company's IT assets that are accessible from the outside.
Unnecessary ports are not open, or vulnerable software is not used.
We use tools to investigate our domains.
Establishment of an Internal Trouble Reporting Form
We thought that we could collect useful information from within the company, so we set up a trouble report form.
We have set up a window where you can report any minor troubles, and we have shared information regardless of development, office work, sales, or occupation.
Most of these incidents are not classified as ISMS incidents, but even minor human errors or application configuration leaks can be prevented before major incidents occur by sharing countermeasures before they become accidents.
Evidence
All of the above measures are automatically posted and shared in the chat tool, so you can leave a trail as a trail.
In the past, traces were often managed in Excel, but I often neglected to update them or became obsolete, so I made it an easy-to-operate method.
These traces will eventually be summarized on the ISMS performance evaluation sheet at the end of the fiscal year, and what measures have been taken and what kind of effects have been achieved will be evaluated and explained to the management level.
Evaluation During Screening
We have tried many measures, but I don't think it is necessary to do it all at once in the actual examination.
The important thing is whether there is a flow to evaluate and improve the process and results after taking measures for management measures.
As an aside, the last incident report form was very well evaluated in the external review.
It seems that not only the points for improvement, but also the good points recently are reported as review results.
It was worth doing.
See you next time on other new management measures.