As if 2020 wasn’t a difficult enough year, more news of recent ransomware attacks has caused greater alarm among our most critical institutions. The attacks are very much targeted at agencies that are perceived as “able to pay.” Additionally, attackers have now begun to exfiltrate data so that even if an organization is able to recover their data, they’re still forced to pay a ransom to keep the data from being leaked or sold. This leads attackers to focus on industries with data assets that are too critical to lose. Ultimately the strongest defense against these attacks remains a security posture with a zero-trust approach being key to protecting an organization from attack. Have gathered some basic countermeasures to protect against common cyber attacks to your organization from cyber threat actors.
What is Zero-Trust?
Zero trust is an approach to data security that assumes that everyone is a danger to critical data assets within an organization. You only open access to the needed data at the exact moment that access is required. It also requires that several steps be taken to ensure data and system assets are understood, and fine-grained controls are implemented.
Step One: Classify your Assets
The first step to approach a zero-trust model is to understand where your data lives and what level of secrecy is to be applied to this data. Using a classification model is desired and recommended to be successful. Several regulations exist for Healthcare, Finance, and others that are a good starting point. However, often overlooked is the “non-public” information such as strategic initiatives or other intellectual property.
Step Two: Identify the Business Criticality of those Assets
Now that you have an “asset register,” begin ranking the data into buckets representing the desired level of protection. Data and systems which represent the “golden egg” of your organization get the highest level of protection. If possible, it is highly recommended you begin considering migrating data into separate network segments according to escalating criticality.
Step Three: Determine Who Needs Access
Divide your teams into functional groups. There is no reason someone in engineering should have access to human resources data and/or payroll systems. Vice-versa, information technology should have no access to patient care applications aside from supporting the platforms they operate on. Beware of the “super-user” person on your team who seems to have access to it all. These accounts are often the very targets of attackers or can fall victim to extortion.
Step Four: Apply your Findings
Once you have an understanding of all of the above, you now have a solid foundation for applying protections. It is highly recommended that networks be segmented internally by powerful firewalls with next generation features enabled. Additionally, SSL inspection is necessary for data loss prevention practices. As previously mentioned, going further into segmentation by departments is highly recommended, if possible.
Technical Applications (Deep Dive)
In practice, this might seem a little overwhelming at first but becomes easier once the initial work has been completed. For example, let’s do a case study with “The Bank of Best Security.”
The Bank of Best Security (BBS) has implemented a core processing system that is typical for most regional banks that host their own core operations. They have Core Banking System Enterprise and some web-based Software as a Service applications that help support their overall operations and offerings to their clients.
First, BBS has implemented their database servers within a separate VLAN with no access allowed from anybody. They have several VDI workstations for developers and report writers to generate reports as needed, but physical devices are unable to communicate with this server. Patches are applied once a month at a set time. During this time, a web proxy allows traffic to and from Brand X Linux patching servers. These are validated on a test system before applied to production.
Second, the API servers that supply data to the front-end applications reliant on the database are allowed to talk to the databases on the established database communication port, and nothing else. The user accounts utilized for this backend access only have the necessary access controls to perform CRUD operations against the objects needed. TLS is utilized for communicating with the database so that data cannot be “sniffed” in flight.
Batch servers also live at this layer. All batch operations are closely monitored, and a database firewall was implemented to detect anomalous activity (select * from X), and suspicious activity is reported on immediately. Changes to these servers require access to VDI systems that alert as soon as someone accesses them. Justifications and prescheduled access are necessary for these systems, and misuse is met with discipline and/or training as needed.
As a third layer, vendor systems are placed in individual DMZs, and vendors’ comingling is strictly forbidden. Access is allowed between these DMZs and networks as needed. A review of BBS’ firewall shows that there is not a single “Allow Any.” Every inbound and outbound rule is tightly controlled.
Finally, users are segmented into their own networks according to function. There is no cross-pollination, and users only have access to the data they need. File servers are assigned to each network. Egress rules on the firewall only allow exactly what is needed. Ingress does not permit executable files to be downloaded at all. Patches to VDI workstations are performed within one week of vendor released patches. Including non-operating system applications such as Clay Brick PDF Reader. Because BBS utilizes VDI, master images are patched overnight, and users logging in the next day receive fresh images with up to date software the following day.
Remote users are required to log into the VDI environment they’re assigned to. They cannot gain access to other environments without using a different VDI image. Remote users are not permitted to move data onto personal devices. Email is permitted, but file attachments are closely scrutinized, and BBS has a policy of not emailing files around for any reason.
Users are constantly tested on their social engineering skills utilizing a third party that provides training and regular testing exercises to ensure users remain up to date on their training.
While BBS has other protections in place (SIEM, IDS/IPS, Malware Detection, ETC), these core tenants outlined above give BBS a clear advantage in preventing malware. Ransomware would have difficulty traversing this network as the segmentation would allow for isolation of departments should one have a failure in their protection scheme.
We Can Help!
STN Inc has designed and helped customers approach this nirvana of data protection. Our lead engineers are all students of security, and several hold CISSP or better certifications. Get in contact with us, and we’ll work with you to address these difficulties.
