Report IT

Posted by kong.yang Feb 26, 2016

In this final post of this SOAR series, I conclude with reporting as the final high value-add skill needed for mastering the virtual environment. Reporting is all about supplying the intended audience with what they need to make an informed decision.


Reporting: The decision-maker’s ammo

Reporting molds data and logged events into a summary that highlights key facts to help the end-user make a quick, yet sound, decision. Reporting is neither glamorous nor adrenaline-pumping, like the experience you get while developing and honing the other skills, but it is the one skill that will help you get on the promotion fast track.


Reporting is better than slideware

IT reporting at its best is pure art backed by pure science and logic. It is storytelling with charts, figures, and infographics. The intended audience should be able to grasp key information quickly. In other words, keep it stupid simple. Those of you following this SOAR series and my 2016 IT resolutions know that I’ve been beating the “keep it stupid simple” theme pretty hard. This is because continuous decision-making across complex systems can lead to second-guessing by many IT chefs in the IT kitchen, and we don’t want that. Successful reporting takes the guesswork out of the equation by framing the problem and potential solution in a simple, easily consumable way.


The most important aspect of reporting is knowing your target audience and creating the report just for them. Next, define the decision that needs to be made. Make the report pivot on that focal point because a decision will be made based on your report. Finally, construct the reporting process in a way that will be consistent and repeatable.



Reporting is a necessary skill for IT professionals. It helps them provide decision-makers with evidence leveraged in the decision-making process. Reporting should be built upon the other DART and SOAR skills so that reports become a valuable asset instead of merely a check mark on someone’s to-do list. Reporting can empower IT pros to new career paths and to new IT frontiers.

Mrs. Y.

Can Security Be Agile?

Posted by Mrs. Y. Feb 25, 2016

Unless you’ve been living in a bomb shelter for the last five years, it’s impossible to avoid hearing about the struggle IT organizations have with supporting DevOps initiatives. Those of us on infrastructure or information security teams are already under pressure to implement and streamline processes to improve efficiency in the midst of budget cuts and downsizing. Now we’re being asked to accommodate the seemingly unrealistic schedules of Agile developers. It often feels as though we’re working with two-year olds in the midst of an epic “continuous deployment” temper tantrum. 


Those of us who have some tenure in IT remember the bad old days. Sleeping under cubicle desks while performing off-hours maintenance or trudging back to the office at 3:00 AM because someone made a change that took down the network. It was the Wild, Wild West and organizations started implementing change management procedures to keep the business happy.  But then a shift occurred. While we were busy trying to improve the way we manage change, many organizations became risk-averse. They have meetings about meetings and it seems as though their IT staff spends more time talking about work than actually doing any. The stage was set for a DevOps revolution.


Does Agile have value outside of a few eCommerce companies or is it simply confirmation bias for technology chaos? Only time will tell, but organizations hungry for innovation drool when they hear Etsy pushes 50 deploys per day. You heard that right, per DAY. While DevOps organizations seems to be moving at warp speed, others stumble trying to implement that many changes in a month. What’s the secret? How do companies like Facebook, Google and Amazon stay nimble while maintaining some semblance of order and security?


Don’t be fooled by snazzy lingo like “sprints” and “stories,” DevOps still relies on process. But the requirements of Agile development demand rapid change. The main question infrastructure teams ask is how to support this environment safely. And how do security teams manage risk and compliance without an army of analysts to keep up?


The only way to achieve DevOps speed while minimizing risk is through a two-pronged approach: automation and self-service. Standards are useful, but being able to instantly spin up a system, application or container based on those standards will better meet the needs of your developers. When you manually build servers and install applications, then ask security to assess them, you’ve wasted precious time with process “gates.” Approach everything as code, something to be modularized then automated. Google and Facebook don’t perform manual code reviews, they use frameworks with pre-approved libraries built on standards.  This eliminates the need for frequent manual code reviews.


Moreover, implementation times are shorter when teams can fend for themselves. It’s critical to deploy tools that allow developers to be self-sufficient. Start to think like a programmer, because, as Marc Andreessen pointed out, “Software is eating the world.” Most hypervisors have excellent orchestration capabilities and every self-respecting public cloud has various APIs that will allow you to implement your own deployment scripts or integrate with existing help desk applications.  By spending time up-front to develop automated processes and creating self-service front-ends, you can actually maintain control over what your developers are able to do, while keeping them working.


Embracing DevOps doesn’t have to mean kicking security controls to the curb. But it will require security staff with skillsets closer to that of a developer, those who can think beyond a checkbox and provide solutions, not roadblocks.

Stop And Smell The Documentation

A recent issue with a network reminded me of the importance of documentation. I was helping a friend find out why destinations in the core of the network were unable to ping other locations. We took the time to solve some routing neighbor issues but couldn't figure out why none of the core could get out to the Internet. We were both confused and working through any issues in the network. After a bit more troubleshooting with his team, it turned out to be a firewall issue. In the process of helping the network team, someone had added a rule to the firewall that blocked the core from getting out. A lot of brainpower was wasted because this engineer was trying to help.

We reinforce the idea that documentation is imperative. As-built documentation is delivered when a solution is put together. Operational docs are delivered when the solution is ready to be turned up. We have backup plans, disaster plans, upgrade procedures, migration guidelines, and even a plan to take equipment out of service when it reaches the end of life. But all of these plans, while important, are the result of an entire process. What isn't captured is the process itself. This becomes very important when you are troubleshooting a problem.

When I worked on a national helpdesk doing basic system support, we used the CAR method of documentation:

  • C - Cause: What do we think caused the problem? Often, this was one of the last things filled in because we didn't want to taint out troubleshooting method with wild guesses. Often I would put in "doesn't work" or "broken".
  • A - Actions: This was the bulk of the documentation. What did you do to try and fix the problem? I'll expand on this in a minute, but Actions was the most critical part of the documentation that almost never captured what was needed.
  • R - Resolution: Did you fix the problem? If not, why? How was the customer left? If you were part of a multiple call process, Resolution needed to reflect where you were in the process so the next support technician could pick up where you left off.

Cause and Resolution are easy and usually just one or two line entries. What broke and how did you fix it? Actions, on the other hand, was usually a spartan region of half sentences and jumbled thoughts. And this is where most of the troubleshooting problems occurred.

When you're trying to fix a problem, it's tempting to only write down the things that worked. Why record things that failed to fix the problem? If you try something and it doesn't affect the issue, just move on to the next attempt. However, in the real world, not recording the attempts to fix the problem are just as detrimental as the issue in the first place.

Writing In The Real World

