6 ms·

The attitude is simple - don't give your code, and especially don't give access to your devops repositories to 3rd party companies who simply don't need it. If

The attitude is simple - don't give your code, and especially don't give access to your devops repositories to 3rd party companies who simply don't need it. If a security vulnerability happens on the public Fogzbugs instance, we'd be bitten by it badly in this sort of situation. In our setup, we protect against that by exposing the JIRA webserver and git servers only inside of our private network. It's not about perfect security, but it does greatly reduce the attack surface when the server isn't even accessible via the internet. I can't prevent anyone who wants to from signing up for the free trial of Fogzbugs and exploiting their publicly running system - even logged-in-only exploits are possible in such a case. Not to mention the issues with downtime on these cloud providers. My provider has had 1 sizeable, noticeable outage in the last 5 years. It spanned about 20 minutes. Look at a big, popular cloud service like GitHub - they've had several in the past year alone, spanning hours at times. I find these sorts of compromises where I'm offering my code and server configurations to a 3rd party company (where basically any admin there is free to read it, or anyone who can compromise their admins) to be rather poor. I'd rather keep the blame within my own company and be in control of our data fully rather than having to worry about whether Fogzbugs operations follows proper security precautions, I only have to worry about whether we do. Call it paranoid if you want, but I think it's a more than reasonable precaution to not just throw your data around to anyone who asks for it. Especially data which could lead to compromise of servers and customer information. I value my customer's information much more than I value any gains from some easy to use cloud service.

jessaustin 10y ago
Thanks for the detailed reply. The downtime issue is certainly understandable. I hope you're keeping customer data out of DVCS, but it's true that flaws in your code might be more "discoverable" if an attacker had that code. It does introduce another step into the attack, however, to have to hack FogBugz before reading your code and discovering the flaw that hacks your services. You know your threat model better than we do, but I doubt most carders would bother with that...
- problems 10y ago
  I'm not too concerned about someone getting the code, reading it and discovering a flaw allowing for exploit. I'm much more concerned about someone being able to modify code that will be pulled onto production systems by build and deployment scripts (not to mention the build and deployment scripts themselves) which would allow direct access without any need to hack anything beyond the external cloud service. Even a disgruntled admin at Fog Creek in this case could do something like this without the need to hack anything.
  - jessaustin 10y ago
    Yes, code signing is important whether onsite or off-.
    - deleted 10y ago
      [deleted]
    - problems 10y ago
      Hmm, code signing might not help us due to some specifics of how we do deployments and builds, but thinking a little more about it - what could help in an even bigger way here is PGP signing at the commit level. Git supports this builtin and recently there have been a few pushes for it's support on services. Probably have to hack together a little custom verification script, but I know of no reason that wouldn't be viable. This would basically resolve my biggest problems with it I suppose, if used fully and properly. Currently comitting with your SSH key basically resolves this issue in the same way, assuming our internal-restricted server isn't compromised of course. I'd still be a little uncomfortable putting code on 3rd party servers and having any data there at all for stability reasons, but this does make it more viable. I'll definitely be commit signing everything I have on cloud services from now on.
  - briandear 10y ago
    Does anyone care enough about your product to actually go to the trouble to do that? It seems that in terms of actual risk management, managing an on premise version of everything is mitigation out of scale with the actual risk. Besides, a disgruntled employee of your company is far more likely to be malicious than a disgruntled employee of some random cloud services company. What would be their motivation? They probably don't care about your code at all -- but your employees -- they certainly might. Has there ever been a case of a disgruntled Github employee hacking a customer company's production code ever in the history of Github? Has there ever in the history of SMEs been a disgruntled employee that harmed his own company? All the time. So what risk is more realistic to mitigate? The hypothetical disgruntled employee at a vendor that probably has never heard of you or employees sitting right there in the office with you?

jessaustin 10y ago

Thanks for the detailed reply. The downtime issue is certainly understandable. I hope you're keeping customer data out of DVCS, but it's true that flaws in your code might be more "discoverable" if an attacker had that code. It does introduce another step into the attack, however, to have to hack FogBugz before reading your code and discovering the flaw that hacks your services. You know your threat model better than we do, but I doubt most carders would bother with that...

problems 10y ago
I'm not too concerned about someone getting the code, reading it and discovering a flaw allowing for exploit. I'm much more concerned about someone being able to modify code that will be pulled onto production systems by build and deployment scripts (not to mention the build and deployment scripts themselves) which would allow direct access without any need to hack anything beyond the external cloud service. Even a disgruntled admin at Fog Creek in this case could do something like this without the need to hack anything.
- jessaustin 10y ago
  Yes, code signing is important whether onsite or off-.
  - deleted 10y ago
    [deleted]
  - problems 10y ago
    Hmm, code signing might not help us due to some specifics of how we do deployments and builds, but thinking a little more about it - what could help in an even bigger way here is PGP signing at the commit level. Git supports this builtin and recently there have been a few pushes for it's support on services. Probably have to hack together a little custom verification script, but I know of no reason that wouldn't be viable. This would basically resolve my biggest problems with it I suppose, if used fully and properly. Currently comitting with your SSH key basically resolves this issue in the same way, assuming our internal-restricted server isn't compromised of course. I'd still be a little uncomfortable putting code on 3rd party servers and having any data there at all for stability reasons, but this does make it more viable. I'll definitely be commit signing everything I have on cloud services from now on.
- briandear 10y ago
  Does anyone care enough about your product to actually go to the trouble to do that? It seems that in terms of actual risk management, managing an on premise version of everything is mitigation out of scale with the actual risk. Besides, a disgruntled employee of your company is far more likely to be malicious than a disgruntled employee of some random cloud services company. What would be their motivation? They probably don't care about your code at all -- but your employees -- they certainly might. Has there ever been a case of a disgruntled Github employee hacking a customer company's production code ever in the history of Github? Has there ever in the history of SMEs been a disgruntled employee that harmed his own company? All the time. So what risk is more realistic to mitigate? The hypothetical disgruntled employee at a vendor that probably has never heard of you or employees sitting right there in the office with you?