Designing for Securability
The security design process is cyclical. The security of an application depends upon the vigilance of the developers and administrators not just during the design phase but also for the life of the application. Since new threats arise almost daily, an application must be scrutinized constantly for potential security flaws. However, the initial design of an application determines how often those flaws are likely to occur.
Security threats are any potential occurrence, malicious or otherwise, that can have an undesirable effect on the application. Vulnerabilities in the application or operating system make a threat possible. An attack on the application is an action taken by a malicious intruder to exploit certain vulnerabilities in order to enact the threat. The risk involved is the potential damage that attack can inflict on the application or even the business.
Analyze the threats
Before you can select the correct security measures, you must first assess the threats and risks your application faces. Security measures implemented without regard to the actual array of threats your application might face merely give you a false sense of security. The technologies and methods you choose will depend upon the threats you determine are likely to occur. To what extent you implement them will depend upon the level of risk that is acceptable for the application, the level of risk that is acceptable for its data, and the expense. The effort and expense should correlate with the value of what you are seeking to protect.
At Microsoft, we use the acronym STRIDE, which describes the following taxonomy of security threats:
- Spoofing Identity
- Tampering with Data
- Information Disclosure
- Denial of Service
- Elevation of Privilege
Let's examine each classification of the taxonomy to understand how your application is threatened and to identify suggested countermeasures.
Identity spoofing occurs when the method of authentication has been compromised. This can happen when an attacker has hacked or can replay a user's authentication sequence. Using a valid user's credentials, an attacker can impersonate that user and gain access to the areas of the application and data that are normally accessible to the impersonated user.
For example, authentication protocols that use passwords without encrypting them disclose credential information to an eavesdropper, who can then use this information to impersonate the user.
Use strong authentication methods, such as Kerberos authentication and client authentication certificates, to best prevent spoofing. For more information, see Overview of the Kerberos Protocol.
Storing authentication information in cookies and self-designed authentication schemes are the weakest and most easily foiled.
Data tampering is the deliberate destruction or manipulation of data. The tampering may or may not be detected until some time in the future. Data is threatened both in-transit (physically or electronically) and while it is stored.
For example, unprotected data packets can be intercepted and modified, or data can become corrupted due to execution of malicious code that has been executed by an attacker exploiting a buffer overflow vulnerability.
Beyond controlling access, sensitive data should be encrypted using hashes and digital signatures. When in transit, protected data should be transmitted using secure, end-to-end protocols, such as Secure Sockets Layer/Transport Layer Security (SSL/TLS) and Internet Protocol Security (IPSec). For more information, see the following articles from MSDN Magazine: Web Security: Putting a Secure Front-End on Your COM+ Distributed Applications (http://msdn.microsoft.com/library/periodic/period00/websecure.htm) and Web Security: Part 2: Introducing the Web Application Manager, Client Authentication Options, and Process Isolation (http://msdn.microsoft.com/library/periodic/period00/websecure2.htm).
Repudiability is the notion of denying that an action occurred. Denying that you received an item, when in fact you did, and expecting the vendor to supply you another is an example of repudiability.
Actions that you would otherwise not want an unauthorized user to perform should be logged. Such non-repudiability can also be obtained through the use of digital signatures and timestamps. For more information, see Event Logging.
Additionally, digital signatures can be used to help provide non-repudiability. For more information, see Hashes and Digital Signatures.
The severity of information disclosure is dependent upon the sensitivity of the information disclosed. For example, since medical data is highly sensitive, its disclosure would be a severe threat. In addition, disclosure of information about the application structure, such as path disclosure of a server-based application, can be equally threatening.
Many of the steps that can be taken to prevent information disclosure are the same as those outlined above to prevent data tampering. However, while being able to tamper with data typically requires the ability to modify it, exposing data does not.
Application availability and reliability are directly impacted by denial of service (DoS) attacks, which are a form of sabotage that makes applications unavailable to authorized users. DoS attacks occur when a system is flooded with traffic to the point that it is unable to process legitimate service requests.
There are numerous methods for launching a DoS attack, but most of the high visibility ones have been based on exploiting the shortcomings of the TCP/IP protocol or bugs in the operating system's TCP/IP implementation. As such, DoS attacks can be difficult to repel or even to predict. To make matters worse, DoS attacks are some of the easiest attacks to mount. The most basic DoS attack is the physical destruction of the computer hosting the application.
To defend against DoS attacks, most countermeasures consist of filtering packets using a firewall to separate legitimate from malicious packets. Also, bandwidth throttling and resource throttling can be used to prevent an overloaded web site from bringing down an entire server. You can use various methods to help mitigate such threats, but none are absolute. For more information, see Microsoft Internet Security and Acceleration Server (http://www.microsoft.com/ISAServer/).
An elevation of privilege occurs when a user obtains privileged access to portions of the application or data that are normally inaccessible to the user.
For example, an attacker could exploit a buffer overflow vulnerability to execute malicious code with the same security context as the application process.
Applications should operate using the lowest possible security context. A managed application running on the common language runtime can only execute code for which it has permission. For more information, see Securing Applications.
Also, managed applications are use type-safe code that helps prevent the occurrence of buffer overflows in the first place. For more information, see Type Safety and Security.
When developing with Visual C++, applications should be compiled with the /GS compiler switch. The /GS switch injects security code in functions subject to buffer overflows. For more information, see /GS (Buffer Security Check).
Prioritize the threats
Once you've determined the type of likely threats to your application, you must then prioritize them with regard to the potential damage and the cost of implementing appropriate security measures. To assign a rank to threat risks, use the following formula:
Risk = Criticality / Effort
Criticality is a number from 1 to 10 ranking the importance of the resource being protected (with 10 being the most important). Effort is also a number from 1 to 10 that ranks the degree of difficulty required to launch an attack on the resource.
For example, an e-commerce site will likely determine that the availability of its site is paramount and assign a ranking of 10 for criticality. After all, if customers are not able to make purchases the site cannot make money. A common threat to site availability is a SYN attack, which is a denial of service attack that exploits IP's three-way handshake model. Since such attacks are relatively easy to mount, the level of effort would rank a 1. Using the formula above, we can determine that the threat risk involved ranks a 10/1, or 10. Perform this calculation for each potential threat to your application.
Apply security policies
Once you have compiled your raw list of security threats ranked by risk, the next step is to make adjustments according to existing security policies that are typically dictated by the application consumer or management. These policies may dictate a re-ordering of your list despite the calculation you performed earlier.
Each item on the resulting list is then placed into one of three categories. The first category is comprised of those threats you have decided to ignore. Threats in this category may be those that do not warrant the expense or are of minimal risk, such as a DoS attack on an intranet application.
The second category is comprised of those threats for which you have delegated responsibility to a third party, such as an insurance company or application service provider (ASP).
Finally, the third category consists of threats for which you will take direct action to defend against by using technology or user education. The following sections discuss this category of threats.
Select security technologies based on threats
Since a multitude of security technologies can be used to defend your application, it is best to work with generic countermeasure concepts before selecting a specific technology. Doing so will help ensure the best technologies are chosen on their merits and not because they feature the latest buzzword.
Design security services
After selecting the security technologies you will use, the next task is to design the security services to mitigate the risks you have chosen to mitigate. It is important to realize that a well-built security service will only lessen the chance that your application will be successfully attacked. It is unlikely that your application will ever be 100% impregnable, which is why constant vigilance is a key aspect of security.
Practically all data held on computers has some value. Sometimes this value is small, such as simple e-mail messages between friends saying "Hi!" Other times the value is great, such as documents pertaining to military secrets or to business tactics and strategies.
When determining the appropriate level of security services for your data, you need to consider the following:
- The value of the data (the cost to create it, as well as the cost to the organization if the data is leaked to malicious users)
Note The cost to the organization if data is leaked also includes the intangible cost involving loss of client or shareholder faith.
- The cost of securing the data
- Usability tradeoffs