3 ms·
Sure there is a good way to do it right. Yet most IS teams got drawn too much into the polar reaction of either chicken little or boilerplate. From a client st
by bitcuration 5y ago
Sure there is a good way to do it right. Yet most IS teams got drawn too much into the polar reaction of either chicken little or boilerplate.
From a client standpoint, which came to me as a no surprise but I've learned the hard way for something so obvious, is that they don't understand nor care the whole explanation, articulation of the security issue. All they wanted is you to take care it, don't waste everybody's time by only coming in to find security problem at the worst timing and making impulsive decision as a IS methodology.
This calls for build security by design, merge the lifecycle of security management into the modern software engineering, some refer that as DevSecOps, which sounds bolts-on so I doubt that's all there is to it. The software engineering never has given security the weight it deserves.
Why now and why this has never been the case since the beginning? Probably because most IS professional are from auditors, operation etc. background. Very few brains are from software engineering background, this is also different from a mere programming background. Script kiddy is not software engineering.
Contrary to the article's claim, what it needs is system thinking, STEM brain. People skill will not fix it, only to make it go away.
- Kalium 5y agoYou're absolutely right. The key idea that's badly needed here is to build secure systems by design, building in security-critical features and design aspects from the start. As you correctly say, this is the best way to do this and addresses what the clients want - just get it done. Having personally experienced several different aspects of this process, I've found that it's almost always much easier said than done. It's been my experience that clients/executives don't just want things done. They want security, but without impacting product roadmaps, development timelines, or design choices. Engineering rarely appreciates someone else trying to tell them how to make design tradeoffs. Product wants security, but this commitment often wavers in the face of increased development time or an ongoing vulnerability management effort. There's a target date to hit, and maybe security isn't viewed as part of the MVP... can't things just be done when they're shipped to prod? How do I, or another security specialist, get leadership of other parts of the organization to enable me to take care of it without wasting everybody's time? Or anybody's time? Generally a lot of people skills, negotiation, and prioritization effort. Security work, no matter how integrated into the overall effort or DevSecOps the implementation, is never completely without cost. Again, you're completely correct. The best way to do what the client wants and just take care of things is to use systems thinking and merge security work into every part of the product lifecycle. Do you think it is perhaps possible that there might be a place for human-wrangling skills in the complex human-computer system that controls how software is developed?