MODELO DE REESTRUCTURACIÓN DE LAS ESCUELAS DE EDUCACIÓN ESPECIAL:

Security vulnerability can have several definitions. The National Infrastructure Advisory Council (NIAC) defines security vulnerability in its "Vulnerability Disclosure

Framework" as

...a vulnerability is defined as a set of conditions that leads or may lead to an implicit or explicit failure of the confidentiality, integrity, or availability of an information system. Examples of the unauthorized or unexpected effects of a vulnerability may include any of the following:

• Executing commands as another user

• Accessing data in excess of specified or expected permission • Posing as another user or service within a system

• Causing an abnormal denial of service

• Inadvertently or intentionally destroying data without permission

• Exploiting an encryption implementation weakness that significantly reduces the time or computation required to recover the plaintext from an encrypted message U.S. National Institute of Standards and Technology (NIST) offer the following definition of vulnerability in its "Risk Management Guide for Information Technology Systems":

Vulnerability: A flaw or weakness in system security procedures, design, implemen- tation, or internal controls that could be exercised (accidentally triggered or inten- tionally exploited) and result in a security breach or a violation of the system's secu- rity policy.

Many more definitions exist for security vulnerability, but they tend to be variations of these two definitions. The one thing that can be noticed is that these definitions are more qualitative than quantitative in nature. That is not surprising because that is the only way the definition can be written. On the other hand, that can represent a problem when eval- uating whether something is a vulnerability.

Following are three examples showing how practical these two definitions are. The vul- nerabilities are default administrator password, weak cryptographic algorithm, and sus- ceptibility to denial-of-service (DoS) attack.

• Default administrator password: Enables anyone who can access the device to exer- cise full control over it. This is security vulnerability by any of the two definitions

because it enables an unauthorized user to access the device and modify it or, poten- tially, data residing in the device.

• Weak cryptographic algorithm: If you rely on a simple mono-alphabetic substitu- tion as in a Caesar cipher to protect confidentiality of data, this would qualify as security vulnerability. Caesar cipher can be deciphered in a matter of minutes using nothing more sophisticated than a pencil and a bit of a paper. But what if, instead of a Caesar cipher, you use Data Encryption Standard (DES)? It is common knowledge that DES is broken, and information encrypted using that algorithm can be decrypt- ed in a matter of hours or days given the sufficient computational power. A relatively inexpensive ($10,000 USD in 2007) machine, such as COPACOBANA, can break DES, on average, in 6.4 days (12.8 days worst case). For triple DES, it can take even longer than 12 days to decrypt the information by brute force. Now the question: If the confidential information must remain secret for only 30 to 60 minutes, is using DES to protect it security vulnerability? If breaking encryption takes two hours then DES might be sufficient for the purpose. What is obvious is that we can have a slid- ing scale that would mark when using DES becomes a product vulnerability. For some users, and for the purpose they are using the product, DES can be quite suffi- cient, whereas other users would consider DES a vulnerability for the purpose they are using it.

A different algorithm might require a longer or shorter time period within which it can be broken. The question is, How can you to determine what timeframe (to break the encryption) constitutes security vulnerability? Is it a vulnerability if you can break the algorithm in 10 years? What if you need 100 years to break it? There is no universal answer to this, but it depends on how the encryption is used and on the data encrypted. And a vendor cannot know what data will be encrypted. Another issue that must be considered is how to use encryption. Using DES to encrypt passwords and then storing them in a file to which everyone has access (as used to be the case in Unix operating systems) should be considered a product vul- nerability. That is because an attacker can mount an offline brute force attack that is devastating. Using DES as a part of Message Authentication Code (MAC), as used to be the case in Data Authentication Algorithm (DAA) in FIPS PUB 113 (now defunct) might not constitute a vulnerability even if protecting a file with DES is a vulnerabili- ty-

• Denial-of-Service (DoS): In this attack, a miscreant would consume a resource (for example, network bandwidth, central processing unit [CPU], memory, and disk space) so legitimate users could not perform their tasks. The NIAC's definition phrases this as "....a abnormal denial of service". The definition assumes an asymmetrical relation- ship in which an attacker uses relatively small effort to consume disproportionate larger amount of resources on the attacked device. Imagine a web server, with soft- ware running on the latest hardware with the fastest processor and a huge amount of memory. The device is connected with a Gigabit Ethernet interface to the network. All expectations are that this web server can serve a large number of connections per second. If an attacker can prevent the server from accepting any further connection by establishing ten connections per second, everyone would characterize that as a

security vulnerability But what if you now start to gradually increase the number of attacking sessions per second that is required to cripple the web server? At what number of sessions per second would unresponsiveness of the web server cease to be a vulnerability and become just a design or network limitation? Would that be at 100 connections per second? Maybe 1000,10,000, or 100,000? Again, the answer depends on the information served by that web server, but that is something that a vendor cannot know in advance.

From these few examples, it should be visible that determining what constitutes a securi- ty vulnerability is not always easy and straightforward. Sometimes things must be put into a wider context to make a proper determination. Users can have different expecta- tions and, if not fulfilled, may consider that as a vulnerability. Other times, how product or a feature is used can determine whether something is a vulnerability. This, however, does not mean that vendors should avoid improving products and removing such ambigui- ties even if they do not constitute a vulnerability in all cases. (For example, DES should be phased out no matter what.)