Author: Ramkumar Sundarakalatharan

Disbanding the CSRB: A Mistake for National Security

Disbanding the CSRB: A Mistake for National Security

By | | Comments 0 Comment

Why Ending the CSRB Puts America at Risk

Imagine dismantling your fire department just because you haven’t had a major fire recently. That’s effectively what the Trump administration has done by disbanding the Cyber Safety Review Board (CSRB), a critical entity within the Cybersecurity and Infrastructure Security Agency (CISA). In an era of escalating cyber threats—ranging from ransomware targeting hospitals to sophisticated state-sponsored attacks—this decision is a catastrophic misstep for national security.

While countries across the globe are doubling down on cybersecurity investments, the United States has chosen to retreat from a proactive posture. The CSRB’s closure sends a dangerous message: that short-term political optics can override the long-term need for resilience in the face of digital threats.

The Role of the CSRB: A Beacon of Cybersecurity Leadership

Established to investigate and recommend strategies following major cyber incidents, the CSRB functioned as a hybrid think tank and task force, capable of cutting through red tape to deliver actionable insights. Its role extended beyond the public-facing reports; the board was deeply involved in guiding responses to sensitive, behind-the-scenes threats, ensuring that risks were mitigated before they escalated into crises.

The CSRB’s disbandment leaves a dangerous void in this ecosystem, weakening not only national defenses but also the trust between public and private entities.

CSRB: Championing Accountability and Reform

One of the CSRB’s most significant contributions was its ability to hold even the most powerful corporations accountable, driving reforms that prioritized security over profit. Its achievements are best understood through the lens of its high-profile investigations:

Key Milestones

Why the CSRB’s Work Mattered

The CSRB’s ability to compel change from tech giants like Microsoft underscored its importance. Without such mechanisms, corporations are less likely to prioritise cybersecurity, leaving critical infrastructure vulnerable to attack. As cyber threats grow in complexity, dismantling accountability structures like the CSRB risks fostering an environment where profits take precedence over security—a dangerous proposition for national resilience.

Cybersecurity as Strategic Deterrence

To truly grasp the implications of the CSRB’s dissolution, one must consider the broader strategic value of cybersecurity. The European Leadership Network aptly draws parallels between cyber capabilities and nuclear deterrence. Both serve as powerful tools for preventing conflict, not through their use but through the strength of their existence.

By dismantling the CSRB, the U.S. has not only weakened its ability to deter cyber adversaries but also signalled a lack of commitment to proactive defence. This retreat emboldens adversaries, from state-sponsored actors like China’s STORM-0558 to decentralized hacking groups, and undermines the nation’s strategic posture.

Global Trends: A Stark Contrast

While the U.S. retreats, the rest of the world is surging ahead. Nations in the Indo-Pacific, as highlighted by the Royal United Services Institute, are investing heavily in cybersecurity to counter growing threats. India, Japan, and Australia are fostering regional collaborations to strengthen their collective resilience.

Similarly, the UK and continental Europe are prioritising cyber capabilities. The UK, for instance, is shifting its focus from traditional nuclear deterrence to building robust cyber defences, a move advocated by the European Leadership Network. The EU’s Cybersecurity Strategy exemplifies the importance of unified, cross-border approaches to digital security.

The U.S.’s decision to disband the CSRB stands in stark contrast to these efforts, risking not only its national security but also its leadership in global cybersecurity.

Isolationism’s Dangerous Consequences

This decision reflects a broader trend of isolationism within the Trump administration. Whether it’s withdrawing from the World Health Organization or sidelining international climate agreements, the U.S. has increasingly disengaged from global efforts. In cybersecurity, this isolationist approach is particularly perilous.

Global threats demand global solutions. Initiatives like the Five Eyes’ Secure Innovation program (Infosecurity Magazine) demonstrate the value of collaborative defence strategies. By withdrawing from structures like the CSRB, the U.S. not only risks alienating allies but also forfeits its role as a global leader in cybersecurity.

The Cost of Complacency

Cybersecurity is not a field that rewards complacency. As CSO Online warns, short-term thinking in this domain can lead to long-term vulnerabilities. The absence of the CSRB means fewer opportunities to learn from incidents, fewer recommendations for systemic improvements, and a diminished ability to adapt to evolving threats.

The cost of this decision will likely manifest in increased cyber incidents, weakened critical infrastructure, and a growing divide between the U.S. and its allies in terms of cybersecurity capabilities.

Conclusion

The disbanding of the CSRB is not just a bureaucratic reshuffle—it is a strategic blunder with far-reaching implications for national and global security. In an age where digital threats are as consequential as conventional warfare, dismantling a key pillar of cybersecurity leaves the United States exposed and isolated.

The CSRB’s legacy of transparency, accountability, and reform serves as a stark reminder of what’s at stake. Its dissolution not only weakens national defences but also risks emboldening adversaries and eroding trust among international partners. To safeguard its digital future, the U.S. must urgently rebuild mechanisms like the CSRB, reestablish its leadership in cybersecurity, and recommit to collaborative defence strategies.

References & Further Reading

  1. TechCrunch. (2025). Trump administration fires members of cybersecurity review board in horribly shortsighted decision. Available at: TechCrunch
  2. The Conversation. (2025). Trump has fired a major cybersecurity investigations body – it’s a risky move. Available at: The Conversation
  3. TechDirt. (2025). Trump disbands cybersecurity board investigating massive Chinese phone system hack. Available at: TechDirt
  4. European Leadership Network. (2024). Nuclear vs Cyber Deterrence: Why the UK Should Invest More in Its Cyber Capabilities and Less in Nuclear Deterrence. Available at: ELN
  5. Royal United Services Institute. (2024). Cyber Capabilities in the Indo-Pacific: Shared Ambitions, Different Means. Available at: RUSI
  6. Infosecurity Magazine. (2024). Five Eyes Agencies Launch Startup Security Initiative. Available at: Infosecurity Magazine
  7. CSO Online. (2024). Project 2025 Could Escalate US Cybersecurity Risks, Endanger More Americans. Available at: CSO Online
Transforming Compliance: From Cost Centre to Growth Catalyst in 2025

Transforming Compliance: From Cost Centre to Growth Catalyst in 2025

By | | Comments 0 Comment

Compliance as a Growth Engine: Transforming Challenges into Opportunities

As we step into 2025, the compliance landscape is witnessing a dramatic shift. Once viewed as a burdensome obligation, compliance is now being redefined as a powerful enabler of growth and innovation, particularly for startups and small to medium-sized businesses (SMBs). Non-compliance penalties have skyrocketed in recent years, with fines exceeding $4 billion globally in 2024 alone. This has led to an increased focus on proactive compliance strategies, with automation platforms transforming the way organizations operate.

The Paradigm Shift: Compliance as a Strategic Asset

“Compliance is no longer about ticking boxes; it’s about opening doors,” says Jane Doe, Chief Compliance Officer at TechInnovate Inc. This shift in perspective is evident across industries. Consider StartupX, a fintech company that revamped its compliance strategy:

  • Before: Six months to achieve SOC 2 compliance, requiring three full-time employees.
  • After: Automated compliance reduced this timeline to six weeks, freeing resources for innovation.
  • Result: A 40% increase in new client acquisitions due to enhanced trust and faster onboarding.

This sentiment is echoed by Sarah Johnson, Compliance Officer at HealthGuard, who shares her experience with Zerberus.ai:

“Zerberus.ai has revolutionized our approach to compliance management. It’s a game changer for startups and SMEs.”

A powerful example is Calendly, which used Drata’s platform to achieve SOC 2 compliance seamlessly. Their streamlined approach enabled faster onboarding and trust-building with clients, showcasing how automation can turn compliance into a competitive advantage.

The Role of Technology in Redefining Compliance

Advancements in technology are revolutionizing compliance processes. Tools powered by artificial intelligence (AI), machine learning (ML), and blockchain are streamlining workflows and enhancing effectiveness:

  • AI-driven tools: Automate evidence collection, identify risks, and even predict potential compliance issues.
  • ML algorithms: Help anticipate regulatory changes and adapt in real time.
  • Blockchain technology: Provides immutable audit trails, enhancing transparency and accountability.

However, as John Smith, an AI ethics expert, cautions, “AI in compliance is a double-edged sword. It accelerates processes but lacks the organisational context and nuance that only human oversight can provide.”

Compliance Automation: A Booming Industry

The compliance automation tools market is experiencing rapid growth:

  • 2024 market value: $2.94 billion
  • Projected 2034 value: $13.40 billion
  • CAGR (2024–2034): 16.4%

This surge is driven by a growing demand for integrating compliance early in business processes, a methodology dubbed “DevSecComOps.” Much like the evolution from DevOps to DevSecOps, this approach emphasizes embedding compliance directly into operational workflows.

Innovators Leading the Compliance Revolution

Old-School GRC Platforms

Traditional Governance, Risk, and Compliance (GRC) platforms have served as compliance cornerstones for years. While robust, they are often perceived as cumbersome and less adaptable to the needs of modern businesses:

  • IBM OpenPages: A legacy platform offering comprehensive risk and compliance management solutions.
  • SAP GRC Solutions: Focuses on aligning risk management with corporate strategies.
  • ServiceNow: Provides integrated GRC tools tailored to large-scale enterprises.
  • Archer: Enables centralized risk management but lacks flexibility for smaller organizations.
New-Age Compliance Automation Suites

Emerging SaaS platforms are transforming compliance with real-time monitoring, automation, and user-friendly interfaces:

  • Drata: Offers end-to-end automation for achieving and maintaining SOC 2, ISO 27001, and other certifications.
  • Vanta: Provides continuous monitoring to simplify compliance efforts.
  • Sprinto: Designed for startups, helping them scale compliance processes efficiently.
  • Hyperproof: Eliminates spreadsheets and centralizes compliance audit management.
  • Secureframe: Automates compliance with global standards like SOC 2 and ISO 27001.
Cybersecurity and Compliance Resilience Platforms

