I’ve previously mentioned that I’m getting into lockpicking, and I continue to practice in small pieces of spare time. Last week I picked my first non-practice lock, a 5-pin dead bolt in my apartment. Just tonight I sat down to try it again and picked it three times in 6 minutes. I’m a little scared, but happy with my progress!

I’ve been able to start to actually feel the various “gives” when a pin is set, as well as the sounds. Sometimes there is a small give in the torque when a pin clears. Sometimes a small click. Sometimes it is the lack of tactile response from the pin when it is set and the spring no longer pushes down on the pick. All of these evidences are getting more and more common. I’m even surprised more and more at how easy raking a lock open can be. Raking involves moving a jagged rake pick in and out of the key way such that several pins quickly set, as opposed to picking the pins one by one. Insert torque, slide in a rake pick, and before I’ve even completed two “rakes” the lock is open. I’ve done that a few times much to my surprise. If you know what a bumping is, raking is smack in the middle of the spectrum between bumping and pin-by-pin picking.

Sunday evening I watched War in the theater and for the first third of the movie and through the previews had a lock and pick in my hands just opening it over and over, while not trying to create a pattern of it. I don’t want to unlock my locks just because I follow the same pattern each time, but rather to open them through actual semi-conscious effort.

So far it has been working, and is quite a nice little idle activity. I might move up to my cut out spool pin lock this week. You can see a picture of a spool pin towards the bottom of this really interesting page on lockpicking. This page looks like something nice to read. I especially enjoyed skimming down to the part about unset/unbinding pins and the various states, plus how they feel so as to identify the state.

Ahh, summer’s beginning to give up her fight [1], portending my favorite season, Autumn! I’ve also been busy at work and at play, which has limited my posting energy. Not only that, but holy crap have some of my feeds been posting a ton the past couple weeks! It is tiring trying to keep up with them, or even to scroll through the articles I don’t care to read.

Today’s news comes from Marcin who reviews the question of going with a series of best of breed solutions or all-in-one security packages? You’ll almost certainly have cost and support benefits from an all-in-one solution, but it may still have small gaps, and certainly tends to be weaker in some areas, if not weaker than the whole of a series of best of breeds put together.

What I would choose is as good in the best of breed as I can afford in time and money based on my company size. As a techie, I’d much prefer best of breed over all-in-one behemoths. I tend to find best of breeds to be more trustworthy and much more surgical in their approaches. In a way, that illustrates a comparison. Would you prefer a specialized surgeon to perform operation X, or a more commoditized but affordable provider? What about for a routine operation? Do you want a common product or something specialized? Agility?

Compliance promotes this idea as does the maturing of the security industry, but should we really settle for “Good Enough” security? Perhaps that is pragmatic, but I’d still like to think anything I secure is better than the typical Good Enough…

[1] If you know this song, props to you, you have some taste!

Upon recommendation in the Security Catalyst Forums, I picked up a copy of The Practice of System and Network Adminsitration by Thomas Limoncelli, et al.

So far I am impressed by the book. This is an ideal book to give any manager or beginner/intermediate SA/NA. It stays technical, but so far all of the advice is very general and common sense for any IT shop. Do automation, do this, don’t do this, this is why this is a bad idea, these are universal steps to get yourself out of the hole…

There are moments of mangled sentences and some of the topics seem a bit dated (Windows NT…) but this is so far a book I think I’d like to see on the shelf of any manager (or SA team library) I might have for the foreseeable future. It may not tell you how to automate deployments of Windows XP workstations, for example, but it will give you the reasons why this is a good idea and approaches to take to get shit done.

It is also nice to see some things I’ve learned on my own to be echoed in this book, validating my own common sense and reinforcing confidence. Despite being a big book (over 1000 pages), it can be read in chunks and is an easy read nonetheless.

I have adopted the use of xml files as configuration files for any PowerShell scripts I’ve been writing for work lately. Today I just found an odd bit of behavior when working with building a new xml file (if the script runs and sees no existing xml config file, it creates one). Normally, adding child objects in xml is fairly straightforward. Assume this is the existing xml.

<installcontrol>
   <serverlist>
      <server>
         <servername>ALDARAAN</servername>
         <servername>TATOOINE</servername>
      </server>
   </serverlist>
<installcontrol>

We can use this script to add a new child server, DANTOOINE.

$xmlFile = Get-Content $xpath
$objNewServer = $xmlFile.CreateElement(“server”)
$objNewServerName = $xmlFile.CreateElement(“servername”)
$objNewServerName.Set_InnerText(“DANTOOINE”)
$objNewServer.AppendChild($objNewServerName)
$xmlFile.installcontrol.serverlist.appendchild($objNewServer)
$xmlFile.Save(“$xpath”)

This is great, but what if there are no child objects already present, such as in this xml file.

<installcontrol>
   <serverlist>
      <server>
      </server>
    </serverlist>
<installcontrol>

Powershell complains that it can’t add append a child to a string. The script needs to change slightly to accomodate. The following snippet will work both for empty parents and also populated parents. The difference is in the 6th line.

$xmlFile = Get-Content $xpath
$objNewServer = $xmlFile.CreateElement(“server”)
$objNewServerName = $xmlFile.CreateElement(“servername”)
$objNewServerName.Set_InnerText(“DANTOOINE”)
$objNewServer.AppendChild($objNewServerName)
$xmlFile.installcontrol[“serverlist”].appendchild($objNewServer)
$xmlFile.Save(“$xpath”)

I’ve been working again with PowerShell, doing some new things. There are still a few nuances to a newbie like me. For instance, while it is easy to create arrays, it is a bit more arcane to remove items from an array. Thankfully, I found a site that gave me the answers I need.

To remove the first item in an array, reassign only items 1 through the length of the array back into the array (or a new array). Remember that arrays are indexed with the first item as 0, not 1.

$array = $array[1..$array.Length]