Right now, I work in software QA. been doing it for a while, and am a manager/ lead at times.
I am good at what I do, but too much of it is being outsourced, and there are to many managers that have never done the job asking for or promising stuff that can't be done.
But it pays me pretty well right now.

Changing careers this late means a pretty big pay cut. But cyber security clearly is the next big thing.

In qa I started at min wage and worked my way up to six figures after 17 years.
I can aford the pay cut for a while, but only for 4 or 5 years. Is that unrealistic?

I know right now when I will be working overtime(exempt of course) due to the release calendars. But it sounds like shift work for the security guys? weekends and holidays maned or on call?

I have my sec +, network +. I have configured servers port lock downs as well as services running/exposed, firewalls and SSL boxes as part of my testing work. I didn't design the configurations, but rather pulled them from DOD best practices at the time.

There must be more to it than that, and it seems specilzation as there seem to be pen testers and ethical hacking vs the guys that do the configs.

Just curious if this is a good path, or am I dreaming?

Security is a great field to be in if you get in with a company that actually values security.  Unfortunately, there are still a significant number of companies out there that are not very interested in it and/or protecting themselves.  It can be incredibly frustrating to work for one of those types and you really have accept the mantra that it will take a breach for them to learn.  If you believe all of the industry reports, there is a negative employment rate in this field meaning there are more vacancies than qualified people.  I tend to believe that based on the interviews I've conducted when trying to hire folks.  There is a substantial difference in candidates who are truly "security folks" versus those that have dabbled with the theories.  

As with all IT realms, there are many different concentrations within the greater "security" umbrella.  Everything from penetration testing to web security assessments to infrastructure and architecture to incident response and forensics to risk and policy.  You have to decide what is most interesting to you and start walking down that path.  Personally, do mostly hands-on stuff and avoid as much of the policy mess as I can because it bores me.  My role requires me to know infrastructure (servers, storage, virtualization, databases), networking (route/switch, firewalls), a bit of programming (web application assessments), etc. which has required years of experience with each of them.  You would not be successful in my type of position without being in the technology field for a while and having been able to touch all of these varying technologies.

You will work longer hours in the "operational" and incident response / forensics concentrations than the others; and more than any other IT groups it seems at times.

Thanks for the reply.

How is security different from general IT?
I mean setting up a server and the ports blocked and web services to not start automatically is pretty much either general proceedure or built into the image.

Is there something you check if you aren't part of the after action teams?
or are you testing to make sure the IT guys did it right on each server?

I have done a security test contest before, but that mainly was IT work trying to get systems up and running again and pulling logs to see what was going on and how to lock it down further.

There's no way to accurately answer your question on how security compares to general IT because it varies from company to company.  The spectrum encompasses everything from it being the responsibility of one guy (along with everything else) to having multi-person teams responsible for specific realms within the greater security construct; e.g., ID/PS teams, firewall teams, DLP teams, eDiscovery and forensics teams, etc. ad nauseam.   I'd say the general rule is that the larger company, the larger the disbursement of teams and personnel.  As part of that, you could expect to be more "hands-on" across more technologies with smaller teams and organizations than with the larger companies; again, it varies from company to company.

My department is not as diluted as other large organizations and we have collapsed many areas into an "Engineering and Architecture" group but we do have several other more focused teams.  Our E&A group is focused on managing and supporting the Security team's infrastructure, providing overall enterprise architectural guidance, active defense technology control (firewalls, ID/PS, web security appliances, etc.), control certification and verification, and project consultation.  It works for us because our overall IT group is security-focused and have adopted the "security is everyone's responsibility" mantra; our CIO made sure of that.  Other organizations may not have that mentality thus creating a scenario where Security has to hover over the other administrators dictating how and when to turn knobs and pull levers; if they have that ability.  I've seen many companies where the security group has no "teeth" whatsoever and is there purely as a token.

There are comparably-sized companies right down the road from us who have the diluted model I mentioned above.  Based on their business model and practices, that works better for them.

Thanks. There is more to this than I thought.

Like any other discipline security has quite a few different aspects to it and security teams from different organizations can vary fairly widely in how they operate. I've seen everything from security that has no technical role and instead focuses on policy and compliance to security that has technical people embedded with IT admin and engineering performing configuration and deployment work.  There are some who focus much more heavily on monitoring and auditing.  Most tend to perform a combination of such operational roles in varying degrees.

Bottom line, depending on where you get a position you could be doing something very different than what you had in your mind as the role of information security.



Not quite sure what you are asking with this one.



You shouldn't be.  I've never really seen anything like a server by server check to make sure it was configured properly.  Generally speaking, organizations have best-practices/policies and procedures that dictate configuration details as far as basic server-level security goes.  In medium to large organizations that process is automated to a very high degree.  Security is more likely to be reviewing the best-practices and policies on a regular basis and updating configurations if there are changes that justify it.


