cloudsec9

While it's easy to write a small piece of code, it's much harder to craft a coherent system of some kind to do anything non-trivial. Does that mean we need some test or professional credential to serve as a "gate" between small and large? I think that the only thing that helps here is experience. And a piece of paper doesn't really help with that.

I also think that good developers are able to be self-deprecating. Just because we muse over not working or writing bad code, we don't want to deliver a bad product or project -- usually the user doesn't see the code. So, I'm fine with being a bit less "professional", if my users are happy with my work product and it makes me seem more approachable and human.

I'd choose an server OS I was familiar with, to start. Something you know is easier to work with then something you don't. Then, keep it up to date, and run only what you need to -- shut off things you aren't using.

Can you run one of the esoteric OSes mentioned here, with a default stance that is "more secure"? Sure. But, when something breaks, can you fix it? Will you be able to maintain it? Will others? If you are building a security _appliance_, like a firewall, I would say 100% run a default secure OS. If you are running a server, pick something you are good at maintaining, and maintain it. It's not perfect, but if you maintain it you'll do pretty well.

Either your business model and philosophy embraces open source, or it doesn't -- I really don't see how having things on conditions helps really. All such pledges might do is give you a bit of runway, and I'm not sure how that advances things. If you have a solid biz model, then going open source helps people who might either benefit or use your software to leverage your platform -- and that can help right away. For me, if your startup is open source, even if you go poof I can still pay someone to maintain the software, reducing my business risk. Plus, if something is broken, I can get it fixed, or if I need something I can add it and possibly contribute it back.

You don't mention the area you are targeting or your biz model, so I can't help on that side. But I wouldn't be so thrilled to contribute to something that "might be" or "will become" open source. I have seen projects that do "funded development", where features are added based on customer or $$ flows -- like "feature X will cost $2k, so 10 new customers or equivalent community contributions and we'll work on it".

I think it's important to document anything, be it at home or for business. I've done good and not so good jobs with this at times, and you feel like a hero when it's well done and you suffer through reinventing things if it's poorly done. I agree you should have config files and backups, but like with work, I think it would be good to go through a "disaster" where you have to build a version of your config from an unconfigured environment. A colleague had built such a config for a small office (10 people), but it depended on a specific DNS that ... wasn't set up until 1/2 way through the config. It worked because in testing they were using the network with a DNS that was already working. Small things like that are hard to catch in a working environment.

I think writing (not short blogs, but longer writing) is a process, and you have to enjoy the process, or at least enjoy the end product to struggle through the process. I think writers can hate a part of the process while enjoying the creating and end part -- and I think we should encourage people to navigate the hard part.

I think it depends on what you want _out_ of the system. For many, they want people with "ready job skills", which can be a challenge to give learners (budgets, always moving targets, etc). If you want to build good theoretical understanding and critical thinking, that requires the learners to work a lot, and is harder to quantify and test, but allows you to keep the material consistent over a long period. Also, different subjects can lend themselves better (or worse) to a distance learning situation. The OP mentions kids moving at different paces -- but that happens in person too -- they just don't notice/see it.

I think one issue is the idea that you can take a few pieces of quality "content", thread through them and have a meaningful course. Mastery is a great thing to talk about -- what is it exactly? For most, it's doing well enough to get a certain mark on a test. But I'd argue what you want is to ensure that learners use concepts they have mastered in a demonstrative way -- but again, this is harder and will cost more. It would be great if education was concerned about deeper understanding, but right now the focus seems to be "will this be on the test".

I don't think it's super helpful for most orgs to try (to stay ahead of NSO type orgs), honestly. You can't have a 100% secure computer, so you are already making some compromises. And, by definition, a zero-day is something that you have no forewarning of.

I think MOST orgs don't have to worry about NSO or state-level actor attacks. Most orgs are far more susceptible to ransomware and phishing, and should focus first on those.

The best approach to mitigating Zero-days is _detection_, to be honest. Would your shop be able to detect files flowing out? Odd time access? Weird probes from a computer inside the network? Security through obscurity is never a good solution. That means bespoke stuff that might be hard to work with, but doesn't necessarily improve your security posture.

You want to develop a deep defense with good detection and monitoring with review. That will help you not just with Zero days, but all security aspects.