Welcome to securityCRUSH

Welcome to the securityCRUSH blog, a place where you can find random musings as well as postings relevant to information security, penetration testing, and my latest projects - Daniel Wood.
Showing posts with label learning. Show all posts
Showing posts with label learning. Show all posts

Friday, February 17, 2012

Seperating yourself from the herd

Perhaps this could also be entitled: How to specialize and carve a niche for yourself while becoming a subject matter expert (SME).  

If you’re just getting started or thinking about jumping into Information Security as a career you may not know where to get started.  From my experience, a lot of professionals get started with conducting security assessments; whether it’s FISMA SA&A’s (formerly C&A’s) within the government realm, or Security Impact Assessments as Jr. Analysts.

SANS has put together a great list of the Top 20 Coolest Jobs in Information Security that provides a ‘How to be Successful’ blurb for each role.  Below is the list, however, I’ve stricken out the roles in the list that I don’t agree with:

  1. Information Security Crime Investigator/Forensics Expert
  2. System, Network, and/or Web Penetration Tester
  3. Forensic Analyst (this can be lumped into #1)
  4. Incident Responder
  5. Security Architect
  6. Malware Analyst
  7. Network Security Engineer
  8. Security Analyst
  9. Computer Crime Investigator (again this can be lumped into #1)
  10. CISO/ISO or Director of Security (this doesn’t happen until you’ve already shown your expertise…usually)
  11. Application Penetration Tester
  12. Security Operations Center Analyst (this is more of a hybrid of #7/#8 and only applies if you’re in a SOC)
  13. Prosecutor Specializing in Information Security Crime
  14. Technical Director and Deputy CISO
  15. Intrusion Analyst (see #4)
  16. Vulnerability Researcher/ Exploit Developer
  17. Security Auditor (being an auditor does not require specialization, generally speaking)
  18. Security-savvy Software Developer
  19. Security Maven in an Application Developer Organization
  20. Disaster Recovery/Business Continuity Analyst/Manager (related to #4)

Don’t get me wrong, SANS’s list is great and extremely helpful, however, I view it as a bit too high level.  If you really want to get into the weeds and deeper in security, I suggest following these few principles:

  1. Choose a technical area that interests you and start learning more about it; either through online articles, technical reference books, or free tutorials.  For example, if you want to get into penetration testing, I highly suggest picking up several introductory books (see my reading list post) and if you don’t know a programming language, start learning basic HTML, Perl, ASP, Javascript, Database (SQL), PHP, and XML.  These are just primers to get you started.  It helps to use multiple references for learning and pick what works best for you.  Don’t forget to practice, practice, practice!
  2. Learn a new technology; whether it’s firewalls, intrusion detection, or log analysis.  If you’re stuck in an analyst position and are looking for a way to carve that niche, knowing Cisco routing and firewall configuration principles will definitely help with transitioning over to a position as a Network Security Engineer (#7 on the list).
  3. Don’t be afraid to ask your project manager for added responsibility, or volunteer for it.  Showing that you are eager to contribute will increase your added value to the team or company, thus making you more indispensable, then say poor Billy who only does what he’s done a million times before and is essentially a paper pusher with no drive.
  4. Contributing to the security community.  Showing that you know your stuff and willing to share it with others will help make a good name for yourself.  Perhaps start off by tutoring your coworkers or when there’s a company training event, volunteer to conduct a training workshop for the company.
  5. Lastly, being a lifelong student is key.  Learning something new on a regular basis is what keeps our minds sharp.  If you are constantly learning and practicing, you will only get better and your knowledge base will only continue to grow.  This can only help your career.  When hiring someone, I take a look at what they’ve done and what they’re currently doing.  I’m not satisfied with a snapshot in time.  I want a dynamic candidate, not someone who is stagnant and happy just doing their job.

With all this being said, remember to choose what interests you and what excites you.  Don’t be satisfied with the status quo - get out there and challenge yourself!

-sC

Friday, February 10, 2012

Setting up a pen test lab

If you Google for this very same topic, you will be rewarded with a dozen different ways to do this.  My goal here is not to add to the collection of articles on the web with an ideal setup for you.  The purpose of this post is to show you how I setup my own pen testing lab for my purposes.

First things first, when setting up a lab, I determine what my goal for the lab will be.  In this case, pen testing.  Pen testing what?  Great question, glad you asked.  My goal with this lab setup is to create an environment that is extremely similar to what you may find in the wild within any organization’s infrastructure.  This includes a mix of Windows servers and workstations, Linux, Oracle Application Servers, Databases and the like.  Luckily it is pretty easy to do this, and can be done extremely cheap, if not for free.

My first step would be to download and install the latest virtualization software.  In the past I used to use an offering from VMware, however, for quick setup and maintenance, I find Oracle’s Virtualbox to be my cup of tea.  After installing Virtualbox, my next step is to create virtual machines that will serve as my attack targets.
Here’s a brief listing of places I use to find my possible targets:
For my testing purposes, I will always download the 32-bit architecture (unless it’s a 64-bit only server) of an image and load it into Virtualbox.  Using the aforementioned ground breaking internet search engine, Google…you can find tutorials on how to do such a thing.

After creating the virtual machine and installing my images, I want to also create an attack machine(s) to be used against these targets.  Keep in mind, every virtualization software is different, in Virtualbox, we want to make sure that all our targets and attack machines are set to use the ‘Internal Network’ only.  This way they can all communicate with each other within the virtual environment.  If you don’t adjust this setting you will find very quickly that you won’t be able to test properly.

My attack machines include:
  • Dedicated BackTrack 5 R1 VM - this comes with the metasploit framework (don’t forget to msfupdate!)
  • Dedicated WinXP VM to run windows only tools such as Cain & Abel
  • Dedicated Web App Testing VM - contains Burp, Firefox w/ specific pen testingaddons and more, Nessus, skipfish, etc
  • OS X running another instance of Virtualbox w/ BackTrack 5 R1
  • great list of more live CD’s for pen testing attack machines
My recommendations:
  1. Virtualize everything if you can, sometimes you can’t virtualize it all, but it cuts costs down.
  2. Make sure the host computer you are using has plenty of hard drive space and plenty of RAM.  (I highly suggest 8GB of memory)
  3. Dual monitor setups are your friend.  You can do more, however, I find 2 works nicely.
  4. "A penetration tester is only as good as his/her tools" is only partly true.  Compiling a great collection of tools and other resources is extremely helpful, however, being able to master them is what separates script kiddies from true professionals; and
  5. Knowledge of scripting languages is extremely helpful: Perl, Python, Ruby, and Tcl are great!
  6. If you run into problems or have questions, search for answers!  Don’t give up, and if all else fails, ask me a question (see the link on the sidebar to the right)
Keep in mind this is not an exhaustive ‘tutorial’ or ‘guide’.  This should merely server as a launching point for you to start your adventures.  As with any ‘guide’, your mileage may vary, and you should adopt and adapt any of the information within this post as you see fit that suits your needs.  There is a myriad of different ways to setup a lab, there is no ‘right way.’