3 ms·
I can understand the idea of starting from a simple spot, and iterating/evolving a system to more complexity. But where does - or can - security fit into this?
by cr0sh 8y ago
I can understand the idea of starting from a simple spot, and iterating/evolving a system to more complexity.
But where does - or can - security fit into this?
That is, I've consistently found over my years developing, is that when making a "secure system" - ie, implementing some kind of permissions-based system on top of a login/password or other authorization scheme, for access controls and such...
...doing so after the fact (ie - bandaid-ing) - when the system has already become complex enough to "suddenly" need it - usually ends up being a very poor implementation with tons of holes. It also tends to be very grueling to implement, and lots of refactoring tends to be needed to accommodate the changes.
A similar kind of issue can also be found in the hardware world, specifically automated/robotic systems where you need to implement and think about certain safety measures, cutoffs, big-red-button-full-stop measures. Doing so after the fact can lead to missed edge cases or other issues that can make the system less robust and/or less safe - but only in retrospect after something fails to work from a safety perspective (and it is compounded by the fact that such a system will have both physical hardware and electronics coupled with software).
From that standpoint and personal experiences, I've always tried to stress for new projects that such parts of the system, if needed or thought to be possibly necessary in the future (which is pretty much almost guaranteed for all but the most simple examples) - that it should be designed and implemented "up front" - as the first part of the project. Get it in place and get it solidly built, to the best of your knowledge, then move on to the rest of the project built around that security/safety system(s).
However, such systems can tend to be or become extremely complex in their own right.
Am I wrong in this assessment? Should I not be advocating for such things for new designs? How do you balance this "law" with such needs? Stub all the things?
- AgentME 8y agoGall's Law applies to the security part of a project too. A complex security subsystem needs to evolve from a simpler security subsystem. Waiting until the project as a whole is super complex and needs a complex security subsystem built from scratch is asking for failure.
- hathawsh 8y agoThe word "simple" depends on the context. What's simple for a human may be very complex for a machine and vice-versa. What's simple may be very different for different people and machines. Most of the time, the word "simple" when applied to technology means "well-understood by the people who will use and maintain it". A simple thing can seem very complex for outsiders. For example, I used to think the C programming language was horribly complex, but now that I've spent serious time with it, I think it's actually rather simple. Therefore, I think it's fair to replace most uses of the word "simple" in technology with "well-understood", like this: A complex system that works is invariably found to have evolved from a well-understood system that worked. A poorly understood system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working, well-understood system. I agree that permissions-based systems have necessary upfront complexity, but I also think they can be well-documented and well-understood.