Seguridad en Base de Datos

Ing. Alfredo Juan Haln Tafich M.C.

Traduccin de palabras tcnicas

Data breach:
Organization asset:
Forensic analysis:
Security regulations:
Regulatory compliance:
Data encryption:
Threat:

Fuga o prdida de datos.

Activos de la organizacin.
Anlisis forense.
Normas de seguridad.
Cumplimiento de normas.
Cifrado de datos.
Amenaza.

Chapter 1: Security Regulations

The cost of a data breach

Data constitutes organizations most important and prized asset.

Information can describe an institutions relationship with its
customers, competitive or proprietary processes, trading
relationships with partners, and tactical and strategic positioning
against their competitors.
When data is lost or stolen, real and significant damage can
occur.
Potential costs associated with Developing and Understanding.
Additional security infrastructure, such as encryption and auditing
solutions.

Actions after a data breach

Forensic analysis and internal investigation of the theft.

Notification campaign, emails, phone calls, letters, and so on.
Call center costs due to increased volume of customer traffic.
Legal costs for defense and investigation.
Internal investigations resulting in mitigation.
Classify to salvage customer and investor relations.
Fees and penalties.

Indirect Costs after a data breach

Loss of employee productivity.

Erosion of customer base due to loss of confidence.
Reticence for new customers to establish relationships.
Reduced shareholder confidence and value.
Decreased competitive standing.
ROI Calculation.

Regulatory compliance

Health Insurance Portability and Accountability Act of 1996.

(HIPAA)
Gramm-Leach-Bliley Act of 1999. (GLBA)
Sarbanes-Oxley Act. (SOX)
California Senate Bill 1386. (SB 1386)
Payment Card Industry Data Security Standard. (PCI)
IBM Data Server Security. (ISS)
Ley Federal de proteccin de datos personales en posesin de
los particulares (LFPDPPP)

HIPAA

Also known as Public Law 104-191 or the Kennedy-Kassenbaum

Bill, is an act passed by the U.S. Congress and signed into effect
on August 21, 1996.
Guarantee health insurance coverage of employees.
Reduce health care fraud and abuse.
Implement administrative simplification to augment effectiveness
and efficiency of the health care system.
Protect the health information of individuals against access
without consent or authorization.

GLBA

Enacted on November 12, 1999, approximately seven months

after the merger between Citicorp and Travelers Group to form
Citigroup.
Ensure the security and privacy of customer information.
Protect against threats to the security and integrity of customer
information.
Protect against unauthorized access or usage of this information
that could result in harm or inconvenience to the customer.

SOX
Passed by the U.S. Senate and the U.S. House of
Representatives with large majorities and signed into law on July
30, 2002.
Audit committee issues.
Audit committee expertise.
Enhanced review of periodic disclosures.
New oversight board for corporate governance.
Certification of financial statements.
Improper influence of conduct of audits.
Forfeiture of bonuses and profits (in some cases).
Off-balance sheet transactions.
Pro-forma financial information.
Dealings with securities analysts.

SB 1386

In September 2002, the Governor of California signed Senate Bill

1386 into effect.
In effect this means that any business that maintains personal
information of a resident of California must have the appropriate
provisions and capabilities to know when this information may
have been accessed by an unauthorized person.

PCI

The standard includes 12 requirements across six categories,

concentrating on data authentication, access control, audits, and
data encryption. To comply, companies that handle payment card
information are required to establish stringent security policies,
processes, and procedures.

ISS

Securing data requires a holistic and layered approach that

considers the broad range of threats. This is commonly referred to
as defense in depth, and requires a security by design approach,
where multiple layers of security work together to provide the
three ultimate objectives of security, commonly known as the CIA
triad: confidentiality, integrity, and availability.

LFPDPPP

Como aplica?
Dnde empieza?
Que incluye el aviso de privacidad?
Como se cumple con la Ley?
Existe alguna solucin tecnolgica?

Chapter 2: Database Infrastructure

Database Components

Database Server Infrastructure

Network Components
Application Structure
Clients (End Point)

Database Server Infrastructure

Server Hardware
Server Operating System
Windows
Unix
Linux
Server DBMS
Oracle
Informix
DB2
SQL Server
Etc.

Network Components
Core Switch
Switches
Routers
Access Points