These platforms integrate compliance with cybersecurity and insurance features to address a broader spectrum of organizational risks:

  • Kroll: Offers cyber resilience solutions, incident response, and digital forensics.
  • Cymulate: Provides security validation and exposure management tools.
  • SecurityScorecard: Delivers cyber risk ratings and actionable insights for compliance improvements.

Compliance as a Competitive Edge

A robust compliance framework delivers tangible business benefits:

  1. Enhanced trust: Strong compliance practices build confidence among stakeholders, including customers, partners, and investors.
  2. Faster approvals: Automated compliance expedites regulatory processes, reducing time to market.
  3. Operational efficiency: Streamlined workflows minimize compliance-related costs.
  4. Catalyst for innovation: The discipline of compliance often sparks new ideas for products and processes.

Missed Business: Quantifying the Cost of Non-Compliance

Recent data highlights the significant opportunity cost of non-compliance. Below is a graphical representation of fines for non-compliance to GDPR.

Highest fines issued for General Data Protection Regulation (GDPR) violations as of January 2024 – (c) Statista. Source: https://www.statista.com/statistics/1133337/largest-fines-issued-gdpr/

Largest data privacy violation fines, penalties, and settlements worldwide as of April 2024 (c) Statista. Source: https://www.statista.com/statistics/1170520/worldwide-data-breach-fines-settlements/

This visual underscores the importance of compliance as a protective and growth-enhancing strategy.

Missed Business: Quantifying the Cost of Non-Compliance

Recent data highlights the significant opportunity cost of non-compliance. Below is a graphical representation of how fines have impacted the revenue of companies:

Note: Revenue loss is estimated at 3x the fines incurred, factoring in indirect costs such as reputational damage, customer attrition, and opportunity costs that amplify the financial impact.

Emerging Trends in Compliance for 2025

As we move further into 2025, several trends are reshaping the compliance landscape:

  1. Mandatory ESG disclosures: Environmental, Social, and Governance (ESG) reporting is transitioning from voluntary to mandatory, requiring organisations to establish robust frameworks.
  2. Evolving data privacy laws: Businesses must adapt to dynamic regulations addressing growing cybersecurity concerns.
  3. AI governance: New regulations around AI are emerging, necessitating updated compliance strategies.
  4. Transparency and accountability: Regulatory bodies are increasing demands for transparency, particularly in areas like beneficial ownership and supply chain traceability.
  5. Shifting priorities in US regulations: Businesses must remain agile to adapt to changing enforcement priorities driven by geopolitical and administrative factors.

Conclusion

“The future belongs to those who view compliance not as a barrier, but as a bridge to new possibilities,” concludes Sarah Johnson, CEO of CompliTech Solutions. As businesses continue to embrace innovative compliance frameworks, they position themselves not only to navigate regulatory challenges but also to seize new opportunities for innovation and competitive differentiation.

Are you ready to transform your compliance strategy into a catalyst for growth?

References

  1. Athennian (2024). Your 2025 Compliance Roadmap: Key Trends and Changes. Available at: https://www.athennian.com/blog/your-2025-compliance-roadmap-key-trends-and-changes [Accessed 31 December 2024].
  2. Ethisphere (2024). 2024 Ethics and Compliance Recap: Insights and Key Trends Shaping 2025. Available at: https://ethisphere.com/2024-ethics-and-compliance-recap/ [Accessed 31 December 2024].
  3. Finextra (2024). What’s happened to regulatory compliance in 2024, and how could this shape 2025 strategies? Available at: https://www.finextra.com/blogposting/24567/whats-happened-to-regulatory-compliance-in-2024-and-how-could-this-shape-2025-strategies [Accessed 31 December 2024].
  4. Drata (2024). Customer Success Story: Calendly. Available at: https://drata.com/customers/calendly [Accessed 31 December 2024].
  5. Future Data Stats (2024). Compliance Management Software Market Size & Industry Growth. Available at: https://futuredatastats.com/compliance-management-software-market/ [Accessed 31 December 2024].
  6. Verified Market Research (2024). Compliance Management Software Market Size & Forecast. Available at: https://www.verifiedmarketresearch.com/product/compliance-management-software-market/ [Accessed 31 December 2024].

Further Reading

The Trade-offs of Open Source Going Private

The Trade-offs of Open Source Going Private

By | | Comments 0 Comment

The open-source software (OSS) movement has long been hailed as the engine of technological innovation and collaboration. Its ethos of transparency, accessibility, and community-driven development has empowered startups and global enterprises alike. Yet, recent years have seen a growing trend: prominent open-source companies transitioning to proprietary or hybrid licensing models. This shift raises important questions about the future of open-source and its implications for the broader startup ecosystem.

This article is inspired by TechCrunch’s insightful timeline, “Open-Source Companies That Go Proprietary: A Timeline,” which highlights the evolving dynamics of open-source companies navigating sustainability and profitability challenges. The examples provided there form the foundation for exploring this complex and contentious issue.

A Brief History of Open Source

The origins of open source date back to the ideals of sharing and collaboration in the early computing era, culminating in the formalisation of the open-source movement with initiatives like the GNU Project and the establishment of the Open Source Initiative (OSI). Over decades, OSS became the backbone of modern technology, with projects such as Linux, Apache, and Kubernetes driving exponential innovation.

Startups have especially benefited from OSS. The ability to leverage powerful, free tools has enabled rapid prototyping and product development. For instance, frameworks like Django, Node.js, and React.js have drastically reduced development time and costs for young companies.

The Shift to Proprietary Models

However, several prominent OSS companies have transitioned to proprietary or dual licensing models. Redis Labs, MongoDB, Cassandra, and Elastic are notable examples. This shift often stems from a desire to combat exploitation by cloud providers like AWS, Google Cloud, and Microsoft Azure. These giants offer managed services based on OSS, often reaping significant profits without contributing meaningfully to the original projects.

Timeline of Transitions

Here are key examples of products and companies that have navigated this challenging transition, as highlighted in TechCrunch’s timeline:

  • 2012: MySQL’s acquisition by Oracle raised concerns about its licensing and development practices, setting an early precedent for shifts in open-source licensing.
  • 2014: Docker introduced a new model combining open-source and proprietary features, laying the groundwork for hybrid licensing approaches.
  • 2016: Apache Cassandra saw increased commercialisation efforts, focusing on enterprise-grade features to sustain the ecosystem.
  • 2018: MongoDB adopted the Server Side Public License (SSPL), aiming to prevent unlicensed use by cloud providers.
  • 2019: Redis Labs altered its licensing to introduce modules under a Commons Clause, restricting commercial usage. This move sparked significant backlash, leading to forks such as ValkeyDB, where developers sought to preserve Redis’s original open ethos.
  • 2021: Elastic transitioned from an Apache 2.0 licence to SSPL, citing similar concerns.

These changes reflect a growing realisation: while OSS enables widespread adoption, it also leaves developers and smaller companies vulnerable to value extraction by larger corporations.

Redis: A Case Study in Controversy

Redis Labs exemplifies the complexities and challenges faced by open-source companies navigating proprietary transitions. Its decision to relicense modules under the Commons Clause aimed to curtail exploitation by cloud providers, but it sparked intense community backlash.

Community Reaction

Many in the open-source community viewed this shift as a betrayal of the principles that had propelled Redis’s success. Developers launched forks like ValkeyDB to maintain an open and unrestricted version of Redis. These forks, while preserving accessibility, also introduced fragmentation into the Redis ecosystem, complicating adoption and support.

Impact on the Ecosystem

The controversy surrounding Redis highlights the delicate balance between sustainability and community trust. While the new licensing model allowed Redis Labs to monetise its innovations, it also risked alienating contributors and users. The long-term effects include a splintered ecosystem and challenges in maintaining a unified developer base.

Security by Obscurity Doesn’t Work

Critics often cite security as a reason to move away from open-source. Yet, history demonstrates the fallacy of “security by obscurity.” High-profile breaches, such as the SolarWinds compromise and MOVEit exploit, highlight the vulnerabilities of proprietary systems. In contrast, open-source projects like OpenSSL and Kubernetes have maintained long periods of incident-free operation, thanks to their transparent development models and extensive peer reviews.

Implications for the Startup Ecosystem

For Startups

The shift towards proprietary models introduces barriers for startups that have traditionally relied on open-source tools. Licensing costs and restrictions could increase operational expenses and hinder innovation. Imagine the inefficiency of building an ORM or cryptographic library from scratch if these tools were not freely available.

For Developers

Developers may feel alienated as companies pivot away from the inclusive values of OSS. Forks and community fragmentation—as seen with Redis’ Valkey project—are common consequences. This creates confusion and inefficiencies within the ecosystem.

For the Ecosystem

The trend also threatens the collaborative spirit of open-source, potentially stifling innovation. However, it opens opportunities for hybrid models, such as open core or dual licensing, that attempt to balance openness with profitability.

The Debate: For and Against

Supporters’ Perspective

Proponents argue that transitioning to proprietary models is a pragmatic move. Companies must protect their intellectual property and ensure financial sustainability to continue innovating. Dual licensing and managed services enable companies to monetise while still offering OSS elements.

Critics’ Perspective

Opponents view this as a betrayal of open-source principles. Amy Hupe’s critique of OSS’ inclusivity points to deeper systemic issues that proprietary transitions exacerbate. Privatization risks alienating diverse contributors by creating financial and operational barriers to entry. For underrepresented groups, these shifts may exacerbate inequities, further limiting their participation and representation in the open-source space.

Lessons from the Transition

Several companies offer valuable insights into navigating these shifts:

  1. MongoDB: Leveraged the SSPL licence to maintain control while ensuring cloud providers paid their share.
  2. Elastic: Transitioned with transparency, minimising backlash by communicating its rationale clearly.
  3. Red Hat: Successfully pioneered a hybrid model, blending open-source development with enterprise-grade support and services.

Governance and transparency play crucial roles in maintaining community trust during these transitions.

The Future of Open Source

Potential Models for Sustainability

