Skip navigation
1 15 16 17 18 19 Previous Next

Geek Speak

1,922 posts

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 Employee 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.

In 2015, I introduced the DART Framework as a series of skills that virtualization administrators can leverage to master their virtual universe. In 2016, it’s time to take your IT career flight beyond the final frontiers of your virtual universe. Just do it with the SOAR Framework: [Updated with hyperlinks to SOAR articles.]

  • Secure - Govern, control data, app, stack, and user planes
  • Optimize - Run more efficiently & effectively
  • Automate - Scale IT
  • Report - Show & tell to the leadership team


SOAR-ing skill set

Security should be top of mind with every IT professional – we are all responsible for security ops whether directly or indirectly. Securing IT delves into governance, compliance and control of data, applications, stacks and user planes.


Optimization boils down to maximizing the return on investment (ROI) of IT. We all get that IT budgets are getting squeezed or being diverted into new investment areas. Optimizing allows IT professionals to do more with less in their data center environment. If done well, it highlights command and control over any given data center ecosystem and opens the door to many new career opportunities.


Automation is the skill that allows IT professionals to scale both their data center and their career aspiration. Whether it’s through scripts, workflows, templates or blueprints, automation is a skill that reclaims the most important resource for any IT pro – time.


Reporting is the least glamorous IT skill; but it’s the one that will most likely get you promoted. Essentially, it revolves around communicating how great of a job you are doing managing your data center efficiency or making your case to get the necessary tools to deliver what the business needs.


February S.O.A.R.s

Every Friday in February, I will publish an article on each specific SOAR skill with an example of what good looks like in a virtual environment. P.S. it can be applied to any tech construct and tech domain. Time to shatter the shackles of silos!


Reference [Updated with hyperlinks to SOAR articles]

If you follow Geek Speak, you're probably aware of the annual "Head Geek IT Pro-Dictions." That said, we thought it would be fun to have the Head Geeks revisit last years predictions. Last year certainly offered countless technology trends and topics to discuss, deliberate, dissect, and debate.

But, were the Geeks right or wrong with their predictions? Check out the video below, as the Head Geeks discuss if they deserve a cheers for their tech predictions or an unfortunate series of jeers. And if you haven't seen this years IT Pro-dictions, be sure to check them out at the end of the video to find out what they believe will be the top ten industry drivers of 2016.

As always, your comments are welcomed, so feel free to chime in and have some fun with the Head Geeks!







January 28 is Data Privacy Day (DPD). Observed since 2008, DPD brings awareness to the importance of data privacy and protection. According to the Verizon 2015 Data Breach Investigations Report, about 60% of cyber attackers are able to compromise an organization’s data within minutes. 2016 is going to be no different from a threats perspective, and data thefts are bound to happen. However, you can minimize the possibility of a cyberattack or data privacy incident by strengthening network security and following some simple security tips.


Centralize monitoring and control: Continuously monitor your network and get a centralized view of the hundreds of security incidents happening in real-time. This is one of the most basic requirements if your organization is required to follow industry-standard compliance regulations like HIPAA, PCI DSS, etc.

Embrace data-driven forensics: Data-driven analysis of a suspicious event will result in better root cause analysis and forensics. A suspicious event can be as trivial as an increase in Web traffic from a known host during specific non-business hours over the last seven days, or repeat connection requests to critical assets (servers, databases, etc.) from an unknown host outside the network. Considering the worst case scenario that an attack has happened, you must be able to trace it back to the source, establish an audit trail, and document the findings and the action taken.

Watch out for malicious software: A term we may see more often in 2016 is ransomware. Sensitive data is the main driver behind these types of malicious software penetrating the network, and a regular user can become an unsuspecting victim of this attack, spreading it to other computers/applications inside the network. Though anti-virus and anti-malware software can be installed to protect the systems, you should set processes in place that will alert you to suspicious application and file activities. Also, you must consider the fact that subtle file and registry changes are hard to detect without file integrity monitoring tools, and zero-day malware attacks dwell on this advantage.

Educate your users/colleagues: Patient records and credit card information are critical data. However, other data, such as social security numbers, ATM passcodes, and bank account names stored on an unprotected desktop or document creates a prime opportunity for private data leaks. Periodic mailers and knowledge sharing among peers and with users can relatively improve your organization’s security.


You can learn more about the Data Privacy Day here.


Do you think it’s time to stop, think, and formulate an effective data privacy policy for your organization? What plans do you have to improve data privacy in your organization in 2016? What roadblocks do you foresee that will stop or slow you down from implementing some right away? Write in and let me know.

