Chris Sanders

There are a lot of things that the industry does well when it comes to network security monitoring (NSM). For instance, I tend to think that we have data collection figured out reasonably well. I also think that signature-based intrusion detection is a really well developed science. However, with NSM having only existed for a short period of time there are several facets of it that aren’t too well defined. One such aspect is the actual diagnostic method that people use to analyze NSM events. That is, the process an analyst uses to connect the dots between the initial alert and the final diagnosis. In this article I’m going to discuss the use of a common medical diagnostic method called differential diagnosis and how it can be applied to NSM.

 

Understanding Normal

The first thing that was ever taught to me when I started my career as an NSM analyst was that if you know what normal looks like, then you can determine what is bad. I trusted in this concept for many years and even taught it to others. As true as this statement may be, I believe it is relied on entirely too much. This is primarily due to a failure in separating the collection, detection, and analysis processes.

 

Collection centers on the hardware and software used to collect NSM related data. Consider the collection of full content packet capture (PCAP) data. The use a network tap and DaemonLogger allow you to store this data on disk so that it may be used for the identification and analysis of network security related events. Collection occurs with a combination of hardware and software.

Detection is the process by which collected data is examined and anomalies are identified, typically through some form of signature, anomaly, or statistically based detection. Snort is software that is an example of signature-based intrusion detection that compares collected network traffic to signatures of known malicious activity in an effort to perform pattern matching to determine if something bad has occurred. Detection is typically software focused.

Analysis is what occurs when a human interprets the results of the output of an identification tool. Although Snort may detect a pattern match in a communication sequence and generate an alert, it is a human who is ultimately responsible for reviewing the alert and investigating it to an end determination on its validity. The key concept here is that analysis is human focused.

 

With those three terms more clearly defined and distinctions drawn, it would stand to reason that the concept of knowing what normal looks like in order to determine what is bad is actually more relevant to detection than analysis. Realistically speaking, it’s not feasible in the modern state of network computing to be well versed in every aspect of normal communications. Although some traffic patterns may remain fairly static, the open nature and loose standards that govern network communication protocols result in a constant evolution of traffic patterns. Don’t be mistaken, this is still an important concept that must be incorporated into the analytic approach, it’s just not strong enough to stand on its own as the singular concept new analysts should be taught. Knowing what normal looks like is best used when analyzing specific facets of a potential breach rather than as a holistic method to classify all network traffic you may be capturing.

 

A Differential Approach

The general goal of an NSM analyst is to digest the alerts generated by various detection tools and investigate multiple data sources and perform relevant tests and research to see if their findings represent a network security breach. This is very similar to that of a physician, whose goal is to digest the symptoms a human presents and investigate multiple data sources and perform relevant tests and research to see if their findings represent a breach in the person’s immune system.  Both practitioners share a similar of goal of connecting the dots to find out if something bad has happened and/or is still happening.

Although NSM has only been around a short while, medicine has been around for centuries. This means that they’ve got a head start on us when it comes to developing their diagnostic method. One of the most common diagnostic methods used in clinical medicine is one called differential diagnosis. If you’ve ever seen an episode of “House” then chances are you’ve seen this process in action. The group of doctors will be presented with a set of symptoms and they will create a list of potential diagnosis on a whiteboard. The remainder of the show is spent doing research and performing various tests to eliminate each of these potential conclusions until only one is left. Although the methods used in the show are often a bit unconventional they still fit the bill as a part of the differential diagnosis process.

The differential method is one based upon a process of elimination. It consists of five distinct steps, although in some cases only two will be necessary. The differential process exists as follows:

1. Identify and list the symptoms
   
   In medicine, symptoms are typically initially conveyed verbally by the individual experiencing them. In NSM, a symptom is most commonly in the form of an alert generated by some form of intrusion detection system or other detection software. Although this step focuses primarily on the initial symptoms, more symptoms may be added to this list as additional tests or investigations are conducted.

 

2. Consider and evaluate the most common diagnosis first
   
   A statement every medical student is taught in their first year is “If you hear hoof beats, look for horses…not zebras.” This is to state to that the most common diagnosis is likely the correct one. As a result, this diagnosis should be evaluated first. The analyst should focus his investigation on doing what is necessary to quickly confirm this diagnosis. If this common diagnosis cannot be determined to be true during this initial step then the analyst should proceed to the next step.

 

3. List all possible diagnosis for the given symptoms
   
   The next step in the differential process is to list every possible diagnosis based upon the information currently available with the initially assessed symptoms. This step requires some creative thinking is often most successful when multiple analysts participate in generating ideas. Although you may not have been able to completely confirm the most common diagnosis in the previous step, if you weren’t able to rule it out completely then it should be carried over into the list generated in this step. Each potential diagnosis on this list is referred to as a candidate condition.

 

