By Charles Parker, II; Cybersecurity Lab Engineer
Attackers have not been overly picky as to the selection of targets. The focus continues to be the money and data, specifically sensitive data and intellectual property, which would then be sold on the dark web. This set of vulnerabilities leading to issues is due to several reasons including, but not limited to the lack of adequate security. This lack of security is not due to the non-profit intentionally not wanting a secure system. This is more a function of budgetary constraints, staff, issues, lack of security tools, and other aspects of their operations.
This creates an interesting dilemma. The non-profit can’t have an insecure environment, but don’t have the necessary resources available and necessary to fulfill this endeavor. This places the non-profit in dire straits. The management would not be a proper steward of the funds if a compromise were to occur and their funds and/or sensitive data exfiltrated. Worse yet, if the non-profit had to pay a third party to provide a decrypt key so the users could use the system or pay a forensic analyst to remediate the issue, as they are not inexpensive.
The threats to not only non-profits but all businesses and consumers abound from several sources from around the globe. With the mass number of people and bots, all focused on compromising your system, defending the enterprise appears to be very difficult at best.
As prolonged as defending the perimeter and system is, there are actions to take to further this goal. The users may need updated training as to the acceptable password format. Not every password is acceptable. As examples, 123456, 3456789, the user’s birth month and date or year, or the user’s mother name would not be acceptable. Any data or information that is readily trackable and available on social media should not be used. This is by far too easy for an attacker to secure. The password should be at least eight characters, with upper- and lower-case letters, numbers, and special characters. The parameters for the password may also be configured for this in the case of non-compliance. A poorly configured password is an easy attack point.
Two-Factor authentication is a useful tool in combatting third party’s unauthorized access. This works as a secondary method to ensure the person attempting to log in truly is the authorized person and not an unauthorized third party. The user is verified with an external source, generally, a code sent to the user’s phone or a push.
The entity should use up-to-date software. If the non-profit is using software that is the end of life (EOL), the software manufacturer is not, as a rule of thumb, continuing to spend much time and effort with ensuring the software does not have vulnerabilities or patching new vulnerabilities as they arise and are found. For instance, Windows XP has been EOL. The regular patches being pushed from Microsoft are not directed at Windows XP. The attackers look for outdated systems, as they likewise know there are vulnerabilities with these. By the non-profit not having relatively current software in use, the non-profit is leaving the door cracked for the attackers to look in and enter the system.
With budgetary constraints as they are, open-source software may be used to fill a gap in function while not incurring operation (OpEx) or capital (CapEx) expenditures. Although serving a function, this application may be problematic. The open-source software is there to be used without charge. The service may also charge for the upgraded, non-baseline version with a greater range of functionality. The issue regarding this not having a dedicated staff in place for updates, patches, functions the customers want in the future, etc. This also provides, unfortunately for outdated, insecure software. This encompasses a substantial portion, but not all, of the open-source software packages. In the alternative software from manufacturers should be used if possible.
Internal risk is a viable risk vector and attack point. The employees have their innate ability to be the non-profit’s best friend and worst enemy. The employees may exfiltrate data and intellectual property via third party email, USB drives, and other methods. The unintentional effect may also be the user not being very wary of phishing attacks and becoming a primary victim, while the non-profit is the second victim of the attack. The attackers with the well-crafted email may be enticing the staff to bring ransomware to be placed onto your system.
Non-profits have many difficulties and obstacles to overcome with their operations to provide a secure system. The C0level need to ensure the cash flow is relatively constant or available in a variety of economic circumstances. Assuredly this has not been an easy task, especially during the economic issues of 2008. The non-profit must maintain its relevancy in an s sea of the other non-profits with like and different mission statements.
Coupled with these issues is the maintenance of enterprise security. The issues with implementing a robust, solid cybersecurity defensive posture range from the implementation to employees and procedures. Although this is a rather large project, this may be completed with a bit more effort and creativity, but clearly possible.
Active Defenses for Churches
As with so many other non-profits, churches likewise have been listed as a target for attackers. This issue has been exasperated due to churches, along with other non-profits, having issues with cash flow and budgetary constraints. For the church’s management structure, purchases of tangible assets may be a much less daunting task. With cybersecurity having such a new focus in mainstream IT and industry, describing what needs to be done, why the project needs to be done, and the potential impact of a breach is difficult. Describing the potential impact of a breach, an intangible, is much different than purchasing a new pew, a tangible asset that would be seen and used with regularity. The management may not be able to fully appreciate the extensive issues directly associated with a compromise and its effects on future rapport with the community/parishioners, remediating the issue from the network and protecting assets. The lack of understanding is compounded with the church’s need to be connected via the internet only further complicates the issue.
The church needs to be competitive and digitally connected with the congregation and the public. This has historically taken the form of the church’s website available for people to search for and gain information on, email updates to the staff, and/or congregation, Wi-Fi for the people attending and staff, and many other services. With the current state of technology and the people’s perceived need for this, the churches don’t have much of a choice. These and other points provide ample attack points and vulnerable areas that need to be addressed prior to a system being compromised.
The goal of securing the church’s network or enterprise may be a rather arduous road. This is not an impossible task, however, would take effort and time on the part of the IT area and open-minds from the management.
The church certainly can ask for voluntary help and assistance from their congregation. The staff may be amazed at the depth of knowledge there is at the church. People from all walks and industries have been members of the church. Each of these people has a different level of expertise in different areas of IT. These persons may also have a varying number of hours to volunteer. Some may have eight, while others may have ten hours per week to put the system in place and later monitoring the security logs. With a few persons in place, this would be less of a momentous task. These persons may not be computer experts, but certainly can help or provide input.
The church also could put in place programs that don’t require a mass amount of effort and time. One action that needs to be addressed in anti-virus and anti-malware. If this is already in place, this may be reviewed to ensure it is a good fit. This solution is not perfect, which has been researched at length, however, it does provide for a baseline
level of protection. The church also should train the staff in its entirety. Any of the church’s staff with access to their system computer system should be trained for security threats. This training should be focused on phishing prevention and social engineering examples. This vector of attacks has been thriving for a few years and has proven to be present rather significant issues for the targets. If this is not presently being done, the church’s IT department needs to have a robust and timely patch management program in place and being used. Patches should be pushed often. These have been coded for a reason. These have been designed to improve processing, fix vulnerabilities, and other options. These are not meant to be an inconvenience, but a necessity with most patches.
The church needs to ensure the back-ups are done and tested to ensure the back-ups are done and tested to ensure the back-ups are done and in a retrievable form. This is useful in many forms and reasons. In the case of ransomware, the church would be able to restore the systems from the back0up with little loss of data. Without the valid, viable back-ups in place, the circumstances would be drastically different, creating stress and taking much time to fix. Without this in place and being actively tested, the church’s network and the system would be susceptible to ransomware, malware, and simple user error. This is relatively simple to implement.
Spam filters are a valid tool to assist in protecting the system. This is always a good idea for the members and staff with email accounts when the email is internal. Spam is sent to virtually every single email address when operating for more than two days. These would entice the users to click on links, pictures, or to visit a website selling products or services, or informing them of “fantastic” offers. The adequate spam filter would remove this issue to a significant level from the users. By extension, this should also decrease the level of malware experienced by the church. The church should have their policies regarding computer usage. There should not be an issue with this, however, when this is in a written form, documented for the users, there is a clear line to cross. The policies would be read, and reviewed by all users on the system and signing a document reflecting this.
About the Author
Charles Parker, II began coding in the 1980s. Presently CP is a Cybersecurity Lab Engineer at a Tier One supplier to the automobile industry. CP is presently completing the Ph.D. (Information Assurance and Security) with completing the dissertation. CP’s interests include cryptography, SCADA, securing communication channels, and inorganic chemistry. He has presented at regional InfoSec conferences. Charles Parker, II can be reached online at firstname.lastname@example.org and InfoSecPirate (Twitter).