Week 10, what we’ve covered so far.

Up until this point we've covered about half of the SANS top 20. For those of you who don't know I tend to reference the SANS information security reading room. This is where you can locate information on the top 20. I occasionally will bring in some experience or talk about a product I've used. When it comes to that I may reference a specific vendor. Ok, onto the specific review.

We've covered, why you need to know what you have. Why it's important to define how you setup systems. How to protect your border network, and analyze logs of all types, and lastly controlling who get's administrative privileges. The main idea is focusing on the things you can control. Most I.T. Security professional don't want to mention some of the more nasty truths out there. There is a really good chance that if someone wants to get into your network they can. However, the SANS top 20 isn't about that. It is about stopping the majority of attacks that are using well known and understood vectors. Furthermore, it's about limiting and understanding the damage post incident. I recently read the Verizon Report for 2011. This report shows that from the time of penetration to the time data is harvested, you have a sizable window to find out. Depending on the type of attack this could be anywhere from weeks to months. This means that if you are doing what SANS recommends you can minimize the impact! Furthermore, you will know what the impact was!

Next week I will be back with an exciting new topic… Malware prevention… Until then.

The SANS Top 20 Week 9

    This week we will be discussing controlled access. Most people are thinking, you mean like permissions on files? While this is certainly a large part of the picture, it is not the only part of it! Controlled access starts with asking who needs to know? I have often found myself in the position to decide who should have access to information. For the last few years I have fought this freely given power. When someone sends me a message which says, "I can't get into file x" I will typically respond with a few questions. These questions in my mind are the keys to controlling access to information.

    Questions I ask myself.

1. Who is in control of this data?
   
   1. Does the user already have access to this data? Many times the answer is yes.
      
   2. Do I need to ask HR or a department head about this?
      
   3. Is the data even being stored in the correct place? Is the user trying to share a personal directory?
      
2. What level of access is needed?
   
   1. In windows this is fairly straightforward
      
   2. Is this access permanent?
      

   
    

Questions I ask the user.

1. When do you need this by?
   
2. Does anyone else need access
   
3. Who is requesting this?
   
4. Have you opened a ticket or sent an e-mail (paper trail people, paper trail)
   

Ok, so I've made a point of giving out some basic information about what should be asked. This is what I've done in most situations which are not ideal. However, ideally what should happen is the following.

1. DFS should be used. This gives data redundancy and availability.
   
2. All shares should be hidden. While this isn't the end all be all of security it does stop casual browsing.
   
3. Knowledge owners should be identified. In other words someone needs to approve these changes.
   
4. When possible, setup shares by work area
   
5. Drives should be universally understood and applied via script
   
6. Access based enumeration should be used
   
7. Make sure a process is known to request changes
   

While access to data is important, remember, just because you have the keys doesn't mean you should open the door!

The SANS Top 20 Week 8

    This week we will be discussing… Controlled use of administrative privileges. This idea begins with a discussion on what accounts have administrative access. Ok, after a few weeks of reading these I would expect most people to already be saying, "How can I know what I'm limiting if I don't know what I have?" That of course is a great question. When it comes to PC's, I recommended using group policy. You can actually set restricted groups. This will make sure that no matter what when a PC is rebooted only the list groups have admin access. This means that if an admin wanted to give a user rights and then forgot, they would be gone when the PC rebooted. Another recommendation I have is checking who in active directory is part of the admin users group. This can be accomplished with a power shell script or even a manual glance at the group. Additionally, you can do some research. You should spend time finding out when the last time the admin password for any system was changed. I recommend beginning to document some of this in a spreadsheet or something. If you need to change an admin password go ahead and do it. After that, I would recommend finding out which processes i.e. backups, websites, services, etc… are dependent on admin passwords. Once you find this out you can begin the process of making sure those accounts are using service accounts. The big picture here is making sure that admin accounts are used by administrators only, only used when needed, and are relatively secure. In my experience the issue with changing admin passwords is the unpredictable things which break in a network upon doing so. Documentation and planning are truly the keys to this week's topic.