Let's take the above example. We were concentrating on the network and all the issues there. No one thought to look at the firewall until we found out the issue was with outbound traffic. No one mentioned there was a new rule in the firewall that directly affected traffic flow. No one wrote down that they put the rule in the firewall just for this issue, which made is less apparent how long the rule had been there.

Best practice says to document your network. Common practice says to write down as much as you can think of. But common sense practice is that you should write down everything you've done to during troubleshooting. If you swap a cable or change a port description it should be documented. If you tweak a little setting in the corner of the network or you delete a file it should be noted somewhere. Write down everything and decide what to keep later.

The reason for writing it all down is because troubleshooting is rarely a clean process. Fixing one problem will often uncover other issues. Without knowing the path we took to get from problem to solution, we can't know which of these issues were introduced by our own meddling and which issues were already there. Without an audit trail we could end up chasing our own tails for hours not knowing that the little setting we tweaked five minutes in caused the big issue three hours later.

It doesn't matter if you write down your steps on a tablet or jot them on the back of a receipt for lunch. What is crucial is that all that information makes it to a central location by the end of the process. You need great tools, like the ones from Solarwinds, to help you make sense of all these changes and correlate them into solutions to problems. And for those of us, like me, that often forget to write down every little step, Solarwinds makes log capture programs that can let the device report every command that was entered. It's another way to make sure someone is writing it all down.

How do you document? What are you favorite methods? Have you ever caused a problem in the process of fixing another one? Let me know in the comments!

Stay in the IT game long enough and you’ll see the cyclic nature that exists as well as the patterns that form as tech trends go from hype to in-production. I remember working with virtualization technologies when you had to do things via the command line interface (CLI), such as configuring to your ESX host servers to connect with your fibre channel SAN. It was tedious and prone to human errors, so vendors simplified the experience with slick GUIs and one-touch clicks. Well, things have come full circle as the CLI is all the rage to gain scale and run lean via automation and orchestration scripts. With that in mind, here are a few things that virtualization admins need to remember.


First, let’s start with pattern recognition as in IT silos will always be targeted for destruction, even virtual ones. Just as virtualization broke down IT silos across networking, storage, application and systems, new technology constructs are doing the same to virtual silos. In this case, the virtualization silos are embodied by vendor-locked in solutions and technologies. Don’t be that IT guy who gets defensive about virtualization without seeking to understand the pros and cons of cloud services and container technologies.


Second, virtualization is an enabler of the application in terms of availability and data center mobility. Well guess what - containers, clouds, and microservices enable high availability and mobility beyond your on-premises data center at web-scale. So enable high availability and mobility in your career by learning and using these tech constructs.


Finally, let’s bring this conversation full circle – lean on your expertise and experience. If you know virtualization, you understand the underlying physical subsystems and their abstracted relationships to the application. Put that trust in yourself and embrace the new era of continuous service delivery and continuous service integration. It’s just an abstraction using a different model.

Automate IT

Posted by kong.yang Feb 19, 2016

Last week, I covered optimization as a skill to keep your IT environment in tip-top shape by constantly delivering the most optimal Quality-of-Service (QoS). This week, I’ll walk through automation as another high value-add skill for the virtual environment. Automation is one part best practice, one part policy, and one part execution.


Automation: the only way to scale IT’s most valuable resource – you the IT professional

Automation is a skill that requires detailed knowledge including comprehensive experience around a specific task such that the task can be fully encapsulated by a workflow script, template or blueprint. Automation, much like optimization, focuses on understanding the interactions of the IT ecosystem, the behavior of the application stack, and the inter-dependencies of systems in order to deliver economies of scale benefit and efficiency towards the overall business objectives. And it embraces the “do more with less” edict that IT professionals have to abide by.


Automate away

Automation is the culmination of a series of brain dumps covering the steps that an IT professional takes to complete a single task, one that the IT pro is expected to complete multiple times with regularity and consistency. The singularity of regularity is common thread in deciding to automate an IT process. The chart below entitled “Geeks and repetitive tasks” provides good perspective on an IT professional’s decision to automate.


[2016 from Hosted on ]


Automate the IT way: scripts, templates and blueprints

IT automation usually is embodied by scripts, templates and blueprints. These scripts, templates and blueprints are built upon an IT professional’s practice and methods. Ideally, it’s based upon best practices and tried and true IT methods. Unfortunately, automation cannot differentiate between good and bad practices. Therefore, automating bad IT practices will lead to unbelievable pain at scale across your data centers.


With this in mind, keep automation stupid simple. First, automate at a controlled scale and follows the mantra doing no harm to your production data center environment. Next, monitor the automation process to make sure that every step executes as expected. Finally, analyze the results to make necessary adjustments to the automation process.



Automation is the skill that allows an IT professional to scale beyond what they could do singularly. It is also a skill that builds upon the DART and Optimization skills. It seeks to maximize the IT professional’s time by freeing up more time to do other tasks. And next week, I’ll talk about Reporting, the last of the SOAR skills that virtualization admins need to SOAR their professional careers.

In the previous post we discussed on ways to get started down the Infra-As-Code journey. However, one thing that was pointed out from others was that I missed the backup process of devices. So I wanted to go ahead and address that here in the beginning of this post to get that area covered. And I very much appreciate those who brought that to my attention.


So how do you currently cover backups on network devices? Do you not back them up? Do you back them up to a TFTP/FTP server? Well in order to accomplish backup tasks for Infra-As-Code we need to do our backups a little differently. We need to ensure that our backups are created as the same filename on our destination on every backup occurrence. So you are thinking to yourself this seems rather un-useful correct? Well actually it is very useful and this is what we want. And the reason behind this is that we want to store our backups in our version control system and in order to benefit from this the backup filename needs to be the same every time that it is committed to our version control system. Doing so allows for us to see a configuration diff between backups. Meaning that if any configuration change occurs our version control system will show the diff of the previous backup and the current backup allowing for us to track exact changes over time. This allows for easy identification of any changes that may have possibly caused an issue or maybe even identify an unauthorized change that was not properly implemented using our change methodologies that hopefully are in place. One last thing in regards to backups is that we do indeed need to ensure that our backup strategy is followed as part of our previous post in the implementation phase at the very least. Ensuring that our backups are running and validated prior to the actual implementation of a change. Now with this section on backups being covered let’s continue on where this post was meant to be and that is what is required for Infra-As-Code.


What do I mean by what is required for Infra-As-Code? I mean what tools are required to be in place to get us started on this new journey. I will only be covering a very small subset of tools that will allow us to get started as there are way too many to cover. And the tools that I will be mentioning here are the same ones that I use so I may be a bit partial but in no-way are they to be considered the best.


