6 ms·

There are lot of interesting technologies that we should pay attention to from mainframes particularly in managing distributed processes, interesting IO and acc

by bbatha 7y ago

There are lot of interesting technologies that we should pay attention to from mainframes particularly in managing distributed processes, interesting IO and accelerator configurations, etc. But this article seriously misses the mark and makes some bad arguments that show this person hasn't really administered a non-mainframe server in the last decade or so. He's also an "IBM Gold Consultant" we should take this with a huge grain of salt. > It should not be an acceptable practice to just insert a CD and indiscriminately install software onto a production machine. This assumes your machine is set up correctly. I've worked on some mainframes where everyone could access customer data and swap out production executable freely. Why? Because no engineer wanted to deal with 6 layers of bureaucracy to debug an issue or update a library. Segmenting the data and isolating specific infrastructure has proven out to be more efficient and more secure. > Nor should it be acceptable to just flip the switch and reboot the server. These are more about the fact that there is one mainframe. The reality is for distributed systems that anyone can flip the switch at any time and you better plan for that up front. Its a good thing that I can restart my laptop, or production servers whenever I need for updates, and don't need to do 6 months of business continuity planning for "update day". > In mainframe shops there is an entire group of people in the operations department responsible for protecting and securing mainframe systems, applications, and data. As does any non-negligent mid-sized organization. Having a security team is very standard at this point. > Ever wonder why there are no mainframe viruses? Because no hacker can afford to have an IBM mainframe running in their garage? > There is even a term – the accidental DBA – that has been coined in the SQL Server world for developers who become the DBA because nobody else is doing it. Such a situation is unheard of in the mainframe world – indeed, you’d be laughed at if you even suggested it! Great now I need to hire extra people to specifically administer my very expensive database deployments instead of relying on a cloud provided database and relying on general "DevOps" people to have enough knowledge to troubleshoot some specific problems. The DBA didn't go away for no reason, they've just largely outlived their economic usefulness.

technion 7y ago
Regarding the "insert a CD and install software" statement, as someone who hasn't worked on this sort of environment I've always wondered - I have multiple test machines running Windows and Linux. I can push software to a canary installation on an identical server to production. Yes, I can do so indiscriminately, but by the time I push canary to production it's had a certain level of testing. I knew a mainframe engineer and he certainly didn't have multiple spare mainframes laying around to play with. There might have been some form of partitioned install they called "test" but by the time people bureaucracy gets involved noone is "playing with it" and ergo, there's a lot less actual experts involved. Bonus question: Was there never a firmware bug that would take down an entire mainframe? A certain server line was advertised with "mainframe like redundancy" on Windows, yet that's exactly my experience.
- nijave 7y ago
  For test systems, you can create LPARs on IBM z mainframes. I don't have much mainframe experience but I know they have access to test systems and development systems Not sure about bugs, but I suspect mainframes have fairly redundant software with enough hardware and software to handle unknown bugs.
  - neverartful 7y ago
    Or VMs (guests) in z/VM. The guest OS can be linux, CMS, z/OS, z/VM (2nd level), etc.
    - rbanffy 7y ago
      I believe you can stack z/VM as deep as you like. Current x86s can do that too, AFAIK.
- southern_cross 7y ago
  > Was there never a firmware bug that would take down an entire mainframe? Yes, there was quite an ugly one not that long ago in fact. A local mega-corporation which still has some mainframes had its main (and redundant) systems just roll over and die suddenly, plus their hot backup systems which were offsite. I don't remember all of the details, but IIRC this was a case of "We [the vendor] knew we had a major bug, and we had a fix for it, but we were remiss about getting it out to all of our customers in a timely manner." This type of thing is shockingly rare in the mainframe world, though.
rsj_hn 7y ago
I am skeptical of the claims of superior mainframe security. 1. The IT Security Profession is young, in many ways, it's still in its infancy. I say this because today you can still get a B.S. in Computer Science without being taught secure coding best practices or having that be integrated into the curriculum. So given that the state of the art is young, and yet mainframes are quite old and have a reputation of being slow to change, how could they possibly keep up with best practices? 2. The mainframe world tends to be highly proprietary, even with proprietary protocols. I am skeptical that they adopted appropriate information sharing and training mechanisms, and how can they recruit security talent when access to the system is so closed? How would we even know of attacks if they are kept secret and not reported?
- rbanffy 7y ago
  Security through obscurity should never be your only line of defense, but it's a good thing to layer upon the other defenses. Hercules is a great teaching tool, but it will limit the kind of exploits you can develop (the most interesting being hardware based ones anyway). On top of that, mainframes are very observable machines. Because a lot of companies rented out extra capacity and billed it by usage (70's AWS), everything is audited, logged, measured, traced and, unless the intrusion went really deep, you'll have detailed information on how it happened. There is a course I never took ("Hack the mainframe") by a couple nice folks I know from Twitter that teaches a lot about vulnerabilities in default settings and how to secure mainframe based services.
