Network Doctor is a growing managed services provider (MSP) focused on providing a “white glove” level of service to its 80 clients.

“One of our main goals is to be proactive to help our clients maintain the highest possible amount of uptime,” says Andrew Kropf, who heads up the company’s network and data center operations, including all of Network Doctor’s cloud offerings.

“Success for us means as few unpredicted problems as possible, no failures we didn’t get an alert on, no services stopped, no impacts to users.”

Network Doctor’s existing network monitoring tool wasn’t up to the task.

“Our previous solution wasn’t telling us about new equipment being added to the network so we weren’t fully up to date on the client’s environment, and we couldn’t see what was connected where,” says Andrew.

“It wasn’t doing discovery or initial auditing. Onboarding took a lot of time because we had to physically find the equipment. We also had to manually input all the inventory into ConnectWise, our PSA tool, once we found it.”

That’s when Andrew discovered Auvik.

Hear Andrew and managed solutions engineer Ryan Contompasis share how Auvik’s network infrastructure RMM has helped Network Doctor cut ticket resolution time, automate manual processes, and slash onboarding time by 75%.

Download a PDF copy of the complete Network Doctor case study.

The post Growing MSP Uncovers Huge Service Efficiencies With Network Infrastructure RMM appeared first on Auvik Networks.

Ed. note: This week we are pleased to bring you a guest post from Liberty Technology, a company that’s breaking ground in applying agile methodologies to their service provider business.

It’s time MSPs rethink how services are delivered if they are to survive. Traditional and accepted ITIL methodologies need to be challenged and improved. For several years, there’s been chatter about new and innovative alternatives but nothing has surfaced as a reasonable, well-thought-out alternative.

We believe agile methodologies are the catalyst needed to revolutionize managed services.

Agile began in manufacturing and has been long applied to software development. Studies show that using an agile framework leads to increased productivity, higher quality outcomes, increased business stakeholder satisfaction, and reduced cost of implementing solutions.

The same problems that plague manufacturing and software development also affect the quality of service delivered by MSPs. So at Liberty, we’ve implemented the best and most appropriate aspects of agile in our day-to-day.

The results have been tremendous: Within six weeks, our average open ticket count dropped by 50% and our customer satisfaction rating rose by 7%.

Here are four agile components we implemented and the successes they generated.

1. Kanban to visualize work in progress

   Keeping work moving is integral to increasing productivity and decreasing waste. Service boards are a great way to track and manage incidents, but they lack the visual elements crucial to fully understanding the status of tickets and projects throughout the company.

   Kanban is an illustrative way to see work in progress and to quickly identify roadblocks.

   Liberty Technology has been using ConnectWise to display customized ticket reporting and dashboards for years. But when we started down the path towards an agile practice, we realized the need for service tickets to be visually reflected on kanban boards.

   So we paired ConnectWise with a software tool called Kanbanize. Using the robust APIs from both systems, we now have tickets from our service board showing on a kanban board. Changes in status from either system update the tickets appropriately.

   “Before [agile], we relied on a simple list when reviewing our tickets,” says Liberty engineer Drew Dutton. “While it worked to remind us what we were working on, it didn’t do much to show us where those tickets were in the process. Now with a quick glance we can see … which issues might require immediate action.”

2. Daily standup meetings

   We begin every day with a 15-minute standup meeting. During these meetings, we show the kanban service board and each technician speaks to all of his open tickets. Conversations evolve with comments like, “Hey, I worked with Sally on that same issue last week,” or “Let me take that from you. You’ve got enough to do today.”

   Patterns begin to emerge and efficiencies develop. This played a big part in our 50% reduction in open tickets.

   Daily standup has become “the most collaborative and productive part of the day,” says Dutton. “It has gone from a progress report to something we look forward to every morning.”

   An unexpected but welcome side effect to the daily standup is a greater focus on updating tickets. Like many MSPs, we’ve always been challenged to motivate technicians to enter their time on tickets and capture the details of the work. Turning it into a conversation rather than an end-of-the-day data entry nightmare has significantly improved the timeliness and completeness of our tickets.

3. Real-time communication tools

   A service provider’s backlog is fluid and can change dramatically depending on critical outages or other unexpected support requests. Ongoing conversation throughout the day really makes a difference to handling this constant flux.

   To bring some order to reactive fixes while maintaining the constant communication needed within an agile team, we’ve implemented Slack. This collaboration tool archives and indexes chat messages within teams, company-wide groups, and between individuals for constant direct connection and absolute searchability.

   We attribute the 7% increase in our customer satisfaction rating to the increased interaction that has emerged from real-time communication.

4. Time-bound cycles aka scrum

   Scrum is an agile framework that focuses work into tight incremental cycles that can be summed up as “create, review, improve.” Implementation is broken into smaller timeframes, and stakeholders can review progress early on and provide feedback to avoid costly mistakes.

   The managed service business does not traditionally align with this method of delivery due to the random nature of issues, but we’ve found that scrum within our organization is very powerful.

   Our service team now works in two-week sprints. At the beginning of each sprint, we plan what we’ll implement. Following the sprint, we stop and complete a review to capitalize on the things that worked well and to identify areas that could be better in future implementations.

We feel our successes at Liberty are proof that agile methodologies can be leveraged in IT managed services, infrastructure/endpoint support, deployment projects, and general business. Join us in a movement that’s well past due!

The post Agile Methodologies Transformed Our MSP appeared first on Auvik Networks.

The news has lately been thick with reports of major attacks on corporate networks. In the cases of the Panama Papers, the OPM leak, and the Hacking Team leak, the results were catastrophic leaks of extremely confidential information.

In each case, the organizations that were hacked spent a great deal of time and energy on PR after the fact downplaying the significance of the leaks. But in each case, the hacks were made possible because of basic flaws in the network infrastructure and a failure to take security seriously.

Perhaps the worst recent attack was the case of the Bangladeshi central bank. Reports suggest they did almost nothing to secure their infrastructure prior to the attack, and it wound up costing them many tens of millions of dollars.

In truth, a determined and well-resourced attacker can always find a way in. If your information is of value or interest to a foreign government, you should probably assume they’ve already taken it. But in the Panama Papers and Hacking Team leaks, the attackers were probably independent, non-government hackers.

In all of the cases, though, there were critical errors made in securing network infrastructure.

The good news — and the bad news

Right now, the most worrisome network threats fall into four main categories: malware, phishing, denial of service (DoS) attacks, and advanced persistent threats (APTs).

The good news is that it’s neither extremely hard nor overly expensive to mount a reasonably effective defense.

The bad news is that it’s impossible to create a perfect defense. In particular, you can’t keep determined, skilled, and well-resourced attackers like government agencies away from your data. They’ll always be able to find and exploit vulnerabilities in your defensive security infrastructure.

So let’s focus on the more manageable task of keeping out the routine criminals.

1. Malware and ransomware

Malware is the modern term for what we used to call a computer virus. The term has changed because the threat has changed—today’s malware is much more dangerous. It’s usually deployed starting with a small “dropper” program that then contacts a command-and-control host (variously abbreviated C&C, CC, or C2) to get further instructions and download additional malware.

One of the most dangerous and growing types of malware is crypto-ransomware, which immediately sets about encrypting all your files, including all files on any network shares. It then offers to give you the key to unlock your files in exchange for paying a ransom.

Defenses against malware and ransomware

Most malware isn’t targeted. By that I mean it’s produced with the general intent of catching somebody—anybody—not you in particular.

Malware writers often exploit software vulnerabilities in common applications like your web browser, Flash, Word, or Excel. In many cases, they also exploit operating system vulnerabilities.

First line of defense

There are two critical elements in a first line of defense against malware.

First, keep up with software patches. If you apply all patches as soon as they’re released, you’ll be ahead of just about all malware threats.

Second, use a good endpoint protection system. Endpoint protection is what we used to call anti-virus software. Traditional anti-virus software relied heavily on file signatures. Whenever a new file appeared on your computer, the anti-virus software would scan it. It would calculate an overall file checksum that it could compare against a database of known malware, and it would scan through the file to see if it contained a sequence of bytes associated with any known malware.

Anti-virus packages are still valuable tools, but the problem is that malware writers have started adopting clever tricks like encrypting the code with random and frequently changing keys. That means the malware will never appear with the same checksum twice, and the internal byte sequences will be obscured.

To combat random keys, modern endpoint protection software generally includes some sort of sandboxing feature. The suspected malware is unpacked in a safe, virtualized environment and allowed to install itself and run while the scanning software carefully monitors it for signs of any malicious actions.

But the fight against malware is an ever-escalating battle. Malware writers have started building special sandbox avoidance techniques that detect when they’re running in a sandbox instead of a real system.

So most good endpoint protection systems also monitor the real endpoint workstations for signs of malicious software actions and try to block the malware before it’s too late.

Photo: Erik Drost on Flickr

Second line of defense

The second line of defense in protecting infrastructure from malware is to assume the first piece of malware will actually be a dropper, and that it will reach back across the Internet to a Command and Control server for further instructions and further software packages.

Modern malware is often highly modular, so we can often catch the infections by implementing good scanning on the network edge. This is different from a traditional Intrusion Detection System (IDS), which generally monitors inbound connections. Here, we’re monitoring outbound connections.

We’re looking for several key indications of compromise including:

• Connecting to known malware domains or C&C systems
• Downloading suspicious files
• Traffic patterns that appear to indicate interactive VPN-like activities, which might indicate a remote access Trojan (RAT)

But be aware! In the case of common ransomware infections, additional command-and-control action often isn’t necessary. The initial piece of malware just starts encrypting every file it can read and keeps going until you stop it. If it’s been allowed to unpack itself and start running, it’s probably already too late.

The best defense against encrypting ransomware is good old-fashioned backups. Find and shut down the infected machine, then start restoring files from the backup.

If you keep the backups offline or otherwise inaccessible to normal users, and if you take backups at least daily, then your exposure is limited to whatever has changed in the last 24 hours. It isn’t great, but it’s usually not a disaster. And it’s certainly preferable to paying ransom, since there’s little reason to believe the criminals will actually give you the decryption keys after you’ve paid.

2. Phishing

I actually don’t consider phishing to be an IT security problem. It’s a social engineering attack in which an attacker contacts a person inside the organization, often through email, and tricks that person into doing something.

In some cases, the person is tricked into transferring money to the attacker’s account. In other cases, the target is tricked into installing or running software that helps the attacker with the next stage of their attack.

Because phishing isn’t really a technological attack, technological solutions are generally ineffective. Closing the door to an email-based phishing attack doesn’t necessarily close the door against a similar attack conducted over the telephone or through the mail. This is old-style fraud — it has always existed and it will always exist.

Defenses against phishing

There are two main defenses against phishing.

The first is education. You can reduce the chances you or your client will suffer from a phishing attack if everyone is vigilant and aware of what phishing looks like. But this really only reduces the chances. An extremely clever attacker will always be able to come up with a convincing ruse.

What would happen if they emailed a realistic looking invoice to somebody in the Accounts Payable department, designed to look exactly like it came from one of your suppliers? It’s almost certain the message would be opened. The same would be true of a realistic resume sent to the HR department.

So the other defense against phishing is procedural. Make it a well established and rigidly adhered to process that money transfers are never done without verbal confirmation from a small number of specifically named individuals. The CEO will never send an email to the head of accounting requesting a money transfer to a mysterious supplier in a foreign country. And even if they do, standard procedure is to call the CEO’s cell phone and verify the instructions.