Let’s start with a version control system first because we need a repository to store all of our configurations, variables and automation tooling. Now I am sure you have heard of GitHub as a git repository for users to share their code and/or contribute to other user’s repositories. Well we are not going to be using GitHub as this is a public repository and we want a repository on-site. You could however use GitHub as a private repository if you so choose to but be very careful on what you are committing and ensuring that the repository is private. There are others such as BitBucket that allow the creation of free private repositories whereas GitHub is a pay for private repositories. So what do I use for an on-site git repository for version control? I use GitLab-CE (GitLab Community Edition) which is a free and open-source git repository system which has a very good WebUI and other nice features. GitLab also offers a paid for enterprise version which adds additional functionalities such as HA. Having a good version control system is absolutely crucial because it will allow us to create git branches within our repos to designate which are Master (Golden) and maybe some others such as a staging, test, dev and etc. Having these different branches is what will allow us to do different levels of automation testing as we work through our workflows of changes.


Let’s now touch on code-review. Remember our code-review is the system that will allow sign-off on code/configuration changes to be applied on our network devices. Code-review also enforces accountability for changes. The ideal recommended method is that whomever signs-off on code changes has a complete understanding of the underlying network devices as well as what the configuration/code changes are. Taking this method ensures that everyone is in the know on what is actually changing and can take the proper measures prior to a production change which brings down your entire network. And luckily if that was to happen you did have a proper backup of each configuration right? So what do I use for code-review? I use Gerrit which is developed by Google. Gerrit is a very well-known and used code-review system throughout the developer ecosystem. One thing to note on Gerrit is that it can ALSO be used as a git repository in addition to code-review. This works well for those who want only one single system for their git repositories and code-review. The integration is very tight but the WebUI is not so pretty to say the least. So when deciding on whether to use a single system or to use Gerrit for only code-review and GitLab for git repositories is a matter of choice. If you do choose to not use a single system, it takes additional steps in your methodologies.


Now we will touch on automation tooling. There are MANY different automation tools to leverage and each one is more of a personal preference and/or cost. Some of the different automation tools include Chef, Puppet, Salt, Ansible and many others. My preferred automation tool is Ansible. Why Ansible? I spent a good bit of time with many of the others and when I finally discovered Ansible I was sold on it’s relatively easy learning curve and power. Ansible relies on Python which is a very rich and powerful programming language and is also easy to learn. Using Ansible you can program network devices via an API (if it exists), raw commands (via SSH), SNMPv3 and other methods. There are other tools that leverage Ansible such as NAPALM as well. I highly recommend checking out NAPALM. so definitely checkout the different automation tools and find the one that works the best for you.


And for the final tool to discuss in this post covers our CI/CD (Continuous Integration/Continuous Delivery) automation of workflows and changes. There again are so many different tools to choose from. Some of these tools include Go-CD, Rundeck, Travis-CI, Bamboo, Jenkins and many many more. My tool of choice is Jenkins for the most part but also leverage several of the others listed above for one-off type deployments. Jenkins is a widely adopted CI platform with a massive number of plugins developed for tying other tooling into your workflows, such as Ansible playbooks and ad-hoc Ansible tasks. Jenkins allows for us to stitch together our complete workflow from top to bottom if desired. Meaning we could leverage Jenkins to kick off a backup, pull a specific branch from our git repository with configuration changes, run an Ansible playbook against a set of network devices, report back on the status and continue throughout our workflow pipelines. Jenkins is the tool that takes many manual processes and automates those tasks for us. So think of Jenkins as the brains to our Infra-As-Code.


Now I know this is a lot to learn and digest on many new tools and methodologies but hopefully I can help you with getting your head around these tools. And with that I have created a Vagrant lab that you can spin up and begin learning each of these tools. I will be leveraging this lab going forward with the additional follow-up posts in the next few weeks. But I wanted to share this here now so you can also start getting your head around these tools. So if you head over to here you can begin your journey too.


And with that this ends this post and up next we will discuss some examples of our new methodologies.

If you’re in management, you may not understand the effects of changes on your network.  However, if you’re the network engineer you know exactly the effects and ramifications that come with a change on your network.  The slightest change can literally cause an outage.


So what’s the big deal with software companies that want you to buy Network Configuration Change Management (NCCM) software?  Well I know personally that a few of you have been in this exact position and on both sides of this ball.  As a manager you want to have a seamless network and keep down costs.  As the network engineer you want to be able to have a smooth running network and a happy manager.


What is the happy medium here?  When are too many software tools or too many diagrams on walls and an over-abundance of saved test files enough to know software is required to actually manage all of this?


SolarWinds offers a Network Configuration-Change Management package. Does this mean it’s the best?  No, as that is in the eye of the beholder and user. Does this mean that it is manageable and can save me time and my manager money?  You’re darn rightit can do both very easily!


Yes, there are other software tools that do all about the same thing with little differences along the way.  Just like I like thin pancakes and you may like fluffy thick pancakesin the end they are still pancakes.


Now to know what a good NCCM is regardless of the name across it, let’s go over the top 6 reasons to have such software.


  1. Making changes because you were told to…
    1. You want to be able to know if someone is in fact making changes immediately and have a way to revert changes if needed.  NCCM software allows you to do this and consistently backs up your devices in case such changes are incorrect and provides a complete barebones backup if needed for a new device.
  2. Scheduled device changes
    1. Planning IOS upgrades, change in ACL lists, SNMP passwords, or many other items on your daily tasks.  Having a program that will allow you to monitor and roll out these changes saves time and show results quickly.
  3. A second pair of eyes
    1. It’s good to have an approval system in place so that scripting and changes receive a second look before deployment.  This helps prevent outages and mistakes, and definitely is valuable when your network has service level agreements and high availability needs.
    1. I cannot say this enough…if you do not have regular backups of your system that are easily retrievable, you do not have a fully reliable network.  PERIOD. Backing up to your local machine is not acceptable…You know who you are
  5. Automation of the tasks you might rather forget...
    1. Being able to detect issues within your configuration through compliance reporting, real-time change detection, scheduled IOS upgrades, inventory, and many more automated tasks. This allows you to focus on the integrity and availability of your network.
  6. Security
    1. If you have certain required security measures within your configurations, then you need compliance reporting.  With NCCM software, you can schedule a report or run it manually and print out that your ‘state of compliance’ within seconds instead of per device.


Well there are a few valuable reasons to at least consider this type of software.  If you have any other thoughts, feel free to drop me a line! Add to my list or take away, I’m a pretty open mined individual.


