SoylentNews is people
SoylentNews
I recently had to work with a large piece of well aged and reliable legacy software that had to be modified to include data protection for some sensitive personal information due to recent legislation. Developers not experienced with security bolted on some encryption. They made up their minds on what to do on the fly, as they tried to somehow add the security features. It could be expected, that under such circumstances, they ended up with a confusing mess of obfuscation that couldn't even really called "secure". Anyone with knowledge of the inner workings would be able to reconstruct all the data from accessible files. Yet they had to write extra software, not only for handling passwords, but also for moving data between machines that could be moved by simple file transfer before. Debugging this also became annoying, with many road stops, and I flinched a lot.
But in this journal entry, I don't want to highlight how good or bad this implementation was, but how much time it took to deal with the issues. Many person-months were spent on getting it to run or working around the hurdles it created. And more will be spent in the future to sort out persisting issues and go forward.
Of course, I have thought about how the setup could be made to work in a proper secure way. It would mean, much simplified, moving the key management to a separate process running as root, and throwing away the root password and the keys for the padlock on the machine case. As a consequence, all normal administration would have to happen elevated from root. But again, the details don't matter here. What matters is my estimate that implementing it would have taken at least as much time as the weaker implementation.
Fred Brooks, in "The Mythical Man Month" has a figure, the first in the book, showing the double evolution from a Program to a Programming System Product. He postulates that each single evolution, from Program to System, or from Program to Product increases the required effort by a factor of three. These combine, so getting from a Program to a Programming System Product will take a ninefold effort.
I postulate that the addition of securing the processed data will add another factor of three. Therefore, a Secure Programming System Product - that is secure, interacts with other programs, and can be deployed to end-users - will take twenty-seven times the effort of writing a simple self-contained Program for the same task without the extra considerations.
Don't fool yourselves when you make fixed-price offers. ;)
(Score: 5, Funny) by DannyB on Tuesday October 11 2022, @02:18PM (1 child)
Trying to make an accurate estimate for a fixed price offer would be difficult. It would require actual work and analysis of what is to be done. Shirley you cannot expect a contractor to do this?
What must actually be done to secure that data at rest? Where do you keep the key to read and write that data? Under the welcome mat is a good place.
While Republicans can get over Trump's sexual assaults, affairs, and vulgarity; they cannot get over Obama being black.
(Score: 3, Touché) by Rich on Wednesday October 12 2022, @03:26AM
Well, I'm not Boeing, and my customers aren't funded by the American taxpayer...
(Score: 1, Insightful) by Anonymous Coward on Tuesday October 11 2022, @05:31PM (6 children)
It seems like a significant part of the issue is that the security features were added on to a mature piece of software and couldn't easily be integrated well into the existing system. Perhaps that's an incorrect assessment, but that's what I understood from reading your journal.
Would it have been better if it was initially designed around security requirements like data being encrypted? I know, this won't completely avoid the issue as security standards are updated. However, it seems like the changes might be more incremental (e.g., updating data encryption standards) instead of the more significant changes that you're describing. It seems easier, for example, to switch encryption methods than to add on encryption to a system that doesn't already have it. There's still some extra work to create a secured system like the management of keys, but it seems like it would be less work if that was a design decision made at the beginning instead of being added on in a clunky way later in the process.
It seems like having general standards for secure design (e.g., when and where data have to be encrypted, access controls, etc...) from the beginning would be a good approach. There will still most likely be improvements that are needed during the life cycle of the software, but it seems like this could make the code more maintainable. I think that's some of what you're proposing, and if so, I agree.
(Score: 1, Insightful) by Anonymous Coward on Tuesday October 11 2022, @07:05PM (4 children)
Software is written to solve the problem you have at the time, not unknowable problems you may have in the future. We like to say that security shouldn't be a bolt-on but often we can't accurately predict real world requirements. From a maintenance perspective, over-engineering can be more burdensome than poor engineering. C'est la vie!
(Score: 2) by RS3 on Tuesday October 11 2022, @09:01PM (3 children)
Dovetailing with your and parent's posts, it saddens me how pretty much everyone is conditioned to accept "workarounds" and patches. Usually that becomes the full acceptable normal first-line way of doing things. Sigh.
(Score: 3, Insightful) by Rich on Wednesday October 12 2022, @01:26PM (2 children)
I've come to accept this mode of operation in business. Until the underlying economic system is switched out anyway. If a software covers a new topic and creates an ecosystem around it, the first one to be barely good enough to bear, and cheap enough for the masses, will own that ecosystem. Classic application of the German saying "Der Teufel scheisst immer auf den größten Haufen." (The devil always shits on the biggest pile). Hello '80s Microsoft. Anyone who comes late to the party, even if it is because of higher quality standards, will lose out.
To a lesser extent, other products are affected too, because taking longer simply cuts into the margin. And doing something in a pure perfectness that pleases OCD souls will always take longer than getting to the point where it can be sold.
My journal entry was only there to point out how long I think it takes to make a software properly secure. If there's anything to conclude from that estimate, and the devil's-pile rule, it is that a properly secured competitor will generally lose out to something that has only enough superficial security theater put on to be marketable.
However, I think that there's a situation where the software (or even some hardware) is considered neither as a product (as above) or as means to scratch an itch (common with FLOSS), but as art, free of economic considerations or necessities. But this is material for another post.
(Score: 2) by hendrikboom on Wednesday October 12 2022, @02:04PM
I'd very much like to see that other post.
(Score: 2) by RS3 on Wednesday October 12 2022, @07:47PM
I wish I had more time for a better post. I'm not a psychologist, but I think much of the problem is with the end user. I think one factor is that generally people are short-sighted, and maybe that's innate. "Eat, drink, and be merry, for tomorrow we die" kind of thing. And part of that factor is that technology, including software, changes fast and uncontrollably. I got into Novell (fell into it at jobs really) back in the 90s and it was truly amazing software. What it could get out of a very modest CPU and RAM was amazing. But the freight train pushed most of the market into Windows and Novell fizzled. Most companies I've worked for have had the attitude of "just ship it", as in, it'll be obsolete next month anyway.
Personally I'm of a different mindset. I have and drive older cars, older computers, older tools, etc. Some new stuff is super useful and helpful, but most newer things don't last as long as the older more rugged stuff. I wish the mindset was to refine something before shipping it. But again, the market always wants "New!" and "Features!", so competition-driven development gives us the large-scale system we have (ever-cheapening of everything, but make it look good on the outside...)
I'm constantly wishing for the option of better quality stuff. Stores don't want to track and stock 20 different ratchet wrench brands and models, so you generally get maybe 2 options: bad and worse. Online buying has helped that world in many ways. Online you can buy even cheaper crap, but also much better stuff.
Another factor I remember from some article years ago- the bean-counter / MBA-types consider IT a loss expense, so do everything you can do reduce IT costs.
About 10 years ago I inherited admin of an email server. It was based on "qmail", which was an abandoned project at that time, but it was working, so nobody prior paid any attention. ISP suddenly (I had no warning anyway) decided to block port 25, and all sent mail had to be on port 587. Qmail is written in C. I've done some C, so I wasn't afraid to see what I could do to change port numbers. SOB, port 25 references were not a #define (like it should have been) nor a variable- it was all hard-coded ("magic numbers" a past co-worker coder called them). So I found and replaced all referenced to port "25", made a #define (made sure it was unique), recompiled, but long story short- it never worked. That server was critical to many customers, including a printing business that needed very fast communications. Within 2 days, company owner (properly) ended up moving email to some major provider. So I lost some income.
The whole thing got worse and worse- ISP started requiring SMTP authentication mechanism. Then every "from" address had to be within their domain. Their "help" people could never give me a straight answer as to how to run our email server, or even send formmail from a webserver. So sometimes "security" is too good and blocks most functionality.
TV show on yesterday (kind of in the background- I don't focus on TV) talked about how 65% of all Rolls Royce automobiles ever produced are still on the roads today. Now if I could just afford one!!
I've learned I do better in market sectors where quality is higher priority. I've been working in a food processing factory and quality and cleanliness is critical, and nobody ever pressures anyone to cut corners if there's any chance of affecting product quality. Don't misunderstand- we'll patch anything we need to (hardware, mechanical) to keep production running, but again, never never never if it could affect product quality. And we always aim to get the correct parts needed to do the repair correctly.
Another huge layer is that most people have no experience with coding and to them software is a "black box". So again, inner product quality and design is not palpable to most people. Too often people come to accept that something is designed well and we humans have to adapt to the thing.
There's been a growing sentiment that everything is fungible and disposable (eat, drink, and be merry...).
All of this reminds me (too well) of the Boeing 737MAX / MCAS disaster. It's interesting to study that story, of how something so critical to the safety of the passengers and crew got less critical review and attention than upholstery color in first class.
(Score: 2) by Rich on Wednesday October 12 2022, @03:54AM
The system I mentioned in the journal entry has been an ongoing project since the early nineties of the last century. I assume there are lots of such legacy systems having to be upgraded to data protection regulations. Still, I think an incremental development in such a situation is less effort than a complete re-design. A re-resign would, Brooks again, risk suffering from second-system syndrome. It happened that the ad-hoc development of the extra features wasn't thought out well, so it ended up being quite shitty, but even if it had been done by the unobtanium developers every executive dreams of having, it would only have been better in quality, not faster in development time spent.
I think my prediction holds for ground-up designed systems, too, because considering the data protection requirements for every bit of data to be protected not only adds to the considerations that already have to be done for every bit of data (permissible value ranges, relationship behaviour, object lifetimes, access performance, and what not), but also interferes with those other considerations at times. (Which in the example case, led to the necessity to write a complete backup solution instead of being able to use plain file copies.)
I didn't really propose anything. I just noted that this extra effort is there and has to be taken into account. None of the usual customers will accept that the little hack that took ten work days will take over a man-year if it is supposed to interact with other processes (3x so far as per Brooks), be deployable to customers (9x so far, again, Brooks), and follow data protection regulations (27x, as per my thesis), but you still have to be honest to yourself when planning.
(Score: 2) by DannyB on Wednesday October 12 2022, @02:33PM (2 children)
If security wasn't a consideration in the original design, then that dates it quite a bit. I'm guessing this was probably written more than twenty years ago?
While Republicans can get over Trump's sexual assaults, affairs, and vulgarity; they cannot get over Obama being black.
(Score: 3, Insightful) by Rich on Wednesday October 12 2022, @10:34PM (1 child)
You guess right. That project started around 1992. Personal computers were exactly that, "personal", back then. Over the years, two waves of security features had to be added.
Note that I don't think a secure product has to be built from scratch. I think incremental development is a very sensible choice for going forward. You don't throw away all the institutional knowledge that has accumulated in the code. It just has to be done right, exactly like a from-scratch-design has to be done right. Problem is that this can be immensely complicated with complex systems and corporations usually don't have the right staff for it.
(Score: 2) by DannyB on Thursday October 13 2022, @01:53PM
You cannot just rewrite everything.
This is why COBOL is still around.
It is why Java is the modern day COBOL. And for the same reason.
While Republicans can get over Trump's sexual assaults, affairs, and vulgarity; they cannot get over Obama being black.