JPMorgan Suffered Exodus of Tech Talent Before Breach by Hackers
bloomberg.com
bloomberg.com
But, the real kicker is at few such firms will you find the tech "talent." They might join mistakenly, but usually they'll get out within a year or two to better pastures at startups or SV. What often remains are the folks that are mainly task masters at CRUD forms, but not anyone that thinks about the merits of various architectures, reads up on optimal coding practices, or that learns in their free time. Nope, those are the high paid "contractors" that are hired when folks can't figure out why a six foot long query is running slowly.
Being in Dallas, I have poked around at openings for some of them. They seem to be the epitome of enterprise HR buzzword bingo.
This is because our IT is diligent and wants to do things correctly and follow standards and practice. But there is no effort to educate the money makers to this effect, they just want results yesterday. So they bitch and wine about IT being a blackhole where requests go to die. And I agree with them in many cases as someone who's sort of midway between these people.
That's a bit demeaning IMO. As with any large corporation, there will be people who stay for years and years just coasting and letting their skills stagnate. However, there are also a lot of people who work hard, learn rapidly, and move around a lot internally instead of changing companies.
They pay a lot for IT. Good hacker can make 300k, but the main problem that big banks have is complexity. Years of M&A, 20 systems that do the same. Simply paying more is not a solution.
Come back when the language you are running on that AIX system is completely dead since before 1990 and there is no online documentation for it. ;)
The problem is the average IBMer will not know how to secure your zOS server. If you ask them how to configure, or how to manage files they'll tell you their aren't any. This is simply amazing double speak because they are, and are not correct. When you first log into this systems you see the old zOS stuff, which looks and feels like MTS system360-67M/70 (its a long story). All your files are data sets, which aren't files, see MTS didn't have files, it had data sets.
But it isn't. Its just a mainframe layer running on AIX. Its called something dumb like encom, unicom, in MTS . That brings you into proper unix mode. Which you may think is running inside MTS, but it isn't. MTS is running inside AIX. Because keeping MTS up to date with modern hardware would be impossible. So we just trick it into thinking its processor is running at the Plank frequency. Not 200 PowerPC chips or what ever IBM shoves in these things today.
Then your in a standard unix environment. If you attack these things from the outside (and get in), you'll see and feel what looks like a BSD/SysV (ish) system. Because that's what it is. Its a unix system.
But nobody configures this crap because the mainframe dudes can just say, "Oh no there are no files on a mainframe, just data sets, they're different." But if I steal a data set in unix mode, its a file. So no, your wrong.
Nobody really goes into Unix mode half the time. They just care about keeping the system360 stuff working. Nobody cares about security because "Its a mainframe, they don't have security issues." Well they do, just like every other unix box on the planet. But unlike every other unix box we pretend they don't need security.
z/OS itself is most certainly not an emulation layer over AIX. It's a complex operating system with 50 years of history behind it.
I look at MTS on a nearly a weekly basis. I want to say z/OS's mainframe OS is based on MTS. I don't know this for sure.
This is how I arrived at this conclusion:
(This is all ancient ~6-8 years Pre-Unix System 1)
See the big draw of of the System360 was Michigan University shoe horned in memory visualization (which allowed for concurrent time shared processing). This was released as the System360-67M (M for Michigan), these things exploded off the shelves. IBM received roughly 100 orders for these systems, not requests to lease time, but cash in hand gimme that.
They rolled out the System360-70 which was just the System360-67M, but under a different name. These are going to ship with TSS/360 (Time Sharing System 360). But ya know it never got done in time, and UofM had already finished MTS. Which did explode.
Also OS/360 was batched based. You couldn't have multi-user, multi-process. Which famously modern System360 emulation can do. So who knows.
I honestly don't know. But I'm 90% sure z/OS is just AIX with MTS in some kind of BSD-esque jail. I think MTS is open-ish sourced. It had a big community up until it was mothballed universally in the mid to late 90's.
:.:.:
I certainly can't afford a z/OS system to sit around and pentest myself :P
:.:.:
Also as I stated nobody configures the security of the underlying unix on IBM mainframes. So they maybe fairly easy to own.
Migrating and/or killing large legacy enterprise applications is monstrously expensive, so the decision makers often decide against it. Relatively speaking, there haven't been enough very large companies that have been burned by that sort of decision, so executives at these companies (and the government) are less likely to see how badly it can go.
Then there's the very real challenge of justifying a big IT spend on retiring legacy applications to the shareholders. And the high chances of large enterprise IT projects going wildly over budget.
As much as we like to point the finger at the c-suite guys who keep doubling down on technical debt until there's a disaster, it's not an easy to make the case for paying to fix the problem. At least not until there are plenty of negative case studies out there like this one.
I was at one large financial company similar to JPMo and every time the development team came up with a good idea, it was met with a laundry list of requirements we had to meet in order to show positive ROI over a very short time period. Not sure if they did to discourage us from trying to help processes and development, or they really believed redesigning some parts of their network architecture could be done in a month or two.
Either way, it was quite frustrating to say the least, and after a few gallant attempts to get something going, most of the younger developers just opted out and left. I saw the writing on the wall and was in the second wave of people who finally gave up and moved on.
I worked there for half a year before quitting and going back to a start up. Nice people but only the people at the top seem to have a clue as to what to fix and they, themselves, can only focus on so many things at once.
Unions are obviously one solution but can be wrought with other issues. Besides that, it seems there really is no solution to wage stagnation outside of major failures or security breaches which hit the business' pockets directly.
I don't just mean in IT but it does seem to be an area where salary growth doesn't match up _at all_ with the amount of value it adds to a business, especially in the case of IT within a non-IT company.
[1]http://online.wsj.com/news/articles/SB1000142405270230402680...
For instance, I think house construction is overpriced because I think "what's so hard about putting up walls around some ground?". The answer is everything is hard about it. But that it is hard is incidental. By that I mean, it was harder before, and now it is easier, and it should get even easier (there are 3D printers printing houses now) and therefore cheaper.
A non-programmer thinks the same way about software as I do about houses: "what's so hard about telling the computer to do grab this data and transform it?". Well, all of it is hard, but again, it's incidental. It would have been more expensive in the past because it was harder, and it will be easier in the future (Docker, NixOS, mathematically proven programs that do not require maintenance, etc).
It's nice being a programmer today but we won't ride this forever. As we automate ourselves out of the market, it will be a net benefit to everyone (as no one will have to program as hard or as much as today).
On the other hand, something that hasn't changed in 40 years is that end users are not able to precisely explain what they want. That is why we will always have jobs. There will always be some sort of exceptional rule.
Complexity expands so as to fill our current mental capacity.
Each level of abstraction divides the cost per feature and so multiplies the sum of total complexity.
Sysadmins/"IT people" are probably seen as janitorial.
http://www.theregister.co.uk/2012/06/28/rbs_job_cuts_and_off...
Working most of my life in financial services, executives dont have intimate knowledge unless the systems in place happen to be the same ones they helped build 10-15 years ago (which is true in some cases).
I still consider myself hands on, although not cutting code on a daily basis, and I dont have intimate knowledge of those systems. They will still phone me at 2am despite that.
After a little longer, the underlying infrastructure (OS and native libraries), platform (java, node, ruby, etc...) and persistence (Oracle, MySQL, MongoDB, you get the idea...) starts to become vulnerable to zero-day exploits and you get one of these big breaches. Maybe I'm just being cynical ;)
It's sort of like the old rusty ship that finally sinks. It happens all the time...
The departures meant that executives with intimate knowledge of JPMorgan’s systems... were gone"
Yeah, um, worked there. At least in my line of business and those others I was exposed to, losing the executives may have been beneficial in terms of knowledge because it's possible that the newcomers would try to learn the stuff that the departees never bothered to know in the first place.