Mainframe security

[Maxime B]

Hi everyone,

I'm studying in a computer engineering degree program and it's currently my fourth internship in a mainframe environment, which means I currently have 16 months worth of experience. For my degree, I was considering specializing in security because it's something that interests me a lot. I find mainframes also very interesting. That's why I'd like to ally both in my career to come. For my next (and last) internship, the shop I'm currently working for proposed to me a job as a security analyst. It means I'd accompany any development project they have on a mainframe to give them a security solution.

That being said, my question is if people specialized in both mainframe and security are on-demand or if I should consider another career orientation? If so, is there anything else possible to work with both?

Thank you for your time,


Maxime B.

[dick scherrer]

Hello,

I'm not sure how you differentiate "mainframe" and "security" in your question. These, to me are not either/or disciplines.

Every mainframe has security. Not all security is on the mainframe. Win-based systems and *nix systems also have security implementations.

In some organizations, security support is multi-platform. In some, the security support for one platform is not the same people as for another. I suspect that no matter how many platforms there are or what new is provided, there will always be "security work".

I also suspect that the "mainframe" will be around for quite a while longer. It may not be a Blue Box, but the billions of lines of code and the millions of screens/panels will be used for years yet.

Along the same line, there will be the need to support storage management on all platforms as well.

my question is if people specialized in both mainframe and security are on-demand

One of the things that determines "demand" is locale. Different places usually have different demand unless there is something major that affects most organizations involved (i.e. HIPAA or Y2K). The abilit/willingness to relocate can often find more opportunities.

I usually tell people to find somethng they will enjoy as they will do this for the next 20-40 years. In fact i elieve it is better to make a bit less for something one enjoys than to make more $ and dread gong to work each day.

Good Luck

d

[Maxime B]

Well, I know security and mainframe are not the same discipline. English not being my first language, I might not have made myself clear. My question is if it's possible to make a living out of both disciplines at the same time? Is it something I could do for the next 20 or 40 years to come? I know that working in computer security won't be a problem, but I'd also like to keep in touch with a mainframe as much as possible. I also found the world of embedded systems interesting and because I still don't know what to do yet, I'm checking at the pros and cons of eveything. Thus, asking here about both mainframe and security in general.

Anyway, thank you for your reply.

[dick scherrer]

Hello,

You're welcome.

English not being my first language, I might not have made myself clear.

Yup, language is often a challange here at the forum. SOmetimes it takes a couple of iterations, but we eventually get there

My question is if it's possible to make a living out of both disciplines at the same time?

Many people do this - after a fashion. Usually, a person who becomes a security analyst (or whatever the term in the organization) spends most of their time administering security. After working in security a while, some want to go to (or go back to) application development or some other discipline on the mainframe.

Sometimes in smaller organizations, people are required to wear multiple "hats". A securioty analyst may have other duties as there is not enough security work to fill an entire position.

If you were to "do both" how do you see this managed?

If i've not yet understood, have another go and i'll try to catch up

[Maxime B]

For example, a simple task would be, for a series of new batch jobs, to determine if a new userid is required to submit the job, if there's a special treatment with security considerations like frp a dataset, etc. The whole point is determining how it should be done without to actually doing it (like creating the new users or giving the access). I hope it's clearer.