What is Security By Design?
Security by Design is a road in security that enables businesses and organizations to set and automate infrastructure so that security can be built and structured from the bottom up. Security by Design helps organizations mitigate data breaches and hacking attempts before they are hit by a cyber-attack rather than repairing the issue and restoring systems after getting hit.
Information security relies on the three core pillars.
Confidentiality: Only authorized users are permitted access to data and resources.
Integrity: Data should not be altered by unauthorized users.
Availability: Ensuring that authorized users can access data and resources when required.
Security By Design always refers to these fundamental pillars whenever a new product is created and formulated as a solution. Whenever a new solution is created, here are some questions that you need to ask:
If I were evil, how would I exploit this feature or solution?
Does this solution need to be running by default? If so, how could I limit any risk related to it?
Is this solution safe, or is this a flawed process?
The Best security designs of architecture and design documents contain brainstorming and security discussions on every single feature and how the risks associated with every element will be handled and mitigated. Security is a Marathon and not a sprint.
These are security principles based on the OWASP development guide that must be planned when dealing with Security by Design.
Minimizing the Attack Surface Area.
Every single feature added to a solution or application adds a level of risk to the overall solution. The aim is to reduce this risk as much as possible.
Examples: Limiting the number of input parameters where it is not needed. The likelihood of an attack can be reduced as dynamic content cannot be added, and the ability to perform an attack like SQL injections is limited.
Establish the principle of least privilege.
Limit the number of users having permissions to data and resources.
This principle focuses on accounts having the least amount of privilege to perform their business duties. This entails user rights, permissions to resources, etc.
Create secure defaults.
A user's experience should always be secure irrespective of the user is a first-time user or a long-time user.
Example: Password complexity.
Secure Application Failure.
There are many instances that an application fails. This could be due to several reasons, it could fail during production, during a testing phase, faulty configurations, etc.
The application must fail securely, and how an application fails determines whether they are secure or not.
Keep Security Simple
Developers must keep security very simple and grounded.
Developers should avoid complex architectures, code, and methodologies.
Do not trust 3rd party services.
External systems and services with policies and security posture not aligned with your own should not be trusted and used if possible.
It is unlikely that you would have any influence or control over the externally provided service.
Separation of Duties
Someone who requests a laptop should not be the one assigning it not should they directly receive it.
There should be a clear separation of levels and duties.
Defense in Depth
When a developer adds one additional feature, the risk is reasonable, but when several features are added, the risks associated with them also add up.
When controls and defense are used in-depth, it makes the exploitation of solutions that much more difficult.
