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.

The SANS Top 20 Week 7

    This week focuses on application security. This is an interesting dilemma. Let's say we have well maintained and managed operating systems. We watch our logs, and know what is coming in and out of our network. We even know what devices and software are on our network. However, what do we know about some of those applications? How do those apps work? Do they have patches, what about security flaws? Many of these questions need to be answered for off the shelf products. It gets even more interesting when we begin to consider home grown products.

    I used to work for a company that had an in house software developer. He would take care of most of the behind the scenes database work as well as the main business analytics pieces. All of that to say he was creating code that gathered data which in turn ran the business. SANS's recommends that software have a development life cycle. In other words, much like hardware or other off the shelf products, a plan needs to be in place. We state that we are creating a piece of software for a task and we plan on how to implement it and take it out of the enterprise. This also means knowing what pieces of software are developed in house, and who is responsible for them.

    I will be honest; I don't have a lot of experience with this. However, it is clear to me that having software developers involved in ongoing education and being a part of a community of practice would help a lot. In the end, people need to understand what is going on and have a process in place. This should ensure that an account can be made of all locally developed products.

The SANS Top 20 Week 6

    Control 6 on the Sans Top 20 is something near and dear to my heart. That's right Logging. Ok, before we get too far into this I have to be honest. There is absolutely nothing fun, exciting, or interesting about logging. Most of the great solutions out there are very expensive. The primary example of what comes to my mind is Logrythm. However, the guys who made the 2011 Verizon report have a great point! They stated that if someone had a basic idea of how many logs entries they have in a given time, and could tell when they increased they would be ahead of a large portion of the people who were mentioned in their report. While this is a bit beyond the scope of this entry here is a link.

    I worked for a restaurant chain not too long ago. We had a PCI compliance issue and we needed to do some logging. So here is what I did. I found a solution to this called Splunk. Splunk will index up to 500MB of logs per day for free. What this means is that you can take logs from just about anywhere and index them! Ok, so what I did is took all of our point of sale systems, the Cisco logs for our firewall, and a few choice others. That information was then collected into a flat file database. Splunk then offered me a great browser which I could type queries into, but where this solution really shined was the modules. Someone had a already designed a PCI module. I was able to have it do the searching for me!

    In the end, logging comes down to two things. First, you have to hold onto logs for a fixed amount of time. Second, you need to have a way to look at them. In the end logging efficiently depends on the size of the organization, the amount of data, and how important it is to the organization. In my mind with a little bit of hard disk, and a few hours, you can get a lot of great data!

The SANS Top 20 Week 5

    This week we will be talking about Border defense in networks. Lately I have heard some negative press on this topic. Not because people are opposed to border defense, but because many IT people over emphasize this aspect of network security. While I tend to agree that border defense is important, I would like to point out that it is not a total defensive strategy in and of itself. If you remember back in week one we talked about hardware inventory. This is going to come into play heavily this week.

    Ok, so how do we define our border? In general I would state that it is the end of possible total control in our LAN networks. Most often this is characterized by a firewall, router, or both. Let's say we feel pretty good about our network and router configs. We reviewed them thoroughly because of Week 4. So the next question we have to ask is who is changing them. SANS recommends and I agree that logs of this type of information must be kept. Those logs should be e-mailed to whoever is responsible for security within an organization.

    So what type of tools can do this? NIST recommends a Linux distribution called Security Onion. I have also seen this done with Splunk. Providing you are capturing logs, it's not too much effort to determine who is logging into a system. Those logs could be sent out daily, or weekly. In the end I see this week's topic as a matter of two things. 1. IS change management, while 2. Is maintaining control over access.

The Sans Top 20 and you Week 4

Last week we discussed creating default setups for software. This week we will be discussing secure configurations of Network Devices. You guessed it firewalls, routers, and switches. This topic is something near and dear to my heart. I've spent a considerable amount of time over the last few weeks studying for a CCNA exam, but enough about my free time or lack thereof. Ok, so how do we configure network infrastructure securely. The first thing we can do establish a process for changes on the network. The next thing we can do is refer to that inventory of devices that we created earlier. We can then make sure that we know what versions of equipment software we are using. At this point we can check with our manufacturers and see if issues are present. After that we can make copies of all the configuration files. We can then review the files. I like to look for things like no console passwords, or unencrypted passwords in the config. Next, make sure you are using SSH or HTTPS for all management. This may not always be possible, but do your best. Lastly, and this is the most important, make sure you review the configs annually. As a bonus, while I realize this can get expensive find a way to log firewall and switch data. I recommend using Splunk for this!