If you’re looking for more information this has a solid outlook on NCCM and businesses.

Not to be outdone in the race for federal network modernization, the United States Army last year issued the Army Network Campaign Plan (ANCP). Created by Lt. Gen. Robert Ferrell, the Army’s outgoing director, the ANCP “outlines current efforts that posture the Army for success in a cloud-based world” and provides “the vision and direction that set conditions for and lay a path to Network 2020 and beyond.”


These broad and bold statements encompass several things. First, there’s the Army’s desire to create a network that aligns with DISA’s Joint Information Environment (JIE) and the Defense Department’s modernization goals, which include better insight into what’s happening within its networks and tighter security postures. Second, there’s the pressing need to vastly improve the services the Army is able to deliver to personnel, including, as outlined in the ANCP, everything from “lighter, more mobile command posts to austere environments that will securely connect the network and access information.”


How unifying operations and security fits into the ANCP


The need for greater agility outlined in the ANCP dictates that operations and security teams become more integrated and unified. The responsibilities of one can have a great impact on the other. Working together, cybersecurity and operations teams can share common intelligence that can help them more quickly respond to threats and other network problems.


Similarly, the solutions that managers use to monitor the health and security of their networks should offer a combination of features that address the needs of this combined team. As such, many of today’s network monitoring tools not only report on the overall performance of the network, but also provide indications of potential security threats and remediation options.


Why letting go of the past is critical to the success of the ANCP

Combing operations and security teams is a new concept for many organizations and it requires letting go of past methodologies. The same mindset that contributes to that effort should also be applied to the types of solutions the Army uses moving forward, because the ANCP will not be successful if there is a continued dependence on legacy IT solutions.


It used to be fine for defense agencies to throw their lots in with one software behemoth controlling large segments of their entire IT infrastructure, but those days of expensive, proprietary solutions are over. Army IT professionals are no longer beholden to the technologies that may have served them very well for the past few decades, because the commercial market for IT management tools  now has lightweight, affordable, and easy-to-deploy solutions. The willingness to let go of the past is the evolution of federal IT, and is at the heart of all modernization efforts.


The fact that Ferrell and his team developed a plan as overarching as the ANCP indicates they are not among this group of IT leaders. In fact, the plan itself shows vision and a great desire to help the Army “be all it can be.” Now, the organization just needs to fully embrace new methodologies and technologies to reach that goal.


To read the extended article on Defense Systems

A week ago Leon Adato shared a fine post titled What “Old” Network Engineers Need To Remember.  I enjoyed reading his post and agreed with every point.  And so I thought I’d make my own list this week and share my thoughts on how “Not” to be a bad network security engineer.

So let’s get right two it shall we?

  1. Don’t assume bad motives.  Too often we assume that users are doing something they shouldn’t be and when we get the call that their computer has malware or we find something funny in the logs we treat them pretty bad.  Sure, some people are jerks and try to get around the rules.  But most people just want to get work done with as little friction as possible.
  2. Don’t assume that everyone knows the latest malware or ransomware delivery methods.  I have a friend that works for an autoparts distributor.  He deals with shipments all the time.  One of the emails he received was a failed shipping notification.  He opened it and boom!  Cryptolocker.  It encrypted everything on the shared drives he was connected to and left the business limping along for a few hours while they restored the previous nights backups.  He had no idea.  Malware  and Ransomware isnt in his job description.
  3. Educate your users in a way that isn’t demeaning to them.  I know the old “Nick Burns” videos are humorous.  But again, if you take the time to train your users and your not a jerk about it, they’re more apt to respond in a positive manner.
  4. Now for the technical stuff.  If you’re using a ton of ACL statements to control traffic, please add remarks.  By adding remarks to your ACL statementns those who come after you will think you’re a pretty nice guy.  I’ve inherited ACLs with thousands of lines and no clue what any of the entries were for.  Not cool!
  5. Use Event Logging and Correlation to your benefit.  Too many network security professionals try to get by without a solid logging and correlation strategy.  So instead of having all the info, they tend to tread water trying to keep up with what’s going on in the network.  There are a number of SIEM solutions today that offer event correlation and really good filtering on the logs.  If you don’t have one, build a case for one and present it to upper management.

It’s true that we’re in a very tough spot some times.  We manage systems that have a lot of power in terms of network connectivity.   It’s good for us to be transparent to users but at the same time we don’t want our users activity to be transparent to us.  It’s quite a balance we have to strike, but it’s worth it when we can.  And using some of the more advanced tools made available today can help give us the visibility we need.  Here’s a good example of how you can use Solarwinds LEM to create rules for real-time correlation and response..  This is just one example of how we can use today technology to provide security services while being somewhat transparent to users.  And as far as the five points mentioned above, these are but a few point I’ve learned over the years that have proven to be useful.  There are many more of course.  If you have one perhaps you’d share it below.  Iron sharpens iron after all!

Optimize IT

Posted by kong.yang Feb 12, 2016

Maximize your resources’ utility

In the previous week, I covered security as a skill to take your IT career to the next level. This week, I’ll walk through optimization as another high value add skill in the virtual environment. To truly appreciate the importance of optimization, you have to understand the blood, sweat and tears that one endures when gaining optimization wisdom.


Optimization: More than meets the I → T

Optimization is a skill that requires a clear end-goal in mind. Optimization focuses on understanding the interactions of the IT ecosystem, the behavior of the application stack, and the inter-dependencies of systems inside and outside their sphere of influence in order to deliver success in business objectives.


If one were to look at optimization from a theoretical perspective, each optimization exercise would be a mathematical equation with multi-variables. Think multivariate calculus as an IT pro tries to find the maximum performance as other variables change with respect to one another.


I’m positive that Professor sqlrockstar could lead us through a database optimization course leveraging multivariate calculus to analyze the deterministic SQL systems with N-degrees of freedom. Meanwhile, I could leverage my ECE background and lead a discussion on applied control systems theory and its application to optimize performance in your dynamic, virtual data centers. This begs the question: is calculus knowledge required to optimize your virtual environment? The answer is no. While it may help to formulate theories and visualize the overall concepts, IT is all about keeping IT stupid simple. That should be the IT ideal after all.


Optimizing for everything is really optimizing for nothing

Optimization is a skill forged from focus tuning to achieve a desired end-goal. As such, the one trap that all IT pros should avoid is trying to do too much. Optimizing for everything and everyone more often than not ends up in disappointment as the optimization efforts end up making the Quality-of-Service worse for everyone involved.