- DrScump 7y ago
  Mainframe security (or mainframe era security) was stronger simply because of access. Introducing media required access to a connected peripheral and console (or TSO, at least) access, both of which were probably in a secure, raised-floor computer center. You couldn't rely on leaving a tape sitting on a bench and expect an operator to just load it, a la Stuxnet.
- southern_cross 7y ago
  Having spent my entire career with one foot on the "legacy" side of things (mainframe-like systems) and the other on the Wintel side, I can tell you that I've had to deal with any number of problems on the Wintel side that generally just wouldn't happen - and indeed in many cases couldn't happen - on the legacy side. As an example of how things are done on the legacy side, I was once dealing with a piece of Power hardware which could be configured as either a Linux system or an iSeries system. There was a USB port in the hardware which was enabled on Linux systems but disabled on iSeries systems, and AFAIK it couldn't be enabled, either. This puzzled me at first, until I found out how USB ports can be used to attack systems and then it made perfect sense - they had chosen to disable the USB port for security reasons.
skissane 7y ago
> > Ever wonder why there are no mainframe viruses? > Because no hacker can afford to have an IBM mainframe running in their garage? There have been IBM mainframe malware in the past, the most famous incident being https://en.wikipedia.org/wiki/Christmas_Tree_EXEC https://en.wikipedia.org/wiki/Christmas_Tree_EXEC If an attacker wants to learn to attack IBM mainframes, they don't need a mainframe in their garage. Using the open source Hercules emulator, you can run IBM mainframe operating systems emulated on x86. Legally, you can only run really old versions, but piracy of newer versions is widespread. (IBM will sell you a legitimate way to emulate newer versions on x86 for a few thousand dollars annual subscription - but we can assume an attacker isn't going to be bothered with obeying copyright laws.) Security through obscurity is a bad practice, but sometimes it really works. Exotic platforms tend not to get much malware, not because they lack security vulnerabilities, but simply because knowledge of how they work (and in many cases, even opportunity to acquire that knowledge) is rare.
- bin0 7y ago
  > Security through obscurity is a bad practice, but sometimes it really works. Exotic platforms tend not to get much malware, not because they lack security vulnerabilities, but simply because knowledge of how they work (and in many cases, even opportunity to acquire that knowledge) is rare. More importantly, the return per hour spent to write that malware is lower. There are fewer macs, though knowledge is widespread, so there are more windows viruses because there is a larger pool of victims.
zzzcpan 7y ago
> from mainframes particularly in managing distributed processes None of it works for actual distributed systems.
C1sc0cat 7y ago
I would take Our Accidental DBA at BT instead of the actual DBA team :-) they where the design Guru for an entire engineering centre. He once mentioned in the pub at lunch that "oh my first boss was Diskaja".

by bbatha 7y ago

technion 7y ago

Regarding the "insert a CD and install software" statement, as someone who hasn't worked on this sort of environment I've always wondered - I have multiple test machines running Windows and Linux. I can push software to a canary installation on an identical server to production. Yes, I can do so indiscriminately, but by the time I push canary to production it's had a certain level of testing. I knew a mainframe engineer and he certainly didn't have multiple spare mainframes laying around to play with. There might have been some form of partitioned install they called "test" but by the time people bureaucracy gets involved noone is "playing with it" and ergo, there's a lot less actual experts involved. Bonus question: Was there never a firmware bug that would take down an entire mainframe? A certain server line was advertised with "mainframe like redundancy" on Windows, yet that's exactly my experience.

nijave 7y ago
For test systems, you can create LPARs on IBM z mainframes. I don't have much mainframe experience but I know they have access to test systems and development systems Not sure about bugs, but I suspect mainframes have fairly redundant software with enough hardware and software to handle unknown bugs.
- neverartful 7y ago
  Or VMs (guests) in z/VM. The guest OS can be linux, CMS, z/OS, z/VM (2nd level), etc.
  - rbanffy 7y ago
    I believe you can stack z/VM as deep as you like. Current x86s can do that too, AFAIK.