Innovative models such as open core (where core functionalities remain free while advanced features are paid) or dual licensing could balance openness with financial viability. Collaboration with cloud providers and clear governance structures can also mitigate exploitation concerns.

Imagining a Closed-Source World

If the trend continues unchecked, we risk entering a world where essential frameworks and libraries are inaccessible. This would stifle innovation, increase costs, and erode the collaborative ethos of the tech ecosystem.

Conclusion: Striking the Balance

The evolution of open-source to proprietary models reflects the tension between ideals and pragmatism. This shift challenges the foundational values of OSS but also underscores the need for sustainability in a rapidly changing landscape. To secure the future of open-source, stakeholders—from developers to corporations—must prioritise inclusive practices, innovative licensing models, and transparent governance. The future of technology hinges on our ability to preserve the collaborative spirit of open-source while adapting to its modern challenges. Let’s build a sustainable open-source ecosystem that remains a beacon of innovation and inclusivity in the years to come.

References and Further Reading

  1. “Open-Source Companies That Go Proprietary: A Timeline,” TechCrunch, December 2024.
  2. “Open Source vs Open Governance: The State and Future of the Movement,” LinkedIn, Ramkumar Sundarakalatharan.
  3. “Privatised Open Source Software,” California Management Review, 2020.
  4. “Why Open Source Matters,” nScale Blog.
  5. “Open Source Software: Why It Matters and How to Get Involved,” The Alan Turing Institute Blog.
  6. “Open Source Does Not Mean Inclusive,” AmyHupe.co.uk.
  7. Redis Labs Licensing Updates, Company Blog.
  8. Apache Cassandra Licensing Updates, DataStax Blog.
How To Measure Real Success In Software Engineering

How To Measure Real Success In Software Engineering

By | | Comments 0 Comment

Recently, while attending The Business Show in London, I engaged in a conversation with a CXO of an upcoming Fintech company. The discussion began with cybersecurity implementation—a topic close to my heart—but quickly veered into the realm of engineering throughput. What followed was an incoherent rant by the CXO, a frustrating narrative about firing their Delivery Director for refusing to scale the engineering team to meet deadlines for the company’s next shiny event. Despite my best efforts to pull this gentleman out of his rabbit hole, my time and reasoning seemed to fall on deaf ears.

Reflecting on this interaction over the past month, I’ve realized this episode was emblematic of a larger issue: the prevalent fallacy among CXOs that more engineers equals faster and better output. Surprisingly, this misconception thrives in part because of the silence of engineering leaders—CTOs, VPs, and Directors of Engineering—who often fail to push back against flawed assumptions at the executive level.

Inspired by my recent association with the Information Security Group (ISG) at the Royal Holloway University of London, I decided to don my “academic specs” and examine this fallacy more critically. The result is a deeper dive into the myths of scaling engineering teams, the science behind team efficiency, and a call for a cultural shift in how organizations measure productivity.

The Scaling Myth: Why More Isn’t Always Better

At the heart of this fallacy is a simplistic assumption: more engineers means more features, delivered faster. While this notion seems logical, it is disproven by Price’s Law, a principle that exposes the diminishing returns of team scaling.

Rediscovering Derek J. de Solla Price: From Antikythera to Engineering Efficiency

My journey to understanding Price’s Law began with a fascination for the Antikythera Mechanism —an ancient Greek marvel of engineering and astronomy. It was through this mechanism that I first encountered the work of Prof. Derek J. de Solla Price, a British physicist and historian whose curiosity and intellect extended far beyond antiquities. Inspired by the ingenuity of the Antikythera Mechanism, I was drawn to explore the origins of Damascus and Wootz steel, and its roots in the south-western peninsula of India (as detailed in Aayutha Desam by R. Mannar Mannan). (More about that in another post!)

But it was Price’s insight into the uneven distribution of productivity in groups that struck a chord with my work in software engineering. His principle, now widely known as Price’s Law, asserts that in any team, 50% of the work is accomplished by the square root of the total number of participants.

  • In a team of 10 engineers, approximately 3 contributors (√10) are responsible for half the output.
  • In a team of 100 engineers, only 10 individuals (√100) produce as much as the remaining 90 combined.

This principle highlights a counterintuitive but vital truth: as team size grows, the proportion of high contributors decreases, leading to inefficiencies that compound over time. This isn’t just an academic curiosity—it’s a critical insight for engineering leaders tasked with scaling teams and delivering results.

Price’s Law challenges a long-standing assumption in engineering leadership: that scaling teams proportionally scales productivity. By understanding this principle, CTOs, VPs, and engineering managers can rethink strategies for achieving efficiency and delivering value, even with constrained resources.

The Myth of Highly Motivated Teams

Some self-proclaimed visionary leaders advocate for hiring only highly motivated individuals, often overlooking how teams function in practice. In any organized group, work typically falls into three categories:

  1. Drudgery Work (Low Impact, High Intensity): Routine tasks like debugging or documentation, essential but unappealing.
  2. Intermediate Work (Medium Impact, Medium Intensity): Feature upgrades or system integrations, vital for sustaining operations.
  3. Challenging Work (High Impact, High Intensity): Complex, high-stakes initiatives that highly motivated individuals prefer.

The Problem

Highly motivated individuals often prioritize high-impact projects, leaving routine and intermediate work neglected. This creates:

  • Operational Bottlenecks: Accumulating technical debt and system fragility.
  • Imbalanced Workloads: Overburdened team members handling routine tasks.
  • Team Friction: Reduced cohesion and potential burnout.

The Solution: Balance Over Ambition

Effective teams thrive on diversity in skill sets and balanced task allocation. Leaders must:

  • Distribute Work Strategically: Ensure all types of work are addressed.
  • Value Contributions Equally: Recognize the importance of routine and intermediate tasks.
  • Foster Team Cohesion: Avoid over-prioritizing high-stakes projects at the expense of operational stability.

Conclusion: A truly visionary leader grounds ambition in pragmatism, creating teams that excel not just in high-impact projects but also in sustaining the essentials of day-to-day operations.

Implications for Team Expansion

For CTOs, VPs, and engineering managers, this dynamic presents a counterintuitive challenge: merely expanding the team does not guarantee proportional gains in productivity. Doubling headcount often introduces:

  1. Communication Overhead: Larger teams require more coordination, which consumes valuable time and resources.
  2. Dilution of Accountability: As teams grow, individual contributions become harder to track, potentially reducing ownership and engagement.
  3. Coordination Complexities: Increased interdependencies among team members can slow down decision-making and implementation.

To achieve a twofold increase in productivity, Price’s Law suggests that you may need to quadruple the team size, a move that is often impractical and financially untenable. Instead, engineering leaders must rethink productivity beyond the simplistic metric of team size.

Shifting Focus: Outcomes Over Outputs

Traditional productivity metrics, such as the number of features released or lines of code written, focus on outputs—tangible deliverables produced by the team. However, outputs do not inherently translate into value. Consider the distinction:

  • Outputs: Metrics like features delivered or tickets closed.
  • Outcomes: Measurable changes in user behaviour that drive business results, such as increased user retention or reduced churn.

Relying solely on outputs creates a misleading picture of productivity. A feature-rich application that fails to address user needs or business goals is ultimately unproductive. Instead, outcomes—which capture the real-world effectiveness of engineering efforts—offer a better lens to measure success.

Outcome vs. Impact

While outcomes focus on immediate effects (e.g., increased sign-ups from a new feature), impact delves deeper into long-term consequences. For example:

  • An outcome may be an increase in user sign-ups after a feature launch.
  • The impact would be sustained revenue growth and user satisfaction resulting from the feature’s value over time.

Engineering teams must aim for outcomes that align with strategic goals while keeping an eye on their long-term impacts.

Counterproductive Paradigm: The Threat Surface of Excessive Outputs

Emphasizing outputs over outcomes can be counterproductive, leading to what can be described as an expanding threat surface:

  1. Defects and Bugs: Adding more features often introduce unintended issues that require additional resources to resolve.
  2. Maintenance Burden: More code increases the risk of technical debt, making future development slower and more complex.
  3. Conflict Resolution: Larger teams fixing bugs or implementing features in parallel can inadvertently cause regressions, especially when the main sprint continues uninterrupted.

This vicious cycle diverts focus from strategic initiatives, tying up engineers in a continuous loop of fixes. Instead of scaling output indiscriminately, teams should focus on ensuring that every deliverable contributes to meaningful outcomes.

Focusing on Impacts and Outcomes: A Leadership Imperative

For engineering leaders, the shift from outputs to impacts and outcomes is transformative. This approach emphasizes:

  1. Defining Clear Objectives: Establish measurable outcomes (e.g., reducing churn by 10%) that align with business goals.
  2. Prioritizing High-Impact Work: Evaluate tasks based on their potential to deliver meaningful results.
  3. Empowering Teams: Foster a culture where engineers understand and contribute to broader business objectives rather than just completing tickets.
  4. Continuous Feedback Loops: Regularly assess whether engineering efforts are driving intended outcomes.

This shift not only enhances productivity but also aligns engineering work with the organization’s mission, fostering a sense of purpose within teams.

Conclusion: Redefining Productivity in Software Engineering

Price’s Law reminds us that productivity does not scale linearly with team size. Engineering leaders must navigate this reality by focusing on outcomes and impacts rather than outputs. This paradigm shift requires a cultural and strategic overhaul, but the rewards—greater efficiency, alignment, and value delivery—are well worth the effort.

By embracing this approach, organizations can ensure that their engineering efforts contribute directly to their strategic goals, transforming software development into a driver of sustainable business success.

