Information Security Primer

What is the primary goal of InfoSec?

To ensure all changes at context boundaries are well-regulated.

For example, every system call on a UNIX platform satisfies this condition, in terms of the UNIX user/group process+filesystem security model. The literal definition of a context switch, as typified by system calls, involves API-usage sanity checking on the kernel’s side of the call.

In terms of SaaS delivery, all data originating from a runtime UNIX system call should be treated as tainted, and validated at the ingress points into the application’s accessible process memory. These ingress points should be considered infosec context boundaries for such application data. The appropriate regulatory validation should whitelist string patterns (via regex typically); tainted data clearing the whitelist, and its dependent data, may be safely shipped outbound from the application’s process memory via another system call. Those system call egress points are also infosec context boundaries; what constitutes “safe” whitelist patterns on the ingress tainted data are informed by these specific APIs on the egress points. Over the SSDLC, these egress points will evolve, as should the corresponding whitelists.

The UNIX security model alone never made provisions for networked client/server application development, because historically the BSD socket API that predated the rise of Network Computing in the 90s (Sun Microsystems) was invented over a decade after UNIX was born (with its OS-based multiuser security model fully formed at birth). MIT Kerberos was a step in the right direction, but leaves much to be desired in a SaaS context.

Securely scheduling CPUs to perform kernel-level work on behalf of some “authorized user/group/role context” untethered to the underlying process’s UNIX user/group context has always been outside of the UNIX model. Many infosec initiatives fail to recognize this regulatory responsibility belongs to applications alone; don’t let yours be one!

In case it’s not clear at this point, DevOps/SRE teams triaging SaaS security (CAI) incidents on Linux should familiarize themselves with htop‘s strace interface via the s key! Better still to master strace as a stand-alone. (FYI: I have static compiles of these binaries on github that can be delivered to K8s containers or nodes, including via SSH/SSM delivery, at https://github.com/joesuf4/home/tree/wsl/bin).

How does this relate to Zero-Trust initiatives, as a practical matter?

Zero-Trust Architectures have no network-specific infosec context boundaries.

While there may be VPN/Firewall contexts in reality, none of those details are relevant to InfoSec within a Zero-Trust framework. In other words, such network topology security initiatives may augment Zero-Trust initiatives, but they are never relied on within a Zero-Trust initiative at the base server-host security level on up through the application level.

MIT Kerberos and Active Directory are Zero-Trust compliant, for example.

$Date: 2023-01-19 17:58:40 -0500 (Thu, 19 Jan 2023) $