The big news of the week was a social engineering hack of Twitter. The hackers were able to send out fake tweets from famous accounts in order to scam hapless victims.

While it’s not clear yet exactly what happened, from the little we know the hackers conned Twitter employees into giving access to some internal tools. These tools allowed the hackers to post tweets directly from any account they wanted. Most likely they posed as co-workers at Twitter.

This type of security breach underscores a sometimes overlooked problem in securing your data and networks. We’re used to changing our passwords, Multi-factor authentication, security questions, etc. However, everyone should be aware of direct personal contact from someone asking for sensitive information. We’re used to screening these “phishing” attempts out of our email, phone, and text messages, but would you (or your employees) be able to catch a seemingly benign request from a “co-worker”?

In an era where workers are increasingly virtual and do not meet most of their co-workers, it’s easy to see how someone could craft a careful attack to gain unauthorized access or sensitive information. Remind your employees to be careful about company data, even when requested from someone that seems legit.

This was a relatively slow week, being a holiday week and having finished a sizable cutover described in last week’s post.

That said, I am reminded how much I love using Amazon Workspaces. For those who don’t know, this is a virtual desktop, sort of like “Remote Desktop” for those who’ve used that. In my case, the client for which I use Workspace has it set up so that the workspace is inside their network. This means I don’t have to connect via VPN anymore, use proxies, etc. I just login using the app, and have my desktop there, with all running applications from the last time I used it. It’s very nice, and accessible from multiple devices, even a web browser.

Usually when moving an application to a new platform, upgraded software, etc. I prefer to slowly implement the new solution – allowing for bug fixes and other issues to be addressed. Then, when the new platform is stable, finish moving things over to it. That’s a nice option to have, but it’s not always possible.

This week the monitoring team I work with moved to a new version of Microfocus’s Ops Bridge. This involved porting many custom applications, and lots of prep work. However, the final “cutover” had to be what I call “big bang” – no soft launch, or partial move, but everything at once. The name “big bang” comes from what can happen if things don’t go well when doing one of these.

So far, things seem to have gone well. I say “so far”, because once we took care of the realtime problems that came up, things have been quiet. I assume more problems will be discovered over the next few days, but hopefully nothing major. It feels good to have this one behind us, though!

I spent a lot of time this week cleaning up some data used to synchronize two databases for one of my clients. Essentially, this involves taking inconsistent or otherwise messy data from system A, and applying changes or rules to it when updating system B. Ideally, data would be clean from the start, but that never is the case. NEVER!

For tasks like this, my goto tool is Perl (see www.perl.org). It’s old school, I know, and most programmers today never heard of it, or used it. It’s sort of like the COBOL of the 90’s. Everybody says it’s obselete, but there’s a lot of legacy code out there written in Perl.

Perl is ideally suited for text / data processing, in my opinion. It’s a scripting language, so it’s quick to make changes and re-run, great with regular expressions, and generally pretty fast. Oh, and it’s ubiquitous. That means, practically every Unix system you run into has it installed already, and it easily installs to Windows if for some reason you have to use it there. That makes it easy to copy and reuse code, without lots of setup.

So, use Perl. Or ask me for help!

I spent some of this week working with an old friend – wget. For those that don’t know, wget is a command line tool to query a remote website and get the response (a web page, or whatever). Anyway, in my case, I was tasked to build a tool to check various URL’s and send alerts if any were not responding or responding incorrectly. With php, I should have been able to the built in curl functions, but couldn’t figure out how to make curl use the system proxy settings (some urls needed to go through a proxy). Anyway, sometimes I go with what works, rather than beat my head against a wall for too long.

Also, I moved this website to hostgator, an old hosting friend. For a long time I’d had the site on AWS, to learn more about cloud services. But AWS doesn’t give all the bells and whistles of a hosting platform out of the box, and it just got too tedious to get set up. Who wants to set up a load balancer just to add SSL to your website anyway?

So it was a week of old friends, if you can call technology a friend!