It's perfectly possible it's someone with deep domain experience, or someone who has product design or management skills. Regardless, dismissing these people out of pocket is not likely the best choice.
HN user
sullivanmatt
[ my public key: https://keybase.io/matthewsullivan; my proof: https://keybase.io/matthewsullivan/sigs/gBEOQiOcZp0tYlRkA7TpKwFads57SzYoG9OOxQbIlWE ]
https://mattslifebytes.com sullivan.matt@gmail.com
Staff Security Engineer at $EMPLOYER_NAME
I'm no longer living in Oregon but remain closely connected. I can't opine to the behavioral challenges, but in terms of the raw score drop I think there's also the one-two punch here of:
1) Schools were closed from Covid for a long time. Not here to debate whether that was good/bad/otherwise, but it is factually accurate to say Oregon schools remained remote longer than almost any others in the country, and we now know the duration of closure had pretty direct influence on learning outcomes.
2) In the past decade the Portland metro area has seen an influx of migration from economically disadvantaged families who are immigrants / first generation citizens / non-native English speakers in the home. Students from these families are lagging significantly behind their peers in terms of post-Covid recovery, which if I recall correctly, follows national trends as well.
You can tell when this deal started to come together by looking at the history of the website on Wayback Machine. In fall of 2024, the website had a checklist comparing SDF to dbt and claiming SDF had a better feature set than dbt Core (page rendering is hit and miss right now for whatever reason): https://web.archive.org/web/20240919110243/https://www.sdf.c...
In December 2024 the page had been updated to now compare "dbt Core" against "SDF with dbt": https://web.archive.org/web/20241217172451/https://www.sdf.c...
Little marketing switcharoo there to avoid pissing off their future owners.
My first employer is now a decently well known B2B SaaS and we didn't build user interfaces to manage various settings for a very long time. For example, we supported custom fonts, but we would have to jack into production to upload them and manually configure the database to make them available to a given customer. That ability didn't become customer-facing for a decade, simply because it was easier to file a ticket and make an SRE do it.
This is a little tangential but another good piece of advice is to avoid over optimization of the engineering stack. A giant monolith running on the largest RDS instance AWS provides a lot more runway than people realize.
In all of these advisories there has never once been a mention of cloud being vulnerable. I think it's safe to assume cloud runs a similar, if not identical, codebase, and that these issues are simply patched there first before vulnerability announcements are published. But that's the type of thing no company is ever going to be willing to say in public.
There must be a specific set of libs present on the victim (client), correct. Qualys claims that stock Ubuntu Desktop systems often have these libs, and that they haven't looked into whether other distros tend to.
But yes, your point stands. Huge number of preconditions here to fulfill.
This sounds way worse than it is.
To be clear, the "remote" part of the code execution is that an attacker controlling your destination server can cause your client to run an attacker-controlled payload, if the client is forwarding their credentials (`ssh -A`). Most people don't tend to make connections to arbitrary SSH hosts, and certainly they don't do it while forwarding their credentials along.
It's a neat attack, and I applaud the Qualys team on their find, but this is not any sort of emergency situation for 99.99% of systems.
If I were a user or integrator, how do I know that the de-identification step is actually working? Is there a way to test (and/or continue testing) your regex patterns or whatever mechanism used continues to accurately strip my sensitive information before it goes to OpenAI?
I'm not even a user of rhel but the difference is: security patches. Enterprise uses rhel because they fix or triage nearly every vuln, every time. If you work for a company with extremely stringent security requirements, or sell to government entities, rhel and its derivatives (CentOS/Amazon Linux 2, etc) are basically the only way you can clear their requirements.
Debian (and by extension, Ubuntu) chooses to not fix a significant amount of security issues. This makes sense given their business models, but is an unworkable position for a huge number of enterprises that depend on Linux. Example: https://ubuntu.com/security/CVE-2021-45464
I would recommend reading both Inspired and Empowered by Marty Cagan to help you think about your product journey. Very relevant to what you'll be building, and personally I found Empowered challenged me in ways that both made me uncomfortable and also better at my job as a Product Manager.
I built this with AWS Lambda. Relevant info if someone else wanted to try my approach to build such a service: https://mattslifebytes.com/2023/04/14/from-rebuilds-to-reloa...
My day job is security engineering, and I just keep encountering the same problem over and over again: the code is the easy part, it's all the other shit that sucks. I don't want to write a bunch of terraform, set up a CI pipeline, and have to justify why I haven't updated a docker container's dependencies in like 6 months. I just want to write a little Python and make it available on the internet somewhere. Why is that hard?
I'm working on a side project to basically make the tool I wish existed: https://integralcloud.io
If you have a use case that you are willing to talk to me about, please reach out (contact info on my profile). I won't try to sell you anything, ever. I just want to hear about business use cases and try and make something people want to use.
I'm working on a product right now that targets this exact use case. I have contact information in my profile, I would love if you would be willing to reach out and just talk to me about your use cases. I already have a day job at a tech company, so I promise I won't try to sell you anything, ever.
https://integralcloud.io is the app.
If they had built this so they handled the SaaS part, but could persist the data in your organization's own AWS / GCP / Azure blob storage, would that be enough to get the solution past the line for acceptance? I'm in security, but in tech, where SaaS solutions are usually much more accepted.
The challenge with on-prem software of course is just how much support it takes to maintain. At my last gig, we deployed new microservices every 5 minutes; I can't imagine how much it would have sucked to worry about maintaining on-prem installs.
I'm wondering if this kind of shared model could make it workable.
Wowsa. Somebody didn't do their job right if it took anywhere near that amount of time to get logs back. Sorry it was so painful.
For sure. Pull a dbt and get everybody hooked on your tool, then slap a SaaS platform ecosystem to the farthest right and watch the revenue flow.
This issue exists to the right of your solution and is (for now) out of scope, but the biggest issue I have with security data lakes is the need to (easily) get both row-based data and visualizations. Back when I had access to a well-built and cared for Splunk environment, I would constantly run queries, build visualizations, go back to the results index, tweak the query, go back to viz, etc. This feedback loop is important and allows for fast iteration, especially if you are conducting a high-stakes investigation and need answers rapidly. I should be able to look at my available fields and tweak the viz accordingly in under a few seconds; preferably in one mouse click.
Now I live on an ELK stack and I experience nothing but full-time agony as I switch between Kibana and Kibana Lens constantly. It's clear they are two completely separate "products" built for different use-cases. The experience reminds you constantly that they were not purpose-built for how I use them, unlike Splunk.
Increasingly we are moving towards the reality of a security data lake, and all I can think is that I'm about to lose what little power I had left as I have to move to something like Mode, Sisense, or Tableau which again, were not purpose-built for these use-cases and even further separate the query/data discovery and visualization layers.
I hate how crufty and slow Splunk has gotten as an organization, and they use their accomplishments from 15 years ago to justify the exorbitant price they charge. I really hope the OSS/next-gen SaaS options can fill this need and security data lake becomes a reality. But for that to happen, more focus is needed on the user experience as well.
Regardless, very cool stuff and could definitely fill a need for organizations that are just starting to dip toes into security data lakes. I wish you success!
None of it was news. As we learned during the Trump era, just because a narcissist claims that unjust things are happening doesn't make it true. I, for one, am glad that Twitter suppressed links to and media of Hunter Biden stolen and disseminated without his consent. All the other discussions in the "Twitter Files" are mundane, day-to-day happenings and decisions made at a ton of tech companies across the world with two goals: don't get sued, and don't get bad press. More than half of what has been released had already been covered many times over by other news outlets and journalists.
If anyone thinks these communications are a smoking gun, I'd invite them to get into the upper reaches of leadership and see for themselves that there are rarely cut and dry cases where everyone agrees on what to do or when to do it. In reality, operating a multinational business that needs to avoid regulatory scrutiny is, believe it or not, challenging.
So look at all this through the lens of what Elon seeks to gain from releasing all of this. He never acts out of pure altruistic intentions; he only takes action when he believes it will greatly benefit him.
Don't confuse a trademark with a patent. Even if Google uses "go links" internally, the fact remains that the trademark is registered and in use by another entity.
A trademark is not a patent, you don't need to prove you were first to have "the idea". [IANAL] It's the first to use the term in a commercial context, which Google has not.
Typing go/wiki is faster than typing "wiki" in my search bar and hitting the down arrow 5 times for the correct autocomplete answer. I found the bigger (unexpected) value of something like this to be that when I don't know what I want, someone else is likely to have defined it already. E.g. go/401k at my employer takes me right to the wiki page about our 401k plan with a link to our provider prominently at the top. Nobody told me this existed, I simply needed info about our 401k plan and assumed someone, at some point, would have created it. Sure, I could bookmark it or something, but simply typing go/401k "just works" for me. It's also really nice for new hires who don't have some super robust autocomplete history already built up.
That's the value prop.
The name is going to be quickly problematic if the trademark holder for golinks.io decides to get litigious:
Ubuntu 22.04 & RHEL 9 are the major distros impacted. Docker images built on ubuntu:latest will also be impacted. The latest releases of Alpine/Debian/AL2 are all not impacted, they use 1.1.x lineage.
The email address listed in the blog post, securitykeys@cloudflare.com, appears to not be a valid mailbox.
Not a complete nothing burger; a lot of people here work for companies that sell to the Feds or host FedRAMP-authorized SaaS solutions. There will definitely be private-sector impact from that risk framework, though I'm not saying that's necessarily a good or a bad thing.
You have a very neat website (https://sam.design). Learned something new today.
I'm a security professional with a decade and a half of hands-on, real world experience. My most recent position being the product manager for Identity and Access Management for a leading B2B SaaS, dealing with real world attacks from extremely sophisticated threat actors. I assure you I know what I'm talking about, I've lived and breathed it every day for many years and have followed these standards since their initial drafts.
If you have knowledge on superior ways to protect users from MFA passthrough, please share it. I am always happy to learn about better ways of doing things. But contrarian bandwagoning without providing effective alternatives isn't helpful.
[removed by author]
A lot of people still have legacy Yubikeys floating around, and these are replayable. What you need now is something like the Google Titan FIDO2 key or one of the Yubikey FIDO2 keys. Transitioning an entire company to these, getting everyone to self-enroll, and then removing the ability to use all the less safe options across the employee base, contractors, etc is not cheap nor easy, and of course requires a massive amount of retraining. It's not as trivial as just buying them, sadly.
I think it's worth repeating: at this point, MFA that is not based on Webauthn (https://webauthn.guide/#about-webauthn) should be considered dangerously insecure. Uber almost certainly enforces MFA for remote access; I strongly suspect we'll end up hearing that it was successfully provided during the authentication step (update: screenshots on Twitter appear to confirm this). As we saw in the case of the 0ktapus campaign, a sufficiently-skilled attacker will simply proxy the MFA calls to the real identity provider in real-time, the user none the wiser.
Webauthn, however, binds the authenticator to the domain and port, and requires https as the scheme. If a user gets phished, they cannot be compromised: the phisher's domain will not match and any Webauthn authentication challenge would fail.
So if your workplace is letting you authenticate with SMS codes, push notifications to an app, or 6-digit codes generated by an authenticator app/hardware device, you need to start banging on pots and pans up your reporting chain to get your security team the support they need to make Webauthn + FIDO2 hardware tokens or Webauthn + Mac Touch ID happen.