Re: Re:Predictive failures

Liste des GroupesRevenir à se design 
Sujet : Re: Re:Predictive failures
De : blockedofcourse (at) *nospam* foo.invalid (Don Y)
Groupes : sci.electronics.design
Date : 17. Apr 2024, 20:50:07
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <uvp5l9$1ojua$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
User-Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
On 4/17/2024 10:49 AM, Edward Rawde wrote:
You could ping me if you knew my IP address.
>
You can't see me, at all.  You have to know the right sequence of packets
(connection attempts) to throw at me before I will "wake up" and respond
to the *final*/correct one.  And, while doing so, will continue to
ignore *other* attempts to contact me.  So, even if you could see that
I had started to respond, you couldn't "get my attention".
 I've never bothered with port knocking.
Those of us with inbound connectable web servers, database servers, email
servers etc have to be connectable by more conventional means.
As with installing updates and other "maintenance issues", I have
no desire to add to my workload.  I want to spend my time *designing*
things.
I run the server to save me time handling requests from colleagues for
source code releases.  This lets them access the repository and
pull whatever versions they want without me having to get them and
send them.  Otherwise, they gripe about my weird working hours, etc.
(and I gripe about their poorly timed requests for STATIC resources)
There is some overhead to their initial connection to the server
as the script has to take into account that packets aren't delivered
instantly and retransmissions can cause a connection attempt to be
delayed -- so, *I* might not see it when they think I am.
But, once the connection is allowed, there is no additional
overhead or special protocols required.

