Services
Although most Jemurai and securityprogram.io customers are based in the US, many customers have folks working all over the world including the Ukraine. Several customers have asked us what they should do to protect their people, information assets and otherwise prepare for potentially escalating conflict there.
Now, as a Ukrainian friend of mine was quick to point out, this is not as new a conflict as most people in the U.S. may think. So hopefully if you're in this situation, you've already identified the risk and given thought to how you think about securing your systems. And in many ways, it just raises the stakes on things you should probably already be doing as part of your security program. But we thought it made for a thought provoking exercise and decided to write up our thoughts in this blog post. Note that we are not intending to take a political position in this post, though I think we can generally say that we hope that armed conflict does not escalate - for everyone's good.
First, it is important to understand and level set on a couple of things that are true in the case of the Ukraine that are not necessarily always true:
Based on all of this context, there are some things that become more important for your organizations security - and the sections that follow cover these.
Note that even if you do not have team members in the Ukraine, it is probably also a good idea to note that CISA has been publishing information about active campaigns and the vulnerabilities that are being used in them. With general tension and adversarial behavior either increasing or being more visible, it is probably a good time to step back and think about your organization's security posture in general and make sure it is aligned to the risks out there.
CISA also provides further information and great resources in this Shields Up page.
These are the protections we identified as being very important given the context.
Most of our customers that have a presence in the Ukraine have developers but not hosted data centers or offices with backend systems. However, if your organization has hosted data centers or offices with backend systems running, it is critical to identify these systems and make a plan for how you would run any of those backend services if the ones in Ukraine were unavailable.
We would start by making an inventory of these systems, ranking criticality and then figuring out what alternatives may be possible. This should be part of a typical business continuity or disaster recovery plan.
An additional consideration that will come up again is the possibility that the Ukraine hosted systems could be taken into possession.
Generally it is a good practice to encrypt all drives on laptops, phones, tablets, desktops and servers. This can be done with OS native software in most cases. The likelihood that a device might get lost, left behind or repossessed during a prolonged event is significant. Generally having a device encrypted is similar to a remote wipe capability - which might also be a good thing to establish so that a device can be wiped in the event it is lost.
To protect against network traffic in general being rerouted and inspected, we recommend using a Virtual Private Network (VPN) for all users. It isn't 100% clear what the capabilities of various threat actors are but it is quite possible for network traffic to be rerouted during a conflict through either seizure of local network infrastructure or associated hacking exercises.
Using a VPN can protect basic traffic interception. You may also want to look at how access to production environments works and restrict it such that it has to be intermediated by an auditable command channel. For instance, using AWS Systems Manager Session Manager provides a strongly authenticated, auditable way to access your production environment. A related control is network segmentation which needs to be in place in any data center to help enforce things like least privilege and separation of duties.
In addition to the increased risk of physical loss of devices, there is a likelihood that there will be organized campaigns to win Ukraine based digital assets - including both phishing and website based malware campaigns (watering hole attacks). In other words, attackers might stand up websites with inflammatory information (from a variety of angles) and use the websites to distribute malware to visitors. To reduce the risk of malware through these channels, we recommend using an XDR product.
Using multi-factor authentication (MFA) wherever possible, including:
Maybe the most important of these is to review your production environments for access that is governed by access keys and secrets that don't also require MFA. We want to ensure that access to cloud operational systems requires MFA - and potentially is done through auditable channels.
Many mobile device management (MDM) platforms allow for enforcement of MFA on startup and configuration management in general (eg. encrypted hard drives, etc.).
Although there are valid discussions in the infosec community about the strength of different channels for delivering MFA (SMS vs. Authenticator) the most important thing is to have MFA enabled.
In general, we prefer single sign on (SSO) to MFA. But we need to be careful about the implications of this when an SSO provider gives a long term session token when a session is established. So the devil is in the details a bit with SSO - but at a high level, make sure MFA is required for access to key assets.
If you have developers based in the Ukraine, they may need access to certain things and not others. Based on the elevated risk, it is very reasonable to reassess these and step back to providing access to only what they actually need.
For example, if you have two products, maybe they only need access to the one they are actively working on. Similarly, maybe it is possible to reduce access to a particular development environment and not provide access broadly to AWS resources, for instance.
Another consideration is that you may want to reduce privileges for a period of time either in general, i.e. Ukraine based devs don't need access to production for a period of time, or as a response to specific events, eg. laptop is confiscated during military exercises.
Least privilege is hard and generally under appreciated work when it comes to security - because people complain when they don't have access and it is complicated to establish strictly what access is required for a given activity. Still, time spent here reduces your attack surface in the event that a developer's access is somehow stolen.
Ideally, developers don't have credentials to production systems sitting on their laptops. Again, the risk here is that a laptop is repossessed and there are secrets on the hard drive that are accessed.
A concrete way to achieve this is to use something like aws-vault and store access keys and secrets in the keychain. Looking in local files for private keys, credentials, etc. is a way to reduce what an attacker can get at if they somehow get access to a running system and can see the file system.
Confirm that alerting is in place to detect changes to your identity management system, whether that is AWS IAMIAM (Identity and Access Management) is a set of processes, policies, and technologies that enable organizations to manage and control access to their systems and data. IAM solutions help to ensure that only authorized individuals can access sensitive resources, and that access is granted on a "need-to-know" basis. or G Suite or JumpCloud or Okta. A common action taken by an attacker may be to establish other identities they can use in your account. You want to be able to detect this.
Another common attacker action is to create additional resources (eg. EC2 instances) that can then be used to create a lasting presence in your network. Being able to track these, say with AWS Config, or CloudTrail is another important capability.
Honestly, there's not a lot a small developer shop can do to ensure physical security of a team in a potential conflict zone. It may be worth offering short term relocation. Larger companies might provide more secure locations or seek paid protections but for most of our clients, this is not something they are able to think about.
In InfoSec there is an idea of a canary, which is derived from the old idea of a canary in a coal mine. The canary is basically an early warning signal that something is wrong. Although it is hard to think about, it is certainly possible that a team member could be held captive and forced to provide passwords and MFA tokens. Organizations could establish canaries, essentially otherwise harmless looking signals that the person is ok or has been compromised so that their access can be removed.
Some companies use the idea of warrant canaries to signal whether law enforcement is asking them for detailed personal information and asking them not to disclose that they have been asked.
In this scenario, a company could provide a simple check in process that if followed indicates everything is ok, but if missed triggers removal of privileges. Of course, if you do institute such a process, you would want to also establish communication channels and authentication / validation processes for reinstating privileges.
An obvious concern is developer productivity and continuity of access. The internet could go down. A laptop could be confiscated. It can be possible to provide a backup network (eg. cell phone) or process for getting a new laptop - but it is probably not possible to fully mitigate the risk of developer downtime. Therefore, we advised our customers to plan for some of this and evaluate projects that have critical contributors and important timelines - and revisit plans to see if they can be adjusted to provide better continuity. Ultimately, we see this as a case where we need to be aware of the risk and mitigate it the best that we can - but not expect to fully eliminate the risk.
For me, it feels surreal to think that we may have colleagues in conflict zones. For many of us though, that has been true for some time and it is probably something we need to include in our threat models and risk strategy. This post tried to highlight some of the specific things that maybe matter more given the types of circumstances we see developing in the Ukraine. It is intended to be an example and to provoke thought. Stay safe out there!
Map credit: Ukraine - Wikipedia - By Rob984, ByStaJ - Location European nation states.svg, CC BY-SA 4.0, Link
