My Technology Career Change

As many of you know, I work for a large Cisco partner as a Solutions Architect (pre-sales engineer) focusing on Cisco Unified Communications and Collaboration.  It’s a technology that I have worked in for 18 years and my knowledge and skills there have served me well.  What only a few of you know is that when I started this job, I made a promise to myself that if I left this company it would not be to move to another role that focused on unified communications.  By making this promise I was trying to ensure that I would stay in that job for longer than my previous four or five jobs (averaging about a year each) and also to ensure that if I did leave it wouldn’t just be taking a job that was the same thing with slightly different scenery.  If I was going to move it would be the opportunity to learn something new.  Due to my experience and certifications and the compensation that has come along with them, I felt that I probably wouldn’t be making a move any time soon.  It’s been three years now and today is my last day at my current job.

I have accepted a job with ServiceNow as a Solutions Consultant and while it is still a pre-sales engineering role.  The technology is a major change from what I have been doing.  If you’ve not quite sure what ServiceNow does, go check out their web site, I’ll wait right here for you….Now that you’re back, you’ll probably agree with me on a few things:

  • There are a lot of things these folks are doing
  • This is definitely not a Unified Communications focused position
  • This isn’t even a Cisco focused position

As I was going through the interview process, several close friends were curious about how this would pan out.  Based on some of these discussions I came to the decision to document this transition because I’m sure that there are some people in the industry that feel they have been supporting a specific technology too long but also feel that they are too embedded to make a change.  Welcome to My Technology Career Change blog series.  Over the next several months I’ll cover what my experience in transitioning to a new technology and new job type will be!


Why the Change?

For some of my readers, this may seem like a foreign concept.  Taking a job that moves you our of the technology spot that you’ve been in for almost two decades may seem insane or at the very least, ill thought out.  What I can tell you is that this decision was not made lightly.  For over a year I had been trying to determine what my next role would be and how to get there.  I studied AWS certification material, I talked to friends about potential jobs that were at their companies, I interrogated people that worked in the collaboration and UC space.

What all of the researched reaffirmed in my brain was that it was time to leave.  After 18 years, I needed a change.  It’s not that there is anything wrong with the technology that I’ve been working with for so long, but where I used to get excited talking about the new things going on with it, I lost some of that passion.  Additionally, I wanted to increase my scope of knowledge outside of that sphere, so I am a little more well-rounded.  I’m excited to see what the next phase of my career evolves to and what new knowledge I can acquire as part of this move!


The Inevitable Questions

I’ve already had several questions asked to me repeatedly.  As the first post in this series, I’ll address them quickly, but as I continue on if something warrants more discussion I might have another post dedicated to the topic.

So You’re Completely Ditching Cisco?

I wouldn’t say completely.  I’ve still got a couple of blog series that I plan on writing around the Cisco arena that will keep at least a toe in that space.  Add to that some external projects that we will talk about in a moment and yes I’ll still have an ear in that direction for news even if it won’t be my complete focus.  Additionally, several aspects of ServiceNow have touch points in the Cisco sphere, so maintaining knowledge in that area will be helpful in my mind.

What About Engineering Deathmatch?

The bulk of the episodes of Engineering Deathmatch that I have filmed have been focused on Cisco, so I can understand where there might be some concern that the show would be going away.  I have told my new employer about the show and they are good with me continuing it.  I’ll continue to work with Cisco as long as they would like to work with me on episodes, but I also intend to expand the show to cover other technology companies as well.  Additionally the show family will be expanding with the addition of The IT Inquisition, so I’m actually excited to see the future of both of these shows!

Are You Going to Maintain Your CCIE?

Now this is a question that I have been thinking hard and long on.  The short answer is that I won’t let it expire, but the longer answer is I don’t know what I am going to do.  This past February was my 10-year anniversary so I have the option to go CCIE Emeritus.  For those not well-versed in CCIE lore, engineers who have been a CCIE for 10 years or more may opt to go CCIE Emeritus.  By doing this they no longer have to take re-certification exams, they can say that they are a CCIE Emeritus, however their certifications cannot be used by a partner to fulfill partner certification requirements.  As an Emeritus CCIE, if you decide that you want to get back to a full-fledged CCIE status you can take the CCIE written exam or complete continuing education requirements.  I still have over a year to make this decision but I will either be choosing the Emeritus route or taking the continuing education credits, which direction will largely depend on how much time I have available to do things like go through the training courses for continuing education.


