Keeping track of servers in a large organization is a daunting task, and one which many organizations don’t do well – sometimes with grave consequences. There are lots of reasons why systems get “lost”. If you can keep track of your servers, you can decrease your chances of an intruder getting in by 30%. In this article, we’ll look at what happens when you lose servers, and some of the ways people lose servers.
Although Linux systems are by-and-large more secure than many other systems, they still need to be administered intelligently. Stupid configurations often lead to unfortunate results. According to Akamai: “As the number of Linux environments has grown, the potential opportunity and rewards for criminals has also grown”. As part of the IT best practices project, I’ve recently added a rule which disallows password authentication over ssh. This blog post explains this, and why people who manage Linux systems should care.
The three pillars of IT security are confidentiality, integrity, and availability. Most of the press coverage is all about confidentiality – at least until we have an airline or two or three have trouble with availability ;-). Of course, availability is also a key dimension of server management with significant operational dimensions. Those of you who know me, know I have a deep expertise in availability. Unsurprisingly, in this post, I’m going to concentrate on availability – and the necessity of monitoring everything, and knowing that you’re monitoring everything.
Last weekend, I had the honor of giving the opening keynote on Friday at the 2015 Ohio LinuxFest and a session presentation on the Assimilation project the next day. Both talks were very well-received, but the reception the Assimilation project talk received from the standing-room audience was extraordinary. So it seems good to give a summary of the talk and why I think they resonated so strongly to it.
In lots of ways, the most dangerous attack any enterprise sustains comes one way or another through “social engineering”. The reason why this works so well is that it’s mainly an application of social skills – the kind people use everyday to work together and get things done every day. Like any tool, skill, or weapon, it can be used for good or for evil.
This came to mind when I was recounting a story from years ago to my friend Emily Ratliff – and she laughed and said “that’s social engineering” – and I suppose she’s right. So this week, I’ll tell the story of my tiny bit of social engineering that snagged me a cool book.
Last week I had an epiphany about the Assimilation software which led me to go into total full-on development mode. This was fine except for one thing – I had a trip to make to Beaver Creek resort for an excellent Top 6 business retreat lead by Tommi Wolfe – and I wasn’t done with the development I’d been obsessed with when I needed to go.
It turns out that being in total full-on development mode isn’t terribly compatible with travel or more mundane things – like parking a car in a parking garage. This blog entry is about the comedy of errors that happened when I tried to do that. After it was over, it was pretty funny and all ended well in every respect.
Over time I’ve had a number of people ask me why I wrote the Assimilation System Management Suite. I wrote this blog post to answer that question. Since I’m a techie at heart, this is a story told through a technical lens.
In a previous blog post, I outlined the characteristics of a CMDB for the DevOps era. In this post I give my somewhat-biased view of how well the Assimilation System Management Suite CMDB meets those needs.
CMDBs have a bad reputation in many circles. They are seen as expensive, have been associated with costly IT failures, high overhead clumsy processes, are reviled by some, and are thought to be incompatible with DevOps. In my opinion, they don’t have to be that way. The idea of a database that knows everything about your IT environment, replaces manual documentation and springboards automation is incredibly attractive. What would a CMDB look like that is easy to install, and easier to maintain – one that followed the DevOps mantra of automating everything? This post explores that question.
Today’s blog post is about the imperative, absolute necessity for automation in cybersecurity. Those of you who read this blog regularly will note that this has been the theme for a while – with three recent articles about automation and one on the IT best practices project (which is all about automation). In this article we talk about why to automate cybersecurity, what to automate and how to automate cybersecurity.
