Way too many organizations do not use any form of network isolation / segregation. For example, they do not control which workstations can access specific servers directly.
Does the administrative assistant of the CEO (or any other user) have a legitimate business need to be able to access the Domain Controller via RDP?
Do they need to access the database server? On any port?
You get my point. Now is the time to really think about how to isolate specific groups of users (even inside the IT department!) from specific groups of other users and devices.
No employee should be able to access network shares or anything else in the HR department, for example – and if you sit with your team and think about it, there are really a lot of rules which can and should be created for this. A good person to call to the brainstorming session is the risk manager of your organization, as they will be able to help with identification of sensitive areas you might not have thought about.
You should assume that at any point in time some endpoint will get infected in one way or another – when that happens, the attacker should be ‘sandboxed’, isolated in that specific network segment and should not be allowed to roam freely across the whole network.
Protect people from themselves. You are not isolating them because they might somehow magically obtain the ability to hack computer systems – you are protecting them from the risk of being exploited and becoming a bridge between a threat actor and your most sensitive data.
On Web Servers / Externally accessible services and DMZs
Do you have web servers and / or other internet-accessible services in a DMZ? Move them out immediately. They should not be located even in the same datacenter as your primary devices.
Ideally the only connectivity there should be over a VPN with a port-knocking set up, so as to not expose any remote administration capabilities over open ports. DMZ is dead (my personal opinion), from a security perspective. Treat all your devices as internet accessible – from the point where your user endpoints became entry points DMZ became irrelevant.
Whenever possible, such services should run from a BSD Jail – or from isolated (per app) virtualized environments, never overlapping more than one service on one jail or one virtual machine.
On VPN connections
Always remember that a VPN connection and the target device / network is only as secure as the source device connecting to it.
That means, that no matter how hardened your network and servers are, if an administrator connects from home from a compromised machine, whoever has compromised their machine has also effectively compromised your network.
You can prevent this by providing separate, secured laptops to your administrators with an enforced policy to ONLY be used for remote connectivity. Same should be encrypted, should have the same hardening measures applied to them as all your other critical endpoints, including security software, policies, STIGs, etc.
Think about enforcing 2 or even 3 factor authentication for VPN connections.
MAC and vendor whitelisting
Only MAC addresses existing on a pre-approved list of devices should be able to connect to the network, and only to specific network outlets.
Let me give you an example why.
Attackers often use rogue devises to plug a gateway (in the form of a wirelessly connected flower pot, for example) into your network. Other times they come in during a time when people are on a break and plug in rogue devices.
A new device on the network, even if not allowed to connect due to MAC filtering, should raise the loudest of alarms for your infosec and physical security teams.
Since MAC addresses are extremely easy to fake and duplicate, you should enforce matching of a mac to a wall outlet – a device should not be allowed to ‘roam’ – can you imagine your network-connected printer suddenly picking itself up and connecting from another floor?
Another good idea is physically securing specific wires to specific outlets, with a lock – where applicable. It sounds like an overkill but it is not. Attackers do come into printer rooms, they do copy MAC addresses – and they can unplug your printer and plug in their rogue device, even putting it between the printer and the wall outlet. Unplugging the cable in such rooms with limited visibility should be impossible (and these rooms should always be under video surveillance).
Host-based Network Whitelisting
Most commercial Antivirus products come with a host based firewall. If yours doesn’t it is time to switch vendors.
Host based firewalls should be granularly, centrally configured to only allow traffic to the internet for specific applications (your corporate approved browser, for example). If everything else is denied, hostile binaries will not be able to communicate with C&C (command and control) servers and / or exfiltrate data.
You should explicitly deny, log and send alerts for all traffic attempts from unauthorized applications.
Rules should also be defined in the same way for servers, as internet access should only be allowed for the hosted application and for nothing else. You should NOT allow any powershell executable / ftp or anything else internet access from a server or a workstation. Applications to block from internet access using host-based firewalls: ftp.exe, powershell.exe, psexec.exe, psexecsvc.exe and any other executables you may want to prevent from external access in your environment.
If you need an official-looking document to convince the network team that this topic is worth discussing you might want to take a look at https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/Slicksheet_SegregatingNetworksAndFunctions_Web.pdf
