Not a week goes by without an email from someone asking me to how to create a baseline or worse, requests to review a baseline. I will explain both points before moving on.
Asking how to create a baseline
Spoiler alert, there is no real baseline ‘standard’ or ‘template’ that will meet all your needs. Of course there are typical things that you always document, but after that, it gets very specific. Even different departments will use the same software differently.
A great example is Microsoft Outlook, a sales person will use the contacts like a CRM with conversation notes and follow up dates, where an IT person will use the same contacts feature to simply record contact info.
This is why I usually ask the I.T. specialist to spend a little bit of time with the user to determine how they use the software, basic tasks, etc before capturing packets.
Requests to review a baseline
The reason why I say this is scenario worse is because many times someone is asking me to help interpret what someone else did years ago.
Here is specifically why this never works out:
Methodology not documented
Goal for baseline not documented
Network and related equipment has changed
Application has changed since baseline
In most cases, I recommend on starting a new baseline, using the old one as a reference.
Moving on
Baselines are critical when migrating to the cloud, moving your servers to a recovery site or configuring firewalls or routers for remote access.
As I mention in the video, a baseline doesn’t need to be 100 pages or take weeks to compile. I find the shorter, concise ones that you can combine for a more comprehensive baseline, are far more helpful.
A simple example would be to create separate captures of the application launch, login and common task. That way if there are performance complaints about the login, you can compare fewer packets.
A helpful tip that I use is called ‘packet bookmarks’ where you create a predicable packets in your trace in between tasks. Using the previous example, I would ping thetechfirm.com in between tasks, if I was using a packet capture tool that provides one trace of my baseline.
Another example of using the ‘packet bookmark’ technique is when baselining or troubleshooting an application that constantly receives or transmits packets, like VOIP, terminal services some CRM and email applications.
Getting Started
I would suggest that anyone who wants to baseline, troubleshoot or as a way to get familiar with how applications work simply take short traces of any application you are familiar with.
Applications such as email, web browsing, VOIP, IM, printing, file sharing and other streaming services are a great way to get familiar with protocol analysis. As you go through different applications, you will develop techniques and skills to help you along the way. Smaller traces are easier to analyze and even if you don’t have time to analyze the traces, simply give the trace files a meaningful name and put them in a folder with an equally good description. Then you can review them whenever you have a moment.