devopsy.kinsta.cloud

Tag: CISO

Succeeding at DevSecOps Requires a Rubric for SDLC Governance
In January 2024, the New York Times experienced a significant breach due to an exposed GitHub token, resulting in the theft of 270GB of sensitive data, including IT documentation and infrastructure tools. This incident is just one of many examples that underscores the urgent need for robust security measures throughout the software development lifecycle (SDLC).

In today’s world, software developers are our source of product; they are the workhorses in a booming digital economy. However, the productivity demands placed on developers often lead to a deprioritization of SDLC security measures. For example, when VPs of Engineering give large developer teams broad permissions across a code repository in the interests of speed, they may inadvertently create a large attack surface vulnerable to a single compromised account.

DevSecOps, a term that encompasses the combined efforts of development, security and operations acting as one unit, is an urgent security requirement for any CISO. By breaking down DevSecOps into four essential pillars – identity governance, CI/CD governance, code governance and SDLC compliance – organizations are provided with a rubric for preventing SDLC breaches. This framework also helps define a new category of security for development environments, referred to as SDLC governance.

The Four Pillars of SDLC Governance

Securing an SDLC is a monumental task. It’s not a simple shift left from the cloud infrastructure. Rather, an SDLC environment includes code repositories, run time environments, artifact repositories, open-source code scanners, secret managers, CI/CD tools and much more. These are four pillars to comprehensively wrap our heads around the SDLC Governance problem set:
- Identity Governance: Ensure that each developer and service account has the entitlements needed to do their job – no more, no less. Implementing strict identity governance policies limits access to only what is necessary, reducing the risk of unauthorized access that can lead to breaches. Additionally ensuring that Insider risk and external identity risky behavior are rapidly detected and contained is critical to mitigate SDLC identity risks.
- CI/CD Governance: Maintain consistent security postures for integration and deployment tools based on the context in which the application is being deployed. This means understanding the bespoke needs of each application that CI/CD tools apply tailored integration and deployment procedures.
- Code Governance: Assign an identity, date and time for the import of every package in the repository. This includes monitoring for secret leakage, static application security testing (SAST) vulnerabilities and performing infrastructure as code (IaC) Terraform scans.
- Compliance: Automate continuous compliance detection and remediation according to the relevant standards. By automatically detecting compliance failures and remediating them in real-time, organizations can meet industry standards and avoid potential fines or penalties.
Before implementing an effective SDLC Governance model, engaging stakeholders across the organization is critical. CISOs should collaborate with engineering leaders, AppSec leaders, DevOps leaders and compliance officers on SDLC security and governance policies to ensure that all aspects of security are considered and addressed.

Framework Implementation and Overcoming Challenges

Strong leadership from the CISO is essential to successfully implement this framework. However, many of the challenges CISOs face are not technology problems—they are cultural problems. As the primary advocate for security, the CISO must conduct thorough research to understand the organization’s specific security needs and challenges. Engaging staff and functional heads, the CISO must present evidence of potential threats and develop policies that balance productivity with robust security measures.

One major challenge is a culture where CISOs may defer to functions where IT is a core competency, often presuming that they understand the security risks the teams are taking. Another challenge stems from the nature of high-growth technology companies, where aggressive growth targets push engineering teams to prioritize speed over security. This “go, go, go” mentality leads to governance and security measures becoming secondary concerns.

Embracing SDLC Governance for a Secure Future

While the challenges of implementing SDLC Governance can be daunting, the successes CISOs have achieved in securing cloud infrastructure demonstrate what’s possible. Consider the rapid evolution from on-premise security, which took decades to perfect, to the seamless adoption of public and private cloud solutions in just a few years. CISOs have been instrumental in this transition, bringing in numerous developer tools and helping push products quickly. Not to mention, CISOs never get credit for all the breaches that don’t happen, yet they remain on their toes and are willing to talk to innovators to find solutions. Because of their work, I truly believe this industry can solve anything.

As businesses across all industries now rely heavily on software development, the urgency to integrate security into the DevOps process has never been greater. The nefarious attacker continues to experiment and exploit weaknesses in critical infrastructure. The recent battery of SDLC-focused attacks highlights the need for robust security measures in the manner in which software is built. It’s no longer sufficient to only protect the cloud in which the application is hosted.

If you’re waiting for the ASPM market to shift left, I’d offer that SDLC Governance is too complex for it to be done comprehensively by a typical cloud security provider. DevSecOps is its core competency and requires specialty tools and services to secure. Now is the time to engage your SDLC stakeholders and begin the journey of securing your development pipelines — the future of your organization’s security depends on it. Implementing an SDLC Governance framework that encompasses identity, CI/CD and code governance, as well as compliance will ensure that security is an integral part of your development process, safeguarding critical assets and fostering a culture of shared responsibility.
July 26, 2024
The Problem With Security

As an IT professional with decades of experience at every level of technology and organizations—from cell phone prototyping to banking enterprise architecture, from entry-level to CTO—I can state definitively that I have spent an inordinate amount of time dwelling on and dealing with security. And I know I’m not alone. This is a common theme. You could almost make a sitcom out of it. “What are your developers doing?” Uhhh … writing code? “That’s security!” I could go on, hitting on everything from users to cloud instances and you could fill in the “That’s security!” punchline every time.