Surely It’s Not All Roses

The pessimists among you may be saying that I’m going to run into all sorts of challenges.  I fully expect there to be some challenges and maybe even a thing or two that I don’t like about my new employer.  Every employer has issues in one way or another and I would be naive to think otherwise.  I can’t say that I know what these will be but I’ll deal with them as I encounter them.

That being said, I do see my biggest challenge with starting a new job like this is the rapid ramp-up on a new product and technology that I didn’t really have experience in before.  I’ll use all of my study magic that I have used both for studying for the CCIE as well as trying to stay on top of new products.  This will help me to not only quickly learn things, but to retain deep knowledge for the long term.  I’m excited about what’s to come!

Cisco’s Bold Move for Team Collaboration and Cutlery

Wow, I would not have expected this one in a million years, but it kind of makes sense.  Cisco announced today that they would be changing the name of their popular team collaboration application Cisco Spark to Cisco Spork.  When asked for comment, a high-ranking member of Cisco’s marketing team responded saying, “A lot of people love the Cisco Spark platform and a lot of people love multi-function cutlery, so it really just made sense to merge the two together.”

When I had the chance to talk some of the internal folks, a lot of details were unclear, but it was speculated that the name change would be announced at DevNet Create later this month.  Several theories floated around, but my favorite involved pay-subscription users getting a free spork for every paid Cisco Spork named user account.  I have to say that this was quite a shock, but now when I’m eating out of that can of beef stew while on a camp out I know that I will always think about the multi-funtion collaboration app that is now called Cisco Spork.  For up to date information on this unbelievable development, make sure to check the date on this post and wish yourself a happy April Fools Day.

Get Excited About Traceroute!

Let’s be honest, when you’re talking about networking tools, while it’s useful traceroute is nowhere near the most exciting. So as you can imagine, when SolarWinds mentioned at Tech Field Day 16 that they had released a new traceroute tool called Traceroute NG, I wasn’t exactly jumping for joy. It’s traceroute after all, what exactly are you going to do to it to add value? Despite my reservations, I went ahead and downloaded the tool to play around with it a little bit. So what’s it do that’s different? Read on and let’s see.

What’s New?
If you just run the application without any arguments, TraceRoute will give you the list of options in the image below:

As you can see, you can simply enter an IP address and do what you might think is a standard traceroute (more on that later) but you also have options to notify you if the path happens to change when you are running the traceroute. Something to note is that by default, when you run this it continuously gathers route data and updates as the data changes. You do have the option to change that, but as you will see later, it is kinda handy to leave it running just because of the additional data that can be gathered as a result.

Speedy McGee
Compared to a traditional traceroute tool that’s part of your computer or network OS, Traceroute NG is super fast. Within a couple of seconds I had data back on the full path to my destination address. And as mentioned before, it continued to update data. So while you may just have a path to start, it will update with average response times, packet loss and more. The speed and interface for Traceroute NG are really what stood out to me when I initially ran it.

As you can see in the image above, the application highlights packet loss red so you can see that there might be an issue going on. This interface stays on screen and dynamically updates RTT, packet loss, and path changes until you tell it to quit.

Why Now?
Ok, so there are a couple of cool features here that, if you use traceroute regularly, will make your life easier. But you may be asking yourself, why release this free tool? And why now? Well the why now I can’t necessarily answer my friends, but the why release it is pretty easy.
Traceroute NG is a pretty neat tool to give you some additional ad hoc capabilities for troubleshooting your network, but it’s not going to be the end all, be all of network management. If you want to do some truly dynamic and helpful stuff monitoring your network then you may want to look into NPM. If you were using it to take a look at the path and latency to your web site like I was doing in the example above then Traceroute NG might be a good place to start but if you really want to get into the user experience side of things then you might want to look into using SolarWinds’s cloud solution Pingdom so you can test latency from various locations all over the world and track the actual web site load time. Maybe the traceroute looks good and you still have performance issues, while Traceroute NG won’t find back end performance data, the SolarWinds AppOptics platform can help you out there.

