Most people hear the term Infosec, and they automatically associate that with network and telecom security, but in reality it’s much broader than that. IDS specialist, firewall specialist, penetration tester, forensics investigator, security assessments (not to be confused with penetration testing because they are very different), are all parts of the Infosec field, just to name a few. I know people who do nothing but design and test physical security; they break biometric mechanisms, social engineer the heck outta people, and do tons of other things that require little or no knowledge of network or telecom security.
The fact is, in most small and medium sized companies, the security team usually consists of one person (if they have that many). So this person becomes a general practitioner by default. This is good for getting “exposure” to different areas of security, but in most cases they won’t become an expert. For example, there are not a lot of one man security teams that can properly do a complete forensics investigation from start to finish. It requires in depth knowledge of certain tools, extremely in depth knowledge of operating systems and file systems, and considerable knowledge of local, state, and federal laws and regulations. You’d be hard pressed to gain and maintain all of this knowledge without doing it on a regular basis.
But in the real world there are common trends to how these responsibilities are broken up. Even if there is only one person to do the work, all of these roles need to be addressed.
CISO, ISM, IAM (Chief Information Security Officer, Information Security Manager, Information Assurance Manager): (CISSP, CISM, CISA, and other security management certs)
These are the people who typically come up with network security policies. They come up with policies that best protect the network and company resources. It is often mistakenly said that these people don’t have to know much about the actual technical side of things as they only make policies, but this is not always the case.
In order to make policies that can actually be implemented on a technical level, this person has to be aware of what’s possible at the technical level. The best way to gain this knowledge is by actually doing it on a technical level. This is why I’m a fan of the people setting policy being people that have spent some time in the trenches. This will reduce wasted time as proposed policies go back and forth before something actually doable is produced. An example: Network Security Policy dude says, “I think all TCP traffic from the outside should be blocked at the firewalls.” Network Engineer says, “Ahhhh, are you sure you mean ALL traffic?”
Keeping the information safe from outsiders isn’t enough. The policy honcho also has to be concerned with ensuring the data is stored accurately and is made available to the people who need it. This all has to be done with whatever budget is available for the task, which rarely is enough to do everything. So decisions need to be made.
Network Security Engineer: (CISSP, CPT, CEH, CCSP CCNP, and other vendor specific certs)
These people take policies or security requirements and engineer or design technical solutions that will make these policies an enforceable methodology. This is the person that usually sends stuff back to the manager saying it’s not possible, or it’s not feasible. The security engineer will usually be well versed in current/available technologies. He would also be wise to have skills needed to test the strength of his designs before rolling them out in production. It’s also helpful (if not a requirement) that this person have some vendor specific certs not security related. For example, if the company uses Cisco equipment, then this person needs to be very familiar with how this equipment works, and how it is configured. So CCNP, CCDA, CCSP would be helpful and probably even required if it were my decision.
Penetration Tester: (CISSP, CPT, CEPT, CEH, CCSP, MCITP, CCNA, CCNP)
A good penetration tester needs to know a lot about a lot of things. Notice the cert recommendation looks very similar to Security Engineer. But the key difference is which of these areas or certification bodies of knowledge the professional branches off into more. For example, a network security engineer would almost certainly go a lot deeper than the CCSP cert requires if he is to design and engineer a secure Cisco network. However most of this “deeper” knowledge will come from either on the job hands on work or preparation spent during spare (read personal) time.
Network Security Junior Engineers, technicians, etc.: (Security+, Network+, Vendor specific security certs)
These are the people that will either be implementing or assisting with whatever implementation the engineer comes up with. If they’re smart they’ll always be wondering, and even asking, why a certain design is this way or that way (so they can one day be an engineer). Or they may just blindly implement without having a clue as to why and never progress beyond assisting.
It’s important to recognize that in some circles it is required to NOT ask why, due to separation of duties and “need to know” type situations.
Network Security Analysts: (ECSA, Vendor specific IDS certifications and IPS certifications)
These people might actually touch stuff and implement a little bit, but they mostly analyze logs (loganalysis), tweak IDS rules (remember a true IDS is passive so they can’t screw up communications here much), decide when there’s a breach or potential breach and other similar functions. Again, if Cisco equipment is in use, then the entry level certs that aren’t related to security would be paramount here.
So now let’s pretend your company has all these people in place, and IDS reports a potential breach. Now the forensics and other incident response teams come in.
Forensics Investigator: (EnCE, CHFI, and other vendor specific forensics certs)
Since the IDS suspect there’s an incident, but can’t prove it, they need forensics people to:
- Decide if there’s indeed been a breach,
- Prove there’s been breach, and
- If there has been a breach, take steps to ensure that a forensically sound investigation can actually take place.
The third step will ensure that if the company decides to pursue prosecution, the case is not thrown out of court due to failure to follow commonly accepted rules of evidence. This person might have to communicate and work with all the folks above to actually obtain certain logs (because the person configuring a router or firewall is the best person to ask where they configured the logs to be stored). They will certainly have to work closely with the CISO in order to get permission to get all this information in the first place. The days of the CISO saying to everyone on the security team “give this guy whatever he asks for” are long gone. In actuality, the process is much more granular and tedious than that. In this case, knowing where logs are stored will only help his case and might even speed up the process if he can tell the security guys exactly where to look for what he needs. So knowledge of equipment logging and storing procedures can only help. This is why I would recommend knowledge of Cisco equipment if that’s what the company uses.
Forensics Analyst/Examiner: (EnCE, CHFI, and other vendor specific forensics certs)
This person would usually be in a forensics lab and would actually be the one examining all the collected information (or actually copies of it). He would be performing data carving, file system analysis, log validation and all kinds of other functions that would locate evidence to prove or disprove what the IDS initially thought happened.
Now keep in mind all of this just scratches the surface of the network and telecom side. There might be an entire risk assessment or risk management team that does nothing but try and keep these things from happening by using quantitative and qualitative data to decide, based on occurrences and potentials, what to spend on what, and where things need to be tightened down more. There might also be an incident response team or person that is responsible for deciding who deals with what and how it’s dealt with when it happens.
So the fact that the IDS team (or person) reports to the CISO, who then engages the forensics team, should be something already planned by the incident response team in coordination and with the help of the rest of the security team. Often times the incident response person is temporarily called upon to be the “quarterback” of the entire security team as a whole, because during an incident they will probably become part of what’s known as an incident response team that includes not just IT Security but other areas of the company as well (HR, PR, Accounting, Loss Prevention, etc.).
Once this breach is contained, there could be an effort to get someone unbiased, that’s not part of the company to regularly assess the security posture of the organization in hopes of minimizing the changes of a breach happening again. Enter the penetration testers, security consultants, and security assessment consultants. These roles can all be carried out internally as well. But, just like with auditing of financial records, security auditing holds more weight when a third party does it.
This is certainly not intended to be a comprehensive article that spells out every possible position in information security, but it is intended to give you an idea of just how deep the rabbit hole goes.