To avoid such pitfalls, have a simple optimization plan. Prioritize your most important deliverable as defined by all the stakeholders. Optimize with that deliverable as the focal point. Understand the behavior and relationship of change as it pertains to your optimization goal. And if additional optimization tasks are appended to the original task, communicate the risks clearly and concisely. And understand that sometimes, there is no convincing an IT executive looking to make their mark, even at the expense of their direct reports.



Optimization is a high reward skill that builds upon the DART skills framework. It seeks to maximize the utility of IT resources as it delivers the best in class Quality-of-Service to end users. Next week, I’ll discuss the Automation skill, another of the SOAR skills that virtualization admins need to take flight in their careers.

The day starts like any other. You’re finally starting to feel like you’ve got a handle on the security posture of your enterprise, because you’ve been able to add a reasonable amount of visibility into the infrastructure:

  • You have a Netflow collector reporting anomalies.
  • Taps or network packet brokers are installed at key ingress/egress points.
  • Vulnerability management systems are implemented to scan networks or devices and report regularly.
  • Firewalls, intrusion detection systems (IDS) and other malware detection mechanisms send log and alert data to a security information and event management system (SIEM) or a managed security service provider (MSSP).
  • A centralized log correlation system is deployed to meet the needs of security and assist operations with troubleshooting.


Then the unthinkable happens.


Your boss waltzes in to tell you, “We’re moving to the cloud. Isn’t that exciting?!” While management is already counting the money they think they’re going to save by eliminating on-premise systems and reducing head-count, all you feel is frustration and dread. How are you going to do this all over again, and in the cloud, without the organization going broke or your team having a nervous breakdown?


Remain calm and don’t surrender to nerd rage. While challenging, there are ways to use some of your existing tools and leverage similar ones built into software-as-a-service (SaaS) or infrastructure-as-a-service (IaaS) offerings in order to meet your security needs.


For example, you can still use network monitoring tools such as Netflow to track anomalies at key ingress/egress points between the enterprise and the Iaas or SaaS. To implement access restrictions, you could set up a dedicated virtual private network (VPN) tunnel between your physical network and the cloud environment, forcing your users through traditional, on-premise controls. Additionally, most cloud providers offer the ability to create access control lists (ACLs) and security zones. This provides another method of restricting access to resources. By leveraging VPN tunnels, ACLs and logging ingress/egress firewall rules from your network to the cloud service, you can create an audit trail that will prove useful during and post breach.


Other useful access control methods are the addition of multi-factor authentication (MFA) or single-sign-on (SSO) to your cloud service or infrastructure. We all know the problems with passwords, but this becomes even more frightening when you consider your services and data are in a multi-tenant environment. Many cloud providers support free or paid MFA integration. Moreover, you’ll want to leverage the provider’s SSO capabilities to ensure that you’re controlling, auditing and removing administrative access centrally. When choosing a cloud service, these requirements should be in your RFP in order to ensure that a provider’s offerings in this realm align with your security model and compliance initiatives.


If you already have security products you’re comfortable with, you generally don’t have to reinvent the wheel. Because of multi-tenancy, you won’t be able to install physical taps and IDS appliances, but you have other options in applying more traditional controls to IaaS and Saas.  Many companies offer versions of their products that work within cloud environments. Network firewalls, IDS, web application firewalls (WAF), logging systems, vulnerability scanners; a simple search in the Amazon Web Services (AWS) marketplace should alleviate your fears.


Finally, many providers have an administrative console with APIs and external logging capabilities. AWS’ Cloudtrail and Cloudwatch are just two examples.  With some effort, these can be integrated with either an on-premise or outsourced SIEM.


Migrating to the cloud can be intimidating, but it doesn’t have to be the end of security as you know it. Your team must be prepared to shift the way you apply controls. With some tweaks, some of them will still work, but others might need to be abandoned. The cloud seems to be here to stay, so security must adapt.

Technology moves fast in today's world. We go from zero to breakneck speed on a new concept before we can even catch a breath. New software enables new business models and those new models drive our understanding of people forward in ways we couldn't imagine before. I can catch a taxi with my phone, perform a DNA analysis from the comfort of my home, and collect all kinds of information about my world with a few clicks. Keeping up gets harder every day.

It's important to recognize new technology that has the potential to change the way IT professionals do their job. Years ago, virtualization changed the server landscape. The way that server administrators performed their duties was forever changed. Now instead of managing huge tracts of hardware, server admins had to focus on the fine details of managing software and resources. Making the software perform became the focus instead of worrying about the details of the server itself.

Today, we're poised to see the same transition in application software. We've spent years telling our IT departments how important it is to isolate workloads. Thanks to virtualization, we transitioned away from loading all of our applications onto huge fast servers and instead moved that software into discreet virtual machines designed to run one or two applications at most. It was a huge shift.

Yet we still find ourselves worried about the implications of running multiple virtual operating systems on top of a server. We've isolated things by creating a bunch of little copies of the kernel running an OS and running them in parallel. It solves many of our problems but creates a few more. Like resource contention and attack surfaces. What is needed is a way to reduce overhead even further.

Containment Facility

That's where containers come into play. Containers are a software construct that run on top of a Linux kernel. They allow us to create isolated instances inside of a single operating system and have those systems running in parallel. It's like a virtual OS instance, but instead of a whole copy of the operating system running in the container it is just the environment itself. It's fast to deploy and easy to restart. If your application service halts or crashes, just destroy the container and restart it. No need to reprovision or rebuild anything. The container admin program takes care of the heavy lifting and your service returns.

Containers have been used in development organizations for some time now to help speed the need to rapidly configure hundreds or thousands of instances to run a single command once or twice. It's a great way to provide huge amounts of test data for code to ensure it will run correctly in a variety of circumstances. Beyond development there are even more uses for containers. Imagine having a huge database application. Rather than building query functions into the app itself, the queries can run as containers that are spun up according to direction as needed and destroyed as soon as the data is returned. This would reduce the memory footprint of the database significantly and off-load some of the most CPU-intensive actions to a short-lived construct.

When application developers start utilizing containers even more, I imagine we will see even more security being built into software. If a process is forked into a container it can be isolated. Containers can be configured to self-destruct when a breach is detected, immediately ejecting the offending party. Data can be contained and communication lines secured to ensure that the larger body of sensitive material can be protected from interception. Applications can even be more responsive to outages and other unforeseen circumstances thanks to rapid reconfiguration of resources on the fly.

Containers are on the verge of impacting our IT world in ways we can't possibly begin to imagine. The state of containers today is where virtualization was a decade ago. In those 10 years, virtualization has supplanted regular server operations. Imagine where containers will be in even just five years?