If the phishing attack is a method of deploying malware, then you can at least fall back on the malware defenses mentioned in the previous section.

Photo: madmrmox on Flickr

3. Denial of service

Denial of service (DoS) attacks can be launched fairly easily by unskilled attackers, and they can be carried out without needing access to your internal infrastructure.

The simplest DoS attacks try to overwhelm your Internet link by sending huge amounts of traffic so that legitimate business traffic gets shut out. More sophisticated DoS attacks involve less traffic, instead using up other network resources.

DoS attacks are sometimes done to disrupt business and sometimes to extract a ransom to make the attacks stop.

Defenses against denial of service

The trouble with most DoS attacks is that once they hit, they’ve already used up your Internet resources. It doesn’t help to throw away malicious packets if there are so many of them that the link is full.

You really can’t protect against most DoS attacks. The best approach is to use a protection service provider like CloudFlare or Arbor Networks to interrupt the attacks somewhere upstream from your infrastructure.

Protection services typically work by directing your traffic through their infrastructure before it gets to you. They’ll either automatically detect attacks or allow you to specify you’re under attack. Then they simply redirect the malicious packets into the trash can, and only forward the legitimate traffic to you.

Another good and popular way of mitigating DoS attacks is to put public-facing infrastructure on a cloud service provider with ample resources. That way, if you’re attacked, there’s no effect on your real infrastructure, just on the web hosting provider, which will generally have robust DoS mitigation systems.

More sophisticated DoS attacks seek to disrupt web infrastructure without necessarily using lots of traffic as the attack mechanism. Instead, these mechanisms use software vulnerabilities in the web hosting systems to take the systems off-line, or they use up all resources on those systems to prevent them from accepting new connections.

Since the more sophisticated attacks are generally based on software vulnerabilities, it’s hard to create permanent defenses against them. But regularly patching Internet-facing infrastructure goes a long way to minimizing risk.

4. Advanced Persistent Threats

Advanced persistent threats (APT) are the attacks everybody fears. In an APT, the attackers manage to build a back door into your infrastructure, then carefully extract your most valuable data. The effectiveness of this type of attack depends on the skill of the attackers and your ability to detect and stop them.

APT attacks often start out as malware or phishing attacks. The attacker has to somehow get a foothold inside the infrastructure. Then, typically, the attacker instructs the initial dropper software to download a remote access Trojan, which is like a VPN that allows them interactive access.

I say typically because there have been a few cases where APT attacks have happened entirely without external feedback, but it’s a ridiculously difficult way to attack a network, and nobody would do it this way if they had the option of interactive access.

Defenses against APTs

The defenses against APT attacks include everything we said about malware attacks. It’s also useful to monitor your Internet links for the typical signatures of RAT-like traffic patterns. However, if your attackers are skilled, an APT attack can go undetected for considerable lengths of time as they move laterally within your network looking for valuable data.

For this reason, in addition to prevention and detection, it’s useful to have good forensic abilities when it comes to APT attacks. In particular, it can be very useful to maintain thorough logs of every access to every file and system on your infrastructure so you can reconstruct what user IDs accessed what resources from what systems. This is most easily done using the Active Directory or LDAP server logs.

Another useful forensic capability is some sort of packet capture or traffic flow monitoring tool. NetFlow-based systems can keep track of every conversation that takes place, including source and destination addresses, protocols, and amount of data transferred. This is often supplemented by detailed packet capture data, which can show you exactly what was transferred.

What next?

In my next blog post, I’ll get more specific about tactics that can help secure network infrastructure against attack. I’ll focus particularly on network architecture, since good architecture is a critical element of secure infrastructure.

The post Defending Network Infrastructure Against Attack – Part 1 appeared first on Auvik Networks.

Last week, we discussed how perfect network security is impossible. A determined and well-resourced attacker can always find a way in. Your goal is therefore to cover as many of the risk areas as you can with the budget you have.

In this post, we take a look at ways at effective ways to block most inbound and outbound network attacks.

Defending a network against inbound attacks

By inbound attacks, I mean traditional hacking attempts against a network’s front-door elements like web servers, web applications, email systems, and remote access (VPN) systems.

Firewalls

The first and most obvious security element against inbound attack is a firewall. Pretty much any commercial firewall is suitable, but I generally recommend using a more sophisticated next-generation or unified threat management (UTM) firewall.

A firewall is a network device more than it is a security device. It facilitates connection between your internal network and the public Internet. Since everybody these days uses private IP addressing, a firewall is the right place to do address translation between internal and external address spaces.

A firewall also has the ability to filter incoming or outgoing connections based on simple Layer 3 and Layer 4 elements in the packet header. These include internal and external IP addresses, as well as TCP and UDP port numbers.

A firewall also has to be stateful, which means it keeps track of every individual session passing through it. You shouldn’t be able to get packets past a firewall simply by constructing them to look like part of a pre-existing session.

The problem with basic firewalls is that they assume everything that looks like a duck must be a duck. If it’s a TCP session on port 443, then it must be HTTPS. But this assumption completely neglects the possibility that somebody might shift an illegal application to a legal port. Ports are just numbers—they’re easy to change.

Photo: Daniel King on Flickr

Intrusion detection and prevention systems

To get around a firewall’s essential flaw, it’s useful to couple a firewall with an intrusion detection system or intrusion prevention system (IDS/IPS). An IDS/IPS is a device that watches every packet and session to look for signs of malicious activity. Generally, more serious problems cause the IDS/IPS to use prevention mode, where it drops the session. Less serious problems and things that are suspicious but not necessarily bad are merely detected, resulting in an alert.

Most IDS/IPS devices use a combination of factors to detect malicious behavior. They monitor for what might be called application orthodoxy, which means they reject sessions that don’t appear to be following the established rules for the protocol they’re using. And they use signature-based detection to look for known patterns of malicious behavior. To be really effective, you need to make sure those signatures are kept up to date, which generally means some sort of subscription model.

The reason I like next-generation or UTM firewalls is because they include an IDS/IPS in the same box, and display IDS alerts on the same management interface. Such a two-in-one device is cost-effective and simplifies management. Some UTM firewalls also look for things like virus signatures during file transfers.

Reverse proxies and web application firewalls

The next important inbound protection you can deploy at the network edge is a reverse proxy, a device that masquerades as a web server or similar Internet-accessible server. The real server sits somewhere inside the network, and the reverse proxy passes the data to and from that real server. (Obviously, you only need this type of protection if you have some sort of server that’s accessible from the Internet.)

In many cases, a reverse proxy is used to translate between an insecure protocol like HTTP, which might be all that a legacy application server supports, and a more secure one like HTTPS, which is more appropriate for anything on the public Internet.

The problem with reverse proxies is that they don’t inspect the contents of the traffic they’re relaying. That’s fine for protocol-based attacks, but not for application-based attacks. For example, two of the most dangerous and common types of attacks against web servers are SQL injection and cross-site scripting. In both cases, the HTTP traffic looks perfectly fine, but is specially constructed to trigger a bug in the implementation of the web server that gives the attacker access they shouldn’t have.

For this reason, I’m not a huge fan of reverse proxies unless they’re also web application firewalls (WAF). A WAF is also a device that sits between the Internet and a web server, but it explicitly sanitizes every request coming from the remote user. At a minimum, it will remove quotation marks and other special characters that are typical of SQL injection attacks.

Some WAF devices can also be configured to know exactly what types of data are allowed in specific fields on a web page that accepts input. Some WAFs will even monitor the connection between a web server and a database to ensure that an otherwise innocent-looking request didn’t somehow result in a huge table dump.

Photo: Kate Ter Haar on Flickr

Email scanners

Another device frequently exposed to the public Internet is an email server. I’ve seen attackers directly trying to do malicious things to an email server, but more typically, they’re trying to deliver malware or spam. So I like to deploy an email scanner in front of an email server. (Note that you can completely avoid the need for this type of defense if you use an outsourced email service.)

Email scanners are concerned with two problems: They want to eliminate or at least reduce spam, and they want to reduce malware attacks by scanning for viruses. An emerging use of these devices is a reduction in phishing attacks as well. However, a well-constructed phishing attack looks so much like a legitimate email message that it’s really only feasible to eliminate the bad ones.

Imagine that an incoming email message has a virus in an attachment. If the email scanner catches it, it quarantines the message and the end user doesn’t see it. If the email scanner doesn’t catch it, then you have to hope whatever anti-malware system you have on that user’s workstation will catch it. For this reason, it makes sense to use completely different malware scanning systems on emails scanners and workstations. I’ll discuss malware scanning systems in more detail later in this post

Defending a network against outbound attacks

Outbound attacks include malicious traffic that originates inside a network and goes out to the Internet. It probably sounds like a pretty low priority. Why should you spend any special effort looking for evidence that your staff or corporate clients are hacking somebody else?

While that’s one of the things we’re looking for, it’s far from the most important. There are two other things we really care about here:

• Attempts by malicious software in the infrastructure to reach out to its controllers
• The leaking of sensitive data to external parties

Photo: Korona Lacasse on Flickr

DNS

The simplest and least expensive thing you can do to protect against outbound attacks is to use a really robust domain name system (DNS). Malware has three ways to call home for instructions. It can use:

• Hard-coded IP addresses—but they’re very easy to block once discovered
• Domain names the malware rotates through on a programmed schedule
• Compromised legitimate sites or advertising services

DNS-based protection can be a useful first line of defense against the second type of attack, but not the others.

Interestingly, though, there do appear to be some malware systems that use DNS queries for communicating with other command-and-control traffic. That is, the results of a DNS query might be interpreted by the malware to mean something other than an IP address. This is another way a good DNS filtering system can be helpful in combatting malware.

However, the problem with relying on DNS for malware is that the malware is still sitting there inside your environment. It hasn’t been eliminated, just temporarily silenced.

IDS/IPS

Another useful line of defense against outbound attacks is an IDS/IPS, perhaps the same one deployed for inbound protection. But this time we’re interested in different types of attacks with a completely different set of signatures. Now we’re looking for malware inside a network as it tries to connect to command-and-control (C&C) servers on the Internet. We’re also looking for indications of unauthorized VPNs or remote access Trojans (RATs).

Logs

If you use a central authentication system like LDAP or Active Directory, (and I believe you should) then you get another excellent defensive tool essentially for free. Simply monitor LDAP or Active Directory logs. Look for repeated failed logins, which might be an indication of somebody attempting a brute force attack. Look for people logging in when they shouldn’t be or logging into systems they shouldn’t be on, particularly users with special privileges, like system administrators.

Probably the most effective type of advanced persistent threat (APT) attack is one where the attackers steal legitimate user credentials. Then they don’t need to devise any exceptionally clever hack—they simply log in and poke around until they find something interesting.

Photo: Wonderlane on Flickr

Web proxy servers

The next thing to look at for protection against outbound attack is a web proxy server, a system that intercepts all outbound web requests and tries to serve them locally. If somebody just loaded a particular web page, the proxy can take the page from its cache and send it back to the user immediately.

Proxy servers provide better performance, as well as an opportunity to centrally scan all web content, including encrypted SSL content, and reject things that look malicious.

I don’t like to make a proxy my first line of defense. It can obscure and limit the effectiveness of some of the other tools. For example, if you see a DNS request or an outbound connection to a known malware domain, it’s a multi-step process to track it back to a particular workstation.

