𝛑
𝛑
Posts List
  1. 0x01 Preface
  2. 0x02 Main Content
    1. 1. Establish Processes and Standards
    2. 2. Deliver Capabilities Through Platforms
    3. 3. My Vision of a Modern SDLC Platform
  3. 0x03 Summary

Modern SDLC and Security Architecture Review

Oct 23, 2022 Felix Zhao 中文 2k words ~12 min read

0x01 Preface

Today let’s talk about my vision for Modern SDLC & Security Architect Review. I first started doing architecture reviews (or maybe just participating) about once a month - total newbie stage, not much substance to it, though I did start participating in building and maintaining SDLChina at the time. Later when I was doing architecture reviews at Local Life, the workload really ramped up. We’d have two afternoons every week dedicated to review meetings, with lots of new services launching. That’s when I gradually got exposed to all kinds of architectures. The architecture review process back then already had a complete workflow established, focusing on system and application levels, mainly involving the tech team. My own work was primarily optimizing the process - things like building case libraries, having business teams prepare required documents, checklists, etc. I even summarized it in an article. As for PayPal, I didn’t actually participate that much until the colleague responsible for application security left and I temporarily stepped up to handle some reviews. The reviews at that point were quite different from before, especially in terms of attendees. Beyond the tech team, there would be compliance, legal, business, project managers, etc. Also worth mentioning - the review results had a tracking process to see if issues got resolved, with complete platform support. Of course, for most companies, forget about SDLC and architecture review platforms - they don’t even have an SDLC. Small companies might do fewer architecture reviews in a year than a big company does in a month, yet architecture reviews have become a routine operational part of an architect’s daily work. Side complaint: some companies recruit people claiming they need 5+ years of architecture review experience, and some engineers dare to claim they’re proficient in SDLC just because they maintain code scanning rules. This industry has too many people talking big game but too few with actual technical skills. And basically all the architecture reviews I mentioned were on the business side. I participated less in reviews for systems supporting the business. That’s one of the reasons I’m writing this article. Alright, today’s preface is getting a bit long - let me ramble about how to build modern SDLC and architecture reviews.

0x02 Main Content

Before talking about modern SDLC, let me briefly explain why SDLC looks the way it does now. I made a diagram for this.

sdlc01

Looking at the diagram, after an application goes through R&D and deployment, the initial protection provided to the system is at runtime. The security capability at this stage typically includes firewalls, WAF, anti-DDoS, etc. - what’s called Border Security. But border defense obviously means once the barrier is breached, there’s no protection inside. So what if we shift the Security Capability left (Shift To Left; side note on shifting right - generally refers to testing preferring to do fault injection in real environments)? By covering the entire R&D with security capabilities and providing security outputs at each stage, we move from Border Security to Defense in Depth (though this is just Defense in Depth from an application perspective).

Now we roughly understand why we have this current approach. But since we’re talking about modern SDLC and architecture review, I need to make three assumptions first:

  • Assume the company has certain project processes and product/R&D standards. This means the company has foundational capabilities like project management, development workflows, etc. For example, managing projects through Jira, creating tickets for new features, and associating them with corresponding code branches.
  • Assume the company has some DevOps foundation, like automated deployment, all services connected to CI/CD pipelines, separated environment configs, etc. Even better if there’s some IAC - generating resources through code means you can not only detect after generation using CSPM-type tools but also follow default templates and hardening rules when creating resources to achieve some Security Default. This is one manifestation of security capabilities sinking into infrastructure.
  • Assume the company’s security capabilities are already ready. If basic security capabilities aren’t even in place, building an SDLC is obviously premature. For example, tools like IAST, DAST, app hardening, image scanning, etc. are all functioning properly, with teams managing the corresponding tools, rules being maintained, etc.

OK, assuming our assumptions are met. Let’s see how to build a modern SDLC. Focus on these points:

  1. Establish processes and standards
  2. Deliver capabilities through platforms
  3. What I think a Modern SDLC platform should look like

1. Establish Processes and Standards

In architecture reviews, have you ever been asked: “Where does this requirement come from?”, “Where can I reference this point?”, and similar questions? For security work, the best basis comes from Approved Policy. These documents need to be placed in a unified Portal, distinguished from Draft versions. They also need to be promoted to colleagues across departments through briefings, then revised on an annual or semi-annual update basis. Of course, some companies might have dedicated teams writing various policies, but generally it’s more common for frontline senior experts to write them, then go through approval at different levels. SOPs generally don’t need to follow this process. Beyond that, you need to work with different departments to establish different standards. For example, working with ops to establish standards so newly created resources have default security capabilities - this is another manifestation of security capabilities sinking into infrastructure. Only by backing things up through processes and standards can security capabilities be output more effectively. For example, if policies specify how to handle certain non-compliant scenarios, you can choose not to do it, but then go get special approval. But special approval only provides a buffer period - after the buffer you still have to complete it. It’s not me challenging you, it’s the rules challenging you.

2. Deliver Capabilities Through Platforms

