Geek Speak

10 Posts authored by: KMSigma Administrator
(Disclaimer: This post was co-written by Leon and Kevin and presents a point/counterpoint style view of Cisco Live US 2019. But without either calling the other “ignorant” or insulting their choice in quantity of romantic liaisons.)


Kevin M. SparenbergThis year, once again, it was my absolute pleasure to be part of the staff that attended Cisco Live! US. Part of my time was spent in the booth and the rest of my time was spent in various sessions to catch up on everything from the last year. If there’s one thing that really resonated with me this year, even more than previous, was how quickly IT is moving.
This year, in a flurry of last-minute activity, I discovered I would be attending Cisco Live. Because of its proximity to the Jewish holiday of Shavuot (which is most notable for commandment to consume vast quantities of cheesecake. I regret nothing.) I didn’t think I’d be attending. But I did, and I’m extremely happy the powers-that-be at SolarWinds helped make that happen. Because let me tell you, times, they are a-changing!Leon Adato
Kevin M. Sparenberg

At the SolarWinds® booth, we talked about all the greatest additions and updates to the portfolio of products. In the last year, SolarWinds has released 32 updates to existing products or completely new products. To say it’s been a busy year may just be a tad bit of an understatement. For booth visitors, we got to show off some of the new enhancements to our network management portfolio and retread some of the past favorites (looking at you here, NetPath).

It really should come as no surprise that “it’s been a busy year.” They’re all busy. You folks keep telling us about persistent problems and challenges, and that’s what we set out to fix. If you’ve been following these Cisco Live reports for even a couple of years, you know that this is the time when we release those solutions into the wild.

Leon Adato
Kevin M. SparenbergThis year, more than most, I spoke with more people whose title didn’t include the word “network.” On the surface this would seem odd, but more and more organizations are recognizing that networks aren’t what their end users interact with, it’s the highway on which those interactions happen. Having a blazing fast network is great but doesn’t help if you are connecting to a server which takes 1,500 milliseconds to even send back the first bit of data. If that happens, you’re still going to have a horrible experience. As a former network engineer, I know the network is always blamed first, but how often is it really a network problem?

From MS Ignite to VMWorld to Cisco Live, I’ve been noticing that the same people are at every show. I don’t mean the same EXACT people, like some weird convention groupies or something. I mean that rather than having strictly systems folks coming to Ignite, virtualization admins at VMWorld, and network engineers at Cisco Live, the people who visit are concerned with multiple (or all) areas of their environment. They’re as likely to talk about virtual database instances on vSANs as they are about load balancing or traditional route/switch.

Leon Adato

Day One


Kevin M. Sparenberg

But those that know us, know that like to have fun at these events. One of those things was #KiltedMonday, which is a tradition that the Monday of Cisco Live! US, attendees are encouraged to wear their kilts instead of the blasé pants. I added a kilt to my ensemble a few years ago, and I kept it strong this year. As good as it was to be able to show off my shins, it was good to speak with everyone who came up to the booth. But the best part, the absolute best part, was introducing some new SolarWinds people to the booth experience.


We had a handful of “raw” recruits this year. This wasn’t just their first Cisco Live, this was their first ever event with SolarWinds. Monday is always a mad dash for swag, new feature demos, and saying “hi” to old friends. All I can say is that the new recruits did a smashing job at handling the flow, pivoting on topics, and responding to questions. Day one is typically the most hectic and a good trial-by-fire. Not too much unlike starting a new job in IT.

Monday was still a holiday for me.

Leon Adato
Kevin M. Sparenberg

Status update: Voice is already scratchy. Must come up with a regiment so I don’t “talk” myself hoarse on the first day.

Day Two


This was my first day on the show floor, and I have to tell you there’s no convention like Cisco Live. It’s hard to describe the intensity of the folks who come to the booth, the level of depth we get to go into in our conversations and demos, and the sheer love—of the product, of the philosophy of monitoring, and of the team. I’ve taken to ask visitors to the booth what THEY think the “big story” of Cisco Live is. On Day 2, all anyone could talk about was the changes to Cisco Certification program. Immediately after the keynote, there were a lot of emotions… ahem… “passionately held and strongly worded opinions” across the convention floor, but by the end of the day the prevailing wisdom could be summarized as:

  1. It’s not changing immediately
  2. Most certifications aren’t going away
  3. This makes it easier for certain folks (especially CCIE’s) to re-up their cert

…and thus, calm was restored to the masses.

Leon Adato
Kevin M. Sparenberg

