loudwhisper

joined 2 years ago
[–] loudwhisper@infosec.pub 1 points 5 minutes ago

But you know what the kernel is. You know that syscalls are a thing, you know what role the kernel performs, you know that different filesystems have different properties (and pros and cons), etc..

You don't need to know the details, perhaps, but you can't ignore the fundamental theoretical concepts of kernel and OS. You might not know the whole detail of the boot procedure, but if your machines are stuck on boot, you know at least what to look for.

Here I was talking about equally foundational topics. There is nothing "above" - say - producing attestations and then verifying them. That's literally all there is to it, but if you don't understand the theory behind it, what exactly are you doing? As as I said, I don't care about the details, I didn't expect someone mentioning ciphers or timestamp authorities, transparency logs etc. All I would expect is "we produce a signature with a bunch of metadata and we verify it where we consume the artifact, so that we are sure that the artifact has the properties attested by the signature".

Not knowing this is like someone claiming that they administer Linux machines but can't explain what network interfaces are or how routing is determined. This is not a question of being expert on different layers, this is just being oblivious to those other layers completely.

[–] loudwhisper@infosec.pub 1 points 15 minutes ago

A cloud VM, just shut it down and you're done.

If this flexibility is needed, and it's an "if", a dedicated server does the same. But even a cloudVM is already lower level compared to other services (which are even more abstract) - like EKS, SQS, etc.

The value an organization provides to customers should be the primary focus of the business, the rest is a means to sharpen that focus.

In my experience this often translates in values that flows to AWS, while the company giving value to customers is stuck with millions of cloud bills each month, and a large engineering footprint that eventually needs to cut, leaving fewer and fewer people working on the product.

That said, I acknowledge that cloud has business reasons to exist, I wrote an entire other post about my hate for it, but I still acknowledge that. However there are some myths that finally are getting dispelled (outsource infra and focus on your product).

[–] loudwhisper@infosec.pub 2 points 20 minutes ago (1 children)

I mean, the person in question had "hardening EKS" on their CV. EKS still means that the whole data plane is your responsibility. How can you harden a cluster without understanding the foundation of container security (isolation primitives, capabilities, etc.)? Workload security is very much part of the job.

I mean the moment some pod will need to run with some privilege (say, a log forwarder which gets host logs), and you need to "harden" the cluster, what do you do if you don't understand the concept of capabilities? I will tell you what, because I asked this very question, and the answer was "copy the logs elsewhere", which is the "make it work with the hammer solution" that again shows the damage of not understanding.

I am with you about different scopes, skillsets etc. But here we were interviewing people with a completely matching skillset on paper.

[–] loudwhisper@infosec.pub 1 points 27 minutes ago

Thanks, indeed I think there are many parallels with other areas. I will check it out.

[–] loudwhisper@infosec.pub 2 points 29 minutes ago

I totally agree with you, but I don't think this is the specific case. Most of the rejections in our case (which I can see) on the preliminary screening were based on lacking CV skills. Which is stupid in its own way, but at least makes sense assuming we are looking for those skills specifically.

For the rest, the company is a remote company paying good salaries for the European market, I would say slightly above market average in many metrics.

I will sift more into the rejections, but from what I have seen, almost all those who had the screening phone call made it to the interview (I.e., rejections were mostly cv-based).

[–] loudwhisper@infosec.pub 1 points 34 minutes ago

But those are absolutely not the only 2 levels. Server rental can be managed easily by the same infra team who manages the cloud, for a fraction of cost.

I will say more, the same exact team that spends time managing EKS clusters could manage self-managed clusters and have money to spare for additional hires.

[–] loudwhisper@infosec.pub 4 points 1 hour ago (3 children)

Mind you that my take and experience is specifically in the context of security.

I struggle to make the parallel that you suggest (which might work for some areas) with a security engineer.

Say, a person learned to brainlessly parrot that pods need to have setting x or z. If they don't understand them, they can't offer meaningful insight in cases where that's not possibile (which might be specific), they can't provide a solid risk analysis etc.

What is the counterpart to this gap? Because I struggle to see it. Breadth of areas where this superficial knowledge is available is useless, IMHO.

[–] loudwhisper@infosec.pub 6 points 1 hour ago

Ahaha yes, that might be the case, but I started to lose hope if the top of the applicants (out of hundreds of rejected!) all exhibits this behavior. I can't help but feel that now we are looking for people with a mindset and skillset that is simply disappearing in the industry.

And as I said in another post, I perfectly acknowledge that if I stopped reading and investigating stuff on my own, I could absolutely keep my job by just mindlessly administering a few services and rephrasing CIS benchmarks...

[–] loudwhisper@infosec.pub 1 points 1 hour ago (4 children)

This is quite a trite argument from my point of view. Also, this is from the perspective of the business, which I don't particularly care about, and I tend to look from the perspective of the worker.

Additionally, the cloud allows to scale quickly, but the fact that it allows to delegate everything is a myth. It's so much a myth that you see companies running fully on cloud with an army on people in platform teams and additionally you get finops teams, entire teams whose job is optimizing the spend of cloud. Sure, when you start out it's 100% reasonable to use cloud services, but in the medium-long term, it's an incredibly poor investment, because you still need people to administer the cloud plus, you need to pay a huge premium for the services you buy, which your workforce now can't manage or build anymore. This means you still pay people to do work which is not your core business, but now they babysit cloud services instead of the actual infra, and you are paying twice.

