scott_j_f...@yahoo.com (Scott Ford) writes: > Well 1987 wow before the real firewalls. Security was on the inbound/outbound > dial devices. Also worked VM, cut my teeth on VM/SP1 > , loved VM, still do, I can how a exec would cause major pain in a VM system, > no > doubt. z/OS would be a bit tougher I would think, plus a pre-req would be > enough > knowledge to get in and be able to execute, plus passwords and ids...A lot of > research and work ...just to hack a MF
re: http://www.garlic.com/~lynn/2011f.html#23 Fear the Internet, was Cool Things You Can Do in z/OS http://www.garlic.com/~lynn/2011f.html#24 Fear the Internet, was Cool Things You Can Do in z/OS big difference between internal network and the internet in the 80s ... was that all internal network links (that left corporate premise) had to be encrypted. could be a big pain ... especially when links crossed certain national boundaries. in the mid-80s, it was claimed that the internal network had over half of all link encryptors in the world. company also did custem encrypting PC (2400 baud) modems for corporate home terminal program. there is folklore that one high-ranking (EE graduate) executive was setting up his own installation at home. supposedly at one point he stuck his tongue in rj11 jack (to see if their was any juice ... old EE trick) ... just as the phone rang. After that there was a corporate edict that all modems made by the company had to have the jack contacts recessed sufficiently so babies (and executives) couldn't touch them with their tongue. http://en.wikipedia.org/wiki/RJ11 i had an HSDT (high-speed data transport) project and was dealing with T1 links & higher speed. T1 link encryptors were really expensive ... but you could get them ... but I to start work on my own to go significantly faster. misc. past posts mentioning HSDT http://www.garlic.com/~lynn/subnetwork.html#hsdt big difference in worms/viruses (and various other exploits) and social engineering ... is that social engineering requires active participation by the victim (current flavors frequently advertise download & execute things, frequently of very dubious nature; games, videos, etc). allowing users to execute arbitrary (unvetted) programs was identified as vulnerability at least back in the 70s (if not the 60s). somewhat more recent thread (with some of my comments copied from another venue) How is SSL hopelessly broken? Let us count the ways; Blunders expose huge cracks in net's trust foundation http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/ with regard to above .... we had been called in to consult with small client/server startup that wanted to do payment transactions on their server, they had also invented this technology called SSL they wanted to us (the result is now frequently called "electronic commerce"). By the time we were finished with the deployments ... most of the (current) issues were very evident. very early in the process I had coined the term "comfort certificate" ... since the digital certificate actually created more problems than it solved ... in fact, in many cases, it was totally redundant and superfluous ... and existed somewhat as magic "pixie dust" ... lots of old posts mentioning SSL digital certificates: http://www.garlic.com/~lynn/subpubkey.html#sslcert There was two parts of SSL deployment for "electronic commerce" ... between the browser and webserver and between the webserver and the "payment gateway" ... I had absolute authority over interface deployment involving "payment gateway" ... but had only advisory over browser/webserver. There were a number of fundamental assumptions related to SSL for browser/webserver secure deployment ... that were almost immediately violated by merchant webservers (in large part because of the high overhead of SSL cut their throughput by 85-90%). I had mandated mutual authentication for webserver/gateway (implementation didn't exist originally) and by the time deployment was done the use of SSL digital certificates was purely a side-effect of the crypto library being used. the primary use of SSL in the world today is electronic commerce for hiding payment transaction information. The underlying problem is the transaction information is dual-use both authentication and needed by dozens of business processes in millions of of places around the world. In the X9A10 financial working group we (later) directly addressed the dual-use problem with the x9.59 financial standard (directly addressing the problem, x9.59 is significantly lighter weight than SSL as well as KISS). This eliminated the need to hide the transaction details ... also eliminates the threat from majority of data breaches (doesn't eliminate data breaches, just eliminates crooks being able to use the information for fraudulent purposes). Problem (as always) is there is significant vested interests in the current status quo. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