Application Structure
Language Programming
Visual Basic
PSP
Etc.
SQL elements
Database
Tables
Store Procedures
Etc.

Clients (End Point)

Traditional PC
Screen emulation (3270 type)
Bar code reader
Printers and scanners
Internet access

Chapter 3: Database Elements

Database Elements
Tables
Primary Key
Foreign Key
Indexes
Unique
Multiple
Synonyms
Views
Etc.

Data Model
Entities
Associations
1-1
1-M
M-M
Normalization

Primary Key
A primary key is a column or group of (non-superfluous) columns that
insures the uniqueness of rows within a table. A primary key that
consists of more than one column is a composite primary key.
Primary keys do not imply either sequence or access path.
Primary keys are indicated by the letters PK under the appropriate
column heading (s)
Assuming that EMPLOYEE.NUMBERs are always unique:

EMPLOYEE
NUMBER
PK

EMPLOYEE
NAME

HIRE
DATE

BIRTH
DATE

SALARY
AMOUNT

Primary Key ..
Assuming that the combination
PART.NUMBER is always unique:

of

ORDER.NUMBER

and

ORDER PART
ORDER
NUMBER

PART
NUMBER

PK

ORDERED
QUANTITY

SHIPPED
QUANTITY

Primary key values must never be null (PK implies NN).

Primary key values may not be null because a row without a primary
key cannot (technically) be distinguished from other rows in the same
table

Primary Key ..
Primary key columns may not contain duplicate values (PK implies
ND).
By definition

Existing primary key values may not be modified.

This rule is currently the subject of debate among relational database
theorists. In certain cases, it seems desirable to allow changes to some
composite primary keys. Generally speaking, however, it is advisable
to abide by the rule.

Foreign Key
A foreign key is a column or group of columns that is not the whole
primary key of a table, but is based upon the same domain(s) as the
primary key of the same or; some other, table. A foreign key that
consists of more than one column is a composite foreign key.
EMPLOYEE.DEPT.CODE is a foreign key since it is not the primary
key of the EMPLOYEE table, but is based upon the same domain as
the primary key of the DEPT table.

DEPT
DEPT
CODE
PK

EMPLOYEE
DEPT
NAME

EMPLOYEE
NUMBER
PK

EMPLOYEE
NAME

DEPT
CODE
FK

Foreign Key ..
ORDER.CUSTOMER.NUMBER is a foreign key since it is not the
primary key of the ORDER table, but is based upon the same domain
as the primary key of the CUSTOMER table.
CUSTOMER
ORDER
CUSTOMER
NUMBER

CUSTOMER
NAME

PK

ORDER
NUMBER

CUSTOMER
NUMBER

PK

FK

Locate the foreign key(s) in the following tables:

BUILDING
DEPT
BUILDING
NUMBER

BUILDING
NAME

DEPT
NUMBER

PK

PK

BUILDING
NUMBER

PK

MANAGER
MANAGER
NUMBER

DEPT
NAME

PROJECT
MANAGER
NAME

PROJECT
NUMBER
PK

PROJECT
NAME

MANAGER
NUMBER

Reading
tables
Given these two tables,
EMPLOYEE

DEPT
DEPT
CODE

DEPT
NAME

EMPLOYEE
NUMBER

EMPLOYEE
NAME

DEPT
CODE

PK

NN,ND

PK

NN

FK

The system is concerned with departments and employees (from the table
names).
Each department must have a department code (PK implies NN)
Each department code is unique (PK implies ND).
Department codes are not subject to change (PK implies no changes).
Every department has a department name (NN).
Every department has only one department name (each department code
appears on only one row).
No two departments have the same name (ND).
Each department may have zero, one or more employees (FK)
All employees have employee numbers (PK implies NN).
Each employee number is unique (PK implies ND).
Employee numbers cannot be modified (PK).
And so forth...

Data Model
A data model is a collection of constructs, operators and integrity rules
which together support a dynamic representation of real-world objects
and events
Constructs
Constructs are the basic building blocks of a data model.
Relational data models use a single type of construct, tables.
Operators
Operators are the means whereby the data in a data model is
maintained and retrieved. Typical relational operators are add,
change, delete, select, project, join, group, and so forth.
Integrity Rules
Integrity rules serve to maintain order and consistency in a data
model. No null, no duplicate, primary key and foreign key
constraints are examples of integrity rules