4. Prioritize the list of candidate conditions by their severity
   
   Once a list of candidate conditions is created a physician will prioritize these listing the condition that is the largest threat to human life at the top. In the case of an NSM analyst you should also prioritize this list, but the prioritization should focus on which condition is the biggest threat to your organizations network security. This will be highly dependent upon the nature of your organization. For instance, if “MySQL Database Root Compromise” is a candidate condition then a company whose databases contains social security numbers would prioritize this condition much higher than a company who uses a simple database to store a list of its sales staffs on-call schedule.

 

5. Eliminate the candidate condition, starting with the most severe
   
   The final step is where the majority of the action occurs. Based upon the prioritized list created in the previous step the analyst should begin doing what is necessary to eliminate candidate conditions, starting with the condition that poses the greatest threat to network security. This process of elimination requires considering each candidate condition and performing tests, conducting research, and investigating other data sources in an effort to rule them out as a possibility. In some cases investigation on one candidate condition may effectively rule out multiple candidate condition, speeding up this process. Alternatively, investigation of other candidate conditions may prove inconclusive leaving one or two conditions that are unable to be definitively eliminated as possibilities. This is acceptable however as sometimes in network security monitoring (as in medicine) there are anomalies that can’t be explained that require more observation before determining a diagnosis. Ultimately, the goal of this final step is to be left with one diagnosis so that either the incident handling process may begin or the alert can be dismissed as a false positive. It’s very important to remember that “Normal Communication” is a perfectly acceptable diagnosis, and will be the most common diagnosis an NSM analyst arrives at. I also find that remembering that all packets are good unless you can prove they are bad is an important concept to remember during this step.

 

 

Let’s consider this process with a couple of broad case scenarios.

 

Scenario 1

Step 1: Identify and List the Symptoms

Symptoms:

• Internal host appears to be sending outbound traffic to a Russian IP address
• The traffic is occurring at regular intervals, every 10 minutes
• The traffic is HTTPS over port 443, and as such is encrypted and unreadable

Step 2: Consider and Evaluate the Most Common Diagnosis First

It’s been my experience that most entry level analysts will see these symptoms and automatically think that this machine is infected with some form of malware and is phoning home for further instructions. Those analysts tend to key in on that fact that the traffic is going to a Russian IP address and that it is occurring at regular 10 minute intervals. Although those things are worth noting (I wouldn’t have listed them if they weren’t), I don’t buy into the malware theory so easily. I believe entirely too much emphasis is placed on the geographic location of IP addresses, so the fact that the remote IP address is Russian means little to me. Additionally, there are a whole variety of normal communication mechanisms that talk on regular periodic intervals. This includes things like web-based chat, RSS feeds, web-based e-mail, stock tickers, software update processes, and more. Operating on the principal that all packets are good unless you can prove they are bad, I think the most common diagnosis here is that this is normal traffic.

That said, how we can confirm this potential diagnosis? Confirming something is normal can be hard. In this particular instance we could start with some open source research on the Russian IP. Although it’s located in Russia it still may be owned by a legitimate company. If we were to look up the host and find that it was registered to a popular AV vendor we might be able to use that information to conclude that this was an AV application checking for updates. I didn’t mention the URL that the HTTPS traffic is going to, but quickly Googling it may yield some useful information that will help you determine if it is a legitimate site or something that might be hosting malware or some type of botnet C2. Another technique would be to examine the host physically if you have ready access to it in an effort to see if any processes are launched on the machine at the same intervals the traffic is occurring at.

Let’s assume that we weren’t able to make a final determination on whether or not this was normal communication.

Step 3: List all Possible Diagnosis for the Given Symptoms

*There are obviously more candidate conditions in the realm of possibility, but for this and the other scenario I’ve kept it to some of the more common ones for the sake of brevity.

Candidate Conditions:

• Normal Communication
  We weren’t able to rule this out completely in the previous step so we carry it over to this step.

 

• Malware Infection / Installed Malicious Logic
  This is used as a broad category. We typically don’t care about the specific strain until we determine that malware may actually exist. If you are concerned about a specific strain then it can be listed separately. Think of this category as a doctor listing “bacterial infection” as a candidate condition knowing that they can further narrow it down later.

 

• Data Exfiltration from Compromised Host
  Potential that the host could be sending proprietary or confidential information out. This sort of thing would likely be part of a coordinated or targeted attack.

 

