[This is a Guest Diary by Joshua Tyrrell, an ISC intern as part of the SANS.edu BACS program]
Managing the Attack Surface
You’ve begun the journey of reviewing your IT infrastructure and attempting to figure out how to protect yourself from those who might not have the greatest intentions. That’s great! Stop yourself though, before you get too far into the weeds of the different technologies available to you to defend yourself. Before you get to that point, there are some details that need to be fleshed out. Let’s have a look:
These are all pertinent questions to either scaling up or scaling down your attack surface and working towards having chaos-free Friday nights.
Fortify the Exterior Walls
Defense-in-Depth is the name of the game in the 21st Century, but that doesn’t mean we shouldn’t be doing what we can to make sure the perimeter walls aren’t as imposing as possible. You use firewalls, yes, but are you using them to their maximum potential? Modern firewalls allow for geo-blocking, which is the blocking of traffic based on IP addresses correlated to countries. These databases are updated somewhat regularly, so there is maintenance to be done on your firewalls to make sure they’re up to date. If you’d like even stronger evidence for using geo-blocking, search for “Top 10 Countries where cyber attacks originate”. Lists have been generated by teams across the world to show where many of the world’s cyber criminals are calling home. Now though, what if you do have a business partner that resides in one of those countries that you may not want traffic widely from? Easy enough, create an exception for their ASN in the geo-fence.
Another tool at your disposal is reputation filtering. This process allows your firewall to reference the IP of either source or destination and forward or drop the packet as per the policy. This can be highly effective at reducing the amount of potentially malicious traffic that is not initially blocked by your geo-fence. Take heed though: Cloud Service Providers may be unintentionally flagged and dropped due to the nature of their business model. There is a way to help you navigate this mystery though, and that is to simply look at who the largest CSP’s are, and weigh that against historical traffic to your assets. You may want to allow AWS, Azure, GCP, and even DigitalOcean, but how about that small-time server farm in Seychelles? Or the Netherlands? Those you can probably block outright, after considering those initial questions we talked about earlier.
We spoke about traffic coming to the outer walls, but what about traffic trying to get out of the gate? You should consider blocking websites internally. i.e. social media sites. You can go one step further and segment your network to allow certain employees to access those sites, should it be within their role’s purview. If employees want to peruse social media while working, let’s say they’re on downtime, then force them to connect their devices to a well-segmented guest network. It is probably not worth allowing them to access these things from a network that also houses production environments though.
Email is one of the most widely abused mechanisms for delivering malware and social engineering. What can we do about it though? Well let’s set up an email gateway, so we can filter out the wheat from the chaff. Modern email gateways allow integration of services like VirusTotal, which would scan the email attachments and flag them for being potentially malicious. You could also integrate a sandbox, which would then scan and ‘detonate’ email attachments to find the malicious threats hidden in the mail. Obviously, before implementing these services you need to test them. That goes for all your possible interventions though; don’t just throw things into your infrastructure and hope for the best.
Another way to protect from bad emails is reputation filtering, much the same way we discussed earlier. There is a problem however- scammers, spammers and all the other generally not-so great people like to use free email services like Gmail, much like the rest of us. So, what could we do? We can’t just block inbound Gmail, that could be disastrous for communications. What we can do is server-side filtering to allow the free email services to go to some internal email addresses but not to another. Your customer service team might need to talk to people who are using Gmail, but how about your engineering team? Or your HR team?
You can safely assume that these protections can be costly, in terms of both finance and time. If you’re a smaller organization, these might not be feasible to do, at least in-house. You may have to source the assistance of a third party, or perhaps form a consortium with other like-entities and purchase the solutions from a vendor. When considering time, think about your mean time to recovery. If you’re organization is breached, how long do you have until there’s no coming back?
Harden your Outposts
You need to be better at managing your devices. You might find the tone accusatory, which is fine, it’s supposed to be. By reading that statement though, you probably just started doing an inventory of all the things you’ve done to protect your endpoints, to the best of your knowledge and ability. Let’s look at some of the top things you can do to make sure you’re best protected.
First, you need to inventory what you have. You cannot protect what you don’t know exists, so go ahead and run that internal nmap discovery scan to find that web server you stood up 10 years ago but then never touched again.
Now that you know what you have, let’s take a look at patches. Patching needs to be done, or if not, then you need a good excuse and mechanisms to protect the enterprise from issues that may arise from leaving a weakness in the network defenses. Depending on where that weakness is, you’ll need to increase the surveillance on the assets that connect to that unpatched or out-of-date asset. Patch management also needs to exist, don’t just run “Scan for Updates” on your Windows machine then let it update in the middle of the workday. Have yourself a testing environment, and stage those updates. If you need any other supporting evidence for this notion, then I’ll direct your attention to the recent global CrowdStrike outage.
BYOD, or “Bring Your Own Device”, is an idea that has taken off due to cost, but it does have its issues. The first issue is vulnerability management for that device. You have potentially hundreds or even thousands of different devices that you have no control of whether they are up to date with the latest security patches. If you cannot avoid BYOD, say because of cost, then you’ll need to really be up to date on what devices your employees are hooking to the network. Make a note of the devices they plan on using for work, and if they purchase a new one, have them reach out to your IT staff and let them know about it. If you cannot control what devices are accessing your data, then you’ll need to compensate by working even harder to manage your alerting mechanisms.
Data commingling is another issue. How to control what happens to the business data that is on that device? Applications as well, having no idea what these people are downloading on to their devices and the vulnerabilities they are introducing. More on Application Control: find the best possible software for what you need it to do and stick to that. It does you no favors to use several different IDEs for software development, or package management. This also assists in general IT operations, not just security.
Managing the attack surface is no easy task, and entire books could be and have been written on what to should do. I hope though, that what I’ve highlighted here today helps you down your path.
[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu