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