4 ms·

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

> 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.
  - lima 7y ago
    That's because the person you talked to probably did not know, either. They were basically reading off a checklist.
guiambros 7y ago
To be fair, it's not their job to educate you on good security practices. This was an obvious red flag (developers should indeed not have unfettered access to production databases), so if you fail at a basic separation of duties on the team, there's no point in progressing any further. If you're expecting some "detailed guidelines" so you can "fix" your system to pass their audit, you're missing the point entirely. Also when showing anything that remotely looks like customer PII, it's your job to clarify that this is not real data. Given the precedent, I can see why they thought you were being careless and showing real production data.
- YeGoblynQueenne 7y ago
  Wait a minute. How would they be showing production data if they couldn't access the database were, presumably, this data was stored? It sounds a lot more like the smaller company was interfacing with someone who was not technical or at the very least did not have a clear understanding of the internal processes of the big company, and expected the smaller company to have prior experience of this thing and to guide them through it. Most likely, the process would have involved the samaller company communicating with someone inside the larger company, like a DBA, and asking the large company DBA to make the changes they needed. In large financial corps, company developers are not allowed to touch the database either, in fact where I worked, we were not even allowed to create a database for testing an internal-facing project. Processes are that anal.
  - celticmusic 7y ago
    > How would they be showing production data if they couldn't access the database were, presumably, this data was stored? The entire anecdote was about them telling the representative that they DO in fact have access to the production DB. Why would you expect him to act as if they didn't have access after being told they do?
    - YeGoblynQueenne 7y ago
      Oh, my mistake- sorry, I misread that.

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.
- lima 7y ago
  That's because the person you talked to probably did not know, either. They were basically reading off a checklist.

guiambros 7y ago

To be fair, it's not their job to educate you on good security practices. This was an obvious red flag (developers should indeed not have unfettered access to production databases), so if you fail at a basic separation of duties on the team, there's no point in progressing any further. If you're expecting some "detailed guidelines" so you can "fix" your system to pass their audit, you're missing the point entirely. Also when showing anything that remotely looks like customer PII, it's your job to clarify that this is not real data. Given the precedent, I can see why they thought you were being careless and showing real production data.

YeGoblynQueenne 7y ago
Wait a minute. How would they be showing production data if they couldn't access the database were, presumably, this data was stored? It sounds a lot more like the smaller company was interfacing with someone who was not technical or at the very least did not have a clear understanding of the internal processes of the big company, and expected the smaller company to have prior experience of this thing and to guide them through it. Most likely, the process would have involved the samaller company communicating with someone inside the larger company, like a DBA, and asking the large company DBA to make the changes they needed. In large financial corps, company developers are not allowed to touch the database either, in fact where I worked, we were not even allowed to create a database for testing an internal-facing project. Processes are that anal.
- celticmusic 7y ago
  > How would they be showing production data if they couldn't access the database were, presumably, this data was stored? The entire anecdote was about them telling the representative that they DO in fact have access to the production DB. Why would you expect him to act as if they didn't have access after being told they do?
  - YeGoblynQueenne 7y ago
    Oh, my mistake- sorry, I misread that.