Securability
Summary
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:
- Authentication
- Authorization
- Data Protection
- Auditing
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 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 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 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.
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:
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.
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.
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.
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.