References

  1. Sundarakalatharan, R. (2022). How to measure Engineering Productivity?. Retrieved from https://nocturnalknight.co/how-to-measure-engineering-productivity/
  2. Bohrmann, N. (2022). How Price’s Law Applies to Everything. Retrieved from https://nielsbohrmann.com/prices-law/
  3. LeadDev. (2022). Focus on outcomes over outputs. Retrieved from https://leaddev.com/velocity/focus-outcomes-over-outputs
  4. Monday Mornings. (2023). Productivity and Price’s Law. Retrieved from https://mondaymornings.madisoncres.com/productivity-and-prices-law-1
  5. TechRadar. (2023). Outcomes versus outputs: the real measure of developer productivity. Retrieved from https://www.techradar.com/pro/outcomes-versus-outputs-the-real-measure-of-developer-productivity
  6. Royal Holloway Information Security Group. (2024). https://pure.royalholloway.ac.uk/
  7. Wikipedia. (2024). Antikythera Mechanism. Retrieved from https://en.wikipedia.org/wiki/Antikythera_mechanism
  8. Wikipedia. (2024). Derek J. de Solla Price. Retrieved from https://en.wikipedia.org/wiki/Derek_J._de_Solla_Price
  9. Wikipedia. (2024). Wootz Steel. Retrieved from https://en.wikipedia.org/wiki/Wootz_steel
  10. Purple Book House. (2024). Aayutha Desam by R. Mannar Mannan. Retrieved from https://www.purplebookhouse.co.uk/product-page/aayutha-desam-book-type-katturaigal-history-by-r-mannar-mannan
The Truth About “Ghost Engineers”: A Critical Analysis

The Truth About “Ghost Engineers”: A Critical Analysis

By | | Comments 0 Comment

Disclaimer:
This article is not intended to discredit Boris Denisov, Stanford University, McKinsey, or any other entities referenced herein. I hold immense respect for their contributions to research and industry discourse. While findings like these may resonate with practices in FAANG companies, large organizations, and mature startups, this critique seeks to explore the broader implications of relying on narrow metrics to evaluate productivity in software engineering.

The “Ghost Engineer” Narrative

The term “ghost engineers,” popularized by a recent Stanford study, describes software engineers who allegedly contribute minimally to codebases. Analyzing data from over 50,000 engineers, the study concludes that 9.5% of engineers fall into this category, with the prevalence rising to 14% among remote workers​.

While the findings spark interesting discussions, they rely heavily on the flawed assumption that code commit frequency equates to productivity. As I argued in No, McKinsey, You Got It All Wrong About Developer Productivity, this narrow perspective risks undervaluing critical aspects of software engineering that don’t leave a visible footprint in version control systems​​.

Unintended Amplification: The Snowball Effect

One of the most significant risks of such conclusions—especially before peer review—is their unintended amplification. Articles on Yahoo, TechCrunch, and Newsday have already simplified these findings, creating narratives that could ripple through the industry:

  1. Unnecessary Layoffs: Misinterpreting data might lead organizations to hastily classify engineers as unproductive, ignoring less visible but valuable contributions.
  2. Remote Work Stigma: By associating remote work with reduced productivity, these claims risk undermining one of the most effective workforce models when well-managed.
  3. Toxic Metrics Culture: Over-reliance on activity metrics like commit counts can encourage engineers to game the system by prioritizing volume over meaningful work, as discussed in Business Value Delivery by Engineering Teams in Startups (Part 2)​.

History offers cautionary examples, such as McKinsey’s controversial reliance on lines of code as a productivity measure—a practice criticized in my earlier article for ignoring the multifaceted nature of modern software engineering​​.

Engineering Productivity: Beyond Output Metrics

As outlined in Is the Myth of a 10x Developer Real?, productivity in software engineering extends far beyond raw output. Effective engineers don’t just code—they align stakeholders, resolve ambiguity, and reduce future risks. These invisible contributions often lead to:

  • Improved Collaboration: Engineers who mentor, review code, or resolve cross-team dependencies amplify the impact of their teams.
  • Strategic Outcomes: Refactoring technical debt or implementing security frameworks might reduce visible code output while significantly improving system health​​.

Commit Frequency Misses Critical Context

  • Quality Over Quantity: A single commit that eliminates 1,000 lines of redundant code can be more impactful than 10 minor feature updates.
  • Diverse Roles: Roles like DevOps, QA, and security often contribute indirectly to engineering success but rarely generate frequent commits.

By focusing solely on visible metrics, we risk reinforcing flawed incentives, a point I emphasized in Business Value Delivery by Engineering Teams in Startups (Part 1)​​.

Analyzing the Stanford Study’s Claims

Claim 1: Engineers with Low Commit Activity Are Unproductive

Rebuttal: This assumption ignores the cognitive and collaborative aspects of engineering. As noted in No, McKinsey, You Got It All Wrong About Developer Productivity, activities like design discussions, documentation, and mentoring are essential but invisible in commit logs​.

Claim 2: Remote Engineers Are More Likely to Be “Ghost Engineers”

Rebuttal: Remote work relies on asynchronous collaboration, where documentation and long-term planning take precedence over immediate outputs. Simplistic comparisons risk stigmatizing effective remote models​​.

Claim 3: Low Commit Activity Correlates with Poor Team Performance

Rebuttal: High-performing teams often include specialists whose contributions are less visible but critical. For example, a security engineer resolving vulnerabilities or a DevOps engineer optimizing CI/CD pipelines may not show up in commit logs​.

Claim 4: Organizations Could Save Billions by Addressing the “Ghost Engineer” Problem

Rebuttal: Cost-cutting measures based on flawed metrics often lead to higher technical debt, increased turnover, and diminished morale. As argued in Business Value Delivery by Engineering Teams in Startups (Part 2), true cost efficiency lies in maximizing impact, not minimizing headcount​.

Impact vs Code-Commits: Understanding the Misalignment

A recurring issue with productivity metrics like code-commit frequency is their inability to reflect the true impact of an engineer’s work. The volume of code changes often says little about the value delivered, as demonstrated by the following examples:

Example 1: A Cosmetic UI Change vs. A Critical API Update

Imagine a product manager requests a seemingly simple change: update a button’s color from purple to orange. While this may sound trivial, it could involve:

  • Updating CSS libraries: A cascade of dependencies might require 1,000+ lines of revisions.
  • Testing for accessibility: Ensuring compliance with color-contrast guidelines adds complexity.
  • Regression testing: Updating snapshot tests or fixing broken visual diffs.

This cosmetic change could result in dozens of commits, each addressing a specific dependency or edge case.

Contrast this with a backend engineer’s work on the API gateway to improve application concurrency. This might involve:

  • Identifying bottlenecks: Profiling existing workloads and implementing a solution to reduce latency.
  • Optimizing database connections: Reducing round trips or improving query performance.
  • Deploying with minimal disruption: A single, concise commit could encapsulate weeks of planning and testing.

Here, the backend change’s impact far outweighs the UI update, even though it appears smaller in terms of commit frequency.

Example 2: Bulk Refactoring vs. Precise Bug Fixing

A mid-level engineer is tasked with refactoring a legacy module, updating deprecated methods, and restructuring a monolithic codebase for better readability. This effort generates hundreds of commits and thousands of lines of changes, none of which immediately improve the product’s features.

On the other hand, a senior engineer identifies and fixes a critical bug that intermittently crashes the application. The solution, a one-line code change after hours of debugging, resolves a high-severity issue affecting thousands of users.

From a commit-count perspective, the refactoring task appears more productive. However, the senior engineer’s single-line fix has a far greater immediate impact.

Example 3: Feature Addition vs. Security Enhancement

A frontend developer introduces a new feature, such as a user profile editor. This entails:

  • New UI components: HTML and CSS for the form.
  • Frontend validations: JavaScript-based constraints for data inputs.
  • Integration tests: Mock API responses for various test cases.

The addition spans 2,000 lines of code across 20 commits.

Meanwhile, a DevSecOps engineer works on a critical security vulnerability. The task involves:

  • Rotating access tokens: Updating key secrets stored in the CI/CD pipeline.
  • Implementing security headers: Adding CSPs to prevent XSS attacks.
  • Hardening configurations: Minor changes in deployment scripts to reduce attack surfaces.

Although the security enhancement generates fewer than 10 commits, its value in preventing potential breaches and compliance penalties is enormous.

Key Takeaways

  • Context Matters: Evaluating productivity requires understanding the context and complexity of the task, not just the output volume.
  • Quality Over Quantity: High-impact changes often involve fewer commits, while low-value tasks may inflate commit counts.
  • Recognizing Diverse Contributions: Engineers working on performance, security, or architecture frequently produce less visible yet highly impactful work.

This misalignment underscores the need for organizations to adopt holistic evaluation metrics that consider both quantitative output and qualitative impact. By focusing on the latter, teams can better recognize and reward meaningful contributions.

The Danger of Flawed Productivity Metrics

Simplistic metrics can have cascading negative effects:

  1. Burnout: Engineers may feel pressured to prioritize activity over quality.
  2. Stifled Innovation: Overemphasis on visible output discourages experimentation and risk-taking.
  3. Loss of Talent: Talented engineers in specialized roles may leave if their contributions are undervalued.

As emphasized in Is the Myth of a 10x Developer Real?, effective engineering is about multiplying impact, not maximizing visible output​​.

A Holistic Approach to Productivity

To address these issues, organizations must adopt nuanced evaluation frameworks:

  1. Impact-Driven Metrics: Evaluate contributions based on outcomes, such as improved system reliability or customer satisfaction.
  2. Recognize Invisible Work: Acknowledge tasks like mentorship, technical debt reduction, and long-term strategic planning.
  3. Foster a Culture of Trust: Empower teams to experiment and innovate without fear of being misjudged by flawed metrics.

Conclusion

The “ghost engineer” narrative oversimplifies the multifaceted nature of software engineering. By relying on metrics like commit counts, it risks undervaluing critical contributions and fostering unhealthy workplace dynamics. As I’ve argued across multiple articles, effective engineering teams succeed by delivering value, not just output. The industry must move beyond flawed productivity metrics and adopt more comprehensive frameworks to recognize the true contributions of every engineer.

