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.
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.
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.
Management only gives security lip service at best, they just want a minimal stable app for the minimal price. The only time they wake up is if there's a breech that costs them money.
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
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).
I've been a software developer for 25 years and a hardware engineer even longer. I don't get what this is saying. I guess making embedded software the whole "DevOps web dev" thing makes no sense to me and seems like a silly organizational thing.
But security isn't something you "integrate." If you don't start off with security on day 1 of design then there is none. You can't add it later.
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.
Interviewer: is security important to your organization? do you want to be more secure?
CTO: Yes oh course
later that day
IT guy: Hey CTO this security product costs 50k can we buy it
CTO: No
IT guy: ok i guess we will just need to be really careful about how we code
CTO: great do that
IT guy: ok cool so lets just add an extra 2 weeks to this project for security review....
CTO: no, this project needs to be done on time
IT guy: ok i guess since its so important we can wait but lets add a new project to review the security later
CTO: no, we have to many projects already.
I recall being at a security conference almost 10 years ago. They were all focused on scanning this application, or scanning that application for vulnerabilities, or teaching all the "security people" about this exploit or that exploit.
Everyone was focused on the damn technology, and NOBODY was thinking about the actual human beings that created the problems in the first place! So I asked a question to the group why nobody focused on actually educating the developers about all this stuff, instead of trying to find it all after it got created.
The answer was "Well they don't stick around long". Ha! Gee, maybe that's your problem? Creating environments were people actually want to stay, and you can improve people is perhaps a long term goal of any organization. These companies just wanted to treat developers like commodities. As if they were just McDonalds employees, and you could simply just replace them easily when they left.
The above of course is just normal Corprorate America thinking. People are fungible and don't matter. That's why they call them "resources" instead of people. Resources are things like water and lumber. One is mostly like another.
Very very much of these are corporate culture problems. Corporations like centralized control, and they just can't deal with this idea that maybe someone lower down the chain might be organizing things, and you
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.
Found the Democrat!
To cheap, they just don't care.
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"
before or after the boss/marketing/customer screams for the product and damn it all to testing/your testing should be good enough?
That the problem is with organizing your business around "DevOps" ? You're not really saving money or being more agile if DevOps isn't doing the job they are chartered to do.
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.
And APK just struggles with day to day life being an abject failure at every endeavor he has undertaken. The pinnacle of his life has been the file downloader and concatenator that he calls a host file engine that he coded with 12,000+ lines of code.
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.
Devops and secure products produced by the developers are independent issues. If this would have been a story about the lack of operational security related to the devops principles, frameworks or processes we might have something worthwhile to talk about. One could as well say that organizations find it hard to integrate development into devops.
The lack of security knowledge among all developers is allegedly an industry wide issue and companies apparently find it hard to cover the omissions in the basic training. Or outsource the work to people who actually know what they are doing in terms of security. Like they would do in any other industry.
This answer is really depressing. How do you understand the issues if you don't understand how it is coded?
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
Agreed. Plenty of security types know some coding. Hell, most IT professionals beyond entry level know some coding. Very few coders know how anything actually works beyond their IDEs. It's a big industry and far more complex than it was back in the day so I don't expect anyone to know everything but I do expect people to carry over their problem solving mindset and be able to actually learn and adapt to meet the situation. Security professionals can offer guidance on secure coding practices and maybe even assist in the process some but they aren't software developers. Ultimately its up to the developers to learn how security applies to their niche in the industry and how to best implement it. Security professionals have a hard enough time applying that to the unwashed masses, they shouldn't have to hold the hands of fellow technology professionals. There are books, seminars, classes and certifications that handle secure coding practices. Software devs should be incorporating those tools into their preexisting professional development.
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
Your software is just fine - well written, functional... I'm going to continue using the Host File Engine by mmell February 17, 2017
Your premise that hostfiles are a good way to deal with advertising and malvertising is quite valid - by JazzLad April 20, 2016
his hosts program is actually pretty good by xenotransplant August 10 2015
his hosts tool is actually useful for those cases in which one does indeed want to locally block stuff outright while consuming minimum system resources by alexgieg September 25 2015
I like your host file system by Karmashock September 09 2015
that APK guy, I use his host file by rogoshen1 Tuesday March 03, 2015
I personally use a HOSTS file blocker produced from a genius called APK by 110010001000 October 27 2017
* You've done BETTER by our /. peers (& I've DOZENS more like 'em - shall I post those too? Ask)?
APK
P.S.=> FAR from a "pinnacle of my life" (I've built/co-built systems that run companies info Fortune 500 down) but it's done well!
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."
If our DevOps team ask IT Security for help to hardening code, the best they will get is links to lengthy articles on best practices.
Why are DevOps being given a pass to not know their job? Why must a security team with their own responsibilities also intuitively know and take the time to teach DevOps how to code with security in mind properly?
Finally, security is an ever moving target. The best anyone can do is be aware of threats, know their systems, and use best practices. To scoff at literature about using best practices with secure coding is to admit you aren't ready to take responsibility for your own related actions and education.
A burglar is not an architect. A "security expert" is not a developer.
The cyber-attackers out there trying to break into sites are not developers: They are people with whatever intent (white, grey, black hats) who specialize in BREAKING the stuff that coders build. They are not trying to build anything: They are trying to insinuate their instructions into the code the developers are creating.
The "security expert" is not there to teach you how to code securely. That's YOUR job to learn how. The "security expert" is not there to assume responsibility for security from you: Security is EVERYONE'S responsibility, and the security of your code is YOUR responsibility
If a "security expert" doesn't solve your particular problem and sends you to "lengthy articles on best practices", then that is because you NEED to read and understand that article. If you just want the "security expert" to help you fix every mistake you make, that is NOT a workable model in any way.
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.
Advertiser/botnet herder/malware maker/webmaster ad profiteer you mean YOU don't since I block ads that infect/slow/track us + malscripts that do too as well as botnet C&C + endpoint malware download nodes you stuff into those scripted links AND in emails!
SO don't "speak for everyone" moron - yes, it's THAT EASY to know you're 1 of the above mentioned in my list here above (that or an INFERIOR competitor).
* GO away, grow up & GET ON TOPIC...
APK
P.S.=> You WISH you were me & could get such PRAISES Mr. JEALOUS "Lil' Jowie" who STALKS ME constantly by UNIDENTIFIABLE anonymous posts (since you FEAR me)... apk
Focusing on the technology means you don't have to deal with those pesky hyoomanz. Which is why most of us got in the computing business in the first place.
Focusing on the breadcrumbs ("scanning for defects") and not the whole picture (making sure the defects don't arise in the first place) means more bread on the table for the breadcrumb-following crowd.
And the mindnumbing tedious detail of that breadcrumb-hunting effectively keeps the brighter ones out, and so keeps the field to the perserverant few.
This has been the case since the field became a field.
Agile, Continuous Delivery, Continuous Security, DevOps, Lean, Waterfall .. so none of these actually contribute to secure code.
I don't threaten vs. a NOBODY
Shut your fucking pie hole you lying sack of shit.
You threaten people all the time and when called on it you hide in the fucking corner and piss yourself.
So come on pussycake post your fucking address
WRONG unidentifiable anonymous NOBODY (you're not a real person: Bugs Bunny has more identity than YOU do shitbrain)!
I literally threatened NO ONE (& you start w/ me constantly STALKING me by UNIDENTIFIABLE ac as you are now).
Don't play "jailhouse lawyer" w/ me - you'll LOSE on that alone!
Especially when even from your 'example' PROVES you START it harassing/stalking me 1st & constantly as you are now too!
So yes, & I tell 'your kind' I'll smash your face IF face to face (& yes, I mean it)!
Again - Only problem for you LEGALLY??
YOU'RE NOT A REAL PERSON (is "Anonymous Coward" who doesn't even ID himself as I do on your birth certificate as your NAME/IDENTITY? NO, it is not) so YOU CAN'T DO SHIT, lol - & I win, you lose!
* You're TOO STUPID to "F" w/ me dumbshit...
(I'd get you LAUGHED outta a court of law.. lol, guaranteed!)
See subject: You're nobody real & nobody in accomplishment either (lol, KING nothing).
APK
P.S.=> WHY you HIDE behind UNIDENTIFIABLE anonymous coward? You KNOW you're GUILTY of STALKING ME but were we to meet in person? I'd just bust your fucking teeth FLAT out of your PUNY jaw fucker (I've had it w/ your stalking bullshit)... apk
67% of DevOps is DevO
Also, 117% of businesses give two shits about security beyond plausible deniability when the next breach coincides with a quiet day on Trump's Twitter feed.
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.
Yep. That's the problem. You. You ooze being that quintessential butt-hurt IT security "professional" all over. I love how you throw around 'coders' as if it's something beyond half the shit you probably ripped off stack overflow. What does an IDE have to do with having solid logic and mastery of a language, syntax and principle engineering skills? Nothing.
From one anon to another: take your OWN advice and There are books, seminars, classes and certifications that handle secure coding practices. Software devs should be incorporating those tools into their preexisting professional development...and everyone you're barking that to, make sure you know it, be highly aware of it beyond it's mere existence and exercise it yourself in some form.
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.