That’s a problem. But not in the way you might think. I spent many years thinking I was somewhat unique in that I always rose to the occasion and approached security issues head-on. Most of the organizations I’ve worked for didn’t have dedicated security (I’ve probably written about that before), so some of us rose to the occasion. Nowhere near all of IT, but enough to feel like we were protected.

I now realize that I’m not all that unique; that more of us are doing the “learn security to be secure” thing than are not. I see it in modern organizations all the time. And I think that the real problem is this: Most of these people, like me, did not see themselves as security staff—but they are. Most organizations don’t recognize them as security staff—but they are.

We’ve long harped on cultivating security recruits from this pool, and I’m now going to suggest that you go even further. Make these people part of your planning. If you know that person X on the ReallyCoolApp team is ferreting out security stuff, ask them to just send an email to update InfoSec once a week. Don’t make it a huge burden, and don’t try to force them into a pure security role if they don’t show the aptitude and interest (you really don’t want unwilling security staff) but make use of their talents and drive. Certainly, if this person is doing a good job of making certain ReallyCoolApp is mostly locked down and DevSecOps tools are running against it for a secondary validation, then your limited InfoSec resources can be directed elsewhere.

Replicate this throughout the organization, and “That’s Security!” becomes a benefit rather than a hassle to try to lock down. You already do some of this—since the automation of passwords, most identity management is handled by operations staff, with security merely providing policy and being available to ops if needed. I’m simply suggesting that you expand this type of approach to include every IT department (and some non-IT departments in distributed environments). Don’t recruit everyone to be InfoSec, but recruit them to do a little bit of InfoSec in their area of specialty.

People have always said “Security is everyone’s problem,” which is true, but it’s far too vague to be useful. This is a workable intermediate. “Security is every team’s problem” and recruiting the people on each team most interested in InfoSec to formalize their involvement is a better approach.

And keep rocking it. We need security everywhere, because ne’er-do-wells have made everywhere a part of the InfoSec battleground. So recruit people everywhere without moving them from their current roles/responsibilities. Don’t let the sweet systems you’ve nursed through the years get whacked by attackers when a little recruiting and nurturing will fill the gap.

April 20, 2022
DevOps and Security: Focus on Importance

Why have I written “DevOps and Security” and not DevSecOps or one of the other names that floats around? Because this post is aimed to apply to everyone—not just those far enough along to have melded some of their security practices into DevOps.

Note: After I wrote this article but before I posted it, Bill Doerrfeld wrote this excellent example/solution post. It’s worth a read.

From the beginning, DevOps has struggled with a couple of touch points that don’t give themselves easily to the “frenetic movement” of DevOps. Security is one of those items. If your organization does manual vulnerability assessments, it is unlikely that this testing slips well into the DevOps process chain.

Most organizations that are dead set on making DevOps their primary dev/test/deliver platform have simply put limitations on security—limiting what long-running processes can be part of DevOps or dropping unaccommodating processes altogether. Some spectacular failures have occurred because of this type of thinking—and more will come—but for many the benefits of DevOps outweigh the risks. Will I get flamed for this paragraph? No doubt. That doesn’t make it untrue.

Given that IT has almost never given security the full leeway/authority that they want—and in shops where IT did, business often stepped in to say no—this really is not a massive change from how we have always done business. Just in the modern development environment, where a ton of libraries come from outside and configuration is software or data, there is a greater risk from running roughshod over the security team.

So what can security do to minimize the risk? Start looking more at enterprisewide and architectural risk. Accept that app or app portfolio team X is not going to give you time/resources to thoroughly vet their product and focus on things such as configuration files and malicious code embedded in that external library “Bob’s Really Good GIF Drawer™” that the team insists on using. Focus on the database configuration being in GIT or a shared (public/private) repository and what mischief might come about should attackers get at that repository. Run some of the increasingly sophisticated checkers against external libraries and review the results. As has been the growing case for years now, use automation to at least minimally check apps for things such as SQL Injection, but focus actual man-hours in places that might impact more of the organization. It might be worth the fight to get a full-on security review for applications or an application portfolio that touches the customer database, but perhaps not so much for the app used to schedule a conference room, even if customers are using it (unless it touches the customer database, of course; then see the first part of that statement).

Worry about network configuration as code, database configuration as code and the whole slew of unique security issues that come from public cloud. They’re manageable, and there are tools to help. Just make sure you have it down, because architecture is going to be the new target. A hacker doesn’t have to hack your DC if you left a public cloud storage bucket misconfigured and the data they want is in that bucket.

In too many organizations, the CISO is increasingly treated as chief compliance officer (assuming compliance does not interfere with DevOps cycles) with less to do with security and more to do with legal protection should security fail. Don’t be that organization. Security doesn’t have to be perfect; it just has to make you a hard enough target that only someone who really has it in for your company will keep trying.

As for Devs doing Agile and Ops doing DevOps, as has been true from the beginning, some of the security burden needs to fall to you. Security doesn’t have its hands in what you do every day, so ask them for guidance, learn from them; make it so they need to be active in every step, then include them in every step, because the security environment changes faster than almost anything else in IT. And when you are implementing monitoring, include security monitoring. In most DevOps shops, the question isn’t, “What can we monitor?” but rather, “In this wealth of data, what do we want to monitor?” Well, the answer should include, “What security thinks will help protect us and our customers’ data.”

As automation continues to increase, this tension will continue to ease, and focus can increasingly shift to locking down the really important bits such as database configurations and repositories. Until then, keep fighting the good fight and protect your customers’ ass(ets).

— Don Macvittie

November 29, 2018