In the first part of this article series we covered the skills that a network security analyst should have in order to do their job properly. Now, this second part of the article will put these skills into context by simulating a "day in the life" of a network security analyst. I will give real life examples of why you need the specific skills that I noted earlier. Following this will be a brief discussion on the value of certification, and some of the ones I would suggest. Wrapping up the article will be some of the advanced skill sets that an analyst should strive for, and an indication of the small list of places one can go to learn them due to their complexity.
Example: a new vulnerability is discovered
The following premise assumes that you have just come into work, ready to begin your daily routine. The first thing I do once I hit my workstation at work is check my mail and take a quick look at the mailing lists I subscribe too. The ones I have coming to me are the SecurityFocus ones such as Vuln-Dev and Pen-Test, as well as the Firewall wizards one. Many people find Bugtraq and the massive Vulnerability Database to be useful as well. These plus several others are the ones I subscribe to in an effort to keep my finger on the pulse of the security world. Quickly scanning the subject lines I see one that happens to catch my eye. There appears to be a new vulnerability that was released late yesterday concerning a new exploit vector in a popular operating system. Exploit code, it seems, has been posted to one of the popular sites which hosts fully functional code.
Seeing as the network I help maintain security on is clearly going to be affected by this exploit, I hustle on over to the management console for our firewall. Lo and behold there have been quite a few scans on the port with that vulnerable service listening on it. This is of immediate concern to me, for we may have already been compromised (or, "rooted") overnight. With the firewall registering all of these hits I now go over to look at the IDS logs to see what it has registered. It seems that the IDS has fired off a series of "shellcode" alerts on the port in question. Things seem to be getting worse indeed. It now looks like our computers have not only been scanned, but that exploit code may have been sent to them.
While bearing in mind the above information, there are two things I have to do immediately. The first is that I will design a bpf and bitmask filter for my IDS, to cull all the packets that were directed at the port in question. The second step is to go and download a copy of the exploit code itself.
Seeing as it was a scan of our network, which was apparently followed by exploit code being sent to specific computers, I will construct a bpf filter as follows:
-nXvSs 0 tcp and src net 192.168 and src port 135 and tcp[13] = 18
Shown above is the filter I wrote to give me all the packets sent to our vulnerable port. It also shows me the syn/acks sent back to the machines scanning it. This enables me to write down the IP addresses of the possible offenders for future followup action with their ISPs, if and only if they are attempting to penetrate our network.
Now I devise a bpf filter to give me all the packets. This is to show actual data being sent across to our network, and it would look as follows:
-nXvSs 0 tcp and src net 192.168 and src port 135 and tcp[13] = 24
As mentioned, this will give me all the packets which are psh/ack's. These are the packets which will be used to convey the actual exploit code, if any. Writing the above filter will allow me to most effectively use my time by analyzing only the actual packets which are of importance. At this stage of the game I am no longer really concerned with who is scanning us or whether our computers sent syn/ack back, but rather I need to know if there was any actual exploit code directed against us. Instead of wasting my time with other packets like the syn and syn/ack packets, I concentrate on the important ones first.
While the filters are being worked on by the computer I surf over to the well known site which hosts the exploit code, in this case www.k-otik.com. Once there I grab a copy of the recently released exploit and open it up on a dual-booted laptop I have at work for these types of instances. The laptop itself is not connected to the network in any way, and it is therefore safe to play with exploit code or malware on it. I take a quick look at the exploit code itself and the header files to find that the exploit was written on a Linux machine. I realize this due to some of the #include files in the exploit code, which cannot be found on a Win32 based operating system.
I try to compile the code only to get some errors. I find it somewhat odd because this site is normally known for fully functional exploit code. I decide to try and compile the code again, but this time in an IDE within Linux. Once again the same errors come back, but this time I can use my average C programming skills to debug the code. As luck would have it there was just some minor "script kiddie" obfuscation done to the code. Five minutes later I now have a functional copy of the code.
Where I work I have the luxury of using a couple of lab boxes, which mirror our production baseline. This allows me the ability to test out patches, and other system fixes prior to deploying them on production machines. Also it allows me to test out new exploit code as it comes out to see how it will affect our machines and observe the behavior of an exploited machine. Ideally one has access to this type of lab environment at their work. Realistically not everyone has lab machines available for us, and he may have to make do simply with a company laptop to simulate most of the company's software baseline.
It is now time to go back and inspect the file that was generated by my bpf filter earlier. Upon close inspection of the psh/ack packets I can see there was definitely a binary transfer that has taken place. Seeing as I have not yet had time to invoke the exploit that I have now functioning, I do not really know what tell-tale sign is to look for in the packets themselves. By that I mean a sign such as say "/bin/sh" within the ASCII content of the packet, or some such other indication of possible mischief.
With this in mind I go back and establish a direct connection between my laptop and a lab machine. Once this is done I invoke the now functioning exploit and direct it towards the vulnerable port on the lab machine, which is segmented from the rest of the network. Lo and behold I am able to obtain a reverse command shell using this exploit. Prior to running this exploit I fired up tcpdump to write myself a binary log of all packets. This allows me to inspect them post-facto. I kill the command shell, which was obtained, and take a look at my binary log trace. The syntax I used to copy all of the packets being sent and received by the exploit is as follows:
tcpdump -nXvSs 0 ip and host 192.168.1.101 -w sploit_log
The above noted tcpdump filter will copy all packets with a valid IP header in them, and write them to the binary log called "sploit_log". Lastly the IP address of the lab machine being tested is 192.168.1.101.
Now that I have the binary log file and the exploit has been executed I can look at the packets themselves, and see if there is something telling in the packets themselves. I use the following tcpdump syntax to look at the file that was generated:
tcpdump -r sploit_log -nXvSs 0 |more
Looking at the file for a brief time I notice that there is no tell tale sign in the packets themselves that I can use for a possible IDS signature, or other aid to the analysis. With nothing obvious in the ASCII content, and without header metrics the job becomes a little more difficult. Bearing this in mind I will have to check out all the psh/ack packets by hand. This will not be overly arduous, as I have been able to pare down this mass of traffic to just the psh/acks themselves.
With this information in hand I approach management and advise them that until a vendor patch comes out we should shut down this port at the border router. Once the vendor patch comes out and an IDS signature is developed we can then open this port back up, but in the interim we need to manage the risk. Lastly I inform the management team that we probably have computers which have been compromised. With that update to management I am off to check and further analyze data to confirm or deny any compromised machines on our network.
As you can see from the above scenario, I have painted out the use of every skill mentioned in part one of this article series. This is why it is imperative to learn all of these skills, starting with TCP/IP, to become a competent analyst.
Thoughts on certification
What happens though if you have all of the aforementioned skills? How do you improve your skill set in an effort to improve yourself? There are two suggestions I would advise. Firstly would be to seek out a certification and preferably one which has a practical portion to it. In my opinion, arguably the best technical certification out there today with this practical portion are the GIAC certifications. These are widely recognized as being very technical and require the person to prove their skills not only via two exams but also through a demanding technical paper submission.
Not everyone is going straight to the network security field, however. What follows are my suggestions on a triumvirate of certifications to consider as a baseline. Obtain the CCNA, for example, as it will denote proficiency with a routers and daily maintenance. Perhaps get one of the GIAC certs, specifically the GCIA or GCIH. The former is about Intrusion Detection and the latter is the Incident Handling one. Both are very good, and demonstrate your mastery of the subject material. Lastly I would consider the MCSE simply because most corporate networks are still Microsoft based and it only makes sense to learn the operating system that you are trying to protect. Many sneer at the MCSE certifications, saying that they are paper certs only. While this is sometimes true, I have also met many MCSEs who are very good indeed. For many people, and particularly employers, it is simply a baseline to start from. Finally, if your aim is to eventually go into management then the cert to get is clearly the CISSP. It is very much a management based certification, is generally recognized around the world, and it will give you a bit of knowledge over a wide variety of topics. One can debate over the value of having a certification, and then argue about which is the best. The bottom line, however, is that any certification is better then none.
Programming essentials
What might be the next step to improve your skill set when you already have many of the core skills, and have evaluated various certifications? One should then strive to become good at C programming as well as learning Assembler. Why? Simply because most exploits are written in one of these two languages. Also, one should ideally become proficient at reverse engineering malware. It helps to understand exactly how it works, and being able to reverse engineer a piece of code is the best way to see that. This still leaves the problem of where to find this type of advanced training. Training venues that cover this topic are highly specialized in nature as they cater to an advanced skill set, or "training the trainer" courses if you will. It is at this point where such names as Mike Sues, Dave Aitel, and HD Moore begin to appear as possible teachers for these advanced skill sets. I would argue that these are some of the best presenters in computer security today.
Conclusion
Once you have reached this point in your career, you'll find that many new things are learnt on your own. Finding such specialized training is difficult, and expensive -- however the value of such training is indeed very much worth it when compared to the cost of a network breach, and can be great justification to your current employer. I sincerely hope that this article was able to clarify these skills for you, and help you out in your quest for possible skills upgrading. Remember being in this field means you are perpetually learning. You can't afford to sit still.
|