Implementing Corporate Email

[Unplugged]

So the company I work for decided to implement a corporate email next week, We will have a seminar about the policies concerning the Do's and Don'ts when using the corporate email

I also plan to launch a social engineering exercises to know whether they learned to use our corporate email or not

also to know if where are vulnerable to such attacks.

I just wanted to know your opinions if I'm on the right track or launching a social engineering attack for these kind of thing are a total waste of time and resources

I work for a small to medium size bank and we are currently using our personal mail for transactions.

[cooper]

I work for a small to medium size bank and we are currently using our personal mail for transactions.

I shouldn't be surprised since I did some work for a dutch top-3 bank once and... well let's just say I'm happy not to be banking with them.

Can't find any reason why you shouldn't test the workforce to see if they adhere to the policy. Since it's a completely new thing you'll probably find in this process the ways by which the workers are trying to circumvent the policy and why, allowing you to tune your policy to the day-to-day reality where needed, and to implement processes that verify the following of the policy when unwanted.

With any new policy, if you have one big meeting where the policy is explained and maybe a hand-out for the workers about the new status quo, what you'll really end up with is a workforce that keeps on doing things the way they used to, with one more piece of paper tucked away in their desk somewhere (if you're lucky). Change takes time and you should give it that. So have the meeting. Give the handout. Ask for feedback on the new process (specifically asking for areas of improvement they may have spotted) maybe a week after and if nobody gives any you either did an amazing job or not a single fuck was given and nothing has changed. Inform the workers about the feedback you've gotten and what you plan to do with it (and keep them posted on its progress). About a month after that sporadically do your social engineering thing to see if specific worker bees are really adhering to the policy.

You may need more than 1 meeting and a location on the intranet where you can store the document aswell in case someone 'loses' their handout copy.

The main thing to remember about the policy is that the workforce *HATES* that shit with a passion. What you're effectively doing to them is getting in the way of them doing their job. No, I know you're not, but that's how they will see it. Approach it from their perspective and make sure they understand why it's in their interest to do things the correct way. What the real dangers are of retaining the old process and how what you're now doing not only mitigates those dangers, but makes it so much easier for them to do what they used to be doing - you're not getting in their way, you're letting them do things more efficient. If you can do that you'll find that people will be a LOT more willing to accept the policy.

As a simple anecdote, at my work right now the security hounds are pushing to move our test server away from our local dev lan to a remotely hosted location because if a plane were to crash into the building the server would be destroyed. While there might be an actual chance of this happening, why does that mean that the latency of this very, VERY busy server should go up at least tenfold, impacting our daily work negatively in a very big way? Why can't they include the server in the nightly backup round (answer: because it's not officially hosted... insert suggestive hand motion)? Being the crafty critters that we are, we still use the same server but have configured it to upload our changes nightly to the main, remotely hosted server or whenever someone who needs the latest version of our stuff complains. This is the shit you're up against.

[Unplugged]

Thank you very very much for your response. I noted of the problems you stated because I would most probably encounter them.

[Mampt0n]

Saw an excellent talk on this topic the other day which I would copy closely

As Cooper says, the important thing is to play carrot, not stick. You should be continually encouraging and helpful rather than just bemoan the people who will always click the link because the subject says "free".

[Unplugged]

That's exactly what my plan is. thanks for posting that's really a great help

[Urieal]

Unplugged - Look into PhishMe - Great Product, encouraging, and really does help cut down on problems! Partner winning departments with gift cards / lunch / pizza / whatever and I assure you will see rapid improvement.

[preeper.peter]

One other thing you will need is managment who will back you and any policies up. One of the problems we have had with corporate email is not technology change, its changing human behaviour. Including ones who ignore what the IT/Security/Tech part of the organization instructs them to do. Especially if there is a culture of letting certain ones to circumvent the policies because they are a "good guy."

Good luck, the testing out the social engineering is the usual way to find weakenesses in the chain/departments.

[cooper]

In certain environments, like the bank in his case and healthcare in my case, security has the luck of being the starting point for pretty much everything. There's not much "we'll just wing it" going on here.

It's either safe, or it will be with the next (patch)release which will be in the fairly near future, you're going to have to specify a date here and now and you're going to make that deadline - no ifs, buts or any of that.

In environments where IT is more something to manage the periphery of the business, it's a much harder sell.

[badbass]

That video is cool