“Si vis
pacem, para
bellum” (i.e., “who wants peace, prepares for war”) is a Latin adage adapted from a statement found in Book 3 of the Roman author Publius Flavius Vegetius Renatus’s “tract De Re Militari” (fourth or fifth century). Many centuries before, Chinese General Sun Tsu has already claimed in his famous treaty “The Art of War”:

He will win who, prepared himself, waits to take the enemy unprepared.

Cyber security is a war between two opponents. On one side, the security designers and practitioners defend assets. On the other, cyber hackers attempt to steal, impair or destroy these assets. Most of the traditional rules of warfare apply to cyber security. Thus, “The Art of War” is a pamphlet that any security practitioner should have read.

Be proactive; a static target is easier to defeat than a dynamic one. Security defense should be active rather than reactive where possible. Furthermore, security is aging. Thus, the defenders must prepare new defenses and attempt to predict the next attacks. The next generation of defense should be available before the occurrence of any severe attacks. Of course, they must be different from the previous versions. The new defense mechanisms do not need to be deployed immediately. In most cases, their deployment may be delayed until their impact will be optimal. The optimal time may be immediately after the occurrence of an attack, or only once the loss occurred would be higher than the cost of deploying the new version. The optimal time may be when it hurts at maximum the attackers. For instance, a new generation of Pay TV smart card may be activated just before a major broadcast event.

Being proactive is also a rule for day to day defense. Do not wait for that a hack was detected to check your logs. Do not wait for an exploit to hit your system to learn about latest attacks and new tools. Do not wait for a hack to exploit unpatched systems, patch the system as soon as possible.

Design for renewability; according to Law 1, any secure system may be compromised one day. The only acceptable method to address this risk is renewable security. Every secure system must be renewable in the case of a successful hack. Without renewable security in its design, a system is doomed. Nevertheless, to ensure secure renewability, the kernel that handles renewability cannot be updated in the field. This kernel must ensure that attackers cannot misuse this renewability mechanism for their own purpose and that attackers cannot prevent the renewal. This kernel must also make sure that the attacker cannot roll back the updated system to the previously vulnerable version. One element of your trust model is probably that this kernel is secure.

Do not rest on your laurels; complacency is not an acceptable mindset for security practitioners. They must constantly be vigilant. The attackers are adapting quickly to new defenses and are creative. Some attackers are brilliant. If the defender did not detect a breach in the system, it does not necessarily mean that this system is secure. It may be that the breach has not yet been detected.

This is the fourth post in a series of ten posts. The previous post explored Law 3: No Security Through Obscurity. The fourth law is one of my preferred ones. The most futile reason is that I am an X-files fan (I want to believe) and it was a recurrent tagline. Now, the serious reason is that a key element of every system. Usually, my first detection test of snake oil is asking the vendor what the trust model of the system is. If the vendor has not a clear answer, it smells bad. And it becomes worrying if the vendor has no idea what a trust model is.

Trust is the cornerstone of security. Without trust, there is no secure system. It is the foundation of all secure systems. But what is trust? I like to use Roger Clarke’s definition.

Trust is confident reliance by one party on the behavior of other parties.

In other words, trust is the belief that the other parties will be reliable and that they are worthy of confidence. Other parties may be people, organizations such as Certification Authorities (CA), systems, software or hardware components.

Know your security hypotheses;
it is not possible to build a secure system without knowing the security assumptions. They define the minimal set of hypotheses that are supposed to be always true. This is the trust model. It is mandatory to identify and document the trust model thoroughly. Whenever one of these hypotheses is not anymore true, the system may not be secure anymore. Any change in the environment or context may invalidate the assumptions. Therefore, hypotheses must be continuously monitored as the system evolves to check whether they are still valid. If they have changed, then the design should accommodate the new security hypotheses.

An example is the current trust model of Internet when using TLS. The basic assumption is that the CA is trustworthy. Unfortunately, with modern browsers, this assumption is weak. By default, most browsers trust many trusted root CAs. The current Internet has more than 1,500 CA that the browsers trust. Only one wrongdoer amongst them is sufficient to weaken https.

Minimize the attack surface; Medieval castle builders new this consequence of the fourth law. They designed small, thin apertures in the walls that allowed observing at besiegers and the firing at them arrows with bows. The smaller the aperture was, the harder for an attacker it was to hurt the defender with a lucky arrow strike. Attackers will probe all the possible venues for breaking a system. The more the number of possibilities available for the attacker to try, the higher the likelihood that the attacker will succeed in finding an existing vulnerability. It is thus paramount to reduce the attack surface, i.e., the space of possible attacks available to an attacker. For instance, the current migration to the public cloud increases the surface attack compared to the traditional approach based on private data centers. This migration stretches the trust model.

Provide minimal access; a secure system should grant access only to the resources and data that the principal needs to perform his function. Access to any additional unnecessary resources or data is useless and creates an unnecessary potential risk. The consequence is that the role and function of each principal have to be clearly defined and thoroughly documented. For instance, there is no valid reason why the accounting team should have access to the shared repositories of the technical teams. This rule is very similar to the rule of least privilege and an illustration of minimizing the attack surface.

Keep it simple; complexity is the enemy of security. The more complex a system is, the higher the likelihood is that there is an error either in its design or its implementation. The error may turn into a security vulnerability that an attacker may exploit. Many vulnerabilities are due to software bugs. Protocols such as TLS become more and more complex, making their implementations more vulnerable.

Be aware of insiders; while
the attack usually comes from outside the trusted space, unfortunately, sometimes, the attacker may be an insider. The attacker will either accomplish the attack herself or knowingly be an accomplice in it. Sometimes, the insider may even be tricked into facilitating the attack involuntarily, for instance, through social engineering. Therefore, the trust within the trusted space should not be blind. Due to their privileged position, insiders are powerful attackers. Any security analysis has to tackle the insider threat.

Of course, security must trust some elements. There is no security with a root of trust. Never trust blindly. Trust wisely and sparsely.