can easily identify the risks associated with physical
and tangible assets, and then protect these. But how
can we secure data that is fed to an application, and
its output after processing? How can we secure the applications
themselves and their source code? by Avinash Kadam
Securing against visible threats
is not difficult. We can easily identify physical risks,
communication risks and access control risks. Application
security risks are much more difficult to identify.
The security weaknesses of a system are 'born' with
the system. Hence, there should be more emphasis on
prevention during system development.
Development of an application
system is undertaken after a thorough analysis of the
business requirements. Functional specifications of
the system are then drawn after careful consideration.
At this stage one should identify the security needs.
Security specifications should reflect the value of
information. What will be the damage to business if
Confidentiality, Integrity and Availability of the application
system are compromised?
Three areas of concern for
the security of an application system are Input, Processing
The old acronym GIGO (Garbage In Garbage Out) was coined
to reflect the concern about incorrect data getting
into the system, resulting in worthless output. Today
most of the data is entered, not by experienced data
entry operators, but by laypeople. We have to ensure
that the data entered does not cause unintentional damage.
We also have to accept the fact that people with malicious
intentions could deliberately enter wrong data. They
will try to test the capability of the system to detect
errors. Buffer overflow is the term used to describe
such attempts. For example, one can enter more than
1,000 characters in the subject area of a mail program,
thereby crashing the system and taking control. The
design of testing of input fields should be done to
prevent such attempts.
Our next area of concern is the application programs
and their processing. If the programs are not well tested,
they may fail during runtime or crash the system. Adequate
validation checks must be built in to prevent such conditions.
These checks could be proper session controls to ensure
correct sequence of operations like run-to-run controls,
and program-to-program controls, or validation of system
Today's applications not only accept data through normal
terminal entry, but also accept messages as an input
source. For example, a message instructing a banking
application for electronic fund transfers. Confidentiality
of the message may not be the prime concern here, but
integrity of such messages is important to ensure correct
Even though we may have taken enough precautions to
ensure validity of input and processing, we cannot assume
that the output will be always correct. It is necessary
to validate the output before it is delivered to the
end user. Such validation should reconcile various control
counts to ensure that all the data has been processed.
Most importantly, we should conduct a 'reasonableness'
One relies heavily on cryptography
for maintaining confidentiality, authenticity and integrity
of information. These controls are selected if it's
felt that other controls do not provide adequate protection.
Cryptographic controls should
not be implemented in an adhoc manner. To begin with,
the company should frame an appropriate policy on the
use of cryptographic controls. The policy should reflect
management's understanding of the risks involved for
business information. It should properly identify the
business processes to be subjected to cryptographic
controls, and also the categories of information to
be encrypted. The policy should also decide on the cryptographic
standards to be adopted by the organization.
After deciding on the 'why'
and 'what' of cryptographic controls, decisions should
then be made on 'who' and 'how' aspects of the controls,
which deal with implementation. For example, who should
be responsible for encrypting the information, maintenance
of encryption keys, and recovery of information in case
the keys are lost?
The various cryptographic controls
Encryption ensures confidentiality of information, by
keeping it safe from prying eyes. There are a number
of algorithms that could be used for encryption. Key
size makes the encryption stronger. But many governments
are skeptical about encrypted data. An organization's
cryptographic policy should consider various government
regulations, not only of the country of origin, but
also of other countries where the information is destined.
Export and import of cryptographic technologies are
sometimes subject to strict government regulations.
Digital signatures ensure authenticity and integrity
of electronic documents. In an electronic transaction,
it is essential to have proof that the transaction is
genuine. Digital signature is now a recognized tool
to provide this assurance. This has also been accepted
within the legal framework in many countries (including
India). You could use it to sign legal contracts and
agreements, make electronic payments and transfer funds.
Since the identity of a person
using the digital signature is linked to the key used,
authenticity and confidentiality of the private key
or secret key is very important. Authenticity is provided
through the use of digital certificates issued by trusted
Certifying Authorities. Confidentiality of the private
key has to be maintained by the person holding the key.
Nobody else should have access to it.
Digital signature is still a new technique. There may
be disputes about the validity of a digital signature.
There may be cases where the person signing the document
may refuse to take the responsibility. All such cases
need the identity to be established by using the quality
of non-repudiation of digital signature. Such services
are based on the use of the encryption and digital signature
The cryptographic algorithm is not entirely a secret.
It is open for public review. This helps to detect any
weakness in the algorithm. The strength of cryptography
as such, depends only on the selection of an appropriate
key. Once selected, this key has to be protected against
any misuse. This requires a management system to be
in place to protect the keys. The keys should be protected
against copying, modification, destruction or any unauthorized
disclosure. This requires appropriate physical protection
for the equipment generating and storing the keys, and
also for the media on which the key is stored.
The key management system should
be based on well-designed and approved standards, procedures
and secure processes, for various aspects of the key
life cycle, for example:
- key generation
- public key certificates
generation or acquisition
- key distribution
- key storage
- change of keys
- revoking the compromised
- recovering lost keys
- archiving keys
- destroying keys
- logging the key management
- auditing the key management
Since digitally signed documents
are now legally acceptable in an Indian court, sooner
or later it is bound to surface in legal cases. Then
we will have to deal with cases involving forged digital
signatures and stolen keys. We will have to be ready
to face such issues by creating trustworthy management
SECURITY OF SYSTEM FILES
Dependability of operational
systems is linked to integrity of the operational software,
protection of the test data, and access control of the
program source library.
A piece of software is elevated
to operational status from the development environment
only after thorough testing. Only authorized persons
with specific instructions from management should execute
changes. This also applies to vendor-supplied software.
Vendors usually issue a number of patches. These should
be applied after proper testing and confirming that
they will remove or mitigate security weaknesses seen
in the previous version.
An application system becomes
operational after rigorous testing. The test data represents
all the test cases involving as many real life scenarios
as possible. Care should be taken to depersonalize this
data. The same test data should be used if the application
system has to be retested after an upgrade or after
applying patches. It is necessary so that the test data
remains unchanged and is reused for testing an upgraded
system. This requires proper management processes to
be in place, to prevent unauthorized access to this
The source code of the programs
is another critical item on our protection list. This
should be maintained by an independent person, preferably
a program librarian and not by the programmers themselves.
This is to avoid the temptation of replacing an erroneous
program without going through the discipline of making
appropriate version changes. Any copying or maintenance
of the program source should follow strict change control
procedure. An audit log should be maintained of all
accesses to the program source library. Old versions
of programs should be properly archived. All these measures
are part of good software management practices. These
practices get elevated from nice-to-have to mandatory,
when we think of security.
SECURITY IN DEVELOPMENT AND
Security should not be an afterthought.
It should be built in the development and support processes.
Observing the best practices of software engineering
will do this. In addition, incorporate the following
best practices of secure software engineering.
Change is a constant requirement
for application software. Changes are required to meet
changing business needs, to improve the functionality
and also to correct any flaws. These changes should
follow a formal change control procedure involving approvals,
identification process, record keeping and auditing.
An operating system consists
of several large programs. The reliability of any computer
depends on the stability of its underlying operating
system. Millions of computer users subject the operating
system to rigorous (beta) testing, thereby discovering
flaws not identified at the testing phase. Operating
system vendors keep issuing patches to correct these
flaws, and also to improve functionality. But the applications
systems developed on earlier versions of the operating
system may not work properly with new patches. This
requires testing of applications systems with the newly
patched operating system. Also, proper documentation
control is mandatory. Do not forget to update your business
continuity plans to reflect all the operating system
changes that are made to the operational systems.
All these cautions also apply
to packaged software being used in the organization.
Do not make unauthorized changes. The vendor may stop
supporting you. Test all the changes. Document all the
changes. Retain the older version.
Does the software have other
functionality other than what it was designed for? Has
the programmer built some maintenance hooks, which he
has 'forgotten' to remove? These are real concerns.
Take all possible precautions to avoid existence of
covert channels or Trojan code in the software.
Buy programs only from reputed
sources. Inspect the source code before putting it in
operational use. Use only evaluated products. Employ
trustworthy staff in key positions. Control access to
the source code.
These concerns become more
acute when the software development is outsourced. You
do not have direct control over the development process.
You have to create a legal structure to protect your
interest. This involves the licensing arrangement, ownership
of the code, intellectual property rights, quality and
accuracy certifications. You may also need to make arrangements
to acquire the source code, in case the developer is
no longer in a position to support you. You also should
have rights to audit the development process, and test
the applications for Trojan codes before acceptance.
Avinash Kadam is Director Miel e-Security,
Pvt. Ltd. He can be reached at email@example.com