All that to say that Traceroute NG is a very useful tool that is also a gateway drug to a much wider portfolio of products from SolarWinds. I don’t think anyone downloading this tool has deluded themselves that that is not the case and I don’t think it’s a problem. Use the beneficial tool, and if you have need for these other features, look at the more robust and paid for features.

What’s in a Name?
The Traceroute NG tool is pretty useful and cool, especially for something available at no cost. My only complaint, if we can call it that, is the name. I would guess that the ‘NG’ in Traceroute NG stands for next generation. I’ve always had a problem with products calling themselves next gen simply because what happens when the generation of product after the next gen comes out? Do you call them the next next gen? Since that’s probably not a realistic resolution, I will propose that we call the product Traceroute NG, where NG represents the elemental symbol for nougat (atomic weight: yum).

Wrapping Up
Short post this time, but I’m ready to wrap it up. SolarWinds has been one of those companies that knows a tried and true way of luring in new customers. By providing free software, they get customers used to the SolarWinds name and interfaces so when it comes time to look into network monitoring or application performance the customer has a good idea of where to start looking. That being said, the tool has to be useful and if you’re a heavy user of traceroute in your environment then Traceroute NG may be what you need to amp up that part of your troubleshooting.



Disclosure Time

I occasionally attend various Tech Field Day events organized by Gestalt IT. These events are sponsored by networking vendors who thus indirectly cover our travel costs. In addition to a presentation (or more), vendors may give us parting gifts ranging from their own products, to usb keys and various swag.

The vendors sponsoring Tech Field Day events don’t ask for, nor are they promised any kind of consideration in the writing of blog posts, and as always, all opinions expressed here are entirely my own and not those of sponsoring vendors, my employer and/or its affiliates, and all the mistakes are my fault (but please do feel free to point them out, I gladly correct factual errors).

Security by Behavior

We’ve all had something like this happen at some point.  The phone rings and you answer it.

“Hello John, this is Judy from the bank.  We’ve noticed some unusual activity on your account.  It appears that there was a $1,500 charge to Clowns R Us for a twenty foot tall velvet clown painting.  Is this a legitimate purchase?”

“Yes Judy, yes it is.”

After you hang up, you might be upset that Judy is judging you.  Sure, you don’t have a wall to fit a 20’ tall velvet clown painting, but who is she to judge?  If you take a step back though, you’ll realize that this is pretty cool.  The bank is evaluating your purchasing behavior and found this outlier that doesn’t fit with their baseline, so they check it with you before processing.  A recent call like this got me thinking about how behavior analytics can apply to the IT world to make us all a little more secure.

I was talking to a couple of friends that focus on the security world and I asked them about what they think of using behavior as part of a security posture.  I got overwhelmingly positive responses about it.  One went as far as saying, “Many breaches could have been prevented by tracking bad or abnormal behavior.  Others could have been dealt with quickly if behaviors outside the norm were flagged.”

That sounds great from an organizational perspective.  If your security group could see what normal behavior is and then block or flag what is outside those norms, you could do a lot to block the effects of trojans, hackers, end user ignorance, malicious end users and other nastiness that might penetrate your company.

I was lucky enough to be invited to Tech Field Day 16 in Austin, Texas and one of the presenters that week was Forcepoint.  Their User and Entity Behavior Analytics (UEBA) platform provides just those capabilities to establish a user behavior baseline and then compare current activity against it.

To start with, UEBA is not designed to stop people from getting into your network.  That’s what your firewall and other devices are supposed to work on.  UEBA helps prevent and identify insider threats.  An insider threat could be anything from a user accidentally mis-typing e-mail address and sending confidential data outside the organization to malware making actions on the user’s behalf to a user maliciously stealing data and everywhere in between.  Often things like firewall policies disregard traffic from the inside of the network out, but UEBA can work with other security components to assign a risk level to a user and determine whether they should be able to perform that action based on their score.  Jim from accounting has been involved in some risky behavior on the network lately?  Maybe he shouldn’t have access to download the full comp plan for your sales force and upload it to an external file storage site.

All of this user behavior information is gathered from a lot of sources.  If you’re using Forcepoint’s other security products they can send data about user activity to the UEBA.  But it doesn’t have to be from there.  UEBA can ingest data from a lot of different third party sources for instance, Active Directory, physical security card readers, and more.

