Three steps to stop ransomware in the business

Can ransomware be stopped?  Probably not. But there are some things that can be done to make a business (your business) less of a target.  These steps are not new and you probably have already heard of them.  However, based upon my experience building and protecting networks, if a business can  implement at least two of these three steps, then when a ransomware attack does hit, the business will be better able to survive.

Step 1 - Patch

Patch you systems.  Patch all of your systems.  That is easy to write... sometime not so easy to do.  When I read about how business were compromised I always read that the business was hit by a new zero-day exploit.  Right!?  Wrong.  When I read the articles and look for the initial compromise, it is usually that the attacker got their first foothold from a system that was not patched.  HVAC systems, Point of sale systems, security video systems, user workstations.  All these systems run software.  All that software has bugs and many, many, many of the bugs are already know.  In fact there are databases of bugs.  The operating system you are most likely reading this on now (Microsoft Windows) has and entire patch release process known across the industry as "Patch Tuesday".  Here Microsoft will release a series of new patches for critical (and not so critical) vulnerabilities within Microsoft products.  Are you patching all your Windows systems once a month?  If you cannot confidently say 'YES' then you are not.  And if you can confidently say 'YES'... good job... and are you sure?

Whatever systems exist in the business they need to be patched regularly.  If there isn't a patching schedule that is followed at least monthly then the business is at risk.  I've been in companies where there is "this one system" that is critical to the business or "the person who know about this system has left the company".  Does one or both of those scenarios fits sound familiar?  In the first case, if the system is really critical to the business, a proper DR/BC plan needs to be in place.  And if there is already a DR/BC plan, then exercise that plan monthly.  Have a "failover event" to the DR environment and run off of the DR environment for a month, patch the Prod environment then next month fail back.  This process, while not easy at first, will ultimately help prepare a business when there is a disaster (such as ransomware).  For the second case, things are not quite as simple.  If no one at the business knows about the system, then someone needs to be hired to a) figure it out, b) document the system/software/process and c) develop a plan to get this system ready for DR/BC.  This will not be ease and will cost money... but it will cost a lot less than a ransomware infection and cleanup.

Extra Credit

Does the business have the ability / automation that will allow systems (PC, network, storage, application) to be rebuilt from known clean media/images.

Step 2 - Segmentation

Network Segmentation?... Data Segmentation?... Application Segmentation?  Which one? Where do I start?

Answers in order: Yes. All.  From the beginning. :)

It begins with the network...

While a business can begin the segmentation journey anywhere, most business find the easiest to start with the network.  One because it is usually the least understood and second virtualization and segmentation has been apart of networks for 20+ years now.

The best place to start segmentation on the network is between the data and the users.  Yep.  Let that sink in for a second.  Put a firewall between the datacenter and the users of the data.  What about single points of failure of the firewalls?  What about throughput?  I have a 10G data center... there is no way that the firewalls can keep up!  Maybe.  Answer this question "How quickly do you want to loose your data?"  Remember this is just the first step for network segmentation.  If data cannot stop be stopped from leaving the business does anything else matter?

Second step for network segmentation is to VLAN and isolate each class of system from one another.  A system class is made up of like functions.  An example of these functions that I commonly see are: building control; printers / conference room; user workstations; vendor/provider systems and VoIP (though VoIP is becoming less and less of an issue).  This separation can be done with simple VLANs + ACL's, or this can be done with firewalls and dynamic endpoint identification.  In either case, access to and from the class of systems should be defined as to what is expected.  For example:

A simple table like this can help define what traffic is expected between classes.  Anything else can be blocked.  Then, when an event occurs, you can know what classes were possibly impacted and what classes are safe.

Extra Credit

Deploy NAC with dACL's or use static port based ACL's to limit or prevent cross communication within a segment.  Is there any reason that printer need to communicate with each other?  How about user machines?

Data Segmentation

Let me guess... Your business data is kept in a ... database!  Right?!  How did I know? Psychic?

What is business data?  Customer information?  Intellectual property ? Payroll data?  All of the above.  Does all the data exist in the same database? If so why?  Does it need to?  The people who have access to some of this data, should they have access to all of the data?  If the answer is 'No' to any of these questions then separating this data into different servers and different databases would be the first step.  Once this is done, user access to different databases can be differentiated and separated.  The database servers themselves can even be isolated on different VLANs behind the data center firewall further protecting them from one another.

Application Segmentation

Just like data segmentation, applications that do not need to communicate with each other should be separated.  Can the application be rebuilt from media or a CI/CD pipeline?  How quickly can the applications be rebuilt?  Since the data has been segmented and locked down the application frontends are the most likely to be attacked.  Especially if these frontends are on the Internet.  Being able to "throw away" the frontend server and start with a known good server is critical to recovering from a compromise.  This may be easier to do in cloud environments where administration is just an API away, but being able to flatten an on-prem system and have it up and running in minutes or hours can make the difference between remaining in business or not.

Step 3 - Get rid of Microsoft Windows

This is the most controversial recommendation and possibly the hardest one to wrap ones mind around.  There was computing before Windows and there is computing without Windows.

Am I just a Microsoft hater?  Apple fanboy?  Why do I write this?

No. No. And I'll tell you.

There are 3 reasons I say ditch Microsoft.  First is that the vast majority of compromises are against Microsoft systems.  I acknowledge that Microsoft has the vast majority of the OS market, but that is irrelevant.  Having a Microsoft system in your business makes your business a target.  But you are patching every month so you'll be OK. Good Luck.  

Second, Microsoft continues to maintain compatibility with all previous versions of Windows. All the way back to Windows 3.1.  This backwards compatibility, while "protecting investments" in ancient software, also make the attack surface of the Windows OS larger than any company can realistically protect.  In addition the backwards compatibility means that any bug within an API must be maintained, lest a program stop working.

Third, Microsoft doesn't care about your business or your data.  Yes, I am personifying a company here which is dangerous to do.  However, a recent discussion/rant by Steve Gibson on the Security Now podcast #832 said it better than I ever can. See page 9 of the show notes. (Really, read his discussion on this topic then come back.  I'll wait.)

So what would a non-Microsoft company look like?  Is that even possible? I think so.

User machines would run a more secure operating system.  There are many Linux and BSD variants available today.  An since the majority of applications and services are now web based the only requirement of these operating systems is a web browser like Firefox or Chromium (Google's opensource version of Chrome)

Servers would run Linux or BSD.  There are probably already Linux servers running in the business today.  And most of the major storage systems are based upon BSD or Linux with a fancy storage frontend.

LDAP User directories can be deployed on-prem or with a SaaS offering to support user accounts and application login via SAML or OAUTH.

Any critical business processes/systems that cannot survive without Windows can be isolated in the datacenter away from all other systems.  (See step 2)

Conclusion

Even if implemented perfectly, the steps cannot 100% guarantee that a business will escape a ransomware infection.  However each step will reduce the impact of a ransomware infection and can make it harder for the ransomware actors to compromise the business in the first place.

Will it be easy?  No.  Will it be worth it?  Absolutely!