If the goal were point-scoring gotchas, that I frequently advocate industry best practices for security redundancy might indeed seem out of place here. I am normally a belt-and-suspenders kinda guy, and I make no apologies for it.

Those redundancies usually come up in discussions about exposing databases directly to the open Internet, as opposed to doing the common thing of putting a script between the DB and the connection (which affords the added benefit of allowing us to craft a nice API to help our client dev work move forward more smoothly as well).

The distinction is how common the practice is. We see that most systems put a script in front of their DB. And we see that most use localhost sockets without SSL.

I'm not inventing any of this. I don't hold an CISSP cert, and I don't manage most of the world's projects. I just see what I see, share what I see, and where I don't understand something I'll ask, like I did here seeking a use-case where the benefit of slowing every socket comm down with encryption and decryption provides a benefit not immediately undone the moment the data is at rest.

I still hold that there might be a good use case, but after a brief search on this I was unable to find one, and none has emerged yet even here.

In your original post describing this system, you emphasized that LC multiprocessing is being used to find the fastest way to handle the data flow. We generally accept a tradeoff between utility and security, but as with so much of life tradeoffs work best when evaluated for the case at hand.

If a user's machine is hosed, it's hosed. If we look for guidance on that from better minds than mine, we can review the practices of leading app and OS vendors. Address space layout randomization may be a good example of how an OS vendor can mitigate risks in compromised machines, but the same OS vendors employing it don't also recommend app devs add their own address randomization at the app level. Maybe app devs should? Maybe OS vendors are lax?

The deeper we go down the rabbit hole of protecting systems, the more challenging it gets. At a certain point -- a somewhat shallow point, I don't mind admitting -- I'm happy to leave the deep thinking to specialists and just follow common practice. If I happen to see a risk that common practice doesn't cover, I'll cover it as I go. But even though we have Stuxnet to remind us of the impact of unanticipated consequences from design decisions, if I don't have a specific threat vector in mind AND it's not a common practice, odds are I'll skip it.

I admit I'm far less of a programmer than the minds behind Stuxnet. And since most of the world is, I'm okay with that.

Security awareness is good, and redundancy common. But where a redundancy is both uncommon and provides little benefit not undone easily elsewhere in the system, I'll often skip it.

And when the house is on fire, I'm not sure it's a service to the homeowner to help maintain the illusion that their house isn't on fire.

 Richard Gaskin
 Fourth World Systems

Tom Glod wrote:

> Hhahah Richard, that was hilarious. :D Given I've given you next to no
> info on the use case, I understand why it may seem overkill, and maybe
> it is.
> A wise person once told me .... and I'm paraphrasing..... " you can't
> prevent everything ....so the task at hand is to make things harder
> and take longer."  That person was you.
> So would it make it harder to steal data if data transport between 2
> decoupled processes was encrypted? you bet.
> Thanks for giving me food for thought...and I will triple check to
> make sure its necessary. :D
> On Mon, Feb 1, 2021 at 6:16 PM Richard Gaskin wrote:
>> Tom Glod wrote:
>>  > Richard,
>>  >
>>  > Lets say one of my users is targeted by a hacker and they manage
>>  > to install a malware process on their system that will capture all
>>  > the data flowing between the 2 processes.
>>  > Then they do not need to be sitting in the victim's chair.
>>  > But if the data was encrypted, this wouldn't matter.
>> True, that one aspect of your program wouldn't matter.  But since
>> everything else on the system is now hosed, does anything matter?
>> To my ear it sounds like a planning committee meeting for a zoo in
>> which they're deciding on the steel thickness of armored suits they
>> require visitors to wear because tigers are running loose, while
>> the whole facility is on fire. I'm in the back of the room raising
>> my hand asking if we might just put the tigers back in the cage.
>> After we put out the fire. :)
>> In the scenario you described, what prevents the bad guy from reading
>> the data at rest? Or keylogging? Or replacing either or both of the
>> executables you delivered? Or anything else they might do once they
>> have that level of control throughout the system?
>> --
>>   Richard Gaskin
>>   Fourth World Systems

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to