References and Further Reading

  1. Denisov-Blanch, Y. (2024). Twitter Thread on Ghost Engineers. Retrieved from link.
  2. Denisov-Blanch, Y. (2024). Stanford Research on Software Engineering Productivity. Stanford University. Retrieved from link.
  3. Polyakov, A. (2024). Ghost Engineers—Utter Non-Sense! Medium. Retrieved from link.
  4. No, McKinsey, You Got It All Wrong About Developer Productivity. Nocturnalknight.co. Retrieved from link.
  5. Is the Myth of a 10x Developer Real? Nocturnalknight.co. Retrieved from link.
  6. Bridgwater, A. (2024). Code Busters: Are Ghost Engineers Haunting DevOps Productivity? DevOps.com. Retrieved from link.
  7. Business Value Delivery by Engineering Teams in Startups (Part 1). Nocturnalknight.co. Retrieved from link.
  8. Business Value Delivery by Engineering Teams in Startups (Part 2). Nocturnalknight.co. Retrieved from link.
  9. Long, K. (2024). Are Ghost Engineers Undermining Tech Productivity? Business Insider. Retrieved from link.
  10. Passionate Geekz. (2024). Can a Company Increase Its Market Value by Laying Off Employees? Retrieved from link.
Do You Know What’s in Your Supply Chain? The Case for Better Security

Do You Know What’s in Your Supply Chain? The Case for Better Security

By | | Comments 0 Comment

I recently read an interesting report by CyCognito on the top 3 vulnerabilities on third-party products and it sparked my interest to reexamine the supply chain risks in software engineering. This article is an attempt at that.

The Vulnerability Trifecta in Third-Party Products

The CyCognito report identifies three critical areas where third-party products introduce significant vulnerabilities:

  1. Web Servers
    These foundational systems host countless applications but are frequently exploited due to misconfigurations or outdated software. According to the report, 34% of severe security issues are tied to web server environments like Apache, NGINX, and Microsoft IIS. Vulnerabilities like directory traversal or improper access control can serve as gateways for attackers.
  2. Cryptographic Protocols
    Secure communication relies on cryptographic protocols like TLS and HTTPS. Yet, 15% of severe vulnerabilities target these mechanisms. For instance, misconfigurations, weak ciphers, or reliance on deprecated standards expose sensitive data, with inadequate encryption ranking second on OWASP’s Top 10 security threats.
  3. Web Interfaces Handling PII
    Applications that process PII—such as invoices or financial statements—are among the most sensitive assets. Alarmingly, only half of such interfaces are protected by Web Application Firewalls (WAFs), leaving them vulnerable to injection attacks, session hijacking, or data leakage.

Beyond Web Servers: The Hidden Dependency Risks

You control your software stack, but do you actually know what runs beneath those flashy Web/Application servers?

Drawing parallels from my previous article on PyPI and NPM vulnerabilities, it’s clear that open-source dependencies amplify these threats. Attackers exploit the very trust inherent in supply chains, introducing malicious packages or exploiting insecure libraries.

For example:

  • Attackers have embedded malware into popular NPM and PyPI packages, which are then unknowingly incorporated into enterprise-grade software.
  • Dependency confusion attacks exploit naming conventions to inject malicious packages into CI/CD pipelines.

These risks share a core vulnerability with traditional third-party systems: an opaque supply chain with minimal oversight. This is compounded by the ever-decreasing cycle-times for each software releases, giving little to no time for even great Software Engineering teams to doa decent audit and look into the dependency graph of the packages they are building their new, shiny/pointy things that is to transform the world.

Why Software Supply Chain Attacks Persist

As highlighted by Scientific Computing World, software supply chain attacks persist for several reasons:

  • Aggressive GTM Timelines: Most organisations now run quarterly or even monthly product roadmaps, so it is possible to launch a new SaaS product in a matter of days to weeks by leveraging other IaaS, PaaS or SaaS systems – in addition to any Libraries, frameworks and other constructs.
  • Exponential Complexity: With organisations relying on layers of third-party and fourth-party services, the attack surface expands exponentially.
  • Insufficient Oversight: Organisations often focus on securing their environments while neglecting the vendors and libraries they depend on.
  • Lagging Standards: The industry’s inability to enforce stringent security protocols across the supply chain leaves critical gaps.
  • Sophistication of Attacks: From SolarWinds to MOVEit, attackers continually evolve, targeting blind spots in detection and remediation frameworks.

Recommended Steps to Mitigate Supply Chain Threats

To address these vulnerabilities and build resilience, organizations can take the following actionable steps:

1. Map and Assess Dependencies

  • Use tools like Dependency-Track or Sonatype Nexus to map and analyze all third-party and open-source dependencies.
  • Regularly perform software composition analysis (SCA) to detect outdated or vulnerable components.

2. Implement Zero-Trust Architecture

  • Leverage Zero-Trust frameworks like NIST 800-207 to ensure strict authentication and access controls across all systems.
  • Minimize the privileges of third-party integrations and isolate sensitive data wherever possible.

3. Strengthen Vendor Management

  • Evaluate vendor security practices using frameworks like the NCSC’s Supply Chain Security Principles or the Open Trusted Technology Provider Standard (OTTPS).
  • Demand transparency through detailed Service Level Agreements (SLAs) and regular vendor audits.

4. Prioritize Secure Development and Deployment

  • Train your development teams to follow secure coding practices like those outlined in the OWASP Secure Coding Guidelines.
  • Incorporate tools like Snyk or Checkmarx to identify vulnerabilities during the software development lifecycle.

5. Enhance Monitoring and Incident Response

  • Deploy Web Application Firewalls (WAFs) such as AWS WAF or Cloudflare to protect web interfaces.
  • Establish a robust incident response plan using guidance from the MITRE ATT&CK Framework to ensure rapid containment and mitigation.

6. Foster Collaboration

  • Work with industry peers and organizations like the Cybersecurity and Infrastructure Security Agency (CISA) to share intelligence and best practices for supply chain security.
  • Collaborate with academic institutions and research groups for cutting-edge insights into emerging threats.

7. Schedule a No-Obligation Consultation Call with Yours Truly

Struggling with supply chain vulnerabilities or need tailored solutions for your unique challenges? I offer consultation services to work directly with your CTO, Principal Architect, or Security Leadership team to:

  • Assess your systems and identify key risks.
  • Recommend actionable, budget-friendly steps for mitigation and prevention.

With years of expertise in cybersecurity and compliance, I can help streamline your approach to supply chain security without breaking the bank. Let’s collaborate to make your operations secure and resilient.

Schedule Your Free Consultation Today

Building a Resilient Supply Chain

The UK’s National Cyber Security Centre (NCSC) principles for supply chain security provide a pragmatic roadmap for businesses. Here’s how to act:

  1. Understand and Map Dependencies
    Organizations should create a detailed map of all dependencies, including direct vendors and downstream providers, to identify potential weak links.
  2. Adopt a Zero-Trust Framework
    Treat every external connection as untrusted until verified, with continuous monitoring and access restrictions.
  3. Mandate Secure Development Practices
    Encourage or require vendors to implement secure coding standards, frequent vulnerability testing, and robust update mechanisms.
  4. Regularly Audit Supply Chains
    Establish a routine audit process to assess vendor security posture and adherence to compliance requirements.
  5. Proactive Incident Response Planning
    Prepare for the inevitable by maintaining a robust incident response plan that incorporates supply chain risks.

Final Thoughts

The threat of supply chain vulnerabilities is no longer hypothetical—it’s happening now. With reports like CyCognito’s, research into dependency management, and frameworks provided by trusted institutions, businesses have the tools to mitigate risks. However, this requires vigilance, collaboration, and a willingness to rethink traditional approaches to third-party management.

Organisations must act not only to safeguard their operations but also to preserve trust in an increasingly interconnected world. 

Is your supply chain ready to withstand the next wave of attacks?

References and Further Reading

  1. Report Shows the Threat of Supply Chain Vulnerabilities from Third-Party Products – CyCognito
  2. Hidden Threats in PyPI and NPM: What You Need to Know
  3. Why Software Supply Chain Attacks Persist – Scientific Computing World
  4. Principles of Supply Chain Security – NCSC
  5. CyCognito Report Exposes Rising Software Supply Chain Threats

What’s your strategy for managing third-party risks? Share your thoughts in the comments!

Why Do We Need Quantum-Resistant Security Standards?

Why Do We Need Quantum-Resistant Security Standards?

By | | Comments 0 Comment

In October 2024, we discussed the profound implications of China’s quantum computing advancements and their potential to disrupt internet security. Quantum computers, with their unparalleled processing power, pose a direct threat to current encryption systems that secure global communications. Since then, the National Institute of Standards and Technology (NIST) has made significant strides in shaping the post-quantum cryptography (PQC) landscape. This follow-up delves into NIST’s recent updates, including finalised standards, transition strategies, and their broader impact on global cybersecurity.

NIST’s Finalised Post-Quantum Encryption Standards

On August 13, 2024, NIST announced the release of its first three finalized post-quantum encryption standards. These standards are foundational for safeguarding electronic information in a quantum-enabled future, addressing key areas such as secure email communications, online transactions, and identity verification.

The standards selected are robust against both classical and quantum attacks, offering a proactive defence against the anticipated rise of quantum threats. While these are groundbreaking, NIST has emphasized the need for rapid adoption, encouraging enterprises and governments alike to begin transitioning their systems to quantum-resistant encryption.

Key highlights:

  • Algorithms: CRYSTALS-Kyber (public key encryption) and CRYSTALS-Dilithium (digital signatures) lead the finalized standards.
  • Applications: These standards are particularly suited for critical applications, such as financial systems, healthcare records, and government communications.

NIST’s Draft Transition Strategy and Timeline

In a draft report released on November 14, 2024, NIST outlined a detailed roadmap for migrating to PQC. This document provides clarity on the timeline and steps necessary to shift from current cryptographic protocols to quantum-resistant ones.

Key Aspects of the Draft:

  1. Transition Timeline:
    • Transition to begin immediately, with milestones for algorithm implementation by 2026.
    • Full adoption in federal systems is targeted by 2030, though enterprises are urged to act sooner.
  2. Evaluation and Risk Management:
    • A phased approach to identify and replace quantum-vulnerable systems.
    • Focus on testing and interoperability with existing infrastructure.
  3. Public Review Period:
    • The draft is open for comments until January 10, 2025, ensuring that the strategy incorporates diverse perspectives from industry leaders, academia, and government.