You owe it to yourself to do some investigative work on containers. And don't forget to check out the Thwack forums where IT professionals just like you talk about their challenges and solutions to interesting problems. Maybe someone has the container solution to a problem you have waiting for you right now!

It’s quite common to see end-users complaining about SharePoint® being slow. It could be slow to load content, search pages, upload/download file, or any operation. Usually, it’s the website front-end where the user is facing the issue and complains about. But the root cause of the problem doesn’t always necessarily lie on the web front-end. Whether it’s SharePoint or another web application for that matter, a deep-rooted infrastructure performance issue in the web application layer, or the database, or the underlying physical/virtual server environment could be the actual source of the problem. Let’s not forget about storage. A performance issue in the storage layer—whether it is server disk volume or external NAS/SAN array—could directly impact all the way up to the web application and impact end-user experience, as well as business continuity.


One of the main challenges IT pros have today is absence of centralized visibility into all these layers. While it is possible (time-consuming though) for IT admins to check each component of the IT stack one by one, the smart way would be to have comprehensive visibility across the various layers in one view.


SolarWinds AppStack™ dashboard can really help solve these problems. AppStack consolidates performance insight and monitoring data from four SolarWinds IT management products (SAM, WPM, VMan and SRM) and presents the data in one view, which is in the form of an application dependency map—allowing you to see how various infrastructure entities are connected to one another, all the way from website transactions to applications, databases, physical and virtual servers and storage systems. From a single dashboard, you can centrally monitor the health and performance of all these components speeding up problem detection and troubleshooting.


Check out the infographic below: visually it explains how the AppStack dashboard works and how you can simplify performance monitoring and troubleshooting of your IT infrastructure. In the example, we have taken the example of a slow SharePoint transaction alert received on the website front-end, and show how AppStack helps you analyze the application layer (horizontally across the stack), and underlying physical and virtualized environments (vertically down the stack) until you arrive at the root cause.


Download the full infographic at the end of the blog.

AppStack 1.PNG

AppStack 2.PNG

AppStack 3.PNG

AppStack 4.PNG


Note: AppStack is NOT a separate product. It’s available as a built-in dashboard as part of each of these products—SAM, WPM, VMan, and SRM. You can benefit from AppStack even when you are using these products individually. But when integrated, the collective insight across all IT layers will simplify IT troubleshooting significantly.

By Leon Adato, Head Geek SolarWinds


Not long ago, I read “Five Things Old Programmers Should Remember” by Gary Wisniewski. In it, Gary recounts watching Star Trek one evening and how something the late, great Leonard Nimoy as Mr. Spock said to James T. Kirk in response to the good captain’s lamenting about getting too old and worn out:


“If I may be so bold, it was a mistake for you to accept promotion. Commanding a starship is your first, best destiny; anything else is a waste of material.”


Gary then commented on how this applied to him, having gotten sidetracked, if you will, and departing from his first, best destiny as a software engineer—never mind the fact that his sidetrack was starting his own company and raising bucket loads of venture capital money. He then goes on to list five things old programmers should remember.


I loved his perspective and, as I head into my third decade in IT, the reminder that the things that pushed me into a career in technology remain the things that not only keep me here, but are also the things that make me great at what I do. So, I thought it a worthy endeavor to list out the things that have always been true for me as an IT professional; more specifically, as a network administrator.


To help me, I've engaged with friends, colleagues, and fellow Head Geeks over at SolarWinds - Patrick Hubbard, Kong Yang, and Thomas LaRock - to get a perspective from each of their respective areas of specialization. In the coming weeks, you'll hear what is important to remember if you are and old SysAdmin, Virtualization admin, or DBA.


As for me, I'm going to keep this focused on (almost) nothing but net. So what is it that an old network engineer needs to remember?


1.) First, I can't say it better than Tom will in his essay, so I'm going to give you a preview here: Always assume good intentions. "Just because someone is yelling at you because the server is down doesn't mean they hate you. If an end-user suggests that SQL replication is the answer to all their problems, take the time to learn more about what problem they are trying to solve. A little empathy will go a long way in your career." If an end-user suggests that “adding some QoS” is the answer to all their problems, take the time to learn more about what problem they are trying to solve.


2.) Tightly related to number one is the fact that “they” are never going to understand the network (or networks in general) like we do. Never. Shouting into the void, rolling your eyes, muttering under your breath and generally holding “them” in some form of contempt is not going to change this. Commit to the idea that you will educate when and where the opportunity presents itself, but otherwise you may as well wear a pointed hat and beard.


And no, numbers one and two are not contradictory. True, they don’t understand. Yes, they will make suggestions that border on insane, not to mention inane. But you are still best served by assuming good intentions.


3.) This one’s all about us: Just because “they” won’t understand doesn’t mean nobody will ever understand. Just “them.” Find the ones who are “us.” The ones who share your passion and interest. Bring them close. Learn how to be a mentor. How to challenge without overwhelming How to teach. Learn how to share the load, and even delegate. In the beginning, you may only be able to offload 10 percent or even less of your tasks, but believe me, even that is worth your time.


4.) “Reload in” has been and always shall be your very good friend.


5.) I invoke good old RFC1925, also known as “The Twelve Networking Truths,” which is just as true today as it was in 1996: If your network doesn’t actually work, then all the fancy hardware is for naught. Anything that impacts the ability of your network to work should be suspect. And you must know that your network is working and how well it is working. This is only accomplished through proper monitoring and management. For more on that, check out this ebook on monitoring as a discipline.


6.) You should always focus on what you are able to accomplish. As network engineers, we frequently get caught up in how we can get the job done—being a CLI jockey, an ACL guru or a Wireshark wizard. Even though we take pride in the hundreds of hours we spend building a specific skillset with a particular tool, the reality is that our value is far more than the commands we’ve memorized.


In closing, this more than anything else, is what we “old” Network Engineers (and all IT professionals, really) who have been around the block a time or four need to remember: We are more than the sum of our skills—we’re the sum of our experiences, ideas, and passions. That is what got us here in the first place, what has kept us here all this time and what will keep us here as wave after wave of new blood and fresh young faces come to join us on this journey.


Look for more thoughts on what "old" IT Pro's need to remember in the coming weeks!

Secure IT

Posted by kong.yang Feb 5, 2016

Last week, I discussed taking your mastery of your virtual environment and extending its domain command. I listed a set of four skills that will allow any virtualization administrator to take flight with their career: Security, Optimization, Automation, and Reporting. This week, I’ll cover the first skill, security, and what it means to not get breached.


Security: Control and governance across the data, application and user planes.