And I haven’t found that the scanning capabilities of most proxies are any better than those found on the best UTM firewalls anyway. The important thing a web proxy buys you is the ability to decrypt and inspect HTTPS (SSL) content.

Forensic packet capture

Finally, if I had all of the security tools we’ve already discussed and I really needed something more to help me deal with incident response following an attack, I’d look at forensic packet capture tools. These are carefully optimized and targeted network protocol analyzers that record interesting looking sessions. They then allow you to search through a massive historical database of these sessions.

Forensic tools are mostly useful during the incident response process when you’re trying to figure out what systems might have been affected by an attack, what credentials might have been compromised, and what data stolen or altered. That’s useful information, but it’s obviously not the starting point.

Photo: IAEA Imagebank on Flickr

Endpoint security

Malware sneaks onto a system in many different ways. The typical malware attack starts with some sort of dropper download. The dropper is a small piece of code whose main function is to get itself installed—somehow, somewhere—then to reach out to the C&C network for further instructions. Usually, the instructions will involve downloading additional malware modules, installing them, running them, and possibly reaching back again for more instructions.

The drop-and-reach-back methodology of most malware gives us many opportunities to catch attacks. First, we try to detect and block the suspicious domains. Then we try to detect and block the dropper download. Then we try to detect and quarantine the dropper software. Then we try to detect and block the C&C traffic. Then we try to detect and quarantine the other malware modules.

The first couple of items on that list are already covered by the UTM firewall and other tools we’ve already mentioned. So the most critical malware-specific tool in our defensive toolbox is good endpoint security.

An endpoint security tool is a mix of traditional anti-virus and behavior-based malware detection. Don’t bother with a straight anti-virus system anymore. Traditional anti-virus programs scan files and use signatures to spot anything that looks like a known virus. But modern malware isn’t always file-based, and it’s often able to change its appearance by repeatedly encrypting and re-encrypting itself. So on their own, signatures aren’t very useful.

However, signature-based detection can be supplemented with behavior-based indicators of compromise (IOC). Malware does malicious things like encrypting files, making strange entries in Windows Registry, or modifying system files. A good endpoint security program will monitor for these types of actions, as well as traditional file signatures.

Sandboxes

Another extremely useful modern anti-malware defense is a sandbox, which grabs a copy of anything being downloaded by any device. This could be email attachments, JavaScript code, a Windows executable file, a Flash animation—really anything.

The sandbox tries to unpack the files and run them in a special, isolated virtual machine. As it does so, it watches carefully for any signs of malicious behavior. The hope is to prevent malware from ever reaching a workstation, which is particularly important for those malware strains like crypto-viruses, which deploy as soon as they’re downloaded and immediately start destroying files.

Sandbox detection can usually be done so fast that the end user isn’t even aware their download was intercepted. However, sometimes malware can evade detection in a sandbox. Sandboxes keep getting better at detecting malware. Malware keeps getting better at detecting sandboxes. So a sandbox should never be considered a replacement for good endpoint security.

Photo: F Delventhal on Flickr

Bringing network defenses together

Once you have several essential elements of network security up and running, you’ll quickly find you don’t have the resources to look at all of them. Firewall and IDS logs alone accumulate at rates of kilobits per second, even after filtering. Active Directory and DNS logs are often just as bad. There’s no way a human can monitor these systems in real time. Instead, you need a way of storing, filtering, and correlating messages into something meaningful.

Initially, it might be enough to use the management tools that come with your equipment. A good UTM firewall generally has a management GUI. You can always use the GUI on your domain controller to look at Active Directory logs. And most endpoint security systems also have a central console. But at a certain point, there are just too many different consoles, and they aren’t sharing information with one another.

This is where a security incident event management (SIEM) system becomes useful. Often the SIEM doubles as a searchable long-term storage system for log messages. Some organizations deploy these functions separately, but ideally, I like them to be together.

The SIEM is a single pane of glass that correlates information it receives from the various security systems you’ve deployed and presents you with all the relevant information about each event.

For example, if somebody is attacking a web server, you might receive relevant data about the attack from the firewall, the IDS/IPS, the WAF and perhaps also the Active Directory server. The SIEM rolls all of that information together so you don’t have to manually search through each of the different data sources to understand exactly what’s going on.

Effective security requires many tools working together. You’ll often hear the expression “defense in depth”, and this is what it means. One of the most important tasks is to identify your risk areas. Then allocate your budget and your time carefully to cover the highest risks first.

The other point that I really want to stress is that tools alone are not security. You can’t lock the door and expect that will keep out all the burglars. Somebody has to be looking at the tools, investigating every single anomaly and eliminating the threats as they appear. Even the risks will change over time, so you need to continually re-evaluate your highest risk areas to make sure they’re appropriately covered.

The post Defending Network Infrastructure Against Attack – Part 2 appeared first on Auvik Networks.

In this new series, we profile MSP (managed service provider) executives by asking them questions big and small. Have a question you think we should ask? Want to be profiled next? Let us know at blog [at] auvik [dot] com.

David Dooley
President, EZ Micro Solutions

Year EZ Micro was founded
1993

Number of employees
14

Percentage of business that’s managed services
100%

Your favorite conference and why
Connectwise [IT Nation]. It covers lots of different content in one conference.

Where you get your industry news
Mainly CRN

How you run a meeting
We focus on the EOS meeting rhythm and agenda. The first part of the meeting focuses on follow-ups, scorecard reviews, and issue identification. And then the majority of the meeting is focused on resolving things on our issues list.

A typical work day for you
Morning huddle with staff, review and prioritization of to-do list (I use Trello), email catch-up, work on to-do list, go on appointments if I have any, then try to catch up on email at the end of the day. I try to be home around 6 or 6:30 to spend time with the family.

The one trait you look for in new hires
They need to be a good fit for our culture and core values.

Your best personal productivity tip
Pick out the top three things you need to get done each day and work on them first.

Peer or business networking groups you belong to
HTG

What you’d be doing if you weren’t an MSP
Not sure, but I know I would be helping people in some way.

A geeky secret you have
Can’t really think of anything, but I do like writing custom reports.

Podcasts — yes or no?
No

What you wish all software vendors knew
We focus on what clients need and not what a vendor has for us to sell them.

Best piece of conference swag you ever received
Accessories for cell phones are always good.

A book you recommend for MSPs
I have read over 100 books, but Patrick Lencioni’s books are really great. The Advantage is one book that kind of sums up all of the rest of his books.

Your regular coffee order
Iced vanilla coffee

The Terminator movies — science fiction or the future?
I hope it’s science fiction, but there are some technologies being developed that make it look not too farfetched.

The post Secrets of the MSP Pros: David Dooley appeared first on Auvik Networks.

Ever wonder why your client’s network is “slow”? Or if the network is at fault in the first place?

It’s not uncommon for IT-enabled workers to experience web, application, or session delays. Most end users gripe a little to colleagues or at their screen, then wait for things to start up again. Or maybe they go coffee up in hopes that all will be well when they get back.

It’s an inconvenience for sure, but it can also be a drag on productivity. In the worst cases, it can bring business to a halt entirely.

Temporary spike or chronic issue?

There will always be cases where a temporary spike in network activity will cause these types of disruptions. There’s not much to be done about it, unless you seriously overprovision your IT infrastructure, including your Internet connection, to a huge (and expensive) degree. Few can afford that, and will have to work with systems and networks that are limited, but ideally are designed to handle load gracefully most of the time.

More troubling are the recurring, chronic performance issues, which indicate a significant resource shortage or malfunction somewhere in the infrastructure. The network usually takes the blame.

While the network isn’t always the core reason (my own research as an industry analyst found the network was a fault of performance issues at most around 40% of the time), it’s a great place to start looking for root causes, because it connects everything together.

Much like the transit system in a major metro area, congestion and breakdowns can cause noticeable delays. Watching traffic flow patterns is a great way to quickly recognize where issues are occurring so you can trace them back to the most likely root cause—network or not.

Uncovering answers with flow data

To get definitive insights into what comprises network traffic, flow-based network instrumentation is the key. The two primary approaches for doing so are:

1. Capture and inspect packets as they stream across network links, usually requiring costly network probe appliances, or
2. Have network devices generate flow record snapshots, using formats such as NetFlow, sFlow, or IPFIX, as packets stream through them.

The latter approach is much simpler and less costly to deploy, and it’s the primary approach that Kentik Technologies takes for consuming and analyzing network flow telemetry. Kentik’s tech is behind Auvik’s new AuvikFlow offering, which adds flow-based visibility features to the core Auvik platform.

AuvikFlow flow data, powered by Kentik

Using flow records, we can get a number of very important insights into what makes up the traffic that consumes network bandwidth.

First off, we can see source and destination IP addresses, so we know who’s active. Next, we can also see port and protocol info, so we can determine what class of applications are being used (web, email, file transfer, etc.). Finally, and perhaps most importantly, we can see how much of the total network capacity is consumed by each flow.

You can conduct this analysis against any point in the network where flow records are being produced, but most common is the point where your network leaves the comfy confines of your LAN and connects to the wider outside world: your edge router. External links, whether WAN or Internet, are commonly lower bandwidth than LAN and thus more likely to be a point of congestion that interferes with normal traffic flow, a.k.a. “network slowness.”

With analyzed flow in hand, you can see at a glance:

1. Is my Internet link clogged up?
2. Who are the biggest users?
3. What application are they using or website are they browsing?
4. Or… should I look elsewhere?

Pinpointing culprits

You might indeed find congestion, as might be caused by big file transfers (think patch downloads, presentation files, or backups) or streaming media. Those could be legitimate business activities, though sometimes they aren’t. In my many years working and researching network visibility tools, I’ve seen a lot of interesting problems of this type.

In one case, a software developer decided to download a new operating system version for a lab trial during normal business hours, clogging a 12Mb Internet link with a 12GB file transfer.

In another, an engineering employee was pulling pirated multi-gigabit digital movies from filesharing servers based in China.

And then there was the accounting employee who set up and was running their own Internet-based business from their desktop.

But there are also cases where a file backup to offsite storage was set up using the wrong timezone, and suddenly fired off in the middle of the business day. And the (frankly glorious) case of a marketing campaign that went viral and brought a small shop to its knees with business demand.

You might also find no congestion problem, in which case the issue may lie with the way the network is configured, resource issues on the end user’s system, or degradations of servers or service somewhere out across the Internet.

Examples I’ve run across abound here too, such as a circuit misconfiguration causing excessive packet drops/retransmits, a bad NIC on a server that wouldn’t autonegotiate properly, an antivirus scan kicking off unexpectedly (due to misconfiguration), or a degraded DNS provider.

Going with the flow

There are so many possible reasons why “the network is slow” that it would be impractical to go through them all here. But the important takeaway is this: With clear visibility into the uses and users of network traffic, you can accurately determine if the network is indeed the problem, what the root causes are most likely to be, and where to focus actions to set things right. Best of all, it’s fast!

So relax, take a deep breath, and go with the flow. It’ll make your day-to-day a lot simpler and less stressful. You’ll be in a position to understand and answer questions about network use and misuse that you haven’t been able to before, and also in a position to get ahead of problems by making better-informed decisions around usage policy and capacity planning.

The post Using NetFlow & Other Flow Data to Solve Network Problems appeared first on Auvik Networks.

