It never got old. Phishing+macros+lateral movement are still a very significant vector. The industry exacerbates this by running with the feel-good "don't blame the user!" mantra.

At some point you really do need to give up on your fancy canaries, gateway and host IDS, perimeter blinky boxes, threat intelligence feeds, endpoint protection products, etc, and just start firing those in your employ who willfully and joyously thumb their noses at basic security hygiene.

The problem is that most endpoint protection is a joke. Companies buy enormously expensive enterprise endpoint protection systems with big dashboards to tell them if their endpoints are protected, and one of two things happens: either the dashboard falsely reports that everything is up to date (and you have Outlook 2007 running in the wild) or the dashboard reports that you have 4,394,665 security issues that need fixing, and not only does nobody have a clue where to get started, the minute they move laterally in the org to try to update anything, users scream DON'T YOU DARE TOUCH THAT!

You can't fix your security posture until you fix your update culture.

> and just start firing those in your employ who willfully and joyously thumb their noses at basic security hygiene.

Until it's your top salesperson who 2x'd the quarterly revenue target... I'd like to live in a world where everyone knew basic security hygiene, but we have to teach it first, not punish.

Considering the current lessons are "if you don't use frequently changed garbage passwords with a mix of cased characters, numbers, and special characters you aren't secure" and "...but we'll allow you to reset the lockout because you can never remember your password using this self-service reset guarded by unchanging common answers to facebook quizzes", I'd say the solutions is ( Find the right thing to teach > teach it > expect it).

But then it can be over emphasized, and no one in your organization trusts any links or attachments because of phishing. Then it all becomes a horrible mess of skype/slack IMs with the actual links to Sharefile or Dropbox shares. Then you wave goodbye to async communication because everytime someone sends you a hyperlink they _absolutely need_ to know if you were able to get the file...

I have worked at financial companies where they get it right, and it is not a problem. Having crappy infrastructure and procedures is never an excuse for poor security.

well if he/she is such a fantastic earner they should be held personally liable for the banks losses stemming from their reckless conduct (clicking on email links or opening strange documents)

The power in corporations will pretty much always lie with profit centers (i.e. sales) over cost centers (i.e. security). I'd doubt that almost any company will be able to overcome that. Better to focus on mitigation of risks than fight political battles that you're not going to win as an infosec team IMHO.

If we're going to start firing people, first on my chopping block would be IT staff who implement security theater policies which go against NIST recommendations (like forced rotation of passwords every x days) and create security hygiene problems as side effects.

Unfortunately PCI compliance requires rotating passwords last time I checked. : \

No. You are free to reference nist and use a compensating control for that. No more pw changes :) Source: QSA

I guess I was under the impression that compensating controls don't really let you question the efficacy of the point of the original requirement, but instead "we're meeting the requirement in this other way"?

That's correct :(

> 8.2.4 Change user > passwords/passphrases at least once > every 90 days.

and then you get Password1990!!!!!!

Train the employees by sending fake Phishing attempts and then letting them know when they have clicked on them. Do this regularly.

The company I work for (in the utility industry) does this regularly and there are disciplinary actions for falling for the attack

The consequences range in severity based on the number of times an employee is caught over a 12 month period, or if, as part of the attack, the employee enters their credentials on the webpage linked in the email (a big no-no). They range from: a meeting with your manager to discuss, a requirement to park outside the security gate and walk in for at least 2 weeks, to your vacation accrual rate being reduced, all the way to unpaid suspension or termination with 4 failures in 12 months.

Of course as part of the on-boarding process the company provides pretty extensive training on how to spot a phishing attempt but some attacks can still get a large portion of our company.

The downside is now some employees who have been burned before are terrified of opening any external emails. This ironically resulted in an exceptionally low participation rate in our company's annual employee engagement survey conducted by, you guessed it, an external party.

My employer does this. Some people laugh about falling for every single one.

My employer does this as well. Even though I have been on the internet since the early 1990s, I still fell for one. There is just no way around it, if you process 300 emails a day you are going to slip once or twice. The human brain just works that way.

I think they have other mitigation strategies. Like probably quietly installing extra scanners on the email of the most "problematic" people who open anything and forward chain letters constantly.

I worked somewhere where we received a yearly Christmas bonus of some maximum amount reduced by various factors. Maybe the threat of loosing 10% of some yearly bonus for: "fails to meet security standards" would work well as a deterrent.

or use those physical devices that google hands out as well as training.

The issue at hand is the faulty Windows security model. Users have been trained to give full admin rights to anything that asks.

"Users" probably shouldn't have that option. When I have to be responsible for Windoze boxes, no one gets admin except myself.

Let he who is without sin initiate the first termination process with HR.

Seems to me in 2018 you shouldn't be receiving Word Docs as email attachments from unknown/unauthenticated senders.

In ancient times .exe were banned outright, and I have customers who also ban .zip. And a Word Doc with embedded macro is in effect an executable.

Lots of supposedly known senders that are actually hostile actors, some account takeovers, and there are many external facing people who expect to receive word docs from unknown people.

Accounts payable, for example, gets lots of these things as an expected part of the workflow, as does legal, and various parts of management.

PDFs have had problems of their own.

Many of the people that you most want to secure are the same people who need to be exposed to the outside world. CEO and CFO HAVE to deal with random people, as it's the job, but they are the most dangerous. If someone needs a 5 step verification process that takes days to communicate with your CEO, then you are not going to get may new clients or investors.

Yep. And what about the most obvious? HR. Resumes, cover letters, reference material, etc. Many places don't subscribe to the evil ATS or taleo parser tools and casually open whatever is sent to them with a familiar icon or extension as attachment.

These people need to be receiving Word Docs with macros and need to open those docs executing macros by default, from unknown/unauthenticated people? That doesn't make much sense to me. I see automated tasks as being internal. Receiving automated tasks from random people and executed by default seems like asking for trouble.

You dont understand. Everyone has all Macros enabled by default because Bob down the hall wrote an Excel macro that lets us plug numbers in our spreadsheet from the mainframe in 5 seconds instead of typing them for 20 minutes.

Everyone knows that to get the Macro to work, step one is to enable all macros.

We could reduce our risk a lot using a combo of technology that isolates executions to certain deprivileged memory ranges with tech that blocks code injections in general. Think a separation kernel running a desktop OS in one partition and in another a PDF viewer written in Rust. The general tech for stuff like that was being sold commercially far back as 2005, minus Rust of course. They did have Ada runtimes, though. The NSA and military ended up retiring the concept because there was too much complexity in PC hardware they thought would lead to attacks bypassing the VM boundaries. They did.

The old approach, which I used, was to use a mix of desktop and embedded boards physically separated with a KVM switch plus controlled, sharing mechanism. Just keep the untrustworthy stuff on their own machines. It's klunky but a greater chance of working securely.

Would it be possible to simply serve employees a hardened email VM on demand which included editing and composition utilities (office, Adobe)? I envision something that could be destroyed after each use to prevent persistence and could be put on a VLAN which included only the email server and specific internal services if need be to make pivoting difficult.

That's what I was talking about with VM risk, though. You're right back to it. Even the most secure VM will have the hardware and firmware in its attack surface. Those are getting tons of attention right now. It will reduce the number of times you get breached with associated damage. It's not as secure as physical separation, though.

There is something similar on the market called Bromium. It spawns micro VMs for some filetypes so that possible code execution is contained within the micro VM. Still haven't tested it.

https://www.bromium.com/