<div dir="ltr">Hi guys,<div><br></div><div>Please find my thoughts from our discussion few hours ago, regarding &quot;Sub Topic 4 – Future Challenges&quot;, i believe the below is limited in scope and achievable with a reasonable effort, please feel free to consider if you think suitable, thanks.</div><div><br></div><div>-------Start-------</div><div><div>1-Performance security (SSR2 scope)</div><div>Issue high level recommendations towards ICANN technologies(routing, switching, computing environments, DNS related services) resources utilization (Traffic, processing/power/memory utilization, ...)</div><div>To do so we need to:</div><div><span style="white-space:pre-wrap">        </span>-identify a list of the types of technologies used by ICANN</div><div><span style="white-space:pre-wrap">        </span>-recommend forecasting techniques to be used by ICANN to determine future utilization </div><div><br></div><div>-ICANN role in return: Recommendations need to be considered in future technological planning or architecture designs by ICANN.</div><div><br></div><div>2-Technology selection security (SSR2 scope)</div><div>Issue high level recommendations on:</div><div><span style="white-space:pre-wrap">        </span>-Vendor security technology evaluation process (how to test solutions)</div><div><span style="white-space:pre-wrap">        </span>-Vendor security technology selection process (how to select a solution)</div><div><span style="white-space:pre-wrap">        </span>-Vendor security technology implementation process (what vendors need to do when deploying solutions)</div><div><span style="white-space:pre-wrap">        </span>-Vendor security maintenance process (how vendors should maintain their solutions)</div><div><span style="white-space:pre-wrap">        </span>-Vendor responsibilities and SLAs (patching vulnerabilities, technology development/deployment)</div><div><span style="white-space:pre-wrap">        </span>-Vendor accountability for security problems</div><div><br></div><div>-ICANN role in return: Selection recommendations need to be considered in future technology selection processes employed by ICANN</div><div><br></div><div>3-Threat intelligence (SSR2 scope)</div><div>Issue high level recommendations on:</div><div><span style="white-space:pre-wrap">        </span>-The need for an ICANN threat intelligence team</div><div><span style="white-space:pre-wrap">        </span>-The need for ICANN to have established communication with top threat intelligence sources to know about the latest threats</div><div><span style="white-space:pre-wrap">        </span>-The need for adapting threat intelligence internally, to identify attacks and threats accordingly</div><div><br></div><div>-ICANN role in return: Threat intelligence recommendations to be adapted by ICANN towards enhancing blocking of cyber attacks, identifying causes of new breaches, and knowing about the latest threats endangering similar organizations.</div><div><br></div><div>NB1: Recommendations provided should be vendor/technolgy neutral, as to be valid for future utilization</div><div>NB2: issues of ddos, route injection all fall under “Sub Topic 3 – DNS SSR” as they are issues probably currently being dealt with. What is not dealt with, is how they could be used in the future, which falls under threat intelligence. I do not believe should predict protocols misuse options through new vulnerabilities, that has an unlimited scope.</div><div>-------End-------<br></div><div><br></div><div>Regards,</div><div>Amin</div></div></div>