• Misconfiguration
  It’s well within the realm of possibilities that a system administrator fat-fingered an IP address and a piece of software that should be trying to communicate periodically with an internal IP is now trying to do so with a Russian IP. This is really quite common.

 

Step 4: Prioritize the List of Candidate Conditions by their Severity

These priorities are fairly generalized since they are dependent upon your organization.

Priority 1: Data Exfiltration from Compromised Host

Priority 2: Malware Infection / Installed Malicious Logic

Priority 3: Misconfiguration

Priority 4: Normal Communication

Step 5: Eliminate the Candidate Conditions, Starting with the Most Severe

Priority 1: Data Exfiltration from Compromised Host

This one can be a bit tricky to eliminate as a possibility. Full packet capture won’t be of the most assistance here since the traffic is encrypted, but if you can create some statistics from this traffic, or better yet, if you have netflow available, you should be able to determine the amount of data going out. If only a few bytes are going out every then minutes than it’s likely that this is not data exfiltration. The host based research you did earlier on the Russian IP address may also provide some value here in determining the reputation of this host. It would also be of value to determine if any other hosts on your network are talking to this IP address or any other IPs in the same address space. Finally, baselining normal communication for your internal host and comparing it with the potentially malicious traffic may provide some useful insight.

Priority 2: Malware Infection / Installed Malicious Logic

At this point the research you’ve already done should give you a really good idea on whether or not this condition is true. It will be likely that by examining the potential for data exfiltration you will rule this condition out as a result, or will have already been able to confirm it to be true.

Priority 3: Misconfiguration

This condition can best be approached by comparing the traffic of this host against the traffic of one or more hosts with a similar role on the network. If every other workstation on that same subnet has the same traffic pattern, but to a different IP address, then it’s likely that the wrong IP address was entered into a piece of software somewhere proving that a misconfiguration exists. Having access to host-based logs can also be useful in figuring out if a misconfiguration exists since they might exist in Windows or Unix system logs.

Priority 4: Normal Communication

If you’ve gotten this far, then the diagnosis of normal communication should be all that remains on your list of candidate conditions.

Concluding a Diagnosis

At this point you have to use your experience as an analyst and your intuition to decide if you think something malicious is really occurring. If you were able to complete the previous analysis thoroughly, then operating on the assumption that all packets are good unless you can prove they are bad would mean your final diagnosis here should be that this is normal communication. If you still have a hunch something quirky is happening though, there is no shame in monitoring the host further and reassessing once more data has been collected.

 

Scenario 2

Step 1: Identify and List the Symptoms

Symptoms:

• A web server in our DMZ is receiving massive amounts of inbound traffic
• The inbound traffic is unreadable and potentially encrypted or obfuscated
• The inbound traffic is coming to multiple destination ports on the internal host
• The inbound traffic is UDP based

Step 2: Consider and Evaluate the Most Common Diagnosis First

With the amount of traffic being received by the internal host being very large and the packets using the UDP protocol with random destination ports, my inclination would be that this is some form of denial of service attack.

The quickest way to determine whether something is a denial of service is to assess the amount of traffic being received compared with the normal amount of traffic received on that host. This is something that is really easy to do with netflow data if you have it available. If the host is only receiving 20% more traffic than it normally would then I would consider other alternatives to a DoS. However, if the host is receiving ten or one hundred times its normal amount of traffic then DoS is very likely and almost a certainty.  It’s important to remember that a DoS is still a DoS even if it is unintentional.

Once again, for the sake of this scenario we will continue as though we weren’t able to make a clear determination on whether or not a DoS condition exists.

Step 3: List all Possible Diagnosis for the Given Symptoms

Candidate Conditions:

• Denial of Service
  We weren’t able to rule this out completely in the previous step so we carry it over to this step.

 

• Normal Communication
  It doesn’t seem incredibly likely, but there is potential for this to be normal.

 

• Misdirected Attacks
  When a third party chooses to attack another they will often spoof their source address for the sake of anonymity and to prevent getting DoS’d themselves. This will result in the owner of the spoofed IP they are using seeing that traffic. This web server could be seeing the effects of this.

 

• Misconfigured External Host
  A misconfiguration can happen on somebody else’s network just as easily as it could on yours. This misconfiguration could result in an external host generating any number of types of traffic and sending them to the web server.

 

• SPAM Mail Relay
  The server could be misconfigured or compromised in a manner that allows it to be used for relaying SPAM across the Internet.

 

Step 4: Prioritize the List of Candidate Conditions by their Severity

Priority 1: Denial of Service

Priority 2: SPAM Mail Relay

Priority 3: Misconfigured External Host

Priority 4: Misdirected Attacks

Priority 5: Normal Communication

