All Posts in “Solutions”

So Ya See Timmy

As promised I will now talk about containers vs micro services. UGH ok where to start … Maybe it’s best if I do this in a dialog I recently had. Customer will be C I will be M. Also incase you haven’t read these sorts of things before <> will indicate internal dialog or though in my brains.

C: “ I am looking at Docker or VMware Photon to manage a bunch of web sites deployed in containers.”

M: <Ok I thought.>

C: “The web sites are currently deployed and we want to migrate them off of a unix server that they are sitting on today.”

M: <Hmmm, ok weird but if they rebuilt them …. >

C: “We just need to get them off the box as is today”

M: <But but that’s not what containers ….. ok. >

Here is my problem I am no good at keeping my mouth shut, like no good at all. I keep repeating to myself, Mike just stay quiet and people won’t think you are an ass. But then I open my mouth and well words fall out. 

M: “No sir, that’s a bad use case for Docker or Photon. You see a container is great if you have an application and want to deploy multiples of it. Scale it out, not so great for existing web services, better if you were to rebuild them and need multiple instances”

C: “Right like we have a lot of web sites, plus containers provide isolation and security.”

I could actually feel my eye twitch a little here. You know like the eye lid and the side of my face. Maybe it was a stroke?

M: “No see if you wanted to move them off of their existing hardware, just a straight virtual migration would be good, or you could use a code release software to layer them onto a micro kernel vm. But for what it sounds like you want, containers would be tricky. You see you need to have a host OS arguments here can be made that, that OS can be virtualized or bare metal. Then you have your container technology, your containers, and some orchestration methodology that maps them together. Containers are way different than the virtual environments you are used to managing and deploying today.”

Ok so at this point the conversation trailed into other things, and I won’t bore you with those I am just going to use my imagination to finish this conversation as I believe it would have gone.

C: “Yes but I was saw at VMworld …”

M: “I am not saying that container strategies are wrong, nor that you shouldn’t invest time and energy into having one. Quite the contrary I think there is a place for containers in environments where application management is difficult and the concept of micro services isn’t possible to adopt. But containers while they do provide another layer of abstraction are not natively more secure. In fact containers provide the app dev or owner all the more control over the application they are packaging and deploying.”

C: “But it’s isolated so that means any vulnerabilities they expose in their container can’t impact my infrastructure.”

M: “Have you ever watched Lassie?”

C: “What?”

M: “Lassie you know the dog that always saved people?”

C: “ … Yes”

M: “At the end of ever episode Timmy, the boy who owned Lassie learned a lesson in the form of a speech that his dad gave him. South Park uses this in all of their episodes where Stan and Kyle reminisce on the lessons of the episode. We call this a ‘SoYaSeeTimmy’. The point is no one learns the lesson while they are going through the adventure, they learn after the fact.”

C: <blank stare>

M: “So you see Timmy, mind if I call you Timmy? Good. So you see Timmy, you surely can run your web services in a container, or believe your container is actually not going to impact or open you up to security vulnerabilities, but just like when you fell down the well while trying to walk across a board like a balance beam, and Lassie came a running barking, and spinning in circles to get me to follow her back to you, you will learn that just because you can doesn’t mean you should.”

If I am incorrect or you feel differently let’s discuss it, I am still learning and could use a conversation on this that isn’t in my head. 🙂

 

What can a vet teach us about IT?

One of my sisters is a veterinarian, she has a degree in animal husbandry. Her job is stressful and tough, both from a patient perspective as well as their owners. She loves animals and hates to see them abused or in pain. She is often confronted with owners who either don’t care or can’t afford to properly care for their pets. This leads to some trying to euthanize their pets for minor health issues because they never thought about the long term care costs.

Now before you assume that my next comment is saying we should look at human care the same way, please remember this is primarily an IT blog.

PetvCattle2Many of you have heard me or someone else expound on the Platforms of Applications that IDC laid out P1 through P3 apps, and the analogy of P2 & P3 apps being like pets and livestock. If not here is a quick synopsis (for those of you who are familiar please read ahead):

Platform 2 applications are the many of the X86 apps we run today, SharePoint, Exchange, SQL Server, Oracle, etc. These applications all require care and feeding, but if we want more from them then we need to grow them vertically. Meaning more app servers running the same applications and clusters or split resources. These sorts of application trade offs are fine and expected, and in fact the app owners tend to care for the apps as though they are part of their family, polishing the server bezels and spouting things like “Precious!” They are also the ones who are quick to blame infrastructure teams for their apps failings when service interruptions occur because redundancy is tied directly to the environment it sits on.

