Re: security for home users

  [ My original reply to Heidi's message didn't make it to the mailing
  [ list, so I'm reposting to get this in the archive.  The message
  [ I'm replying to was about 2 months ago, but it's still the last
  [ message to the list so this reply will be in order in the
  [ archive :-), where you can look if you need a reminder.

For home PCs running M$ systems, which--reading between the lines--is
apparently all the systems in the survey, I would have expected the
fraction to be a little higher than the numbers quoted in the
article.  For businesses, I expect the number to be lower.  Some
subset of businesses are probably as bad as home users, but on the
whole they tend to be better about keeping their security up to date.

As far as researchers go, overall I expect the numbers to be better.
It's been a while since I was managing the MIT-LCS network and had
direct daily interaction with researchers, but I still suspect that
researchers are somewhat less likely to be running M$ software than a
home user, and that alone will bias the overall average.  Researchers,
and specifically those in network research, will also tend to be more
aware of the issues and thus more likely to pay attention.


So, I was thinking about how this issue would impact OMIS.  Most of
the proposals for the internal infrastructure of GENI don't include
equipment that is as vulnerable as home systems to start with and is
fairly easily secured even further.  But, I think there's something to
think about under each of our four "letters".  The relevance to
"Security" is obvious...so I'll skip that and cover the others
starting from that end of the acronym.

Under "Integration" we should be sure that security vulnerabilities
and SW updates (of all kinds, but security SW is relevant here) are
included in the criteria for testing proposed additions to the
network--both equipment to be used in the internal infrastructure of
the facility as well as contributions for connection on the
periphery.  Something that's a cross-over to the Services WG is that
there may need to be some visibility to experimenters about how well
"secured" the equipment is that is contributing slivers to their
slice, and perhaps let them use that in the selection.

"Management" needs the ability to control an experiment gone rogue,
which is already covered for other reasons (including just bugs in
their experimental code).  But, a worse case scenario might be an
experiment that gets infected in a way that causes it to do something
pathological like allocating and releasing resources at a rate that
affects the control plane, affecting the ability to shut it down
perhaps.  So the design for how network management is done needs to
consider how this is handled.

"Operations" needs to include technology for monitoring the security
of components in addition to just the operating/failed status.  This
isn't really specific to GENI, like the others, just good NetOps
practice, which we should strive to be even better at...

And one other thing that occurred to me, I'm not sure which of our
four letters it falls under, or maybe it belongs to another WG.  The
procedures when a sliver gets released from one slice/experiment and
later gets reallocated into a different one needs to be extra careful
not to transfer any viruses that the first experiment happened to be
infected with.  I suspect that most sliver allocations will start from
tabla rasa and avoid this.  But, some that have substantial overhead
might be tempted to cache old slivers and they need to be sure about
the state they transfer between experiments.

        -MAP

_______________________________________________
omis-wg mailing list
omis-wg@...
http://lists.geni.net/mailman/listinfo/omis-wg