southern_cross 7y ago
> Was there never a firmware bug that would take down an entire mainframe? Yes, there was quite an ugly one not that long ago in fact. A local mega-corporation which still has some mainframes had its main (and redundant) systems just roll over and die suddenly, plus their hot backup systems which were offsite. I don't remember all of the details, but IIRC this was a case of "We [the vendor] knew we had a major bug, and we had a fix for it, but we were remiss about getting it out to all of our customers in a timely manner." This type of thing is shockingly rare in the mainframe world, though.

rsj_hn 7y ago

I am skeptical of the claims of superior mainframe security. 1. The IT Security Profession is young, in many ways, it's still in its infancy. I say this because today you can still get a B.S. in Computer Science without being taught secure coding best practices or having that be integrated into the curriculum. So given that the state of the art is young, and yet mainframes are quite old and have a reputation of being slow to change, how could they possibly keep up with best practices? 2. The mainframe world tends to be highly proprietary, even with proprietary protocols. I am skeptical that they adopted appropriate information sharing and training mechanisms, and how can they recruit security talent when access to the system is so closed? How would we even know of attacks if they are kept secret and not reported?

rbanffy 7y ago
Security through obscurity should never be your only line of defense, but it's a good thing to layer upon the other defenses. Hercules is a great teaching tool, but it will limit the kind of exploits you can develop (the most interesting being hardware based ones anyway). On top of that, mainframes are very observable machines. Because a lot of companies rented out extra capacity and billed it by usage (70's AWS), everything is audited, logged, measured, traced and, unless the intrusion went really deep, you'll have detailed information on how it happened. There is a course I never took ("Hack the mainframe") by a couple nice folks I know from Twitter that teaches a lot about vulnerabilities in default settings and how to secure mainframe based services.
DrScump 7y ago
Mainframe security (or mainframe era security) was stronger simply because of access. Introducing media required access to a connected peripheral and console (or TSO, at least) access, both of which were probably in a secure, raised-floor computer center. You couldn't rely on leaving a tape sitting on a bench and expect an operator to just load it, a la Stuxnet.
southern_cross 7y ago
Having spent my entire career with one foot on the "legacy" side of things (mainframe-like systems) and the other on the Wintel side, I can tell you that I've had to deal with any number of problems on the Wintel side that generally just wouldn't happen - and indeed in many cases couldn't happen - on the legacy side. As an example of how things are done on the legacy side, I was once dealing with a piece of Power hardware which could be configured as either a Linux system or an iSeries system. There was a USB port in the hardware which was enabled on Linux systems but disabled on iSeries systems, and AFAIK it couldn't be enabled, either. This puzzled me at first, until I found out how USB ports can be used to attack systems and then it made perfect sense - they had chosen to disable the USB port for security reasons.

skissane 7y ago

> > Ever wonder why there are no mainframe viruses? > Because no hacker can afford to have an IBM mainframe running in their garage? There have been IBM mainframe malware in the past, the most famous incident being https://en.wikipedia.org/wiki/Christmas_Tree_EXEC https://en.wikipedia.org/wiki/Christmas_Tree_EXEC If an attacker wants to learn to attack IBM mainframes, they don't need a mainframe in their garage. Using the open source Hercules emulator, you can run IBM mainframe operating systems emulated on x86. Legally, you can only run really old versions, but piracy of newer versions is widespread. (IBM will sell you a legitimate way to emulate newer versions on x86 for a few thousand dollars annual subscription - but we can assume an attacker isn't going to be bothered with obeying copyright laws.) Security through obscurity is a bad practice, but sometimes it really works. Exotic platforms tend not to get much malware, not because they lack security vulnerabilities, but simply because knowledge of how they work (and in many cases, even opportunity to acquire that knowledge) is rare.

bin0 7y ago
> Security through obscurity is a bad practice, but sometimes it really works. Exotic platforms tend not to get much malware, not because they lack security vulnerabilities, but simply because knowledge of how they work (and in many cases, even opportunity to acquire that knowledge) is rare. More importantly, the return per hour spent to write that malware is lower. There are fewer macs, though knowledge is widespread, so there are more windows viruses because there is a larger pool of victims.

zzzcpan 7y ago

> from mainframes particularly in managing distributed processes None of it works for actual distributed systems.

C1sc0cat 7y ago

I would take Our Accidental DBA at BT instead of the actual DBA team :-) they where the design Guru for an entire engineering centre. He once mentioned in the pub at lunch that "oh my first boss was Diskaja".