Entities
An entity is a person, place or thing, of inters to the user community,
about which the system is to maintain, correlate, and display
information
Entities are nouns
Entities are within the scope of the system.
Entities have existence in, and of, themselves and are therefore not
dependent upon, or subordinate to, something else.
Entities may be tangible (such as buildings or employees), intangible
(like departments or accounts), or semi-tangible (orders, perhaps or,
invoices).
Characteristics of entities (such as an employee's name), and other
information about entities (the total number of customers, or the average
number of orders placed in May) are not considered entities.

Associations
An association is a relationship between two or more entities (or other
associations), of interest to the user community, about which the
system is to maintain, correlate an display information.
Associations occur in three forms: one-to-one(1:1), one-to-many(1:M),
and many-to-many(M:M).
Associations typically occur between one entity and another (customers
and orders, for example, or orders and parts), but can involve any
number of entities and interrelationships (see the topic "Complex
Associations" in Section Four for a further discussion of this matter).
Associations are within the scope of the system.
Associations occur in three different forms (discussed in the following
topics).

One to One associations

A one-to-one association occurs when two entities (say, A and B) are
related as follows: each occurrence of entity A is related to at most one
occurrence of entity B, and each occurrence of entity B is related to at
most one occurrence of entity A
Entity

Entity
B

One-to-one associations are modeled by placing the primary key of the

entity A table as a foreign key, no duplicates (FK, ND) allowed column in
the entity B table
One-to-one associations are relatively rare.

One to One associations ..

The data model for the one-to-one association above is
A
KEY

B
KEY

A
KEY

PK

PK

FK, ND

A1

B1

A1

A2

B2

A3

A3

B3

A5

A4
A5

Since one
one--to
to--one associations are symmetrical,
symmetrical, either key may be
placed in the other table.
Foreign keys that model one-to-one associations should be placed to
minimize or eliminate null values.

One to Many associations

A one-to-many association occurs when two entities (say, A and B) are
related as follows: each occurrence of entity A is related to zero, one or
more occurrence(s) of entity B, but each occurrence of entity B is
related to at most one occurrence of entity A.

Entity A

Entity B

One-to-many associations are modeled by placing the primary key of

the entity A table as a foreign key (FK) column in the entity B table.
One-to-many associations are quite common.

One to Many associations ..

The data model for the one-to-many association above is:
A
KEY

B
KEY

A
KEY

PK

PK

FK

A1

B1

A1

A2

B2

A3

A3

B3

A1

B4

A1

B5

A3

Since one
one--to
to--many associations are not symmetrical,
symmetrical the A key must
be placed in the B table, and not vice versa.
Note that 1:M associations in tabular form look exactly like 1:1
associations, with the exception of the "ND" integrity constraint.

Many to Many associations

A many-to-many association occurs when two entities (say, A an B) are
related as follows: each occurrence of entity A is related to zero, one or
more occurrence(s) of entity B, and each occurrence of entity B is
related to zero, one or more occurrence(s) of entity A.

Entity A

Entity B

Many-to-many associations are modeled by defining a new table with a

composite primary key. The components of the new primary key are
the primary keys of the entity A and entity B tables. Both components
of the new primary key are also individual foreign keys.

Many-to-many associations are quite common.

Many to Many associations ..

The data model for the M: M association described above is:
A
B
A
KEY
PK
A1
A2

B
KEY
PK
BI
B2

A_B
A
KEY
PK
FK
A1
A1
A2

B
KEY
+
FK
BI
B2
B1

Since many-to-many associations are symmetrical, and since the order

of the columns of a table is arbitrary, the above table could have been
drawn in reverse (B/A, the B Key first).

Atributes
An attribute is a characteristic or quality of an entity or an association,
of interest to the user community, about which the system is to
maintain, correlate and display information.
Attributes may be related to either entities (the name of a customer, for
example), or associations (say, the quantity of a particular part on a
particular order).
All columns of a table are technically attributes of that table, and
therefore are also attributes of the entity of association modeled by that
table. But it is useful to distinguish between three different "roles" that
attributes can play in table.

Attributes ..

1.- Primary key attribute identify the entity or association modeled by a

table.
2.- Foreign key attributes define relationships between entities and other
entities and/or associations.
3.- Other attributes (that are neither primary key nor foreign key
components) further the entity or association modeled by a table.

Chapter 4: Database Security Issues

Database Security
Concerns the use of a broad range of information security controls to
protect databases (potentially including the data, the database applications
or stored functions, the database systems, the database servers and the
associated network links) against compromises of their confidentiality,
integrity and availability.
It involves various types or categories of controls, such as technical,
procedural/administrative and physical.
Database security is a specialist topic within the broader realms of
computer security, information security and risk management.

Database Security ..
Security risks to database systems include, for example:
Unauthorized or unintended activity or misuse by authorized database users,
database administrators, or network/systems managers, or by unauthorized
users or hackers (e.g. inappropriate access to sensitive data, metadata or
functions within databases, or inappropriate changes to the database
programs, structures or security configurations);
Malware infections causing incidents such as unauthorized access, leakage
or disclosure of personal or proprietary data, deletion of or damage to the data
or programs, interruption or denial of authorized access to the database,
attacks on other systems and the unanticipated failure of database services;
Overloads, performance constraints and capacity issues resulting in the
inability of authorized users to use databases as intended;

Database Security ..
Security risks ........
Physical damage to database servers caused by computer room fires or
floods, overheating, lightning, accidental liquid spills, static discharge,
electronic breakdowns/equipment failures and obsolescence;
Design flaws and programming bugs in databases and the associated
programs and systems, creating various security vulnerabilities (e.g.
unauthorized privilege escalation), data loss/corruption, performance
degradation etc.;
Data corruption and/or loss caused by the entry of invalid data or commands,
mistakes in database or system administration processes, sabotage/criminal
damage etc.

Database Security ..
Many layers and types of information security control are appropriate to
databases, including:
Access control
Auditing
Authentication
Encryption
Integrity controls
Backups
Application security
Database architecture

Access control
Access control is the selective restriction of access to a place or other
resource. The act of accessing may mean consuming, entering, or using.
Permission to access a resource is called authorization.
Locks and login credentials are two analogous mechanisms of access control.

Auditing
Database auditing involves observing a database so as to be aware of the
actions of database users. Database administrators and consultants often set
up auditing for security purposes, for example, to ensure that those without the
permission to access information do not access it.

Authentication
Authentication is the act of confirming the truth of an attribute of a datum or
entity. This might involve confirming the identity of a person or software
program, tracing the origins of an artifact, or ensuring that a product is what its
packaging and labeling claims to be.

Encryption
Encryption is the process of encoding messages (or information) in such a way
that eavesdroppers or hackers cannot read it, but that authorized parties can.

Integrity controls
Integrity refers to maintaining and assuring the accuracy and consistency of
data over its entire life-cycle and is an important feature of a database or
RDBMS system.
Data warehousing and business intelligence in general demand the accuracy,
validity and correctness of data despite hardware failures, software bugs or
human error.
Data that has integrity is identically maintained during any operation, such as
transfer, storage or retrieval.
All characteristics of data, including business rules, rules for how pieces of
data relate, dates, definitions and lineage must be correct for its data integrity
to be complete.
When functions operate on the data, the functions must ensure integrity.
Examples include transforming the data, storing history and storing metadata.
The most popular types of Integrity are: Entity Integrity, Referential Integrity
and Domain Integrity.

Backups
A backup, or the process of backing up, refers to the copying and archiving of
computer data so it may be used to restore the original after a data loss event.
Backups have two distinct purposes. The primary purpose is to recover data
after its loss, be it by data deletion or corruption. Data loss can be a common
experience of computer users. A 2008 survey found that 66% of respondents
had lost files on their home PC.
The secondary purpose of backups is to recover data from an earlier time,
according to a user-defined data retention policy, typically configured within a
backup application for how long copies of data are required. Though backups
popularly represent a simple form of disaster recovery, and should be part of a
disaster recovery plan, by themselves, backups should not alone be
considered disaster recovery.
One reason for this is that not all backup systems or backup applications are
able to reconstitute a computer system or other complex configurations such
as a computer cluster, active directory servers, or a database server, by
restoring only data from a backup.

Application security

Application security encompasses measures taken throughout the

application's life-cycle to prevent exceptions in the security policy of an
application or the underlying system (vulnerabilities) through flaws in the
design, development, deployment, upgrade, or maintenance of the application.

Database architecture

Hierarchical architecture
Network architecture
Relational architecture
Object Oriented architecture

Chapter 5: Administracin de la
Seguridad de la Informacin

Seguridad de la Informacin

Uno de los mayores retos en la administracin de TI, es el manejo de la

seguridad de la informacin.
Vivimos en una era en la cual las organizaciones son dependientes de la
tecnologa basada en Internet.
El potencial dao causado por ataques, podra detener la operacin de una
organizacin.

Seguridad en la era de Internet

En la actualidad, todos los ejecutivos de una empresa necesitan entender las

amenazas a los sistemas basados en Internet.
Y apoyar financieramente el trabajo que se haga para proteger el negocio.
Desde 1996, el Computer Security Institute y el San Francisco Federal Bureau
of Investigation Computer Intrusion Squad, han hecho encuestas anuales a
empresas para conocer los crmenes cometidos.

Tipos de Ataques

Prdidas en 2006

Tecnologas de Seguridad usadas

5 Pilares de la Seguridad
Autentificacin.Verificar la autenticidad de usuarios.
Identificacin.Identificar usuarios para otorgar acceso.
Privacidad.Proteger la informacin.
Integridad.Mantener la informacin en su forma original.
No repudiacin.Que nadie pueda negar que una transaccin ocurri.

Recuperacin en caso de desastre

Si bien los sistemas de informacin son slo una parte de las operaciones de
una empresa, stos han llegado a ser una parte crucial.
Usando recursos internos:
Mltiples Centros de Computo
Proceso Distribuido
Respaldo de Comunicaciones
LANs
Usando recursos externos
Servicios integrados
Servicios especializados
Almacenamiento de datos

Usando recursos internos

Mltiples centros de computo

En los ltimos aos y para ahorrar dinero, las empresas han consolidado
sus mltiples centros de cmputo en uno solo.
Septiembre 11, caus que esto cambiara, ya que mltiples centros,
pueden proporcionar respaldo de emergencia a servicios crticos.
Para respaldo de datos, las empresas tienen lugares retirados con discos,
que son actualizados regularmente y que pueden ser accesados en lnea
o en modo batch.

Usando recursos internos

Proceso distribuido
Otras organizaciones usan proceso distribuido para recuperarse en caso
de desastre. Ellas realizan el proceso crtico en forma local ms bien que
en el centro de cmputo de manera que las operaciones pueden
continuar in-interrumpidas en caso de desastre en el centro de cmputo.
Debido al costo de esta alternativa, por la redundancia de datos,
normalmente se utiliza solamente para aplicaciones que deben continuar
operando, como ejemplo: proceso de rdenes y transacciones
financieras.

Usando recursos internos

Respaldo de comunicaciones
Las compaas manejan el respaldo de las comunicaciones de dos
formas:
Duplicando sus instalaciones
Utilizando servicios de Carriers
LANs
Servidores en una LAN pueden ser usados para respaldar servidores de
otras LAN.

Usando recursos externos

Servicios Integrados
Respaldo completo de las instalaciones del cliente.
Servicios Especializados
Respaldo parcial de las instalaciones del cliente.
Almacenamiento de Datos
Bvedas resistentes al fuego que pueden mantener los datos en lnea.

Chapter 6: Data Base Vulnerability

Data Base Vulnerability

Vulnerability refers to the inability to withstand the effects of a hostile

environment. A window of vulnerability (WoV) is a time frame within which
defensive measures are reduced, compromised or lacking.

Data Base Vulnerability

Default, blank, and weak username/password
It might be a daunting task at an organization that has to keep track of
hundreds or even thousands of databases. But removing default, blank and
weak log-in credentials is an important first step for filling chinks in your
database armor. The bad guys are keeping track of default accounts, and
they'll use them when they can.

Default, Blank & Weak Username/Passwords

Desarroll:
Estela Alvarado Daz de Len

Data Base Vulnerability

To create a strong password:

Dont use words that can be easily guessed or found in the dictionary
Use a combination of letters, numbers and characters
Create a complex sentence instead of a word
Do not share your password with anyone or write it down and leave it in your
desk drawer

Data Base Vulnerability

SQL injections
When your database platform fails to sanitize inputs, attackers are able to
execute SQL injections similar to the way they do in Web-based attacks,
eventually allowing them to elevate privileges and gain access to a wide
spectrum of functionality. A lot of vendors have released fixes to prevent these
problems, but it won't do much good if your DBMS remains unpatched.

SQL Injection
Juan Carlos Torres Prez
Matricula: 1063002

Data Base Vulnerability

For example, the model SQL code might be:
SELECT Count(*) FROM UsersTable
WHERE UserName = contents of username textbox
AND Password = contents of password textbox;
When a user enters a valid username, such as Mary and a password of
qwerty, the SQL query becomes:
SELECT Count(*) FROM UsersTable
WHERE UserName=Mary
AND Password=qwerty;

Data Base Vulnerability

However, if a user enters the following as a username: OR 1=1 -- the SQL
query becomes:
SELECT Count(*) FROM UsersTable
WHERE UserName= OR 1=1 - -
AND Password=;
The expression 1 = 1 is true for every row in the table causing the OR clause
to return a value of true. The double hyphens comment out the rest of the
SQL query string. This query will return a count greater than zero,
assuming there is at least one row in the users table, resulting in what
appears to be a successful login. In fact, it is not. Access to the system was
successful without a user having to know either a username or password.

Data Base Vulnerability

Extensive user and group privileges

Organizations need to ensure privileges are not given to users who will
eventually collect them like janitors collect keys on their keychains. Instead,
Rothacker recommends only making users part of groups or roles and
administering the rights through those roles, which can be managed
collectively more easily than if users were assigned direct rights.

Data Base Vulnerability

Unnecessarily enabled database features
Every database installation comes with add-on packages of all shapes and
sizes that are mostly going to go unused by any one organization. Since the
name of the game in database security is to reduce attack surfaces,
enterprises need to look for packages that don't use and disable or uninstall
them. This not only reduces risks of zero-day attacks through these vectors,
but it also simplifies patch management. When it'those packages need the
patching, your organization won't need to scramble.

Caractersticas y funciones de
base de datos innecesariamente
habilitadas
Por: Yazmany Jahaziel Guerrero Ceja.

Data Base Vulnerability

Broken configuration management

Similarly, databases have a panoply of many different configuration choices
and considerations available to DBAs to fine-tune performance and enhanced
functionalities. Organizations need to be on the lookout for unsafe
configurations that could be enabled by default or turned on for convenience of
DBAs or application developers.

Data Base Vulnerability

Buffer overflows
Another hacker favorite, buffer overflow vulnerabilities, are exploited by
flooding input sources with far more characters than an application was
expecting--say, by adding 100 characters into an input box asking for a SSN.
Database vendors have worked hard to fix the glitches that allow these attacks
to occur. This is yet another reason why patching is so critical.

Data Base Vulnerability

Privilege escalation
Similarly, databases frequently sport common vulnerabilities that allow
attackers to escalate privileges within a little known and low privilege account
and gain access to administrator rights. For example, an attacker might
misuse a function that runs under a sysdba, Rothacker explains. As these
vulnerabilities are uncovered, administrators need to reign them in with timely
updates and patching.

Data Base Vulnerability

Denial-of-service attack
SQL Slammer provided a very illuminating illustration of how attackers can use
DBMS vulnerabilities to take down database servers through a flood of traffic.
Even more illuminating is the fact that when Slammer went down in 2003, a
patch already was out there that addressed the vulnerability it attacked. Even
seven years later, SQL Slammer is still around and picking on unpatched
servers.

Data Base Vulnerability

Unpatched databases
This could be repetitive, but it bears repeating. So many database
administrators don't patch in a timely fashion because they're afraid a patch
will break their databases. But the risk of getting hacked today is way higher
than the risk of applying a patch that will go haywire, Rothacker says. That
might not have been true five years ago, but vendors have become much
more rigorous with their testing.

Data Base Vulnerability

Unencrypted sensitive data at rest and in motion
Perhaps it is a no-brainer, but organizations should never store sensitive data
in clear text within a database table. And all connections to the database
should always use encryption.
Encryption is an important part of housing sensitive data. Network traffic
should also be encrypted to ensure that the passwords used to access
sensitive, critical data cannot be seen by traffic.
Any information that goes over the network or stored in the database should
be encrypted and kept from prying eyes. Some network configurations and
database management systems might allow for critical information to be sent
in clear text. To ensure this doesnt occur, make sure you have the latest
version of software and turn off text indexing.