alexsmolen

I've been using elhaz (https://github.com/61418/elhaz) to manage AWS creds locally, and also experimenting with sandboxed (e.g. dangerously-skip-permissions) agents using Docker. The nice thing is that you can use a single Unix socket to expose agent-specific creds rather than dealing with files or environment variables.

I'm working on TrailTool, which aggregates CloudTrail for analysis in both UI and AI contexts. I've always found it tough to tie together CloudTrail logs into meaningful narratives useful not only for security investigations but also "role engineering" (i.e. reducing privileges on human-operated IAM roles). The idea is to make this info available via MCP for agent workflows as well, so you can get high quality, low latency, manageable context size CloudTrail data.

If you want to kick the tires, you an deploy a CloudFormation stack to a Sandbox AWS account - see https://trailtool.io/install.html

In my research I haven’t come across the prior art you suggest exists. The trust centers you linked aren’t fungible with what I’m building with GraphGRC. The idea is to make all your security docs just a GitHub repo with structured markdown that permits useful automation (e.g. generating linked internal site, validating all docs have been “reviewed” annually by checking metadata, change control via PR, etc.)

There are plenty of GRC products out there and are popular for good reasons, but I don’t think any of them are Git/Markdown/developer-first.

I love this idea despite the real world operational challenges - most people with governance responsibilities in organizations don't want to code, and code is often too precise to model messy social/organizational context without constant tweaking, tending, and exception management.

I'm an advocate for bringing software culture to GRC, or as it's sometimes called “GRC Engineering”. While there are plenty of products to automate evidence generation for auditors, the underlying policies and documents that they prescribe are usually still old-school Word/PDF-style boilerplate junk.

I'm working on an open source project for security policies/processes/standards that map back to underlying frameworks (e.g. SOC 2, GDPR, ISO 27001, etc.) Docs are Markdown with YAML frontmatter metadata, interlinks generated automatically, site is published via GitHub actions.

The code is at https://github.com/engseclabs/graphgrc, and you can see an example published site here https://graphgrc.engseclabs.com.

Would love to know if others find it useful or have built similar systems.

This is a pretty good article about preventing SSRF including DNS rebinding-based attacks in Go https://www.agwa.name/blog/post/preventing_server_side_reque...

Kind of wild that there's no mention of SSRF. A quick search shows it's a pretty frequent security issue in Webhooks: https://www.google.com/search?q=ssrf+webhook

This is what https://tosback.org/ does, I believe.

Yeah, I think it’s tricky to figure out how to place it somewhere that attackers would look but AWS tooling wouldn’t, by default, since otherwise they may be used in legitimate operation.

I recently helped build a secret store system for our infrastructure, and we decided to not use Vault.

A big reason was that Vault’s AWS authentication backend is not based on AWS infrastructure like IAM/KMS, but uses a somewhat backhanded method (https://www.vaultproject.io/docs/auth/aws-ec2.html) to establish verify an EC2 instance. We use ECS, and it doesn't play well with it - see https://github.com/hashicorp/vault/issues/1298

Instead, we would have had to fall back to the App ID method, which requires separate configuration, and is “Trust On First Use” so doesn’t offer as strong of security guarantees in my opinion.

Also, the only Hashicorp supported-backends are file (non-HA) and Consul.

If you're all-AWS, I'd recommend checking out Confidant/Knox (run as a separate service) or Credstash/Biscuit (run directly against AWS infra).

The problem is that SMS provides better recovery rates than TOTP/HOTP + backup codes, because people can go to their carrier and get a new device at the same number.

It's important to remember that availability is an important aspect of security. If you protect a user primarily concerned with mass-account takeover attacks from a low-probability threat (people intercepting their SMS channel) but introduce a high-probability threat (dropping their phone in the toilet and being locked out of their account forever) you may not have made a good security tradeoff.

I built an open-source Rails engine for something like this: https://nopassword.alexsmolen.com.

Does anyone think JWT should replace cookies for session management in non-single page apps? I'm guessing you'd have to include an AJAX call to determine if you're logged in on each page, which seems kind of odd to me.

This is interesting and well-informed, but it's important to remember that fraud is an adversarial problem. The bad guys will change their behavior to evade detection. The habits described here may exist when there is no defense in place, but if you use them to detect fraud, you'll likely see shifts in behavior to appear more "normal" and evade detection.

Shameless plug - I wrote a Rails engine for this type of authentication mechanism called NoPassword - see https://github.com/alsmola/nopassword

I built and open-sourced something like this a while ago: http://nopassword.alexsmolen.com

HN thread here: https://news.ycombinator.com/item?id=4570600

It's a great concept, but like any new authentication mechanism there's a usability and security cost due to the lack of familiarity.

Plenty of authentication mechanisms are "better" than passwords, but passwords are well-understood and flexible, which is a huge advantage for almost all sites.

I built a Rails engine that does this, see https://github.com/alsmola/nopassword and https://nopassword.alexsmolen.com

I built NoPassword (https://nopassword.alexsmolen.com/), an open source Rails implementation of this design. It was on the front page of Hacker News a few months ago. I use it on another site I'm working on, Agave Society (http://www.agavesociety.org).

The links are one-time only, and they expire.

From my blog post:

"Yes, logging in by waiting for an email and clicking a link does take longer than entering a password. But you should only have to do this once per device. Unless you’re constantly letting other people use your computers (and logging out of your email client each time), you’re golden."

http://alexsmolen.com/blog/?p=194

Most people have their email open, not only on their desktop but also on their mobile devices. Most importantly, you'd only do this once per device, unless you need to log out or clear your cookies.

If you lose you email account password, you'd need to follow the email service provider recovery process. Gmail, Hotmail, etc. have significant resources dedicated to helping people with this.

A link to a recognized email provider would be a nice touch, thanks.