Policies are one of the unavoidable assets that you will need during your infosec journey.

We sometimes see policies as long tedious documents that use far too many words to say don't be a dick. When done properly, our policies can be relatable, audienced, and therefore effective. This post is going to tell you about my experiences.

Subscribe

🧢 pro-tip?

At first, you'll probably think you need 39 amazing policies, all with the same lovely first seven pages of corporate crap (title page, table of contents, copyright statement, audience, version control, definitions etc). You don't. I made this mistake, and it was style over substance.

For a start, no one will read them all and fully understand them. Not even your in-house lawyer (if you have one of those).

Secondly, not all policies need apply to everyone, and they shouldn't.

Thirdly, you'll think, at first you need everything in the policy, because the auditor's asked for these in advance, and they will give a first impression. My experience is that a good auditor much prefers a shorter practical one.

Too short?

Let's take a look at an example that is both tongue-in-cheek, and to the point.

This one's from Ryan McGeehan. It's apparently been in my pinboard since August 2022.

Go on, click the link: https://medium.com/starting-up-security/starting-up-security-policy-104261d5438a

What you'll see is great — if you're an engineer. I think it's too long for most people.

There's also a few things that I would expect will be taken care of by Corporate IT (or however you call it — things like device setup)

That's it, though, something that probably fits on 4 pages of reasonable sized type-face. All in all.

If you're a startup, or starting — go ahead, be inspired by it.

Epistemology of policies

or, what's the thinking about policies.

I'm a convert to a tiered system of policies and associated documents.

  1. The policy. Your highest level commitment to doing something (e.g. a password policy shall exist, follow best practice, be reviewed by the board each year)

  2. The framework. Not everything will need a framework, but some specialized areas typically do. An example is a Risk Management Framework that sets out the methodology, matrices, risk universe, risk taxonomies, thresholds for escalation etc. You might also have a Vendor Management Framework, or a AI Framework.

  3. Standards These can be deeply technical (e.g. your encryption standard) or more general — e.g. a password standard might set out the rules such as:

    • not included in the top 100k passwords

    • people involved in procuring new systems must ensure support SCIM.

    • where possible, five random words generated by your password manager

    • the maximum length permitted by third-parties.

    • reflects best practices, e.g.

      • unlearn about password rotation (you must change your passsword every N days).

        • One of my favourite updates to v4 of PCI-DSS was abolition of forced password changes)

      • unlearn about three of upper, lower, number, special

      • learn that '3' is easy for the computer to understand is an 'e'

"To anyone who understands information theory and security and is in an infuriating argument with someone who does not (possibly involving mixed case), I sincerely apologize."

4. Guidelines These are more likely to be documents (including wiki pages) that are updated more frequently and which must be followed. You'll probably want a good password guideline that:

  • mandates the use of a named (e.g. 1Password) as the authorized password manager.
  • says to use SSO where-ever possible
  • and passkeys over passwords

Reviewers

Where possible, it's very sensible to have someone with appropriate competence to review any policy changes. This is especially useful where the policy is highly technical, specialized, or concerning risk or legal aspects.

Get that feedback, incorporate it (if it makes sense), and then, when it comes to submitting for approval, use that to say it's been peer-reviewed.

I'm in two minds about if this should be documented more than your committee papers — I think it depends on your stylistic approach and the tool you use — it could be:

  • a single line (Reviewed by: XXX, Job Title, YYYY-MM-DD)
  • a series of preserved comments
  • a 'final' comment, or
  • maybe as comments in a pull-request
  • a string of emails
  • a 'tracked changes' document

The workflow that works best for you will probably be more helpful — but try not to make it too technical so others can help you.

Approvals

Concerning approvals, this model has worked for me: