'Best Practices’ exist for a reason and while they’re not a foolproof way to prevent intrusion they can be a great first step to take in securing your network. Problem is, they only work if you actually practice your ‘Best Practices’.
Putting into Practice
Here’s a quick Blue Team exercise for you: It’s your first day on the job and you’ve just been put in charge of securing your company’s network. (Hooray for you!) Without putting too much thought into it figure out what your first few actions are. Will you perform an inventory, talk to the current SysAdmins and figure out what they’re already doing, start evaluating what your company’s external footprint is, or something else entirely? Ok, stop making that list. Now, look at your list and compare it to any one of the many, many, many, many lists of ‘Best Practices’ available on the internet. Maybe you listed every action that these lists cover and maybe you didn’t. The issue in securing networks is that our adversaries’ actions are always evolving which means there is a lot of work for us to do in keeping them out. Luckily, as we get better at defense we continue to make note of what methods tend to be the most effective. Even more luckily, people publish what works for them – that’s where these ‘Best Practices’ lists came from.
While none of these lists are identical (and they probably don’t exactly match the list you made earlier either) they do have some shared suggestions. One ‘Best Practice’ that each of these lists specifically mentions is to maintain security patches. Now, I’m not saying that’s the only thing that you should do but if practically every list explicitly states that patching software is crucial you would think that this relatively simple action is one that companies would be sure to implement. Well, if you thought that then you would be wrong.
Take for instance the recent ransomware attack that affected the San Francisco Metropolitan Transit Authority (SFMTA). Over the Black Friday shopping weekend the SFMTA provided free rides while the ticketing kiosks and faregates were proactively turned off to prevent inconveniencing customers. Computer systems across the SFMTA were the encrypted with variants of the HDDCryptor and Mamba malware with decryption keys offered if the attacker received 100 Bitcoins. Initial investigations into the compromise by independent security researchers revealed that access to the network was most likely achieved the same way as it was in a similar attack targeting Maryland based MedStar in April of this year. In that case, as is likely in this one, JexBoss (an open source tool to detect and exploit known vulnerabilities in JBoss) was used to exploit a web-facing (and un-patched) server.
The issues with JBoss and the underlying Apache Commons Library which handles Java deserialization were first reported in November of 2015 with patches issued within a week of public disclosure. In both the SFMTA and MedStar instances financial loss and service disruption could have been avoided if software patches had been properly applied ahead of time.
My parting thought for you is this: with the benefits of patching software well understood and the difficulty of execution relatively low there is no excuse for not having a fully developed patch implementation policy. It’s a simple action that can prevent access to would be intruders. If you’re not sure what policy your organization currently has in place today is a good day to find out… and while you’re taking the time to ensure that you’ve got your patch policy in place why not look at implementing whatever other ‘Best Practices’ your organization might have overlooked; after all ‘Best Practices’ can only happen if you actually practice them.