The unseen threat

We 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 and Output.

Input
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.

Processing
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 generated data.

Message Authentication
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 results.

Output
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' check.

CRYPTOGRAPHIC CONTROLS

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 are:

Encryption
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
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.

Non-repudiation services
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 techniques.

Key Management
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 keys
• recovering lost keys
• archiving keys
• destroying keys
• logging the key management activities
• auditing the key management activities

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 processes.

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 data.

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 SUPPORT PROCESSES

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 awkadam@mielesecurity.com