The principle of security guides you around governance and control as 1s and 0s traverse across the IT planes. Security is a loaded term that can encompass all manners of sin committed against the IT domain. In the virtual environment, just because the resources are abstracted doesn’t mean that you’re immune to security breaches. Ultimately, the end-goal of breaches is to gain access and control to the data, application, and user planes. Accordingly, IT needs to defend multiple planes across multiple domains.


The figure below highlights the many vendors who operate in the security space and all the different entities that require securing from infrastructure to SIEM to cyber to IAM to application.



[Momentum Partners’ Security Sector Strategic Landscape (Q2 2015)]


Knowing is half the battle: common security attacks


There are four common security attacks that IT administrators deal with:

  • DDoS attacks – an attack designed to overwhelm servers with bogus traffic that causes websites and applications to slow down and eventually become unavailable.
  • Phishing schemes – an attack that sends fraudulent email disguised as a legitimate communication that lures recipients into clicking the malware link.
  • Poor patch management – leaving unpatched operating systems, browsers, applications, and databases allow hackers to access your organization’s IT assets.
  • User error – human error can lead to IT nightmares like losing a work device with unencrypted, sensitive data or falling for phishing schemes or surfing to malware infested websites.


Security presents a tremendous challenge and career opportunity for IT professionals. And it's much too vast to properly cover in a single post so this is just an appetizer to future posts. As the digital transformation expands, the gap in security ops personnel is growing as well. For example from ISACA, the 2016 Cybersecurity infographic below shows the shortage of security ops professionals.



[ISACA 2016 Cybersecurity Skills Gap]




Security starts with awareness of potential security threats and developing countermeasures. IT professionals looking to get a start in security should leverage the NIST Cybersecurity Framework, which covers the following risk management functions in detail:

    1. Identify
    2. Protect
    3. Detect
    4. Respond
    5. Recover

Establishing and maintaining trust throughout the IT transaction/interaction is key to securing the any IT environment including the virtual realm.


Additional reference for security:


1. I have previously covered some tips to secure your virtual environment in my Network Computing article.


2. SolarWinds Lab Episode 27:


3. Crossing the Great Divide: Conversations between IT, Networking, and Security Ops

In the last post we discussed a little bit about what Infrastructure-As-Code (Infra-As-Code or IAC) meant. But we obviously didn’t go very deep into how to begin this journey and that is exactly what we will be covering in this post.


Let’s assume that in most environments today you have some sort of process that is followed to implement change on your network. Be it a new change or a change required to resolve a specific issue that needs to be addressed. But for sakes of conversation here let’s assume that our change is to change from existing manually added static routes to dynamic routing using OSPF. Me being the good network admin/architect that I may be, I bring this up in a weekly meeting and state that we need to change our routing methodology. The reason may be that our network is getting too large and difficult to manage by adding static routes manually everywhere. Your manager and peers listen to your reasoning and decide that it makes sense and for you to come up with a plan to implement this change. So you go back and write up some documentation (including a drawing) and add all of the steps required to make this significant change. The following week you present this to your manager and peers once again and receive the go ahead to proceed. So you put in a change control for approvals and attach your document that you spent all of that time writing up.  Now let’s assume that your manager is not so technical and really doesn’t understand the complexity of this change but proceeds with approving your change and you are set for 2 weeks out. You now go and write up some scripts to execute the changes based on your documentation you spent all the time on writing up (better than copy/paste right?). You soon realize that you will be making changes across 50 individual devices but you are not worried because you have scripted it all (50 scripts?). So at the next meeting you assure everyone that you have all of your scripts written out and all should be good to go. Again, your manager and your peers are good with the process you have put together for this massive change and all agree that this change will occur in 1 week. Now, let’s stop right here and evaluate what just occurred. Does this sound like your environment or environments that you are accustomed to? Are we now doing Infra-As-Code? Not even close. So where did we fall short on this so call Infra-As-Code journey? Everywhere could be easily stated.


So what was missed in the above scenario allowing us to start on this new journey? Let’s start with the most obvious first. Where was the code review and peer review? Didn’t we cover peer review discussing this in the meeting(s) with your peers and manager? Nope. Our peer review would have included our team as well as all other teams which could be affected by this change. Remember, you only know what you know and other teams will have different perspectives and uncover additional questions or concerns, in which will be different than your own. So this is a great example of beginning to tear down the silos of communication on implementing change. Up next would be code review. Who else reviewed your scripts for any typos, missing steps or possibly even something added that could break your network? And if you did employ code review did they understand the actual change? Also where was the testing process and results of those tests to review? This doesn’t even cover version control on your scripts and the fact that scripts themselves may not even be the correct automation tooling for this.


So how do we start this journey? It should actually be quite easy but it does require a completely different mentality than what you may be used to in the past. Our process should look something similar to the following.


  • - New change request – Change from manual static routing to dynamic OSPF for all networks
    • Open discussion
      • § Involve all teams and organizations and discuss the specifics and reasons on why this change should be embraced
      • § Entertain input from others on their questions and/or concerns
        • May also include additional benefits which you may not have thought of
      • § Discuss the specifics on a testing plan and what a reasonable timeline should be
    • Development phase
      • § Obtain a baseline of the state of the current routing topology
      • § Document the processes required to get you to the desired state and also include drawings
      • § Create your automation tasks and begin to version control them
        • Using automation templates vs. scripts
        • Version control – will allow you to document all change phases and ensure that your tasks can be repeatable and consistent. As well as allow you to roll back if needed.
        • Leverage API’s (if available) and/or configuration management tooling
    • Testing phase
      • § Ensure that you are testing in a like environment
        • Can also leverage virtual environments which can mimic your current production design
        • You can also use your configuration management tool to run dry runs of the configurations against production systems (No changes made but will report back on results)
      • § Leverage automation integration testing tools to actually perform configuration changes in your test environment (CI/CD)
        • Builds the testing phase documentation and results which will be used in later discussions
        • Maintains a history of the changes and when or where a failed configuration was experienced
        • Allows for a more readily available way to go back and look over all steps performed
      • § Finalize the automation tasks required to reach the desired state of the change requested
    • Code-review
      • § Leverage a code-review system
        • Ensures that the automation tasks are solid and absolutely no room for error
        • Ensures accountability
        • Ability to send back to the testing phase to correct or add tasks which may have been missed or need to be added
    • Peer-review
      • § Re-engage all teams and organizations which were involved in the open discussion phase
      • § Discuss the documentation and drawings of the current baseline established
      • § Discuss the processes and documentation on how to obtain the desired state of the change request
      • § Discuss the findings and results of the testing phase
      • § Share the phases of testing and present the details of each
      • § Discuss any further questions or concerns
      • § Agree on whether to proceed or not to the original timeline
    • Implementation phase
      • § Leverage the exact same automation integration tools and methodologies to bring your production environment to the desired state
        • This will ensure that the processes are exact. Leaving room for error to a minimum and a repeatable process.


