Whitelist of IPs and Ranges for Validating User Phishing Events
回答済み
In order to reduce 3rd party attack surfaces KB4 customers are increasingly going to find themselves in a position where it is not prudent or good security posture to bypass all of their email scanning and validation mechanisms. In this post-SolarWinds environment I would like to propose a whitelist approach to User Phishing Test Event validation/reporting/actions.
Customers should be able to provide a list of Known IP addresses and ranges under which their users are known to operate. The system should continue to log all events outside of these ranges but not apply them to smart group or risk score calculations. Once a customer creates a whitelist of known IPs/Ranges screens such as the Dashboard, Campaign Overview, Campaign Users should only include events from those known IP addresses. Users should be able to review all events by turning of the whitelist filtering or preferably in an all recorded events report so they can check for unknown or unauthorized outside access.
This will allow users to continue to validate/scan/protect ALL INBOUND email while at the same time benefitting from the great services that KB4 can provide.
Through testing we have already validated that KB4 is using last in tracking for user events. Given this information a vulnerability scanning system can trigger an event such as an open and then click with one or set of IP addresses. If the human user then actually performs events the values get updated with a new IP and time stamp.
Allowing customers to specify the IPs that constitute valid user actions provides the following benefits:
- Customer's do not have to weaken their security posture to use your product.
- Customer's gain additional information to help them identify unauthorized 3rd parties accessing their emails. (IPs not on the whitelist are still logged and can be investigated if unknown)
- Customer's can use your data to identify email access on unauthorized devices.
Queries and data warehousing should be minimally impacted by a whitelist as it can be added as an optional filter broadly across queries. WHERE ip NOT IN ips {xxx.xxx.xxx.xxx, ... } You could choose to segment this data as it come in or on request.
サインインしてコメントを残してください。
コメント
5件のコメント