Jim > I will spare all who have been reading all the history of this on IBMMAIN about my strong recommendation for those running SNA networks to strongly consider the need for a "SNA Firewall".
Which means you haven't spared us at all! I recognise a "trick" to which I succumb myself when the occasion demands it! > Native SNA with VTAM no matter how it is configured in the eyes of even those who do it well, does not meet US Government security mandates. FUD piled upon FUD. Prove it - perhaps with just one of those famous "20+" ways and now the proof will need to include some sort of reference to the violated "US Government security mandate". > There are all too few people who even understand VTAM any more to make a good attempt at it. So it's less expensive to purchase the "SNA firewall" product than to train staff to understand the existing products for which they are responsible? And what about training staff to understand the "SNA firewall" product so that it can be used effectively? > Hopefully those who are skeptical will do independent research, consult with really smart people in the know and make a decision as to whether it is wise move to bullet proof your SNA network. I have no argument with getting in a consultant to review the use of the products providing SNA connectivity, just about inevitably bound up with products - even the same product if we are dealing with z/OS Communications Server - providing IP connectivity. I would suggest that - as you should hire a genuinely independent financial advisor when asking about insurance - you hire a consultant who has no connection with the marketing of products which might be on offer. All this to happen *after* you have ensured that the existing in-house expertise is fully developed in what can be achieved with the products for which you are already paying. > I made my replies back in January 2009 in IBM items 97253 and 97522. No one has contacted me further for specific information (which I remember - am a very old guy and maybe it slipped by me). Why should they? They have all been waiting for an explanation of those famous "20+" ways! > My intention was to alert people to the 1+ years of investigation, skepticism, and proof others were accessing my SNA network and not having a clue how it could be happening. "Alerting people" and spreading FUD are two sides of the same coin. Without some proof of what may well be inaccurate suggestions, the "alerting" is at best unreliable. > The interconnection of SNA networks to a trading partner also means you very, very likely connected to their interconnections, etc. Of course, you are. And VTAM development understood and understands this and, from the dawn of SNI, provided the definition possibilities to deal with just allowing the intended sessions to be possible between enterprises interconnected with SNI. Moreover, just gaining knowledge, possibly useful to a competitor, of the adjacent *configuration* is specifically prevented by the popular "back-to-back" structure - and - if specified, is blocked by definitions within NetView Session Monitor, originally Network Logical Data Manager (NLDM). As I demonstrated in answer to your post in the thread "Mainframe Hacking", where you tried most recently to push the supposed need for an "SNA firewall", from what you described, what you needed was provided by VTAM and was described in this thread back in January. > I do not have the time and expertise to take up a skeptical world to prove this is true. Given what this implies it might be better if you had not taken up this topic in the first place - and you've done it twice! And how do you justify "Right now I understand there are 20+ ways which VTAM/SNA systems have been compromised" if you can't explain what they are? > That is why I have sought out very smart people who specialize in areas. Google can be a great starter using "SNA FIREWALL APPN" ... I just tried. For some reason Google isn't very good at including "APPN" in the search which is a bit frustrating. When I finally got to posts that didn't say something like "I don't know SNA security very well", I found that I was dealing with marketing pages for products, the very thing I am trying to avoid! For interest I added the search word "CDINIT" since often the imagined problems involve searching and a "technical" word should limit the search to "technical" items. The pickings were now much slimmer, just 60 and you need to "repeat the search with the omitted results included", otherwise it's less than 20. They include these posts, of course, and SHARE presentations from IBMers. Come on, that "20+" is quite specific, you must have got that number from somewhere other than going through "2 million+" Google hits! > ... and one should never take the word of someone on IBMMAIN without doing their homework. Agreement at last, and, in this case, start with understanding how to use the products you already have. Chris Mason On Mon, 10 Aug 2009 06:35:16 -0500, Jim Marshall <jim.marsh...@opm.gov> wrote: >> >>I believe Jim Marshall is just trying to dismiss a fact inconvenient for the >>product he is promoting? FUD! See previous comments from the Chris Mason >> >> >I will spare all who have been reading all the history of this on IBMMAIN about >my strong recommendation for those running SNA networks to strongly >consider the need for a "SNA Firewall". Native SNA with VTAM no matter how >it is configured in the eyes of even those who do it well, does not meet US >Government security mandates. There are all too few people who even >understand VTAM any more to make a good attempt at it. > >Hopefully those who are skeptical will do independent research, consult with >really smart people in the know and make a decision as to whether it is wise >move to bullet proof your SNA network. I made my replies back in January >2009 in IBM items 97253 and 97522. No one has contacted me further for >specific information (which I remember - am a very old guy and maybe it >slipped by me). My intention was to alert people to the 1+ years of >investigation, skepticism, and proof others were accessing my SNA network >and not having a clue how it could be happening. The interconnection of SNA >networks to a trading partner also means you very, very likely connected to >their interconnections, etc. I do not have the time and expertise to take up a >skeptical world to prove this is true. That is why I have sought out very smart >people who specialize in areas. Google can be a great starter using "SNA >FIREWALL APPN" and one should never take the word of someone on IBMMAIN >without doing their homework. > >I do very much agree with agree I am indeed spreading FUD, as stated in >January. Oh yes, most people on IBMMAIN take great pains not to promote >products and to inspire our younger brethren to do their own research. > >F - Fear and indeed there is, AND STILL SHOULD BE IN THE FUTURE >U - Uncertainty no more >D - Doubt is doubt no more ALTHOUGH WILL LINGER WITH MANY forever > >Your mileage may vary. jim ---------------------------------------------------------------------- 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