I read an interesting thread the other day about a network engineer that tried to use an automated tool to schedule a rolling switch upgrade. He realized after it completed and the switches restarted that he had the wrong image for the device and they weren't coming back up. It was about fifty switches in total, which resulted in a major outage for his organization.

What struck me about the discussion thread was first that he wondered why the tool didn't stop him from doing that thing. The second was that the commenters responded that it wasn't the tool's job to sanity check his inputs. The end result was likely a severe discipline discussion on the part of the original engineer.

Tools are critical in network infrastructure today. Things have become far too complicated for us to manage on our own. SolarWinds makes a large number of tools to help us keep our sanity. But it is the fault of the tool when it is used incorrectly?

Tools are only as good as their users. If you smash your fingers over and over again with a hammer, does that mean the hammer is defective? Or is the fact that you're holding it wrong in play? Tools do their jobs whether you're using the correctly or incorrectly.

2016 is the year when we should all stop blaming the tools for our problems. We need to reassess our policies and procedures and find out how we can use tools effectively. We need to stop pushing all of the strange coincidences and problems off onto software that only does what it's told to do. Software tools should be treated like the tools we use to build a house. They are only useful if used properly.

Best practices should include sanity checking of things before letting the tool do the job. A test run of an upgrade on one device before proceeding to do twenty more. A last minute write up of the procedure before implementing it. Checking the inputs for a monitoring tool before swamping the system with data. Tapping the nail a couple of times with the hammer to make sure you can pull your fingers away before you start striking.

It's a new year full of new resolutions. Let's make sure that we stop blaming our tools and use them correctly. What do you think? Will you resolve to stop blaming the tools? Leave me a comment with some of your biggest tool mishaps!

Will this be the year of Infrastructure-As-Code (Infra-As-Code or IAC) becoming more mainstream? Or is this just a wishful journey that will never catch on? Obviously, this is not a new thing but how many companies have adopted this methodology? Or better yet, how many companies have even begun the discussions of adopting this? Do you currently write scripts and save them somewhere and think “Hey I/we are doing Infra-As-Code already”? Well if true then you are not correct. “But why?” you might be thinking. Infra-As-Code is much larger and more dynamic than just writing scripts in a traditional static method. But if you do currently utilize scripts for infrastructure related tasks and configurations, then you are much better off than those who have not began this journey at all. The reason being is that taking an automated and more programmatic approach of configurations on your infrastructure instead of a manual prone to errors approach is a much more predictable and consistent method of configuring your infrastructure components. Now these components can be of numerous types such as servers, network routers or switches, storage components and much more. But for this series of posts we will only be focusing on the network components and how we can look at beginning the journey towards Infra-As-Code.


Below are some of the topics that we will be covering over the series of posts.



So what does Infra-As-Code really mean? Let’s go ahead and address this here in this post and get a good foundation of what it really does mean.


If you begin to treat your infrastructure as code, you can begin to develop the processes in which allow you to deliver a fully tested, repeatable, consistent and deliverable methodology for configuration state in your environment. In doing this you can begin looking at these items as a pipeline of continuous delivery. Furthermore, allowing for automation tooling to consistently bring your infrastructure to the desired state which has been defined. As you begin this journey you will start with a baseline and then a desired state. Adopting chosen automation tooling for your environment, version control, code review and peer reviews will allow for a much more stable and speedy deployment. As well as, allowing for easier roll-backs in the off chance that something does not go as planned. But the chance of having to roll-back should be minimal assuming that proper testing of configurations has been followed throughout your pipeline delivery.


I know this all sounds great (on paper) and feels a little unrealistic in many aspects but in the next post we will begin to discover on how we can get started. And hopefully by the end of this series you will have a much better understanding and realistic view on how you too can begin the Infra-As-Code journey!

Remember, back in the day, when you’d go to a website and it was down? Yes, down. We’ve come a long way in a short time. Today it’s not just down that is unacceptable, users find it unacceptable and get frustrated if they have to wait more than three seconds for a website to load.


In today’s computing environments, slow is the new down and a slow application in a civilian agency means lost productivity, but a slow military application in theater can mean the difference between life and death. Due to a constantly increasing reliance on mission critical applications, the government must now meet, and in most cases surpass, the high performance standards that are being set by the commercial industry, and the stakes continue to get higher.


