While reading this enumeration of EDA software patterns I had to think of the need for available Cyber reference architectures (RAs) and minimum security baselines (MSBs) to complement misuse test cases, especially for logic.
With cloud-native and FaaS gaining ground, as well as no/low code, Cyber will need to collaborate even closer with QA to determine any confidentiality, integrity &/or availability (CIA) issues.
I'll always remember looking at a 4GL (fourth generation language) telecom app in late 2012 at an insurance company. It was used to route, via prompts, the caller to the right service desk.
So, I embarked on an informal security assessment/threat model by handwriting on my notepad "sources | sinks" then enumerating my perceived/observed of each. After that we walked through the business logic, error/exception handling & misuse cases. It was not the most thorough affair, but it was a value-add to the Cyber folks.
As the industry embraces more no/low code solutions (Power Apps, Honeycode, AppSheet) it behooves Cyber professionals to use a methodology to assess these solutions. Here's a take on such a methodology that I'll pronounce DASL:
D for Data: classification/sensitivity/compliance requirements/retention
A for Application: underlying platform (Cloud Service Provider: CSP) & security/risk/SRE/DR posture
S for Sources/Sinks: ecosystem/supply chain
L for Logic: ruleset, QA testing, misuse cases
While orgs want to deploy a finished product immediately, that isn't practical. From a Cyber, as well as Ops perspective, it's better to incrementally develop & deploy a solution.
Edison didn't succeed overnight; so, why should enterprises....
Continuous integration / delivery / deployment / verification (CI/CD/CV) all need to be segmented in org's processes.
While this may be more difficult for on-premise deployments (Jenkins / Bamboo), most cloud PaaS offerings make this easier, especially AWS with their Code* portfolio (CodePipeline / CodeBuild / CodeDeploy).
https://techbeacon.com/enterprise-it/7-container-design-patterns-you-need-know
When performing a threat model for cloud-native environments I advocate for a comparison to the design patterns articulated above, especially how security-centric services are deployed. To execute on segregation of duties one must abide by said best practices.
https://kubernetes.io/docs/concepts/security/overview/
The 4C's described above do not explicitly include securing the data. Orgs need to secure their data (crytpo, masking) before it goes to the cloud, onsite, or otherwise...
