blog/content/2018/03/unusable-insecurity.html

---
title: Unusable Insecurity
description: >
  When people make security hard, no one will use it [properly].
posted: !!timestamp '2018-03-16'
created: !!timestamp '2018-03-16'
time: 1:40 PM
tags:
  - security
---

Many people claim that security is hard, and in many cases it is hard,
but that isn't an excuse to make it harder than it needs to be. There
are many layers to security, but adding extra layers, or making security
controls inscrutable is a great way to ensure insecurity. Security needs
to be simple and straightforward to configure, and easy to understand.
There may be knobs for advanced users, but defaults need to be simple and correct.

I recently looked at using S3 as a shared store for some data. I was
using the account New Context created for me that had limited AWS
permissions. Creating the S3 bucket was simple enough, and making it
not-public was too, but then I wanted to create a user/API key that only
had access to the S3 bucket. Per Amazon
[IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html),
you should not share your account, but create new users for access. It
turns out that I did not have the CreateUser permission. I involved a
co-worker who did have permissions to create the user. Adding another
person to the task makes things more complex through communication and
their availability to work on it instead of their normal work.

As part of creating a user, you have to figure out what the Policy that
you need to assign to the user. Amazon provides some
[Bucket Policy Examples](https://docs.aws.amazon.com/AmazonS3/latest/dev/example-bucket-policies.html),
but none of them is a simple policy on granting read and write permissions
to the bucket. There is an
[Amazon Policy Generator](https://awspolicygen.s3.amazonaws.com/policygen.html)
for helping you to create the policies, but it doesn't allow you to
select buckets from your account (to simplify ARN [Amazon Resource Name]
selection), and there are almost 70 actions provided in the selector.
After some brief reading, I settled on a simple policy that I thought
would allow the new user proper access: 4 permissions: PutObjects,
GetObjects, ListObjects and RestoreObjects.

My co-worker created the user and applied the policy, but then I got an
error handle code. Amazon does not provide an interface for turning on
logging and/or querying why a request failed. Despite the error handle,
I had ZERO insight into why the request failed. I could have involved
AWS support, but now that would add yet another party in attempting to
properly configure S3.

At this stage, I decided to give up, as I had already spent a few hours
of my time, some of my co-worker's time, and a couple weeks due to
various delays due to availability and other work. In this case, storing
the data in S3 was more of a nicety, and I decided that checking the
data into a private git repo was adequate compared to the complexities
involved in configuring S3. git was a tried and tested way to store data
and restrict access while S3 for this usage was not, and hard to
configure.

After I wrote this blog post, a coworker linked me to the blog post titled
[Writing IAM Policies: How to Grant Access to an Amazon S3 Bucket](https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/).
It is concerning that this blog post has not been integrated, nor linked
to from any of the IAM or S3 documentation. This is a valuable resource
that should not be hidden.

I'm clearly not the only one that has had issues configuring S3 buckets.
The end of 2017 has shown a large number of organizations fail to
properly secure their S3 buckets, leaving many terabytes of data open
for public download. It is unacceptable that such a service is so
difficult to configure. The site
[https://s3stupidity.com/](https://s3stupidity.com/) lists the large
number of breaches, many of which are by large companies who should
have the technical chops (and $$) to properly configure it.

Security controls need to be simple and clear. Their descriptions need
to be accurate and concise in what they do, and how they do it. Amazon
does have a number of good resources, but they do not have a
comprehensive guide for what each permission does. You cannot blame
users for security failures when you make it next to impossible to
configure properly.

Edited to remove a couple extra words.