Monday, June 23, 2014

Mapping Worker Experiences to Security Training and Policy

Earlier today, I visited my local semi-rural convenience store. There were three Sheriff's vehicles in the parking lot, which isn't particularly unusual. There's a shooting range nearby, and I usually just assume that they are using it to stay current in firearms training. Pistols are difficult to shoot well, without a frequency of practice which is far beyond any level of effort I could sustain.

Walking to the door, I heard a “f*****g cops” remark. Perhaps that was meant as an insult—I probably looked like law enforcement, what with the way I was dressed, having really short hair, etc. Whatever. But it was an unusual thing to hear out here. I glanced at the person who made the comment, formed my own conclusions, and went inside.

I noted a few guys in there wearing various mismatched bits of paramilitary gear (camouflage, black “Sheriff” t-shirts, various boot styles, a boony hat, firearms in evidence, etc.). I didn't find any of that disturbing, because I expected it.

I did my business, and left. I noted on exit that the person who made the comment (and the vehicle) was gone, and that I had not seen that person inside the store. Off to the house, and nothing weird to report.

Interlude


Every statement above is completely factual, and forensically useful. Not least because it provides a time-series of events, which is always important. Your mileage will vary with the effectiveness with which you teach the value of accurate reporting.

Future Posts


I regard, in general terms, local and regional government as
  1. occasionally annoying (why is doing this useful thing so difficult)
  2. occasionally useful (providing some service I use occasionally, periodically, or seasonally)
  3. enabling (maintaining existing infrastructure, and building new infrastructure)
  4. emergency (first-responder or disaster-response services)
Given the circumstances, a first-responder post pretty much wrote itself. But that maps to incident-response, and avoiding that in the first place is far more important. Also more elegant, more user-friendly, and far more powerful.





Wednesday, June 18, 2014

A Fractional Day in the Life


This morning (0630 or so), I was out letting the hose run onto the base of a birch tree that has an enormous climbing rose clambering through it. I'm on a well, so water is essentially free, and I often do things like this while I'm thinking about the problem de jour.

This was not obvious to the neighbor who walked by, and politely asked what I was up to. A hose doesn't make much noise, after all. From that neighbor's perspective, I was just leaning against the side of Old Scabrous, my 1990 Jeep. The conversation ran like this.

"Whatcha doing?"

"Working."

"Propping up Old Scabrous?"

"Thinking about entropy."

"WTF is that?"

<brief semi-coherent explanation, while trying to save state, and not lose the better part of an hour of work>

As a reward, I got that exasperated "I live next to a twisted alien mutant from the Forbidden Zone" look. It's all cool; my neighbor knows I am harmless, even if apparently somewhat deranged, and is a very nice person.

So, there you go. A Day in the Life. Well, a snapshot of 6:30 AM life, anyway. And yes, I had been thinking about this since roughly 5:30. I keep weird hours.

Monday, June 16, 2014

Why HR Cannot Hire Good Security People

There are a lot of posts that are more or less begging to be written; much of the behind-the-scenes things, such as consolidated notes, bookmarks, text fragments, etc., is done, and the post would be at least somewhat timely. In some cases, that might involve a flight of posts. Languages worth learning, from a security worker perspective, comes to mind. Embedded Lua interpreters, for instance, turn up frequently. Another Java post is definitely needed.

The list of potential language posts goes on for quite a bit, especially when you consider how broad a term 'security worker' is. It is entirely possible to devote an entire career to statistics, yet fall within plausible definitions of a 'security worker': consider risk analysis, breaking data annonymization, etc. R, various Python-based tools, etc. (all related to technical computing), would then become quite important.

I have attempted to get a grip on what a 'security worker' might be, hence what the qualifications might be, for several years. On at least one occasion, it was in response to an HR request for specific instructions regarding hiring a counterpart in a foreign country. This is a hard problem; to take a random example, the Law of Large Numbers is important in surprisingly many security fields, but it is obviously nowhere near being a useful universal selector.

What else goes wrong in HR, from an applicant's perspective? My top three contenders, on an on-going basis are

  • Requiring five years experience with something that has only existed for two years
  • Requiring experience with something which is completely irrelevant
  • Being driven by marketing fashion, not fundamentals

HR doesn't operate in a vacuum. Someone (likely an over-worked developer, sysadmin, or entry-level supervisor of either) provided those bogus requirements. The knock-on effects are that

  • The best candidates will likely never make it to an interview
  • If the person who defined bogus requirements is part of the interview team, defensiveness is likely to fail the best remaining candidates

The best candidates have now been weeded out. HR often takes the heat, through no fault of their own, while much Internet drama is conducted in the various technical cognoscenti fora. The evil HR director Catbert, made famous in the Dilbert comics, exists. I have run into a few, over the years. However, Catbert is the exception, not the rule.

That seemingly throw-away point above? "Being driven by marketing fashion, not fundamentals?" That is a whole topic in itself. It may be the greatest challenge facing the security industry today.










Thursday, June 12, 2014

Linux Shells Just Keep Bugging Me

A couple of months ago, Dan Farmer (who is definitely someone that technically-oriented security people should pay attention to) put up a one-liner to generate 128 bits of pseudo-randomness, via a shell.

Unfortunately, single quotes are showing up as back-ticks in that post, so cut-and-paste 'programmers' had a bit of debugging to do. Hopefully Blogger will do a bit better (update: yes it does):

dd if=/dev/urandom bs=16 count=1 2>/dev/null| hexdump |awk '{$1=""; printf("%s", $0)}' | sed 's/ //g'

My first reaction was horror; sed and awk are both Turing-complete programming languages, and a bit on the large size. However, large systems written in a shell will likely use both, in which case they will likely be resident in memory. Unless your system is swapping madly, in which case you have other problems. So, even running that code in a tight loop may not have as much effect as one might think.

There are things we might do to swap in lighter-weight utilities, and get more readable code as well:

dd if=/dev/urandom bs=16 count=1 2>/dev/null | hexdump | head -n 1 | cut -d ' ' -f 2- | tr -d ' '

In shells, each command executes in a sub-shell, and that is an expense. My version costs us two more sub-shells. So, is it a win? I have no clue, and getting a clue is not an easy thing to do in shells. Variants of this code fail to give valid results using either the bash builtin 'time', or /usr/bin/time. Putting it into a script, and timing that, does not really help.

It is complicated. Have a look at https://stackoverflow.com/questions/5014823/how-to-profile-a-bash-shell-script. Note that there is no mention of taking an average of many tests, which is fundamental.

Shell code is pretty much the last thing you should use to write anything, if you have security in mind. I've had to do it because managers demanded it. Probably because they read an article about POSIX, from ten or fifteen years ago. But the security argument has seldom worked in the past, so let's mount that profiling argument. It is entirely valid.

Shells are tremendously useful for things like the initial exploration of log files, and setting up execution environments*. Which means that knowing the native shell is important. And there are things I still need to look at; I've just installed the dash shell. But so far, my take is that if you are using a famously slow and error-prone tool to write production (vice exploratory) code, and have no good means of profiling that code, You Are Doing It Wrong.

file $(which firefox)
/usr/bin/firefox: Bourne-Again shell script, ASCII text executable