An Unrealistic Job Posting? - IT Security Engineer III - Active Directory

UnixGuy

@docrice: thanks for the great answer.

Just so we can learn something from this thread, seeing that we established that to be a good security ninja you need ninja experience in multiple domains, how did you go on about getting experience in multiple domains? Did you work in different sysadmin roles before moving to security? or did you get a junior-ish security position where you got a chance to learn multiple things?

Sharing personal journeys helps a lot.

docrice

In my own case (and I'm not implying this is the path everyone should take), I started out as a desktop support/sysadmin for Windows environments back when NT 4.0 was finally moving up to NT 5.0 (known as Windows 2000). My first exposure to "security" was when a senior admin was doing a domain password audit and mine was easily cracked (LM hashes, yup). He explained password complexity and how they relate to security requirements, domain identity theft, and so on.

He also nudged me to attend DEFCON and I think that's what started my traction and interest.

I eventually moved onto a lab support role involving Windows, Unix/Linux, and eventually networking. Didn't really know what I was doing in many cases, but it all started falling in place after being exposed to many different areas. I think my first Linux install was Red Hat 7.3 and while I was comfortable working on the CLI from my old DOS days, Linux took some getting used to. In the new environment I was also prepping endpoints, client software, managing AD, setting up Linux hosts, running the PIX, deploying new VPNs, writing lots of documentation, working with lots of customers (doing some customer support as a product specialist allows you to get a sense of how other environments large and small operate), etc.. Lots of opportunities to install and try things out. Break, fix, break some more, troubleshoot...

I've been somewhat lucky to have landed the roles that I have, and a lot of it was due to good personal connections that had an "in" at different places. Very rarely have I gotten employment offers by going through the front door with a resume in hand or via a recruiter. However, a lot of it also has to do with the amount of effort I've put in, the results I've produced, my work ethic, and the impressions I've made. Without the latter, I'm certain the professional recommendations from others wouldn't have come. It required a lot of sacrifices and setting aside what many would consider a normal life. I've always had my home network structured like a simple corporate environment with DCs, firewalls, routers, switches, Windows domain members, Linux hosts, access points (with 802.1x configured), and whatever else so if something breaks, my Internet connection stops working and I have to fix it. This really forces you to invest in your ability to figure things out.

I took a CCNA bootcamp with a friend back in 2009 and while I already had Cisco device configuration experience back then, the bootcamp really did help in some ways. I didn't get any certs until then and have been on a roll since. I went from having no certs to being a paper tiger in no time (I've never failed an exam ... yet). I can now speak from experience about certifications and their relative worth as someone who has studied enough to pass exams and also someone who interviews and evaluates candidates for hire.

Something else I should mention which I think has helped me grow professionally - working in smaller shops of around a few hundred employees rather than working in a large bureaucracy with thousands or more. You're thrown in a fire at smaller shops and wear many hats by necessity, forcing you to adapt. When you stress a muscle, you either make it or break it. Just have to be smart about how much exhaustion you allow yourself to take on.

I currently run internal network security at a network security vendor. Our company runs, evolves, and changes fast. It's the nature of the industry and there's no room for complacency. I also interview candidates, interact with vendors, perform product evals, and whatever else that comes in my way (including the occasional rack-and-stack). Having a sense of all layers really helps put the links together.

If there's one thing I've learned, complexity is the nature of the business with the additional requirement of keeping up or being left out due to being ineffective. Results matter, effort isn't always recognized unless you can deliver value. If you want to know why so many companies get breached, it's partly due to lack of awareness at the senior management level (and the apprehension of the technology/manpower costs to protect assets) but it's also too many professionals drinking the vendor Kool-Aid and blindly trusting the fancy NextGen Cyber Threat Mitigation™ technology to do their job. Our job as security professionals is to scrutinize by setting aside our assumptions, recognize the limits of what the vendor sells, assess the ongoing/changing risks, and employ compensating controls as your management dictates by finding the right balance at a given point in time. This is why when vendors come into a meeting with me, I'm very terse about skipping the marketing bull and getting straight to the engineering. I don't have enough minutes in the day for excess and I no longer do vendor lunches.

To anyone thinking of entering into the security realm because of the fancy green text on black background (with anything malware-related highlighted in fixed-width red text), realize that there is some digital sexy involved in the work ... but it can be an agonizing, frustrating, supremely detail-oriented endeavor with a lot of explaining of each step, rummaging through incomplete/incorrect documentation, many false assumptions from your peers or management, increasing scale of things to monitor/protect, lack of budget, lack of staff, lack of good candidates in the resume pool, never-ending patching cycles, constantly cleaning up after sloppy configurations, technology shortcomings with vendor claims that don't always live up, and dynamically changing environments both internal and public. The real world looks nothing like what the textbook implies in the training courses.

So now that I've exhaled a bit of a rant, I assure you it's not realistic for everyone to know everything. There's too much ground and minutia to cover. What does help is if you're motivated to learn how things really work under the hood and how the parts fit together, you understand what personally drives you into this role, and a commitment to keep improving with a willingness to stay on top as much as you can. Everyone has specializations, but having those strong fundamentals really help you see what the sysadmin/network admin/DB admin/user/application/business partner is perceiving. Without that perception, doing security effectively is hard.

