Securability

Summary

• Overview
• Designing for Securability
• Testing for Securability
• Staying Secure
• Best Practices for Securability

Overview

Securability is about controlling access to a variety of resources such as software components, data, and hardware. Security measures are based on the following four concepts:

1. Authentication
2. Authorization
3. Data Protection
4. Auditing

Authentication

Authentication is confirming identity. A requestor must be authenticated before it can request access to a resource. The requestor establishes identity by passing in some form of credentials which is only known to the requestor and the authenticating host.

Authorization

Authorization is the process of verifying that an authenticated requestor has permission to access certain resources. Authentication does not imply authorization. Authentication is about 'who are you?' Authorization is about 'what are you allowed to access?'

Data Protection

Data protection is the process of providing data 1)  confidentiality 2) integrity and 3) non-repudiability. Data-protection is required not only when data is in transit from one place to another, but also while it is stored.

Confidentiality
Data confidentiality can be provided through encryption.

Integrity
Data integrity can be achieved through the use of hash-algorithms, digital signatures, and message authentication codes. A hash is a fixed-length string of numbers and characters. It is computed using a hashing algorithm such Message-Digest 5 (MD5) or other standard hashing algorithms. This hash value is then sent with the data where a receiver can then compare a hash value it calculates based on the received data with the actual hash value already supplied by the data. If the two values differ, then data integrity has been compromised.

Digital signatures take hashing a step further by encrypting the computed hash using a private key. This step prevents attackers from intercepting data, modifying it, and then simply re-computing the hash for the modified data. Because the hash is now encrypted, an attacker would need to have access to the original private used to decrypt the hash value. On the receiving end, digital signatures can be verified using the associated public key.

Non-Repudiability
Non-repudiability can be used to prove the origin, contents, and time-stamp of the data.

Auditing

Auditing is the process of logging and monitoring events that occur in a system and that are of interest to security. Auditing provides the key source of security forensics.

Designing for Securability

The security design process is cyclical. Application security depends upon the vigilance of developers and administrators during all phases of an application's life. Because new security threats arise almost daily, an application must be scrutinized constantly for potential security flaws. Application scrutiny may include all software development efforts - design, development, testing, and deployment. The following recommendations can be helpful when designing for securability:

• Analyze threats
  You must first analyze the security threats and risks that you application faces before you can select the correct security measures. Implementing security measures without regard to the actual set of threats your application might face will only give you a false sense of security. In other words, technologies and methods you chose to implement security must address the threats your are likely to encounter. To what level you implement them will depend on the level of risk that is acceptable to the application and its data, as well as the expenses. In general, any application may face any/part/all of the following STRIDE threats:
  
  • Spoofing Identity
  • Tampering with Data
  • Repudiability
  • Information disclosure
  • Denial of service
  • Elevation of Privilege

  Each is examined below:
  

  • Spoofing Identity
    This occurs when authentication has been compromised. This happens when an attacker hacks or can replay a user's authentication service. Using a valid user's credentials, an attacker can impersonate the user and gain access to applications and data authorized for the user. To prevent this, use strong authentication methods such as Kerberos authentication and client authentication certificates. Do not store authentication information in cookies or use self-designed authentication schemes, as these are often the weakest and most easily hacked.
    
  • Tampering with Data
    Data tampering is the deliberate manipulation or destruction of data. Data tampering can happen while data is in transit (electronically or physically) and where data is stored. Beyond controlling access, sensitive data must be encrypted with hashes and digital signatures. When in transit, data must be transmitted using secure end-to-end protocols such as SSL/TLS
    
  • Repudiability
    Repudiability is the notion of denying that an action has occurred. An example of repudiability is denying that you have received an items (when in fact you did) and expecting the vendor to supply another. Non-repudiability is often obtained through the use of digital signatures and timestamps.
    
  • Information disclosure
    The severity of information disclosure depends on the sensitivity of information being disclosed. For example, personal banking details are highly sensitive and its disclosure can be catastrophic. Many of the steps taken to prevent information disclosure are the same as those outlines in Tampering with data.
    
  • Denial of service
    Application availability and reliability are directly impacted by a Denial of Service (DoS) attack. DoS is a form of sabotage that makes applications unavailable for users. To defend against DoS attacks, most countermeasures consist of filtering incoming packets using firewalls to separate legitimate from malicious attacks. Also bandwidth throttling and resource throttling can prevent an overloaded web site from bringing down an entire server. You can use various measures to mitigate such threats, but none are absolute.
    
  • Elevation of Privilege
    Elevation of privilege occurs when a user obtains privileged access to parts of the applications that would otherwise be inaccessible to him/her. Applications should operate using the lowest security context - a managed application running in the CLR can only execute code for which it has permissions.
    
