[lug] NoVAD: Protecting Cloud Data

Dan Ferris dan at usrsbin.com
Sun Jul 13 08:53:03 MDT 2014


In all fairness though, Cloud Spaces was using Amazon in the most stupid 
way possible and several things, like the S3 multifactor delete, IDM 
accounts/permissions, and bucket versioning would have prevented the 
problem.

I use S3 for backups, and all of our stuff has its own write only IDM 
account to its own bucket and you have to have a Yubikey to delete anything.

On 7/13/14, 8:19 AM, Rob Nagler wrote:
> NoVAD stands for No Virtually Assured Destruction.  We're a group of
> people from all walks of life.  We want sensible cyber safeguards to
> protect cloud businesses from destruction by mistakes, criminals, and
> terrorists.  We are looking for people to join the cause and to help
> out.  For now, we are using a LinkedIn Group:
>
> https://www.linkedin.com/groups/NoVAD-6718590/about
>
> Our website is http://novad.club (on github)
>
> You probably read about Code Spaces on slashdot.  In case you haven't,
> here's their story.  An extortionist tried to get them to pay after he
> got access to their master account.  When Code Spaces refused, the
> extortionist started destroying cloud assets, one at a time, over a
> period of 12 hours.  The extortionist was good so they couldn't lock
> him out immediately.  They had to shutdown their business.  Visit
> codespace.com to learn more.  I'm glad they made their situation
> public, many businesses would not.
>
> NoVAD has three recommendations for cloud providers.  Any one of these
> would have allowed Code Spaces to prevent the attack from destroying
> their business:
>
> VSCRAM(tm) - Nuclear reactors have a safety control rod axe man
> (SCRAM), which forces a large insertion of negative
> reactivity. Clients should have the ability to call in or text a
> VSCRAM code to a cloud service provider to force an immediate shutdown
> and freeze all of the client’s servers and assets.
>
> VLockdown(tm) - If Code Spaces could have locked down administrative
> access, the attack would have been stopped without disrupting normal
> operations. Clients should have a VLockdown code to freeze all
> adminstrative access and destructive operations.
>
> VDelete(tm) - Like the Trash can on your desktop, deleted cloud assets
> should not be destroyed immediately. Even a few hours delay before
> “emptying the trash” would have helped Code Spaces save their
> business.
>
> (The reason for the trademarks is to ensure that people use these
> ideas correctly.  Trademarks are the equivalent of copyleft for
> industry standards.)
>
> These safeguards will also help in the event of a serious mistake by
> someone working for a cloud-based company.  Many businesses rely
> completely on one cloud provider.  While this is not the best
> practice, it is common, and your data probably is managed by such a
> company.
>
> We need your help.  Our goal is to build an organization that promotes
> better cloud data security, once an attack is already in progress.
> There are plenty of people who are working on intrusion detection and
> prevention.  We want to protect your data when the unthinkable
> happens: access to the master account is compromised.
>
> We need better content and a better website:
>
> http://github.com/novadclub/novadclub.github.io
>
> We need contacts at cloud providers and better ideas to present to
> them.
>
> By joining our LinkedIn Group, your voice will be heard:
>
> https://www.linkedin.com/groups/NoVAD-6718590/about
>
> Your good name will add weight to our efforts, too.
>
> Please tell your friends and forward this notice to other groups.
> Protect your data by stopping virtually assured destruction.
>
> Thanks,
> Rob
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety



More information about the LUG mailing list