Hacker News Reader

Comment by ivanr | Hacker News Reader

When I needed a security policy for my startup, I looked everywhere and couldn't find anything that made sense. I only found policies that are very, very, verbose, so much that I didn't know what to do with them. And most often outdated. In the end, we wrote our own, focusing on producing something that's comprehensive yet concise. (After all, if it's not concise, no one is going to be able to understand it.)

We're planning to make another round of changes and publish it under a permissive licence. Here it is in case it's useful to someone: https://www.hardenize.com/about/security_policy

A good security policy is very important early on to inform architecture and design. Ours has worked very well for us. It also often helped us get away from having to complete customer security questionnaires.

View on HN

> Work shall be carried out exclusively using corporate equipment. There shall be no access of company networks and data from personal devices. Corporate equipment shall not be used for personal activities.

This one caught my eye. As a dev, corp laptops are usually so locked down as to be useless, i.e. unable to install dev tools etc. So I often use personal equipment (not connected to a corp) and use git as my gateway back into big corp.

The struggle between security and usability is very real. Personally, I don't think that it's possible to lock dev equipment whilst not significantly impacting productivity. That said, ensuring that high-value environments (e.g., production networks) can't be accessed from dev equipment with elevated privileges, well that's necessary. And I feel often neglected in small companies.

So (as a corporation) don't lock them down as much. That's what we do as a small company who has to pass ISO 27001 (and NEN 7510) because our product is used for healthcare. From a security audit standpoint, not allowing personal devices saves a lot of time and trouble. (This of course means that anyone who is on-call just gets a phone from the company.)

As a developer; if you need to work around locked down environments the security policy doesn't really matter to you, as you are already violating it. Whether your employer cares about that or not is another thing of course. Some managers will consider you a liability, some will accept that this is the only way you can do your job.

Ideally employees embrace the security policy, and whoever tweaks it makes sure everybody can still do their job. In reality, that will vary a lot.

> As a developer; if you need to work around locked down environments the security policy doesn't really matter to you, as you are already violating it.

Or the security policy has an "exceptions shall be reviewed and approved by X and documented at Y" clause.

You’re doing yourself, and all other devs at your company a disservice - at least in my opinion.

If the devices are locked down to a degree that you cannot do your dev (aka your job), that should be brought up with management. Of course, it’s easier said than done xD

I’m personally a fan of locked down corporate devices and then either dedicated laptops or cloud vms for development.

It’s not necessarily an easy problem to solve though

It’s pretty rare that a manager will help fighting stupid security restrictions even if they prevent you from doing your work. I currently have to look into Remote Desktop solutions for one of our devices. IT in their wisdom have decided to block access to this category of products (they are blocking VNC sites and TeamViewer, Zoom is ok for unknown reasons). From past experience it’s clear that I either have to do it on my personal equipment or not at all because IT won’t accept even reasonable requests for unblocking. Sometimes running a VM with a non-corporate image will help.

The truth is, security is hard. IT/CorpSec are asked to implement policy drawn up by lawyers/auditors/compliance specialists with limited insight into the real needs of the organisation. Asking them to make complicated exceptions that they don't understand and can't control puts them into an untenable position with respect to hard requirements that are handed to them as absolutes. At the other end, this often filters through as decisions that look utterly nonsensical (you can use Zoom but not something else, etc).

Meanwhile, for a developer, telling people they can't install and run tools they need to do their job is also untenable.

Like others I've come to the opinion that you almost need separate computers and completely isolated networks to do this properly. If you are doing things right, there should be very little need for developer equipment to ever connect into any place that sensitive data resides. And consequently there should be very little need to lock down developer equipment. Unfortunately not many places can architect things that well, nor build that type of nuance into their security policies. Among other things, you need to invest a lot of work in creating fully representative non-sensitive test data so that developers can do their work in a realistic setting.

Curious how they handle personal mobile devices. So they offer company phones, don't offer after hours support, or outsource support to a company with a compatible policy?

Company phones are standard for any organisation like that has a policy like this. Another alternative is provoding a personal phone number that you can be contacted/paged on, and you log in to a corporate device to receive information as to why you're being called.

>As a dev, corp laptops are usually so locked down as to be useless, i.e. unable to install dev tools etc.

In a past life writing my company, which was a .NET shop, was acquired by a large company that used Macs for everyone except salespeople. They didn't provide Macs to anyone on my team, so we had to use the Windows boxes that were so locked down we had to get exceptions for everything. While we were successful in getting Visual Studio and other tools added to the exception list, were weren't successful in getting our compiled software added to the list. i.e. we literally couldn't run the software were were acquired to create.

For the short term, we discovered that anything done in WSL (Windows Subsystem for Linux) was completely ignored by endpoint security, so that let us work around many local issues for the 18 months or so it took us to get Macs for work.

Another "trick" I've used before is to run everything inside a Hyper-V VM on a locked-down Windows box.

Locking down machines makes sense, but won't someone please think of the developers?!

I wonder about the option of having an unlocked dedicated development machine that has no or very limited access to network resources but minimal security software in addition to a locked down laptop for email, slack/teams, etc...

Totally on board with the goals, and I've done some similar work, though haven't gotten anything nearly as trim as this as the output.

I'm interested in if/how this has stood up in externally-audited scenarios, like SOC2/ISO27001 or similar. I get that it's successfully avoided some customer scenarios, but am thinking of more formal processes.

At a glance, it covers many of the bases at a high level, but wonder if it's missing the specifics that an external auditor might typically expect to see from a policy manual. Are there additional sub-documents/playbooks/etc for many of these that elaborate further?

We haven't yet gone through any audits [we're small/young], but we've began to prepare for SOC2. The policy itself is absolutely insufficient for anything of the sort and we expect that we will generate a ton of further documentation. After all, SOC2 is essentially all about documenting your processes in detail.

Reply on news.ycombinator.com