Metaphors in Security

Domain Specific Metaphors can help users to understand security especially when there is no physical example of it such as in the case of public key encryption. A metaphor to explain public key encryption would consist of a public lock and a private key. Open locks for an email address will be widely distributed so everybody shares the same key and can close the lock (secure) the message for everybody else. When a message is secured with a lock (encrypted with a public key) it would then in the closed state and therefore impossible to open without the private key held by the recipient. Every recipient could only unlock the message with the use of their private key. This is all perfectly natural and well understood from the use of padlocks and keys in the physical world. The sender's copy of the message would be associated with his or her own lock as the security mechanism, allowing users to understand the role played by their own keys.

Empirical Formulas in Security

When you need to explain a difficult concept, sometime is easy to visualize it through empirical formulas. Another good way is visualize a concept with metaphor (my next post). In security I found out useful the following formulas:

Security depends on policies, tools and commitment from management:

Security= (Policies^2+Tools)*Commitment

In the formula there is more emphasis (importance) on policies and procedures than tools.

If I change policies by a factor of 2 than security changes by a factor of 4. If I change tools by a factor of 2, security changes by a factor of 2. Basically there is more payoff on changing policies and procedures than tools. Commitment is the most critical since is a multiplier. If there is no Commitment there is no security nullifying all the roll out of policies and the expense on buying tools.

Interesting empirical formulas can also be used to explain risk. Assume the basic formulation:  a Technical risk is the likelihood that threat will exploit a vulnerability to cause an technical impact to the system:

Technical Risk = Threat X Vulnerability X Impact

If you would like to put the emphasis on assets as relate to impact you can also formulate risk as: Risk is the probability of an attack on an asset exposed by vulnerability, Qualitatively can be HIGH, MEDIUM or LOW:

Qualitative  Risk = Vulnerability * Asset * Attack

For example there is a threat but the application is not vulnerable (Vulnerability=0) so there is no risk. Or there are both threat and a vulnerability but there is no asset data (Asset=0, Impact=0) so there is no risk.


Keep in mind that these are empirical formulations for qualitative analysis and not formulation for quantify risk while doing a cost vs. benefit risk analysis such as cost of loss vs. benefit of money invested in security control. The risk of quantitative loss can be formulated as Annualized Loss Expectancy (ALO) = Single Loss Expectancy (SLO) * Annual Rate Of Occurrence (ARO)).

ALO =  SLO * ARO

You can use these risk qualitative formulas to introduce the concept of security risks and of the main factors that can be used for qualitative risk analysis.

Where Cryptographic Service Providers store keys?

Security is all about the key, so the question is where and how Cryptographic Service Providers CSP store the keys. Each CSP store cryptographic keys persistently in his Key Database
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncapi/html/msdn_cryptapi.asp
Each key database contains one or more key containers, each of which contains all the key pairs belonging to a specific user (or CryptoAPI client). Each key container has a unique name. There are usually two key pairs in each container: a key-exchange key pair and signature key pair. One key pair is used to encrypt session keys and the other to create digital signatures.
It is interesting to notice that CSPs uses to store keys in the windows registry. In Windows NT, the Microsoft providers store their key containers in two locations of the system registry. The locations are HKEY_CURRENT_USER\Software\Microsoft\Cryptography\UserKeys and HKEY_LOCAL_MACHINE\Software\Microsoft\Cryprography\MachineKeys. The former is usually used by a stand-alone application, and the latter by a process running on behalf of a non-interactive user, such as an IIS/ASP application.

In Windows 2000/XP, Microsoft decided to move the key containers from the system registry to file system. They can now be found under the directories '%SystemDrive%\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys' and '%SystemDrive%\\Documents and settings\\Application Data\Microsoft\Crypto\RSA\

More on managing Cryptographic Providers and Contexts on http://www.aspencrypt.com/task_learn.html

Effectiveness of web application testing tools and future trends

The two most relevant metrics for determining effectiveness of a web application testing tool are the number of vulnerabilities discovered and the number of false positives generated. False positives can cause, in many cases, the requirement of heavy manual labor to filter out false readings from huge amount of data.
The most advanced tools such as the ones that perform heuristic attack detection, have evolved from simple pattern matching (e.g. 404 error page detection) to slightly more flexible detection (e.g. user-configurable regular expressions).
Future trends will evolve into heuristic detection, which will consist of auto-generating detection through zero-day defense technology. Zero-day defense technology is the ability to learn from a pattern of known vulnerability behavior and then rule all unknown behavior as false positives (the same way some intrusion detection systems work today).
Currently, security testers use multiple tools, including commercial and open source tools and augument the tool deficiencies with manual analysis of the results. Just rely on tools analysis is not a guarantee of finding major vulnerabilities in an application. Overall most tools do not find more than perhaps 25-50% of known vulnerabilities in a typical application.
Some tool vendors allow users to extend the product capabilities by adding their own scripts or exploits which can help in increasing the number of vulnerabilities found, as well as to reduce false positives. Clearly, as the technology progresses, the sophistication of these products will continue to improve. In the meantime, there is no real substitute for the tester knowledge of application security. Testers need to focus on the most important security requirements, write a test plan and use tools that allow for both manual and automated analysis. Tools are only one factor of the equation, the other are people and process. Before to reccomend a tool for your organization, perform a proof of concept, especially look for flexibility in customizing the tool and to extend the tool functionality.

J2EE vs .NET Security References

How J2EE compare vs .NET security? The following articles cover a nice comparison:
Java vs. .NET Security, Part 1 Java and .NET address similar code security issues, but which one offers the best security implementation? Denis Piliptchouk's series starts with a side-by-side look at how each performs configuration, code verification, and memory isolation.
Java vs. .NET Security, Part 2 Java and .NET address similar code security issues, but which offers the best security implementation? Denis Piliptchouk's series continues with a look at cryptography support.
Java vs. .NET Security, Part 3
Java and .NET address similar code security issues, but which one offers the best security implementation? Denis Piliptchouk's series continues with a look at how each platform handles code protection and code access.