Security Commandments

Written by Harry Papadopoulos on 10/11/17

You’re probably aware of the 10 Commandments and their basic idea of living a happy life. Whether you think they’re a work of fiction, gospel truth or something in between, could we come up with a 10 Commandments of Information Security for this modern age?

Rules for good information security can’t be set in stone (and yes, that pun was intended). Sure there are standards and best-practices, but the threat landscape and the technology we use is always changing, and the good advice moves with it. So getting 10 Infosec Commandments might be a bit of a challenge, as we could easily run into the 1000s.

Setting the scene

Everyone, upon first discovering the internet, think they’ve hit an Aladdin’s cave, or unlocked the raw secrets of the Universe. But as we all know, with great power comes great responsibility (thanks, Spidey). Plus after only a short while, you soon see that there’s either too much of the same stuff and often not the actual result you’re after, or people arguing wildly about differences of opinion. Anyone’s who’s ever browsed Yahoo Answers, left a comment on a hot blog, or posted in any kind of forum can attest to this, I’m sure.

Security, to bring this back on topic, is no different: everyone’s ‘doing’ security to some degree or other and everyone thinks they’re doing it right. A lot of services, sites, and applications out there are not as secure as they should be, and for some this results in being hacked.

Thou shalt... think before you act.

Websites are popping up faster and faster, with anyone now able to write a fairly decent-looking website in a very short space of time. Gone are the days where cooking up a website took an in-depth knowledge of an arcane skill. It can take as little as an hour to have a website up and running, and there are many vendors and technologies to choose from. But will it follow best practices? Is it going to be secure? At this stage, probably not. And that’s a problem.

The solutions offered are usually on a pretty standard deal. The user has a virtual space to build all the applications they want and everyone is happy. The problem is in the interpretation of a 'secure' environment...

Vendor: “Our environment is secure, so you can host your services here.”
User: “Cool! Thanks guys. Now I don’t have to worry about security or update patch anything. Updating things is a pain.”
Vendor: “Errrr, no – that’s not how this works.”
User: “Yes it is. You said that the environment was secure! I cannot be hacked”.
Vendor: “We’re secure, but you’re leaving all the doors unlocked and the windows open.”

It’s easy to imagine the essence of the above conversation being a real-world one. It illustrates a fair level of understanding between different kinds of “security”.

Thou shalt be a target... whether you like it or not.

So who takes care of the security of the infrastructure and the applications? There are different kinds of systems with different configurations for different functionalities. Although a basic template can be used for the bare minimum of the configuration, this cannot be enough to ensure a secure site. Even the slightest configuration change in the system or an application can change the whole security posture. But when your business is up and running and customers are coming every day, everything seems fine. Perfect! But how long can you keep up before a hacker smells your success and decides it’s night-night time for your business? To put it more simply, how long ‘til you have a security breach?

A hacker doesn’t care who you are, only if you’re an easy target or not.

Thou shalt... never ignore infosec

So in to the story comes the security Jedis, who all-too-often are responsible for the security after the delivery. Or ideally the security before the delivery. Or sometimes the security during delivery. Or the security configuration based on the application/service that will be run. Or the compliance that will be needed for the service/application. Or the... you get the idea.

User: “Correct me if I am wrong, but isn’t that their job?”

Indeed it is. But often we’ve made their job harder by ignoring infosec from the beginning and designing things without security in mind.

Thou shalt... hack yourself

Have you ever tried to hack your own site to see if it’s secure enough? If that concept sounds odd, you may want to read up about penetration testing. The waters get deeper and darker now as we also deal with compliance requirements, especially PCI DSS, not to mention the financial implications of a breach.

Those penetration testing security Jedis will try to bypass your security, make sure you’re compliant, and even help you put everything right that they find wrong. All you have to do is ask.

Thou shalt... help yourself

Every person who helps or accesses your server and application will have an impact on its security. It sounds simple, but too many people don’t realise it. Make sure your developers work to security best practices always. And given that everyday some new vulnerability comes out that may affect you, the best commandment I can recommend is to keep everything regularly patched and updated.

  • Bulletproof are CREST approved

    CREST approved

  • Bulletproof are ISO 27001 and 9001 certified

    ISO 27001 and 9001 certified

  • Bulletproof are Tigerscheme qualified testers

    Tigerscheme qualified testers

  • Bulletproof are a PCI DSS v3.2 Level 1 service provider

    PCI DSS v3.2 Level 1
    service provider

  • Bulletproof have 24/7 on-site Security Operations Centre

    24/7 on-site Security
    Operations Centre

Get a quote today

If you’re interested in our services, get a free, no obligation quote today by filling out the form below.

By submitting this form, I agree to the Bulletproof privacy policy.