Fundamental security recommendations for critical infrastructure
The last years have seen a number of high profile attacks on computer systems either operated directly by the Ecuador government, or by third party corporations that host critical infrastructure. The latest was an intrusion into the systems of the national police force, which lead to the mistaken arrest of a high-profile individual. Not much is known about this incident - the only released information claims that the attacker logged in to the police system using the credentials of a police officer, and that this log-in happened from a VPN or proxy outside of Ecuador.
This article is not really about that specific incident. Instead, we would like to give a few basic security recommendations that all critical infrastructure in Ecuador absolutely have to implement, before moving on to more advanced techniques. These are not the only things you need, but if you don’t have these properly managed, you will not have a chance of protecting yourself against attacks. The sad fact is that the industry of information security is still in early stages in Ecuador - and more importantly, it seems that important institutions are missing even the most basic measures. What this also tells us is that the attacks we know about are likely only the tip of the iceberg. Most intrusions will likely have gone unnoticed. It is extremely probable that several threat actors or even individual amateurs are inside of government systems right now.
These recommendations will be good for any organization to implement, but it’s primarily aimed at the more important sectors of the government and related corporations. Places such as the justice system (Consejo de la Judicatura, Fiscalía General del Estado, Defensoría del Pueblo, Contraloría General del Estado, Procuraduría General del Estado), law enforcement (Policía Nacional, Policía Judicial, Criminalística), military and health (Ministerio de Salud Pública, hospitals and laboratories). Other places that include a lot of personal information such as tax agencies (Servicio de Rentas Internas) and civil registries (Registro Civil) could also be considered critical for the purposes of information security. Finally, any corporation that hosts large amount of sensitive information.
Just to reiterate - these recommendations are things that most security professionals will already be aware of. But before looking at more advanced measures, these need to be fully implemented everywhere. Let’s jump in.
Secure connections to websites (HTTPS / TLS)
One of the main struggles for the security profession the last ten years has been to convince the world that secure connections to websites are absolutely essential. Even if you’re not managing sensitive data, a secure connection is still absolutely necessary, since otherwise you can expose your users to attack. We are happy to see that most of the world has adopted this practice - including many important websites in Ecuador. But there can be no exception. Every website and every page within every website needs to be protected with HTTPS / TLS. It’s also important that JavaScript and images are delivered with a secure connection. And this is one of those places where we have seen misconfigured sites that sometimes uses secure connections, but sometimes not.
Our position is that it is absolutely necessary to protect every single web connection with modern versions of HTTPS / TLS, and using proper certificates. This is not a complicated thing to set up, and with certificate authorities such as Let’s Encrypt which provides free certificates, it doesn’t have to be expensive.
Proper authentication
If you look at the latest Top 10 list of security problems from OWASP you will see that broken authentication is one of the elements on the list - and it has been there since the beginning. All other security measures rely on being able to identify actual users from other people in a proper way. If you can’t do this, you don’t really have security. The full subject of authentication can get quite deep. There are many things to look at, including how to store passwords, how to manage users and roles and many other topics. But for this list of recommendations, there are only two things we would like to suggest when it comes to authentication, since for critical infrastructure they give you a large benefit for very little cost. Both of these measures are meant to minimize the risk from bad passwords. You can put in all kinds of things to try to control for bad passwords, but the truth is that they will happen. Some people - even people that should know better - will use “password” as their password. And of course, we encourage you to educate your users in how to use password managers and what constitutes good passwords. We encourage you to get rid of bad password practices such as expiration, requirements of different characters in a password and so on. But from the most basic perspective, if you can reduce the risk of a bad password actually being used to attack your organization, that is an even more important measure.
Limits on authentication attempts
The first recommendation is to make sure that you put limits to how many times someone can try logging in as a specific user before locking their account. Make sure that you do not base this on the IP address of the user trying to log in. The amount of tries should be counted for the user which someone is trying to log in to. If you don’t do this, you are opening the door for an attacker to try a large amount of possibilities. Of course, the cost is that sometimes people will lock themselves out of their accounts. But if you balance that against the risk of someone stealing the login information for a police officer and accessing privileged information, that will usually be a good tradeoff. For high-security accounts, it’s probably a good idea to set a low limit on tries - maybe even as low as 3. If you want to, it’s also possible to use more advanced ideas, such as progressively requiring more information the more tries have been made. But the basic idea of simply limiting the number of tries is a very good start. Just make sure that if you’re developing your own software, that it doesn’t have any timing leaks or other problems that leak information about the correctness of a password outside of the limitations on attempts.
Two-factor for all authentication
Even more important than limits on authentication attempts is two-factor authentication. This is a measure that more and more organizations are adopting. And while it is not impossible for an attacker to manage, it significantly reduces the risk of a successful attack, even with a bad password. These days, two-factor authentication is not complicated to implement. You need to make sure you avoid using SMS/text messages for it though. It is much better to use something like TOTP (Time-based One Time Password), which is widely supported by all major languages and platforms. With this kind of solution, you are increasing the difficulty of attack significantly. It also has the side effect of reducing account sharing, which while often convenient, can lead to significant problems in proper authentication and authorization. With a simple TOTP implementation and a free TOTP application for the cell phone of the user, you will be able to protect sensitive information at a completely different level. Even if an attacker manages to use phishing attacks to steal a password, two-factor authentication can still protect your systems in many circumstances.
Our perspective is that two-factor (or multi-factor) is such an important measure that all of the industries and agencies mentioned above HAVE TO implement this. It should be the minimal level of authentication security for government agencies that manage sensitive data.
Logging
What do you do once an attack happened? How do you figure out how the attacker got in, and what they did? This is where logging is supremely important. There should be no question about what happened. For these kinds of industries, all actions have to be logged. But that’s not enough - you need to make sure that the logs are reliable and that there’s no risk of losing log data. The first step in this work is to make sure that each server has a separate storage device for logging. That means that if there’s a problem with the main storage device, logging will continue working. If you can implement append only logs with data structures that provides cryptographic authentication of log entries, this could go a long way as well - especially when it’s necessary to use this data in later proceedings. But this is just the first level. An attacker could still modify these kinds of logs. In order to take this recommendation seriously, you need to implement a separate log system, which has very restricted access. Basically, other services can send logs to this system, but nothing else. It should be on a completely separate network, and as locked down and secured as possible. That way, if an attacker breaks into a machine and does some actions, those actions are already logged in the remote machine. Of course, a sophisticated attacker could potentially jump over and break in to the log server as well, but that is a significantly harder thing than just breaking in to the first server. In this way, you can protect and preserve important information about intrusions from most kinds of attackers.
Network segmentation and authorization
When building a system, it is important to think hard about what the different capabilities of the system are. And once you know that, you need to consider how sensitive each one of them are. Based on this, it is likely that you will need to implement an authorization system where different users have different access to different capabilities. Not everyone in the agency should have access to the same information, nor be able to do all the actions in the system. But that is not enough. You should also segment capabilities based on location. For example, if you have an extremely sensitive operation, and you only have three users that are authorized to use that operation, you might not want to allow them to do that operation from their mobile phone while in a different part of the country. Some operations might be sensitive enough that you want to ensure that the user can only do them while sitting in front of an approved computer in the physical location of the agency. Other operations might be sensitive enough that you want the user to be on the network - but it’s OK connecting using a VPN to access the network. And finally, some operations might be open enough that the users can do them from any location.
This kind of location-based authorization can be extremely simple to implement, but if you do it correctly, it can stop many types of attacks. And more importantly, it can protect your most important information and operations, even if lower-security capabilities are compromised.
Updated versions
All software has bugs. And many of these bugs can be used to compromise a system. These kinds of bugs can reside anywhere, including in libraries from third parties that you use to build your own application. In December 2021 we saw the catastrophic string of vulnerabilities from the Log4Shell attacks, which targeted a big problem in the widely used Log4J library, which is being used by literally hundreds of thousands of projects all around the world. Every year, security bugs are being discovered in almost all the software around us. For this reason, it is of utter importance that you keep all software in use up-to-date. That includes libraries used inside of custom built applications. But it also means using up-to-date versions of operating systems, analysis tools and anything else.
As one example, it seems one public website from the Ecuadorean police (https://mail.policia.gob.ec/) is using the open source software Zimbra. However, looking at the copyright statement, it seems to imply that this version of Zimbra has not been updated since 2017. In the public CVE database you can see that Zimbra has had at least 15 important security issues since 2017.
Keep your software up-to-date. This can be costly, but the alternative is significantly worse.
Leader support
Security has to be a first-level concern for an organization. There’s no alternative - and especially not for organizations and agencies that are part of the critical areas of a government. But sometimes it is hard to communicate this to the leaders of the organization. They often have many different concerns, and security can often seem like a drain on money. One unfortunate aspect of security is that when it’s done well, you won’t see the results. It’s only when something goes wrong that you notice the lack of security. This means that it’s often hard to justify cost increases in security. But this is where a leader needs to give their full support to their security team. In order to implement proper security, investments will need to be made. And they will continue to happen - security is an evolving field and the state of the art will improve.
For these reasons it is absolutely imperative that the leadership of an organization or agency both understands how important security actually is, and also gives their full support to their security team. They need to be strong enough to understand that an investment now will lead to less risk of costly attacks later.
Public accountability
When a security incident happens, most people have a very strong preference for trying to keep it secret. This instinctive reaction needs to be fought. The only way we as a society will become better at security is by sharing knowledge about what has happened, and how we can do better in the future. And what’s worse, public institutions lose trust from citizens when they repeatedly lie or try to avoid talking about something that happened. Often, the effects of this will lead to wide-spread speculation, and the reputational damage might actually be worse. Future credibility will also be damaged. This is important when it comes to any subject related to personal data. But it might be even more crucial in relation to the justice system and law enforcement. These areas of a government have such extreme power over peoples lives, and any sign of evasiveness or lack of clarity will quickly become a permanent stain, making the application of justice less effective.
When an incident happens, a public institution has the obligation to be publicly accountable. They have to describe what happened in enough detail for the population to understand the risks involved and the reasons why this happened. And finally, in this type of post-mortem, it is very important to also describe how the organization will do better, in order to avoid this kind of incident in the future. This information has to be delivered in a clear, simple and timely manner. Public officials should make themselves available to discuss the incident with media in an open and receptive way. It is extremely important that different communications do not contradict each other - this, once again, gives the impression of lies and potential corruption.
Summary
Proper security is a life-long project. But the basics can be put in place surprisingly quickly, and they are the foundation for more advanced countermeasures. The advice outlined in this article is primarily the kind of measures we believe are absolutely essential for critical government agencies. If you work in that kind of environment, and you don’t have some or any of the above measures, we recommend that you urgently try to push for implementing them. Without this in place, your organization is like swiss cheese - full of holes.