RSG Model Works

Mobile devices provide value at trade shows.  Having the information available on the show floor can be a great tool to improve your use of precious time on the floor.  Unfortunately, like anything else on your mobile device, it introduces another potential place to be attacked.  And like most mobile apps, it’s actually made by some 3rd party developer you weren’t really aware you were trusting.  We don’t really need 10,000 physical security professionals wandering around a convention center in Dallas bleeding their too-overused favorite passwords onto the public internet.   Read more »

I don’t hate robots. I think that any new technology that tries to show up today has to be built with some by this time fairly obvious cyber defenses. This means, first, that the vendor has to get it that we might care. We the customers have a right to have an expectation of thorough well-tested well thought out technology solutions.

Especially if you’re gonna let that thing drive itself around my shopping mall. Or my parking lot. Or deliver drugs to the other end of my pharmaceuticals facility.

It’s 2017. You want to put a device on my network, operating within my risk responsibility, that’s mobile and at least partially outside my controlled perimeter. With credentials to access my security command center. And you want a purchase order for that?

Yeah, I expect the product to have some cyber awareness. Read more »

It’s mid-2016. XP has been end-of-life for over a year or something. What’s that mean? It means there’s approximately a 100% chance that any given XP system is exploitable. It definitely means the system has exited the vendor’s maintenance window. Either way there are few if any reasons to justify use of XP from a security standpoint.

So when you hear about present-day XP deployments, it’s disturbing. Well before March of 2016 there should be zero XP deployments out there. “Oh, yeah, that’s an old recording appliance. It’s still running XP” is not the kind of thing you should hear at a PACS user group meeting.

After your enterprise has grown up enough to really need electricity all the time, uninterruptable power becomes a necessity.

In the 70’s if you drove through Waltham Massachusetts on Route 128 you could point out the large enterprises.  They all had a Cat diesel engine mounted on cinder blocks behind the building, set up to run a generator.  You’d put it six feet up on cinder blocks, behind the building so that for example a vehicle in the parking lot wouldn’t have a chance to crash into it.  I noticed these because to me a Caterpillar product was a farm tractor sold as far back as the 1930’s (my father sold three rail freight cars full of Cat D-series tractors one season.)  They looked quite silly to me, until I realized the IBM 370’s we were using would crash horribly if those Cats weren’t out in the back yard.

My point is that’s an OLD STORY.  Check out that “one page tsunami plan” news item on the internet.  Look for the AP version here. Check out picture 4 of the TEPCO-released images in the side bar (also below). That’s water gushing into the basement where the dieslel generators for the coastal nuclear power plant were deployed.

Yeah. After the boss buys you a UPS (because you did pass D/R 201), put it somewhere sensible.

We encountered a security video camera failure recently. Check your computer, this post really is being written in 2011. They parked me at an empty table with a test network and a sample of the failing device. Not knowing how to connect to it, a small bit of network investigation was in order. NMAP, the universal source of network knowledge, was invoked. Nothing fancy, mind you. “nmap -sT” and “nmap -sU” is all I ever do. Keep it simple, let the NMAP elves guide me through what ports and protocols to exercise.

The camera crashed. The security video camera crashed with “nmap -sU”. Not some ninja-cool xml-encoded command line exploit magic. Just the vanilla set of UDP ports. Locked up the device, had to power cycle it.

Come on, folks, this is 2011. Crashing due to weird network input is certainly a problem we all have to worry about, but the nmap command to kill your device should be longer than the average Starbucks latte order.

Could I have a tall dry no-fat decaf udp port scan, followed by a sysDescr.0 SNMP query and response, please?