If you really like this stuff, you will never stop reading and tinkering. That's what makes you stand out because your intuition and technological sense will outgun the person next to you. You must always compete with yourself, not just others. Not everyone in security will have all the fundamentals, but the common security practitioner will need to be versed in the obvious areas.

Don't expect security certifications to teach you everything. They are merely the first step into a larger world, and security is based on existing domains like managing Windows networks or web applications. Applying what you've learned and the discovery of the gritty oil between the gears of the moving machine helps you realize how a simple valve in an engine can hold so many other things together. Part of the experience of growing is banging your head against the wall until you realize there's another way. That's why it's so important to Try Harder.

Oh yeah, and learn to type fast. It really helps to get things done.

Zoovash

Hey docrice! Thank you for your time to write this awesome post!

SaSkiller

Thechainremains wrote: »

So i just came across this.. and when i read it...I was just stunned. You really gotta watch out for stuff like this.. Googling some of this description, listed a few Staffing agencies who have " tried to fill the position. " Which further tells me, this post is even more questionable..

a few things...

1) Who in the world is experienced in Coding or basically a Programmer, and has Security experience?

2) Why would anyone with a Security related certification, have any know-how of Active Directory? I mean the 2 just dont mix.

3) On top of all of that, who would have Unix, Linux, BSD, or Cisco iOS experience to go along with it?

4) No mention of a Linux+, Cisco Cert or Microsoft Cert, which in reality is what they are really after?

5) They want someone with HIPPA and SLA experience but they dont even mention ITIL?

Some parts of this make a lot of sense. A security person should have an understanding of programming at some levels, so it's not out of the range of desired qualities. They should also have SA/NA experience to get into security, so they should understand and have worked with AD and Cisco. If you are a security person who doesn't have linux experience, you are in management. Outside of the HIPA/SLA experience, i'd fit those qualities. I spent years as an SA with AD. CCENT Certified, was well prepared for CCNA/CCNA:S. Experience with linux including BT/Kali. Studying Python/C/ASM in prep for the CREA.

UnixGuy

Thanks for the great contribution docrice!

I think it all comes down to personal internal motivation, and nailing down WHY you even study or bother.

Deathmage

my co-worker at work is the perfect person for this role. he's been in IT since he was 16 and he's 44 now. He's the best programmer/developer and oracle/SQL administator I know with a strong understand of Security and System Administration in Unix and Linux. His problem is he can't do it all so hes just the programmer/developer of the Syteline ERP and I do system/network administration. It's the perfect match and the amount I've learned in one month from him is immense; plus were both Trekkies like comon'!!!!

To put his level of madness into perspective hes currently doing his MCM in SQL.

dou2ble

docrice wrote: »

Speaking just for my own experience, I'd say having a generalized background and some specialization really helps in making a good security engineer. Virtually everything stems from fundamentals, and being able to deep-dive requires seeing things from the ground up and recognizing the moving parts and mentally compartmentalizing them as needed. That's where being detail-oriented stems from in regards to having a wide array of exposures and understanding the bigger picture because everything's dependent on each other.

Risk management and providing justification requires being able to research, figure things out, and demonstrating or relaying the gritty details in a way that's relateable. Having that flexibility/adaptability requires 1) a keen interest and curiosity in general, 2) maintenance and self-refreshes as the larger world evolves, and 3) mental tenacity.

In general, the security professionals that I've known don't see themselves as "having a job" but rather being part of a larger mission. There are some IT professionals who are really dedicated to their craft, but there's also a lot more who just want to do their shift and go home. Security is going to be really, really tedious work for someone who just wants to get a paycheck.

Well said! Articulate and on point!

Deathmage

dou2ble wrote: »

Well said! Articulate and on point!

in this industry you really gotta have it as a passion.

higherho

dou2ble wrote: »

I have to disagree with your comment about "real security engineer". I work with CCIE's, Linux guys, and Microsoft consultants and they aren't security engineers. They can certainly address security requirements but they don't know how to identify risk and security laws and regulations. They spend their time building a solution and I advise on how to create it securely. I do the risk assessment and recommendations, they do the clicking and required research to build security into the solution. Together we get it ready for certification. It's also part of the SoD. They focus on functionality and security focuses on risk. I have some knowledge and experience in servers and networking but I look at networks from a different perspective then they do. This has been my security engineering and IT audit experience in commercial and Federal work.

Identifying risk, security laws, regulations is important but that's not "engineering" that's Information Assurance. It's sad that everyone calls themselves an engineer but honestly anyone can read up a NIST documentation, STIG document, and IA controls to review a configuration. A true engineer will know how to build, design, and configure it to meet those controls and after doing it for so long they will also know the laws and regulations. Not to mention it's the engineers that originally found those risks to mitigate (create a patch) them anyways.

Chivalry1