Again, depending on position and organization, this kind of testing might be a regular part of the job or you might never (or fairly rarely) touch hardware and software to do this kind of lab/test work. You're far more likely to wind up monitoring or doing policy and procedure work. Especially at the lower and entry levels.

Again, depending on position and organization, this kind of testing might be a regular part of the job or you might never (or fairly rarely) touch hardware and software to do this kind of lab/test work. You're far more likely to wind up monitoring or doing policy and procedure work. Especially at the lower and entry levels.

This seems backwards to me.
as entry level, I figured I would do the grunt work of actually setting up and monitoring. Higher level more experienced people would be deciding policy and reveiwing?
or did I misunderstand?

The job ads I have seen make it seem more straight forward, but it may be just the larger companies doing it, so the tasks are very defined, instead of smaller companies where you wear multiple hats.

Sorry, I should have been a little more clear but I am speaking in pretty broad terms and it's easy to obscure some of the more salient details.

At the level that is appropriate to this discussion you are correct.  You would not be deciding policy.  However, you likely would be reviewing existing policy on a regular basis as you monitor for compliance, check configurations, etc.  As far as setting up or configuration you could very well find yourself dealing with security specific systems.  Say, for example, working with infrastructure to deploy agents on servers and workstations and troubleshooting server/agent configurations if your monitoring tools are not registering or receiving the data you are expecting.

I think I was trying to convey that actually working with general IT hardware and software like end-user devices and infrastructure and applications systems and servers is typically not something security staff typically are involved in.

The important thing to note is that if you have specific desired duties and/or skillsets you want to apply, you'll need to review job descriptions and such (for whatever they are worth which tends to be "not much") to make sure you don't wind up on the opposite end of the spectrum.

Having said that, security is not the easiest IT discipline to get into so you should seriously consider getting in wherever you can doing whatever you can.  Experience is still king and you need that above all else when you are in this industry.

ETA:  If you're lucky one of our resident security professionals will chime in.  They can add much more defined and practical information than I can.  I work closely with our chief information security officer on an almost daily basis but that is not the best perspective for entry-level advice!

Thanks.

OP, what did you do in QA / what is your experience? Maybe you should migrate towards the application security realm and devops instead of secops. Secops is plenty outsourced, devops / devsecops has some green grass. Did you code and test or were you a PM?

Sorry to give the typical "IT response" again, but this depends on the company and role. It's hard to say with certainty without seeing specific job postings and/or knowing a little something about the company.

When I am interviewing someone for my team, I'm assessing many things in addition to just your raw talent and experience. It's one thing to know technology. It's a completely separate thing to have the right mindset that will make you successful in a corporate security group.  I'm going to ask you about your hands-on experience but I'm also going to try and get a feel for your mindset; e.g., how do you solve or think through problems, what are your interests, how do you stay current on security topics, etc.  I'm also going to ask you trick questions or say something balatantly incorrect (HTTP is on tcp/90) to see if you'll correct me and how you do that. This is not a field where you can be passive when dealing with other folks and teams. You must possess the ability to be assertive and, when necessary, tell folks directly they're wrong or doing something the wrong way respectfully.

Assuming you make it through the gauntlet and are hired on, you're going to be assigned break/fix stuff for some of the lower profile systems for a while. I would not allow you to come in and start making changes to high profile or sensitive systems (firewalls, database security appliances, etc) during your first few weeks. That would be rolled in over time as you ease into the position.

That's my group. One of the other groups in my department would task you with reading and suggesting changes to existing policies from the start.

The structure of the security department and within the overall IT department or organization is going to vary wildly across the board. As someone else mentioned, it's worth getting in the door wherever the opportunity presents itself; even if it is an entry level position. I personally do not equate entry-level security with entry-level IT. There is too much responsibility - in a very broad sense - on the shoulders security groups to allow for folks to walk into right off the street without any previous IT experience. I do not see how you can be successful or effective as an operational security person if you have never had to understand all the varying components bolt together; i.e., if you cannot see or know the small details, how can you handle the much bigger picture.

never really heard those terms before.

I did the qa.
reviewed requirements, had them changed or questioned if they made sense.
Learned what the end user wanted to do.
did code reviews with app dev to see how they were going to implement
wrote the skeleton for the test cases and gave them to testers to write the click by clicks.
reviewed and then did some of the testing, but mostly the trouble shooting when testing went sideways.
And obviously level 3 support when app dev couldn't figure out what was going wrong in prod.

I did only enough pm to keep us on target and keep the people off my back asking where we were and if we were going to finish on time after having to start 2 months late.

In appsec jobs they are happy to have someone with dev/QA experience. A lot of appsec resources come from other security disciplines and aren't familiar with the development lifecycle or patterns, so if you're changing employers you might find an appsec team that would value your QA/security experience to balance out their other resources or liaise with their development groups while you train up on their appsec program.

thanks. I will do some reasearch on that.