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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