Step 5: Eliminate the Candidate Conditions, Starting with the Most Severe

Priority 1: Denial of Service

We’ve already gone through the paces on this one without being able to identify that it is the definitive diagnosis. Even though this is the most severe we would have to proceed to attempt to eliminate other candidate conditions to help in figuring out if a DoS is occurring. Of course, depending on the effect of the attack it may make the most sense to contain the issue by blocking the traffic before spending more time investigating the root cause.

Priority 2: SPAM Mail Relay

This one is relatively easy to eliminate. If the server was being used as a mail relay then you would have a proportionate amount of traffic going out as you do going in. If that’s not the case and you don’t see any abnormal traffic leaving the server then it is likely that it is not relaying SPAM. If the web server is also running mail services then you can examine the appropriate logs here as well. If it is not supposed to be running mail services you can examine the host to see if it is doing so in an unauthorized manner.

Priority 3: Misconfigured External Host

This one is typically pretty tricky. Unless you can identify the owner of the IP address and communicate with them directly then the most you can hope to do is block the traffic locally and/or report abuse at their ISP level.

Priority 4: Misdirected Attacks

This is another tricky one along the same lines as the previous candidate condition. If it’s an attacker somewhere else whose antics are causing traffic redirection to your server then the most you can do is to report the issue to the ISP responsible for the IP address and block the traffic locally.

Priority 5: Normal Communication

This doesn’t seem likely, but you can’t say this for sure without baselining the normal traffic for the host. Compare its traffic at similar times on previous days to see if you can draw any conclusions. Is the pattern normal and it’s just the amount of traffic that anomalous? Is it both the pattern and the amount that’s anomalous? Does the server ever talk to the offending IP prior to this?

 

Concluding a Diagnosis

In this scenario, it’s very possible that you are left with as many as three candidate conditions that you cannot rule out. The good thing here is that even though you can’t rule these out, the containment and remediation methods would be the same for all of them so you still have gotten to a state of diagnosis that allows the network to recover from whatever is occurring. If the amount of traffic isn’t too great then you may not need to block the activity and you may be able to monitor it further in order to attempt to collect more symptoms that may be useful in providing a more accurate diagnosis.

 

Conclusion

I’ve spent quite a bit of time doing analysis with this differential approach and also reviewing previous investigations post-mortem while applying these concepts and I’ve been really pleased with my findings. I think that if you are struggling with being able to grasp a firm analytical method then this may be a great one to start with. I’m not entirely sure that the differential method is appropriate for all organizations, but just as with medicine, there are competing approaches and I hope to examine more of those in the future so that I can draw more comparisons between the medical field and NSM. If you have any scenarios in which you’ve used this differential approach (for better or for worse), I’d love to hear about them.

As a lot of my frequent readers know, 100% of the profits from my books sales and the advertising revenue on this site go to support the Rural Technology Fund, a non-profit I direct that provides scholarships to students from rural areas pursuing degrees in technical fields. We’ve just announced our 2012 scholarship offerings. This includes a brand new offering, a $2500 scholarship available to any high school senior or undergraduate student who attended high school in a rural area, is pursuing a degree in a technical field, and has a strong interest in cyber security.

 

Cyber Security Scholarship

The Cyber Security scholarship is awarded annually to one high school senior or undergraduate college student who is currently or has attended high school in a rural community. In order to be considered for this scholarship, the applicant must demonstrate an interest in cyber security. The student must also be planning to attend college to pursue a degree in a computer technology related field, or already doing so as part of an undergraduate degree program. This scholarship is awarded based upon answers to a series of essay questions that are designed to gauge the student’s passion for his or her intended career in cyber security as well as the student’s sense of citizenship and pride in their rural community. This scholarship is awarded in the amount of $2500.00.

 

Judith A. Sanders Memorial Scholarship

The Judith A. Sanders Memorial Scholarship is awarded annually to a student from the rural community of Graves County in Western Kentucky. In order to be considered for this scholarship, an applicant must currently be attending Graves County High School or Mayfield High School as a senior. The student must also be planning to attend college to pursue a degree in a computer technology related field. This scholarship is awarded based upon answers to a series of essay questions that are designed to gauge the student’s passion for his or her intended career in computer technology as well as the student’s sense of citizenship and pride in their rural community. This scholarship is awarded in the amount of $1000.00.

 

Kentucky Student Technology Leadership Program (STLP) Scholarship

