Slashdot Mirror
92 Percent of Enterprises Struggle To Integrate Security Into DevOps (betanews.com)
A large majority of organizations are struggling to implement security into their DevOps processes, despite saying they want to do so, according to a new report. From a report: The study commissioned by application security specialist Checkmarx looks at the biggest barriers to securing software today depending on where organizations sit on the DevOps maturity curve. The report finds 96 percent of respondents believe it is 'desirable' or 'highly desirable' for developers to be properly trained on how to produce secure code.
As developers take responsibility for the security of their software, respondents believe it is more important to educate developers and empower them than it is to educate other stakeholders in the organization like ops specialists and security specialists. However, 41 percent agree that defining clear ownership and responsibility in relation to software security remains a big challenge, and just 11 percent say they have adequately addressed the need for developer education. Software security is a boardroom issue according to 57 percent of respondents, it's a matter of business risk.
As developers take responsibility for the security of their software, respondents believe it is more important to educate developers and empower them than it is to educate other stakeholders in the organization like ops specialists and security specialists. However, 41 percent agree that defining clear ownership and responsibility in relation to software security remains a big challenge, and just 11 percent say they have adequately addressed the need for developer education. Software security is a boardroom issue according to 57 percent of respondents, it's a matter of business risk.
So if 92% are admitting to having trouble the other 8% are just lying to themselves and others about it.
Security is ALWAYS a struggle and if you are committed to creating secure software and systems you will soon realize that you can never really call the security job done. So, if you are saying you have arrived, your security efforts have been successful, you are either out of business or you are destine to fail in your task because you quit working on it, having arrived.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Comment removed based on user account deletion
Not a choice, a requirement.
Coders will tell you documentation 'slows them down'. They will tell you version control 'isn;t worth the trouble', and 'slows them down'.
And they will tell you security 'slows them down'.
Nothing slows you down as much as total pwnage by whatever malware you've missed due to inadequate security.
And nothing will strip value form your project as fast nor as completely as your treasured code going off to enrich your competitors.
Security for DevOps needs be internal and external. No one can be trusted, and data loss is just as expensive as an infestation.
deleting the extra space after periods so i can stay relevant, yeah.
Devops was not designed to bridge the collaboration gap between developer and operations. It was designed to bridge the hiring gap. Fully staffed ops teams are a rarity, as are fully staffed dev teams. If you can make either do both, you can report to your leadership that youre no longer overstaffed, and are surprisingly at or below budget for headcount.
secops are already a thing. The only thing silly-con valley needs to convince the industry now is that some sort of dev/sec/ops monster is not only a real position, but employable at a fraction of the rate of either 3 roles.
Good people go to bed earlier.
We have the opposite. We have a dedicated security engineering team that works along side our engineering teams. We ensure that the security requirements are met and even pair program with the other engineers. I write code every day in my security engineering role. I build pipelines, I write scripts, build recommendations and requirements, and even sometimes get down in the day to day with helping engineering solve complex issues.
Lastly, my masters program included a secure software design course. It was terribly lacking.
It is hard to DevOps with security when in most organizations DevOps means 1 person is doing a job of 4+ people (BA, Dev, QA, SysAdm). Security is usually first one to get compromized (cost, time, and scope would be considered before security).
THANK. YOU. That's been my experience, too. I will say 99% of branded info-sec analysts in any organization I've been at are just certified, expensive turn-key Big brother security scanner stack, banner grabbing phrase repeaters who say a lot of buzzwords (Blue Team, Read Team, FISMA, go-go-go) like we're playing Halo charades. I'm not knocking them --- that's why I don't have or want their job, but I know it's hard to exercise security when the expertise, competency, skill and where-with-all of a developer, or sys-admin/engineer hat caring about matching CVE numbers to package releases or the developer who can code OO-Python, C++ or PHP like a mad-man but is absolutely nebulous about any sort of vector attacks, how exploiting or overflows generally work, or in-memory attacks, all that BS that exists today.
I don't blame the people in those positions though, it's the churn of an organization and the management: whatever you're working on makes the business, and more times than none, it's bottom line get-it-out-the-door or get-it-released 100% of the time. And I feel like there also a lot less expertise and well-rounded computer-science and highly technical people these days in positions. Everyone just wants it to 'work' and never look back. Unless you're in a relatively respected position or valued enough for someone to listen to, "That's great, but we really need to focus on security here, there, over there and right here" AND actually set up a foundation for people applying, implementing and caring for security in their respective roles, this is how it will always be.
It doesn't matter how many leaks, hacks or compromises of millions of accounts at this place or that place will be in the future, thinking and priorities to security as a whole have to change first and be just as high on the list as that new feature in you're working on in that 2-week Agile sprint.
Separation of duties.
Principle of least privilege.
These are security concepts which are inherently incompatible with some of the more common ideas of what DevOps means.
For example, if the same guy (or team) is writing the code and the jobs that deploy it to prod and triggering that job, you might have "a devops" but you don't have a sane security model.
A blank check is not necessary, but what is necessary is to abandon any hope of directing your DevOps schedule. It's done when it's done and not a day earlier. DevOps solutions should allow your developers to be flexible and agile, but oftentimes this erroneously translates to DevOps doing the bare minimum, which does not include secure solutions, typically.
When DevOps is done well, it joins development and operations. If you have separate Development, System Administration and DevOps teams, you're doing it wrong so of course you fail.
On the other hand, too much modern devops has reinvented the wheel, improving upon practices which were obsolete 20 years ago. Puppet? Chef? Ansible? Hello rdist and rsh. Crappy then, crappy now. Docker? How the eff do you validate security compliance and successfully patch docker images? You know, the job that in normal VMs gets handled by "yum update." Docker is a security disaster area.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
It's where the webmonkeys go "oh we know! we'll fix the system administration ourselves... with docker!"
I used to be sour at this. I used to do systems and networks administration, mostly free Unices including linux*, some non-free Unices. I also can "code" (C, C++, shell, python, whatever. Not admitting to java nor to php to protect my sanity.) And sure, I know how (some) exploits work, can do assembly and even dabbled with disassembly and binary patching, though it's not really my cup of tea. I shoot trouble, I don't really deliberately go out and make it by picking nits. And for years I tried to sell that combination of skills and usually got zero response. Now it's a thing to combine the first two and call it devops. Turns out that it makes a big old mess of things. Because it's where the webmonkeys, etc. And now they're proposing to add security on top of devops? Nobody could have predicted, etc.
So it doesn't surprise me that this approach doesn't actually work very well. Nor does it surprise me that secops --if it exists-- typically consists of (see above) a bunch of non-coding fully-certified founts of "best practices" documents. Because security is a [X] Due diligence, [X} CYA item.
It's easy to blame HR and hiring practices for this, but really, this is too stupid to be the work of just HR alone.
I'm still somewhat tempted to say "I'd love to help..." but really, I don't any longer. I'm just going to continue sitting on the sidelines. I'll just enjoy the fireworks for once. It's not especially difficult to do better once you see what's really wrong, but "everyone" is too busy to ask, care, or notice. Oh well.
* WIth more and more poetteringesque crap added, usurping the useful Stuff, I count linux less and less as a Unix.