To truly follow the Security by Design principle, security needs to be part of a system at the design stage. When designing architecture, it’s particularly important to make certain components trusted if system security goals depend on them. But the question is how?
The most intuitive option is to go through every component individually and determine how trustworthy each of them is. The most trustworthy can be deemed trusted, and all the others not trusted. But in this case, you’ll end up trusting components that don’t really affect the achievement of security goals. Instead, you’ll get components that are good, but maybe not critical when it comes to security goals. So what should you do?
In movies, the world is often destined to be saved not by an experienced hero who deserves the honor, but by some random kid chosen by an unexpected turn of fate. The Chosen One goes through trials and tribulations, grows up, finally becomes worthy of his destiny, and then fulfills it.
But things get tricky when selecting which components to trust: components are chosen as trusted not because they deserve this trust initially, but because fate has deemed it such (or in our case, security goals). Then they’re made trustworthy using code analysis.
But this begs the question: suppose a component is “destined” to be trusted, but it’s completely unsuitable for the job, maybe because it has a huge attack surface and complex functionality. Making a component like this trustworthy is too expensive. So what then?
Example. A web server is responsible for authenticating users on the site. It’s almost impossible to make it a trusted component because of its huge size. So it’s better to create a separate authentication service responsible for one narrow task, and place it outside the web server. Then you can make this new service trusted and leave the web server not trusted. This way, the cost of the system guaranteed to fulfill security goals (in this case, related to authentication) won’t be unreasonably high.
Example. To implement the TLS Terminator in our solutions, we chose the compact Mbed TLS library. It was much easier to check and make trusted than, for example, OpenSSL.
Ultimately, being trusted and trustworthy aren’t the same thing. Trust is required in relation to system components that are critical to security. Then they become trustworthy after all the verification procedures.
To truly follow the Security by Design principle, security needs to be part of a system at the design stage. When designing architecture, it’s particularly important to make certain components trusted if system security goals depend on them. But the question is how?
The most intuitive option is to go through every component individually and determine how trustworthy each of them is. The most trustworthy can be deemed trusted, and all the others not trusted. But in this case, you’ll end up trusting components that don’t really affect the achievement of security goals. Instead, you’ll get components that are good, but maybe not critical when it comes to security goals. So what should you do?
In movies, the world is often destined to be saved not by an experienced hero who deserves the honor, but by some random kid chosen by an unexpected turn of fate. The Chosen One goes through trials and tribulations, grows up, finally becomes worthy of his destiny, and then fulfills it.
But things get tricky when selecting which components to trust: components are chosen as trusted not because they deserve this trust initially, but because fate has deemed it such (or in our case, security goals). Then they’re made trustworthy using code analysis.
But this begs the question: suppose a component is “destined” to be trusted, but it’s completely unsuitable for the job, maybe because it has a huge attack surface and complex functionality. Making a component like this trustworthy is too expensive. So what then?
Example. A web server is responsible for authenticating users on the site. It’s almost impossible to make it a trusted component because of its huge size. So it’s better to create a separate authentication service responsible for one narrow task, and place it outside the web server. Then you can make this new service trusted and leave the web server not trusted. This way, the cost of the system guaranteed to fulfill security goals (in this case, related to authentication) won’t be unreasonably high.
Example. To implement the TLS Terminator in our solutions, we chose the compact Mbed TLS library. It was much easier to check and make trusted than, for example, OpenSSL.
Ultimately, being trusted and trustworthy aren’t the same thing. Trust is required in relation to system components that are critical to security. Then they become trustworthy after all the verification procedures.
