<div dir="auto">You keep avoiding the specific question of how all your ideas are going to prevent attacks such as wannacry.<div dir="auto"><br></div><div dir="auto">According to this, the wannacry attack vector is a 32 bit integer being subtracted from a 16 bit integer, which is simple enough to do unintentionally with C.</div><div dir="auto"><br></div><div dir="auto"><a href="https://www.google.com.au/amp/s/www.theregister.co.uk/AMP/2017/05/16/microsoft_stockpiling_flaws_too/" target="_blank">https://www.google.com.au/amp/<wbr>s/www.theregister.co.uk/AMP/<wbr>2017/05/16/microsoft_<wbr>stockpiling_flaws_too/</a><br></div><div dir="auto"><br></div><div dir="auto">How is you "missing" security plane going to audit host OS and application code for these coding errors?</div><div dir="auto"><br></div><div dir="auto">As a side note, what you're describing sounds like IP security options (RFC1108) and a multi-level secure OS, which are both old and tested ideas.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Mark.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 May 2017 9:45 pm, "Paul Wilkins" <<a href="mailto:paulwilkins369@gmail.com" target="_blank">paulwilkins369@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Mark,<br></div>That's a good question and I'm glad you asked.<br><br></div>Once you have a security plane for your data, you can assign profiles according to the data's provenance. Integrate this with your OS security plane, including as an input to your virus scanner, with a view ultimately to preventing control plane actions (like encrypting all your data) that emanate from untrusted or untrustworthy sources from ever being allowed write access outside of the mail spool.<br><br></div><div>The basic problem being, the OS treats a control plane action on a socket the same, regardless of you're logged in from iLo, or coming remote from Ukraine. Firewalls are essentially creating an artificial security plane, but it's a bandaid, and requires you architect your network to channel all your traffic through a chokepoint. If a socket's security profile was part of the API, the profile would follow control actions up the stack, and you'd get end to end security.<br></div><div><br></div><div>Kind regards<br><br></div><div>Paul Wilkins<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 May 2017 at 11:12, Mark Newton <span dir="ltr"><<a href="mailto:newton@atdot.dotat.org" target="_blank">newton@atdot.dotat.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On May 14, 2017, at 3:34 PM, Paul Wilkins <<a href="mailto:paulwilkins369@gmail.com" target="_blank">paulwilkins369@gmail.com</a>> wrote:<br>
> My feeling is we could see Cisco invent a means of allocating SGT tags by BGP community extended to 64 bits, and some integration of 802.1x to deliver Trustsec to the desktop. The problem being, this implies separate routing tables for different security profiles, being necessarily the case, which is not something ipv6 could be made to support.<br>
<br>
</span>How, precisely, would that make any difference to the ransomware attack that sparked your creation of this thread?<br>
<span class="m_8547351381391591648m_-5845101916911226352HOEnZb"><font color="#888888"><br>
  - mark<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net" target="_blank">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" rel="noreferrer" target="_blank">http://lists.ausnog.net/mailma<wbr>n/listinfo/ausnog</a><br>
<br></blockquote></div></div>