Security Artefacts Base

One of the important steps of this method is to establish the Security Artefacts Base. From best practice and ISO 27001 control, it can be concluded that security must embody some form of activities such as authentication, authorisation, encryption and accounting. Security services such as access control, emphasises on a prevention approach to security. Accounting as a detection security approach should also be taken into account in the proposed framework. Other security services such as authentication, supports both protection and detection.

4.6.3.1 Authentication

In authentication, a subject is some kind of user who has to identify itself to the system so as to gain authorisation. There are various ways to make authentication. The typical ones involve password which may possibly use a security service like Lightweight Directory Access Protocol (LDAP) or Radius. Some other mechanisms like ID cards or biometrics are popular authentication means. Figure 4-15 shows the core structure of authentication mechanism.

Figure 4-15 Authentication Core Structure

Typical mechanisms used for authentication are listed as follows: • User ID and Password

This technique generally scores high on cost effectiveness and usage requirements, but lower on reliability and protection of passwords. Password’s ability to avoid confirming imposters is medium at best, because passwords can be obtained through theft or other means. This ability depends on good password practice—for example, the use of hard-to-guess passwords, and not recording passwords in easy-to-find locations. Password’s ability to avoid denying legitimate users depends on the likelihood of remembering passwords: good passwords can be somewhat difficult to remember.

• PKI (Public Key Infrastructure)

This technique depends somewhat on the population to which it is applied. It can score very highly on reliability with a relatively sophisticated user base, but has high cost.

• SSL or password digests

Basic authentication uses SSL or password digest to protect the password. • Server-side authentication

Authentication should be in the server side (instead of client side/JavaScript). • Credentials

• SSO (Single Sign On) / centralised security service

Users don't have to have many accounts/passwords, users don't have to share their passwords with many applications/resources, and the developers don't have to maintain multiple authentication mechanisms in different systems. With federated identity provider, you can centralise the credentials across organisations.

4.6.3.2 Authorisation and Access Control

Access control exists to ensure that unauthorised access is not allowed and that authorised users cannot make improper modifications. A reference monitor is used in access control to check whether or not the access request from the subject to the protected object is authorised. The request with a valid authorisation can be forwarded. In the implementation phase, the reference monitor can be realised as proxy, wrapper or mediator. Figure 4-16 shows the core structure of access control mechanism.

Figure 4-16 Access Control Core Structure

Access control policies are a collection of access control rules. As shown in Figure 4-17, access control rule is a tuple involving entities of Subject, ProtectedObject, and Right which means for a given Subject whose accessible objects are determined by the Right representing by “allow” or “deny”. In implementation phase, the rules may be implemented and stored in a XML document or a table rather than appearing as a class. The subject in access control policies may be a role with related users or with groups and sessions.

Figure 4-17 Access Policy Core Structure

The typical access control techniques may include： • Group grants

• Role grants • Delegation

• Access control lists • Policy objects • Rules

4.6.3.3 Encryption Mechanism

Encryption techniques play a vital role in secure software from unauthorised access. The well encrypted data or information cannot be read by unauthorised parties even if it is hacked. Encryption is typically required for services involving personal information, for example, online banking.

In an encryption scheme, information or data referred to as plaintext is encoded into a different unreadable form using some kind of encryption algorithm, and the encrypted form is called cipher text. There are various encryption algorithms exist which are open to public. An encryption key is needed to perform the encryption which specifies how the data is to be encoded. An unauthorised party without the key should not be able to understand anything from the cipher text while an authorised one can decode the cipher text with a secret decryption key. The keys are usually produced by a key generation algorithm randomly for security reasons.

Encryption scheme can be classified into two kinds according to the different encryption key schemes:

• Symmetric key encryption

In such scheme, the key used to encrypt and decrypt are same. Therefore, the communication parties have to reach an agreement on the secret key before starting the communication. The example of symmetric algorithm includes DES, AES, and IDEA etc.

• Asymmetric key encryption

The keys used to encrypt and decrypt are different. The encryption key also called public key is published to anyone who wish to encrypt the messages, while only the receiving party holds the decryption key and then cipher text can be decrypted and read. The most frequently used asymmetric encryption scheme is RSA.