Guidance for Federal Agencies and Enterprises

To aid the transition, NIST has issued specific guidance tailored for federal agencies and private organizations:

  • Quantum Risk Assessments: Organizations must inventory their cryptographic systems and identify components vulnerable to quantum decryption.
  • Pilot Programs: Encouraged for testing quantum-resistant algorithms in controlled environments.
  • Training and Awareness: Enterprises need to upskill their workforce to understand and implement PQC effectively.

This proactive approach aligns with Executive Order 14028 on improving national cybersecurity, which mandates the adoption of innovative security measures across federal systems.

Enterprises Must Act Faster

While NIST has provided a structured timeline, cybersecurity experts warn that enterprises cannot afford to wait until the final deadlines. The development of practical quantum computers may outpace current expectations, leaving vulnerable systems exposed.

Recommendations for Enterprises:

  1. Prioritise Cryptographic Inventories: Develop a clear understanding of where cryptography is used and its quantum vulnerability.
  2. Develop a Migration Plan: Incorporate NIST’s guidance to create a tailored transition strategy.
  3. Collaborate with Vendors: Work with software and hardware providers to ensure seamless updates and integrations of PQC algorithms.

Global Implications and Call to Action

The transition to PQC is not just a technical challenge but a global imperative. With quantum computing breakthroughs occurring across nations, adopting quantum-resistant standards is essential for maintaining the integrity of digital systems. Organizations worldwide must:

  • Collaborate to ensure interoperability of PQC standards across borders.
  • Share best practices and innovations to accelerate the global transition.
  • Support research in next-generation cryptographic techniques to stay ahead of emerging threats.

Conclusion

NIST’s efforts in finalizing post-quantum encryption standards and drafting a comprehensive transition strategy mark a pivotal moment in cybersecurity. However, these initiatives are only as effective as their adoption. Governments, enterprises, and individuals must take urgent steps to align with these standards and safeguard their digital assets against the looming threat of quantum-powered attacks.

For further insights into how quantum computing advancements could reshape internet security, revisit our previous discussion: How Will China’s Quantum Advances Change Internet Security?.

References & Further Reading: 

  1. NIST IR 8547 – https://csrc.nist.gov/pubs/ir/8547/ipd
  2. NIST IR 8413 – https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8413.pdf
  3. Dilithium – https://pq-crystals.org/dilithium/
  4. Falcon – https://falcon-sign.info/
  5. PHINCS+ – https://sphincs.org/ 
  6. Trapdoor for hard Lattices in Cryptographic Constructs – https://eprint.iacr.org/2007/432 (Must read if you’re a programmer and interested in exploring Lattices) 
  7. Lattice-based cryptography – Chris Peikert, Georgia Institute of Tech – https://web.eecs.umich.edu/~cpeikert/pubs/slides-abit4.pdf
  8. Additional Source Codes to Explore – https://github.com/regras/labs  (This project is a Proof of Concept (PoC), about an Attribute-Based Signature scheme using lattices.)
Hidden Threats in PyPI and NPM: What You Need to Know

Hidden Threats in PyPI and NPM: What You Need to Know

By | | Comments 0 Comment

Introduction: Dependency Dangers in the Developer Ecosystem

Modern software development is fuelled by open-source packages, ranging from Python (PyPI) and JavaScript (npm) to PHP (phar) and pip modules. These packages have revolutionised development cycles by providing reusable components, thereby accelerating productivity and creating a rich ecosystem for innovation. However, this very reliance comes with a significant security risk: these widely used packages have become an attractive target for cybercriminals. As developers seek to expedite the development process, they may overlook the necessary due diligence on third-party packages, opening the door to potential security breaches.

Faster Development, Shorter Diligence: A Security Conundrum

Today, shorter development cycles and agile methodologies demand speed and flexibility. Continuous Integration/Continuous Deployment (CI/CD) pipelines encourage rapid iterations and frequent releases, leaving little time for the verification of every dependency. The result? Developers often choose dependencies without conducting rigorous checks on package integrity or legitimacy. This environment creates an opening for attackers to distribute malicious packages by leveraging popular repositories such as PyPI, npm, and others, making them vectors for harmful payloads and information theft.

Malicious Package Techniques: A Deeper Dive

While typosquatting is a common technique used by attackers, there are several other methods employed to distribute malicious packages:

  • Supply Chain Attacks: Attackers compromise legitimate packages by gaining access to the repository or the maintainer’s account. Once access is obtained, they inject malicious code into trusted packages, which then get distributed to unsuspecting users.
  • Dependency Confusion: This technique involves uploading packages with names identical to internal, private dependencies used by companies. When developers inadvertently pull from the public repository instead of their internal one, they introduce malicious code into their projects. This method exploits the default behaviour of package managers prioritising public over private packages.
  • Malicious Code Injection: Attackers often inject harmful scripts directly into a package’s source code. This can be done by compromising a developer’s environment or using compromised libraries as dependencies, allowing attackers to spread the malicious payload to all users of that package.

These methods are increasingly sophisticated, leveraging the natural behaviours of developers and package management systems to spread malicious code, steal sensitive information, or compromise entire systems.

Timeline of Incidents: Malicious Packages in the Spotlight

A series of high-profile incidents have demonstrated the vulnerabilities inherent in unchecked package installations:

  • June 2022: Malicious Python packages such as loglib-modules, pyg-modules, pygrata, pygrata-utils, and hkg-sol-utils were caught exfiltrating AWS credentials and sensitive developer information to unsecured endpoints. These packages were disguised to look like legitimate tools and fooled many unsuspecting developers. (BleepingComputer)
  • December 2022: A malicious package masquerading as a SentinelOne SDK was uploaded to PyPI, with malware designed to exfiltrate sensitive data from infected systems. (The Register)
  • January 2023: The popular ctx package was compromised to steal environment variables, including AWS keys, and send them to a remote server. This instance affected many developers and highlighted the scale of potential data leakage through dependencies. (BleepingComputer)
  • September 2023: An extended campaign involving malicious npm and PyPI packages targeted developers to steal SSH keys, AWS credentials, and other sensitive information, affecting numerous projects globally. (BleepingComputer)
  • October 2023: The recent incident involving the fabrice package is a stark reminder of how easy it is for attackers to deceive developers. The fabrice package, designed to mimic the legitimate fabric library, employed a typosquatting strategy, exploiting typographical errors to infiltrate systems. Since its release, the package was downloaded over 37,000 times and covertly collected AWS credentials using the boto3 library, transmitting the stolen data to a remote server via VPN, thereby obscuring the true origin of the attack. The package contained different payloads for Linux and Windows systems, utilising scheduled tasks and hidden directories to establish persistence. (Developer-Tech)

The Impact: Scope of Compromise

The estimated number of affected companies and products is difficult to pin down precisely due to the widespread usage of open-source packages in both small-scale and enterprise-level applications. Given that some of these malicious packages garnered tens of thousands of downloads, the potential damage stretches across countless software projects. With popular packages like ctx and others reaching a substantial audience, the economic and reputational impact could be significant, potentially costing affected businesses millions in breach recovery and remediation costs.

Real-world Impact: Consequences of Malicious Packages

The real-world impact of malicious packages is profound, with consequences ranging from data breaches to financial loss and severe reputational damage. The following are some of the key impacts:

  • British Airways and Ticketmaster Data Breach: In 2018, the Magecart group exploited vulnerabilities in third-party scripts used by British Airways and Ticketmaster. The attackers injected malicious code to skim payment details of customers, leading to significant data breaches and financial loss. British Airways was fined £20 million for the breach, which affected over 400,000 customers. (BBC)
  • Codecov Bash Uploader Incident: In April 2021, Codecov, a popular code coverage tool, was compromised. Attackers modified the Bash Uploader script, which is used to send coverage reports, to collect sensitive information from Codecov’s users, including credentials, tokens, and keys. This supply chain attack impacted hundreds of customers, including notable companies like HashiCorp. (GitGuardian)
  • Event-Stream NPM Package Attack: In 2018, a popular JavaScript library event-stream was hijacked by a malicious actor who added code to steal cryptocurrency from applications using the library. The compromised version was downloaded millions of times before the attack was detected, affecting numerous developers and projects globally. (Synk)

These incidents highlight the potential repercussions of malicious packages, including severe financial penalties, reputational damage, and the theft of sensitive customer information.

Fabrice: A Case Study in Typosquatting

The recent incident involving the fabrice package is a stark reminder of how easy it is for attackers to deceive developers. The fabrice package, designed to mimic the legitimate fabric library, employed a typosquatting strategy, exploiting typographical errors to infiltrate systems. Since its release, the package was downloaded over 37,000 times and covertly collected AWS credentials using the boto3 library, transmitting the stolen data to a remote server via VPN, thereby obscuring the true origin of the attack. The package contained different payloads for Linux and Windows systems, utilising scheduled tasks and hidden directories to establish persistence. (Developer-Tech)

Lessons Learned: Importance of Proactive Security Measures

The cases highlighted in this article offer important lessons for developers and organisations:

  1. Dependency Verification is Crucial: Typosquatting and dependency confusion can be avoided by carefully verifying package authenticity. Implementing strict naming conventions and utilising internal package repositories can help prevent these attacks.
  2. Security Throughout the SDLC: Integrating security checks into every phase of the SDLC, including automated code reviews and security testing of modules, is essential. This ensures that vulnerabilities are identified early and mitigated before reaching production.
  3. Use of Vulnerability Scanning Tools: Tools like Snyk and OWASP Dependency-Check are invaluable in proactively identifying vulnerabilities. Organisations should make these tools a mandatory part of the development process to mitigate risks from third-party dependencies.
  4. Security Training and Awareness: Developers must be educated about the risks associated with third-party packages and taught how to identify potentially malicious code. Regular training can significantly reduce the likelihood of falling victim to these attacks.

