What's This?
Whether you need to build it from scratch, refactor it the best you can, or just a fan of "Doing-It-Yourself" - Security Best Practices (SBPs) is the cyber-perfectionist best friend.
SBP is, and should be regarded, as a heavy-duty instrument - it is used when information security has to be taken seriously for compliance/regulatory reasons, or when a project is too big or too important for information security to be left out of your milestone designs or PRD.
Theoretically, a "Best Practice" is a term used to describe "the best way of implementing something", Security Best Practices (or SBP) is "the best way of securing or implementing something securely".
Practically speaking, Security Best Practices are provided as a set of actions that are required in order to answer all possible security requirements in a given context.
SBPs hold a great similarity to Security Implementation Plans, although SBPs, are significantly more comprehensive with respect to the solution setup context:
Domain SBPs (Technology Non-Specific) - the highest level of abstraction, includes Best Practices relevant to a certain technological domain - Identity Access Management (IAM), Data Protection, Networking, Auditing, Computing, etc.
Technology Specific - Security Best Practices which are provided to a certain technology (a brand), e.g. PostgreSQL, HDFS, Kafka
Case Specific - non-of-the-above; certain stack situations may require "special care" and SBPs could be affected as a result of specific conditions. e.g.
multi-tenant infrastructure with dynamic computing arrays per tenant
multi-vendor cloud infrastructures
legacy systems that has to securely integrate with new components.
As you can see, Security Implementation Plans describe the actions needed to achieve specific Security Requirements, while SBPs include the actions needed to achieve every Security Requirement possible within a given context.
What You're Getting?
The highest security level possible (if fully implemented) - as mentioned Security Best Practices is a heavy-duty, which aims to "overkill" information security risks, and prevent them almost completely.
A robust, step-by-step, practical means for you to secure your solution in the best way possible, potentially from scratch.
SBP document are updateable, and can be updated on a regular time basis at lower costs.
OwnSec treats Security Best Practices as dev-projects for all intents and purposes. Updates about plan progression are provided on a chosen time basis and access to the plan can be achieved at any time.
Extra hours for Implementation Consultancy or pair-programming - free of charge.
How It's Done?
Although Security Best Practices is significantly bigger than Security Implementation Plans in terms of size, it has a similar procedure which is also rather straightforward:
The solution setup context of the SBPs, as well as the technologies within it, are thoroughly reviewed along with other business factors (e.g. schedule and resources).
Once all preconditions are agreed upon - Information Security Requirements are gathered with regards to the solution setup context and existing technologies within it. When dealing with SBPs - these requirements would stem from official practices and InfoSec standards/methodologies, as well as from additional compliance/regulation requirements, PRF/HLD (solution definition documents).
Once everything is set, the SBP development phase begins.
Delivery - if required, SBPs can be delivered incrementally over time in order to meet time schedules, otherwise delivery is scheduled regularly, on a specified date.