• Prioritize Threats
  Once you have determined the types of threats that your application is likely to encounter, you must then prioritize then with respect to potential damage and the cost of implementing appropriate security measures. To help you prioritize threats, you can use the following formula:
  
                   Risk = Criticality / Effort
  
  Where Criticality is a number from 1 to 10 ranking the importance of the resource being protected (10 being most important). Effort is also a number from 1 to 10 ranking the difficult of mounting an attack on the said resource. For example, for an e-commerce site, availability of the site is the most important because otherwise it would not make money. Therefore, for web-site availability, Criticality is 10.  If a certain attack is fairly easy to mount and hence its Effort factor is 1, then the Risk factor to availability form this kind of attack is quite high at 10.
  
• Apply Security Policies
  Once you have compiled a list of security threats ranked by risk, the next step would be to apply adjustments according to existing security policies. These existing security policies are typically dictated by the application consumer or management. In fact, these policies may even dictate re-ordering of the list of threats and their associated risks.
  
• Design Security Services
  After selecting the appropriate security technologies, you must then design security services around your application to mitigate the risks that you have chosen to mitigate. It is important to note that a well-designed security service will only lessen the chance of your application being successfully attacked. It is unlikely that an application will be 100% impregnable - that's why constant vigilance is always required. When determining the appropriate level of security for your data, consider the following:
  
  • Value of data (cost to create and cost to the organization if leaked to malicious users.)
  • Cost of security data.
  • Usability tradeoffs.

Testing for Securability

Security testing is about validating your application's security services and identifying potential security flaws.  Observe the following pitfalls when testing for securability:

• Because attackers are always inventive and have no standard of way of breaking into applications, there are no standard methods of conducting security testing.
• Because a functional bug in the application can also represent a potential security flaw, it is important to conduct functional testing before conducting security testing.
• Because security testing will never prove that an application is 100% secure, security testing will only validate the effectiveness of the instituted countermeasures.

Keeping the above points in mind, below are suggestions for testing the securability of your application:

• Test for Buffer Overflows
  This is one of the first security bugs exploited in computer history. Buffer overflows continue to be one of the most dangerous and most commonly occurring weaknesses. Buffer overflows can be used to crash the application or even to execute malicious code in the application process.
  
  Buffer overflow occurs when writing more to a buffer than it can hold - in the most basic example, writing 11 bytes to a 10-byte array. When a buffer overflow occurs, data is written into parts of memory that may be allocated for other purposes. A worst-case scenario occurs when the buffer overflow contains malicious code that is then executed.
  
• Conduct Source Code Security Reviews
  Depending on the application's sensitivity, it might be prudent to conduct a security audit of the application source code. Do not confuse a security code review with the standard code review. The standard code review is used to identify general code defects and adherence to company programming guidelines. Security code reviews on the other hand are used to identify security flaws, intentional or otherwise.  Security code reviews are espeically important when developing financial or sensitive applications.
  
• Validate Contingency Plans
  If security is thwarted, reactions must occur rapidly to prevent further damage. Find out if your contingency plans do work as expected.
  
• Attack your Application
  When attacking your application, look for exploitable flaws that represent a weak spot in the application's defenses.

Staying Secure

Applications evolve, new features are added, bugs are fixed, but at the same time, security threats evolve.  Therefore, it is important to conduct periodic security reviews to ensure that the application continues to be secure. The following are steps you can take to preserve the security of your application:

• Add Security Comments to Your Source code
  During the design and coding phase, you may have made numerous decisions regarding the implementation of security. Future developers who may maintain your code need to be aware of these decisions in order to fully appreciate the ramifications of modifying the source code. The best way to lessen this risk is by adding appropriate comments to your source code. Obviously the comments should clarify any assumptions, the intent of the code, and any dependencies on external resources.
  
• Regression Test Bug Fixes
  It is almost always the case that a bug fix unmasks other bugs. It is also possible to identify bugs after code has been released. Therefore, always regression test your application to ensure that security bug fixes do not jeopardize the application's security
  