The place that you can grab massively deep user behavior information is the Insider Threat product.  It’s basically like an agent that runs on a user’s computer that has deep access into anything that goes on there.  Registry changes, files being put on any drive, data being uploaded, basically it sounds like if something happens on your computer it can get deep data on it to determine user behavior.  That’s a ton of information and when I first heard about it, I was a bit concerned.  Here’s why:


The challenge with something that collects so much information on your users is what that does to their privacy and who in your organization has access to your personally identifiable data.  After all, when I’m bidding on a new velvet painting of Pennywise on eBay, I don’t want that jerk Dan in IT that has access to all my behavioral data to see that and go outbid me.  I know I’m joking here, but there are a lot of instances where you wouldn’t want just anyone to have access to the data that a user generates.  It could be something to deal with HR or even communications regarding an upcoming merger, or maybe someone for some reason is communicating with their doctor over corporate e-mail (yeah, I know, but users will be crazy).  The point is that there is just some information that the people that manage the system (IT) should probably never see.  This was really bothering me, so I placed a call to Forcepoint and put the question to them.  They were super helpful in giving me this information.

Forcepoint has two concepts called entitlement and application roles that address privacy concerns when it comes to user behavior data.  Entitlements can define whether a user can see types of data pertaining to specific users.  So for instance, if we don’t want Dan in IT to be able to see the e-mails of the CEO, that can be restricted.  The application roles can allow you to define whether individual users see anonymized data (where names are replaced pseudonyms) and whether data is masked or completely hidden.  The data is masked in more than just the source and destination, the content is searched and anonymized as well.  On the back end, UEBA is still tracking the original behavior data, so if the CIO needs detailed information on a user that Dan can’t see, then he can be given that access.

The Honeypot

My other concern with technology like this is that if you’re gathering thirty or sixty days of deep user behavior data on your users, that creates a huge vault of data that someone might be interested in.  How is this secured?  UEBA uses a variety of open source datastores for the storage of their behavior vault (that’s my term, not theirs) like Elastic Search.  All the data is encrypted while in the vault helping you rest a little more easily that someone isn’t going to break in a steal all that behavior data.  From an organization perspective, you still want to align the rest of your security policies to help protect that data, encryption is just one portion in a line of protections.

Wrapping Up

I have to admit, when I first saw the presentation on Forcepoint UEBA I was definitely impressed, but had an equal sense of Orwellian paranoia.  Admittedly, while there’s still a touch of that paranoia, it’s eased somewhat by the lengths that Forcepoint has taken to protect user privacy where it makes sense, while still being able to add a layer of security that most organizations don’t currently have.  If used correctly, UEBA can be a valuable part of and organiation’s security posture, just keep away from my velvet clown paintings.


Disclaimer Time

I occasionally attend various Tech Field Day events organized by Gestalt IT. These events are sponsored by networking vendors who thus indirectly cover our travel costs. In addition to a presentation (or more), vendors may give us parting gifts ranging from their own products, to usb keys and various swag.

The vendors sponsoring Tech Field Day events don’t ask for, nor are they promised any kind of consideration in the writing of blog posts, and as always, all opinions expressed here are entirely my own and not those of sponsoring vendors, my employer and/or its affiliates, and all the mistakes are my fault (but please do feel free to point them out, I gladly correct factual errors).

Why the Heck Would You Use NSX?

Back in 2012 there was quite the hubbub around VMware acquiring a company called Nicira.  At the time Nicira was known for software defined networking and a lot of people thought that this was a shot across the bow at traditional networking vendors.  As many of you probably already know, Nicira became VMware NSX, but I didn’t really ever see a heightened “war” of SDN involving the acuisition.

Despite all the talk at the time, I never really got a good idea of what the actual value to an organization and since then I haven’t heard a whole lot except the standard SDN arguments:  you can automate the configuration of your network (in this case your virtual network), you can reduce the number of network configuration issues you have when you deploy a new host, etc.  And, while I don’t work a lot with super-large organizations, many of the companies pretty much gave a collective “Big Whoop!”.  A lot of them looked at their VMware environment and while hosts got added and removed, the overall virtual network didn’t have a whole lot of change, and they therefore didn’t feel like there was a big need for them.  So if that wasn’t a compelling reason, why deploy NSX?