Most IT teams focus on the hardware, after blaming and ruling out the network of course. If an application is slow, the first thought is to add hardware: more memory, faster processors, upgrade storage to SSD drives, etc. – to combat the problem. Agencies have spent millions of dollars throwing hardware at application performance issues without a good understanding of the bottleneck slowing down an application.

However, according to a recent survey on application performance management by research firm Gleanster, LLC, the database is the number one source of issues with application performance, in fact 88 percent of respondents cite the database as the most common challenge or issue with application performance.


Trying to identify database performance issues poses several unique challenges:

  • Databases are complex. Most people think of a database as this mysterious black box of secret information and are wary to dig too deep.
  • There are a limited number of tools that assess database performance. Tools normally assess the health of a database (is it working, or is it broken?) and don’t identify and help remediate specific database performance issues.
  • Database monitoring tools that do provide more information don’t go that much deeper. Most tools send information in and collect information from the database, with little to no insight about what happens inside the database that can impact performance.

To successfully assess database performance and uncover the root cause of application performance issues, IT pros must look at database performance from an end-to-end perspective.


In a best-practices scenario, the application performance team should be performing wait-time analysis as part of their regular application and database maintenance. A thorough wait-time analysis looks at every level of the database—from individual SQL statements to overall database capacity—and breaks down each step to the millisecond.


The next step is to look at the results, then correlate the information and compare. Maybe the database spends the most time writing to disk; maybe it spends more time reading memory.


Ideally, all federal IT shops should implement regular wait-time analysis as a baseline of optimized performance. Knowing how to optimize performance—and understanding that it may have nothing to do with hardware—is a great first step toward staying ahead of the growing need for instantaneous access to information.

Read an extended version of this article on GCN

With its ongoing effort toward a Joint Information Environment, the Defense Department is experiencing something that’s extremely familiar to the enterprise world: a merger. The ambitious effort to consolidate communications, services, computing and enterprise services into a single platform is very similar to businesses coming together and integrating disparate divisions into a cohesive whole. Unlike a business merger, however, JIE will have a major impact on the way the DOD IT is run, ultimately providing better flow of and access to information that can be leveraged throughout all aspects of the department.


When JIE is complete, DOD will have a single network that will be much more efficient, secure and easier to maintain. IT administrators will have a holistic view of everything that’s happening on the network, allowing them to pinpoint how one issue in a specific area can not only be detrimental to that portion of the network but also how it impacts other areas.


The JIE’s standard security architecture also means that IT managers will be able to more easily monitor and corner potential security threats and respond to them more rapidly. The ability to do so is becoming increasingly important, as is evidenced by our recent survey, which illustrated the rise of cybersecurity threats.


As DOD kicks the JIE process into high gear, they are establishing Joint Regional Security Stacks (JRSS) which are intended to increase security and improve effectiveness and efficiency of the network. However, the network will still be handling data from all DOD agencies and catering to thousands of users, making manual network monitoring and management of JRSS unfeasible. As such, IT pros will want to implement Network Operations (NetOps) processes and solutions that help support the efforts toward greater efficiency and security.


The process should begin with an assessment of the current NetOps environment. IT pros must take inventory of the monitoring and management NetOps tools that are currently in use and determine if they are the correct solutions to help with deploying and managing the JIE.


Network managers should then explore the development of a continuous monitoring strategy, which can directly address DOD’s goals regarding efficiency and security.


Three key requirements to take into account in planning for continuous monitoring in JIE are:


  • Optimization for dual use. Continuous network monitoring tools, or NetOps tools, can deliver different views of the same IT data while providing insight and visibility to the health and performance. When continuous monitoring is implemented with “dual use” tools they can serve two audiences simultaneously. 
  • Understanding who changed what. With the implementation of JIE, DOD IT pros will be responsible for an ever-expanding number of devices connected to the network, and this type of tool enables bulk change deployment to thousands of devices.
  • Tracking the who, what, when and where of security events. Security information and event management (SIEM) tools are another particularly effective component of continuous monitoring, and its emphasis on security and could be an integral part of monitoring JRSSs. SIEM capabilities enable IT pros to gain valuable insight into who is logging onto DOD’s network and the devices they might be using, as well as who is trying to log in but being denied access.


Like any merger, there are going to be stumbling blocks along the way to the JIE’s completion, but the end result will benefit many – including overworked IT pros desperate for greater efficiency. Because while there’s no doubt the JIE is a massive undertaking, managing the network that it creates does not have to be.


To read an extended version of this article, visit Defense Systems

Filter Blog

By date:
By tag: