Whenever a new “critical” vulnerability is found, the cry goes out across the land; Patch! Patch! Patch! Whenever a major incident is caused by known vulnerabilities the question is always Why didn’t they patch? We’ve known about this for months! They should have patched! Sometimes this is valid criticism, and learning why the organisation wasn’t patched can lead to some insights into failure modes.
Unless you’ve been living under a rock, you may have heard of two panic panic panic bugs, known as Meltdown and Spectre. People are panicking about them because they are CPU level issues that may impact almost every modern CPU around. Meltdown is Intel specific, but Spectre affects Intel, AMD, and potentially others (Redhat claims POWER and zSeries is impacted). What is the problem? In short, modern CPUs may execute instructions out of order, especially when the order doesn’t matter.
“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!
It’s a fairly common design in enterprise networks; a three tier network architecture, with firewalls between the tiers. Typically these layers are split up with variations of the following names: Presentation Layer (Web) Application Layer (App) Data (or storage) Layer (Data) Typically you may have additional tooling in front of each layer; e.g a load balancer, a web application firewall, data loss protection tools, intrusion detection tools, database activity monitoring…
A few weeks back I completed my Arduino hack for a digital safe. What was missing, however, was the software to drive it. One requirement I had was to let it work with password managers. I also had the idea that maybe remote access (e.g. control the safe while away from home, to grant a guest access) might be useful. This kinda meant it’d be easiest to do as a web site, with internet connections forwarded via the router.
A couple of weeks ago I was asked a question around the disposal of SSDs. The question went along the lines of “In the old days we could just overwrite the disk many times (eg with DBAN). What should we do, now, with SSDs?” Recently, a bunch of Infineon TPMs were found to have a flaw that generated weak RSA keys. This could have lots of impact, including Bitlocker disk encryption.
For a number of years I had one of these cheap electronic safes. They allow for a combination to be set. I bought this one from Harbor Freight in 2004: This post isn’t about that safe though. About 10 years later the safe started to stop working; the control panel stop responding, it made horrible noises… Fortunately anger lifting and dropping the safe got it working again to open the door.
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 was asked an interesting question: I am about to investigate Docker. We are moving to AWS too. So in your opinion, should I put energy on EC2 Container services or should I put my energy on Docker on EC2? Which is better ? I find this type of question interesting because there’s not, really, a “one size fits all” answer. It depends on your use cases.
In previous posts I’ve gone into some detail around how Docker works, and some of the ways we can use and configure it. These have been aimed at technologists who want to use Docker, and for security staff who want to control it. It was pointed out to me that this doesn’t really help leadership teams. They’re getting shouted at; “We need Docker! We need Docker!”. They don’t have the time (and possibly not the skills) to delve into the low levels the way I have.