The SANS top 20 and you, Week 3

    Week 3 of the SANS top 20 covers creating secure default setups for software, servers, and end user systems. The tricky part here is defining what is standard, safe and secure. However, if you have a good idea of the hardware and software present, which you should at this point, this becomes a lot simpler of a task. You can start by asking questions about what is present on your network. In my opinion you should know generally who and uses what software and why. I'm not advocating knowing the ins and outs of all software present on your network, but merely being aware of the primary users are. Secondly do some research! You can go to sites such as the Center for Internet Security and the NSA to look for details on configurations of some systems. The great thing here is that once you get a template you can copy it! Microsoft also has a built in base line security analyzer. This allows you to know the status of your Microsoft systems. In addition if you are using Spiceworks or another tool to monitor your network, you can scan for new software or hardware! You can also set switches and wireless access points up to deny unknown mac addresses. I also recommend an annual review of the corporate firewall. In addition develop a process for making changes. This can be as simple as a log that states when the change was made, who made the change, and why! Lastly Sans has intrusion detection worksheets, these sheets allow the creation of an automated baseline of systems. It gives you something to compare systems to if an issue occurs.

The Sans Top 20 and you Week 2

Last week I wrote about the SANS top 20 security recommendations for small business, I focused on the first point, know what you have hardware. I decided this week I would focus on the second point. Know what you have software. In brief software is all of the stuff on your computer which allows you to do things. I would like to make a point here that while the Computers Operating System is software, it's not what I'm referencing this week.

Ok, I work in I.T., and more than once I've been called to someone's desk with a comment on, "My program doesn't work!", To which the typical I.T. response is, "What program?" Part of the issue is as I.T. professionals we don't often go through the trouble of limiting what people can put onto their PC's. After all, people want games, cool fonts, screen saver packages, etc… In this day and age many of those things are done on the internet using flash, but that's not something I'm looking to go too far into this week either!

I remember in one particular case I had a MAC user. Let's go ahead and call him user X. I was doing some traffic analysis on our network using OPENdns. Open DNS allows filtering and metrics on DNS data from networks. It's free and can be checked out at opendns.org. I noticed a lot of traffic going to a series of IP addresses. I did some reputation checking using mxtoolbox, and reputation authority. I found out that these IP's had a nasty reputation for being associated with botnets. I then found out after using the built-in MAC OSX firewall that the traffic was being placed on the net by you guessed it, a screen saver!

This covers why we need to know what programs are on PC's and a little bit of how you can track programs which are negative, but a better approach would be proactive! Spiceworks can check which programs are on your network. It can do this by scanning for .exe's. Spiceworks as I mentioned last week is free, and great to use! You can also use Microsoft's built-in software policies. I most recently used these on a terminal server to force programs to only run from one directory and then locked it down. This also stops people from accidently installing things. I next recommend restricting local admin rights on PC's. This limits the amount of damage that can occur. The last step with things like this is rescanning PC's. No matter how hard you try someone will typically find a way to get unwanted programs onto PC's. Remember, a non-technical solution to this could be a policy which states what is acceptable on a local network. For starters, NO non-approved software!

The SANS top 20 and you Week 1

    I came across some very interesting information the other day. Apparently the SANS institute (System Administration Networking and Security), has a list of 20 items that a business can implement at no cost. I realize that time is money too. Soooo, even if there is no direct monetary value attached to the ideas, someone still has to put them in place. If I was naming this list it would say 20 good ideas for security (definitely a cheap way to get it done). While I won't be covering this whole document right now, I plan to dive into it more over the next few weeks. Here is the link to the article if someone get's to jumpy and can't wait (http://www.sans.org/reading_room/whitepapers/hsoffice/small-business-budget-implementation-20-security-controls_33744)

    Ok, so the real question is why do we care about securing networks? How effective are the ideas listed in this article? According to SANS, the adoption of this program in 2009 resulted in an 88% drop in vulnerabilities. In other words the number of systems which were vulnerable went down a lot. It bears reminding that a vulnerability is a weakness which may be exploited in a system. It is like locking a window in your house. Just because a windows is open doesn't mean a thief will break into it. So, onto the vulnerabilities, let's start with item one on the list.