I wouldn't bother. I'd just not connect it to wifi or wired if I
thought
there was a risk.
>
What I mean by that is I'd clean it without it being connected.
The Avira boot CD used to be useful but I forget how many years ago.
>
If you were to unplug any of the above mentioned ("house") drops,
you'd find nothing at the other end.  Each physical link is an
encrypted tunnel that similarly "hides" until (and unless) properly
tickled.  As a result, eavesdropping on the connection doesn't
"give" you anything (because it's immune from replay attacks and
it's content is opaque to you)
 I'm surprised you get anything done with all the tickle processes you must
need before anything works.
I wouldn't "unplug any of the above mentioned drops".  I'd let them connect
using their native protocols.  This is already baked into the code so "costs"
nothing.
The hiding prevents an adversary from cutting an exposed (e.g., outside the
house) cable and trying to interfere with the system.  Just like an adversary
on a factory floor could find a convenient, out-of-the-way place to access the
fabric with malevolent intent.  Or, a guest in a hotel.  Or, a passenger
on an aircraft/ship.  Or, a CAN node in an automobile (!).

They should be secure from the threats they are LIKELY TO FACE.
If the only access to my devices is by gaining physical entry
to the premises, then why waste CPU cycles and man-hours protecting
against a threat that can't manifest?  Each box has a password...
pasted on the outer skin of the box (for any intruder to read).
 Sounds like you are the the only user of your devices.
I'm a "development lab".  I want to spend my time using my tools to
create new products.  I don't want to bear the overhead of trying to
keep up with patches for 0-day exploits just to be able to USE those
tools.  I am more than willing to trade the hassle of walking
down the hall to another computer (this one) to access my email.
And, if I DL a research paper, copying it onto a thumb drive to
SneakerNet it back to my office.  To me, that's a HUGE productivity
increase!

Consider a small business.
Here you want a minimum of either two LANs or VLANs so that guest access to
wireless can't connect to your own LAN devices.
Your own LAN should have devices which are patched and have proper
identification so that even if you do get a compromised device on your own
LAN it's not likely to spread to other devices.
The house network effectively implements a VLAN per drop.  My OS only lets
"things" talk to other things that they've been preconfigured to talk to.
So, I can configure the drop in the guest bedroom to access the ISP.
Or, one of the radios in the ceiling to do similarly.  If I later decide that
I want to plug a TV into that guest bedroom drop, then the ISP access is
"unwired" from that drop and access to the media server wired in its place.
And, KNOW that there is no way that any of the traffic on either of those
tunnels can *see* (or access) any of the other traffic flowing through the
switch.  The switch is the source of all physical security as you have
to be able to convince it to allow your traffic to go *anywhere* (and WHERE).
[So, the switch is in a protected location AND has the hardware
mechanisms that let me add new devices to the fabric -- by installing
site-specific "secrets" over a secure connection]
Because a factory floor would need the ability to "dial out" from a
drop ON the floor (or WiFi) without risking compromise to any of
the machines that are concurrently using that same fabric.
Imagine having a firewall ENCASING that connection so it can't see *anything*
besides the ISP.  (and, imagine that firewall not needing any particular rules
governing the traffic that it allows as it's an encrypted tunnel letting
NOTHING through)

You might also want a firewall which is monitored remotely by somone who
knows how to spot anything unusual.
I have much written in python which tells me whether I want a closer look at
the firewall log or not.
Yet another activity I don't have to worry about.  Sit in the guest bedroom
and you're effectively directly connected to The Internet.  If your machine
is vulnerable (because of measures YOU failed to take), then YOUR machine
is at risk.  Not any of the other devices sharing that fabric.  You can get
infected while sitting there and I'm still safe.
My "labor costs" are fixed and don't increase, regardless of the number
of devices and threats that I may encounter.  No need for IT staff to handle
the "exposed" guests -- that's THEIR problem.

Do I *care* about the latest MS release?  (ANS:  No)
Do I care about the security patches for it?  (No)
Can I still do MY work with MY tools?  (Yes)
 But only for your situation.
If I advised a small business to run like that they'd get someone else to do
it.
And they would forever be "TAXED" for their choice.  Folks are starting
to notice that updates often don't give them anything that is worth the
risk/cost of the update.  Especially if that requires/entices them to have
that host routed!
My colleagues have begrudgingly adopted a similar "unrouted development
network" for their shops.  The savings in IT-related activities are
enormous.  And, they sleep more soundly knowing the only threats
they have to worry about are physical break-in and equipment
failure.
You want to check your email?  Take your phone out of your pocket...
Need to do some on-line work (e.g., chasing down research papers
or browsing a remote repository)?  Then move to an "exposed"
workstation FOR THAT TASK.
[Imagine if businesses required their employees to move to such
a workstation to browse YouTube videos or check their facebook
page!  "Gee, you're spending an awful lot of time 'on-line',
today, Bob...  Have you finished that DESIGN, yet?"]

I have to activate an iPhone, tonight.  So, drag out a laptop
(I have 7 of them), install the latest iTunes.  Do the required
song and dance to get the phone running.  Wipe the laptop's
disk and reinstall the image that was present, there, minutes
earlier (so, I don't care WHICH laptop I use!)
 You'll have to excuse me for laughing at that.
Cybersecurity is certainly a very interesting subject, and thanks for the
discussion.
If I open one of the wordy cybersecurity books I have (pdf) at a random page
I get this.
"Once the attacker has gained access to a system, they will want to gain
administrator-level access to the current resource, as well as additional
resources on the network."
Hence the reason for NOT letting anything "talk" to anything that it shouldn't.
E.g., the oven has no need to talk to the front door lock.  Or, the garage
door opener.  Or, the HVAC controller.  So, even if compromised, an adversary
can only do what those items could normally do.  There is no *path* to
the items that it has no (designed) need to access!
With a conventional fabric, anything that establishes a beachhead on ANY
device can start poking around EVERYWHERE.  You have to monitor traffic
INSIDE your firewall to verify nothing untoward is happening (IDS -- yet
another cost to install and maintain and police!)

Well duh. You mean like once the bank robber has gained access to the bank
they will want to find out where the money is?
Banks keep the money is well-known places.  Most commercial (and free) OS's
are similarly unimaginative.  So, *looking* for it is relatively easy.
Especially OSs which use a unified file system as a naming mechanism
for everything in the system ("Gee, let's go have a peek at passwd(5)...")
In my approach, an actor only knows about the items that he SHOULD know about.
So, you may *SUSPECT* that there is a "front door" but the only things you
have access to are named "rose bush" and "garden hose" (if you are
an irrigation controller).
In a conventional (50 year old design!) system, you would *see* the names
of all of the devices in the system and HOPE that someone had implemented
one of them incorrectly.  Your task (pen-test) would be to figure out
which one and how best to exploit it.
Had the designers, instead, adhered to the notions of information hiding,
encapsulation, principle of least privilege, etc. there's be less attack
surface exposed to the "outside" AND to devices on the *inside*!  (But,
you need to approach the design of the OS entirely differently instead of
hoping to layer protections onto some legacy codebase)

Date Sujet#  Auteur
15 Apr 24 * Predictive failures70Don Y
15 Apr 24 +* Re: Predictive failures27Martin Rid
16 Apr 24 i`* Re: Predictive failures26Don Y
16 Apr 24 i `* Re: Predictive failures25Edward Rawde
16 Apr 24 i  `* Re: Predictive failures24Don Y
16 Apr 24 i   +* Re: Predictive failures3Edward Rawde
16 Apr 24 i   i+- Re: Predictive failures1Edward Rawde
17 Apr 24 i   i`- Re: Predictive failures1legg
16 Apr 24 i   `* Re: Predictive failures20Edward Rawde
16 Apr 24 i    `* Re: Predictive failures19Don Y
16 Apr 24 i     +* Re: Predictive failures16Edward Rawde
16 Apr 24 i     i`* Re: Predictive failures15Don Y
16 Apr 24 i     i +* Re: Predictive failures13Edward Rawde
16 Apr 24 i     i i`* Re: Predictive failures12Don Y
17 Apr 24 i     i i `* Re: Predictive failures11Edward Rawde
17 Apr 24 i     i i  `* Re: Predictive failures10Don Y
17 Apr 24 i     i i   `* Re: Predictive failures9Edward Rawde
17 Apr 24 i     i i    `* Re: Predictive failures8Don Y
17 Apr 24 i     i i     `* Re: Predictive failures7Edward Rawde
17 Apr 24 i     i i      `* Re: Predictive failures6Don Y
17 Apr 24 i     i i       `* Re: Predictive failures5Edward Rawde
17 Apr 24 i     i i        `* Re: Predictive failures4Don Y
17 Apr 24 i     i i         `* Re: Predictive failures3Edward Rawde
17 Apr 24 i     i i          `* Re: Predictive failures2Don Y
17 Apr 24 i     i i           `- Re: Predictive failures1Edward Rawde
17 Apr 24 i     i `- Re: Predictive failures1Don Y
17 Apr 24 i     `* Re: Predictive failures2Liz Tuddenham
17 Apr 24 i      `- Re: Predictive failures1Don Y
15 Apr 24 +- Re: Predictive failures1john larkin
15 Apr 24 +* Re: Predictive failures11Joe Gwinn
16 Apr 24 i`* Re: Predictive failures10Joe Gwinn
16 Apr 24 i +* Re: Predictive failures7john larkin
16 Apr 24 i i`* Re: Predictive failures6Joe Gwinn
16 Apr 24 i i `* Re: Predictive failures5John Larkin
17 Apr 24 i i  +* Re: Predictive failures3Edward Rawde
17 Apr 24 i i  i`* Re: Predictive failures2John Larkin
17 Apr 24 i i  i `- Re: Predictive failures1Edward Rawde
17 Apr 24 i i  `- Re: Predictive failures1Joe Gwinn
16 Apr 24 i `* Re: Predictive failures2Phil Hobbs
16 Apr 24 i  `- Re: Predictive failures1Joe Gwinn
15 Apr 24 +* Re: Predictive failures8Edward Rawde
16 Apr 24 i`* Re: Predictive failures7Don Y
16 Apr 24 i +* Re: Predictive failures4Edward Rawde
16 Apr 24 i i+* Re: Predictive failures2Don Y
16 Apr 24 i ii`- Re: Predictive failures1Edward Rawde
16 Apr 24 i i`- Re: Predictive failures1Martin Brown
17 Apr 24 i `* Re: Predictive failures2Don Y
17 Apr 24 i  `- Re: Predictive failures1Don Y
16 Apr 24 +* Re: Predictive failures7Martin Brown
16 Apr 24 i+- Re: Predictive failures1Don Y
16 Apr 24 i`* Re: Predictive failures5Bill Sloman
16 Apr 24 i `* Re: Predictive failures4Edward Rawde
17 Apr 24 i  `* Re: Predictive failures3Edward Rawde
17 Apr 24 i   `* Re: Predictive failures2John Larkin
17 Apr 24 i    `- Re: Predictive failures1Edward Rawde
16 Apr 24 +* Re: Predictive failures8Don
16 Apr 24 i+* Re: Predictive failures3Edward Rawde
16 Apr 24 ii+- Re: Predictive failures1Don
16 Apr 24 ii`- Re: Predictive failures1Don Y
17 Apr 24 i+* Re: Predictive failures3john larkin
17 Apr 24 ii`* Re: Predictive failures2Don
17 Apr 24 ii `- Re: Predictive failures1Don
17 Apr 24 i`- Re: Predictive failures1Don Y
18 Apr 24 `* Re: Predictive failures7Buzz McCool
19 Apr 24  `* Re: Predictive failures6Don Y
19 Apr 24   +- Re: Predictive failures1Don Y
19 Apr 24   `* Re: Predictive failures4boB
19 Apr 24    `* Re: Predictive failures3Don Y
21 Apr 24     `* Re: Predictive failures2boB
21 Apr 24      `- Re: Predictive failures1Don Y

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal