The Good (secure) Old Days

[LaurieAG]

There are probably a couple of members of this forum who might remember seeing 8" floppies and drives so the following link might be of interest.

 

http://arstechnica.com/information-technology/2014/04/60-minutes-shocked-to-find-8-inch-floppies-drive-nuclear-deterrent/

 

 

“A few years ago we did a complete analysis of our entire network,” Weinstein said. “Cyber engineers found out that the system is extremely safe and extremely secure in the way it's developed.”

 

I worked in a communications design office and wrote pc LAN based multi user software (Kman/2) in 1987 and cannot remember any security issues or viruses from 1987 until 1990. Of course we had the usual problems with engineers formatting their hard drives and on another floor in the office building one disgruntled employee locked 35 pc's and hid the keys on a paperclip hanging off an air conditioning vent (no work on that floor until somebody noticed the keys 3 hours later).

 

By 1991 I scanned the uni's server lab pc's (all server spec) for root viruses before I started doing anything and by 2004 the in network security joke was that the only safe pc was one in its original packaging that was also locked inside a secure area with the power cord removed. 

 

Last week my mobile broadband usb received a sms message from a certain General John Alonso, with a "us.com" email address, wanting to do $ 8.3 million worth of business, where will it all end!

 

https://isc.sans.edu/forums/diary/Coin+Mining+DVRs+A+compromise+from+start+to+finish/18071

Edited May 8, 2014 by LaurieAG

[Buffy]

The old days were never secure, just more secure because you needed a "SneakerNet" to get the viruses on a target.

 

The biggest problem is that cybercrime is not seen as a national security threat. While the virus writers and anti-virus vendors engage in escalatio on each other (under accusations that they actually cooperate to keep the money flowing: looking at you Kaspersky), the NSA and DoD have the resources to attack and shut down the mechanisms of delivery (mostly spam) that get the viruses to the victims, yet they don't lift a finger.

 

Freedumb I guess.

 

Read a blog post today about how the anti-virus companies are even at the point where they're looking for completely different things to do because of the stalemate in virus distribution that seems to always guarantee that a bunch gets through via "zero-day" exploits. We're definitely at a point where the landscape is changing, so it continues to be an interesting topic.

 

 

Treat your password like your toothbrush. Don't let anybody else use it, and get a new one every six months, :phones:

Buffy

[arissa]

Things have sure changes over the years. I think back now and wonder if my kids are ever going to understand half of the things I tell them in regards to technology. Then I wonder how much of it will be their homework for "history". I took the liberty of censoring this since I am not sure what age limit is set for this board. Thinking about 8" floppies makes me wonder if that would be considered "ancient history".

[CraigD]

https://isc.sans.edu/forums/diary/Coin+Mining+DVRs+A+compromise+from+start+to+finish/18071

Though the image of vast zombie farms of internet thing boxes cryptographically churning out vast wealth for those cunning enough to pull off such exploits is pretty cool in a shady way, the exploit this article describes appears from the little reading I did on it to be effective only on a specific box the Hikvision S04 DVR. It give one pause to think that, if the love of money is the root of all evil, is the love of money not issued by a national government any less evil root-y?

 

http://arstechnica.com/information-technology/2014/04/60-minutes-shocked-to-find-8-inch-floppies-drive-nuclear-deterrent/

I’m not surprised to read articles like this about very high-security systems running very old software on very old hardware. Situations like this are usually, I think, an application of the old “if it ain’t broke, don’t fix it” adage.

 

Though I don’t know the details (and, like most folk, are unlikely to, as the system in this case is a top secret one involved in launching nuclear missles!), I’m confident the engineers Jack Weinstein quotes as saying the system is “extremely safe and extremely secure” are correct. That security owes less, I think, to physical security – data transfer only via sneakernet, those sneakers being on the feet especially trusted “missilemen” – than to the smallness (understand this to be a special term I’ve assigned to a concept I just now invented – not that others haven’t long ago and better, but that I’m not familiar with such prior concepts) of these systems. That smallness is due to their age.

 

The smallness of a computer system isn’t a measure of its hardware’s mass, volume, processing speed, amount of high-speed memory, non-volatile storage, or executable code, but of its architecture, the number of and number of kinds of processes (jobs, threads, or whatever term you prefer) running on them, and, most critically, and most critically (I could arguably define it by this last measure alone) the number of humans required to know effectively everything about the system (for short, all call such a person a programmer). For some old computers, it’s not unusual for programmers of such machines to know effectively everything (or to quickly be able to discover anything, which is practically equivalent to knowing everything) about the programs they run. The numeric measure of their smallness is 1, as small as can be and still exist. The integrity of such systems is the same as the integrity of their programmers (notice the plural – it’s not necessary that only 1 programmer know the system, only that one programmer knows the entire system). They lack “hiding places” for malware.

 

Unless a small computer system interacts only with a small outside world – say just a single or a few trusted users via a single interfaces such as keyboards and screens – it’s not necessarily or even likely very secure, because the encryption programs it uses to get its data to and from trusted users and other systems in the big outside world are likely weak, having been written by their single programmer. If that programmer followed best cryptographic standards and practices, the small system is secure in the big world – otherwise, at best it depends on “security through obscurity”, a kind of security that’s effective only if intruders are unwilling to put much effort into breaking it, and a violation of Kerckhoffs's principle, a 131 year-old idea sacred to, and arguably inaugurating, modern cryptography.

 

Being an aging (54 years old, which some days feels decidedly over the hill) programmer acutely aware of how slow programming via a “know everything” (AKA procedural, contrast with object-oriented) style can be, I realize that simple, strict smallness as I’ve described it isn’t a viable approach to improving security, except in the cases of small world system (such as embedded systems, those reliable systems we trust to make our cars, ovens, etc. work). I fervently believe, though, that a richer application of the concept is.

 

The first rule of this complexified smallness approach (as I’ll audaciously lay it out) is run almost nothing other than human-readable procedural code with a small command set via an interpreter.

[LaurieAG]

Hi CraigD, I tend to agree with your principles of complexified smallness and I'd like to see the other rules.

 

The SANS link was only preliminary research and the standard hack evolution is to, over time, consolidate an entire range of attack exploits into the one package so that multiple deficiencies can be targeted in one go. Also, most of the DoD's software from the late 70's to the late 90's was written in ADA which was originally written to circumvent many of our current problems. It was initially targeted for embedded and real time systems and has had OOP support since 1995. http://en.wikipedia.org/wiki/Ada_(programming_language)

 

Another complexified smallness rule would require that if a correct answer can be obtained from the application of logic and currently available information 100 % of the time then no user input should be allowed. 

[Buffy]

Ada is a wonderful language in general, however the reason it prevents those "current problems" is the way that the compiler produces code that is self-checking. Microsoft long ago put in compiler features for its C/C++ compiler that did bounds checking code on arrays, originally just to aid in debugging, but that's the ticket for catching buffer overrun exploits as well. Unfortunately the default has always been to turn it off in the "Production" compile configuration for performance reasons, thus eliminating that benefit if you don't know what you're doing....

 

 

One essential object is to choose that arrangement which shall tend to reduce to a minimum the time necessary for completing the calculation, :phones:

Buffy

[LaurieAG]

Ada is a wonderful language in general, however the reason it prevents those "current problems" is the way that the compiler produces code that is self-checking. Microsoft long ago put in compiler features for its C/C++ compiler that did bounds checking code on arrays, originally just to aid in debugging, but that's the ticket for catching buffer overrun exploits as well. Unfortunately the default has always been to turn it off in the "Production" compile configuration for performance reasons, thus eliminating that benefit if you don't know what you're doing....

 

Hi Buffy,

 

Ada was based on the pascal programming language and (Borland) turbo pascal was the first compiler I ever purchased.

 

I suppose that's one down side of the modern, we only want experience with the last 5% (knowledge of the latest whiz bang language/development environment) and don't really care about the other 95% (good programming techniques and broad practical experience etc) methods employed by many companies/contractors today.

 

Many of these problems (buffer overruns) don't exist if you do the coding or check/test properly.