No doubt you’re used to doing assessments—or audits—when you first pitch a client. But did you know there are plenty of other ways to use audits?

Throughout the lifetime of an account, network audits can help you build and enhance your service reputation, identify upsell opportunities, troubleshoot thorny problems, and more.

Let’s take a closer look at 9 ways to use network audits in your managed service provider business.

1. Close more business

   Yes, network audits do help you land new business, especially if the audits are accurate and thorough. UK-based LAN3 runs an assessment tool as a managed services proof of concept. “The topology maps and reporting never fail to impress prospects,” says Martin Jones, LAN3’s managing director. “Once we get that far, we expect to win the account.”

2. Discover dead devices posing a security risk

   Zombie devices—those boxes that everyone has forgotten about but that are still attached to the network—create an easy attack surface for hackers. An audit that automatically sweeps and inventories the complete network will uncover zombies so you can get them off the network. Then you can report back to the client on how you’ve cleaned up the network, tightened their security, and possibly improved performance as well.

3. Uncover unexpected client changes

   An employee moves his desk closer to the window. Someone kicks out a cable in the wiring closet. Changes can and frequently do occur without the client telling you. In many cases, the client may not even be aware they’ve affected the network. Regular audits and real-time maps help you stay on top of what’s happening. And that makes you look smart.

4. Properly estimate and bill

   Quoting can be a lengthy and tedious process when you don’t have a clear idea of what you’re dealing with. And estimating poorly can kill your profit margin—or the customer experience. A good audit will catalog every device on the network and how they’re all connected so you know exactly what you’ll be expected to support. If you charge by the device, such an inventory is especially critical. Ongoing audits will make sure the invoices you’re sending remain matched to the size and complexity of the network you’re managing.

5. Plan for a cloud migration

   The first step in migrating a client to the cloud is an audit of the LAN. The bandwidth requirements of a cloud-based office are much lower than an on-premises network, so you should be changing the internal network design. The audit will tell you how to design for the right redundancy requirements.

6. Deliver quarterly business reviews

   Stay top of mind with your clients by delivering the results of ongoing network audits in a regular review. Whether it’s to demonstrate the largely trouble-free status of the network in the previous quarter or to highlight various improvements you’ve engineered, clients will appreciate knowing you’re always on the ball.

7. Identify upsell and expansion opportunities

   Regular network audits help you spot trends and plan for future growth. Knowing ahead of time whether a client will need new gear or bigger pipes helps you make smart recommendations. Advance notice means the client can budget for the upgrades and you can time them to make sure the changes are made before users notice any difference in performance. On the flip side, if it’s a client ask—say, a request to add a new office or bring in a new app—a clear view of the network and what’s been happening on it will guide the way.

8. Meet security or compliance requirements

   Many regulations specify regular network audits. So getting in the habit of completing audits, and having a good tool for doing them easily, means you’ll be in a good position to help clients with their regulatory requirements.

9. Onboard and train new techs

   An MSP that’s growing quickly will need to add new techs. Employee churn can also create a need for new hires. Whatever the situation, you need a way to get techs up to speed on client networks quickly. Audits help you do that. Armed with a real-time map, inventory, configuration history, and more, new employees can get a fast grip on client networks and how they operate.

The post 9 Ways to Use Network Audits to Grow Your Business and Reputation appeared first on Auvik Networks.

Marketing.

There are few words that inspire as much fear and loathing in IT pros as that one.

According to many, tech marketing is lazy, evil, annoying, evil, and dumb. Marketers are addicted to jargon. Marketers misuse and abuse otherwise helpful phrases, turning them into meaningless (if not misleading) paste. Marketing trades in fluff, rather than meat.

It’s not just tech marketing either. A 2012 study from Adobe found that consumers ranked marketing below traditionally despised professions like banking, law, and politics when they were asked how much marketing benefited society.

Still, for whatever reason, it seems technology pros hate on marketing more than other industries do. But you know what? Even though I’m a marketer, I can’t help but agree with a lot of the sentiment.

Well, maybe not the dumb, lazy, evil part—I don’t think the vast majority of marketers are intentionally obnoxious—but there is an awful lot of bad marketing out there, and I know it can leave a decidedly bad taste in one’s mouth.

Rule #6

At Auvik, we work hard to do better. Rule #6 of the Auvik Way, the set of principles that guides us in our daily work, dictates “no a$$holes.” As far as I’m concerned, that also means no bullsh!t.

Yes, we have a product we need to sell. So yes, Auvik’s marketing team needs to spread the word as far as we can. We need to bang the network infrastructure drum and toot the efficiency horn.

But we aim to be straightforward, honest, and respectful while we do it. In this, we take inspiration from Seth Godin.

Marketing is powerful when it sells a product to someone who discovers more joy or more productivity because he bought it. … Ever since Josiah Wedgwood invented marketing a few centuries ago, it has been used to increase productivity and wealth.

Just like every powerful tool, the impact comes from the craftsman, not the tool. Marketing has more reach, with more speed, than it has ever had before. With less money, you can have more impact than anyone could have imagined just ten years ago. The question, one I hope you’ll ask yourself, is what are you going to do with that impact? (Seth’s emphasis)

Valuable, relevant, consistent

We also work hard to embrace the values of content marketing, which Joe Pulizzi at Content Marketing Institute describes like this:

Content marketing is a strategic marketing approach focused on creating and distributing valuable, relevant, and consistent content to attract and retain a clearly-defined audience — and, ultimately, to drive profitable customer action.

The keywords there are valuable, relevant, and consistent. To those I’d also add conversation and commitment.

That’s why, most of the time, you won’t see us mention Auvik in our blog posts. It’s why our blog posts publish at 9 a.m. every single Tuesday morning, rain or shine, and our Rant newsletter goes out at 2:30 p.m. every other Wednesday. It’s why we spend just as much time sharing other people’s great content as we do our own.

It’s why I try to talk and write like a real human being having a conversation with another human being. And why we do our best to avoid buzzwords and phrases, like the ones that were recently banned (in partial jest) at a CompTIA Annual Member Meeting. (Of the 20 business phrases on their list, we’ve used one term—ecosystem—in one of our blog posts. )

I can’t promise you’ll love or agree with everything we do. We’re not perfect, but we’re trying hard.

I’d love to know, are we hitting the mark on our commitments of valuable, relevant, consistent, and conversational? What are your thoughts on our newsletter? (If you’re not a subscriber, you can sign up here.) What about our blog posts? Or our ebooks? Leave a comment or send me an email.

The post Tech Marketing That Doesn’t Stink appeared first on Auvik Networks.

If you’re like us, Slack is a go-to office tool. It’s really handy to collect feeds from a number of different programs and see them all in one place. And with Slack’s flexible channel setup, you can make sure information gets sent only to the people who need to see it.

Here’s a step-by-step on how to feed your Auvik alerts into Slack. Auvik alerts can be posted to one of your existing Slack channels or to any new channel you create. The channel can be public or private.

Create a new incoming webhook in Slack

1. In Slack, click the user dropdown menu and select Apps & integrations.

   
   

2. In the filter field, enter Incoming. Select Incoming WebHooks.

   
   

3. Click Configure next to the Auvik logo.
4. Click Add Configuration.
5. Select the existing channel you’d like Auvik alerts to post to, or create a new channel.

   
   

6. Click Add Incoming WebHooks Integration.
7. Copy the webhook URL. (You’ll need this in the next section, when you create the Slack integration in Auvik.) Optional: Enter a descriptive label for the new webhook.

   
   

8. Click Save Settings.

Add a new Slack integration in Auvik

You’ll likely want to add a new Slack integration for each client you manage by logging into each client’s instance of Auvik. If you choose to have all the notifications sent to a single Slack channel, Auvik specifies the company name on each notification so you know which notifications apply to which client.

1. Click Integrations in the side navigation bar.

   
   

Hover over the Add Integration button, and select Slack.

2. Fill in the integration form.
   • Give your integration a name.
   • Paste in the Slack webhook URL. If you want, click Test Connection to confirm the URL is accurate.
   • Select the notification channel(s) you want to associate with the new integration. You can create a new channel if one doesn’t already exist. (The form says this step is optional but if you don’t do it now, you’ll have to do it separately before you can use the integration.)

3. Click Save Integration.

And that’s it! Easy.

The post Setting Up Auvik to Post to Slack appeared first on Auvik Networks.

We’ve seen a lot of terrible stock photos in our day. A lot. So when we saw this list of Funniest Hacker Stock Photos from TeachPrivacy, we were inspired to put together our own list for networking.

Here’s what happens when you search a stock database for photos about networking, of the computer kind.

Enter The Computer Network. Oooh, this is so exciting. I feel like I’m in a cyber-spy movie. Am I in a cyber-spy movie?

Networking meets the son of the Village People. Because nothing says networking like a tank top and hard hat. With safety goggles. And a drill in your pocket.

---

What is he so damn happy about? Where does he have his hand? What the heck is that suit made of? WHO IS THIS GUY?

---

Duuuuude, look at the pretty blue snake. Whoa.

---

How many times have I told you: No loopbacks! Don’t make me come in there.

---

I feel the network. I shape the network. I am the network.

---

Oh, so this is the cloud computing thing everyone keeps talking about. Imma click right here and sign in. Wheeee!

---

No words.

---

Dammit, Carl! How many times have I told you not to ride your bike on the network. Now we’ve had to call the tiny medics. Wait, is this a metaphor? Carl?

---

Whatever you do, don’t look into the eyes of the beast. Mark, I said don’t look!!

---

The computer network is like a giant web, you see. Isn’t it pretty? Let’s all sing Kumbaya.

---

No, that’s not what it means when we say we’re bring sexy back to networking.

---

I went to this seminar where a lady taught me how to be the network. Works every time. See? The network’s calmer already.

---

I have Photoshop. I like to blend stuff. And the globe adds a powerful message, don’t you think? It’s like, we’re all connected. You know?

---

All I’m saying is you can’t go wrong with Photoshop.

---

…then I slip this little symbol thingie in the back and… look at that! Emails! Isn’t networking amazing?

---

We have lift off! I am on the line!

The post 17 Network Stock Photos So Terrible They’re Great appeared first on Auvik Networks.

So, you’re an MSP that’s recently won a new client. As part of the deal, you’ve promised to take a look at the overall network and determine if there are any glaring issues that will interfere with day-to-day operations.

The topology is vast, spanning multiple sites and dozens of switches and firewalls. How do you act quickly? And what should you be looking for?

Here are 7 network assessment tasks Auvik can help you easily complete. Armed with this information, you’ll land some quick wins with your new client and set the stage for a positive working relationship.

1. See what’s out there

   Having worked with hundreds of MSP partners, I still smile when I hear that Auvik has been able to discover devices the partner (and even the client) had no idea were out in the wild.

   What sort of things have been found before?

   • Unmanaged switches plugged into employee cubicles and used to connect unauthorized devices
   • Private Access Points so users could bypass corporate Wi-Fi
   • A series of switches in the ceiling of a building that the client had completely forgotten were still active
   • Unauthorized wireless cameras (!!!)

   How to see what’s out there with Auvik

   In Auvik, the Inventory > All Devices grid shows you all devices currently or recently connected to the network. Where it’s available, data from protocols like SNMP, WMI, and VMware automatically classify devices.

   Important biodata about your network devices is also gathered automatically, including serial numbers and firmware versions.

   Pro tip: Such information is invaluable during a compliance audit to make sure your gear is running the latest firmware. In one case, a partner found a bug in a switch vendor’s firmware and used Auvik to ensure the hundreds of other switches they had deployed were running firmware that had patched the bug.

