One thing I’ve noticed, over the years, is the habit of people blaming technology for the problems rather than taking a look at the processes behind the problem. A personal example A big example, for me, was when I was part of the Unix enterprise authentication team. The technology worked, and it worked well. It was resilient, reliable, fast. We literally turned off the infrastructure in one datacenter and all the clients correctly failed over to the next nearest one.
This isn’t my normal tech-ish posting; this is a more personal view at how Corporate America and tech startups and the like are abusing their workforce. I don’t mean the sort of abuse seen in the service industry (below minimum wages needing to be supplemented with tips; excessive overtime; all that stuff). I’m talking about white collar tech jobs. The sort of jobs I did; likely the sort of jobs you’re doing (if you’re reading this blog); office workers…
We all know what imposter syndrome is. We may all have suffered from it at some point. I know I did. We may even know, rationally, that this isn’t a sensible thing. One good representation of this was from David Whittaker Yet despite this whenever I started a new job I was always worried that I wasn’t the right person for it; that I’d fail to deliver.
Recently I wrote about how I got here without knowing what it was I wanted to do. That was a prelude to the other half of the equation; I may not know what I want, but I do know what I don’t want. At this moment in my life, I don’t to work. At all. I want to have the luxury to be able to lie in, to read a book, to stay up late hacking on some code or whatever…
One of the most annoying interview questions is “where do you see yourself in five years time?“. I hate it. I have no vision of the future like this. Hell, I barely know what I want to do tomorrow. I’m good at foreseeing the future, honest! So my first job, straight out of uni, was with a small Greek shipping company. I learned a lot there ‘cos I had to do it all.
Else-net there was a discussion on how “security” is generally seen as a blocker; they’re seen as gate keepers and people who just say “no”, or who may be focused on regulatory compliance and not actual security. Who needs Mordac, the Preventer Of Information Services when you have a security team?! The thing is, “security” isn’t a monolith, and it’s not a one way street. Many teams I’ve only really seen security from a megacorp perspective, both from the companies I’ve worked for and the people from other companies I’ve spoken with over the years.
I get email… What are your thoughts about making a career out of specialising in Unix? It seems like you’ve done quite well… Interesting question… Realise that I started doing this 30 years ago. At that time there was no Windows (Windows 1.0 was around the corner). We had DOS. Networking was mostly serial based; if you were (un)lucky you might have had Banyon Vines or Novell or some other proprietary network stack.
Every so often I get asked to do something that’s not related to my employer, or is stuff that results from my activities for my employer. Frequently this is some form of informal consulting/discussion. There was the cloud expo presentation. I’ve been on a couple of “Customer Advisory Boards” because of my container opinions (I have opinions; sometimes people want to listen to them). This time I was asked to look at a mobile email configuration.
One of the exciting parts of the “new world” of cloud is the ability to green field solutions. We don’t have the legacy requirements and so we’re free to do what we want. Or so the evangelists would have you believe. The past lingers on The reality is that many people are closer to a brown field environment. The organisation their team is embedded into has a tonne of reporting (“is your machine patched?
This is an odd post for me. I’m terrible as a manager. I’m terrible as a team leader. I think I’m good as a teacher and mentor, but that’s a different role. Lead by example, teach what I know, learn when I can. I’ve definitely not been in the military. And yet I’m about to write about effective leadership… or maybe bad leadership. Finally I get to see The Last Jedi.
“To summarise the summary of the summary; people are a problem” - Douglas Adams, The Restaurant At The End Of The Universe The above quote is one of my favourite jokes (I’ve used it in a previous post); it highlights how people can complicate any situation. We can try to avoid this by automating as much as possible but, at the end of the day, there’s always a human involved somewhere; even if it’s the team that manages the automation!
Unless you’ve been living in a cave for the past couple of months, you’ll have heard that Equifax, one of the ‘big three’ credit reporting agencies, suffered a massive breach leaking privileged data on over 143 million US people (and millions outside the US as well). The story went from bad to worse as the company completely failed to handle the response properly, with poor communication, staff giving out the URL to phishing sites, web site failures and the story that three executives sold millions of dollars of shares before the leak notification was made.
I’ve previous written about encryption and hashing and why things like customer passwords should never be encrypted. Sometimes, though, you need encryption because you need to get the raw data back. Now you can apply encryption at different layers. Some are easy; some are hard. What you need to be aware of, though, is what they protect against. There is no one-size-fits-all solution A standard app In a common scenario we may have an application that writes data to a database; that database persists data to disk.
Identity and Access Management (IAM) historically consists of the three A’s Authentication What acccount is being accessed? Authorization Is this account allowed access to this machine? Access Control What resources are you allowed to use? Companies spend a lot of time and effort on the Authentication side of the problem. Single signon solutions for web apps, Active Directory for servers (even Unix machines), OAuth for federated access to external resources, 2 Factor for privileged access… there’s a lot of solutions around and many companies know what they should be doing, here.
Over on Twitter, @TinkerSec live tweeted a pentest and created a moment thread of it. It’s fascinating reading, and well worth reading. Even non-technical people should be able to get something out of this. I like that it’s a form of insider attack (industrial espionage by a newly hired employee? disgruntled employee? vendor allowed unaccompanied access?) rather than an external attack. One of the things that typically comes out of an event like this is a series of action items.
One of the major threats that companies are concerned about is “insider threat”. According to some Data Breach Incident Response (DBIR) analyses, insider threat may be the 2nd or 3rd major reason for data loss. It’s interesting to note that the insider threat is way down in the actual number of incidents, but they count for a larger number of successful data loss incidents because the insider knows where the data is, may have legitimate access to the data, and may know the controls that need to be bypassed to exfiltrate it.
There is a temptation in computer security circles to aim for the perfect. After all, we know that if there is a hole then it will be found and will be exploited. So we tend to build (hopefully! ahem OpenSSL) secure products that will withstand attacks… and then fail at usability Let’s take a brief travel through… Unix naming services NIS In the long distant past (the 1980s), Sun Microsystems created a system called NIS (Network Information Services)1.
Sometimes we can learn a lot from nursery rhymes; I’ve previously shown how A Hole In My Bucket can teach us about understanding problems and how this can lead to security issues. The Itsy Bitsy Spider can also teach us… So what is the story of the spider? Spider starts to do something productive Event happens that destroys the progress Spider starts over to do something productive But what we don’t see, here, is the spider learning from the event.
In my spare time I’ve been playing on Unix StackExchange. And I’ve found the old song There’s a Hole In My Bucket going through my head. It’s a conversation between Henry and Liza; Henry has a problem and is asking Liza for help. In summary: H: There's a hole in my bucket L: Mend it! H: How? L: With straw. H: But it's too long L: So cut it H: How?
