I’m a huge proponent of believing that security shouldn’t be something that’s baked in after the fact – it’s something that should be all or nothing from day one. I realize that this is probably a wild and opinionated point of view, but, let me try to explain:

When your application starts out, user account security is usually one of the things that you think of last unless you’re utilizing a framework that has some type of tenant segregation in from day one. While security is usually brought into the product at some point after the core functionality of the MVP is introduced, this is the point in the development lifecycle that can really make or break your application: make the right choice: a library that is well maintained, well documented, and well-tested, and hope that it not only has the support of the community, but, pray that it doesn’t commercialize itself later down the road breaking your core functionality…or, roll your own. Rolling your own means ensuring that you’ve got a well-built set of definitions and goals for your authorization stack and that you’ve thought of everything your application needs from day one. Realizing that it’s a step in futility, most good engineers will try to add some things to your application to allow it to ‘future-proof’ the application, basically locking himself to be the ‘forever authz guy’ or worse, detrimental to your engineering team when that engineer leaves and all of that domain knowledge of the library or gem leaves after everyone on his team has left. (Oddly specific because I’ve lived through it. Twice). How do you solve for that? In my mind, that’s getting as close to the data as you can, and building forward from there. That’s where Soter comes in. Soter’s opinionated, secure by default, and easy to implement. Soter works on the belief that all data should be graded from the moment where it’s defined in the Model – if the model hasn’t been graded, then the data is unavailable to display to the user. Grading the data is mandatory, but, granting access is optional. You could have fields that could only be available to the application, prohibited by rules in being returned as a JSON or other object, keeping those fields secure by default.

…

I move back and forth between neovim and vscode frequently, depending on the day of the week, which way the wind is blowing, and a litany of other things including how I feel like my system is behaving, even if that is something that is completely subjective. I found myself struggling to really grasp the keystrokes required to manage my split panes, so, this post is 50% education for you, and 50% a reminder for me.

…

You can totally tell when I’m depressed if you’re watching closely.

Yes. For those who are wondering, I did hit 10k steps today.

Aspen decided that we needed to go for a long walk today. Halfway through the walk – after she had tried to chase after a fox, a skunk, and a goose – she decided that she had enough walking, and loafed on the ground.

…

A new study titled “Employees as Risks” - released today by the Vienna-based non-profit crackedlabs - explores software from Microsoft and formerly from Forcepoint – specifically SIEM (security information and event management) and UEBA (user and entity behavior analytics) applications. This study, part of an ongoing series of reports on the Surveillance and Digital Control at Work, examine the way in which expansive information gathering in the workplace turns employees into suspects. As the report points out, employee surveillance fosters mistrust, may be disproportionate, and comes with potential problems like false positives and inaccuracies.

…

There’s been a bit of stories about Snowflake recently; both from users who are recovering from the fact that Snowflake had no velocity limits on their wide open user data buckets, companies who are upset about their lack of meaningful MFA Controls, and then Snowflake reporting that they are now going to force MFA controls on all user accounts.

If I’m an administrator at a larger organization, and I’m adding applications to my organization’s SaaS footprint, the baseline is that SSO is a hard requirement. If your team doesn’t have the cash to spend for SSO on their product, then you better build and maintain your own solution, because you have a better chance of winning the lottery than me approving that purchase or allowing our internal or customer data outside of the network: I likely have a SAML implementation – be it EntraID, Okta, OneLogin, or something else – and I’m already enforcing MFA and trusted devices for all of our federation.

…