
Ask HN: How are you securely onboarding people remotely? - davezatch
Hey HN,<p>I&#x27;m the Engineering Director for a company in Beriln that currently has ~40 engineers. We&#x27;re hiring right now, and between Corona and the fact that lots of big players like FB are pushing remote work, I want to embrace our brave new world head-on. As an engineering team, we&#x27;re currently struggling with how to bring on people we may not meet in person for many months, in a safe and secure and trusting way.<p>We are, at least for the forseeable future, going to be a hybrid on-site and remote team. I know that has drawbacks, but, well, everything has drawbacks :)<p>We have smart people and can probably figure this out, but I would rather avoid easy mistakes if possible, so I&#x27;m reaching out to the hive mind. I&#x27;m curious about things like:<p><pre><code>  - What kind of tooling&#x2F;processes have companies implemented as they go more remote? What changes have had a big impact?
  - How restrictive are companies generally with new employees in terms of amount of codebase they can access, secrets (think API token for an important third party), customer data&#x2F;logins that are necessary for fixing tricky bugs, etc?
  - How do you handle ramping up someone&#x27;s access? (e.g. new devs can&#x27;t see $IMPORTANT_SECRET until...X months? manager sign-off? some kind of security training?)
  - What legal&#x2F;regulatory&#x2F;cultural issues may pop up hiring developers on the other side of the world? (e.g., if a developer here steals a laptop or company data, we would just call the police. What do we do if a developer in $FARAWAY_COUNTRY_WITH_DIFFERENT_LAWS_AND_CULTURAL_NORMS does the same?)
  - Anything else I&#x27;m not even thinking about, because I&#x27;m new to this?
</code></pre>
Bonus points if anyone can point me to (or write!) a blog article that explains how their company does this. I can&#x27;t find one, which is surprising!
======
Aussie06
You could try Dekko. They have DekkoLYNX, which is a secure (e2ee) video
conference and DekkoVault, which allows secure file sharing, email, chat, and
document sign offs. DekkoVault allows you to share sensitive information only
with people, who would see it. Have a look at
[https://www.dekkosecure.com/videoconferencing](https://www.dekkosecure.com/videoconferencing)
and
[https://www.dekkosecure.com/dekkovault](https://www.dekkosecure.com/dekkovault)

------
remotelyyours
Adding to what Twunde said, async communication is important. However, I think
chat is a bit impersonal, especially in the onboarding phase where you want
them to create connections with people as well.

You should look at something like vlokit [0]. It's aysnc video chat for remote
teams. You can basically create a story to do introductions. Have videos of
important processes etc.

The cool thing is that they can ask questions or give feedback in the same
thread. So, you can have async communication, while making a real connection
with them.

It can really work well for you.

[0] [https://vlokit.com](https://vlokit.com)

------
twunde
In point order:

1\. Have some sort of standard video chat such as Zoom, etc to hold meetings
easily. Importantly, everyone should have access so expensive tools like WebEx
may not be what you're looking for. Additionally you'll probably want an
asyncronous chat client. This can be Slack/ Microsoft Teams/ Mattermost/IRC
etc, but there should be an easy way to ask questions async.

2\. Plan out something so that new hires can easily meet the team. We
personally assign new hires buddies and we also use a slack app called donut
to randomly assign people to have coffee/tea/lunch together.

3\. In terms of equipment, you'll probably be shipping laptops or something
similar. MacOSX and Windows both support MDM client workflows so that a new
hire opens up the computer and it autoinstalls your company's standard tools,
and enforces secure configurations (search for Zero touch deployments for more
info). This should definitely include encrypting the laptop as lost/stolen
laptops can be considered a data breach if they are not encrypted. Note that
some companies still have larger than normal laptop processing times to ship
out equipment.

4\. In terms of restrictions for what new employees can access, you'll usually
grant access to all of the codebase but give more limited permissions to
access secrets (this assumes that you have a separate secret management tool
and your keys aren't in plaintext so your milage may vary). This is often
controlled by role-based access control (RBAC)

5\. In terms of ramping up someone's access what you're looking for is
attribute-based access control (ABAC), where you can create fancy-pants rules
like grant access to X when someone has been at the company for 3 months. At
40ish engineers, you're probably not there, but this should be something
you're asking about when IAM comes up and when you're hiring more traditional
IT or security folks. You _can_ also build out approval workflows, but these
definitely slow down velocity and are more typical of larger corporations.
This can significantly slow down development while not really providing much
security benefit.

6\. Re: legal/regulatory/cultural issues: Being based in Berlin, you have some
EU laws around data usage ie EU-US Data Shield and GDPR considerations.
Besides that, you'll probably need to check with your company lawyers. Per
devs stealing equipment, your finance team probably doesn't care if a hire
steals a laptop or other equipment (That laptop is probably values as less
than 1000 euros. Time spent trying to recover it will probably outweigh the
value of the equipment). If someone steals valuable data or IP, especially if
you need to report a security breach, that is a different story. You _can_
still call the police in that location. As you grow, insider threats could
become a bigger danger. Most security compliance frameworks (NIST/ISO/etc)
require building out controls for insider threats including at a minimum audit
logs etc. At 40ish engineers this is not a big concern since your interview
process should hopefully be weeding out problems.

7\. The biggest issue with going remote is all those things that you currently
do in person that compose your companies tribal knowledge. Meetings, how
things work, how to best configure your editor and dev environment. You may
have existing documentation, but you'll likely need to invest time in
improving it. Do you take meeting notes and are those available to read by
your engineering team?