I had the honor of attending Networking Field Day 15 in sunny California.  VMware presented on NSX in what I believe was their first presentation at a Tech Field Day event.  I’m glad they did, because it gave me a view into something that I think may be compelling for some organizations: security.

Behold, the Power of Micro-Segmentation!

With NSX, users can deploy an enterprise firewall in their VMware environment that can configure policies down to the vNIC level.  What this means is that you can basically set a stateful firewall policy per VM.

“But I already have a firewall!” you might say and that’s great.  NSX does not remove the need for you to have a hardware firewall in your environment.  NSX micro-segmentation is additive and provides another layer to your layered security architecture.  If someone gets through your perimeter firewall or an internal firewall too, this can still potentially protect your virtual machines.  But in addition to that, if you have virtual machine to virtual machine “east-west” traffic on the same host, that traffic won’t hit your hardware firewall unless you force it to trombone out of the host and back in.

One of the things that I was worried about when VMware was talking about NSX micro-segmentation and firewalling was that a lot of people have trouble identifying what traffic to block on a perimeter firewall, how are they going to define what traffic should be allowed to a single vNIC?  VMware has a tool called Application Rule Manager (ARM) that allows an organization to analyze up to 30 virtual machines at a time to identify normal traffic and help you build a firewall policy based on those traffic patterns.  In my mind, this is super handy to spin up for a month, see what sort of traffic baseline you get and then lock down the VM moving forward.

What’s the Catch?

As you can tell, I like the concept of being able to deploy security policy so granularly in your virtual environment, but like me you may also want to know what the catch is.  So here are a couple of shortcomings or potential shortcomings that might be out there.

As I mentioned in the last section, NSX provides a stateful firewall and while I’m not a security wonk, my security friends have repeatedly told me that stateful firewalls can only do so much.  If some bad actor decides to determine what sort of traffic your policy is allowing to a VM they could potentially hide their traffic using trusted port numbers and encrypted traffic.  Depending on what the normal traffic to a virtual machine is what has been compromised in your environment, the difficulty of someone taking advantage of this will vary (because you can lock down traffic between IP addresses, etc, like any stateful firewall).

The second thing that I don’t have an answer for, so I don’t know if it is a concern or not is resources required for running micro-segmentation and the centralized edge services gateway (this firewalls north-south traffic).  In the presentation at Networking Field Day, VMware was asked about this and they basically said, “Don’t worry about it, it won’t be a problem” without actually getting at what the resource usage was.  Admittedly, the NSX firewall is running at the kernel level from the way I understand it, so it won’t fight for resources within a virtual machine, but the compute for the kernel still has to come from somewhere.  If traffic floods into the virtual firewall and starts taking up more and more resources what goes first, the VM compute or the compute that is being used by the kernel for the NSX firewall and at what point does it cause a traffic bottleneck?  I don’t know the answer, and maybe this isn’t even something to be concerned about, but since I don’t know it goes in this section.

Wrap it Up

Ok, so we’ve had our brief overview. What’s the verdict?  I think that for organizations that are looking to add another layer into their layered security architecture, NSX can offer value.  Even without deep packet inspection, by adding stateful firewalling that can lock down a virtual machine to communicate in pre-defined ways with pre-defined hosts you can add one more way to defend your virtual environment.  Additionally, by using the Application Rule Manager tool, administrators who don’t understand traffic patterns for certain virtual machines can get help with defining firewall policies.


Disclaimer Time

I occasionally attend various Tech Field Day events organized by Gestalt IT. These events are sponsored by networking vendors who thus indirectly cover our travel costs. In addition to a presentation (or more), vendors may give us parting gifts ranging from their own products, to usb keys and various swag.  Additionally, VMware provided a voucher for an NSX training class and test.  While I have not taken either yet, I have informed them I would be interested in the class.

The vendors sponsoring Tech Field Day events don’t ask for, nor are they promised any kind of consideration in the writing of blog posts, and as always, all opinions expressed here are entirely my own and not those of sponsoring vendors, my employer and/or its affiliates, and all the mistakes are my fault (but please do feel free to point them out, I gladly correct factual errors).