92 Percent of Enterprises Struggle To Integrate Security Into DevOps (betanews.com) 90
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.
Re: (Score:1)
They will drain the corporate coffers dry under the guise of security if you allow it. It's really no different than insurance salesmen who want to sell you massive coverage of every type known to mankind. Basically, you get by with the minimum you can until proven otherwise. When proven otherwise, and only then, you invest slightly more to address the specific problem that burned you. Lather, rinse, repeat. Giving a blank check to DevOps to address "security" is fiscal suicide.
You got fired from Equifax, didn't you?
Re: Bottomless money pit (Score:3)
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.
Re: (Score:2)
Perfect security will drain the coffers. But there is a sweet spot where you can be sure you have reasonable security at a reasonable price.
Often what is really needed is just isolation from every layer in the application. Where the inputs from your form cannot be trusted with JavaScript formatting to insure correctness. You business layer will need to reevaluate what was entered, the Database should be setup with the correct security options and constraints.
Permissions of queries need to be made to make s
Re: (Score:2)
DevOps - Fundamentally insecure model (Score:1)
When all the responsibility falls on one person/group, at best you wind up with code developed and tested under the same small set of assumptions. If anything is missed, it won't be tested. DevOps removes layers of checking that could catch this.
In the worst case, since the group responsible for delivering functionality is also responsible for everything else, there's an inherent conflict of interest. Better security necessarily means less effort spent on delivering functionality.
You want to make your so
Re:DevOps - Fundamentally insecure model (Score:5, Informative)
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.
Re: (Score:2)
You describe scalable systems, not devops per se. Great if you're a big enough shop working a big enough project to write all the software that way.
Re: (Score:2)
DevOps became bastardized to mean the tools you use and not the mindset that you use during development and deployment. It takes more time to create secure software and DevOps has come to mean "you will use these tools to deploy applications faster, faster, FASTER!!!" (At least that's the way things worked so-called DevOps environments I've been exposed to recently.)
Re: (Score:2)
First, you move to immutable infrastructure. Stop patching, start designing to replace. We have a time limit on all VMs and containers to ensure they are replaced regularly to comply with 'patching'. New images are consistent and tested. Patched instances are not. Sure not all systems can meet this, but any workload that fits a container should by default be immutable.
Some workloads will still require patching (active directory for example). Ideally though 80% of your systems are immutable, 10% are able to
Re: (Score:2)
Immutable containers require (1) exhaustive automated testing and (2) ongoing software development for the lifetime of the product, that is the product must be discontinued at the same time as active development.
The first is merely expensive. The second - disallowing the very concept of legacy apps - hasn't demonstrated that it can be sustained over time.
Re: (Score:2)
I disagree. The testing is no more complex than testing random patches in production. In fact once the pipeline is built it is easier as you know the exact same artifact you used for DEV/QA/ETC is what is going in production. Your second argument doesn't hold up for similar reasons. Immutable or not, you still need testing, qa, etc. You simply can't know for sure production looks just like QA without immutable architecture.
Re: (Score:2)
That means that 8%... (Score:4, Insightful)
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.
Re: That means that 8%... (Score:2)
No, it just turns out that once you realize security isn't a checkbox, but an approach that is infused into every decision, then you internalize the process and it's no longer a struggle. The only struggle is to convince others that features aren't important if your customers all get hacked.
Re: (Score:2)
Re: (Score:2)
Yeah ok... (Score:1)
Because security is so well implemented elsewhere? What a joke.
Comment removed (Score:5, Informative)
Re:Security in DevOps (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
We leverage devops for everything. If it can't be pipelined it can't be implemented. We even changed AV companies because of a lack of a API. Our image building pipeline even uses test cases to ensure the resulting images really meet the requirements.
Comment removed (Score:4, Interesting)
Re: (Score:1)
There are a lot more security guys that can code than coders guys that know even how packets are transmited or what is a port or a encrypted channel. :)
In my opinion a lot of coders live on a imaginary world were no one hacks anything
Re: (Score:1)
I work in a multinational that has a dedicated IT security team. Not a single certified security IT professional can code. Not a one, though they each hold varying security certificates across multiple security disciplines.
Quite frankly, your entire security team should be fired. It sounds like not a single one of them has done real work in IT. I'd bet hard money they all came from some other discipline, studied for some dumb test, and got a certificate. If all they can do is recommend "best practices",
well the redhat backports lacking in PHP and you (Score:2)
well the redhat backports lacking in PHP and you need to add extra repos.
Why can't up the version numbers like ubuntu lts? or even suse with there SP's that come out from time to time?
Re: (Score:2)
You don't. If you can't code, if you don't grok the architecture and where the pieces fit and why, you don't understand.
If you don't know arithmetic, you don't know calculus.
Re: (Score:2)
Re: (Score:2)
IT security people that cannot code, cannot configure a network and generally are not engineers are basically worthless. All they can do is stand in people's way by insisting on usually pretty worthless "compliance". The thing is, however, there are security people out there that can code and can do it well. They are just a tad more expensive and more difficult to keep happy, but if you really want them, you can get them.
Security needs to be necessary (Score:3)
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.
Re: (Score:2)
Sure they all use version control. Until something happens and they are in a hurry.
Re: (Score:2)
I'm, unfortunately, in charge of my companies security drive for software and let me tell you I hear everything you said, apart from version control, from my boss.
It's very hard to convince anyone that just drawing a state machine on a white board and have a few people 'throw darts' at it is invaluable in saving time and improving security. A few minutes thinking about the abstract and how people can break it saves a boat load of time. Bu
Re: (Score:2)
Agile defines a 'big room' planning process. While this is intended to get buy-in for stakeholders in advance and an agreed scope for everyone to revert to when the SHTF, it also is when security is either built in or added on, and the results of either decision should be fairly obvious.
And sadly many coders don't even think about how users will 'screw with your system'. And your users are supposed to behave...
Re: (Score:2)
Comment removed (Score:4, Insightful)
Devops wasn't even designed (Score:2, Insightful)
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 trou
Re: thats not what devops is for. (Score:3)
I think it has more to do with ops not having the requisite skillset to understand the problem. Only someone who understands the software stack can deliver great solutions. That's where devops comes in. And this surely led to devs wearing two hats, but it's less a hiring problem than it is a mismatch in what developers expect from ops compared with what ignorant MBAs expect from ops. Our standards are higher and traditional ops folks don't cut it.
unfortunatelly DevOps is used for cost cutting (Score:4, Interesting)
Re: (Score:1)
Re: unfortunatelly DevOps is used for cost cutting (Score:1)
Read the Dockerfile for any FOSS images you deploy. They're blessedly simple compared with many other deployment manifest formats.
Re: unfortunatelly DevOps is used for cost cutting (Score:2)
None unless you perform a full audit.
It's quicker to build your own, with a more complete understanding of the security surface.
Ok, look- (Score:3)
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.
Re: (Score:3)
But it doesn't have to be that way. DevOps can still have least privilege and separation of duties. Pipelines can auto deploy to dev, push button to QA and require authorized users/quorums/etc to push to production. I know it's not done correctly everywhere, but we can say that about anything. I know a SaaS product that still has manual deploys to dev, QA, and prod done by hand. They do no security audits, their devs cowboy fix issues not caught in QA. Deployment know how is held by 2-3 people who are liter
Hire on merit (Score:2)
Ensure "security training" is done before the person gets to work on a brands projects.
The person knows what they are doing and can study at lot more every year to learn more.
Find the people who could study before passing exams on merit to get accepted into university.
Could they keep on getting educated while in university? Pass more exams? Learn? Study?
That might just be a good way of working out if they can keep on working for a company after university.
Say what? (Score:2)
92% of cooks do not know how to check their tire pressure. Will that do for a car-oriented example?
Security and DevOps have almost nothing to do with each other. DevOps is all about integrating your software development and your IT operations. Done right, it means that developed software flows smoothly into production. Done wrong, it means that your company is trying to save money by having the developers run the infrastructure, or the other way around.
Either way, it has little or nothing to do with securit
Pay for experienced developers. (Score:2)
Part of the problem is ageism in the industry.
The new fresh out of college programmer with all the new fancy buzzwords like Full Stack developer vs the old Product Life Cycle Developer often hacn't experience the pain of dealing with a security problem, and their skills are more to a point they are happy that it works at all. Vs a deep understanding of how to protect the product in the long term.
Bosses too combined the problem. They want the input screens ASAP, while the Experience developer will want the
Coherent view? (Score:2)
Why does nobody have a coherent view of security and development? The insanity is intentional. It comes from wanting logically impossible things because of money. Whatever. It will be interesting to see it keep burning.
It's a risky job, you know (Score:2)
Continuously delivered agile waterfall code (Score:2)
Enterprises are idiots (Score:2)
what is basically means at this point (Score:2)
is that security scanning and reporting tools are added to the CI/CD pipeline.
which is already a first good step in the right direction.