2. Ensure enough IP addresses

   In an environment with a lot of device churn, it’s critical to ensure there are sufficient IP addresses available to hand out to clients. Without enough IP addresses, clients that are, say, attempting to hop on guest Wi-Fi won’t be able to do so. Existing users may find sessions dropped.

   How to ensure enough IP addresses with Auvik

   Auvik models networks as entities. Each entity has a dashboard within Auvik. On a network dashboard, hover your mouse over Inventory. You’ll notice a tab called Devices. Click on it.

   
   br>
   From the resulting grid, sort the IP address(es) column from low to high. This gives you a list of all the IP addresses currently in use for the subnet. Using this data, you can determine how many IPs are in use.

   Pro tip: You can apply a filter to see only devices that are currently up.

   If you’re averaging 80-90% utilization of available IPs, you may need to consider a few different strategies:

   • Increase the DHCP address pool. Through classless interdomain routing, you have the ability to define subnets of varying size and scope. Decreasing your subnet mask increases the number of IP addresses available.
   • Decrease your DHCP lease time. In environments like coffee shops, reserving an IP for more than 60 minutes is wasteful, considering your average customer (and their devices) won’t be there for more than an hour. The lower the lease time, the more quickly IPs are returned to the available pool.
   • Enable MAC address spoofing protection on your devices. This helps prevent DHCP starvation attacks.
3. Identify broadcast storms

   A storm of broadcast packets is sometimes expected behaviour—for example, when a network is brought back online after an outage and all clients are attempting to negotiate an IP address. But in normal cases, having a continuous stream of broadcast packets in a network segment or from a specific host is suspicious.

   Without deep network visibility, you may only be tipped off by angry users or by randomly looking at interface counters on your switches. But in Auvik there are multiple ways to identify broadcast storms.

   How to identify broadcast storms with Auvik

   • Get an alert on storms. There’s a preconfigured Auvik alert for when a significant percentage of a switch port’s traffic is broadcast as opposed to unicast or multicast. You can lower this threshold in sensitive or troubleshooting scenarios to be more proactive and in-the-know.
     
   • Use the troubleshooting view to see if a broadcast storm may have caused any other events within the same timeframe, such as a spike in CPU on the host or an adjacent switch.
   • Navigate to a device or interface dashboard and look at the Device Packets or Interface Packets to get an idea of the ratio between broadcast, multicast, and unicast packets.

   Ideas for reducing broadcast storms

   • Storm control and equivalent protocols allow you to rate-limit broadcast packets. If your switch has such a mechanism, turn it on.
   • Ensure IP-directed broadcasts are disabled on your Layer 3 devices. There’s little to no reason why you’d want broadcast packets coming in from the Internet destined to a private address space. If a storm is originating from the WAN, this will shut it down.
   • Split up your broadcast domain. Creating a new VLAN and migrating hosts into it will load balance the broadcast traffic to a more acceptable level. Broadcast traffic is necessary and useful, but too much of it will eventually lead to a poor network experience.
4. Identify duplicate IPs

   A duplicate IP address is one associated to more than one MAC address. When this occurs, an ARP lookup returns multiple MACs and this can cause problems. For example, if a desktop has two ARP entries for an IP address that’s supposed to be for a printer, the packet may not reach the intended printer.

   How to identify duplicate IPs with Auvik

   Auvik amalgamates the ARP tables of each device and presents them in a global, searchable grid. You can also retrieve the ARP table for a specific device.

   Auvik’s Network Evidence tab allows you to view the Layer 2 and 3 information that one device has about another.

   Here are two things to look for in Auvik to help identify duplicate IPs:

   • When you search for a specific IP address within Inventory > All Devices or on the map, multiple devices are returned.
   • You see duplicate IPs in the global ARP table for the Layer 3 device (firewall, router, or Layer 3 switch) that routes traffic to and from the subnet on which you’re investigating (Debug > ARP / FDB)

5. Solve the dreaded ‘My network is slow!”

   This is probably the most loaded complaint you can hear from a network user. There are so many potential root causes for a user experiencing network slow-downs. But typically, we find MSPs eventually pinpoint the root cause to one of three things:

   • The Internet connection is flaky and intervention from the ISP is required.
   • The client’s users are maxing out the Internet connection.
   • There are lower level network issues, such as broadcast storms and duplicate IPs.

   How to solve ‘My network is slow’ with Auvik

   Using Auvik’s Internet Connection Check feature, you can automatically determine when a WAN link became unresponsive (stopped responding to pings), and have quantifiable metrics on round trip time (RTT) and packet loss to present to your client’s ISP.

   You can find information on your discovered Internet Connections by heading over to Inventory > Services > Internet Connection Check.

   Unfortunately, the majority of Internet connections out there today are asymmetric—their downlink speeds are much larger than the uplink. But the downlink depends greatly on the uplink for TCP or control-based protocols like DNS, which are fundamental for a good network experience.

   Say an ISP has provisioned an office link for 50Mbps down and 10Mbps up. It’s pretty easy for a group of users to max out that upload link by uploading a large file or through HD video conferencing.

   Auvik can show you an interface’s utilization for a given time period. Here’s an example from a Cisco ASA’s WAN interface.

   In our example of the ISP’s link being a 50/10 Mbps connection, you can see we’re not maxing out our connection. If we are, there are two avenues you could take:

   • Determine which user(s) and protocol(s) are taking up the most bandwidth. This is most elegantly done by collecting flow statistics at the network perimeter. AuvikFlow can do this effortlessly.
   • If additional OpEx is available, upgrade the WAN link to reflect increased network usage.
6. Find physical and logical loops

   Loops can be found within networks at different layers. A Layer 2 loop can be caused by incorrectly configured trunk links between switches or a physical loopback link on the same switch (think of an Ethernet cable plugged into two ports on the same switch). This leads to broadcast and multicast storms that can take down your network.

   A Layer 3 routing loop occurs when packets keep getting routed between two or more routers.

   How to find loops in Auvik

   Auvik does it for you. Auvik automatically alerts you to Layer 2 loops if you have spanning tree enabled on your core (MDF) and access (IDF) switches.

   Auvik automatically alerts you on Layer 3 loops as well.

7. Identify stale or incorrect configurations

   When a network has changed hands or in a network with a lot of moving parts, it’s common to have stale configs. Many times when an admin comes across a line of code they suspect to be stale, they’ll leave it untouched, worried they’ll break something if they change it.

   What’s more, due to user error or ignorance, devices may not be properly configured in the first place. As an admin, how can you safely remove stale configs for routes and port configurations and check for current misconfigurations?

   How to identify configuration problems in Auvik

   Since Auvik combs through the configurations of each of your devices, it automatically begins to determine whether applied configurations have corresponding entries on each segment of the network. There are a number of canned configuration-related alerts available.

   For example, the VLAN with no interfaces alert is triggered when a defined VLAN isn’t associated with any interfaces. Chances are the VLAN was decommissioned but the definition wasn’t deleted.

   Or consider a misconfiguration scenario: The previous network administrator had tried to set up a link between two switches. This would conventionally be configured as a trunk link. But on the downstream switch, the admin configured the port as type access. This would lead to the link operating incorrectly and being unable to establish two-way traffic.
   Imagine walking into a new site and being able to figure that out a few minutes just by turning Auvik on!

At Auvik, we strive to wow our partners. And we want our partners to be able to wow their customers. Assessment features like the ones we’ve just discussed set the stage for strong and mutually beneficial engagements with your customers.

The post 7 Ways to Slam Dunk Your Next Network Assessment Using Auvik appeared first on Auvik Networks.

Network blind spots are the things you can’t see and don’t know about.

They’re dangerous. Just like the blind spots on your car, network blind spots can set you up for deadly crashes. Problems will seem to “come out of nowhere” and hit unexpectedly.

Network blind spots create all kinds of serious problems. A major network crash is one. But other problems can really pile up too. If your techs are operating blind, you’re creating these kinds of headaches for your MSP:

• Outages and downtime
• Network performance issues
• Incomplete and inaccurate network assessments
• Inaccurate service estimates and invoices
• Security issues
• A constant cycle of reactive firefighting

Network blind spots spell trouble for your business. What kind of trouble?

• Unhappy customers and relationships at risk
• Breaches of contract and service level agreements
• Massive amounts of time wasted
• Large amounts of profit lost

Continue on that road and your MSP might not survive.

Network blind spot: Shadow IT

Take shadow IT and rogue devices, for example. Users add all manner of other devices to networks without telling anyone, least of all you as the MSP. Sometimes the client doesn’t even know those devices are there.

California-based MSP ITque had a large manufacturing client with a dozen wireless access points, a firewall, and two routers that the client hadn’t told anyone about. At 2 a.m. on a Saturday, that rogue gear almost cost the client a million dollars in lost profit. Almost.

Because ITque had a real-time mapping and monitoring solution in place, they could see the gear even when the client couldn’t. They were able to remotely diagnose and solve the problem — an unexpected routing change — in 10 minutes.

Without that visibility, ITque would have had to go on site in the middle of the night. “We would have had to figure out what was deployed because there was no documentation. We would have had to, from scratch, figure that out,” says DJ Forman, ITque’s CTO.

In the end, it’s estimated the MSP’s 10-minute fix saved the client 48 hours of downtime at a cost of about $25,000 of profit per hour.

When you drive a car, you use mirrors and shoulder checks to make sure issues in your blind spots don’t cause trouble. In a similar way, the right tools and processes on the network can improve your vision and help you avoid a pileup.

Luckily, ITque had those tools and processes in place to address a major network blind spot. Could you say the same if you had received that 2 a.m. call?

Rogue devices are just one of the common blind spots on a network. Our new blind spot white paper outlines the other five and how you can avoid them. Grab it here — and stay safe out there!

The post Are Network Blind Spots Killing Your MSP? appeared first on Auvik Networks.

“Cool and evil.”

That’s how Paul Querna summed up the Simple Network Management Protocol, or SNMP, back in 2003. He was writing about how the protocol can be used to collect lots of network information easily, but can also seem convoluted.

Querna’s phrase sums up SNMP quite effectively. The protocol certainly has its shortcomings, just like any other technology. And those drawbacks are more pronounced in some SNMP versions than in others.

At the same time, though, SNMP is a vital tool for effective network management. It’s not perfect, but it’s one of the best solutions available for monitoring and managing devices on the network.

Below, I discuss SNMP’s role in network management, identify the various SNMP versions available, and explain how to use SNMP effectively and securely on your network.

What is SNMP?

SNMP is a network protocol created in 1989 to provide a consistent and reliable way for different devices on a network to share information with one another. It allows devices to communicate even if the devices are different hardware and run different software.

Without a protocol like SNMP, there would be no way for network management tools to identify devices, monitor network performance, keep track of changes to the network, or determine the status of network devices in real time. .

SNMP architecture

SNMP has a simple architecture based on a client-server model. The servers, called managers, collect and process information about devices on the network.

The clients, called agents, are any type of device or device component connected to the network. They can include not just computers but also network switches, phones, printers, and so on. Some devices may have multiple device components. For example, a laptop typically contains a wired as well as a wireless network interface.