1. Inventory of authorized and unauthorized devices.
   

Small bushiness's are notoriously busy doing everything in their power to make money. When a computer is broken they buy a new one. When they network goes down they call a guy to fix it. That guy buys some equipment and puts it into place. The problem is solved and business as usual goes on. This happens over a long timeline. No one considers any of it, after all things are working. At some point in this a company get's to a size where they need a little more formal I.T. help. The company may hire an MSP (managed service provider). This MSP may make their network more complicated. They may host the e-mail for the company, or offer to take care of the Anti-Virus system. However, and I can only speak from my experience, they will not document what happens. They won't serialize the PC's on the network and list the MAC (Media Access Control) number. As an interesting aside you can tell a lot by one of these. Most likely what kind of equipment it is or where it came from. Check these links out for further information. (http://www.coffer.com/mac_find/ , http://en.wikipedia.org/wiki/MAC_address). That is because while these things are helpful, they are not vital to the immediate need of a business. However, they are vital to the integrity of a business's information.

    I mentioned some of this in last week's post. I won't belabor the point, but if I knew what the good items on the network were, I could have isolated the bad one by Mac address. So, how does one go about getting this inventory going? There are certainly many ways to accomplish this. However, for free, I would start with spice works. This piece of software will scan your network and figure out what you have on it. If you have managed switches, you can also check the ARP tables (Address Resolution Protocol) on those switches. If you are in a domain environment, and you have a file server, you can check the ARP table there as well. You can even check your DHCP server. This will have the same information. In order to track ongoing changes, SANS recommends sourcefire RNA, this will make alerts when a new device is added. However, I was unable to find any information about getting Sourcefire for free. Spiceworks will do this. While the notification will be less automatic, it will help you notice when something new shows up.

    While this doesn't cover everything in a hardware inventory, I hope it does point out some simple steps.

    
 

     

Documentation is not a four letter word

I have recently found myself in a position where I have begun to appreciate the importance of documentation. A few years ago I worked in a small help desk, most of the time my duties included password resets and some of the smaller minutiae of IT. I remember thinking to myself, "why would I take time to write down what happens?" As luck would have it, I'm no longer working in that role or environment. Information Technology exists for most businesses to keep things running. However, as I've learned recently IT becomes vital to an organization when it exists to help that organizations meet goals. Technology is about making things happen in ways that enhance those it serves.

OK, so I recently found myself in a situation. I was working on a network and found that several PC's were getting rogue DHCP address. I began to wonder if there was an issue. I asked myself, "where is the AP?" I then wondered if documentation of all the WAP's around was available. After a search I found out that it wasn't. So I did what anyone would do. I figured out the IP of the DCHP server. I ended up checking MAC address tables and figuring out which switch it was connected to. Then since I knew where the WAP was relatively, I used a Wi-Fi analyzer to track down the offending AP and disabled it. It turns out this AP wasn't malicious, but it was something a previous admin had left in place and forgotten about.

While the WAP I found wasn't malicious in nature, I did learn several valuable lessons from the experience.

1. Know what is on your network. If you don't have documentation, create it.
   
2. Disable unused ports in rooms. Document
   
3. Make sure you have the capability to track down rogue AP's. This can be as easy as an APP on a phone. WiFi analyzer for android worked for me. (Document what you use and how you use it)
   

While there are numerous other things which can be done, the list I provided is the bare minimum. It is my hope that this article illustrates some simple documentation, and the benefits of having it.

 

 

Introduction

My name is Dan Patterson.  I am a Network Administrator from Omaha, Ne.  I am creating this blog to discuss information security issues, and responses for small and medium businesses.  In my experience many of these smaller companies are unable to afford the manpower or equipment necessary to secure their networks.  Smaller companies face many of the same threats as their larger counterparts, and as such need to have a practical way to defend themselves!