Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <20161108035148.2904b5970...@rock.dv.isc.org>, 
Mark Andrews  wrote:

>* Deploying regulation in one country means that it is less likely
>  to be a source of bad traffic.  Manufactures are lazy.  With
>  sensible regulation in single country everyone else benefits as
>  manufactures will use a single code base when they can.

I said that too, although not as concisely.

>* Automated updates do reduce the numbers of vulnerable machines
>  to known issues.  There are risks but they are nowhere as bad as
>  not doing automated updating.

I still maintain, based upon the abundant evidence, that generallized
hopes that timely and effective updates for all manner of devices will
be available throughout the practical lifetime of any such IoT thingies
is a mirage.  We will just never be there, in practice.  And thus,
manufacturers should be encouraged, by force of law if necessary, to
design software with a belt-and-suspenders margin of safety built in
from the first day of shipping.

You don't send out a spacecraft, or a medical radiation machine, without
such addtional constraints built in from day one.  You don't send out
such things and say "Oh, we can always send out of firmware update later
on if there is an issue."

>From a software perspective, building extra layers of constraints is not
that hard to do, and people have been doing this kind of thing already
for decades.  It's called engineering.  The problem isn't in anybody's
ability or inability to do safety engineering in the firmware of IoT
things.  The only problem is providing the proper motivation to cause
it to happen.


Regards,
rfg

Re: Omaha NE link costings

[Geordie Guy]

Thanks everyone who replied, I've got rough idea now.

Geordie

On Mon, 7 Nov 2016 at 08:47 Geordie Guy  wrote:

> Hi list,
>
> I'm a NOC lead for an Australia-based insurance company and I've been
> asked for quick indicative costing for a 100Mbps symmetrical link to an
> acquired business in Omaha. I've not dropped links into that area before
> and have no idea of rough costs.  Could someone who's bought (or sold) an
> Internet link in Nebraska drop me a line off-list with what the cost was so
> I can give rough figures?
>
> Geordie
>

Re: Spitballing IoT Security

[Mark Andrews]

In message , Pierre Lamy write
s:
> On 30/10/2016 12:43 AM, Eric S. Raymond wrote:
> > Ronald F. Guilmette :
> >> Two kids with a modest amount of knowledge
> >> and a lot of time on their hands can do it from their mom's basement.
> > 
> > I in turn have to call BS on this.  If it were really that easy, we'd
> > be inundated by Mirais -- we'd have several attacks a *day*.
> > 
> 
> It's not easy, Mirai was closed source until the actor released it. We
> see a pattern again and again, where the bad guys find a private
> monetization strategy, milk it, and get out before too much attention is
> focused on just them. By dumping the code, the Mirai actors obfuscate
> attribution.
> 
> Now that the code is public, we see a huge surge in dumb & pointless
> attacks against gaming/mod sites, Dyn, public schools and so on. We also
> see bad code "improvements" which were recently referenced.
> 
> http://motherboard.vice.com/read/wannabe-hackers-are-adding-terrible-and-stup
> id-features-to-mirai
> 
> The long term problem isn't any manufacturer or Mirai, it's going to be
> the long tail of IoT devices that never see a patch, deployed by people
> who don't know anything about security (nor should they need to... flame
> suit on). When millions of any type of device are put online, times
> thousands of products, it only takes one bad guy's "a-ha" moment for
> this to happen again. They'll milk it for a while, the attack
> vector/method will get pushed down to the skid level, and we'll see a
> massive increase in un-targeted attacks by those script kiddies until
> the cycle repeats. There's an endless fresh supply of script kiddies.
> 
> While I agree with BCP38 etc, it wouldn't have prevented Mirai.
> Self-update functions at some point for these devices are going to get
> borked as well, such as a company going bust or forgetting to renew
> their auto-update target domain. If you can't get (thousands?) of major
> operators to deploy common sense security configurations, how will
> similar best practices be implemented by tens of thousands of
> manufacturers? Putting device regulations in one country won't impact
> the rest of the internet's connected devices either.
> 
> Solutions...? Someone's going to have to take out a hammer, not a
> scalpel, for these issues.

Actually the way forward is to not look for a magical solution that
will stop all evil but to deploy what you can where you can.  This
reduces the problem space.

* Deploying BCP38 means you are no longer a source of spoofed traffic.
  It doesn't help with all issues but it does with some.

* Deploying regulation in one country means that it is less likely
  to be a source of bad traffic.  Manufactures are lazy.  With
  sensible regulation in single country everyone else benefits as
  manufactures will use a single code base when they can.

* Automated updates do reduce the numbers of vulnerable machines
  to known issues.  There are risks but they are nowhere as bad as
  not doing automated updating.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org