SNMP data hierarchy

While the SNMP architecture is simple, the data hierarchy the protocol uses can seem complicated if you’re not familiar with it. Fortunately, it’s relatively simple once you understand the philosophy behind it.

To provide flexibility and extensibility, SNMP doesn’t require network devices to exchange data in a rigid format of fixed size. Instead, it uses a tree-like format, under which data is always available for managers to collect.

The data tree consists of multiple tables (or branches, if you want to stick with the tree metaphor), which are called Management Information Bases, or MIBs. MIBs group together particular types of devices or device components. Each MIB has a unique identifying number, as well as an identifying string. Numbers and strings can be used interchangeably (just like IP addresses and hostnames).

Photo: Robert Couse-Baker on Flickr

Each MIB consists of one or more nodes, which represent individual devices or device components on the network. In turn, each node has a unique Object Identifier, or OID. The OID for a given node is determined by the identifier of the MIB on which it exists combined with the node’s identifier within its MIB.

This means OIDs take the form of a set of numbers or strings (again, you can use these interchangeably). An example is 1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3.

Written with strings, that OID would translate to:

iso.org.dod.internet.private.transition.products.chassis.card.slotCps­.
cpsSlotSummary.cpsModuleTable.cpsModuleEntry.cpsModuleModel.3562.3.

Using the OID, a manager can query an agent to find information about a device on the network. For example, if the manager wants to know whether an interface is up, it would first query the interface MIB (called the IF-MIB), then check the OID value that reflects operational status to determine whether the interface is up.

Why use OIDs?

The MIB and OID data hierarchy may seem confusing, but there are several important advantages to a system like this. One is that information can be pulled by the manager without having to send an explicit request for the agent to collect it. That reduces overhead and ensures information about the network’s status is always readily available.

The system also provides an easy, flexible way to organize many devices across a network. It works no matter how large or small the network is, or what kind of devices are on it.

SNMP also makes it possible to collect large amounts of information quickly without clogging the network with traffic. Because information about device status is always available in a simple format and is updated in real-time, managers can pull it without waiting for the data to be collected or requiring large data transfers.

Last but not least, it’s worth noting that some OID values are vendor-specific, which makes it easy to gain some information about a device based simply on its OID. For example, if an OID starts with 1.3.6.1.4.1.9, it applies to a Cisco device. Other vendors have their own OID specifications. (Wireshark, the open source network scanner, offers a handy OID identification tool.) The standard OID prefix, which can be used for almost any device that supports SNMP, is 1.3.6.1.2.

SNMP versions

The final important thing to understand about SNMP is that the features available in different versions of the protocol vary widely, especially when it comes to security.

Photo Briana Cole on Flickr

As well, SNMPv1 uses certain default credentials, which admins don’t always update, making it easy for unauthorized parties to gain access to sensitive information about the network. Unfortunately, SNMPv1 is still used on a relatively wide basis today because some networks haven’t yet updated.

SNMPv2, which appeared in 1993, offered some security enhancements but it was supplanted in 1998 by SNMPv3, which remains the most recent version of the protocol and the most secure.

SNMPv3 makes data encryption possible. It also allows admins to specify different authentication requirements on a granular basis for managers and agents. This prevents unauthorized authentication and can optionally be used to require encryption for data transfers.

The bottom line is that, while the security issues in SNMPv1 earned SNMP a bad name in some circles, SNMPv2 and especially SNMPv3 solved those problems. The newer versions of SNMP provide an up-to-date, secure way to monitor the network.

Enabling SNMP

If the poor security in SNMPv1 has you worried, fret not. SNMP is not normally enabled by default on devices. That means that, in most cases, admins have to log in and turn it on in order to make SNMP data available. This requirement reduces the risk of running an insecure SNMP version without realizing it.

This also means that to use SNMP to manage your network, you usually have to enable it first.

The post Network Basics: What Is SNMP and How Does It Work? appeared first on Auvik Networks.

In this ongoing series, we profile MSP (managed service provider) executives by asking them questions big and small. Have a question you think we should ask? Want to be profiled next? Let us know at blog [at] auvik [dot] com.

Steve Riat
Sales Manager, Nex-Tech

Year Nex-Tech was founded
1951. Nex-Tech/Rural Telephone was started as a telephone company that migrated into Internet and eventually a technology company out of growth and acquisition.

Number of employees
341 as of April 2016

Percentage of business that’s managed services
40% of the technology side

Your favorite conference and why
HTG meetings. They’re the one place I can get everything from developing a leadership team to financial, accountability, and more.

Where you get your industry news
I have a lot of contacts on LinkedIn and Facebook that post great stuff across the industry.

Your regular coffee order
Earl Grey tea (The geeks will get where that came from.)

What’s on your smartphone home screen
Background is of Disney Castle from a vacation a couple years ago, alarm clock app I use as my clock at bed time, PayPal, Dashlane, SuperPhoto, Accession (our cloud phone app), our intranet app, Alexa, short cut to our project management dashboard, JibJab, and the Nex-Tech directory app.

How you run a meeting
I am a stickler for on time and on task. Gazelles.

A typical work day for you
In early, run by the calendar, filled in with one-on-one calls and meetings with the team. The focus is revenue, customer service, and fun.

Someone in computer networking whom you admire
Hardin Byars

The one trait you look for in new hires
Passion. I can teach knowledge, but can’t instil passion.

Your best personal productivity tip
The 80/20 rule. So many places that applies such as for many events, roughly 80% of the effects come from 20% of the causes.

Peer or business networking groups you belong to
HTG, Varnex, Trust X

What you’d be doing if you weren’t an MSP
I am sure something in technology and people.

A geeky secret you have
I have 74 devices connected to my home network.

Podcasts — yes or no?
Yes, I spend a lot of time on the road so when I see a podcast that interests me, I download and listen while traveling.

What you wish all software vendors knew
KISS (Keep It Simple Stupid)

Best piece of conference swag you ever received
Orange handle cover for my luggage. Hey, I have a black bag like everyone else at the airport. Love that thing.

A book you recommend for MSPs
How the Mighty Fall

The Terminator movies — science fiction or the future?
Both! I just hope the outcome is more utopia than destruction.

The post Secrets of the MSP Pros: Steve Riat appeared first on Auvik Networks.

At 2 a.m. on a Saturday, California-based MSP ITque got that call: The network had crashed.

It was peak production time at one of their biggest manufacturing clients, which stood to lose $25,000 in profit for every hour the line was quiet.

This client had rogue IT, including a firewall, a couple routers, and about a dozen wireless access points they hadn’t mentioned. All completely undocumented.

Luckily, the client had just started working with ITque, and ITque had Auvik. They knew all about the rogue gear—what it was, where it was, what it was running.

When they got that middle-of-the-night call, they logged into Auvik. Within 10 minutes, ITque’s technician spotted an unexpected routing change, saw what the route used to be, and reverted it.

The network came up.

Just like that, ITque saved the client a million bucks. Without the visibility that Auvik provided, ITque could have been there all weekend trying to figure things out from scratch.

Instead, they looked like heroes. And it landed them more business from the client.

“Immediately after that, [the client] asked us to go much deeper into their network and develop a much more robust relationship,” says ITque CTO DJ Forman.

“Auvik’s monitoring and management capabilities, along with the visual representation that they provide, has really been a game changer for us,” adds Rob Naragon, ITque’s CEO.

In the video below, you’ll hear more from Forman and Naragon as they discuss how Auvik helps ITque run their MSP efficiently and profitably.

The post Rogue IT Almost Cost This MSP’s Client $1 Million. Almost. appeared first on Auvik Networks.

The cloud is here — and so are its acronyms. Since software as a service (SaaS) hit the world in 2001, the ‘as a service’ model has been extended to just about everything you can think of.

Along the way, the definition has become a little muddied. It used to be that -aaS meant something delivered on a subscription basis via the cloud, without a physical component. Hence software delivered to your computer continually via the Internet rather than a program you purchased for a one-time fee and installed from a disc.

These days, though, -aaS can mean just about anything delivered by subscription or even just a plain old outsourced service, whether the cloud is involved or not. Some -aaS models are an industry category and some are proprietary to a single company. It’s enough to drive an MSP mad trying to keep up.

So if your head is spinning, don’t worry—you’re not the only one. To help, we’ve pulled together a list of 53 ‘as a service’ offerings, everything from BaaS to XaaS. For 22 of the most important, we provide a brief description and a look at the market opportunity.

Did we miss anything? Let us know in the comments.

BaaS
Backend as a Service

Backend cloud storage and processing for faster application development. Helps developers focus on their app’s features instead of spending time wondering how to scale.

Market: Young sector growing at lightning speed, shows no sign of stopping. Expected to balloon from $1.32 billion in 2015 to $28.1 billion in 2020.

also
Backup as a Service
Blockchain as a Service
Building as a Service

CaaS
Containers as a Service

A complete runtime environment hosted in the cloud. Containers package up an app with all the bits it needs and standardize how it runs. Cloud containers make it even easier to test from anywhere, so no wonder the sector is exploding.

Market: Too soon to comment on size. Google and Amazon already involved, so clearly big opportunities exist.

CaaS
Country as a Service

What if you’re Estonia—technically advanced with high living standards—but no one wants to live there? Offer e-residency with access to a variety of digital services in the country. Where could this go in the future? Watch for developments in banking, tax, and business.

Market: Unknown

also
Cloud as a Service
Commerce as a Service
Communications as a Service
Compiler as a Service
Compliance as a Service
Content as a Service

Daas
Desktop as a Service

See Workspace as a Service

DaaS
Data as a Service

When data is siloed off, it’s not working as hard as it could. By centralizing data in the cloud, it can be accessed easily and analyzed far more deeply.

Market: Relatively new but growing quickly. Compound annual growth expected to be 43% between now and 2020.

DaaS
Device as a Service

(aka Hardware as a Service, Notebook as a Service)

Companies pay a monthly fee to lease the latest hardware, along with ongoing management and support. A recurring revenue opportunity for MSPs—or a chance for hardware vendors to disintermediate them? HP, for one, offers device aaS as a channel program. Seems most vendors will. See Surface as a service.

Market: Corporate IT buyers are interested. A 2016 IDC survey says a quarter of them are actively looking at device aaS, while another 20% are planning to do so in the next year.

also
Database as a Service

DRaas
Disaster Recovery as a Service

Leaps into action in the event of a catastrophe to repopulate your client’s data, infrastructure, and applications—ideally before they’ve even noticed a hiccup. More robust than backup aaS.

Market: Another new and quickly expanding market. Expected to grow from $1.68 billion in 2016 to $11.11 billion by 2021.

EaaS
Environment as a Service

Going further than virtual machines or containers, provides test management, test case development, and test execution.

Market: A new market seeing strong growth. Compound annual growth forecasted at 23.5% from 2016 to 2020.

FaaS

Framework as a Service

HaaS

Hardware as a Service
(see Device as a Service, Notebook as a Service)

IaaS
Infrastructure as a Service

One of the fundamental -aaS offerings. Makes world-class IT infrastructure available to any size of business, with setup and maintenance outsourced to third parties. A huge number of platforms, applications, and software have been built on cloud infrastructure.

Market: A booming sector that keeps growing. Expected to skyrocket from $15.8 billion in 2015 to $56.1 billion in 2020. Behemoths AWS, Google, IBM, and Microsoft dominate.

