Assessing/Threat Modeling No/Low Code Applications

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      

Ransomware Response: A Service Continuity Challenge

While many security solutions (e.g., CASB, ATP, MTD, DMARC/SPF, EDR) look to catch malware / ransomware threats before they are experienced, isn't the response to a ransomware incident a service continuity challenge?

 With proper RPO terms, as well as tested BCP/DR procedures, ransomware response should be relatively painless.  The real concern is your ecosystem, as many third parties wont have the same governance regarding BCP/DR as a large enterprise.