On day 2, we held a SolarWinds User Group™ at Roy’s Restaurant right next to the San Diego Conference Center. The venue was gorgeous with vistas overlooking the marina and fantastic Polynesian fusion food. The signature mai tais were not to be missed. At that event, Chris O’Brien, Group Product Manager for the SolarWinds Network Management portfolio talked about all the goodness we delivered the week before. Then it was up to me to talk about everything else that SolarWinds released in the last year. Needless to say, I didn’t cover everything, or I’d still be there talking. Part of SWUG™ is the presentations, but most of SWUG is the conversations between customers. The best, most important part of our community is you, the people who work with our solutions every day. I’m constantly amazed at how gracious and courteous you are with any newcomers to the THWACK® community. You share your expertise, tips, tricks, and more with anyone willing to ask. If I had the opportunity to shake hands with every member who has helped me over the years, I’d do it in a heartbeat and be humbled by the experience. This is just one reason that I feel this is the greatest community in IT. With day two wrapping, I was both exhausted and energized for the rest of the week.

Day Three


Kevin M. Sparenberg

The post-SWUG hangover is always a rough day. It’s not to say that it’s a true hangover, but the exhilaration of speaking with so many people can make the follow-up day feel just a little bit longer. Thankfully, there was a new wave of swag in the booth, which makes the customer-in-me always happy. Today’s “word” of the day was API and I don’t care how you pronounce it (cue Leon groaning at me). I find it very profound that technology is so cyclical. When we started, everything was command line interface only, then we moved onto a GUI, and now we’re back to command line. It’s just one of those oddities that I’ve picked up being in the industry for so many years. As new technology comes out, there’s a push, nearly a requirement, to make sure that you can attach to it via a programmable interface.

The big story from the floor was the way Cisco is adopting a “Meraki style” process to integrating new features into their product. What I mean by that is this: When you have Meraki wireless controllers, when a new feature comes out, the software updates in the cloud and BOOM! you’re in business. And honestly, this has been one of the big complaints of CLUS attendees for several years. They come to the show, get all hyped up on the latest tech (including DNA and intent-based networking), and then go back to their office, only to realize that the molecules they have on site (i.e., the physical gear) can’t handle it, and won’t be retired for several years. While the bean counters may complain about subscription-based models, the fact that it will get the new code into our shops is going to change the speed at which new technologies, protocols, and techniques are adopted.

Leon Adato

Day Four


Kevin M. Sparenberg

The last day on the show floor for the booth staff brought both sighs of relief and sadness at parting. I love talking to people, so the final day always makes me a little sad. I love hearing how everyone is handling their own IT infrastructure. No one has infinite time, so you’ll never get to work hands-on with every technology. Being able to hear what various attendees got from the event is always a high point. Yes, there were product announcements, new technologies, and enhancements abounded, but the real thing for me is the community that happens at events. Part of that is connecting with other people. Those people could be coworkers from another office, other IT professionals you’ve gone to for advice, or new people you meet for the first time. One of the ways that I leveraged this event to reconnect was to go to lunch with my friend and co-worker, Leon, where we discussed our personal findings on the event. That, in part, was the impetus of this post.

