This post is brought to you by the letter W...

Before getting started, I would like to mention that this argument uses some generalities. I still feel that it is a good starting point to figuring out what makes a Security Practitioner different than and Network or Systems Admin.

Note that a Security Practitioner in this case is more of an adviser to an admin than someone that does implementation. Once a security solution needs to be implemented, if the same person that designed the security implements the solution, then the person changes roles at that point.

The technology field is largely a problem solving field, More so than most fields. When dealing with a problem that you have to solve you will invariably have to ask one or more questions about the problem in order to formulate a solution. Most problems have several solutions and the solution that is chosen is largely dependent on the probing questions that were asked of the problem. I believe that the difference between a Security Practitioners and Systems/Network Admins happens to be the different questions that are asked. Specifically that Security Practitioners ask Who, What, When, Where and Why [the Ws] and Systems/Network Admins ask How.

Here's a scenario to hammer home my point:
You have a small office with cubicles on one floor and a network closet on the same floor. The employees have a mix of laptops and desktops and they all run various versions of Windows. You need to deploy a new File Server.

The Systems Admin would be inclined to start with "How do I install a file server and make it available to the office?" He might then think "How do I secure the file server?" The experience of being a security specialist allows the Security Practitioner to start with "Why do you need a file server - is there anything that can be done more securely?" Then, when his boss says "Just make the file server!" he will think:

• "Who needs access to the file server?"
  
• "What will be stored on the file share?"
  
• "When will it be accessed?"
  
• "Where will the requests be coming from?"

The answers to all of these questions have a direct impact on the solution.

Now that we know this...

You're right, this isn't exactly research, nor does it seem relevant to doing your job on a day-to-day basis. It is relevant when working in a team environment, though. Delegating jobs to people that have a certain thought process - or better, teaching people that a certain thought process is how we, as a group, like to do things - is important to make a fundamentally secure environment.

To the admins that have the responsibility of making everything works, monitoring, securing and making sure the boss has coffee, thinking about the Ws first will make a more secure environment. It may bring things into focus that just don't make sense ("Why does the support staff need write access to the financial share?").

Even to the Pen Testing argument, this is valid. Everybody seems to take a side on Pen Testing. There are especially some that think that the client does not understand the reason for Pen Testing. It may help to know the thought process of the client in this case and find a way to advise for or against it as a security issue. For instance, you do a Pen Test, then you report the results. You answer the W questions. The first question that you will be asked is "How would something exploit the vulnerabilities that you just presented?" As a security practitioner, it doesn't matter. It has been proven by someone as an attack vector, therefore it must be secured.

Even in terms of a Security Researcher, you wouldn't think "How do I leverage this bug I just found?" You would say, "I have found a bug, what happens when I do this..." You would go through a series of trial and error. If you start thinking through a scenario starting with the question how, it always ends up a dead end - unless someone already answered all the Ws.

The exception that I can think of to this line of thought is when doing incident response. Someone has already answered the Ws of your network and has already proven that. You need to find out how that exploit did its thing - that way you can work through mitigating it in the future by answering the Ws of your network.