Security mindsets of MSPs
-
@Carnival-Boy said:
I don't keep passwords listed in Word documents. I don't think they should either.
In this type of situation, where do you keep the passwords for all of your different clients for all of their different systems?
Personally I don't mind if they use Word/Excel to store these. The best I can hope for is that they are being stored in a safe manor - i.e. not everyone in their company has access to the files, even better if stored on encrypted drives, etc.
-
@Dashrender said:
@JaredBusch said:
Also realize that email may not be as insecure as you think.
Before you went off the handle and wasted all that time changing passwords, did you check if the email had been sent via TLS?
Not very many SMTP servers use TLS by default (even if both sides have it available).
Office 365 does.
-
This is very interesting to me. As a smaller fish in the IT biz I am trying to do right with security and all of you have a different slant on passwords in emails and in documents. My goal was to password protect my SharePoint OneNote page with my clients User/Pass list. For my web/email hosting clients, I was going to delete all passwords I had on file and require them to create new ones if they forget. I still would have to check how secure my services desks were for sending out passwords for users who request the password reset. Seems like you really can't secure it all, or easily. And how many roadblocks do we want to put in the way of people wanting to get work done?
-
@Carnival-Boy said:
@scottalanmiller said:
@Carnival-Boy said:
I trust them to work on my systems. I don't trust them to prevent credentials from getting into the wrong hands as a result of their sloppy security procedures.
You can't differentiate. Distill what you wrote to "I don't trust them."
So, you can't use them. That's your answer there.
I don't trust anyone external. But I have to take a holiday.
Then you have a gap. You have to choose. Trust or don't take a holiday.
What makes the external nature of someone seem distrustful to you but not someone internal? It's the same pool if humans.
-
@Dashrender said:
@JaredBusch said:
Also realize that email may not be as insecure as you think.
Before you went off the handle and wasted all that time changing passwords, did you check if the email had been sent via TLS?
Not very many SMTP servers use TLS by default (even if both sides have it available).
Business class ones all do. Maybe those insecure "on premise" people have that problem still but it has been gone for the hosted industry for a long time
-
@Dashrender said:
@Carnival-Boy said:
I don't keep passwords listed in Word documents. I don't think they should either.
In this type of situation, where do you keep the passwords for all of your different clients for all of their different systems?
Personally I don't mind if they use Word/Excel to store these. The best I can hope for is that they are being stored in a safe manor - i.e. not everyone in their company has access to the files, even better if stored on encrypted drives, etc.
Depends on a lot if factors. This one no MSP should disclose in too much detail for obvious security reasons.
We can say we do a number of things including varying by client, layers of access control, key based access, access control to lists, etc. We have talked about building a custom break glass style system.
High security passwords are kept in a secure system inside a secure system.
Highest security are "in brain" only with a physical break glass in case of bus scenario.
-
@scottalanmiller said:
@Dashrender said:
@JaredBusch said:
Also realize that email may not be as insecure as you think.
Before you went off the handle and wasted all that time changing passwords, did you check if the email had been sent via TLS?
Not very many SMTP servers use TLS by default (even if both sides have it available).
Business class ones all do. Maybe those insecure "on premise" people have that problem still but it has been gone for the hosted industry for a long time
What do you mean by 'a long time'? Google only went to TLS in light of the revelations of the NSA spying on people. Before that they didn't have TLS enabled by default for SMTP delivery. Hell, they didn't even have encryption between their own datacenters (though.. I will give them a break on that since they believed that those pipes were private and not being spied on through the carrier).
-
One major thing that we do for. Lot if access is limit normal access to coming in through secure central access point and access is then via a key, rather than a password. It's small but it limits problems while making access easier to win at the security vs. usability war.
-
@scottalanmiller said:
What makes the external nature of someone seem distrustful to you but not someone internal? It's the same pool if humans.
Nothing at all. It just so happens that there are a couple of people at work that I would trust with my life. I don't have that kind of relationship with any of my external partners. I'd like to and maybe someday I will.
I'd trust you
I just don't trust them.Another example. Our ERP vendor. Biggish company. Part of Infor. They decide to publish all their support calls on their customer portal as part of a knowledge base. So now I can search other companies support calls to solve my own problems. It's great. But one day, I find a support call that lists the modem number, username and password to remotely access another company's Unix system. They've basically published this information to all their clients around the world.
My point is, some, but obviously not all, IT companies fail to take their client's security seriously and I think they should know better. This was definitely the case when I was a programmer for a software house - I had no idea about security and no-one ever told me.
-
@Carnival-Boy in that particular case, I would guess that that was an accident. Service providers and vendors do have to be careful as their accident "blast radius" is often larger than in house IT is. But to be fair, we see internal IT people accidentally post rather a bit of stuff when looking for help online or using KB systems that are hosted publicly or whatever.
Publishing tickets without an air gap process, though, that is pretty idiotic I must admit.
