devopsy.kinsta.cloud

Tag: development security

  • Security Across the SDLC

    Security Across the SDLC

    We’ve seen some interesting movements in the security space over the last couple of years. My focus is on application security, but one of the movements we’ve seen is the blurring of what is application and what is infrastructure security, so I do a fair amount of that also. And then, with the advent of WAAP, we have network security playing a role in AppSec… It’s a growing snowball.

    I will start with the mandatory happy declaration that DevOps no longer treats security as an annoyance. While we’re well past that, I think the shock of the whole “security is a problem, not protection” mentality that DevOps started with is still hanging with us, and some still actively believe that. But at this point, we’re well on the “Security is part of the process” trail we should be on.

    If you look at the top-level changes, static application security testing (SAST) vendors have grown to be development security, covering SAST, DAST, IAST, RASP and even a bit of data security. Meanwhile, load balancers and WAF slowly evolved into full-on web applications and API security that covers the production side with active protections for things like DDoS and DLP.

    Likewise, we’ve seen this with the growth of cloud workload protection and how the entire digital architecture is being pulled into CSPM.

    I’ve said it before – we’re in a consolidation phase. It looks like it will go even further than I thought, though. Now, we are starting to see an interesting development: WAAP vendors are starting to include some or all of DAST, SAST and RASP. Arguably, they always did some IAST because their focus was on runtime protection, but their emphasis is more on protection than test, so it will be interesting to see that bit expand also.

    And all of this includes an inconvenient fact. We don’t have any more people to do security than we ever did; in fact, we have less. That’s part of the reason that we haven’t shoved security everywhere – there aren’t people to do it. In true DevOps fashion, we have distributed the work across other teams – Dev is right there where code security and API security start, so we’ve implemented SAST and DAST bits right into the IDE, for example. Or Ops has always done some amount of security, and we’ve just upped the amount. But they don’t magically have more time, either. I’m sure you are feeling it if you are a practitioner; almost all of us are. AI promises to help with that, and in security, it will likely deliver. Another thing I’ve pointed out before is that security is one space that really does stand to gain from generative AI – in helping make more secure code, in helping make all the permutations of tests, in making rules based upon observed data and more. The time-saving benefits will deliver, in my opinion. But it’s still a lot of work, and some of it is straight-up additional work because we weren’t doing things like container security a few years ago.

    In the short term, if full SDLC security is applied, there will be more work. In the long term, the mega platform for security may well reduce this work as it limits notifications across tools. Maybe we should name the coming mega platform SecArch. Also in the long term, AI will help alleviate some of the load. Until then, buckle in. You’re not likely to get staff to cover new work. But it will be worth it. Just keep plugging along, and know when to say you just can’t add one more thing to the pile.

  • Shared Responsibility? Yeah.

    Shared Responsibility? Yeah.

    One of the things that the last decade or two of enhancements has brought about is an increasing reliance on everyone across the organization to be more secure. While users have long since thrown up their hands and looked for ways to minimize the fallout when a vendor they frequent is compromised, enterprises have to lock down their own things. And given the ever-increasing volume and sophistication of attacks, the demands are growing.

    Cloud brought us the concept of a ‘shared responsibility‘ model. It is necessary in a world where an org does not control the physical servers and supporting infrastructure that applications ultimately run on. The fact is, the shared responsibility model was really cloud vendors reminding us that we still have to protect our apps, no matter where they’re deployed.

    This model and DevOps together have driven us to demand more of developers and DevOps teams with regard to security. It has also driven ops to have to care more, as more is exposed and security demands are up while security staff isn’t.

    And I’ll just remind you of the obvious. If you are responsible for security at the organization, you can get help from everyone, but those people’s job and direct responsibility is not security. They’re lending a hand because everyone cares, and that is the current state of most enterprises – DevOps made everyone involved in the SDLC a bit more responsible for all the things that aren’t their jobs (often a very good thing, often … not), but they’re not specially trained for it. That’s what security teams are for. And high-quality development security/policy management tools offer Dev and Ops and everyone in between a bit of guidance to good security practices along the way. I’ve praised putting security feedback right in the IDE half a dozen times here and elsewhere, and as a security-conscious developer, will continue to do so until it is so pervasive that people start to worry I’m losing it by going on about it. That’s a great example of helping everyone be more secure without requiring a ton of security staff hours in training. Developers don’t purposely write insecure code any more than they set out to make buggy spaghetti code. Giving tools to help them make the code more secure is a huge bonus – to them and to the corporate security team. So, if you’re not using them, start. And look into all of the other options to help non-security staff lock down their bit. The number of available security people on the market is perhaps the largest it has ever been (It’s so bad I actually know a security researcher who took months to find a new gig – that is pretty much unheard of or a unique case before recent days), but budgets to grow the security team aren’t there – any more than they are currently there to grow most teams. So tools to help are still imperative because you’re not going to get double the security staff in 2024 unless there’s only one of you … and you threatened to quit if they don’t get you help, which no one recommends as a negotiation tactic, so even if you’re solo, no doubling for you.

    Just remember who is responsible for overall infosec. Make use of the specialist and their knowledge in their space by finding tools to help them secure in a manner that matches workflow. Then verify because the organization’s security posture is security’s job.

    And keep rocking it. We’ve got so much cool stuff going on at the moment in IT in general that there is plenty of opportunity to improve architectures that are even relatively recent. Check what you have, consider it from a security perspective, improve what you have and keep rolling along.

    But first, relax, take a breather, and enjoy the holiday period.

  • Survey Surfaces Raft of DevSecOps Cultural and Technical Challenges

    Survey Surfaces Raft of DevSecOps Cultural and Technical Challenges

    A global survey of 606 IT, security, application development and DevOps decision-makers found that the biggest barrier to adoption of DevSecOps best practices is cultural rather than technical. However, the survey, which polled organizations with more than 500 employees and was conducted by Progress, also found only 16% of respondents planned to prioritize addressing those cultural issues in the next 12 to 18 months.

    A full 71% of respondents cited culture as the biggest barrier to DevSecOps progress, with only 30% expressing confidence in the current level of collaboration between security and application development teams currently being achieved. In contrast, 46% of respondents were not particularly confident while nearly a quarter (24%) were not at all confident.

    Nevertheless, well over half of respondents (57%) said security threats are the number-one technology factor driving the evolution of DevSecOps, even though just over half (51%) admitted they were only somewhat familiar with how security fit into a DevSecOps workflow.

    Overall, 86%of respondents said they are experiencing security challenges that include prioritizing externally facing applications over internal applications (47%), securing different types of workloads that were using different development and delivery methodologies (46%), meeting delivery deadlines (45%) and meeting audit requirements specified by the security team (39%). Just over three quarters (76%) recognized they could be more strategic in managing DevSecOps.

    The top three initiatives needed to support a shift to a more strategic DevSecOps approach identified are more investment in continuous learning for developers and engineers (61%), upskilling of developers and engineers to move into site reliability engineering (SRE) roles (60%) and improved communication between developers, security and operations (60%).

    Survey respondents also identified a need to define a clear set of policies and procedures (66%), define the role and responsibilities of staff across teams (62%), create a continuous feedback loop (49%) and automate recurring security tasks (41%).
    Despite that level of awareness, however, only 40% said they believed implementing security training and upskilling efforts across multiple stakeholders was very important when implementing DevSecOps.

    Prashanth Nanjundappa, vice president of product management for Progress, said given all the cultural and technical challenges organizations face, it’s apparent that both a top-down and bottom-up approach to implementing DevSecOps best practices is required. Attempting to shift responsibility left toward application development teams is not going to suffice on its own, he noted.

    The survey also suggested that many organizations are trying to address application security issues as they modernize their application portfolio. A total of 59% said they struggled to attain buy-in/funding for refactoring efforts that didn’t provide new user capabilities. However, only 39% said they had adopted a comprehensive modernization approach based on cloud-native architecture principles, while another 22% felt they lacked one entirely. Just under a quarter (24%) said their approach to modernization is to largely rip-and-replace applications.

    The top business factor driving the adoption of DevSecOps was a focus on business agility enabled by fast and frequent delivery of application capabilities (59%). Just under half (45%) said it had taken six to 12 months to achieve a return on DevSecOps investments, while 31% said it had taken longer than a year. However, only half (50%) of respondents were familiar and interested in both infrastructure and policy-as-code.

    There is no doubt that the DevSecOps journey ahead will be long and arduous. However, there are also a wide range of small process changes that could have a massive impact in terms of improving application security in the short term. The challenge is to quickly identify those opportunities while at the same time employing a more systematic approach that ultimately makes it a lot simpler to implement a set of DevSecOps best practices consistently.