Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security IT Technology

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.

This discussion has been archived. No new comments can be posted.

92 Percent of Enterprises Struggle To Integrate Security Into DevOps

Comments Filter:
  • by Anonymous Coward

    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

    • by Spazmania ( 174582 ) on Tuesday August 07, 2018 @10:41AM (#57085526) Homepage

      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.

      • by rnturn ( 11092 )

        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.)

      • 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

        • 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.

          • 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.

      • Try working for a company that has, over the last 25 years, amalgamated 37 different cable franchises, has never got all the disparate systems talking to each other, and struggles to support mission critical applications that have been obsolete/out of support for decades. That's me :-(
  • by bobbied ( 2522392 ) on Tuesday August 07, 2018 @09:59AM (#57085170)

    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.

  • Because security is so well implemented elsewhere? What a joke.

  • Comment removed (Score:5, Informative)

    by account_deleted ( 4530225 ) on Tuesday August 07, 2018 @10:01AM (#57085182)
    Comment removed based on user account deletion
    • by FictionPimp ( 712802 ) on Tuesday August 07, 2018 @10:11AM (#57085254) Homepage

      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.

      • Comment removed based on user account deletion
        • 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)

      by account_deleted ( 4530225 ) on Tuesday August 07, 2018 @10:16AM (#57085296)
      Comment removed based on user account deletion
      • by Anonymous Coward

        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 :)

    • by Anonymous Coward


      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",

    • Comment removed based on user account deletion
    • by gweihir ( 88907 )

      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.

  • by rickb928 ( 945187 ) on Tuesday August 07, 2018 @10:06AM (#57085210) Homepage Journal

    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.

    • by Durrik ( 80651 )
      You forgot: Designing will slow them down, much faster to just code.

      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
      • 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...

    • Comment removed based on user account deletion
  • Comment removed (Score:4, Insightful)

    by account_deleted ( 4530225 ) on Tuesday August 07, 2018 @10:08AM (#57085230)
    Comment removed based on user account deletion
    • by Anonymous Coward

      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

    • 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.

  • by kiviQr ( 3443687 ) on Tuesday August 07, 2018 @10:13AM (#57085270)
    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).
  • by llamalad ( 12917 ) on Tuesday August 07, 2018 @10:31AM (#57085428)

    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.

    • 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

  • 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.
  • 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

  • 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

  • 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.

  • Do they mean how none of the rest of the crew wants to mingle with the redshirts? Because that's just common prudence.
  • Agile, Continuous Delivery, Continuous Security, DevOps, Lean, Waterfall .. so none of these actually contribute to secure code.
  • 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.

Those who do things in a noble spirit of self-sacrifice are to be avoided at all costs. -- N. Alexander.

Working...