Security by design is the practice of building products with security in mind from the ground up. Instead of adding security as an afterthought after shipping a product, developers incorporate security into the architecture, the code, the testing and the deployment of the software. This is important since modern attack vectors seldom depend on a single vulnerability. Attacks depend on subtle mistakes, default insecurity, flawed assumptions and trust relationships.
Thinking like an attacker is not paranoia. Thinking like an attacker is realism. Attackers do not care about how beautifully the system was designed internally. What attackers care about are weaknesses in the system, trust relationships that can be abused and paths through the system to sensitive information or privilege escalation.
Early Start of Security
Most of the vulnerabilities come from the design stage and not the implementation stage. The programmer can select a comfortable flow for authentication, a liberal design for API, or a database structure that becomes difficult to secure later. This makes the task of fixing such problems after developing the product very costly and cumbersome. This is one of the reasons why security must be involved in the process from the beginning.
The first step towards designing a secure software system is identifying the things that can go wrong. What if there are some malicious inputs? What if a user accesses the other user's information? What if the service itself is compromised? What if there is an alteration in the third party dependency? These questions will help in exposing the risks.
When security is integrated into the design, it helps in selecting the safer defaults, reducing the privilege where unnecessary, and having a better trust boundary.
Think like An Attacker
Programmers don’t have to be hackers, but they should think like attackers at certain times. Programmers need to find places where assumptions can be broken. For instance, when programmers assume that a request comes from a trusted client, it is good to find out whether this request can be forged. When a programmer assumes that a function is accessed by only trusted users, he should find out whether this assumption is valid. If programmers make an assumption that the file being uploaded is of a certain type, it is good to consider the case when this assumption is wrong.
An attacker tries to use the easiest way. It is good to do the same thing, but to defend against attacks. Programmers have to find out where there is trust, where some kind of input is provided, where secrets are hidden, and where some kind of privileges are provided. Sometimes, the most vulnerable spot is not the obvious one. It is the spot that programmers simply forget about.
It is good to use this approach when reviewing code, when designing architectures and when doing threat modeling.
Common Design Flaws
A first mistake developers make is believing in client-side access control. If an application depends on the logic of a browser to define restrictions, then attackers are likely to be able to circumvent these restrictions. Another common mistake is to use wide service permissions since they are easier to maintain. The extra privileges lead to unnecessary risks of compromising the account or process.
Hard-coded passwords, poor management of sessions, lack of rate limits, and insecure file upload are some other common flaws. They tend to seem unimportant during development yet become critical problems in production. An application might work correctly, yet remain vulnerable to attacks.
Finally, one common assumption of developers is the safety of internal systems. After getting access to them, the attacker finds it easier to navigate and move in them due to flat architectures and poor isolation of services.
Designing for Security
Security through design requires that security decisions be made during the entire development process. This includes the design of the system's architecture in terms of its boundaries, its privileges, its authentication processes, and its trust relations. Sensitive functionalities must be segregated, and accesses should be permitted only when required.
This implies that the code must be designed defensively. Input validation and error handling, along with avoiding exposure of sensitive information in logging and responses must be performed during the coding process. Authentications and authorizations should be enforced on the server side, rather than depending upon the client-side validation.
Moreover, testing plays an important role within the design process. Security testing should include abuse testing in addition to user behavior testing. Developers need to think about how their application would behave in case of malicious or invalid input, session hijacking, permissions modification, or any other unexpected situation.
Why the Developer Matters the Most
The developer is responsible for creating the architecture of the system even before any security software gets involved. While a secure scanner will identify some weaknesses, it won't be able to address issues with the design itself. For that reason, the developer plays a significant part in the security process. He or she chooses the way of dealing with trust, managing data, controlling access, and limiting failure spread.
The attack-minded developer is likely to produce the better product. He or she is more likely to spot risky simplifications, challenge assumptions, and create something less exploitable and defendable. Even though this approach will not make your system completely secure, it will increase its resilience significantly.
Security by design can be viewed as self-restraint. The developers should stop to consider all possibilities before shipping any problem to the production environment. In a modern world with ever increasing number of automated opportunistic attacks, this is one of the best defensive strategies.
Find more resources on cybersecurity, threat intelligence, digital risk, privacy compliance, and consent management through IntelligenceX and ConsentX. IntelligenceX helps organizations identify and understand emerging cyber threats through focused digital intelligence analysis and investigations, while ConsentX empowers businesses to achieve global privacy compliance with comprehensive consent management, cookie compliance, and data privacy solutions.
Top comments (0)