Comments on: Sorry, I No Speak (Security) … http://blog.impactalabs.com/2009/10/22/i-no-speak-securit/ Sun, 06 Jun 2010 23:16:06 +0000 hourly 1 http://wordpress.com/ By: Kevin Lam (IMPACTA) http://blog.impactalabs.com/2009/10/22/i-no-speak-securit/#comment-187 Kevin Lam (IMPACTA) Fri, 23 Oct 2009 05:45:19 +0000 http://blog.impactalabs.com/?p=456#comment-187 Hey David, Great to hear from you, hope all is well. Indeed, the bigger the picture the security person has of things going outside of their box the better. I am also glad you pointed out the need to provide advice that's actionable (it's one thing to tell someone they have a problem, but it's another to provide them with a solution). Thanks for taking the time to share your thoughts! --Kevin Hey David,

Great to hear from you, hope all is well. Indeed, the bigger the picture the security person has of things going outside of their box the better. I am also glad you pointed out the need to provide advice that’s actionable (it’s one thing to tell someone they have a problem, but it’s another to provide them with a solution). Thanks for taking the time to share your thoughts!

–Kevin

]]> By: David LeBlanc http://blog.impactalabs.com/2009/10/22/i-no-speak-securit/#comment-186 David LeBlanc Fri, 23 Oct 2009 00:30:35 +0000 http://blog.impactalabs.com/?p=456#comment-186 Interesting post - something I've also observed is that if the security people aren't also developers - and not just developers, but people who ship code - then they're likely thinking about security in isolation. The developer is thinking schedule, perf, risk of regression, feature backlog, localization, making everything run on some number of platforms and/or browsers, AND security. If the security person isn't in tune with the full range of the effects of their suggestions - features cut, schedule slipped, etc - then the developer might just flip the bozo bit, and now the security person sounds like Charlie Brown's teacher - BLAH, BLAH, BLAH... As security people, we need to give advice that's actionable, takes into account the full range of issues the developer faces, and helps them deal with the biggest problems first. Interesting post – something I’ve also observed is that if the security people aren’t also developers – and not just developers, but people who ship code – then they’re likely thinking about security in isolation. The developer is thinking schedule, perf, risk of regression, feature backlog, localization, making everything run on some number of platforms and/or browsers, AND security.

If the security person isn’t in tune with the full range of the effects of their suggestions – features cut, schedule slipped, etc – then the developer might just flip the bozo bit, and now the security person sounds like Charlie Brown’s teacher – BLAH, BLAH, BLAH…

As security people, we need to give advice that’s actionable, takes into account the full range of issues the developer faces, and helps them deal with the biggest problems first.

]]>