P3 apps are built in micro services, hopefully meaning the 12 Factor Manifesto was PetvCattle2followed, but here we find that the applications are groups of services that link together to create a mesh. Applications scale horizontally and single service failures do not impact the overall application availability. Here applications are more tied to the platform and code that creates them, and are far more flexible. *NOTE: This is not to be confused with containers. Micro Services != Containers

Application owners by and large don’t realize the impact or plan for the long term lifecycle of an application. More importantly application development teams don’t make those considerations either. This leads to conflicting views when application lifecycles are discussed. Much like an actual pet you have preventative care and maintenance to keep both you and the pet happy. Your Operations staff act as your Vet here and help to direct and mitigate any pain. With livestock you have the option to cull the herd, and eliminate bad or unsavory elements. Microservices act in the same way allowing you to kill services, perform continuous release cycles of code and change on the fly. Try doing a code update on SAP during working hours, I dare ya. The CMDB board would be on you faster than, me exiting to a Krispy Kreme when the Hot and Fresh sign blinks on.

This isn’t to say that all P2 apps are bad, or that all P3 apps are good. In fact there is debate around the Megalith vs Micro Service approach all over the interwebs. But it’s important to understand the difference.

Oh and containers … next post I promise.

How Ashley Madison Makes Security Sexy

Bringing Sexy Back to Security, ok maybe not back maybe making security sexy for the first time is more appropriate. Thanks to the recent Ashley Madison hack folks are actually equating sex and security more than ever. Thank goodness for that because security really needs to be viewed in a better light even if it is a red light.
Queue someone singing Roxanne.

While full details haven’t been exposed as to how Impact Team were able to so easily crack into Ashley Madison’s network and PWN them harder than a teenage Modern Warfare team playing against a group of kindergarteners. What was explained was that once they were in there was no security internally everything was easily exposed. Evidentially once in the hackers could VPN to every server in the environment with user name root and password of Pass1234. That’s the kind of password an idiot would have on their luggage.

If the importance of this last bit doesn’t immediately jump out at you it’s not that the breach happened, because they too often do. It’s that people suck at security. People are our biggest vulnerability in any environment.

I have had so many conversations with folks regarding security policies and whether they actually make organizations more secure. Odds are no, the policies most likely do not secure the environment. Instead the policies act as a way to set guardrails for users. This helps to curb behavior and drives users in the direction the company wants them to go. It’s like herding cats.

The same who argue against using ridiculous policies, and believe me I have been privy to some really bad security policies, say that what we really need is better training for the employees. Here is where I call BS, SUPER DUPER MAJOR BS. How many of you have to do quarterly or annual training? How many of you then actually do it vs. hit play on some video recording and go to lunch? Hell I have been guilty of that when the training doesn’t actually apply to me but I have to do it anyway. Training doesn’t help either if a breach actually happens or there are regulatory violations that result in fines either, “Oh but we trained our people” doesn’t really get you out of the fines.

So how then does anyone operate securely, is it just replacing the humans with robots?

Look I am not trying to stand on a soapbox and say that I have the answers, what I am saying is security is about risk management. You manage risk in three ways, accept it, mitigate it, or avoid it. Accepting risk means that you get that there is an issue but since nothing can be done you take the risk anyway because the reward outweighs the potential problems. Mitigation means you take as many precautions as possible to eliminate the risk, it’s not fool proof and there will still be breaches but you do your due diligence to protect yourself. Avoidance is a matter of assessing the risk and determining the reward doesn’t outweigh the risks and thus you move away from the risk.

The Ashley Madison hack is hilarious in the irony of the situation because not only was the very business of it a giant risk (cheating on your spouse), but it appears little to no risk assessment was done either from the regulatory controls of PII or the infrastructure for that matter. Step away from the business issues and the lack of security awareness and over to the user side and you see thousands of government employees signed up for the service with their government email addresses. Hello, McFly! What are they thinking how about a little OpSec and the fact that there are free email services all over the interwebs? These people just accepted the risk and pressed on.

Despite all of this stupidity the search for sex led these poor ignorant souls to a poorly managed risk accepting service for what should have been a risk adverse user population. Hopefully now the sexiness of how this could have been avoided can be applied and more companies and users can understand why security and risk management matter so much.