8 ms·

It’s the same in the US Federal government IT space, especially when dealing with archaic legacy systems. Innovation is nearly impossible and change approval bo

It’s the same in the US Federal government IT space, especially when dealing with archaic legacy systems. Innovation is nearly impossible and change approval boards reign. Everyone is risk-averse because of previous breaches, even to the point where engineers are not allowed to run the code they wrote themselves. You heard that right. We can write code, but we can’t run it ourselves.

Aeolun 7y ago
How would they even stop you from doing that? It just sounds like a challenge for a workaround to me.
lowercased 7y ago
Had similar experience talking to ... someone at fidelity. I can't remember his title, but we were trying to negotiate some data exchange with them. He asked for our development workflow/process, and balked when he saw that a "developer" would also be the same person who had "access" to the database with customer information. "Developers can not touch the database" Umm... someone needs to, and we're a small team. "Developers can not touch the database" "Why not?" "They can exfiltrate data". "So could someone else who has access to the database" "Developers can not touch the database" "If we give a non-developer access to the database, by definition, they have access, and therefore the ability to exfiltrate data" "Developers can not touch the database" "Can you provide some examples of how other companies who've passed your inspection are making any sort of database changes/upgrades without someone having access to the database?" "Developers can not touch the database" And that ended it apparently.
- orf 7y ago
  This is a pretty normal requirement. I believe what they are saying is that you should not be able to access sensitive customer data by virtue of “just” being a developer, and you should audit who has access to such data and why. And by “touch” they mean unfiltered access, not “you cannot do anything with the database and therefore cannot work”. This is pretty basic information hygiene, and if you don’t have enough care to implement even that then why should they partner with you? Sounds like a liability waiting to happen.
  - lowercased 7y ago
    > This is pretty basic information hygiene They would not give us any indication of what they expected. > I believe what they are saying is that you should not be able to access sensitive customer data by virtue of “just” being a developer, and you should audit who has access to such data and why. It should be pretty straightforward for them to provide a "here's our initial base minimum requirements guidelines" and work from there. The parameters they laid out were similar to "anyone who would be capable of running any code on the database should not have access to any data". Every clarifying question about "what about X? what about Y?" was met with basically, "no, that person could exfiltrate the data". Which, yes, anyone who has access to the data could, theoretically, exfiltrate the data. I showed a demonstration (from laptop) and the guy got really upset that I had 'customer data' on the screen and in my database. It took several minutes of back and forth to explain to him that it was "faked" data.
    - orf 7y ago
      It sounds like your team has no clue how to approach these discussions and lost out on the partnership. Fidelity don’t know you from Adam, and you seemingly gave no impressions that you had any idea what they wanted or how this process works. They shouldn’t have to spell out how to protect data to you, and simply by asking “what about X” as if you are the only one to ever say this to them or notice that there are of course ways data could be exfiltrated betrayed your ignorance, not theirs. Did you expect them to say “my god! Of course! Why didn’t I see this before? This regulation we are legally and contractually bound to obey is not perfect, so hey why don’t you just ignore it.”? And to top it off you started showing realistic looking data without being upfront and clear to them that it was synthetic? Come on.
      - lowercased 7y ago
        Not the same as "we're doing this and... " being cut off and being told "this is 100% wrong, and we will not tell you any scenarios that will bring you in to compliance with our view of secure". We had plenty of secure process in place. The moment he heard the word "developer" and "database", he basically shut down and refused any meaningful engagement. It is not his job to educate on secure practices. It was his job to inspect what we had in place, and he stopped doing that the moment he heard those two words. "Would having a non-developer administrator connect and process the changes?" "Developers can not have any access to any production data". That's not a meaningful response to the question. > And to top it off you started showing realistic looking data without being upfront and clear to them that it was synthetic? Come on. I'm not sure how much more 'up front' you can be besides saying "we develop with faked sample data, this is faked and unrelated to or connected with the production system" at the start of that walkthrough. Perhaps if we'd opened up a Northwind database it might have looked more plausible? No one was expecting them to ignore anything. We were expecting someone to ask "are you doing X? how are you doing Y?", then followup with "you need to remediate these aspects of your system before we proceed further". That's what I would expect.
- deleted 7y ago
  [deleted]
- xkcd-sucks 7y ago
  No no no, this is where you request a larger budget, change everyone's title to DBA, and have DBAs write the code (but phrase "code" as "queries")
- cosmodisk 7y ago
  While I get the 'atmosphere' of the meeting just by reading this, there are quite a few valid points raised. Developer should not have access to real user data. Devs should be provided with DB schema definitions,info on data volumes and any other relevant information or metadata that is required to develop new features/migrate/etc. When it comes to databases with extremely sensitive data,i.e. banking, healthcare, criminal records, there must be an additional layer security that'd log anyone accessing particular records.