The Kentucky Student Technology Leadership Program (STLP) Scholarship is open to students from schools in Kentucky who have a passion for using technology skills to make a positive social change in the world or at home in their communities. In order to be considered for this scholarship, an applicant must currently be attending a rural high school as a senior in the state of Kentucky and be an active member of their schools STLP. Additionally, the student must also be planning to attend college to pursue a degree in a computer technology related field. This scholarship is awarded based upon answers to a series of essay questions that are designed to gauge the student’s passion for his or her intended career in computer technology as well as the student’s sense of citizenship and pride in their rural community. This scholarship is awarded in the amount of $1000.00.

 

The submission deadline for all three scholarships is April 15^th, 2012. In order to apply, please visit http://www.ruraltechfund.org/scholarships.

 

 

About the Rural Technology Fund

Established in 2008, the Rural Technology Fund (RTF) seeks to reduce the digital divide between rural communities and their more urban and suburban counterparts. This is done through targeted scholarship programs, community involvement, and the general promotion and advocacy of technology in rural areas.

The RTF wants to help rural students recognize the opportunity in technology careers and gain the education necessary to work in the computer industry.

I’m excited to announce that I, along with my good friend and colleague Jason Smith, will be speaking at the DHS US-CERT Government Forum of Incident Response and Security Teams (GFIRST) Conference in August. The conference is being held the week of August 7-12 at the Gaylord Opryland Hotel in Nashville, TN. We will be speaking at 1 PM on Wednesday, August 10th.

Title: Real-World Security Scripting

Abstract:

Scripting serves several purposes within a security operation center (SOC). You can write scripts to automate common tasks, to perform actions on large amounts of data, or to perform calculations and correlation on data sets. Given a bit of time an analyst can do great things with an interpreter and a little bit of elbow grease. Over the past few years our team has found that a lot of incredibly useful analysis tools can be created with only a minimal amount of programming knowledge.

In this presentation, we are going to educate our audience on how to get started with scripting for SOC related functions. Don’t be fooled though, this isn’t your typical scripting lesson. We aren’t going to ramble on about data types, expressions, and syntax formatting. Instead, we are going to look at real scripts we use in the SPAWAR SOC every single day. We will step through as many scripts as time permits while showing effective methods for automatically parsing netflow data for known malicious hosts, extracting payloads from PCAP files for content or entropy analysis, and more. We will go through the process of creating each script from inception to production.

A few specific scripts we will break down include:

• Updating a snort ruleset across multiple sensors
• Automated reporting of known malicious IP addresses and domains with netflow data
• Extracting the data payloads of packets in PCAP files
• Retrieval and concatenation of PCAP data from multiple sources
• Automatic parsing of netflow data into various graphs for visual traffic analysis

 

The tools covered will be a mix of BASH, PERL, and Python. No prior scripting knowledge is required to gain value from this presentation. We will be providing source code for all of the scripts we are discussing as well as a few extras. As a bonus, we will even provide versions of some of these scripts that can be integrated into Arcsight or other SIEM products to extend their capabilities. At the very least, attendees will walk away with scripts they can implement into their production SOC immediately. The real value of this course however, is a real world crash course in scripting for analyst-centric SOC functions.

 

You can read more about the GFIRST conference at http://www.us-cert.gov/GFIRST/.

 

 

Look forward to seeing you there!

 

It happens pretty often that I’ll come across an interesting PCAP file that I want to share with others. Unfortunately, divulging these packet captures can give away certain sensitive information such as an organizations internal IP range, IP addresses of sensitive company assets, MAC addresses of critical hardware that could identify the product vendors, and more.

Fortunately, there is a tool which helps alleviate some of these issues. The tool is called Tcprewrite and is actually a part of the Tcpreplay suite. Tcpreplay is used to send packets from a PCAP back across the wire, but the suite actually contains a few other useful tools.Tcprewrite itself can be used to add and modify packet fields within PCAP files. For example, if you wanted to replace the layer two addressing information within a PCAP so that all of the packets have a specified source and destination MAC address you could use the following syntax:

tcprewrite --enet-dmac=00:55:22:AF:C6:37 --enet-smac=00:44:66:FC:29:AF --infile=input.pcap --outfile=output.pcap

Tcprewrite can do neat things at layer four as well, including remapping ports used in sessions. The following example will remap all port 80 traffic to port 8080.

tcprewrite --portmap=80:8080 --infile=input.pcap --outfile=output.pcap

