If only there were some *principle* to guide operators in better understanding when it might be worth spending their time blocking something that is not a *specific credible threat*
Oh wait... https://en.m.wikipedia.org/wiki/Robustness_principle Now, where there is a specific, credible threat *absolutely* block what you know. Otherwise, kernels, even on lightbulbs, are really good at ignoring packets. Otherwise *you* are the DOS attack --ckg On Fri, May 26, 2023, 10:31 Andrew Campling <andrew.campling@419.consulting> wrote: > This is a really good thread! > > > > For me, it highlights that there appears to be a gulf in understanding, or > at least working assumptions, between developers and those responsible for > network (public or private) security. I suspect that gulf might narrow > somewhat if developers faced some of the same consequences that enterprises > and public network operators face in the event of security breaches – I’m > thinking here about those with compliance obligations such as the finance > sector, those in areas defined as part of critical national infrastructure > and those covered by more general regulations such as NIS2. > > > > Greater involvement by enterprise and public network CISOs would help > inject more understanding of current practice security and operational > considerations into protocol development activity to augment the input of > those within this community that also have that knowledge. For example, it > would be good to see the reaction of CISOs to suggestions that security > should be left to hosts / endpoints rather than using a defence-in-depth > approach which also employs network and perimeter defences, looks for > indicators of compromise etc. > > > > Given the relative lack of diversity within the IETF community, hindsight > suggests to me that it would have been great to see one or more > IETF-sponsored panel discussions at events like the recent RSA Conference > to debate some of the points raised on this thread with the wider security > practitioner community, many of whom don’t follow developments at the IETF > (I can confirm this latter point from personal experience as I asked other > attendees at RSAC 23 and found less than a handful of people that had > involvement in the IETF, either directly or via a team member). > > > > Andrew > > > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >
_______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
