If I dedicate one computer to answering emails, and turn network discovery off, will that help protect the rest of my network from malware?

Question

My boss is very concerned about malware. He has heard that malware usually comes in via email attachments, and so he wants me to set up a computer specifically for that task and isolate it somehow. Is this a practical idea? If so, what steps should I take to isolate the computer? Would turning network discovery off be enough? Would I need to set it up on a separate network entirely? What else do I need to consider?

Answer 1

While I appreciate your boss' interest in improving security, this approach is not practical. The negative impact to productivity of having to use a separate computer just for email is not warranted. Anyone who has had to work with a separate laptop for corporate network access can attest to the frustration and wasted time.

Security controls should always be designed around usability and minimal impact to the business. Every time you slow down people's work for the sake of a security control, you cost the business money. The goal of good organisational security is to lower risk to an acceptable level without excessively impacting the operation of the business. Making good judgement calls in this area involves identifying the risks and gaps, coming up with controls that manage those risks without disproportionately impeding business processes, and consulting with the users throughout the process.

Given the context here, it sounds like your organisation should build a security program. The basic steps are:

• Training and awareness
• Asset management
• Patching & basic security hygiene
• Hardening security policies
• Incident response

There are many guides for these types of things online, and I recommend you search for some. You could also look into hiring a security company or consultant to help build a security program. As a starting point, I'll describe the basics of each of the points above.

Training and awareness is about making your employees aware of the tricks attackers might use against you. This includes things like spotting phishing emails, not plugging in USB sticks they found in the parking lot, not opening attachments from sources they don't recognise, spotting tricks like double file extensions (e.g. .docx.bat), etc., double-checking with someone in person when unexpected requests are made (e.g. the "CEO" emailing finance and asking them to buy gift cards), and what to do in the case that something is suspicious. Ensure that your users go through security policy training that covers this stuff, and test them afterwards. You use online services to run mock phishing attacks against your business, and use the results to gauge the effectiveness of your training.

Asset management is a critical first step in a security program. If you don't know what you have on your network, you can't know whether or not it is secure, let alone take steps to secure it. An asset inventory can be as simple as an Excel spreadsheet, but there are software solutions specifically designed for this kind of thing that can make the job a lot easier. Your asset management information should be able to tell you things like how many devices are on the network, what type of device they are, who they belong to, what their purpose is, what type of data is on there and how sensitive it is, what the systems' IPs are, when they were last patched, and other information such as that. This information is invaluable for all aspects of running a security program.

Patching is what it sounds like. Other than someone running a malicious executable, the most common infection vector is through unpatched software. Ensuring that operating systems and software are kept updated, with patches applied in a timely fashion, helps a lot. The most important pieces of software to keep patched, aside from the OS itself, are tools that deal with outside files or communications. This means web browsers, Microsoft Office, Outlook, Adobe Reader, Skype, Teams, Slack, etc. - many of these can be centrally managed in a Windows domain, allowing you to ensure that patches are quickly applied. This should also be applied to domain controllers and any other internal infrastructure.

Basic security hygiene is about bringing your systems and policies up to a baseline level of security. This includes not giving users admin access on their computers, having Windows Firewall (or the equivalent on macOS/Linux) enabled, having anti-virus (Windows Defender is fine) enabled and kept up to date, setting a reasonable password policy (note: password cycling is no longer recommended), avoiding the use of domain administrator accounts for day-to-day work that does not require it, limiting the privileges of accounts, controlling who has access to file shares, implementing and testing backup procedures for business-critical data, and having processes for offboarding users who leave the company.

Security hardening is about enabling policies and technologies on your devices that make it harder for an attacker to gain a foothold on the network, or traverse across it if you are breached. In a Windows domain, much of this comes down to Group Policy. You can also leverage tools such as Windows Security Baselines to help in this manner. These policies might be things like disabling access to the command line and registry editor for users, disabling SMBv1 and SMBv2, preventing users from installing printer drivers, disabling anonymous enumeration of network shares, or turning off credential caching. You may also seek to enable security features such as Credential Guard / Virtualisation Based Security (VBS), various Exploit Protection settings, Isolated Browsing, etc. to make things harder for attackers. AppLocker (or SRP) can also be very powerful as a method of locking down users' computers to prevent the installation of software that is not approved, including malware.

Finally, incident response is about having a plan for when things go wrong. I say when, not if, because breaches are inevitable. This is one of the reasons why the "use a separate computer" approach doesn't work - it focuses efforts on a single area in a frustrating way that will make users look for ways around it, instead of focusing on broader organisational controls that have a wider benefit without annoying the users.

An incident response plan is document (or set of documents) that says exactly what the procedure is in a range of different scenarios relating to security. These events aren't just about breaches and vulnerabilities - they can also be things like "we had to fire an employee", "the data center we use was flooded", or even "the head of security got hit by a bus". Any eventuality that impacts the business or its security. The primary goal of creating an incident response plan (also called a playbook) is to help you be prepared and save you from having to make security decisions on the spot in a high-stress scenario. The secondary benefit of writing such a plan is that it helps you identify potential gaps in your security, or recovery plans, before an incident even happens. There are a ton of resources online to guide you through building an incident response plan, so I won't go into details here.

You don't have to do all of this today. It's a lot of work, and security programs are a long-term part of IT operations at any organisation. You don't have to do it alone, either - you can seek guidance from professionals along the way. But if you start with the immediately actionable stuff today, and continue making just one small improvement each week, before you know it you'll be in a far better place than most organisations out there.