Ransomware attacks have been causing havoc with everyday life in recent months. The attacks against the Colonial Pipeline Company and JBS, one of the country’s largest meat processing companies are just the most notable. But critical infrastructure isn’t the only trendy topic for today’s malicious actors. In fact, in March of this year, the FBI issued a warning to universities and colleges that they could be among the next big target for attacks.
According to an article in Insider Higher Ed, the FBI was warning colleges that hackers were, “…leveraging software called PYSA ransomware to access IT networks, block access to vital information and systems through encryption, and demand payment to restore access.” The article also highlights how the hackers are, “…not only requesting payment in exchange for making encrypted data accessible again. They are also threatening to sell sensitive information such as Social Security numbers on the dark web if institutions or affected individuals do not meet demands.”
To get a better understanding as to why colleges and universities would be the targets of sophisticated ransomware attacks, and what they can do to better protect their applications and networks from attack, we reached out to Bruce Kuska, the Regional Sales Manager for State and Local Government and Education (SLED) at Checkmarx.
During our discussion, we talked about the vulnerabilities inherent in applications that malicious actors exploit, the reasons why applications are insecure, and the technologies that colleges and universities can implement to ensure their applications are secure.
GovDevSecOpsHub: When we think about hacking targets, we usually think about financial services institutions and other “usual suspects.” Are colleges and universities also at risk for cyberattacks? What different types of malicious actors target them, and what are they looking to gain?
Bruce Kuska: While financial institutions are popular targets because they have the resources – and critical infrastructure has been targeted extensively in the past few months because of the financial windfall and political impact those attacks can have – colleges and universities are also very much at risk.
People tend not to realize or think of this, but colleges and universities store a considerable amount of personally identifiable information (PII). That data is information about their professors, their staff, their faculty, and their students. They may even have PII for their alumni and donors. All of that data can make them a target.
Then there is the financial side of large private institutions. Many of these colleges and universities have large endowments and considerable donations. Others manage employee retirement funds and investments. All of that money can also make them a target.
Finally, there’s the research that is conducted at many large colleges and universities. Many research projects are funded through federal or private grants and are focused on solving large, real-world problems. The information and results from that research could be interesting to a number of organizations – including adversary nation states that would benefit from it.
So, while it may seem counterintuitive to the average person, there are multiple reasons why malicious actors would want to target higher education institutions – from financial reasons, to sensitive personal data, to research and information.
GDSOH: How could a large breach or successful cyberattack negatively impact a college or university? What could be at stake and what repercussions – either direct or indirect – could there be for the school?
Bruce Kuska: The recent attacks on the Colonial Pipeline Company and – more recently – on the meat processing company, JBS, illustrate the immediate damage that is done by a breach or ransomware attack. In both instances, those companies needed to suspend operations while they worked to get access to their systems and data restored.
Then – in the case of the Colonial Pipeline Company – an expensive ransom of approximately $4 million was paid to get their systems and data back. A smaller ransom of about $1 million was paid when a California college was hit with a ransomware attack.
An attack like these to a college or university could be incredibly costly – and not just because of the potential million-dollar ransom.
An attack that shuts down the school temporarily would not go unreported and unnoticed by prospective students. And existing students, staff and faculty may hold the school responsible for falling victim. Ultimately, the reputation of the school is at stake. That could lead to existing students leaving, prospects enrolling elsewhere, and even the loss of staff and faculty.
GDSOH: What role do software vulnerabilities play in college and university breaches? Why should colleges and universities be concerned about AppSec?
Bruce Kuska: Vulnerabilities in the application layer remain some of the most frequently exploited in cyberattacks. That doesn’t change just because we’re talking about colleges and universities. And there are reasons why that’s the case.
Much like with commercial companies or the government, developers writing application for colleges and universities have little training to write secure code. Reviewing code manually is also tedious and very time consuming. Historically, it has been so painful for the development team that they have resorted in copying old code and open source code to speed up the process.
This injects older, known vulnerabilities that are easy to access and make for an easy target with lots of valuable data.
GDSOH: Do colleges and universities develop their own applications, or do they mostly work with established, third-party software and solution providers that sell them applications tailored to education institutions?
Bruce Kuska: I would say that most colleges and universities write applications. Especially applications designed to share information between colleagues and constituents.
Of course, there are commercial companies that service the higher education marketplace. Many of these are creating commercial off-the-shelf solutions that schools can purchase, but they tend to be expensive.
Because of that added expense, writing their own applications can be faster and cost less. Custom applications can also better meet their individual needs because they’re individually tailored for their requirements, not made for the masses.
That being said, just because an application is written by a private company doesn’t mean it’s completely secure. All applications – even commercial off-the-shelf solutions – can contain vulnerabilities that can be exploited. That’s not limited to only custom applications schools write for themselves.
GDSOH: What can, and should, colleges and universities change about their application development processes to ensure that the custom software and applications that they’re creating are built in a secure way?
Bruce Kuska: First, they need to train their developers. Like I said previously, most application developers are just that – not security professionals. They’re not educated on securing applications, just writing code that accomplishes a task. Getting them the training to write better, more secure code needs to be paramount.
Next, they need to have a maturity plan in place that includes many of the same steps and technologies that they would implement for any other cybersecurity threat. This includes embracing static analysis and application testing to test code for vulnerabilities while its being written, threat modeling, and automation of their application scanning infrastructure.
Finally, they need to stop relying only on dynamic testing or penetration testing. This is a snapshot in time that is time consuming and doesn’t help solve the problems that are detected. It’s like a smoke alarm. It only notifies of the problem, but doesn’t tell them where the fire is or put it out.
GDSOH: What new technologies or solutions can they implement for their application developers to help ensure they’re writing secure code, implementing secure open source code, and developing secure applications?
Bruce Kuska: I would start by embracing on-line training that is built into the develop infrastructure. This gives developers quick refreshers on application security and trains them to become better, more secure application developers over time. It can be customized for the organization’s needs.
Next, they should look at today’s advanced static application security testing (SAST) solutions, which are a set of technologies designed to analyze application source code, byte code, and binaries for coding and design conditions that are indicative of security vulnerabilities.
Frequent testing of the source code for vulnerabilities using SAST solutions saves time and money in the application development process. The sooner application vulnerabilities are found, the easier there are to mitigate. It’s like finding out the foundation of a building is cracked before primary construction of the structure begins. So finding these early accelerates the software development lifecycle (SDLC) while saving them money in the long run.
They should also consider interactive application security testing (IAST) solutions which analyzes code for security vulnerabilities while the applications are running. Embracing SAST and IAST solutions together ensures that all vulnerabilities are identified and can be eliminated before the application moves in a production environment.
GDSOH: Colleges and universities aren’t just developing and deploying their own software and applications – they’re also often training the next generation of application developers. What can higher education institutions do to prepare their students for an industry that is increasingly focused on AppSec?
Bruce Kuska: Candidly, the same application developer training solutions that they’re utilizing in their own SDLC should be extended to their students. Teaching their students how to code securely will only make them more desirable, more in-demand developers when they enter the workforce.
But they shouldn’t just be using any training solution. Once that integrate into their SAST solutions, identify vulnerabilities, and train the developers as they work are – in my opinion – the most successful. These solutions are continuously training the students and showing them when they make a mistake or write code with a vulnerability, which is retained and replicated better than training that exists outside of their work and is then quickly forgotten.