• Regression Test Platform Changes
  When patching a platform or applications external to your own, you must be aware of how these changes will affect your application. For example, your application might have used some undocumented API that was no longer supported.
  
• Monitor Support Requests
   During the design phase, assumptions were made on how the application will be used. To validate these assumptions monitor support requests and discussions forms to evaluate real-world scenarios.
  
• Develop a Good Auditing Policy
  A good auditing policy requires that the application logs events of interest that takes place on your system. Timely audit trails facilitate the pursuit of perpetrators and the prevention of any possible damage.
  
• Monitor Not-Found Errors
  Not-Found errors (especially in Web applications) are client requests that could not be satisfied because they included a reference to a Web page that no longer exists (Error 404). Not-Found errors usually occur because a file has been deleted or moved to another location. However, some can result from attempts to access unauthorized documents
  
• Do Not Store Sensitive Information
  If at all possible, do not store sensitive information like credit card numbers. Sensitive data management is usually one of the most challenging aspects of designing a secure system.
  
• Encourage the Use of Least Privilege
  Design the application to require the least amount of access privileges. Doing so lowers the likelihood that an attacker can use your application as a stepping-stone from which to attack other applications. For example, if the application requires users to logon using a highly privileged account like the Administrator account, then an attacker who succeeds in logging can cause serious damage. 

Best Practices for Securability

The following best practices (presented in no particular order) are recommended for creating secure applications:

• Develop using the .NET Framework
  When attempting to access a protected resource, the permissions of all code in the call-chain are checked to ensure that have the required authorization. Essentially, the behavior of the code is constrained by the least trustworthy component in the call chain. 
  
• Exercise Constant Vigilance
  The price of security is constant vigilance. Part of being vigilant is performing timely audits of security logs to identify possible patterns of abuse and potential security breaches.
  
• Establish and Follow Security Procedures
  Security policies such as the following could be established:
  • Password lengths and expiration period.
  • Logon policies and auditing.
  • Intruder prevention processes.
  • Ownership/responsibility of user accounts.
  • Methods for key encryption.
    
• Secure Data
  By using IIS and SQL Server, you can leverage the security model of Windows servers. Also select technologies that use encryption to protect user privacy and data integrity across the network. For example, you can select a protocol standard for your site that is supported by the Internet community such as SSL, TLS, or IPSec
  
• Use Access Control Mechanisms
  Access control limits access to resources based on user's identities and their membership in various functional groups. Access control is typically used to control user access to network resources such as servers, directories, and files. 
  
• Use the Least-Access Approach
  A least-access approach should be used to secure assets that could be potentially under threat.
  
• Enable Strong Authentication
  Use authentication schemes that are integrated with the network operating systems. Strong authentication can be used to mitigate DoS attacks by ignoring anonymous packets.
  
• Encourage the Use of Strong Passwords
  Strong passwords contain seven or more characters, are case-sensitive, include numbers and punctuation marks, and not found in dictionaries.
  
• Use System-Integrated Authorization
  Do not rely on application-level authorization to control access to resources. Instead, use network-wide authorization schemes such as those found in Windows servers. This makes it easy for authenticated users to use the resources they need and for you to efficiently control access to these resources.
  
• Avoid Buffer Overflows
  When a buffer overflow occurs, data is written to other parts of memory that may be allocated for other purposes. Buffer overflows account for a large percentage of security vulnerabilities.
  
• Require Minimal Privileges
  Applications should not require Admin privileges to run properly. Any user, including malicious users, can wreak havoc in the system. 
  
• Use Layered Applications
  The securability of an application can be improved when an application is divided into several layers. Communication from one layer to another should only occur through specific channels, where each layer adds an additional barrier to entry by an attacker.
  
• Validate User Input
  Always check and verify that user input is correct and correctly formed before acting on it, as any user input has the ability to harm the system.
  
• Develop Contingency Plans
  When defending against an attacker, it is always best to have a contingency plan to fall back on when the defense fails. The steps that should be taken if an intrude was able to break in should be clearly outlined for operations personnel. Such plans should seek to minimize damage and determine the extent the application has been compromised. 
  
• Conduct Scheduled Backup
  Develop security policies that mandate clustering and solid backup practices to provide the most availability to users. A routine backup is one of the most important mechanisms of a disaster recovery plan.