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.
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 software development as cheap as you can? You get what you pay for.
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
Because security is so well implemented elsewhere? What a joke.
Comment removed based on user account deletion
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?
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.
Comment removed based on user account deletion
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.
Find the best of the best and hire them.
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.
"Security" is going to be difficult and need skills. Find staff who can keep working on difficult problems and who can take in new information.
The "trust" issue is looking around and knowing too many people did not get in on merit.
Domestic spying is now "Benign Information Gathering"
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 security. Newly written or modified sofware - is it written with security in mind? Has nothing to do with DevOps. Is your IT infrastructure secured? Has nothing to do with DevOps.
Security is important. This kind of article is a disservice - it's aimed at PHBs who like buzzwords.
Enjoy life! This is not a dress rehearsal.
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", get rid of them. I can google for crap like that.
I also have had experience with the "security team" at a multi-national. World Fuel Services (I name them because the world deserves to know how much they stink). At one point the "security team" ran a scan on our servers. The "security guy" told me I had to upgrade Apache to "the latest version". No... not the latest patched version for the Linux distribution I was on (which was still supported, completely patched to the latest patch, no known vulnerabilities existed, and got high marks for SSL configuration). What he meant was the highest version currently available. He wanted me to go download the highest version of Apache that was just released, and install this on the server! Then do that again, myself, every time a new version came out! (Instead of the standard practice of simply just yum update apache that any sane person does). Anyone know knows anything about software knows you DON'T DO THIS unless you have a VERY good reason to (custom patches, etc). Suddenly just replace your software with an untested version that might just suddenly break something. Yet, this is what this guy wanted me to do.
After several days of negotiating between him and my boss (who understood the problem thoroughly and was on my side 100%) we finally got him to agree that providing screen shots of everything being patched was sufficient. We were both just completely flabbergasted that this idiot wanted us to just upgrade to "the latest version". Later I found an actual post from Centos addressing this exact issue, so apparently this is a common idiotic understanding for some security people.
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.
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
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 security model set, and data collecting and gathering engine working, and input validation checking all set even before the first UI is out. This model is overall faster development. But it will mean a few weeks of nothing to show your boss or your customers.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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 sure you have access to such data. Or better yet, layout the data so you cannot access other information.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
This describes the most common reality. Development looks at the IT security team like they are a bunch of knuckle dragging apes. This also causes them to resent any kind of security oversight.
I object to power without constructive purpose. --Spock
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?
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.
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
Do they mean how none of the rest of the crew wants to mingle with the redshirts? Because that's just common prudence.
"The Greens lynched a hacker in Chicago. Last month, but I think the body's still hanging from the old Water Tower."
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Agile, Continuous Delivery, Continuous Security, DevOps, Lean, Waterfall .. so none of these actually contribute to secure code.
Great point. The DevOps Triangle is missing a leg. It cuts out the OS Admin who whould otherwise say... NO... Cant run as root! NO.. Cant disable SELinux. NO... Can't pull code from an internet based repository for basic services... Its done with a nod and a wink to the Security Team that means well, but just says. "OK. It must be proper". So.. there. I said it. Ignore the role of the OS admin at your peril. If DevOps can wrap in the input of an OS admin for Service security, it wont slow you down, unless your methods are inherently unsafe.
Time for a new Political party in the US (or two!) One is off the rails Other cant pony up a leader.
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.
You finally started producing decent code 2 years after being hired (and you didn't quit yet)? Let's shut down your team, cannibalize your resources and move you to another project, fire you, and then bring in new idiots to write bad code again.
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.
On a long enough timeline, the survival rate for everyone drops to zero.