The examples shown above were taken directly from the tcprewrite wiki page (http://tcpreplay.synfin.net/wiki/tcprewrite) where you can find quite a few other usage examples.

The real value of tcprewrite, and the reason for this article, is its ability to randomize the addressing information in a PCAP file. This is done with the following syntax:

tcprewrite --seed=423 --infile=input.pcap --outfile=output.pcap

In this line, the seed option is used in the randomization of the addresses. This will replace all of the IP addresses in the IP headers of the packets and will also modify any ARP packets in the traffic accordingly.

From what I’ve been able to determine this option doesn’t randomize and rewrite and MAC addresses, which is a bit of a problem since MAC addresses can give away the vendor of a piece of hardware. The last thing I want is the entire world knowing that I use Cisco/Juniper/Enterasys/Etc based external firewalls. The ability to rewrite MAC addresses is there but its not random. What you can do in this case is to split a PCAP file into two separate files representing each direction of traffic. This can be done with tcpdump or tcpprep, which is a part of the tcprewrite suite as well. Using tcprewrite you can split the traffic like this:

tcpprep --auto=bridge --pcap=input.pcap --cachefile=input.cache

From there you can use syntax similar to what was shown above to replace the MAC addresses. This isn’t randomized so you will basically have to make something up. At the very least I’d recommend replacing the OUI section of the MACs. That syntax would look something like this:

tcprewrite --enet-dmac=00:44:66:FC:29:AF,00:55:22:AF:C6:37 --enet-smac=00:66:AA:D1:32:C2,00:22:55:AC:DE:AC --cachefile=input.cache --infile=input.pcap --outfile=output.pcap

It wouldn’t be too much of a stretch to write a python script that uses tcpprep and tcprewrite to automate the randomization of MAC addresses as well.

You can download tcprewrite as part of the tcpreplay suite at http://tcpreplay.synfin.net/ or just apt-get/yum install tcpreply. The tool is Unix only (or you can use Cygwin if you are tied to Windows).

SPAM and Phishing are both really big problems for pretty much an organization right now, and it appears to only be getting worse. One of the most common tactics used by spammers is to forge legitimate domain names in the e-mails this send. The goal here is to trick a user in to opening of these messages, or at least to get them through a SPAM filtering service to a users inbox.

The best way to prevent your e-mail domain from being spoofed is through the use of Sender Policy Framework (SPF) Records. This is basically a DNS TXT record that mail servers and spam filtering services access to verify the source of e-mail messages as they arrive.

In order to create a SPF record, start by opening the DNS MMC snap-in. From here, browse to the forward lookup zone for this DNS server, right click in the blank area, choose Other New Records, and select Text (TXT). The typical value for this record (minus the quotes) should be “v=spf1 a mx -all”. What this says is that all mail that is received from an IP address listed that’s listed in the sending domains A or MX records is legitimate. This will suffice for most companies, but in the case that you want to get a little stricter with this, you can use an entry of “v=spf1 a mx ip4:192.168.1.2 -all”. This basically specifies 192.168.1.2 as the only IP address that valid mail can be sent from.

It is considered a good proactive security principle to configure an SPF record for your domain, regardless of whether you are having SPAM/Phishing problems or not.

One of the new features in Windows Server 2008 that is getting the most attention is the introduction of the Read-Only Domain Controller (RODC).

If you manage a network that utilizes more than one domain controller then you are aware of Active Directory’s multimaster replication structure. In this architecture, any change made to active directory on any domain controller is replicated to all of the others. This has made administration a breeze in the past since administrators could make a change at any remote site and it be reflected on all of the domain controllers in the network.

The problem here arises with the threat of a security breach. Managing network and physical security at remote office location has always been a challenge. If an intruder with malicious intentions gained access to an organizations domain controller at a branch office, he/she could easily destroy the whole active directory infrastructure throughout the ENTIRE organization.

Microsoft has addressed this issue with the development of an RODC. An RODC is designed for branch offices where the network conditions require a local source of authentication but a lack of physical security monitoring and localized administration makes placing a domain controller a security risk. The RODC only allows for one way replication. That means active directory information can be replicated to it from another domain controller, but it may not replicate information to any other domain controllers.

With an RODC deployed at a branch office, an individual with malicious intentions can not make modifications to the active directory infrastructure, therefor alleviating the security risks we have mentioned.

You can deploy an RODC by simply choosing the appropriate option when running the dcpromo utility during domain controller promotion.

If your organization does any type of business over e-mail, then you need to be saving every single e-mail sent and received from your e-mail system. Period. End of story. No way around it.

This need for this was something I had always been aware of, but wasn’t something I completed acknowledged until an IT strategy meeting with a local client. That client asked a pretty simple question; “If I am involved in some form of litigation and I have to show proof that an e-mail was sent at a certian time with specific content, and that this e-mail has not been tampered with, how am I going to make this happen?”

Unfortunately, this isn’t just one of those things that are nice to have….it’s required. Thanks to the Sarbanes-Oxley Act of 2002, public companies must prove:

“their internal controls and audit trails are sound and that their processes are capable of producing certifiably correct data. Companies must retain all correspondence created, sent, or received “in connection with an audit or review” of a public company for a period of seven years, during which time these records must be non-erasable and non-rewritable.This includes any “electronic records” such as email, particularly relating to subjects, departments or individuals involved in auditing procedures. Failure to comply is a crime, punishable by up to 10 years in jail.”

So what type of system can be implemented in order to make this happen? Well luckily, there is a whole section of the IT industry devoted to this. Some of the more popular products that achieve this goal include:

• GFI MailArchiver
• Barracuda Message Archiver
• EMC EmailExtender
• Symantec Enterprise Vault

Any of these products and several more not listed can help you to implement a secure compliant method of archiving e-mail messages. These solutions aren’t exactly cheap, but the return on investment will come quickly when being able to reproduce an e-mail saves your company from a multi-million dollar lawsuit.

Microsoft Exchange is the most popular e-mail server application on the market. Unfortunately, when implementing an Exchange server, security is often overlooked. There are a lot of considerations when thinking about Exchange Security. One of the best places to start is by running the Baseline Security Analyzer. You can download it here: http://www.microsoft.com/technet/security/tools/mbsahome.mspx. A few other quick tips include running the Exchange Best Practices analyzer (link), requiring SSL connections for Outlook Web Access (link), using Kerberos authentication rather than the NTLM (link),

Most people have heard horror stories about employees who are fired and then proceed to go on a violent rampages through an office as they exit. It is for this reason that most organizations have policies in place that require terminated employees to be escorted of the building by a security officer or member of upper level administration.

This same policy can be applied to network administration. I have heard countless tales of network uses whose last act before leaving the building after being fired is to romp across any server they have access to deleting files as they go. In all honesty, if a disgruntled former employee ONLY deletes data then you are getting off easy. How about if the employee has access to business critical informationa nd takes a copy with them when they live to sell off to the highest bidder? What if it is a member of the IT staff who has just been fired and he/she decides to change all of the domain administrative passwords or delete the NTLDR file on the domain controller? Even worse, what if the employee has access to sensitive financial information about employees including account numbers and social security numbers?

What I am getting at here is that every organization needs to have a policy in place for limiting the technical resources of a user after they have been terminated. This includes disabling their user account, changing and departmental or administrative passwords they have access to, disabling corporate e-mail access, and locking down access to their personal workstation. In most cases you won’t want to immediatly delete all of their account information, but disabling it and/or resetting passwords is the perfect option until you get the go-ahead from management to trash it all. This can be done manually by a particular member of IT staff or can be setup in an automated fasion through the use of a script.

Every single service or device on your network has at least one point of failure. That is, any point on a network that when in a failure state can cause a service to no longer function. Thinking small, a PC has several points of a failure…the power supply, the motherboard, the hard drive, each one is a point of failure for that PC. Thinking on a larger scale, a service on a WAN might have dozens of points of failure…the router on either end of the WAN link, an internal switch, a network cable.

The goal is to have as few points of failure as possible for any service. A lot of this is achieved by making sure the layout of your network is conducive to having only a few points of failure. The other primary method of ensuring this is through redundancy. A two-node server cluster will eliminate the point of failure should one server crash. Don’t let that false sense of security trick you though, if you have two redundant servers sitting in the same rack, a spilled cup of coffee and ensure that rack as another failure point

The point of this is that you should always be aware of the points of failure on your network for its mission critical services. This will result in fewer disasters, and quicker disaster recovery should there be one.

If your organization relies on technology to any reasonable extent then the chances are that you have servers responsible for several different services and roles. These roles and services can vary from database, to file, to web, to application services. These services all require some form of network communication and use a port to do so. The more services on a computer, the more ports open on that computer.

Nothing looks more juicy to a possible intruder than a machine sitting somewhere with forty-two different ports open on it. It is basically a big red flag saying “Hey! Exploit Me!” This being the case, service isolation can really deter a possible intrustion attempt. If a hacker sees several boxes each with only one or two ports open then they are a lot less likely to even bother with scanning the machines.

There are several ways you can go about service isolation. One of the most effecient ways is to leverage the use of Microsoft Virtual Server (or VMWare server if that is your cup of tea). Doing this you can still achieve a lot of the goals of server consolidation while maintaining a better security baseline. Even though all of these services are still running on the same physical server, them running on different virtual machines makes it appear as if they are all running on seperate machines to those looking in from the outside.

Would you allow somebody to bring a laptop into your corporate headquarters and plug it directly into an Ethernet port? Then why would you allow someone easy access to your network via its wireless infrastructure? That is exactly what you are doing when you do not invest in the security of your wireless network.

It is so common to talk to a Network Admin and listen to them tout the security of their WEP or WPA enabled wireless network. WEP, WPA, and similar technologies are very easily surpassed by even the most novice of hackers. It is for this reason that I refer to securing a wireless network as “investing” in its security. That is because relying on just the individual wireless access points security is not enough.

If your wireless infrastructure is of any reasonable size then it is a safe bet to say that you should look into spending some extra money in securing it. How do you do this? There are a variety of different ways you can go about implenting server based wireless security. The most common (and secure) is RADIUS based security with the enchancements of certificate based authentication. This ensures thats only the wireless clients listed in a RADIUS database on a physical server and holding a certificate pushed out by group policy will be able to authenticate to the network. If someone wishes to compromise the security of your wireless network then they must also compromise the RADIUS and certificate servers. There are several other ways to secure your wireless network beyond WEP/WPA, and I highly reccomend looking into them.

Remember, you can never destroy all of the paths a hacker can take to compromising a device or service. You can however put plenty of hurdles in the way of those paths ot make the process a lot harder.

The administrator account is perhaps one of the most sacred things there is on your network. I am not talking about the Domain Administrator account however, I am referring to the local administrator account. Obviously the domain administrator account has the most power out of any account in your network, but the fact of that matter is that you shouldn’t be logging in with this account anywhere anyways, and it is something that should be nearly impossible to crack from a hackers standpoint.

The local administrator account is where it all begins. If someone is going to break into your network the first thing they will need is to gain administrative priveleges on a machine. If you can protect this account successfully then you are doing a good job of stopping internal attacks at the front line.

This being the case, how do you protect this account? Obviously, the first thing you will want to do is use a strong password. People should not be logging in to computers with this account so it is okay to make it something insanely long that nobody would really want to type. Be sure to use uppercase letters, lowercase letters, numbers, and even a few symbols when setting these passwords. In larger environments you will also want to make sure that the administrator accounts on all your computers vary by location. It is not too pratical to make a different password for every single computer, however you can make multiple passwords for various departments, locations, subnets, etc. These passwords should be changed frequently, as in monthly. If you want to get really creative you can do some scripting paired with group policy to make this task a lot easier.

One more thing you can do is to to completely disable the administrator account all together. This will make sure nobody is logging into it. However, this isn’t always feasible in some cases. Another solution I have often heard is renaming the administrator account. If you rename your administrator account to something other than “admin” or “root” that adds a completely new step of enumeration an attacker has to go through before beginning to try and compromise a system. A lot of the times you can deter an attacker just by making them jump through some extra hoops along the way.

I got to looking at my calendar and noticed I had scheduled a User and Group permissions audit for today. I try to do these at least once every quarter and I am very glad I do. In an environment where you have multiple people who exercise their ability to assign permissions to various resources you can very quickly get people who aren’t on the same page assigning permissions that they shouldn’t be.

Completing this type of task may seem daunting once you start counting up the various network resources you have (printers, shared storage, etc) but if you get an organized system going it really flies by quickly. I typically make an excel spreadsheet where I have a heading for every network resource and a row for every group or user that has permissions assigned to it. From there I make a columns for the type of access assigned (read, write, modify, etc) and place an “X” in the ones that apply to the user or group.

As an added bonus, if you do your audit via the spreadsheet method I mentioned above, you can easily transfer this to a mobile device such as a laptop or PDA in order to have a quickly accessible reference to resource permissions when you are away from the network.

If you have never done a permissions audit on your network I highly recommend scheduling a few spread out across a year. I can guarantee that you will be surprised at some of the things you find.

Network security has gotten to a point where it can no longer be an afterthought. Every application you implement, every device you install, and every user you create must be done so with the utmost security in mind. In a world where technology is integrated into every facet of our lives we must do everything we can from a technical standpoint to ensure the integrity of the technology we rely on. Waiting for a problem to happen and then responding to it is something that can’t continue to happen if we hope to persist in securing our networks. If we ever hope to achieve a consistent level of network security it must be thought of as a proactive concept rather than a reactive one.

With these thoughts in mind, over the course of the next few weeks I am going to be releasing a series of brief articles here regarding proactive security. These are measures that you can take in order to possibly prevent future security issues on your network. This will cover a broad scope of both technical solutions as well as company policies that you can implement in order to achieve a more proactive state of though in regards to network security.

I have several of these articles already lined up for publishing. As always however, I love to hear of things you are doing on your network that would fit into the category of proactive security. If you have anything you would like to see on this site please send it to me at chris@chrissanders.org. You will be given full credit on the site for your contribution as well as a link back to your website if you have one.