Regular Change Windows

I am a proponent of change management (CM). I value the function, even if I sometimes despise the bureaucracy found in typical implementations.

At $work, we follow fairly well established CM process. It’s not perfect and it has bureaucratic elements but it’s well understood and mostly respected. Regular thinking about process improvement has led to critique of the individual elements of the process. Deadlines. Approvals. Communication plans. Success criteria. Change windows.

Let’s talk about change windows. We have a “regular” change window that happens once a month on a particular weekend. This was an IT decision. We decided on a particular schedule and called it the “regular” change window and asked everyone to schedule their changes within that window unless they had justification and approval from management for doing otherwise. The problem is, by the numbers, it is hardly our “regular” change window.

The Numbers

In 2014, just over 89% of our changes were performed outside of the “regular” change window. The trend for 2015 remain nearly identical.

Those numbers mean that we’re (re)negotiating change windows with stakeholders 9 out of 10 times. We’re creating justifications and requiring “off-cycle” approvals 9 out of 10 times. Talk about overhead!

The key to this process failure and resulting overhead is that we haven’t tied change windows to the actual business. We didn’t engage stakeholders to determine when is a good time to make changes for the business. However, in our complex environment doing so isn’t straight forward. We have a multitude of different clients, stakeholders and services. Boundaries often overlap.

Reducing the Friction

We can consider focusing in on major services, identifying stakeholders and establishing regular change windows on a per-service basis. This probably makes sense for the major services but what about the smaller, less visible services? What about services with a single stakeholder? How do we document each change window? How do we enforce changes to a particular service within that service’s specific change window? I don’t know…. but my short-term recommendation is to simply ditch the idea of regular change windows unless we can do them right. Why are we bothering with rubber stamp approvals for scheduling on 90% of changes when we’re going to talk about schedule in CAB anyways? What are we gaining from this?

 

Lync/Skype for Business Message Limit

Maximum frustration alert!

Lync (Skype for Business) has a maximum message size limit for instant messages:

This message is too long.

The limit cannot be configured and has a bizarre maximum of 800 characters for the first message and 8000 characters for subsequent messages to the same recipient. What? Why? How? Confusion and frustration ensues.

I actually enjoy using Lync but this one unresolvable minor irritation is spoiling the entire experience every time I want to share text with my colleagues.

World’s Worst POODLE Scanner for HTTPS

Behold, the world’s worst POODLE scanner for HTTPS services:

#!/bin/bash
 
subnets="192.168.0.0/16 10.0.0.0/8"
 
for subnet in $subnets; do
echo -e "########## SCANNING $subnet ##########\n"
https_servers=`nmap -sS -P0 -n -p 443 -oG - $subnet | grep open | awk '{print $2}'`
echo "TCP/443 found open on:"
echo -e "$https_servers\n"
echo "Scanning for SSLv3..."
for https_srv in $https_servers; do
echo -n | openssl s_client -connect $https_srv:443 -ssl3 &> /dev/null
if [ $? -eq 0 ]; then
echo "SSLv3 ENABLED on $https_srv:443"
fi
done
echo -e "\nCOMPLETED SCAN FOR $subnet\n"
done

All it really does is tell you if SSL 3.0 is enabled on port TCP/443 when given a list of IP addresses and/or subnets to scan.

The above code depends on several things:

  1. bash or bash-like shell
  2. nmap, running with root privileges
  3. openssl command line utility
  4. awk and grep

Define the variable $subnet with a space-delimited nmap-compatible list of IP and/or subnet addresses.

The code can be easily modified to check for SSLv3 presence on other services/ports but I didn’t build that into the functionality because this is, after all, the world’s worst POODLE scanner.

Quick? Check. Dirty? Check. Yep, it’s a hack.