Predictive failures

Another hazard/failure mode happens when things like opamps use pos and neg supply rails. A positive regulator, for example, can latch up if its output is pulled negative, though ground, at startup. Brownout dippies can trigger that too.

Add schottky diodes to ground.

Yeah.

Not quite as dramatic, but in the last year I have been involved in some full-scale vibration tests, where a relay rack packed full of equipment is shaken and resulting phase noise is measured. People are afraid to touch the vibrating equipment., but I tell people to put a hand on a convenient place.

It's amazing how much one can tell by feel. There is some low-frequency spectral analysis capability there, and one can detect for instance a resonance. It's a very good cross-check on the fancy instrumentation.

Joe Gwinn

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.

....

I'm surprised you get anything done with all the tickle processes you must need before anything works.

Sounds like you are the the only user of your devices. 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. 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.

But only for your situation. If I advised a small business to run like that they'd get someone else to do it.

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." 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?

I've seen many a circuit with pos and neg supply rails for op amps when a single rail would have been fine. In one case the output went negative during startup and the following device (a VCO) didn't like that and refused to start. A series diode was the easiest solution in that case.

So let's take a step back before the posts get so big that my newsreader crashes.

All networks are different. All businesses have different online/offline needs. All businesses have different processes and device needs. All businesses have different people with different ideas about how their network and devices should be secured. Businesses which design or manufacture technology may have different requirements when compared with businesses who just use it. People find security inconvenient. "Don't give your password to anyone else" is likely to fall on deaf ears.

There is no one-size-fits-all cybersecurity solution. Any solution requires a detailed analysis of the network, the devices, and how the people and/or their guests use it.

Few people know what is going in/out of the connection to their Internet provider. Few people care until it's too late.

Human behaviour is a major factor.

I had one manager do the equivalent of bursting into the operating theatre while the heart surgeon was busy with a delicate and complicated operation. He wanted to know all the details of the operation and why this part was connected to that part etc. It turned out that his reasoning was that after getting this information he could do it himself instead of paying "cybersecurity" people.

Unskilled and unaware of it comes to mind. Search engine it if you need to.

This reminded me of some past efforts in this area. It was never demonstrated to me (given ample opportunity) that this technology actually worked on intermittently failing hardware I had, so be cautious in applying it in any future endeavors.

RAID, even with backups, is unsuited to high reliability storage of large databases. Distributed storage can be of much higher reliability:

This requires successful retrieval of any n of m data files, normally from different locations, where n can be arbitrarily smaller than m depending on your needs. Overkill for small databases but required for high reliability storage of very large databases.

The problem I have with troubleshooting intermittent failures is that they are only intermittend sometimes.

Yes, neat paper.

boB

Yes, it may be hard to replicate but you just have to try and try again sometimes. Or create something that exercises the unit or software to make it happen and automatically catch it in the act.

I don't care to have to do that very often. When I do, I just try to make it a challenge.

boB