This is the 2nd post in our 2019 National CyberSecurity Awareness Month series.
Throughout my career, whether working in legal and compliance or development (R&D), I have heard “Don’t just tell us what is broken (or not secure), but also tell us how to fix it or avoid it from the start.” This is very valid feedback, but usually given late in a product cycle and from a defensive position. Most security teams (infrastructure, applications, or operations) have been given this feedback at one time or another. It can be frustrating (especially when you have made the Left-Shifting efforts), but still is valid feedback that shouldn’t be discounted or put you on the defensive. When both sides of this necessary collaboration are on the defensive, debt increases and security investment value decreases.
The biggest problem in this context is the lateness of the engagement. When an issue is found during integration, regression, or offensive/penetration testing (i.e. late), the option left is mitigation via defense-in-depth or compensating controls since the “fix” ship sailed much earlier during the architecture, design, and coding phases. “Bolt-on” versus “baked-in” security and privacy implementations can put the best R&D and security teams in difficult and uncomfortable situations. Granted, things move very fast in security and privacy, so the issue may be due to a new vulnerability or attack, or derivation of an old one. [A big reason Cylidify advocates for security and privacy “agility” especially in encryption (whether data is at rest or in transit), authentication, and session management.] However, it is likely due to something that was just missed or skipped earlier in the product life-cycle, such as specific security or privacy requirement, or a trade-off was made in favor of delivering a feature or capability. Either of these are difficult to avoid but especially when there is limited early stage engagement or some unification efforts such as DevOps/DevSecOps. The simple fact is that any issue is easier and less costly to address earlier in a product cycle, but it's exponential with security and privacy. There are very few issues for which there isn’t “baked-in”, off-the-shelf code or components or best practices which provide agile security and privacy implementations for a given scenario. However, these are difficult or impossible to leverage late stage.
The best way to prevent these sort of late stage issues (and strife within a product team) is to get all the constituents involved as early as possible: development, security/privacy, operations, support, services, etc. If there are sponsorship, process, or resource problems preventing this, get that solved ASAP by creating visibility and making management/executives aware and accountable. Then, follow your process with emphasis on the following:
Create and track requirements that call out security and privacy specifically — with product team commitments to implement or backlog
Identify and track risks through Threat Modeling and static analysis techniques (SCA, SAST, etc.) starting in the architecture and design phases
Meet regularly to prioritize work and create visibility/accountability for any trade-offs. This is primarily the R&D and security teams, but management must have visibility and awareness throughout. [Do NOT get set up as the “fall guy” with implied or fuzzy goals! If management is pushing for a delivery with trade-offs including security or privacy risks, there must be awareness and direct accountability established; otherwise there will be finger pointing later and the product’s security and privacy debt will continue to grow.]
Please see previous Cylidify posts on Left-Shifting, Static:Dynamic Venn, or Cybersecurity Constituents for more information. We are available to assist tactically via baseline assessments, guidance and planning, Threat Modeling, or specific issue remediation, or more strategically via processes, implementations, or training and team building.