Cloud exploded during the times of easy money at no interest, where startups had to build some stuff, IPO and then explode without ever turning a single dollar of profit. It's a model that fits perfect in that context.

[–] loudwhisper@infosec.pub 12 points 1 hour ago

Not when the skillset is essentially outsourced and you are left consuming the product of that skillset.

Understanding is nonnegotiable in security, IMHO.

You can't fail to understand how signature attestation works, if you are implementing it, to make one example I made in the post. Otherwise you end up verifying the signature in the CI (like that person claimed it should be done) and waste the whole effort. You can definitely still outsource the whole infra and scripting to Github, but you still need to understand. The problem is that when you can outsource everything, at some point understanding becomes an extra step.

[–] loudwhisper@infosec.pub 5 points 1 hour ago (3 children)

That's the thing! I think it wouldn't be conceivable that your "principal engineer" (real position for one of the people) doesn't understand the basic theory of the stuff they are implementing. Now it feels you can instead work years and years just shuffling configuration and pressing buttons, leading to "senior" people who didn't gather actual years of experience.

I don't want to pretend I am outside this logic. I am very much part of this problem myself, having started my career 10 years ago. I do despise cloud services though (if anything, they are super boring), so I tend to work with other stuff. But I could 100% just click buttons and parrot standard and keep accruing empty years of experience...

 

My take on how a decade (or more) of using cloud services for everything has seemingly deskilled the workforce.

Just recently I found myself interviewing senior security engineers just to realize that in many cases they had absolutely no idea about how the stuff they supposedly worked with, actually worked.

This all made me wonder, is it possible that over-reliance on cloud services for everything has massively deskilled the engineering workforce? And if it is so, who is going to be the European clouds, so necessary for EU's digital sovereignty?

I did not copy-paste the post in here because of the different writing style, but I get no benefit whatsoever from website visits.

[–] loudwhisper@infosec.pub 11 points 3 days ago (1 children)

I completely respect your position. Some people genuinely like the office life and it's totally fine!

Personally, I have never had any boundary issue with home being used for work. I have my own office room that is also my hobby room that I made as I like, so it's a very nice and quiet space, and I love working there.

Besides the obvious aspects of this post which are quite dumb, what that person misses is that by working from home I finish to work at 17 and at 17.01 I am free to go meet people. Cutting commuting time frees quite some time for personal life and not to mention working from home is associated with more flexible work too, like doing some chores during a break etc., which frees up even more time.

 

cross-posted from: https://infosec.pub/post/16642151

(I have just learned you can cross-post!)

As someone who has read plenty of discussions about email security (some of them in this very community), including all kind of stuff (from the company groupie to tinfoil-hat conspiracy theories), I have decided to put ~~too many hours~~ some time to discuss the different threat models for email setups, including the basic most people have, the "secure email provider" one (e.g., Protonmail) and the "I use ~~arch~~ PGP manually BTW".

Jokes aside, I hope that it provides an overview comprehensive and - I don't want to say objective, but at least rational - enough so that everyone can draw their own conclusion, while also showing how certain "radical" arguments that I have seen in the past are relatively shortsighted.

The tl;dr is that email is generally not a great solution when talking about security. Depending on your risk profile, using a secure email provider may be the best compromise between realistic security and usability, while if you really have serious security needs, you probably shouldn't use emails, but if you do then a custom setup is your best choice.

Cheers

 

As someone who has read plenty of discussions about email security (some of them in this very community), including all kind of stuff (from the company groupie to tinfoil-hat conspiracy theories), I have decided to put ~~too many hours~~ some time to discuss the different threat models for email setups, including the basic most people have, the "secure email provider" one (e.g., Protonmail) and the "I use ~~arch~~ PGP manually BTW".

Jokes aside, I hope that it provides an overview comprehensive and - I don't want to say objective, but at least rational - enough so that everyone can draw their own conclusion, while also showing how certain "radical" arguments that I have seen in the past are relatively shortsighted.

The tl;dr is that email is generally not a great solution when talking about security. Depending on your risk profile, using a secure email provider may be the best compromise between realistic security and usability, while if you really have serious security needs, you probably shouldn't use emails, but if you do then a custom setup is your best choice.

Cheers

 

Hi, recently (ironically, right after sharing some of my posts here on Lemmy) I had a higher (than usual, not high in general) number of "attacks" to my website (I am talking about dumb bots, vulnerability scanners and similar stuff). While all of these are not really critical for my site (which is static and minimal), I decided to take some time and implement some generic measures using (mostly) Crowdsec (fail2ban alternative?) and I made a post about that to help someone who might be in a similar situation.

The whole thing is basic, in the sense that is just a way to reduce noise and filter out the simplest attacks, which is what I argue most of people hosting websites should be mostly concerned with.

 

GoDaddy really lived up to its bad reputation and recently changed their API rules. The rules are simple: either you own 10 (or 50) domains, you pay $20/month, or you don't get the API. I personally didn't get any communication, and this broke my DDNS setup. I am clearly not the only one judging from what I found online. A company this big gating an API behind such a steep price... So I will repeat what many people said before me (being right): don't. use. GoDaddy.

 

I hope this won't be counted as some form of self-promotion, even though I am sharing a post from my own blog.

As a tech worker who works in a Cloud shop, I wanted to elaborate the many reasons why I find working with Clouds terrible, from multiple points of view.

I tried to organize my thoughts in a (relatively long) post, in which both technical aspects and political aspects (which are very related) are covered.

I am sure many people will have different perspectives, and this could be potentially also a nice prompt for a discussion.

view more: next ›