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?