also
Identity as a Service

KaaS

Knowledge as a Service

LaaS
Location as a Service

Retail (and other) companies sit on an enormous quantity of customer location data without the tools to pull business insight from it. Location aaS lets them rent high quality location data analysis.

Market: An emerging sector, few big players so far.

also
Linux as a Service
Logging as a Service

MaaS
Monitoring as a Service

Oversees from the cloud how IT infrastructure, systems, and apps are running. Avoids having to purchase and install a potentially costly on-premises monitoring tool.

Market: Difficult to define. No numbers available.

also
Management as a Service
Messaging as a Service
(Bare) Metal as a Service
Mobile Backend as a Service

NaaS
Network as a Service

Rented network functionality from a third-party that owns the infrastructure, usually an ISP. Scale up or down on port capacity as needed—works best for companies with highly variable demand. An interesting model to explore when MSPs serve as the infrastructure provider renting to clients.

Market: Compound annual growth expected to be 36% between 2016 and 2020.

also
Notebook as a Service

OaaS
Operations as a Service

A third-party services that helps businesses design, build, maintain, and monitor the IT infrastructure of their dreams. A new name for a managed service you’ve likely been offering for years.

Market: Managed service market forecasted to hit $193.3 billion by 2019.

PaaS
Platform as a Service

IaaS moves IT hardware to the cloud but opens new challenges for developers in configuring and operating their app deployment platforms. Platform aaS is the answer. Provides not just infrastructure but operating systems, software, databases, and other useful tools.

Market: Much smaller than IaaS but growing rapidly. Expected to rise from $1.3 billion in 2013 to $6.9 billion in 2018.

RaaS
Ransomware as a Service

DIY ransomware kits that would-be criminals can purchase and implement. One service you don’t want to deliver. Unfortunately there’s not a whole lot you can do about the sale of code kits online. What you can do? Protect your clients against ransomware when it attacks.

Market: Oversupply is driving the cost of kits down—that’s bad.

SaaS
Software as a Service

Centrally hosted software with subscription licences. The grandaddy of the entire -aaS market. Providers like it because regular monthly payments are better than one-time deals, and client like its flexibility.

Market: Growing five times faster than the traditional software market. Forecasted to grow from $48.8 billion in 2014 to $112.8 billion by 2019

SaaS
Surface as a Service

Microsoft Surface for a monthly fee. Similar to device aaS, though proprietary to Microsoft. Watch for more and more companies to offer traditional products and services on a subscription basis in the next few years.

Market: Unknown

also
(IT) Security as a Service
Storage as a Service

UaaS
Unified Communications as a Service

Managed and hosted communications channels. VOIP, instant messaging, LinkedIn, Skype, phones, Wi-Fi, social media… new communication channels appear at ever-shorter intervals and businesses struggle to keep their networks organized, secure, and efficient. Unified communications aaS vendors take care of all the hardware and software while guaranteeing a level of quality.

Market: Strong, established market with steady growth. Expected to expand from $15.1 billion in 2015 to $24.9 billion in 2020.

also
Understanding as a Service

VaaS
Video as a Service

Cloud-hosted video conferencing. As more companies move from phone to video conferencing, the IT headaches of keeping them running multiply. Companies moving to cloud-based video aaS enjoy higher-quality images and fewer dropped calls, with technicians on standby to keep things running smoothly.

Market: Small sector seeing strong growth. Expected to expand from $390.3 million in 2016 to USD $1.58 billion by 2021.

VaaS
Virtualization as a Service

One distant server, many accessible virtual machines. Ten years ago, turning one physical server into several virtual machines was a groundbreaking way to fully use server capacity and free up physical space. Today, it can be done via the cloud.

Market: Virtualization as a whole is considered a mature market—not many new opportunities here. Still, there’s $5.6 billion in revenue in virtualization as a whole.

WaaS
Workspace as a Service

Virtual desktop environments. Just log in to access your office desktop, exactly as you like it, with all the business data and applications you need, from any device you choose. Easy to see why this sector has taken off, especially among companies with remote workers and small businesses without resources to efficiently manage their own IT.

Market: Large and growing steadily. Expected to expand from $4.76 billion in 2014 to $9.41 billion in 2019.

also
Wi-Fi as a Service
Windows as a Service

XaaS
Anything (or everything) as a Service

Market: Expected compound annual growth rate of 38.2% from 2016 to 2020

Sources:
Business Cloud News, Business Insider, Computer Dealer News, Esri Insider, Everest Group, Forbes, Gartner, IDC, Information Week, MarketsandMarkets, MSPMentor, Network World, Recode, Research and Markets, SiliconAngle, Techopedia, TechTarget, Wikipedia, Wise Guy Reports, ZDNet

The post The Big -aaS List of As-a-Service Offerings appeared first on Auvik Networks.

When offering a network service to clients, managing servers and endpoints—and managing them well—is important. That pretty much goes without saying.

Devices like desktops and phones are the most visible and tangible part of the network to your clients. They’re the parts clients interact with nearly constantly. So when there are problems with endpoints, they get noticed and complained about immediately.

Endpoints are also the target of many network attacks. Phishing, ransomware, and malware count on the vulnerability (and often gullibility) of end users to make an entrance and infiltrate deeper into the network.

So yes, endpoints need attention. To help with that work, there are a lot of great tools for managing servers and endpoints—tools like Continuum, LabTech, Kaseya, and others.

But what’s typically missing from the network management picture—and the tools—is infrastructure.

Right now, despite it being 2016 and despite the wealth of tools for managing endpoints, most MSPs have nothing in place to help them see or manage network infrastructure like routers, switches, and firewalls.

Are you wearing pants under your desk?

When you signed that contract to manage the client’s network you said you’d manage X endpoints at Y cost, but the network was kind of fuzzy. You didn’t say you weren’t responsible, but you didn’t say you were either. The client expects you’re actively managing it. After all, they pay you every month to take care of “everything”.

This mismatch puts you at risk. We call it not wearing pants under the desk.

On the surface, everything looks great. “Oh yes, Mr. Client, everything’s under control.” But down below, you’re exposed and vulnerable. You know it—but the client doesn’t. And you’re just hoping it doesn’t hurt too much when you finally get bitten by infrastructure failure.

But it could hurt big time. Just how much? Oh say, $1 million dollars in lost production time. That’s what almost happened to a manufacturing client of California-based MSP ITque.

An unexpected routing change crashed the client’s network at 2 a.m. on a Saturday, right at the peak of weekend production time. Within 10 minutes, with an infrastructure tool, ITque was able to identify the problem as a routing change, see what the configuration used to be, and revert it to bring the network up.

ITque was wearing pants under the desk. But if they hadn’t been able to see and control the infrastructure, they figure they would have been there for at least 48 hours trying to troubleshoot and fix the issue. And the client would have lost $25,000 an hour in profit while it was happening.

As it turned out, ITque looked like heroes. By averting a costly disaster, ITque helped build trust with the client and deepen the relationship. And it was all made possible with a good infrastructure tool.

Manual isn’t profitable

Fixing an infrastructure issue using the CLI and manually configuring SNMP monitoring takes time you don’t have when a crisis strikes. Not to mention how much it costs you in labor.

Randy Latimer, a North Carolina-based MSP, says he worried about his exposure to infrastructure risk. “What ended up happening is we put a lot more manpower into that risk. We spent more time with bodies. We spent a lot of time.”

His techs were manually completing tasks like pinging infrastructure devices to see if they were up or down and backing up configurations. It didn’t mitigate the risk completely because a crash could still take days to figure out, but it was something. Trouble was, the work was so resource-intensive, it wasn’t profitable—until he got an infrastructure tool that automated much of the work.

“Now we can truly say we’re managing the network. It’s a lot easier and it’s actually profitable for us,” says Latimer.

Combining an infrastructure tool with a traditional remote monitoring and management system (RMM) ensures you’re covering the whole network. And covering the whole network equals less risk, happier clients, and more profit in your pocket.

The post Is Your MSP Exposed to Network Risk? appeared first on Auvik Networks.

In this ongoing series, we profile MSP (managed service provider) executives by asking them questions big and small. Have a question you think we should ask? Want to be profiled next? Let us know at blog [at] auvik [dot] com.

Charles Love
Director of Service Delivery, Untangled Solutions (a Wheelhouse IT company)

Year Untangled was founded:
2008

Number of employees
5

Percentage of business that’s managed services
75%

Your favorite conference and why
It’s a tie between ChannelCon and DattoCon. Both provide industry insights.

Where you get your industry news
Twitter and Flipboard mostly.

Your regular coffee order
French vanilla K-Cup with french vanilla creamer

What’s on your smartphone home screen
Flipboard, Find My Friends, Twitter, ConnectWise, email, Pokemon Go, Warcraft Authenticator, Waze, and WWE

How you run a meeting
Standing on the table – just kidding! I like to be on point, with an agenda and round robin closeout. (A bit scrum-style.)

A typical work day for you
A full day of living the MSP life, enjoying watching the team grow, having fun while doing it.

Someone in computer networking whom you admire
The Woz [Steve Wozniak]. He has a great story.

The one trait you look for in new hires
Flexibility. I often ask people how crop circles are made to see their reaction. It’s a misdirect question to see how they think on their feet.

Your best personal productivity tip
Make a ticket for your activities. This way you can track everything!

Peer or business networking groups you belong to
ASCII and CompTIA are my primaries.

What you’d be doing if you weren’t an MSP
Trying to become one. Or a rubber duck maker.

A geeky secret you have
I collect WWE title belts and accessories, and have them signed.

Podcasts — yes or no?
These are great listen-while-you-work items. Especially great when you have a commute. You need to stay current. How do you expect to know what’s coming out if you don’t listen?

What you wish all software vendors knew
Without you, there is no me. You complete me, LOL!

Best piece of conference swag you ever received
Novell-branded red Swingline stapler

A book you recommend for MSPs
The Compassionate Geek and 212 The Extra Degree

The Terminator movies — science fiction or the future?
Oh, totally the future!

The post Secrets of the MSP Pros: Charles Love appeared first on Auvik Networks.

In 2016, it’s hard to imagine a world without computer networks. (Go ahead and try it.)

People under 20 have no memory of life without the Internet, smartphones, and interconnected everything. Even some 30-somethings may be hard pressed to remember what the world was like before being online was as natural a state as breathing.

Entire industries would cease to exist without the Internet. Every business disruption of the last 20 years — from Uber and Airbnb to Facebook and Amazon — wouldn’t have occurred without computer networks.

Even smaller businesses rely on networks day in and day out to sell goods, book appointments, answer customer requests, advertise their services, and collaborate with teammates.

Network value is exploding

Clearly, networks have become an indispensable part of life on planet Earth in the 21st century. But just how much is a network worth?

Photo: Pixabay

Consider then the Internet of Things and the massive number of objects that are being connected. By Gartner’s estimates, 5.5 million new objects are added to global networks every day. In a just a few years, nearly 21 billion devices will come online.

Under Metcalfe’s Law, the expansion of the IoT means the value of networks is growing exponentially.

Network downtime is increasingly expensive

Another way to look at the value of a network is to consider the cost when the network goes down. We don’t have to look far for recent examples.

Photo: Wikimedia Commons

In August, Google went down for all of five minutes. And yet in those five minutes, the company lost $545,000 in revenue and Internet traffic dropped by 40 per cent.