Platformization reduces repetitive workload to some degree. Though it often brings another form of workload. The most common form of delivering capabilities in SDLC is defaulting security scans in pipelines. That’s what we commonly call DevSecOps platforms - through DevSecOps platforms, services from security tools are integrated at each stage for applications, and by aggregating results from different security tools, they’re displayed and analyzed along with some operational metrics. Business teams can also self-service on the platform. It’s not that I won’t let you deploy - the platform won’t allow you to deploy without passing checks.

3. My Vision of a Modern SDLC Platform

The last paragraph talked about delivering capabilities through platforms, mentioning DevSecOps platforms focusing on the period after Architect Design and before Runtime. After Runtime there’s usually not much major change - often built-in traffic scrubbing capabilities to detect and block abnormal traffic plus bot verification, etc. So what’s left in SDLC is architecture design and review - specifically how to deliver capabilities through platformization.

SPLC

Spent an afternoon drawing this diagram, let me walk through it. The box in the middle represents requirements for a Modern SDLC platform, mainly divided into two parts: Security Capability and Enhancement.

  • Design & Architecture can visualize existing system architectures, draw and standardize networks, databases, server/runtime locations, along with dependencies of corresponding components and data flow directions. Then for data level, direction in the data flow, Threat Modeling can quickly determine if it’s compliant. For example, discovering sensitive data flowing out unencrypted and highlighting it.
  • Threat Modeling needs to support some existing analysis models, like Attack Tree, STRIDE, etc. Through analyzing data and components in Architecture, combined with scenario libraries, it gives some basic risk points. By manually defining scenario libraries or just keeping some basic risk self-check points for users to do, leaving the rest for security experts to implement. One complaint here - domestic platforms mostly love to hype this as a selling point, but actually just have two scenarios for banks and e-commerce, then require checking 20+ checkboxes to complete, finally taking an auto-generated document to align with business teams. How stupid can it get.
  • Risk Management needs to assess severity for discovered issues, affected assets, determine the degree to which existing problems or risk points might be exploited, along with corresponding mitigation plans. And through data analysis modules give a score - when the score is below a certain value, reject that project from entering the next process. For example, can’t request permission for online resources without passing. Also for discovered issues, establish a tracking process where each process must conclude - whether pass or fail.
  • Scenario & Knowledge needs to focus on several aspects: Application & API (like different languages, common frameworks, common coding issues and corresponding detection rules, etc.), Compliance (like GDPR, PCI-DSS, China Cybersecurity Law, SOC2, etc.), industry standards (like OWASP top10, OWASP ASVS, NIST xxx, CWE, CIS Benchmark, etc.), system deployment (like cloud best practices, web servers, containers, databases, microservice authentication, etc.). Another complaint - knowledge bases are actually a selling point and gimmick for domestic SDLC products, but so-called cases from 20-year senior consulting experts won’t be that well-aligned with the actual situation inside companies.
  • Security Training needs to provide small examples for common coding-related issues to developers, ideally with scoring feedback - if they don’t pass training or score low they need to keep learning.
  • System Integration is the most important part to focus on because platforms in companies are all over the place. SDLC platforms have limited audiences, and many functions can actually be achieved through integration. For example, by integrating with Jira, complete risk management tracking - users can handle risk point cases created by security experts either in Jira or on the SDLC platform. Of course not just risk process management - architecture review process management can also be done in Jira. At this point changes on either side sync to both platforms. Similarly, through integration with DevSecOps platforms, observe security metrics at different stages of a project after architecture review. Through integration with internal training platforms, put training design on the training platform and reference training content into the platform. This kind of system integration isn’t just on SDLC platforms - companies also need integration between platforms to increase system extensibility. Or more accurately, increase data flow.

Many times a company hasn’t done much SDLC, and the portion that does SDLC doesn’t have platforms - more effort goes into doing SDLC on DevSecOps platforms. It’s like testing can detect code quality better but can’t detect architecture quality. A modern SDLC platform doing architecture reviews is very necessary - you can’t just manually record cases, manually manage risk items, and use unpublished checklists to do architecture reviews. Instead, publish policies to support process constraints, deliver architecture review capabilities through platforms, plus focus on process implementation, management, issue tracking, system integration, etc. Shift to Left as much as possible, along with Security By Default.

0x03 Summary

Recently I’ve become more fond of taking a holistic view to look at things from a high level. Though I used to often draw diagrams to explain aspects of things, most were designs constituting a system, but now it’s more about combinations of solutions between systems. Of course the details inside a big diagram are definitely very numerous - can’t be explained in a few words in one blog post. Similarly, I wrote about some focus points in the blog but often didn’t explain why to focus on these points.

Now whenever I think of something, certain points, I’ll quickly jot them down in notes. Because many viewpoints, once triggered, that burst of inspiration only lasts a little while. Inspiration bursts come from continuous diligent exploration, but inspiration seems a bit more important than the prior diligence. Here I pay respect to my boss - he taught me many things and gave me quite a bit of inspiration. Like treating a junior, taught me many principles. Thank you.

Alright, rambled on about all this, the end.