Seems like there is a drift about security and walls.. interesting article I found about walls when reading Cryptograms...
https://warontherocks.com/2018/02/wall-wall-fortresses-fail/ I am interested to see if you get it working for z/OS. Rob Schramm On Tue, Mar 27, 2018 at 12:15 PM Anne & Lynn Wheeler <l...@garlic.com> wrote: > dcrayf...@gmail.com (David Crayford) writes: > > I think the general ROT for those kind of systems is that the network > > defines security. All back-end services should be hidden behind > > firewalls and not accessible to the outside world. It's a different > > world these days where everything seems to run on docker images > > orchestrated by something like kuebernetes and secured by LDAP or > > whatever. Nobody dishes out userids unless you need admin. > > Skip containers and do serverless computing instead; Container > technologies like Docker are very powerful, but require talent you can't > get. Serverless computing provides the same benefits -- with talent you > can actually get > > https://www.infoworld.com/article/3265457/containers/why-serverless-is-the-better-option-than-containers.html > > we had worked with several people at Oracle on cluster scaleup ... part > of getting cluster scaleup being transferred were mainframe DB2 > complaining if I was allowed to continue, it would be at least 5yrs > ahead of them. Over a period of a few weeks, cluster scaleup was > transferred, announced as IBM supercomputer (for technical/scientific > *ONLY*) and we were told we couldn't work on anything with more than > four processors. we leave a few months later. past posts > http://www.garlic.com/~lynn/subtopic.html#hacmp > > not long later, we are brought in as consultants by two of the (former > Oracle) people we had worked with ... who were then at a small > client/server startup responsible for something called commerce server, > the startup had also invented this technology they called "SSL" they > wanted to use, the result is now frequently called "electronic > commerce". > > As webservers got more complex, there was increasing number of > RDBMS-backed servers (compared to flat-file based implementations) that > had significant larger number of exploits. Part of it was RDBMS were > much more complex & corresponding increase in mistakes (along with > rapidly exploding demand for scarce skills). A specific example was they > would disable all outside connections for RDBMS maintenance ... and > during maintenance they would relax various security processes. > Complexity of RDBMS met that increasingly likely they would overrun > maintenance windows, in mad rush to get back online they would > frequently overlook reactivating various security processes. > > more recent > https://en.wikipedia.org/wiki/SQL_injection > > all of these have web application with access ... and attacks are > typically against the web application (where webserver frontends are > also responsible for access control). > > -- > virtualization experience starting Jan1968, online at home since Mar1970 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
