RASP or No RASP

Many orgs these days, especially regulated one's (and most are regulated), use some type of (dynamic) application security scanning tool (DAST: Qualys, Acunetix, WhiteHat) for Web application security.

With that said, fewer use edge protection solutions (e.g., WAF, DDoS) to "Band-Aid" findings, and fewer use static analyzers (SAST: CheckMarx, HPE Fortify, IBM AppScan) to find problems before they go to QA or into production.

So, a while back firms like Prevoty & HPE (& others now, like Immunio) have launched runtime application self-protection (RASP) solutions to further protect Java & .NET applications.  But what about Perl, Python, MEAN, LAMP, etc.? 

That's where an argument against RASP comes in.  At the end of the day, a solid secure development lifecycle (SDL), and existing investments should help negate the need for RASP.  Though, many orgs struggle to fix legacy bugs, let alone to fix w/in an acceptable remediation window.

Therefor, RASP, or no RASP, solely depends on the technology stack & time to remediate.

Loss Expectancy & InfoSec Metrics

So when looking to make single / annual loss expectancy (SLE / ALE) as subjective as possible it helps to have some metrics (i.e., KPIs / KRIs).

While vulnerability scanning / DAST / SAST / pen test findings can help, the best examples are from either honeypots or via red team exercises, to include: social engineering, phishing, whaling, and / or compromised digital assets.

Such metrics will help with the providing the (estimated) annual rate of occurrence (ARO) needed to determine the SLE * ARO = ALE.

Finally, while subjective, annual net sales / days of expected outage always helps w/ determining the SLE for ERP / EMR / EHR / ICS / CRM / SFA systems.