Key size or key length is the size measured by bits of the key used in an encryption algorithm. Generally speaking, the more bits the key size is, the more strength the encryption algorithm is and the more security of the encryption scheme provides.

• Well-proven encryption algorithms

Use well-proven encryption algorithms (e.g. AES) in well-proven libraries instead of inventing and implementation your own algorithm.

• Sensitive data encryption

Encrypt/hash sensitive data e.g. bank-accounts in the LDAP production copy used for development/test.

• Enough encryption key

Use enough key size. Securely distribute, manage, store the keys, and change the keys periodically.

The equivalent relation between symmetric key and asymmetric key scheme can be found in [131], shown in Table 4-7. RSA security claims that the keys with 1024 bits are likely to become crackable during the time between 2006 and 2010 and that keys with 2048 bits are sufficient until 2030. An RSA key length of 3072 bits should be used

beyond 2030. NIST key management guidelines [131] further suggest that 15360-bit RSA keys are equivalent in strength to 256-bit symmetric keys.

Table 4-7 Comparable Strength between Symmetric Key and Asymmetric Key

RSA Keys (bits) Symmetric Keys (bits)

1024 80

2048 112

3072 128

15360 256

4.6.3.4 Accounting

The function of security accounting is to track security-related actions or events, such as damage to property, attempts at unauthorised database access, or transmission of a computer virus, and provide information about those events [151]. The information provided includes identifying those who participated in the events, so that they may be held accountable. The primary security property supported by security accounting is accountability.

For application domain, security accounting mechanisms are usually some kind of auditing. Audit is the review of events stored in logs, sometimes called audit logs or audit trails, to determine inadequacies during operation or non-compliance with policy. Audit specifically scrutinises information for security relevance. Some form of auditing from [149] is listed below.

• Centralised audit log

• Encrypted checksums on log records • Encrypted log records

4.6.3.5 Input Validation

Improper or lack of user input data validation is one of the biggest security issues in web applications. The issues include Buffer Overflows, SQL Injection, Cross-Site Scripting attacks, and many others. Input validation is the process to test the correctness of any input to the applications. All application have the specific requirement for user input which could come from various sources, for example, end user, malicious user, another application or any other sources. All input should be validated before processed by application.

Input validation only on the client side is not sufficient in many cases. For example, JavaScript can be used to validate client side input. However, this kind of validation can be easily bypassed by using some proxy tools, such as TamperIE or WebScarab tool. As a result, it is very important to have a validation on server side while make it on the client side at the same time because there is no guarantee that validations on the client will be executed.

4.6.3.6 Session Management

A common vulnerability of web applications is caused by not protecting account credentials and session tokens. There are four types of session id attacks: interception, prediction, brute-force, and fixation. In each attack, an unauthorised user can hijack a session and assume the valid user’s identity. Encrypting sessions is effective against interception; randomly assigned session ids protect against prediction; long key spaces render brute force attack less successful; forcing assignment and frequent regeneration of session ids make fixation less problematic. Some security suggestions on session management are listed as follows.

• HMAC(Hash Message Authentication Code) or encrypt session ID • Logout mechanism

• One time Nonce

• Random generated Session ids • Session ID length 128 bits or more

4.6.3.7 Configuration Management

Configuration management also referred to as change management, it documents much configuration information in the system, for example, how the networks devices are configured, what version of the application are running, and what are the last patches installed on the devices. There is no doubt that attackers are interested in this information. Therefore, how to manage configurations has close relations with system security. The following lists typical suggestions of configuration management for security concerns.

• Restrict access to configuration file • Encrypt/hash sensitive configuration data • Centralised security management

• Configuration change detection • Restrict message size

4.6.3.8 Error Handling

Error is inevitable during software development. Errors may force an application stop working. How to solve the error securely is vital to application security. Detailed error information may include sensitive information which can be exploited by attacker. Therefore, error messages should be handled properly so as to avoid being exploited by attackers. The typical error handling suggestions are listed as follows.

• Policy for handling errors

• Hide sensitive information in the error pages • Centralised error handling

After identifying the system artefacts with security artefacts base, an assessment checklist is to be generated which has three columns in total. The first two columns enumerate the security services and the security mechanisms supporting the services. The next one is checkbox denoting if the mechanism is implemented in the current design.