schedule a demo

Securing Innovation: Navigating Identity Risks in the SDLC

Updated: Feb 5

With the SolarWinds breach making headlines again due to recent SEC developments, it's an opportune moment to look back at such a watershed event in cybersecurity.  While identity risks impact the entire business, some of the unique complexities associated with the software development lifecycle (SDLC) and the teams involved should be considered as part of implementing a comprehensive identity security program.

 

It was initially speculated that a "Solarwinds123" password inadvertently exposed by an intern on their GitHub played a role in one of history's most significant supply chain attacks. While this specific concern has since been confirmed to be unrelated, then-CEO of SolarWinds confirmed in 2021 that the initial access was likely obtained through methods like a brute force attack on their VPN, credential theft via phishing or a watering hole strategy, or 3rd party zero-day exploitation. This highly notable breach highlights a broader trend reported by the Identity Defined Security Alliance (IDSA), showing that 90% of organizations have experienced at least one identity-based attack in the past year, underlining the essential need for strong identity security measures.

 

Software serves as the critical infrastructure underpinning the global economy, making the implications of security breaches immensely high for both the developers and their clientele. A breach within the SDLC doesn't merely risk compromising a company's intellectual property; it threatens to tarnish the brand's reputation and potentially precipitates a chain reaction of security vulnerabilities among its customer base.

 

The dynamic and highly skilled teams within a business's R&D department are the backbone of innovation, comprising intelligent and inventive technologists adept at tackling complex challenges through groundbreaking methods. However, possessing such a remarkable superpower to innovate is not without its kryptonite. The drive to deliver solutions with looming deadlines can lead to the unintended consequence of taking shortcuts (whether they are perceived as taking an actual shortcut or not) and increasing the risk of data breaches.

 

Such practices risk introducing security flaws into the code – a potential goldmine for cyber attackers – and jeopardize the integrity of the entire SDLC. Left unchecked, oversights can provide openings for threat actors to infiltrate systems, steal intellectual property, insert malicious code, and potentially orchestrate devastating supply chain attacks on a global scale.

 

Beyond coding practices, implementing cutting-edge security technologies, adopting rigorous security processes, and comprehensive training programs are essential to enhance the resilience of the SDLC against evolving threats. Within a landscape of multifaceted security considerations, identity security stands as a true cornerstone for proactive protection. 

 

While certainly not a comprehensive list, here are some top identity exposures that AuthMind has observed in companies with software development teams: 

 

Usage of Weak Passwords (aka the Password123 Problem)

 

So.. developers can be really smart, but they can be really lazy when picking passwords. They don’t have a great track record of always picking the best password to protect a development system or temporary system they set up to collaborate with a partner. Common pitfalls include choosing easily guessable passwords, recycling credentials across multiple systems, and sharing passwords with colleagues and partners. In some cases, developers have been found posting passwords to their personal GitHub accounts. 

 

Kevin Mandia, former CEO of FireEye, highlighted the role of weak and re-used passwords in state-sponsored attacks in his 2021 testimony to the U.S. Senate, where he identified "password spraying" as a primary method of attack by cyber intruders. 

 

Threat actors leverage weak or recycled credentials to infiltrate systems that may initially appear inconsequential but can serve as launchpads for broader attacks. These initial footholds provide attackers with a platform from which they can extend their reach within a development environment—a space often devoid of rigorous internal security measures, allowing minimal access to escalate into broad, unauthorized access to development systems with alarming speed.

 

Local Accounts in Development and Production Environments

 

In addition to the prevalent issue of weak or static passwords, another concerning practice among developers involves the creation and configuration of local accounts for the purpose of troubleshooting or expediting development tasks. These local accounts typically rely on static credentials, lack proper documentation (although they are often familiar to numerous employees - both current and ex), and remain unmonitored for potential unauthorized access.

To compound the problem, these accounts often find their way into production environments, exacerbating the vulnerability to attacks and amplifying their potential negative impact.

 

Such a situation renders these local accounts prime targets for malicious actors. They tend to bypass the stringent security protocols and monitoring systems implemented for accounts managed through an organization's identity and access management systems, creating a significant risk of unauthorized access to sensitive data and the potential escalation of privileges within the system. 

 

In addition to discouraging the widespread use of local accounts during the development phase, it is crucial for release-to-production procedures to remain vigilant in their efforts to detect and replace such accounts with those managed by the enterprise's identity infrastructure, ensuring they are actively monitored for any unauthorized access. Recognizing that even the most robust processes can overlook potential issues, enterprises should proactively implement monitoring mechanisms to detect hidden or shadow local accounts that may inadvertently make their way into production environments.

 

Use of Shadow Secrets Managers

 

In many AuthMind implementations, a recurring issue is the use of unapproved shadow secrets managers by software engineers to store credentials used by applications. While the alternative of hardcoded passwords is clearly much worse, these secrets managers need to be managed like any other piece of software or vendor. Software engineers are resourceful and often work against a deadline, so if your company hasn’t selected an approved secrets manager for developers, they will just pick one – which may be great, until it’s not.  

 

These solutions are like any other software; they must be patched for vulnerabilities, the vendor managed for supply chain risks, etc. By endorsing specific secrets manager tools, raising security awareness, and enacting strong governance measures, organizations can address the challenges posed by these shadow practices, ensuring the protection of sensitive data and maintaining the integrity of applications and infrastructure.

 

Service Account Mismanagement Risks

 

Service accounts, integral for connecting various development applications and enabling secure system communication, are often mismanaged in development and production environments. AuthMind's observations reveal that these service accounts are frequently reused across systems and inadequately monitored, making them prime targets for cyber threats. Practices such as using personal or admin credentials as makeshift service accounts, particularly to meet deadlines or simplify processes, significantly increase security vulnerabilities.

 

The risks associated with service account misuse are compounded when they bridge systems, potentially including third-party services. Key safeguards include avoiding using interactive user accounts as service accounts and ensuring strict adherence to the principle of least privilege. Monitoring for abnormal usage patterns or unauthorized access attempts is critical for the early detection of security breaches.

 

To counter service account risks, it's crucial for identity teams to rigorously identify and rectify misconfigurations, ensuring service accounts adhere to security best practices. Concurrently, SOCs must intensively monitor these accounts for signs of threats, such as anomalous activities or unauthorized access attempts. A coordinated strategy between identity and security teams establishes a comprehensive defense mechanism, significantly enhancing the organization's resilience against service account vulnerabilities.

 

To effectively tackle these challenges and reduce risk, forward-thinking security teams are turning to comprehensive platforms that combine identity security posture management (ISPM) and identity threat detection and response (ITDR) capabilities. Solutions such as AuthMind provide an integrated approach, ensuring continuous monitoring of identity security exposures and real-time identity threat detection within software development environments. 

 

By leveraging a unified ISPM and ITDR platform from a single vendor, R&D teams can more confidently accelerate their pace of innovation while upholding stringent security measures, ensuring a secure and efficient SDLC.