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      

Layer-7 Logging

PPT on Layer-7 Logging

Native Versus Generic Security Baselines for Cloud

For a while now specific providers (Security Scorecard, BitSight) have provided security benchmarking for a client's ecosystem / vendors.

While that is great, these algorithms have been generic in nature versus taking cloud security nuances (i.e., AWS S3 utilization) into consideration.

To fill that gap, cloud service providers (CSPs) have now added their own benchmarks (e.g., AWS Trusted Advisor, Azure Secure Score) that will baseline a specific account versus the entire cloud ecosystem.

One would think that partnerships, maybe in conjunction with the Cloud Security Alliance's (CSA) Security, Trust & Assurance Registry (STAR) program, would allow cloud consumers to provide a holistic view of one's security maturity.