security for home users

[Heidi Picher Dempsey-2]

Slashdot highlighted an interesting summary of a report that found more
than half of a small sample (545) of home users had systems  "at risk"
for spyware infection (as determined by a Verizon scan service).  From
an ops point of view, it was also interesting that almost all users
said they would like to be able to diagnose or check their systems
regularly, even though they clearly hadn't.

http://www.net-security.org/secworld.php?id=5658

This isn't really news, but makes me wonder if OMIS members see the
same rates of risk or more/less in their experience.  Is it more/less
for research users?


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

[Michael A. Patton]

  [ 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

[Heidi Picher Dempsey-2]

On Feb 11, 2008, at 1:52 AM, Michael A. Patton wrote:

>   [ 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.

Keep in mind though, that we are likely to include end-user opt-in to
experiments right from the start, and end users will include people at
home who are not researchers and may not even be savvy computer users.

> 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
>

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

[Aaron Falk]

On Feb 10, 2008, at 10:52 PM, Michael A. Patton wrote:

>  [ 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.
>

(slowly getting to this message....)

Hi Mike-

Just a comment that end-user opt-in may include devices that aren't  
PCs, wireless devices especially.  This added diversity in hardware  
platforms/operating systems/application environments will very well  
make your list below more challenging.

--aaron

>
> 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

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

[Williams, James G]

Two OMIS ideas....

Both of these ideas focus around the question..."What 'ways of thinking' will be most useful in the short-intermediate term, as OMIS tries to move forward within the overall GENI Project?"

1.      Is it useful to begin to classify problems into different OMIS sub-areas such as measurement, security, experimenter interface?  I think we realize that integration is necessary...eventually...but, in the interests of making the most progress as quickly as possible, perhaps segmenting the OMIS activity into chunks is useful.  Then security issues can be discussed in detail within a security sub-group and more generally (at a higher-level and more briefly) in the WG meetings.

2.      Timing of the OMIS efforts, within the overall GENI development timeline, seems important.  There are complicated questions that can be stated now..."How will OMIS and Experimenter Support work together?"  This is a very important question.  But, until we know more about OMIS tools and the basic functioning of OMIS, we can't answer this kind of question.   OMIS will have to be built from the ground up.  At this point in OMIS development it seems like raw tool development, development of OMIS operational prototypes and integration of OMIS tools in other GENI prototype and integration projects are valuable areas of exploration.


Just ideas...designed to stimulate discussion both on the list and at the March meeting.



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

[Heidi Picher Dempsey-2]

On Feb 25, 2008, at 2:13 PM, Williams, James G wrote:

>
>
> Two OMIS ideas....
>
> Both of these ideas focus around the question..."What 'ways of  
> thinking' will be most useful in the short-intermediate term, as  
> OMIS tries to move forward within the overall GENI Project?"
>
> 1.      Is it useful to begin to classify problems into different  
> OMIS sub-areas such as measurement, security, experimenter  
> interface?  I think we realize that integration is  
> necessary...eventually...but, in the interests of making the most  
> progress as quickly as possible, perhaps segmenting the OMIS  
> activity into chunks is useful.  Then security issues can be  
> discussed in detail within a security sub-group and more generally  
> (at a higher-level and more briefly) in the WG meetings.

Certainly classifying is useful.  I don't think we have critical mass  
to make sub-groups yet, but I agree with you that it will probably  
happen in the future as we delve into each area.  Right now I am most  
interested in getting OMIS members to contribute their opinions on  
what they think are the most important areas to pursue in a way that  
allows us to pursue the most important issues right away, which is  
important as you emphasis in your next point. Do you (or others) have  
a suggestion for how to collect this input quickly (aside from the  
"top 10 list?"   I think we'll have to have most of our discussion on  
the mailing list, since there is actually very little time for the  
joint working group meetings during GEC2.  We need to use that time to  
highlight the cross-group issues that are most important.

>
>
> 2.      Timing of the OMIS efforts, within the overall GENI  
> development timeline, seems important.  There are complicated  
> questions that can be stated now..."How will OMIS and Experimenter  
> Support work together?"  This is a very important question.  But,  
> until we know more about OMIS tools and the basic functioning of  
> OMIS, we can't answer this kind of question.   OMIS will have to be  
> built from the ground up.  At this point in OMIS development it  
> seems like raw tool development, development of OMIS operational  
> prototypes and integration of OMIS tools in other GENI prototype and  
> integration projects are valuable areas of exploration.

Along these lines, Mike Patton has been talking to working group  
members in other groups and will be sending some notes to the list  
very soon related to possible GENI use cases that might help clarify  
some ground-up OMIS needs if we can get some discussion going on the  
list.

>
>
>
> Just ideas...designed to stimulate discussion both on the list and  
> at the March meeting.

Thanks very much!  I really want to use people's time wisely at the  
March meeting and on the list.  I'm keenly aware that everyone is  
volunteering at this point, and there are many demands for your time.  
It is very important, especially for OMIS, to actively contribute in  
the early stages of the GENI architecture and design, to make sure  
operations requirements are included in development and prototyping.

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


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