There is a term for when a business invests in a pile of documents and audits which are designed to earn them a security certification. We call this approach Paper Security – think SOC 2 Type 2, FedRAMP, or UK Cyber Essentials Plus (awful name but go on).
We call this approach Paper Security because the output is thin, full of captivating prose, and covers up real weaknesses with declarative intentions. If you can describe your business policies with 100 pages of documents change-managed within an ISMS, if you say you follow your own processes, and if you take screenshots of the right cloud configs, you may be awarded an approval from an auditing company that exists to perpetuate this paper game.
There are at least three reasons why businesses invest in Paper Security:
- they want to access customers which demand specific security certs — think financial, federal, and healthcare sectors
- they want to win a customer trust / feature comparison with a competitor
- they want a shortcut report answer to inbound security questions
None of these reasons are bad or wrong. Each is a reasonable incentive and can be hard to argue against internally, if a sales or IT department determines that the business needs to attain and maintain a certain certification.
The problem with Paper Security is that spending your limited resources describing how security should work means not spending those resources actually securing your systems. If the goal of your security strategy is to pass a specific test, your team will optimize for that outcome at the expense of more practical measures they could take.
My old colleague ran Infrastructure at one of the biggest managed cloud database providers in the space, and he told me that his org spent 18 months and $1.8m seeking FedRAMP authorization, only to find that the federal customers waiting on the other side were accepting low-ball bids from crony sub-providers, proposing under the authorization of some other shell umbrella corp. Game disrespect game.
Not all of the regulatory requirements themselves are terrible, but many do read that way. I’ll give you an example: NIST 800-53 is a dull mess of language ostensibly describing Security and Privacy Controls for Information Systems and Organizations, with guideline documentation helpfully titled NIST Privacy Framework and Cybersecurity Framework to NIST Special Publication 800-53, Revision 5 Crosswalk. Check out this riveting array of word-shaped letters:
Within this document there are some reasonably useful technical considerations, but the textual implementation is mind-bending, and asks for explicit compliance with inane propositions. Take ID.RA-2,
Cyber threat intelligence is received from information sharing forums and sources
If I need to spend a single minute writing a sentence describing how I do, indeed, get my intelligence from "sources", I am wasting time and money. Perhaps the spirit here is that I will disclose my sources, and those will be critiqued by auditors, but in reality this is simply not going to happen. This is boilerplate subcategorization at a painful granularity, like salt in a wound.
I'm picking on NIST in particular as they are infamous for using odd acronyms, microfonts, and impossible indices throughout their guidelines, which has created an industry of specialists who must memorize and explain this nonsense to businesses who choose to play this game. Policies and certifications must be renewed annually, which makes sense because the crosswalk gets repainted every year with new and more specific language, keeping this cottage crew in business.
At Startup.Security, we propose an alternative strategy towards practical durability which we call Scissor Security. Our approach is to cut through the bullshit, fix your most critical vulnerabilities, and do the practical things we know matter the most. This looks like good password hygiene and rotation, IDP/SSO, 2FA, least-privilege role-based access control, database encryption & secure backups, endpoint management, SSL, SAST in CI, and so on until we run out of essential things to do. The important piece here is that we sharpen your security along the specific axes that will impact your customer and data security the most.
We believe that what most companies need is quite simple:
- a checklist with clear questions and answers that describe security maturity
- a security hub to track issues by severity and remediation status
- a third-party software management system, including an index of vendors which interact with your customers’ data
Depending on your company’s size and complexity, building and managing these tools can be easy or hard. The goal is to start simple, stay sharp, focus on what is practical and effective first, and don't attend to empty edge case security which satisfies requirements without truly improving your systems.
Startup.Security is a no-nonsense partner in this process, and over the years we've helped growing companies get the basics right first, while preparing them for their next steps on the security journey. Reach out if you're interested in learning more.
