4 ms·

That's interesting, thanks. I can see how practical techniques will make most sense if they are closer to what you're doing. I'm wondering how to bridge that

That's interesting, thanks. I can see how practical techniques will make most sense if they are closer to what you're doing. I'm wondering how to bridge that gap so there is some assurance for the organisation as well as training for the developer.

watwut 4y ago
What it is that you want to teach them in the training? I mean the question genuinely, not as a snark. I am curious about what you (or other security people) see as missing part. I have seen security audit of what we were working on done few times and found it interesting to read. It is good to put that stuff into training materials and repeat it to people. It is actually cool if you can demonstrate attack on their own software (there is always someone who will call your attack theoretical until you demonstrate it). Imo, the best security is the one that does not depends too much on developers remembering to do the right thing all the time. So for example if there is a method that leads to protentional SQL injection or XSS or whatever, prohibit its use and write unit test for it. Basically, static analysis of a code. So then, when someone accidently uses it, the test suite will complain. Hide unsafe things behind internal libraries that force developers do the right thing. Make the right thing easier then the wrong thing. The other good thing are checklists - checklist of ui code, checklist for API, checklist for database, checklist for configuration. In my opinion, if you want assurance about something important, have checking it regular routine part of process and ideally automated. There is always someone who does not know or dont care or is just tired and not focusing. The best compliance is the one that happens automatically as the easiest thing to do.
- MattPalmer1086 4y ago
  I'm currently working on SDLC security. There's lots of different pieces: peer review, secure code review, threat modelling, training, secure patterns, coding standards, static and dynamic analysis, software composition analysis, build pipeline security, and pen testing! And a bunch of other things to think about. In terms of the developer facing stuff, I'm keen not to repeat the sins of the past where security teams dump a whole load of well-meaning but practically useless stuff on them. As I say, I've been on the other side of the fence. Management and compliance people want assurance that devs are aware of relevant secure coding techniques and pitfalls, but they tend to glom on to big, well known standards, even if half of it isn't useful. I like the idea of finding coding examples relevant to the tech they use, that demonstrates insecure and then secure patterns. For the things that actually make a difference... And then to link the secure coding standards to that as well. Join it up, keep it relevant and practical. Then I just have to demonstrate that this actually meets what the compliance people want to see...

watwut 4y ago

What it is that you want to teach them in the training? I mean the question genuinely, not as a snark. I am curious about what you (or other security people) see as missing part. I have seen security audit of what we were working on done few times and found it interesting to read. It is good to put that stuff into training materials and repeat it to people. It is actually cool if you can demonstrate attack on their own software (there is always someone who will call your attack theoretical until you demonstrate it). Imo, the best security is the one that does not depends too much on developers remembering to do the right thing all the time. So for example if there is a method that leads to protentional SQL injection or XSS or whatever, prohibit its use and write unit test for it. Basically, static analysis of a code. So then, when someone accidently uses it, the test suite will complain. Hide unsafe things behind internal libraries that force developers do the right thing. Make the right thing easier then the wrong thing. The other good thing are checklists - checklist of ui code, checklist for API, checklist for database, checklist for configuration. In my opinion, if you want assurance about something important, have checking it regular routine part of process and ideally automated. There is always someone who does not know or dont care or is just tired and not focusing. The best compliance is the one that happens automatically as the easiest thing to do.

MattPalmer1086 4y ago
I'm currently working on SDLC security. There's lots of different pieces: peer review, secure code review, threat modelling, training, secure patterns, coding standards, static and dynamic analysis, software composition analysis, build pipeline security, and pen testing! And a bunch of other things to think about. In terms of the developer facing stuff, I'm keen not to repeat the sins of the past where security teams dump a whole load of well-meaning but practically useless stuff on them. As I say, I've been on the other side of the fence. Management and compliance people want assurance that devs are aware of relevant secure coding techniques and pitfalls, but they tend to glom on to big, well known standards, even if half of it isn't useful. I like the idea of finding coding examples relevant to the tech they use, that demonstrates insecure and then secure patterns. For the things that actually make a difference... And then to link the secure coding standards to that as well. Join it up, keep it relevant and practical. Then I just have to demonstrate that this actually meets what the compliance people want to see...