As you can see from the above, there is a fair amount of mentality change that has to occur in order to begin this journey. But remember as each new implementation follows these same methodologies it will become much easier going forward. As well as it will provide a much more consistent and repeatable process for each implementation.


Hope you enjoyed this post and it has proven to be of some use. Up next we will discuss some of the tooling required to provide us the needed abilities discussed in the above phases.

Network Access of Old

I remember back in the days when I worked at the phone company.  We had a security desk right inside the door and at the counter was a desktop that had the company directory on it.  What didn’t make a lot of sense to me was that the Ethernet port was on the front of the wall, not behind the counter.  Anyone could walk into the office and unplug the corporate directory PC and plug their own in.  DHCP would give them an address and they were on the LAN.  Sad thing is that people did.  I would come walking in from lunch and often see some random guy copping a squat on the floor with his laptop connected.  Back they we really didn’t have a clear way of preventing access to the network.

What We Used to Do

Prior to 802.1X we did have a few solutions but they had their limitations.  One way we could control things was by using a VLAN Membership Policy Server (VMPS).  With a VMPS the MAC address would dictate which VLAN you were assigned to.  If you were not listed in our database you would not get a VLAN assignment on the LAN.  The drawback here was that you had to manage the MAC database.  If an employee had a NIC failure and the NIC were replaced, we would have to remember to update the database.  This happened a lot back when the laptops had a PCMCIA NIC with the flimsy dongle.

Another way we would control network access was with Port Security.  This of course only worked if your switch supported the feature.  If it did you had a few ways to handle business.  You could enter the MAC that should be connected to each port and then limit the number of MAC addresses to 1.  This didn’t scale well either.  We could sticky learn the MAC which helped, but again, scalability issues.  So even though we had a few solutions, nothing was really a great fit.  Fast forward to today and 802.1X is the clear fit.  While we had 802.1X back then, or at least we started to see it, client support was limited.

Network Access Today

Today we still don’t have all the answers.  We primarily use 802.1X and EAP to authenticate and authorize a user on a switch port or on a wireless SSID.  This method of controlling access works well because we have much better support for EAP in our native supplicants today.  For some of the more advanced EAP methods we have clients like Cisco Anyconnect.  Using 802.1X and an external authentication server scales better than the previous solutions discussed in this article.  Along with the scalability comes a great deal of context data that’s useful in determining who is connecting, where they are connecting, how they are connecting and so on.  From a policy perspective this is fantastic.  We have a level of visibility today that we didn’t have back in my early days.  Still, the solution isn’t perfect and there are still some things we need to address, like all that log data.

Where Do the Logs Go?

Your identity management solution is but one source of log information that you’re receiving.  You have the logs from the switches, APs, and Firewalls where your VPN is terminating.  There’s a handful of logging solutions out there that can handle the volume we see on most networks today.  The key to consuming log data is not just being able to store it and handle the shear amount of data being received, but its also being able to use the data in a meaningful way.  So what are some of the things you’d need to identify?  A good solution would help identify users on the network that are doing things that aren’t exactly normal.  When you consider the prevalence of  Bontnets and DDoS attacks it would be advantageous to implement a solution that would identify if your assets are participating in these types of attacks.

The attacks here are just a few examples.  There are many more.  But I’ll leave this post with two questions:

  1. What are you implementing as your Identity Management Solution?
  2. How are you using the log data from that solution and other network devices to mitigate attacks and minimize unauthorized activity on your network?
Mrs. Y.

Security Narcissism

Posted by Mrs. Y. Feb 2, 2016

Neil_Gershenfeld.jpgA couple of weeks ago, I was pleasantly surprised to find that Neil Gershenfeld would be giving the keynote at a large East Coast security conference I was attending.  I’ve been a fan of the fabrication movement pioneered by people like Gershenfeld for a few years. I’ve been humbled to see how tools like 3D printers and laser cutters are starting to improve lives and empower communities. Consider the e-NABLE project, which fabricates prosthetic hands for children, or various up-cycling projects in the developing world to reduce pollution by reusing computer parts or plastic waste. 


Gersenfeld spoke of fabrication disrupting production and consumption, reinventing the way we work and live. His ideas alternately perplexed and excited everyone in the room and at the end of his talk; he had more groupies lined up to meet him than William Shatner at a Sci-Fi convention. But what was someone like Gershenfeld doing in a room full of people whose careers were based upon finding faults in systems and software? I had reason to hope that I wasn’t the only security professional tired of the worn-out breaker mentality so prevalent in our field.


Maybe the tendency towards narcissism in the security community is finally starting to shift. Many industry veterans I know no longer feel the need to constantly display their prowess by exploiting vulnerabilities. They’re also burned out from repeatedly addressing the same problems with no apparent end in sight.  Perhaps the industry is evolving because its participants are maturing. They have families who are dependent on stable and safe technology. But more likely the change has to do with organizations questioning the value delivered by information technology groups and by extension, security teams. The stakes are higher as breaches get larger and more frequent. Those who are in the business of safeguarding digital assets are being held accountable when losses impact the bottom line.


At Gershenfeld’s keynote, someone asked what security professionals could do to support this evolution in the way we use technology. Shouldn’t this start with an attitude adjustment? The truth is that as much as we want it to, the security tail can’t wag the dog. Security controls only matter if they add value and don’t become an obstruction to the business.


Instead of fearing change to our reactive security processes and checkbox procedures, we should restructure them by focusing on operationalizing security.  Most of the security problems that plague our organizations are still basic, solved by simple controls. These include configuration management, system build templates, access management based upon data and user classification and embedding responsiveness to alerts into our systems.  By approaching security as a feature instead of an end in itself, it becomes everyone’s concern and is more likely to be implemented. No longer some unique skill to someone with a special certification.


Security professionals no longer need to be the center of attention in a room full of technologists. We are simply subject matter experts called upon for guidance to help improve a product or project. This may change the nature of our jobs as digital cops, but ultimately anything that furthers the business will benefit information technology and security groups. Once security teams finally abandon their self-centered need to be a gate, grinding business to a halt, we might actually see progress that will make our jobs truly rewarding. The aim isn’t to increase the security budget, but to collaborate with a team to improve our workplaces, our organizations and maybe the world.

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.