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.