One attendee told me he thought that “the ubiquity of the story around ‘umbrella’” was the big story for the show. Which is awesome (because #SECURITY!) but it’s also amusing, because you can find “Introducing Umbrella” as a session at every Cisco Live (US, EUR, LATAM, and APAC) back to 2016. Even at SolarWinds, we know that sometimes you have to keep talking about an idea for a bit before people start to notice it (looking at you, AppStack™). The other story worth noting was just how busy the expo floor remained. We had folks coming into the booth asking serious questions, and looking for in-depth demonstrations, up to 30 minutes AFTER they closed the show down. Now THOSE are some dedicated IT professionals!

Leon Adato

The Completely Un-Necessary Summary


Kevin M. Sparenberg

At the end of the week, the biggest takeaway for me was the number of non-network people walking around Cisco Live. This concerned a handful of the booth staff, some of the other vendors, and many of the attendees, but not me. For me, this was the year when topics started shifting from an us vs. them to more of an us with them focus. Functional silos are great for training and specialization, but horrible for troubleshooting real-world issues. The number of systems administrators, security operations professionals, and monitoring engineers this year was up and that made me smile. Attendees inquiring about how complete stack monitoring can help them get to root causes (or at least to stop spinning their wheels chasing red herrings) was an absolute pleasure to hear. Even if the problem isn’t in your wheelhouse, ignoring it doesn’t make it go away. Good tools can help pinpoint the problem and get you back to happy.

Next up for me is the New York SWUG and I’m looking forward to connecting with people again at that event. Hopefully by that time, my voice will have returned to its pre-event levels. Cisco Live may be over for this year, but that doesn’t mean the lessons learned or the connections made will go away.

As Kevin and I both noted, Cisco Live is unlike any other show we attend. At the same time, this year was different in one notable way—while every other year the visitors to our booth were both steady (the booth really never got empty) and relentless (we’d usually be doing a demo and have one or more people queueing up for a demo after we were done); this year we saw distinctive ebbs and flows. At first I worried that SolarWinds had somehow lost its mojo, but then we saw that the rest of the expo floor was equally barren. By the third day, I was asking around for reasons. It turns out that there was a rumor going around, that if you badged into a session and left early, the RFID sensors would pick it up and you wouldn’t get credit for attendance. That kept butts in chairs when they might otherwise have used the time to talk to your favorite monitoring enthusiasts. We’ll have to wait until next year to see if that rumor continues to hold sway.

Speaking of next year, mark your calendar and start saving your pennies. Cisco Live returns to Las Vegas, running from May 30 – June 4. For those of you with a Jewish holiday calendar handy, that means it starts the day AFTER Shavuot. I’ll make sure I have plenty of leftover cheesecake on hand.

Leon Adato

Those are our thoughts. What was your experience?

We’re sure getting excited for THWACKcamp™ 2018, and I’m particularly excited for you to join me at one of my sessions, There’s an API for That: Introduction to the SolarWinds® Orion® SDK. You won’t want to miss out on this exciting and informative session, so be sure to make it a part of your session track planning, along with the other highly-anticipated THWACKcamp sessions.


During this session, I’ll be joined by two fellow THWACK® MVPs. You’ll be able to watch history in the making, as it’s the first time three MVPs present a THWACKcamp session together. On top of being THWACK all-stars and IT experts, Zack Mütchler (zackm) is an experienced software engineer and Leon Adato (adatole) is a SolarWinds Head Geek™. Together, the three of us will deep dive into the Orion Platform API, which is readily available for anyone who has installed and is working on the Orion Platform. As the title implies, this session is not just about the API, but also the Software Development Kit (SDK), which is essentially a bunch of tools that can help you use and interact with the API. With all this already at your disposal, what next? Tune into this session so you can learn exactly what the SDK and API are capable of, and how you can use both to their greatest potential, including removing some of the repetition involved with your tasks, and in the process, make your life a little easier.


THWACKcamp is the two-day, premier online IT event that anyone involved in or interested in the IT world should be a part of. A top-tier event like this must be pretty expensive, right? Not at all. You can take part in this entirely virtual, totally awesome IT learning event for free! You don’t even have to worry about travel costs, since it can be accessed anywhere there’s Wi-Fi. Register now for THWACKcamp 2018, taking place October 17 – 18. See you there!

Flood of Kobolds vs. Epic Boss Fight

I had a group where I was running a dragon-themed adventure.  Before you gasp and say mockingly, “In Dungeons & Dragons, there are actually dragons?” let me tell you that that was just thematic (as far as my players knew).


Part of this was making Kobolds be in a frenzy because they were acting on the orders of their dragon overlord.  For those unaware, Kobolds are the cannon fodder of the D&D world.  The party was repeatedly beleaguered by hordes of them with staged battles (archers then infantry then mages).  Long story short, each battle felt like a big fight with the difficulty ramping up each time.  Unfortunately for my players, these were just the opening volleys.

The big battle was against a young dragon.  Don’t let the word “young” distract you from the word “dragon.”  This wasn’t an easy fight.  Sadly, it was nearly a total party kill (TPK) for the group because they got overconfident based on their previous encounters.  Confidence is great – overconfidence less so.

I’ve seen the same thing in IT.  Technicians get cocky thinking that they know everything and bite off more than they can chew.  This is typically something that green IT people do, but they don’t have exclusive rights to this failing.  The thought that “in a perfect world it will go just like this” falls on its face when you realize that there’s no such thing as a perfect world.  New IT people sometimes don’t have the good sense to think, “maybe this isn’t just one-degree harder than the previous thing I did.”  If there’s a lesson to be learned here, it’s that you cannot win every fight with the same skills you already have.  Learn new ones and evaluate your scenarios before rushing in.


We get to the final question here, “Has running a D&D game actually provided me with any life skills?”  The answer is a resounding “Yes!”  So much so, that I would have no issue putting a few things on my professional resume.

·         Meet with peers for scheduled creativity and conflict resolution exercises

·         Assisted multiple people with gathering experience for both character and skill development

  Learned to quickly assess situations and collaborate on best solutions

Short-Circuiting your Adventure

I’ve noted that preparation and planning are some of the hallmarks of both a good DM and IT professional, but sometimes planning gets short-circuited.  In the past, I’ve spent hours working on a campaign with intricate details, a slowly building storyline, interesting character interactions, and a clear path from point A to B to C and so on.

Then we sit down to play this epic tale, and the players choose to follow the white rabbit instead of the obvious path in front of them and jump immediately to point J.  That’s it.  A small change and they’ve completely gone off course.  In the past, I’ve had this go one of two ways: the group takes a petty diversion and makes it more than it’s supposed to be or they’ve jumped ahead in the story so much that I don’t have anything else planned.  As the DM, you can either throw up your hands and walk away, force them back on the “right” path, or see where the adventure leads.

One of those avenues reminds me of scope creep in IT Projects.  You’ve outlined everything in a beautiful waterfall plan and the team starts taking side-trips and tacking on new requirements.  The adventure of discovery is upon you!  Keep going!  Let’s see where this will end up.  Will planning to only swap out a power supply lead to the adventure of replacing all the UPS’s in a data center?  Who knows?  Mystery abounds.

The clear answer here is “within reason.”  You’ve planned one change and now people are adding more and more to that change request.  Where do you draw the line?  I can’t answer that for you, because it’s different for every scenario, but you should be open to change.  Embrace it where you can and push it off where you cannot.

The flip side of this scope creep is having your entire plan thrown out and being asked to “skip to the end.”  Just like in D&D this leaves you asking, “what’s next?” and not having a clue.  Maybe you’ve only planned for five steps and you need to jump right to step six.  Can you plan for this?  Probably not.  About the only thing you can do it plan for unexpected.

Looking back, the same solution presents itself for each problem: plan for the unexpected.  This applies to the players, the DM, and the IT Professional.  There’s always going to be another tree in the forest, and there might be a goblin archer behind one.  Plan for these diversions, but don’t let them pull you from your goal.

This is the second post in a post that started in Part the First.

CRIT! Unplanned Good/Bad

Randomness is a part of life.  This has widespread areas of affect: from human interactions to chaos theory.  To make Dungeons & Dragons more lifelike, it needs to inherit this randomness from real life.  This is where the dice come in.  The one that’s used most often is the 20-sided die (referred to as a d20).

On any roll of a d20, you have a 5% chance to get any number.  The best and worst rolls being a 20 or a 1, respectively.  Anyone has a 5% chance of hitting either result (thanks math!).  In D&D these get special connotations: they are called Critical Rolls.  So, a 20 is a Critical Hit and a 1 is a Critical Fail.

Critical Hits in IT

Sometimes you or your team just hit something out of the park.  Yes, I’m mixing metaphors here, but you get the point.  You didn’t plan for this task to go as well as it did.  You’ve moved 1,000 mailboxes during the night with no downtime.  Your team executed a zero-downtime upgrade of a SQL cluster.  Your coworker applied configurations to 200 WAN routers with no blips.  This a Critical Hit!

On the chance that you’ve encountered one of these rare events, be sure to celebrate.  Do a little dance, take everyone out for a lunch, let your management team know about it, whatever you do to mark accomplishments.

Then again, there’s the other side of the coin die.

Critical Fails in IT

I hate to say it, but in Information Technology, it always feels like there’s more probability of getting a 1 on a d20.  I stated earlier that in the game, you have a 5% chance to get a critical failure, but real-life IT probability feels skewed towards failure instead of success.

In game when you have a critical failure whatever you are trying to do fails… epically.  You go to push a troll off a bridge and instead you lightly caress his shoulder.  You both feel awkward.  This is an epic failure and the scope of it is bound to DM discretion.

In IT, epic failures take different forms.  They can be something as simple as turning off the wrong port on a switch or as great as crashing a mail server.  An IT department doesn’t have a DM to choose what happens when things go wrong.  Instead we rely on our own knowledge and the experience of others to help guide us on how to proceed.  Quick thinking and decisive action are key parts to following up after a failure, but the best thing you can do is communicate.

Communicate with the department and the affected parties.  Clean, clear communication of the issue and your plans for recovery are the first, best thing you can do after getting an epic failure.  Here’s where every member of IT gets to be their own DM.  It’s up to you to decide the next move.  Make it a good one with transparency.

So, here’s the first confession: I’m an über nerd.  I’ve been playing Dungeons & Dragons (D&D) since I was about 16 years old.  It was also about that time (possibly coincidentally) that I also became engrossed with computers.  Not just watching my fake family die from dysentery, cholera, snake bites or drowning, but actually how they worked and why this was important.

In High School, I had a job with a few good friends and still had some free time.  What’s a teenager to do with some free time, friends, evenings off, while still maintaining a clean criminal record?  We decided to give this Dungeons & Dragons thing a try.

Defining Roles

Part of the deal with a new D&D group is punishing someone deciding who will be the Dungeon Master (the “DM”).  Where everyone else gets to read parts of one book, the DM gets to read that whole book and two others.  Your job as DM is to provide the game bounds and guide the characters on their adventures. Done well, it’s like collective story telling with some randomness added.

Looking back, the parallels between working in Information Technology and running a D&D campaign have striking similarities.

Party Balance

Confidence and a little bit of showmanship are key attributes of a DM.  You are the center of attention most of the time as you weave the story and outline possible paths.  Understanding and enforcing the rules is important, but even more vital is keeping the players working together.  This can be especially difficult based on their experience with the game, the varying personality types, and the jobs or alignments they’ve chosen for their characters.

Thinking back, this isn’t any different than working with an IT Team.  There are going to be people who know more than others, each will different skills, and their personalities can be just as varied.  Leading a team like that can be frustrating, but also incredibly rewarding.  The different skills create a great “party balance” and the different levels of experience offer multiple perspectives when solving a problem.

Come to think of it, creative problem solving is also something that crosses the boundaries of Dungeons & Dragons and Information Technology.  Given a situation (dragon in a tower or storage array tray failure) you need to work together to try and find a solution.


Some would argue that being a Dungeon Master is only as difficult as taking the time to do the reading and planning.  Sure, you can pick up a pre-written module, but you still need to read through it and prepare.  Planning is key as it keeps the process (or story) moving forward.  Keeping tabs on various players, settings, and key items is just as important as getting updates on teammates, inventory, and project status.

My past, in both IT and D&D, have influenced each other in more ways that I can count.  In a game a few years ago, my wife was playing as an elven bard.  Basically, her role in the party was to poke fun at the other players and keep things moving forward.  If the players were sitting on their hands debating opening a door, she would kick it in and keep the game moving forward.  Whether she knew it or not, she was acting as my Project Manager – keeping the process moving.

Check back for part 2 soon.

Every year, THWACKcamp is my favorite industry event. Yes, I like going to Microsoft Ignite, VMworld, and Cisco Live, but interfacing with more like-minded people is my bag. This is why things like the SolarWinds User Groups and THWACKcamp are my jam. I’ve been attending THWACKcamp since the beginning.


Let me start by saying that I was a proponent of SolarWinds’ solutions long before it became cool. Does that make me a SolarWinds hipster?  If so, I’ll wear that fedora at an ironic, yet jaunty angle. Years ago, I joined the THWACK community and sometime later was invited to be a THWACK MVP. Since that time, I moved to the “dark side” and became a Product Manager for SolarWinds.

Although I’ve participated in THWACKcamp as a customer since the beginning, this is my third year seeing THWACKcamp from the inside. I've been able to be a part of THWACKcamp since 2015, and I have to say that this year's event was the biggest and best. As always, the content was great. We got input from some of the biggest names in the industry and even had some grace our studio. This year there were more panels, more real-world discussions, and more input from the community than ever.

All of this was great, but I’m here to tell you that the best part was hearing from and meeting THWACK MVPs. This year we had 22 in attendance (25 if you count Leon, Mike, and myself ). You even got to see some of them during the live interludes between sessions.  Many are repeat visitors, others were people I’ve only met at SWUGs, but several were new faces. Though I’ve spoken with many of them online, this was the first time for me to meet them face to face.

Many of these people traveled thousands of miles to be here for the event. In an effort to make it as enjoyable as possible, we tried to line up a few outside events. Thus, the hangover.

Day 0

On Day 0 (the day before the official event), we set up a game night. I got to break out my uber-nerdiness and run a session of Dungeons & Dragons for some of the MVPs.

Here there be dragons... in dungeons.

We even decorated the game room (big thanks to mrssigma for gathering all the goodies)! And a week later, the decorations are still up.  I have no intentions of taking them down... ever.

The Gates of Fun!

Because you can't have a game night with just one game, another group gathered to play SysadMANIA. The laughter was loud and often.

sysADMANIA spotted in the wild!

Day 1

Then Day 1 happened and introductions were made, conversations exchanged, and assistance grabbed.

At the end of Day 1, there was a UX Happy Hour, which turned into a Happy Evening. So happy that even though the restaurant closed at 9:00 pm, we stayed until nearly 11:00 pm.

UX Happy Hour(s)

Day 2

Day 2 began a little slow. I mean, we all got there, but some of us were worse for the wear.

The second day also included more laughs with the MVPs, including a game of "Who Wore it Better?"

Who Wore it Better?

Day 2 ended with a surprise from the MVPs. They unveiled the T-shirts they designed in honor of the UX team.

It brought meech to tears and hugs were everywhere.

Day 2 ended with me going to my bowling league, so I had to beg out of the second-night shenanigans, but that doesn't mean that there isn't photographic evidence.

So I missed some fun.

For the second night in a row, the MVPs closed not one, but two restaurant/bars.

What a great year! It was really fun meeting up with people, talking tech, and building friendships.

Do you feel like you missed anything? Were you unable to watch one session because you had to choose another in the same time slot? Fear not, you can watch all of them here! Check out what you missed, or watch your favorite sessions again, as often as you can. If you're like me, you are already anticipating THWACKcamp 2018. I can't wait!

Without a doubt, we're at a tipping point when it comes to security and the Internet of Things (IoT). Recently, security flaws have been exposed in consumer products, including children's toys, baby monitors, cars, and pacemakers. In late October 2016, Dyn®, an internet infrastructure vendor, suffered a malicious DDoS attack that was achieved by leveraging malware on IoT devices such as webcams and printers that were connected to the Dyn network.


No, IoT security concerns are not new. In fact, any device that's connected to a network represents an opportunity for malicious activity. But what is new is the exponential rate at which consumer-grade IoT devices are now being connected to corporate networks, and doing so (for the most part) without IT's knowledge. This trend is both astounding and alarming: if your end user is now empowered to bring in and deploy devices at their convenience, your IT department is left with an unprecedented security blind spot. How can you defend against something you don't know is a vulnerability?


BYOD 2.0

Right now, most of you are more than likely experiencing a flashback to the early days of Bring Your Own Device (BYOD) - when new devices were popping up on the network left and right faster than IT could regulate. For all intents and purposes, IoT can and should be considered BYOD 2.0. The frequency with which IoT devices are being connected to secured, corporate networks is accelerating dramatically, spurred on in large part by businesses' growing interest in leveraging data and insights collected from IoT devices, combined with vendors' efforts to significantly simplify the deployment process.


Whatever the reason, the proliferation of unprotected, largely unknown and unmonitored devices on the network poses several problems for the IT professionals tasked with managing networks and ensuring the organizational security.


The Challenges

First, there are cracks in the technology foundation upon which these little IoT devices are built. The devices themselves are inexpensive and the engineering that goes into them is more focused on a lightweight consumer experience as opposed to an enterprise use case that necessitates legitimate security. As a result, these devices re-introduce new vulnerabilities that can be leveraged against your organization, whether it's a new attack vector or an existing one that's increased in size.


Similarly, many consumer-grade devices aren't built to auto-update, and so the security patch process is lacking, creating yet another hole in your organization's security posture. In some cases, properly configured enterprise networks can identify unapproved devices being connected to the network (such as an employee attaching a home Wi-Fi router), shut down the port, and eradicate the potential security vulnerability. However, this type of network access control (NAC) usually requires a specialized security team to manage and is often seen only in large network environments. For the average network administrator, this means it is of premier importance that you have a fundamental understanding of and visibility into what's on your network - and what it's talking to - at all times.

It's also worth noting that just because your organization may own a device and consider it secure does not mean the external data repository is secure. Fundamentally, IoT boils down to a device inside your private network that is communicating some type of information out to a cloud-based service. When you don't recognize a connected device on your network and you're unsure where it's transmitting data, that's a problem.


Creating a Strategy and Staying Ahead

Gartner® estimates that there will be 21 billion endpoints in use by 2020. This is an anxiety-inducing number, and it may seem like the industry is moving too quickly for organizations to slow down and implement an effective IoT strategy.


Still, it's imperative that your organization does so, and sooner rather than later. Here are several best practices you can use to create an initial response to rampant IoT connections on your corporate network:

  • Create a vetting and management policy: Security oversight starts with policy. Developing a policy that lays out guidelines for IoT device integration and connection to your network will not only help streamline your management and oversight process today, but also in the future. Consider questions like, "Does my organization want to permit these types of devices on the corporate network?" If so, "What's the vetting process, and what management processes do they need to be compatible with?" "Are there any known vulnerabilities associated with the device and how are these vulnerabilities best remediated or mitigated?" The answers to these questions will form the foundation of all future security controls and processes.
    If you choose to allow devices to be added in the future, this policy will ideally also include guidelines around various network segments that should/should not be used to connect devices that may invite a security breach. For example, any devices that request connection to segments that include highly secured data or support highly critical business processes should be in accordance with the governance policy for each segment, or not allowed to connect. This security policy should include next steps that go beyond simply "unplugging" and that are written down and available for all IT employees to access. Security is and will always be about implementing and verifying policies.
  • Find your visibility baseline: Using a set of comprehensive network management and monitoring tools, you should work across the IT department to itemize everything currently connected to your wireless network and if it belongs or is potentially a threat. IT professionals should also look to leverage tools that provide a view into who and what is connected to your network, and when and where they are connected. These tools also offer administrators an overview of which ports are in-use and which are not, allowing you to keep unused ports closed against potential security threats and avoid covertly added devices.
    As part of this exercise, you should look to create a supplemental set of whitelists - lists of approved machines for your network that will help your team more easily and quickly identify when something out of the ordinary may have been added, as well as surface any existing unknown devices your team may need to vet and disconnect immediately.
  • Establish a "Who's Responsible?" list: It sounds like a no-brainer, but this is a critical element of an IoT management strategy. Having a go-to list of who specifically is responsible for any one device in the event there is a data breach will help speed time to resolution and reduce the risk of a substantial loss. Each owner should also be responsible for understanding their device's reported vulnerabilities and ensuring subsequent security patches are made on a regular basis.
  • Maintain awareness: The best way to stay ahead of the IoT explosion is to consume updates about everything. For network administrators, you should be monitoring for vulnerabilities and implementing patches at least once a week. For security administrators, you should be doing this multiple times a day. Your organization should also consider integrating regular audits to ensure all policy-mandated security controls and processes are operational as specified and directed. At the same time, your IT department should look to host some type of security seminar for end-users where you're able to review what is allowed to be connected to your corporate network and, more importantly, what's not allowed, in order to help ensure the safety of personal and enterprise data.


Final Thoughts


IoT is here to stay. If you're not already, you will soon be required to manage more and more network-connected devices, resulting in security issues and a monumental challenge in storing, managing, and analyzing mountains of data. The risk to your business will likely only increase the longer you work without a defined management strategy in place. Remember, with most IoT vendors more concerned about speed to market than security, the management burden falls to you as the IT professional to ensure both your organization and end-users' data is protected. Leveraging the best practices identified above can help you begin ensuring your organization is getting the most out of IoT without worrying (too much) about the potential risks.

This is a cross-post of IoT and Health Check on Sys-Con.

I may be dating myself, but anyone else remember when MTV® played music videos? The first one they ever played was The Buggle's "Video Killed the Radio Star."  The synth-pop feel of the song seemed so out of place with the words, which outlined the demise of the age of the radio personality. Thinking back, this was the first time I can remember thinking about one new technology completely supplanting another. The corollary to this concept is that radio stars are now antiquated and unneeded.


Fast forward a few decades and I'm entrenched in IT. I'm happily doing my job and I hear about a new technology: virtualization. At first, I discounted it as a fad (as I'm sure many of us old-school technologists did). Then it matured, stabilized, and gained a foothold.


One technology again supplanted another and virtualization killed the physical server star. Did this really kill off physical servers entirely? Of course not. No more so than video killed radio. It just added a level of abstraction. Application owners no longer needed to worry about the physical hardware, just the operating system and their applications. Two things happened:

1.       Application owners had less to worry about

2.       A need for people with virtualization experience developed


From that point on, every new person who entered IT understood virtualization as a part of the IT stack.  It was a technology that became accepted and direct knowledge of physical servers was relegated to secondary or specialized knowledge. Having knowledge about firmware and drivers was suddenly so "retro."


Virtualization matured and continued to flourish, and with it, new vendors and capabilities entered the market, but dark clouds were on the horizon. Or perhaps they weren't dark-just "clouds" on the horizon. As in private clouds, hybrid clouds, public clouds, fill-in-the-blank clouds. The first vendor I remember really pushing the cloud was Amazon® with their Amazon Web ServicesTM (AWS®).


Thinking back, this seemed like history repeating itself. After all, according to many, Amazon nearly destroyed all brick and mortar bookstores. It looked like they were trying to do the same for on-premises virtualization. After all, why worry about the hardware and storage yourself when you can pay someone else to worry about it, right?


This seems reminiscent of the what happened with virtualization. You didn't worry about the physical server anymore-it became someone else's problem. You just cared about your virtual machine.


So, did cloud kill the virtualization star, which previously killed the server star? Of course not. For the foreseeable future, cloud will not supplant the virtualization specialist, no more so than virtualization supplanted the server specialist. It's now just a different specialization within the IT landscape.


What does this mean for us in IT? Most importantly, keep abreast of emerging technologies. Look to where you can extend your knowledge and become more valuable, but don't "forget" your roots.


You never know-one day you may be asked to update server firmware.

This is a cross-post from a post with the same name on the VMBlog.

As technology professionals, we live in an interruption-driven world; responding to incidents is part of the job. All of our other job duties go out the window when a new issue hits the desk. Having the right information and understanding the part it plays in the organization is key to handling these incidents with speed and accuracy. This is why it's critical to have the ability to compare apples-to-apples when it comes to the all-important troubleshooting process.


What is our job as IT professionals?

Simply put, our job is to deliver services to end-users. It doesn't matter if those end-users are employees, customers, local, remote, or some combination of these. This may encompass things as simple as making sure a network link is running without errors, a server is online and responding, a website is handling requests, or a database is processing transactions. Of course, for most of us, it's not a single thing, it's a combination of them. And considering the fact that 95 percent of organizations report having migrated critical applications and IT infrastructure to the cloud over the past year, according to the SolarWinds IT Trends Report 2017, visibility into our infrastructure is getting increasingly murky.


So, why does this matter? Isn't it the responsibility of each application owner to make sure their portion of the environment is healthy? Yes and no. Ultimately, everyone is responsible for making sure that the services necessary for organizational success are met. Getting mean time to resolution (MTTR) down requires cooperation, not hostility. Blaming any one individual or team will invariably lead to a room full of people pointing fingers. This is counterproductive and must be avoided. There is a better way: prevention via comprehensive IT monitoring.


Solution silos

Monitoring solutions come in all shapes and sizes. Furthermore, they come with all manner of targets. We can use solutions specific to vendors or specific to infrastructure layers. A storage administrator may use one solution while a virtualization and server administrator may use another and the team handling website performance a third solution. And, of course, none of these tools may be applicable to the database administrators.

At best, monitoring infrastructure with disparate systems can be confusing, at worst, it can be downright dangerous. Consider the simple example of a network monitoring solution seeing traffic moving to a server at 50 megs/second, but the server monitoring solution sees incoming traffic at 400 megs/second. Which one is right? Maybe both of them, depending on if they mean 50 MBps and 400 Mbps. This is just the start of the confusion. What happens if your virtualization monitoring tool reports in Kb/sec and your storage solution reports in MB/sec? Also, when talking about kilos, does it mean 1,000 or 1,024?


You can see how the complexity of analyzing disparate metrics can very quickly grow out of hand. In the age of hybrid IT, this gets even more complex since cloud monitoring is inherently different than monitoring on-premises resources. You shouldn't have to massage the monitoring data you receive when troubleshooting a problem. That only serves to lengthen MTTR.


Data normalization

In the past, I've worked in environments with multiple monitoring solutions in place. During multi-team troubleshooting sessions, we've had to handle the above calculations on the fly. Was it successful?  Yes, we were able to get the issue remedied. Was it as quick as it should have been? No, because we were moving data into spreadsheets, trying to align timestamps, and calculating differences in scale (MB, Mb, KB, Kb, etc.). This is what I mean by data normalization: making sure everyone is on the same page with regard to time and scale.


Single pane of glass

Having everything you need in one place with the timestamps lined up and everything reporting with the same scale — a single pane of glass through which you see your entire environment — is critical to effective troubleshooting. Remember, our job is to provide services to our end-users and resolve issues as quickly as possible. If we spend the first half of our troubleshooting time trying to line up data, are we really addressing the problem?


About the Post

This is a cross-post from my personal blog @ [Link].

Filter Blog

By date: By tag:

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.