I am a fan and advocate of "left-shifting" practices earlier in any process. However, in a Software Development Lifecycle (SDLC) or Security Development Lifecycle (SDL), shifting security and privacy practices left (earlier) into the NIST cyber-framework Identify, Protect, and Detect phases from the later Respond and Recover phases has big benefits. A left-shift is toward proactive and away from reactive, allowing issues to be identified, tracked, and fixed (or mitigated) sooner, which reduces frustration and "cost" (time, money, opportunity, brand, reputation, etc.).
Left-shifting benefits are not exclusive to software development or security (and privacy), but they are significant in these areas. The loaded cost of architecture, design, and security issues increases over time, which can be a shock when it goes from linear to exponential. Something that is straightforward or easier to fix early in the SDLC may not be later — do not underestimate the user, partner, revenue, deployment complexity, and legacy implications. A security incident or breach can have costs and cause other damages on a corporate scale that can negatively affect the viability of a business.
Shifting your existing security and privacy practices earlier in your processes yields solid value (see Static versus Dynamic post). But improving those practices and adding some new ones in those earlier phases can also provide value. Organizational alignment (see Ops post) is best done before any commitments, but I also recommend planning end-to-end (e2e) at the same time. This includes software or service scaling and maintenance in the short-term, dovetailing into your road map in the long-term, and eventual replacement or sun-setting of the offering. Here is a short-list of left-shift opportunities:
Fundamentals and baseline: Offer security and privacy training for developers and other staff providing the fundamentals they need to understand and meet the expectations of the organization, the business, and the users/clients. This can include advanced training or certification for those that need or want it. Use gamification or "belting" approaches to make this more compelling and recognize individual or team accomplishments.
Requirements: Identify and track all security and privacy requirements. Some of these will be obvious and some you may need to tease out. All requirements and imperatives should be stored in a tracking system with checkpoints throughout the SDLC. Making security and privacy requirements visible and traceable will have many benefits and reduce risks.
Threat modeling: First, draft as part of the feasibility and architecture milestones before any coding. This helps expose disconnects in capabilities or investments and works as a forcing function to align development, operations, support, and services teams. Second, draft as part of the design phase, then as implementation decisions are made include trust boundaries, perimeters, endpoints and integrations, stores, etc. From this point, keep the model updated reanalyzing when architecture, design, or configuration changes — vulnerabilities can be created or surfaced in these events (e.g., a component is moved from a private cloud to public cloud, or a data store is restructured for tenant separations).
Static analysis: Implement when coding starts on your integrated repositories and builds — shifting into sandbox repositories or individual developer environments will add extra value. The closer you can get to "continuous" (where results are presented near the actual coding and check-in) the better. If a check-in gets flagged with an issue at the weekly integration, the context may be cold and stale for the developer. Again, we recommend leaning to dynamic analysis, but static analysis is still an important part of any SDL.
Dynamic analysis: There are many benefits in establishing and tuning DevOps or "continuous" (CI/CD) practices. Implementing a mix of automated and manual dynamic or run-time testing, including offensive testing (a subset of penetration testing), will have high value. This isn't as easy or natural as some of the earlier points but has explicit value and acts as an implicit forcing function for organization and practice alignment. There are big benefits in surfacing run-time deployment/delivery, configuration, performance, or security issues early in your SDLC. Plus, reducing the findings of 3rd parties (e.g., penetration testers, auditors, or customers) will save you time and money on those engagements and remediation efforts, and improve your brand and quality perception in the marketplace.
There will still be situations when practices just can't be done earlier or there isn't the proper value/ROI in left-shifting, and that will depend on your business and its security maturity. Most businesses remain "incident driven" in their security and privacy investments — a business must always be somewhat reactive and prepared to Detect, Respond, and Recover. I don't expect this reactive tendency to improve much in the short-term, but don't lament it or diminish the incident opportunity. Investing late is better than not investing at all — don't waste a crisis or put people off by overplaying "... told you so." Take advantage of these opportunities by building consensus, getting the investments, strengthening partnerships, and left-shifting where there is real value.