triangleman 7y ago
Separation of duties regulation. Nothing wrong with it. The idea is to have a wall so that you can't have one person able to write and push code to production. Now if you mean "run code" at all that's another story.

Aeolun 7y ago

How would they even stop you from doing that? It just sounds like a challenge for a workaround to me.

lowercased 7y ago

Had similar experience talking to ... someone at fidelity. I can't remember his title, but we were trying to negotiate some data exchange with them. He asked for our development workflow/process, and balked when he saw that a "developer" would also be the same person who had "access" to the database with customer information. "Developers can not touch the database" Umm... someone needs to, and we're a small team. "Developers can not touch the database" "Why not?" "They can exfiltrate data". "So could someone else who has access to the database" "Developers can not touch the database" "If we give a non-developer access to the database, by definition, they have access, and therefore the ability to exfiltrate data" "Developers can not touch the database" "Can you provide some examples of how other companies who've passed your inspection are making any sort of database changes/upgrades without someone having access to the database?" "Developers can not touch the database" And that ended it apparently.

orf 7y ago
This is a pretty normal requirement. I believe what they are saying is that you should not be able to access sensitive customer data by virtue of “just” being a developer, and you should audit who has access to such data and why. And by “touch” they mean unfiltered access, not “you cannot do anything with the database and therefore cannot work”. This is pretty basic information hygiene, and if you don’t have enough care to implement even that then why should they partner with you? Sounds like a liability waiting to happen.
- lowercased 7y ago
  > This is pretty basic information hygiene They would not give us any indication of what they expected. > I believe what they are saying is that you should not be able to access sensitive customer data by virtue of “just” being a developer, and you should audit who has access to such data and why. It should be pretty straightforward for them to provide a "here's our initial base minimum requirements guidelines" and work from there. The parameters they laid out were similar to "anyone who would be capable of running any code on the database should not have access to any data". Every clarifying question about "what about X? what about Y?" was met with basically, "no, that person could exfiltrate the data". Which, yes, anyone who has access to the data could, theoretically, exfiltrate the data. I showed a demonstration (from laptop) and the guy got really upset that I had 'customer data' on the screen and in my database. It took several minutes of back and forth to explain to him that it was "faked" data.
  - orf 7y ago
    It sounds like your team has no clue how to approach these discussions and lost out on the partnership. Fidelity don’t know you from Adam, and you seemingly gave no impressions that you had any idea what they wanted or how this process works. They shouldn’t have to spell out how to protect data to you, and simply by asking “what about X” as if you are the only one to ever say this to them or notice that there are of course ways data could be exfiltrated betrayed your ignorance, not theirs. Did you expect them to say “my god! Of course! Why didn’t I see this before? This regulation we are legally and contractually bound to obey is not perfect, so hey why don’t you just ignore it.”? And to top it off you started showing realistic looking data without being upfront and clear to them that it was synthetic? Come on.
    - lowercased 7y ago
      Not the same as "we're doing this and... " being cut off and being told "this is 100% wrong, and we will not tell you any scenarios that will bring you in to compliance with our view of secure". We had plenty of secure process in place. The moment he heard the word "developer" and "database", he basically shut down and refused any meaningful engagement. It is not his job to educate on secure practices. It was his job to inspect what we had in place, and he stopped doing that the moment he heard those two words. "Would having a non-developer administrator connect and process the changes?" "Developers can not have any access to any production data". That's not a meaningful response to the question. > And to top it off you started showing realistic looking data without being upfront and clear to them that it was synthetic? Come on. I'm not sure how much more 'up front' you can be besides saying "we develop with faked sample data, this is faked and unrelated to or connected with the production system" at the start of that walkthrough. Perhaps if we'd opened up a Northwind database it might have looked more plausible? No one was expecting them to ignore anything. We were expecting someone to ask "are you doing X? how are you doing Y?", then followup with "you need to remediate these aspects of your system before we proceed further". That's what I would expect.
deleted 7y ago
[deleted]
xkcd-sucks 7y ago
No no no, this is where you request a larger budget, change everyone's title to DBA, and have DBAs write the code (but phrase "code" as "queries")
cosmodisk 7y ago
While I get the 'atmosphere' of the meeting just by reading this, there are quite a few valid points raised. Developer should not have access to real user data. Devs should be provided with DB schema definitions,info on data volumes and any other relevant information or metadata that is required to develop new features/migrate/etc. When it comes to databases with extremely sensitive data,i.e. banking, healthcare, criminal records, there must be an additional layer security that'd log anyone accessing particular records.

triangleman 7y ago

Separation of duties regulation. Nothing wrong with it. The idea is to have a wall so that you can't have one person able to write and push code to production. Now if you mean "run code" at all that's another story.