Interesting thread....I think you will find it common that most IT Security Professionals have a broad background in various IT technologies. Particularly in my circle most come from networking and/or system administration; not many programmers or app developers. I come from a consulting background so you had to be a JOAT. I would venture to say most of the IT Security person I know, including myself, could comfortable apply for this job without issue. What would be unreasonable if this job only paying $20,000 annually.

discount81

It seems like a fairly standard job description for a skilled security engineer, not sure why you take exception to it.

I feel like security jobs have become somewhat watered down in the past 15 years, I remember when I was starting out in IT, the people involved in security were Unix/BSD/Linux experts, windows experts, they could code in C++/Assembly and write their own exploits or patches, there was few and far between security roles available, the guys in them were superstars.

Now days I feel like security roles are more regulatory than technical, I work with a CISSP and yes he definitely knows all the laws etc, but when it comes down to configuring IPTables on a Linux machine he isn't too good at that.
Then you have the security analysts who all they do is monitor logs and make firewall or application adjustments.

The fact that the guy who started this topic finds it outrageous that a security engineer is expected to code, shows how watered down these roles are now.

dou2ble

higherho wrote: »

Identifying risk, security laws, regulations is important but that's not "engineering" that's Information Assurance. It's sad that everyone calls themselves an engineer but honestly anyone can read up a NIST documentation, STIG document, and IA controls to review a configuration. A true engineer will know how to build, design, and configure it to meet those controls and after doing it for so long they will also know the laws and regulations. Not to mention it's the engineers that originally found those risks to mitigate (create a patch) them anyways.

It's funny that you mention NIST and then say that "A true engineer will know how to build, design, and configure it to meet those controls and after doing it for so long they will also know the laws and regulations". That is a true statement but incomplete. You might want to check your NIST documents (since you're most likely in DOD) because you're mixing a system engineer with a security engineer into 1 position. These are 2 different roles that are often held by only one. You're also making it sound like security engineering and IT audit are the same. They both "Identifying risk, security laws, regulations" but the purpose for doing these steps is different. One is to build correctly and the other is to assess if it was built correctly. Some of the security engineer functions are assessing the desired solution to be engineered, identifying threats and security controls, which then lead to security requirements and making specific recommendations (Technical background really helps here). The system engineer then builds a solution, with the help of a security engineer (again this is where a technical background really helps), to address those security requirements. For information assurance this is where C&A or IT audit (SOX, ISO27001, etc) is most likely done. You certify that it's been built correctly, all policies are met, and if an accreditation is desired you proceed to obtaining that.

Information Security focuses on the security infrastructure and building it correctly with security in mind. Information Assurance is more concerned with policies and if they're implemented. I've heard so many interpretations of this but this is the one that most makes sense to me. DOD likes to confuse the 2 and make them interchangeable.

One of the big reasons DIACAP and FISMA so far have failed is because they primarily focus on Information Assurance/C&A only, they check the box with no desire to actually find the risks early on as part of Security Engineering and then build the right security infrastructure.

I'm assuming in your last statement you mean system or network engineer. Either way it would be inaccurate. A system engineer might find the vulnerability through a scanning tool or news, but rarely do they find the risk. Vulnerability and risk are not the same thing. The risk is determined by assessing the vulnerability, threat and impact to your environment. Patches are also created by programmers, not engineers. When a system engineer, security engineer, vendor or any other worker identifies a vulnerability it then has to be assessed for your environment to find the risk.

We could go on and on about what a Security Engineer used to be or should be but that doesn't change what a Security Engineer is required to do today and the job descriptions seeking one.

higherho

programmers are engineers, software engineers I guess it's just my personal belief that the C&A, A&A, RMF, reviewers are regulators and not engineers. At least the ones I have meet. The people who develop and find those risks for the regulators to search for are engineers. way to many check box monkeys I've encountered. Overall a security engineer would have both the technical aspect (like the main job posting states) and understand the laws. They need to be technical enough to find the risk (similar to an IRRT / RED team combo imo).

dou2ble

higherho wrote: »

programmers are engineers, software engineers I guess it's just my personal belief that the C&A, A&A, RMF, reviewers are regulators and not engineers. At least the ones I have meet. The people who develop and find those risks for the regulators to search for are engineers. way to many check box monkeys I've encountered. Overall a security engineer would have both the technical aspect (like the main job posting states) and understand the laws. They need to be technical enough to find the risk (similar to an IRRT / RED team combo imo).

Haha yes programmers are software engineers. Although I don't think that's what you initially meant.

You're right that "C&A, A&A, RMF, reviewers are regulators and not engineers". Although they're more auditors, not regulators, since they can't regulate anything. They only assess compliance. I guess "check box monkey" is another name for them. Maybe I'll add it to my signature since I did for a bit for one of the big 4. Haha!

The Security Engineer, hybrid of technical and auditor, like you described is where I see the future moving to. This is what I do now and I think most bigger companies and the government will move towards this. I used to create gpo's, write scripts, set permissions, ACL's, configure routers, etc...but now I just consult for the Microsoft and cisco engineers to make sure security is built into the baseline from the ground up, and in some ways I'm the customers representative to the auditors.