Security from the Start

The National Vulnerability Database contains about 75,000 known vulnerabilities.  And all of them were probably written by smart software engineers.  Oops.

My point is that security is very difficult.  Often engineers create a security problem in one area while trying to secure another.  In this post, I outline a few tips for creating some security in your business.  Notice, I said “business” and not “application” because, unfortunately, we live in a physical world and there are actual doors that need to be locked.

Think about security from the beginning

Assume that security will be important at some point in the life of your application and build it from the beginning.  Think about security as the the 13th factor in your application.  The moment you have users logging in, you need to store their passwords securely.  At that moment, you need to understand bcrypt.  You’ll need to understand TLS, too. In fact, there are so many security items that go along with your first user stories (e.g., “As a user, I need to log in.”), that you’re going to miss some, ignore some that are important, or botch their implementation. Unless…unless you’re brilliant or have someone on your team who has done this before.  My advice is to find someone experienced.

Physical security is security

Don’t ignore physical security. Your doors need locks.  You need to know who is in your office.  Your laptop also needs to lock itself.  And, hey, why isn’t your drive encrypted?  The physical aspects of managing your company’s information technology will quickly become a full-time job.  Think about your wired network and your WiFi, your password management, and onboarding and offboarding.  My advice is to find someone good here too.

Contract for penetration testing regularly

No matter how hard you try, you won’t find all your security problems.  We automatically run several static analysis tools on each code commit and use tools like Metasploit to probe our own networks.  It’s not enough.  Much like proofreading your own essay, finding your own security holes is difficult—for whatever reason, you’re blind to them.  Hire someone you trust.  Then, get hacked and mitigate, mitigate, mitigate.

Self audit

Be your own worst critic and seriously audit your own security.  Find a good framework like NIST’s or HIPAA’s and then step through your controls and compare them with what your framework requires. There are great lists of controls out there waiting for you. And again...mitigate, mitigate, mitigate.

Independent Audit

You’ll probably only contract for an independent audit if your market or customers require it.  However, the impact of a SOC-2 or ISO 27001 will be far less disruptive if you’ve taken my prior suggestions to heart.

Good luck with your security program!