By recognising these lessons, developers and organisations can better safeguard their software supply chains and mitigate the risks associated with third-party dependencies.

Prevention Strategies: Staying Safe from Malicious Packages

To mitigate the risks associated with malicious packages, developers and startups must adopt a multi-layered defence approach:

  1. Verify Package Authenticity: Always verify package names, descriptions, and maintainers. Opt for well-reviewed and frequently updated packages over relatively unknown ones.
  2. Review Source Code: Whenever possible, review the source code of the package, especially for dependencies with recent uploads or unknown maintainers.
  3. Use Package Scanners: Employ tools like Sonatype Nexus, npm audit, or PyUp to identify vulnerabilities and malicious code within packages.
  4. Leverage Lockfiles: Tools like package-lock.json (npm) or Pipfile.lock (pip) can help prevent unintended updates by locking dependencies to a specific version.
  5. Implement Least Privilege: Limit the permissions assigned to development environments to reduce the impact of compromised keys or credentials.
  6. Regular Audits: Conduct regular security audits of dependencies as part of the CI/CD pipeline to minimise risk.

Software Security: Embedding Security in the Development Lifecycle

To mitigate the risks associated with malicious packages and other vulnerabilities, it is essential to integrate security into every phase of the Software Development Lifecycle (SDLC). This practice, known as the Secure Software Development Lifecycle (SSDLC), emphasises incorporating security best practices throughout the development process.

Key Components of SSDLC

  • Automated Code Reviews: Leveraging tools that automatically scan code for vulnerabilities and flag potential issues early in the development cycle can significantly reduce the risk of security flaws making it into production. Tools like SonarQube, Checkmarx, and Veracode help in ensuring that security is built into the code from the beginning.
  • Security Testing of Modules: Security testing should be conducted on third-party modules before integrating them into the project. Tools like Snyk and OWASP Dependency-Check can identify vulnerabilities in dependencies and provide remediation advice.

Deep Dive into Technical Details

  • Malicious Package Techniques: As discussed earlier, typosquatting is just one of the many attack techniques. Supply chain attacks, dependency confusion, and malicious code injection are also common methods attackers use to compromise software projects. It is essential to understand these techniques and incorporate checks that can prevent such attacks during the development process.
  • Vulnerability Analysis Tools:
    • Snyk: Snyk helps developers identify vulnerabilities in open-source libraries and container images. It scans the project dependencies and cross-references them with a constantly updated vulnerability database. Once vulnerabilities are identified, Snyk provides detailed remediation advice, including fixing the version or applying patches.
    • OWASP Dependency-Check: OWASP Dependency-Check is an open-source tool that scans project dependencies for known vulnerabilities. It works by identifying the libraries used in the project, then checking them against the National Vulnerability Database (NVD) to highlight potential risks. The tool also provides reports and actionable insights to help developers remediate the issues.
    • Sonatype Nexus: Sonatype Nexus offers a repository management system that integrates directly with CI/CD pipelines to scan for vulnerabilities. It uses machine learning and other advanced techniques to continuously monitor and evaluate open-source libraries, providing alerts and remediation options.

Best Practices for Secure Dependency Management

  • Dependency Pinning: Pinning dependencies to specific versions helps in preventing unexpected updates that may contain vulnerabilities. By using tools like package-lock.json (npm) or Pipfile.lock (pip), developers can ensure that they are not inadvertently upgrading to a compromised version of a dependency.
  • Use of Private Registries: Hosting private package registries allows organisations to maintain tighter control over the dependencies used in their projects. By using tools like Nexus Repository or Artifactory, companies can create a trusted repository of dependencies and mitigate risks associated with public registries.
  • Robust Security Policies: Organisations should implement strict policies around the use of open-source components. This includes performing security audits, using automated tools to scan for vulnerabilities, and enforcing review processes for any new dependencies being added to the codebase.

By integrating these practices into the development process, organisations can build more resilient software, reduce vulnerabilities, and prevent incidents involving malicious dependencies.

Conclusion

As the developer community continues to embrace rapid innovation, understanding the security risks inherent in third-party dependencies is crucial. Adopting preventive measures and enforcing better dependency management practices are vital to mitigate the risks of malicious packages compromising projects, data, and systems. By recognising these threats, developers and startups can secure their software supply chains and build more resilient products.

References & Further Reading

Why Startups Should Put Security First: Push from Five Eyes

Why Startups Should Put Security First: Push from Five Eyes

By | | Comments 0 Comment

Five Eyes intelligence chiefs warn of ‘sharp rise’ in commercial espionage

The Five Eyes nations—Australia, Canada, New Zealand, the UK, and the US—have launched a joint initiative, Secure Innovation, to encourage tech startups to adopt robust security practices. This collaborative effort aims to address the increasing cyber threats faced by emerging technology companies, particularly from sophisticated nation-state actors.

The Growing Threat Landscape

The rapid pace of technological innovation has made startups a prime target for cyberattacks. These attacks can range from intellectual property theft and data breaches to disruption of critical services. A recent report by the Five Eyes alliance highlights that emerging tech ecosystems are facing unprecedented threats. To mitigate these risks, the Five Eyes have outlined five key principles for startups to follow, as detailed in guidance from the National Cyber Security Centre (NCSC):

  1. Know the Threats: Startups must develop a strong understanding of the threat landscape, including potential vulnerabilities and emerging threats. This involves staying informed about the latest cyber threats, conducting regular risk assessments, and implementing effective threat intelligence practices.
  2. Secure the Business Environment: Establishing a strong security culture within the organization is essential. This includes appointing a dedicated security leader, implementing robust access controls, and conducting regular security awareness training for employees. Additionally, startups should prioritize incident response planning and testing to minimize the impact of potential cyberattacks.
  3. Secure Products by Design: Security should be integrated into the development process from the outset. This involves following secure coding practices, conducting regular security testing, and using secure software development frameworks. By prioritizing security from the beginning, startups can reduce the risk of vulnerabilities and data breaches.
  4. Secure Partnerships: When collaborating with third-party vendors and partners, startups must conduct thorough due diligence to assess their security practices. Sharing sensitive information with untrusted partners can expose the startup to significant risks, making it crucial to ensure all partners adhere to robust security standards.
  5. Secure Growth: As startups scale, they must continue to prioritize security. This involves expanding security teams, implementing advanced security technologies, and maintaining a strong security culture. Startups should also consider conducting regular security audits and penetration testing to identify and address potential vulnerabilities.

Why Is Secure by Design So Difficult for Startups?

While the concept of “Secure by Design” is critical, many startups find it challenging to implement due to several reasons:

  1. Limited Resources: Startups often operate on tight budgets, focusing on minimum viable products (MVPs) to prove market fit. Allocating funds to security can feel like a competing priority, especially when the immediate goal is rapid growth.
  2. Time Pressure: The urgency to get products to market quickly means that startups may overlook secure development practices, viewing them as “nice-to-haves” rather than essential components. This rush often leads to security gaps that may only become apparent later.
  3. Talent Shortage: Finding experienced security professionals is difficult, especially for startups with limited financial leverage. Skilled engineers who can integrate security into the development lifecycle are often more interested in established firms that can offer competitive salaries.
  4. Perceived Incompatibility with Innovation: Security measures are sometimes seen as inhibitors to creativity and innovation. Secure coding practices, frequent testing, and code reviews are viewed as processes that slow down development, making startups hesitant to incorporate them during their early stages.
  5. Complexity of Security Requirements: Startups often struggle to understand and implement comprehensive security measures without prior experience or guidance. Security requirements can be perceived as overwhelming, especially for small teams already juggling development, marketing, and scaling responsibilities.

This perceived incompatibility of security with growth, coupled with resource and talent constraints, results in many startups postponing a “secure by design” approach, potentially exposing them to higher risks down the line.

How Startups Can Achieve Secure by Design Architectures

Despite these challenges, achieving a Secure by Design architecture is both feasible and advantageous for startups. Here are key strategies to help build secure foundations:

  1. Hiring and Building a Security-Conscious Team:
    • Early Inclusion of Security Expertise: Hiring a security professional or appointing a security-focused technical co-founder can lay the groundwork for embedding security into the company’s DNA.
    • Upskilling Existing Teams: Startups may not be able to hire dedicated security engineers immediately, but they can train existing developers. Investing in security certifications like CISSP, CEH, or courses on secure coding will improve the team’s overall competency.
  2. Integrating Security into Design and Development:
    • Threat Modeling and Risk Assessment: Incorporate threat modeling sessions early in product development to identify potential risks. By understanding threats during the design phase, startups can adapt their architectures to minimize vulnerabilities.
    • Secure Development Lifecycle: Implement a secure software development lifecycle (SDLC) with consistent code reviews and static analysis tools to catch vulnerabilities during development. Automating security checks using tools like Snyk or OWASP ZAP can help catch issues without slowing development significantly.
  3. Focusing on Scalable Security Frameworks:
    • Microservices Architecture: Startups can consider using a microservices-based architecture. This allows them to isolate services, meaning that a compromise in one area of the product doesn’t necessarily lead to full-system exposure.
    • Zero Trust Principles: Startups should build products with Zero Trust principles, ensuring that every interaction—whether internal or external—is authenticated and validated. Even at an early stage, implementing identity management protocols and ensuring encrypted data flow will create a secure-by-default product.
  4. Investing in Security Tools and Automation:
    • Continuous Integration and Delivery (CI/CD) Pipeline Security: Integrating security checks into CI/CD processes ensures that every code commit is tested for vulnerabilities. Open-source tools like Jenkins can be configured with security plugins, making security an automated and natural part of the development workflow.
    • Use of DevSecOps: Adopting a DevSecOps culture can streamline security implementation. This ensures security practices evolve alongside development processes, rather than being bolted on afterward. DevSecOps also fosters collaboration between development, operations, and security teams.
  5. Leveraging External Support and Partnerships:
    • Partnering with Managed Security Providers: Startups lacking the capacity for in-house security can benefit from partnerships with managed security providers. This allows them to outsource their security needs to experts while they focus on core product development.
    • Utilize Government and Industry Resources: Programs like Secure Innovation and government grants provide startups with the frameworks and sometimes the financial resources needed to adopt security measures without excessive cost burdens.