True, we’re not all Google and Southwest Airlines. But when you rely on a network to get things done, downtime hurts no matter how big or small the business. The average is $5,600 lost per minute of network downtime.

The network is a change catalyst

Beyond keeping the lights on (sometimes literally), the network is also the key to business success. Any industry breakthroughs we’ll see in the coming years will have digitization at their core.

Photo: Dan Brickley on Flickr

Yet here’s where we start to see problems. “In 2015, businesses spent $12 billion on technology to increase the level of IT agility and evolve into a digital organization. However the network has yet to evolve,” the report says.

“Virtualization, the cloud, mobility and IoT enable … agility—but in most organizations, the network remains as inflexible and static as ever.”

The complexity of modern networks makes them difficult to manage effectively. According to ZK Research, it takes businesses an average of four months to implement network changes. That’s “far too slow for the digital era.” Operational expenses have also grown, increasing 300 percent over the past decade.

MSPs are network champions

Photo: E Fraser on Flickr

Think of it this way: If our planet relies on networks and you manage those networks, you are literally affecting the world. You’re champions, doing your part to secure, maintain, and advance the engines that keep everything running.

So delivering the very best network service isn’t just a goal, it’s a requirement. Actively managing and protecting the whole network is essential.

The network is valuable—and that makes what you do indispensable.

The post As Network Value Skyrockets, MSPs Become Increasingly Essential appeared first on Auvik Networks.

Everybody agrees network documentation is extremely important, but there tends not to be a lot of agreement on what that documentation should include. The short answer is that it should include everything that’s relevant—but what that means varies between networks.

For example, in a really small network with one switch and a firewall and perhaps a single wireless access point, there isn’t much to document. It might be enough to put everything in a single diagram.

But in a bigger network, you need to follow the general principle that somebody else will need to support this thing one day and you want to be remembered positively.

So the actual documents you need will vary depending on the network, but the following table shows the relative importance for a typical network.

Critical network documentation

Layer 1 and 2 diagram

A Layer 1 diagram shows the physical connections between the critical pieces of network infrastructure. It includes things like link speeds and cabling types. I like to see individual port numbers or designations on a Layer 1 diagram. Normally I represent the faster links using thicker lines and I use different colours for fibre and copper as well as for storage and data networks.

I often combine Layer 2 features onto the Layer 1 diagram because they seem to go naturally together. Layer 2 features include things like VLAN numbers, link aggregation, and trunk connections. Also, any Layer 2 diagram must include spanning tree information such as the root bridge and any bridge and link priorities that have been changed from their defaults.

If you aren’t running spanning tree, then you probably need a separate diagram just to thoroughly document what you’re doing with TRILL or alternatives. And if you don’t have spanning tree or TRILL and you have more than one switch, you’re doing it wrong.

Photo: Auvik Networks

Layer 3 diagram

Layer 3 diagrams include all your IP segments and all the network devices that interconnect them. That generally mean Layer 3 switches, routers, and firewalls. The IP segments should indicate any relevant VLAN ID numbers and a brief one or two-word description of the intended function, as well as the IP network number and mask. I like to put the IP addresses of the network devices on this diagram as well.

Any important redundancy mechanisms like HSRP or VRRP should be clearly indicated on the Layer 3 diagram. However, I don’t put end devices like servers on a Layer 3 diagram unless they have some extremely important network function — for example, a DHCP, DNS, or LDAP server.

Those are the network diagrams you absolutely need to have. In addition, you should have diagrams that represent other important features of your network. What’s considered important will depend on the network.

Circuit number table

Another piece of critical documentation, particularly if you have any WAN circuits or voice circuits, is a detailed listing of all of your circuit numbers. The list should include the circuit numbers and the network provider, as well as any information about where the circuit goes.

If it’s an MPLS circuit, the spreadsheet should include all of the MPLS provisioning information. If it’s an Internet circuit, then the amount and detail of the information could vary wildly depending on the provider and the type of circuit. And if it’s a point-to-point circuit, then it makes sense to include information about what’s on the other end.

I like to include support information in this listing of circuit numbers. What phone number do I call if this circuit goes down? If I need to provide special support contract information when I make that call, it should also be recorded here.

IP address allocation table

Next is the IP address allocation spreadsheet or database, which should include every internal and external, registered and private, IPv4 and IPv6 address you have in your environment. Every subnet should be listed separately, and every individual device should be recorded. If you’re using DHCP, which is also a good practice, for a range of addresses, just indicate these are dynamic addresses. But every static address allocation should be recorded.

Also, and this is most important, you need to be able to reserve addresses that you intend to use for a particular purpose in the future. Otherwise you’ll inevitably wind up giving out the same addresses to two different projects and creating completely avoidable conflicts.

I like to have a separate spreadsheet for all of my NAT addresses in which I describe exactly what each address is used for. If I have multiple internal or DMZ devices mapped to a single external address on different ports, then I carefully record each NAT rule. This makes life much easier the next time you need to add a new NAT rule.

Useful network documentation

Rack layout diagram

A rack layout diagram shows the server room or wiring closet racks with all of the equipment and patch panels. If you have equipment mounted to be accessible from both the front and back of the cabinet, then you should have diagrams for both the front and the back.

A rack layout diagram should be meticulously accurate about what equipment is mounted in which numerical position on the rack.

You’ll use a rack layout diagram when planning for where to put that next piece of equipment, as well as when talking to technicians and other IT staff about where to find things. It’s extremely important when you’re telling somebody to shut off the power to a particular device that they get the right one.

Rack layouts can also specify things like which aisle is hot and which one is cold, as well as power distribution. However, I don’t recommend putting patch cords on a rack diagram. That information is likely to change regularly, and it only clutters up the picture without adding much useful information. I’ll talk about how to record patching information later.

Photo: Banalities on Flickr

Wi-Fi diagram

If you have an important Wi-Fi component to your network, that should be documented. For Wi-Fi, I like to see floor layouts showing the physical locations of all access points (APs), preferably with RF radiation patterns indicated. This is particularly important if there are any special antennas in use with non-symmetrical radiation patterns.

As well, a good Wi-Fi diagram shows all of the SSIDs along with their intended purposes and security mechanisms. And if there are central Wi-Fi controllers, this information should be indicated in a text box.

Cable plan

A similar diagram that comes in handy whenever you’re troubleshooting an office network problem (like finding the guy who created a loop by cleverly plugging two jacks into the same unauthorized workgroup switch) is a cable plan. This diagram allows you to map the usually inscrutable jack numbers to physical locations in your building.

Routing protocol diagram

Another useful diagram is a routing protocol design. If there are separate routing domains that don’t directly exchange routes with one another, I often make them separate diagrams. For example, if I have an internal OSPF or EIGRP routing domain and an external Internet BGP routing domain, I always make these separate diagrams.

The routing protocol diagram should indicate all autonomous systems, internal areas, and redistribution points and it should clearly indicate special features such as route tagging or filtering.

Security diagram

Another special-purpose network diagram I like to include in my documentation package is a security view. It’s similar to the Layer 3 diagram except that it focuses on things like the Internet edge, as well as any internal or Internet DMZs.

Of course, all special security equipment needs to be clearly indicated on this diagram.
The standard Layer 3 diagram includes firewalls, but the security diagram needs to also include any special security probes, IDS/IPS devices and passive or active taps. I also want to see central management devices like SIEMs and log servers on this diagram. If there are any important NAT rules or firewall rules, it’s often useful to indicate these as well.

Photo: Haria Varlan on Flickr

Cloud services diagram

If you have any cloud services like AWS, you should document them. Cloud service diagrams need to include all of the security zones, and should probably also include all of the virtual servers in the environment.

If you have any special network security infrastructure in your cloud services like firewalls, load balancers, or WAF virtual devices, they need to be clearly described so that the next person can easily understand what you’ve done and how to manage it.

If you have a VPN between the cloud and your internal network, it’s extremely important to include that feature on the diagram because it’s here the most sensitive information will typically be sent, and it’s also a potential backdoor into your network.

Patching table

In a data center, you should document your patch panels. Data centres usually have many different kinds of links, from fibre and copper to perhaps some twinax or Infiniband. And every device is both important and potentially unique. Mistakes could take down the entire network.

Conversely, the patch panels that support all of the users in the west wing of the third floor probably has most of those users connected to identically configured switch ports. It’s certainly useful to keep a good patch table for it, but it’s really not as critical as the data centre patching information. As I mentioned earlier, though, you do want to have a physical map showing where all of those office cables go so you can troubleshoot problems down to the end user.

At a minimum, the patching documentation should show, for every port in the panel, exactly what’s connected on the other end of the cable. If the device or panel on the other end has lots of ports, then the destination port should be uniquely identified along with the device.

The documentation should also indicate what type of patch cord is used. Is it Category 6? Is it fibre? If it’s fibre, is it single mode or multi-mode and what are the connector types on both ends? If the patch cords have unique identifying numbers, which is a good practice, those numbers should be included as well.

Asset tracking

It’s very useful to have a table of asset tracking information. For this, I’m usually not too concerned about commodity items like phones, printers, or workstations. Instead, the list should include the critical pieces of infrastructure like switches, routers, and firewalls, as well as any critical pieces of server hardware.

In the asset tracking information table, I want to see manufacturer names, models, serial numbers, and license numbers. You also want to include support contract numbers so you know who to call if something goes wrong.

Photo: Pixabay

Password vault

One important and useful piece of documentation is a password vault. If you have static administrative passwords on any of your network appliances, store these credentials in an encrypted vault of some kind. In general, I prefer the devices to use a central authentication system like RADIUS or TACACS, but inevitably there will be some devices that need static passwords. And in most cases, you’ll also have fallback passwords that can be used if the central authentication system breaks.

Nice-to-have network documentation

Some other pieces of network documentation depend on the situation.

Network design document

If I’m designing a network for a client, I often do a detailed design document. It’s often a fairly long document in which I describe the design and explain the intended functions of every new feature and new section in the network.

It can be helpful to include a decision log where you identify all of the key design decisions and explain why they were made. For example, perhaps you’ve chosen to use a particular routing protocol because of the need to support a particular legacy requirement. Or you might have wanted to implement a more sophisticated and robust feature in part of the network, but ran into compatibility problems so you had to resort to a brute force solution instead. These notes becomes very useful later when you wonder why something was done a particular way and whether it’s safe to change it.

Network support document

I sometimes write a support document to help with migrating the infrastructure to production. It includes things like suggestions for how to implement new systems within the framework that I’ve made, and recommendations for where and how to modify security restrictions to allow new services through the firewalls without compromising the design. It might also include troubleshooting notes. For example, I might list the expected symptoms of common failure modes like circuit failures.

Routing snapshot

If you run a particularly large network, it’s often useful to maintain a good set of routing snapshots of the routing tables for use when troubleshooting. This could include routing protocol information as well. And you could similarly record other dynamic topology information like spanning tree link states for the same reason.

Final thoughts

Now that I’ve outlined what to collect and document, there’s still the question of how you will do it — that’s your documentation process. Tools can help you automate the process so you’re not spending all your time manually collecting and maintaining information. They can also ensure that all members of your team always have the same accurate information.

But no matter what method you use, what’s important is a consistent process that produces quality information and keeps that information up to date.

The post Network Documentation Best Practices: What to Create & Why appeared first on Auvik Networks.