That is something I just don’t get. I’m a hobbyist turned pro turned hobbyist. The only people who I ever offered my services to were either after one of my very narrow specialties where I was actually an expert or literally could not afford a “real” programmer.
I never found proper security to have any impact on my productivity. Even going back to my peak years in the first decade of this century, there was so much easily accessible information, so many good tutorials, and so many good products that even my prototypes incorporated the basics:
Encrypt the data at rest
Encrypt the data in transit
No shared accounts at any level of access
Full logging of access and activity.
Before rollout, back up and recovery procedures had to be demonstrated effective and fully documented.
Edited to add:
It’s like safety in the workplace. If it’s always an add-on, it will always be of limited effectiveness and reduce productivity. If it’s built in to the process from the ground up, it’s extremely effective and those doing things unsafely will be the productivity drain.
All excellent points. I never worked at those scales or under those conditions, neither should I have been permitted to. And I had enough self-awareness to keep myself away from anything like that.
I guess when I read about this breach or that, the real damage seems to be a result of not having the basics covered. Whatever “basic” might mean for different scales of operation, encrypted at rest seems to be the the basis of public harm through theft of data, and it strikes me that if that can’t be managed at a particular scale, then operating at that scale should not be considered.
Dependencies, scope creep, feature creep, off by one errors, misconfiguration, unclear/unenforced contracts/invariants… Most of those are trivial to solve at small scale, but the more moving parts you have, the more complex it becomes
Of course, but that just makes the case for security as a foundational principle even stronger.
Mistakes happen. They always will. That’s not a reason to just leave security as the afterthought it so often is.
None of the things I mentioned have anything to do with errors and scope creep, but everything to do with building using sound principles and practices always. As in, you know, always. In class, during bootcamps, during design meetings, when writing sample code, when writing reference implementations, during the construction of the prototype that, let’s face it, almost always goes into production. Always.
That is something I just don’t get. I’m a hobbyist turned pro turned hobbyist. The only people who I ever offered my services to were either after one of my very narrow specialties where I was actually an expert or literally could not afford a “real” programmer.
I never found proper security to have any impact on my productivity. Even going back to my peak years in the first decade of this century, there was so much easily accessible information, so many good tutorials, and so many good products that even my prototypes incorporated the basics:
Edited to add:
It’s like safety in the workplace. If it’s always an add-on, it will always be of limited effectiveness and reduce productivity. If it’s built in to the process from the ground up, it’s extremely effective and those doing things unsafely will be the productivity drain.
Did you remember to plan for a zero downtime encryption key rotation?
Did you know when account passwords expire? Have you thought about password rotation?
That sounds like a good practice until you have 20 (or even 2000) backend server requests per end user operation.
All of those are taken from my experience.
Security is like an invasive medical procedure: it is very painful in the short term but prevents dire complications in the long term.
All excellent points. I never worked at those scales or under those conditions, neither should I have been permitted to. And I had enough self-awareness to keep myself away from anything like that.
I guess when I read about this breach or that, the real damage seems to be a result of not having the basics covered. Whatever “basic” might mean for different scales of operation, encrypted at rest seems to be the the basis of public harm through theft of data, and it strikes me that if that can’t be managed at a particular scale, then operating at that scale should not be considered.
Dependencies, scope creep, feature creep, off by one errors, misconfiguration, unclear/unenforced contracts/invariants… Most of those are trivial to solve at small scale, but the more moving parts you have, the more complex it becomes
Of course, but that just makes the case for security as a foundational principle even stronger.
Mistakes happen. They always will. That’s not a reason to just leave security as the afterthought it so often is.
None of the things I mentioned have anything to do with errors and scope creep, but everything to do with building using sound principles and practices always. As in, you know, always. In class, during bootcamps, during design meetings, when writing sample code, when writing reference implementations, during the construction of the prototype that, let’s face it, almost always goes into production. Always.