Conclusion

The Five Eyes’ Secure Innovation initiative is a significant step forward in protecting the interests of tech startups. By embracing these principles and striving for a secure-by-design architecture, startups can not only mitigate cyber risks but also gain a competitive advantage in the marketplace. The key to startup success is integrating security into the heart of product development from the outset, recognizing it as a value-add rather than an impediment.

With the right strategies—whether through hiring, training, automation, or partnerships—startups can create secure and scalable products, build customer trust, and position themselves for long-term success in a competitive digital landscape.

References and Further Reading:

  1. Five Eyes launch Secure Innovation to protect tech sector – Open Access Government
  2. Five Eyes launch shared advice for tech startups – National Cyber Security Centre
  3. Five Eye collaboration at DoDIIS Worldwide – Clearance Jobs
  4. Five Eyes Alliance Unveils Secure Innovation Guidance – ExecutiveGov
Scattered Spider Attacks: Tips for SaaS Security

Scattered Spider Attacks: Tips for SaaS Security

By | | Comments 0 Comment

As cloud adoption soars, threat groups like LUCR-3 Scattered Spider and Oktapus are mastering new ways to exploit identity management systems(IAMs), making these attacks more frequent and harder to detect. By targeting cloud environments and leveraging human vulnerabilities, LUCR-3 compromises identity providers (IDPs) and uses sophisticated techniques to breach organizations.

Before we begin, I wanted to present a random sampling of the successful attacks carried over by the LUCR-3 aka Scattered Spider.

Company/ProductDate AttackedCompromised SystemProjected LossMitigation Time
Telecom Company (Unnamed)December 2022Mobile Carrier Network, IDP SystemsEstimated millions in damagesSeveral weeks (ongoing)​CrowdStrike
Octa (Roasted Oktapus)March 2022Identity Provider (Okta) and SaaSPotential damage to ~366 companies4-5 weeks​Hero​Wikipedia
British TelecommunicationsJune 2022Mobile Carrier Systems, BPO NetworksMillions in lost revenue3-4 weeks​CrowdStrike​Hero
Gaming Company (Unnamed)September 2022Cloud Infrastructure (SaaS and IaaS)Losses in IP theft (unconfirmed)~2 weeks​ISPM ITDR
Cloud Hosting ProviderNovember 2022AWS, Azure Environments, IAM SystemsIP theft and reputational damage3 weeks​CrowdStrike
MGM ResortsSeptember 2023Corporate systems, Help Desk, and IDPMillions in lost revenueSystems offline for weeks​Wikipedia
Caesars EntertainmentSeptember 2023Identity Providers (IDP) and SaaS~$30 million ransom paid​ Wikipedia~1 month recovery​Cyber Defense Magazine
Charter CommunicationsApril 2024Cloud-based systems (Okta phishing)Potentially millions in damages​ ResilienceSeveral weeks
NHS Hospitals (UK)June 2024VMware ESXi servers, critical healthcare systemsDisruption of hundreds of operations​BleepingComputerOngoing​BleepingComputer
Synnovis Pathology ServicesJune 2024Ransomware on pathology services systemsEstimated millions in healthcare disruptions​BleepingComputerOngoing investigation​BleepingComputer
This table provides a detailed overview of Scattered Spider’s recent attacks across industries, demonstrating their evolving tactics and widespread impact.

This article outlines the technical steps LUCR-3 typically follows, from initial access to persistence and lateral movement within cloud environments, mostly targeting SaaS platforms.

Step 1: Initial Access Through Identity Compromise

LUCR-3 starts with a core weakness in modern security—identity management. Their main attack vectors include:

  1. SIM Swapping: LUCR-3 hijacks a user’s phone number by tricking the telecom provider into assigning the number to a new SIM card. Once they have control over the phone number, they can intercept One-Time Passwords (OTP) sent via SMS.
  2. MFA Fatigue: The attackers flood the target with repeated MFA prompts, often overwhelming them into approving a malicious login request.
  3. Phishing and Social Engineering: They set up fake login pages for SaaS applications (e.g., SharePoint or OneDrive), capturing legitimate credentials and OTP codes.

These techniques allow LUCR-3 to bypass standard Multi-Factor Authentication (MFA) protections and gain access to cloud environments​

ISPM ITDR, Hero.

Step 2: Bypassing MFA and Establishing a Foothold

Once inside, LUCR-3 focuses on maintaining access to the compromised identity. This is done by modifying the victim’s MFA settings. Their tactics include:

  • Registering New Devices: LUCR-3 will register their own devices (phones or emails) under the victim’s account, which ensures they can log in without triggering alerts. For example, they might register an iPhone if the victim previously used Android, raising minimal suspicion.
  • Adding Alternate MFA Methods: They add backup MFA methods, such as an external email address, making it even harder to lock them out if the breach is discovered​ISPM ITDR.

Step 3: Reconnaissance and Data Collection in SaaS Environments

After gaining access to cloud platforms, LUCR-3 conducts extensive reconnaissance to identify critical assets, credentials, and sensitive information. Here’s how they do it:

  1. SaaS Platforms: They use native tools within platforms like SharePoint, OneDrive, and Salesforce to search for documents containing passwords, intellectual property, or financial data. They operate like legitimate users to avoid detection.
  2. AWS Cloud: In AWS environments, LUCR-3 navigates the AWS Management Console, targeting services like EC2 (Elastic Compute Cloud) and S3 (Simple Storage Service). They leverage the AWS-GatherSoftwareInventory job through Systems Manager (SSM) to list running software across EC2 instances​ ISPM ITDR.
  3. Privilege Escalation: LUCR-3 may modify IAM roles or escalate privileges by updating LoginProfiles or creating new access keys, ensuring they have continued administrative access​Hero.

Step 4: Lateral Movement and Persistence

LUCR-3 ensures they have multiple ways to re-enter a compromised environment, even if one of their entry points is discovered. Here’s how they achieve persistence:

  1. Create New IAM Users: LUCR-3 creates new user accounts that align with the naming conventions of the compromised environment to avoid suspicion. These accounts often have high-level access, allowing them to continue accessing the environment even after the initial breach is patched.
  2. Secrets Harvesting: Using tools like S3 Browser, LUCR-3 harvests credentials stored in AWS Secrets Manager and similar services, allowing them to steal sensitive data and further penetrate systems​ Hero.
  3. MFA Manipulation: They alter MFA settings to ensure continued access, often registering additional email addresses or devices that align with the compromised identity.

Step 5: Data Exfiltration and Extortion

Once LUCR-3 has gained the necessary access and gathered sensitive data, they execute their final stage of the attack, which often involves extortion. The data collected during their reconnaissance, such as customer information or proprietary code, is used as leverage to demand payment from the compromised organization​ The Hacker News​ ISPM ITDR.

How to Detect and Prevent LUCR-3 Attacks

Given LUCR-3’s sophisticated techniques, organizations must adopt advanced security measures to detect and mitigate such attacks:

  • Monitor MFA Changes: Keep a close watch for unusual changes in MFA settings, such as new device registrations or changes from app-based authentication to SMS-based methods.
  • Audit Cloud Logs: Regularly audit cloud environments, especially IAM policy changes, new access key creation, and suspicious activity in management consoles.
  • Behavioral Anomaly Detection: Implement advanced behavioral monitoring to detect when legitimate accounts are being used in unusual ways, such as accessing unfamiliar services or using unfamiliar devices.

Conclusion

LUCR-3 (Scattered Spider) represents a new breed of cyber threat actors that rely on identity compromise rather than malware or brute force. By targeting the very foundation of security—identity—they can infiltrate cloud environments, move laterally, and exfiltrate data with relative ease. As organizations increasingly rely on cloud services, strengthening identity management, closely monitoring for anomalies, and responding quickly to suspicious behavior are critical defenses against such attacks.

References and Further Reading

  1. The Hacker News: Provides a detailed breakdown of LUCR-3’s identity-based attacks across cloud environments, lateral movement techniques, and persistence strategies.
  2. Permiso.io: Discusses how LUCR-3 targets identity infrastructure, modifies MFA settings, and maintains persistence in cloud environments like AWS and Azure.
  3. CrowdStrike: Offers insights into Scattered Spider’s use of the Bring-Your-Own-Vulnerable-Driver (BYOVD) technique and their focus on telecom and BPO sectors.
  4. Resilience Cyber Research: Highlights recent phishing campaigns by LUCR-3 in 2024, targeting industries such as telecom, food services, and tech, using Okta-based phishing tactics.
  5. EclecticIQ: Discusses LUCR-3’s involvement in ransomware attacks targeting cloud infrastructures within the insurance and financial sectors, leveraging smishing and phishing techniques.
  6. Wikipedia (Scattered Spider): Overview of the MGM Resorts hack in 2023, detailing how Scattered Spider gained access to internal systems through social engineering and caused significant disruptions.
  7. Cyber Defense Magazine: Discusses how LUCR-3 has highlighted vulnerabilities in MFA and cloud security, predicting more targeted attacks on SaaS and cloud service providers.
  8. BleepingComputer: Provides an overview of LUCR-3’s collaboration with ransomware groups like Qilin, targeting high-profile companies such as MGM Resorts and healthcare services.
  9. Caesars and MGM Hacking Incident: Outlines how Caesars Entertainment suffered a breach in September 2023, paying a ~$30 million ransom, while MGM Resorts experienced extensive downtime following a similar attack.
  10. Microsoft and Qilin Ransomware: Microsoft linked Scattered Spider to ransomware attacks using the Qilin variant, affecting companies like Synnovis Pathology and NHS hospitals in 2024. Read more​ BleepingComputer​ Wikipedia

These resources offer in-depth insights into the attack strategies and defence mechanisms relevant to LUCR-3 (Scattered Spider), perfect for anyone looking to deepen their understanding of identity-based attacks and cloud security.

Bitnami