Is-SPEC-APP-023 Application Generic Security Guideline v0.2

Information Technology
IS-SPEC 023
Application Generic Security
Guideline
Release Date: 20 March 2009
Version: 0.2
Restricted
IS-SPEC 023 – Application Generic Security Guideline
Version Control
Owner
Vice President, Information Security
Maintenance
This document is maintained by the Group Information Security Team.
Feedback is welcome, via SI-ITCI-Document-Control@shell.com.
Please mark all correspondence clearly the name of the document. List also the version number of the
document.
Related Documents
IS 202 Information Security Standards Guideline
IS 203 Information Security Glossary
IS 220 Information Security Standard (Control Register)
ISO 27002 Code of Practice for Information Security Management
Additional ISS related documents can be found here:

http://sww.shell.com/it/infosec/professional/is_standard/iss/document_maintenance.html
http://sww.shell.com/it/infosec/professional/is_standard/iso.html
Version History
Version Revision Date Contributor’s Name Revision Description

v0.1 10 March 2009 William Kleyweg Creation
v0.2 17 March 2009 William Kleyweg Update
v0,3
Last saved: 17/05/2009 05:17:00 AM 2/36

Restricted
Contents
1 Introduction..................................................................................................................................... 4
1.1 Purpose.................................................................................................................................... 5
1.2 Scope....................................................................................................................................... 5
1.3 Intended Readership................................................................................................................ 5
1.4 Relation to ISS......................................................................................................................... 6
1.5 Roles and Responsibilities....................................................................................................... 6
2 Application Generic Security Guideline........................................................................................... 8
3 Application Generic Rules............................................................................................................. 10
3.1 Data Access Generic Rules................................................................................................... 10
3.2 Information Classification Generic Rules...............................................................................12
3.3 Identity Management Generic Rules......................................................................................13
3.4 Authorisation Generic Rules.................................................................................................. 17
3.5 Accountability Generic Rules................................................................................................. 23
3.6 Securing the Application – Generic Rules..............................................................................25
3.6.1 Validate ALL input........................................................................................................... 25
3.6.2 Use Secure Coding techniques.......................................................................................25
3.7 Application Deployment Generic Rules..................................................................................26
3.7.1 Development Phases...................................................................................................... 26
3.7.2 Requirements, Definition & Design.................................................................................26
3.7.3 Development................................................................................................................... 27
3.7.4 Deployment..................................................................................................................... 29
Appendix A: Threat Modelling............................................................................................................... 34
Who Does What?.............................................................................................................................. 34
Identify Threats................................................................................................................................. 35
Appendix B: Document Change History............................................................................................... 37
Table of Figures
Figure 1: Relation to ISS........................................................................................................................ 6
Last saved: 17/05/2009 05:17:00 AM 3/36

Restricted
1 Introduction
Welcome to the Shell Information Security Standard (ISS) guideline for generic application security.
This specification is good practice for all applications, but only mandatory for applications as defined in
the current year GRC 100.
Modifications to applications, using the above criteria, are also covered by this document.
Where the application is deployed within the Shell Network, additional controls are mandatory for
production systems that are hosting the application. These are described in Information Security
System & Network Generic Rules (IS-SPEC-INF 020 – System Generic Security Guideline).
As the specific controls will vary widely, dependent upon the application type and environment in which
it operates, this document describes these as generic baseline management controls. Additional,
application specific specifications should be available for some applications and where this is the case,
these must be adopted, as they will conform to this generic standard.
All applications that contain external facing applications for all TCP/IP protocols will be assess against
this standard. For Shell hosted client/server Web Applications, if the Presentation layer is accessed
from an external network, then the application must be assessed against Information Security Web
Systems Generic Specification (IS-SPEC-APP 027 – Web Systems Security Guideline).
Compliance to the controls described in this document (updated versions shall be published from time
to time) is mandatory. Where full compliance is not possible, exceptions and compensatory controls
must be negotiated between the local site and the Global IT Security Standards and Policies team (SI-
ITCI-Document-Control@shell.com).
Note that in order to be simpler to use, this document assumes that general processes are in
place/use within your organisation (e.g. Change Management).
Last saved: 17/05/2009 05:17:00 AM 4/36

Restricted
This document has been created based on ITCI023 – Application Generic Specification.
ITCI documents are founded on Open Network principles, while the ISS (the current Information
Security for Shell model) is founded on protecting Information Assets).
While the two models can be similar in some respects, in other cases they are completely different.
This document has been created as interim step to helping businesses implement adequate
security, and whilst every effort has been made to bring the guidelines in this document into
line with the ISS, please note that this is an ongoing process.
Because of this, some of the terms and definitions of the ITCI document (and therefore in this
document) may lead to confusion.
If in doubt regarding any of the measures in this document, please also contact the Group Information
Security Team, via SI-ITCI-Document-Control@shell.com.
Ideas for improvement (or improvements themselves) are most welcome and can be directed to the
Group Information Security Team via the above email address.
1.1 Purpose
This document is intended to support the ISS and describes guidelines for securing Applications. In its’
unchanged form, the Vice president Information Security is accountable for the design effectiveness of
this reference guide.
Note: Where this reference guide is adopted (and not adapted), businesses/organisations are not
required to address design effectiveness of this guideline. Where this reference guide is adapted, the
business/organisation is responsible for design effectiveness.
1.2 Scope
This document attempts to describe the rules required to meet only the technical aspects of ISS
compliance, and not other aspects of ISS compliance. It may be the case that not all technical ISS
aspects are met by the rules contained in this document (refer to introduction). Where this is noted, the
global Standards Team (SI-ITCI-Document-Control@shell.com) can be contacted for making updates
to this document.
1.3 Intended Readership

This document is intended for System Architects, System Managers, IT Service Providers, local
Security Managers, and Security Auditors.
Last saved: 17/05/2009 05:17:00 AM 5/36

Restricted
Information Owners, IT Managers, and System Planners, Developers and Systems Administrators
should also read it when developing an application for deployment.
An indication of how and where these roles may interact is presented in Appendix A.
A knowledge of Information Technology (IT) and its’ role within a business environment is assumed.
This document may be of interest for other parties or end users, but it should be noted that some
concepts may require further clarification and/or explanation.
1.4 Relation to ISS

The ISS currently consists of Group level policies and requirements, supported by a control register
(IS220 – ISS Control Register),
The control register contains all of the requirements currently mandatory for Shell, and is written from
a generic control objective standpoint to allow for diverse business requirements.
Documents within the ISS can comprise of three general levels:

- Control objectives (as contained in IS 220 – ISS Control Register)
- Implementation guidelines (detailing further what is required)
- Specification guidelines (detailing further how to implement the what)
Last saved: 17/05/2009 05:17:00 AM 6/36

Restricted
Figure 1: Relation to ISS
This document is an implementation guideline, as it does not concern specific IT components.
1.5 Roles and Responsibilities

ITCI Standards Team is responsible for updating this document, should any updates become
necessary. Note that this only applies to cases where this document has been adopted, not adapted.
Last saved: 17/05/2009 05:17:00 AM 7/36

Restricted
Parties implementing the controls contained in this document are responsible for being able to show
compliance evidence.
Last saved: 17/05/2009 05:17:00 AM 8/36

Restricted
2 Application Generic Security Guideline

An application is defined as a software executable designed to perform a specific function by applying
rules (or logic) en route to transform or transfer data. As this definition appears to cover all software,
including operating systems and databases for example, further categorisation is necessary.
There are several types of applications, but the GITA definitions will be used to help identify the
applications in scope of this specification:
 Group Wide Applications contain line of business applications that are considered to be
standard applications for all Businesses within the Shell Group.
 Business Shared Applications contain line of business applications that are used by more than
one Business in the Group, but which are not used by all Businesses.
 Business Wide Applications contain the line of business applications that are unique to one
particular Business in the Group.
 OU Specific Applications contain applications that are unique to one OU in the Group.
 Generic Business Services are the category of applications that are NOT line of business
specific. These are common applications and services that support the running of a business
(mail, document management, etc.), not typically the support of the business process itself.
When considering whether an application should conform to this specification, the key phrase in the
above definition is ‘specific function’. Thus:
 Applications that provide generic services such as word processing, spreadsheet, or other
personal productivity tools do not need to be considered. However, where a generalised
application is used as basis to perform a specific function this should conform. For example,
Excel Macros used to perform a specific calculation or database using database procedures
are included.
 Generic applications such as operating systems, application environments (e.g. Websphere),
or databases are beyond the scope of this document
 Development & Testing environments are beyond the scope of this document but must comply
with ISS System & Network Generic Rules (IS-SPEC-INF 020 – System Generic Security
Guideline) if they are on the Shell Network.
Any application developed and operated solely for personal use is not required to conform to this
specification.
All new applications, both developed and packaged, must conform to this specification. Certain
allowances are made for existing applications; these are clearly annotated in both text and
corresponding checklists.
Last saved: 17/05/2009 05:17:00 AM 9/36

Restricted
If required, application administrators, system administrators, network administrators and auditors may
copy this chapter for use as a checklist.
Where there is no specific interpretation of the generic rules as described in this document, the
general rules/controls as described in this document shall be implemented and a specific
interpretation needs to be created by the user of the document.
If it is not possible to implement specific controls, then the step-out procedure is applicable (GRC 130
– ISS Step Out Process). Contact Global IT Security Assurance Office for further details of the step-
out procedure (SI-IT-GRC-Assurance-Office@shell.com).
Last saved: 17/05/2009 05:17:00 AM 10/36

Restricted
3 Application Generic Rules
3.1 Data Access Generic Rules

As an application is the primary means of accessing data, it is the responsibility of those deploying the
application to apply appropriate security controls to the data which it:
 Permits access to; through the provision of access controls.
 Changes; through the provision of accountability controls.
Some Applications undertake the responsibility for applying these controls directly whereas others may
use the services of the Operating system, Database Management Systems (DBMS), or specific tools
to undertake these responsibilities on its behalf.
How these controls are applied should be determined during the design phase, or, for purchased
(package) applications during the procurement stage.
The design phase must (also) ensure that appropriate system and data access permissions have been
gained from the data (information asset) owner, whose responsibility it is to ensure that information
confidentiality, integrity and availability is maintained. In practical terms, the data (information asset)
owner may additionally be either the business or systems owner.
For existing applications where design is already complete, access controls should be reviewed when
the following types of application modifications occur:
 The application is being revised to access or generate information of a greater sensitivity than
the original design catered for. E.g. Confidential when the application was designed to access
Restricted.
 An internal web enabled application is being modified to be externally facing.
 A non-web application is being web enabled.
If direct access to (raw) data is permitted, these controls cannot be effectively implemented; i.e. where
access is required to change data in order to ensure that the application continues to function
effectively, such as database or file administration.
Where such access is required, additional, more comprehensive, controls must be deployed to provide
higher levels of access and accountability control. This type of access should be restricted solely to
those who require access to maintain the quality and integrity of the data.
These controls can be implemented by the infrastructure or processes.
Last saved: 17/05/2009 05:17:00 AM 11/36

Restricted
Rule Criterion Supporting Compliant

no. material in (Y/N/S)
text?
DA1 Both the system and data (information asset) owner must Y
authorise access to the system and data, respectively.
DA2 As access to raw data is not permitted except for those whose Y
primary role is the maintenance of data integrity, these
communities must be identified.
DA3 These (DA2) communities must have a separate access Y

control mechanism.
DA4 These (DA2) communities must have a separate Y

accountability mechanism.
Last saved: 17/05/2009 05:17:00 AM 12/36

Restricted
3.2 Information Classification Generic Rules

All information within the Shell Group must be classified in accordance with Group Information
Security Classification Standard. Applications permitting access to this information, or the data that
underpins it, must ensure that this classification is maintained.
Full details of Information Classification is given in the Group Information Security Classification
Standard (IS237 – Information Security Classification Standard).
Applications transform data into information. When deploying an application, therefore, both
information input to and output from an application need to be considered for classification purposes.
The application will need to be able to support access rules that pertain to the highest classification
required.
Certain applications that handle Most Confidential information may benefit from isolation from general
access by using additional security controls above and beyond the ISS. Examples of this are
Exploration, Mergers and Acquisitions, or Information Security systems. Whilst this considerably
improves the security of the application, this will increase both the cost of implementing and operating
the application. Thus, caution should be taken in selecting this option; both the benefits and costs of
isolation should be determined by risk assessment.
To ensure that security controls reflect the classification of the information being accessed or
generated, a risk analysis must be conducted before or during the design phase in conjunction with
the data (information asset) owner, whose responsibility it is to ensure that information confidentiality
and integrity is maintained. The IRAM process as described in IS251 – Information Security Risk
Management Process can be used as means to performing a Risk Assessment. This process is also
linked to Shell impact measures, as contained in Business Impact Reference Tables (BIRT).
In practical terms, the data (information asset) owner may also be either the business or systems
owner.

preface?
IC1 The Information being accessed must be classified by the Y

data (information asset) owner in accordance with the
Information Security Classification Standard (IS237 –
Information Security Classification Standard).
Last saved: 17/05/2009 05:17:00 AM 13/36

Restricted

preface?
IC2 The Information being generated must be classified by the Y

data (information asset) owner in accordance with the
Information Security Classification Standard (IS237 –
Information Security Classification Standard).
IC3 For applications accessing or generating Most Confidential Y

Information, a risk assessment is required to determine
additional controls required.
3.3 Identity Management Generic Rules

While it is important to understand the nature of the data being accessed by an application, it is
equally important to establish the identity of all of those using it, in accordance with the Identity
Management Standard.
The following levels of assurance have been agreed as being appropriate for Identity Management
across all Group businesses: The following broad definitions cover the agreed types of classification:
 Level 0, None/Anonymous Level Identity Assurance. Provides minimal assurance of
asserted electronic identity. Suitable only for transactions where an error may lead to minimal
harm to the Group.
 Level 1, Low Level Identity Assurance. Provides on the balance of probabilities that there is
some confidence in the asserted electronic identity. Suitable only for transactions where an
error in authentication of identity might lead to minor harm.
 Level 2, Substantial Level Identity Assurance. Provides high confidence in the asserted
electronic identity. Suitable for transactions where an error in authentication of identity might
cause significant harm.
 Level 3, High Level Identity Assurance. Provides very high confidence in the asserted
electronic identity. Suitable for transactions where an error in authentication of identity might
result in considerable harm.
Further details of Identity Management are given in the ISS Register (IS220 – Information Security
Control Register).
When deploying an application, the first step is to establish a full list of all communities that require
access to it. This must include applications, database, and systems administrators and others who
require access to maintain the application and its environment.
Last saved: 17/05/2009 05:17:00 AM 14/36

Restricted
To ensure that security controls reflect the assurance associated with the community or communities
using it, a risk analysis must be conducted before or during the design phase. The IRAM process as
described in IS251 – Information Security Risk Management Process can be used as means to
performing a Risk Assessment. This process is also linked to Shell impact measures, as contained in
Business Impact Reference Tables (BIRT).
When all communities have been identified, it is then necessary to establish whether all members of
these communities have an identity that meets the assurance levels outlined above. Three outcomes
apply:
 The identity of all members of all communities is issued and managed by an Identity
Management System.
 The identity of some members of some communities are outside the scope of any Identity
Management System, but controls can be established to achieve the levels of assurance
described in the Identity Management Standard.
 The identity of some members of some communities cannot be established to meet the levels
of assurance outlined in the Identity Management Standard.
Where assurance levels cannot be met, there are three courses of action available:
 Seek risk acceptance from both the system and data (information asset) owner. These risks
should be formally documented in accordance with the Group Step Out process (GRC130 -
Information Security Standard Step-out Process). Note that where group risk is involved,
the risks cannot be accepted solely by the local organisation or own business. .
 Restrict access to the application in accordance with the Classification of Information that it
accesses or generates. A simplified table is presented below.
 Review any step-outs needed with the Global IT Security Standards and Policies group.
The following table is an indication of the types of access one might expect to see. For the provision
of authentication controls, where an Identity Management System is not available, this table can be
assumed a good indicator. It is, however, simplistic with regard to the provision of authorisation
permissions and should not be taken as definitive. For example, untrusted users may be allowed to
input confidential information, Trusted users may be able to view some confidential information but not
all. These should be determined through risk analysis during system design.
Level 0 Level 1 Level 2 Level 3

Unrestricted X X X X
Restricted X X X
Last saved: 17/05/2009 05:17:00 AM 15/36

Restricted
Confidential X X
Most Confidential X
To provide appropriate levels of identity assurance, the following functions should be in place for all
applications:
 Identification: ensuring that a person is who they say they are. All Service Delivery (SD) and
Middleware (MDW) users must be formally identified prior to allowing them access to the
reports
 Authentication (a security control process that verifies asserted credentials)
 Authorisation (a security control process that grants permissions to access specific categories
of information or to carry out defined tasks)
 Accountability (a security control process that records the linkage between an action and the
identity of the individual or role that invoked the action, thus providing an evidence trail for
audit or non-repudiation purposes)
 Audit (a security control process that examines data records, actions taken, changes made
and identities/roles invoking actions which together provide a reconstruction of events for
evidential purposes).
Where it is available, an Identity Management System will provide appropriate controls for
identification, authentication, and audit.
Where it is not, it is good practice for those deploying the application to ensure that assurance levels
identified by the Identity Management Standard are provided.
Identification and authentication must provide sufficient assurance to reflect the access requirements
indicated by the Group Information Security Classification Standard (IS237 – Information Security
Classification Standard); the classification aspects of these are outlined in the table above (Integrity
and Availability are not included).
The use of a GI approved smartcard is the preferred mechanism to provide authentication as it

provides two factor authentication. Note, however, that the application must still provide the
authorisation mechanism as indicated below in section 3.4.
IF passwords are being used, password security must be sufficiently robust to ensure that
accountability remains appropriate to the information classification.
Where this is not possible due to restrictions in system functionality, these requirements should be
issued as guidance to users and as many of the settings implemented as is possible (similarly, other
applications requirements, such as a list of impermissible passwords should be implemented where
available).
Last saved: 17/05/2009 05:17:00 AM 16/36

Restricted
Providing authorisation and accountability controls is the responsibility of the application. At this time,
these are recommended rather than mandatory rules, and are covered in more depth, below.

text?
IM1 All members of all communities requiring access to the Y

application must be identified.
IM2 An identification process should be provided for all members Y

of all communities, in accordance with the Identity
Management Standard. If an Identity Management System is
being used this can be assumed.
Existing applications should provide assurance levels

indicated by the Group Information Security Classification
Standard (IS237 – Information Security Classification
Standard).
IM3 An authentication process should be provided for all members Y

of all communities, in accordance with the Identity
Management Standard. If an Identity Management System is
Existing applications should provide assurance levels

indicated by the Group Information Security Classification
Standard (IS237 – Information Security Classification
Standard).
GI approved smartcards and connectivity via a ISS compliant

server each provide sufficient assurance levels to access
Restricted information. When either is used in conjunction
with Strong passwords assurance is sufficient to access
Confidential Information.
IM4 An audit process should be provided in accordance with the Y

ISS Control Register (IS220 – Information Security
Controls Register). If an Identity Management System is
IM5 If all members of all communities cannot be identified, the Y

risks must be acceptable to the system and data (information
asset) owners.
Last saved: 17/05/2009 05:17:00 AM 17/36

Restricted
3.4 Authorisation Generic Rules

It is the responsibility of those deploying the application to ensure that the application (or the
operating system or Database Management System on the application’s behalf) provides a
mechanism to permit (or authorise) access to data. This is to ensure that:
 Unauthorised access is not allowed.
 Authorised users may only undertake actions for which they have permission.
 Authorised activities can be traced to an individual, i.e. all users are accountable for their
actions.
To achieve appropriate levels of accountability:

 Access rights to the application must be authorised by the data (information asset) owner. This
includes:
o The use of roles for data access.
o Access by applications, database, and systems administrators and others who
maintain the application, its data, and its environment.
All users must have unique identifiers unless there is formal approval for a functional account.
Functional accounts must comply with the controls as contained in the ISS control register (IS220 –
Information Security Controls Register). Note that each user may have more than one identity, and
is required to do so if performing a separate function; for example system administration.
To ensure accountability over the lifetime of the application, unique identifiers, such as user ids, should
not be re-allocated once the original owner has no further need.
It is the responsibility of each user to ensure the security of their id. IDs should only be shared by
those who have an explicit need to do so (e.g. systems administrators.). Passwords should never be
shared or divulged.
Other means of ascertaining identity, such as shared secrets, may be shared with those responsible
for maintaining the primary identity credentials. For example, mother’s maiden name may be shared
with the help desk to provide greater assurance when dealing with problems.
If inter-platform access is required, for example, where an application accesses a database, the
requesting platform should have a unique identifier. Where user id and password are deployed, a user
id must be deployed and maintained for its sole use. In this case, it is the responsibility of those
maintaining data integrity (on behalf of the data (information asset) owner), for example a Database
Administrator, to ensure that the identifier, and any associated password or PIN, conforms to password
policies.
Last saved: 17/05/2009 05:17:00 AM 18/36

Restricted
It is the responsibility of those developing an application, on behalf of the data (information asset)
owner, to ensure a process is in place to issue, manage, and revoke access rights in accordance with
the life-cycle of an end user or platform.
Revocation or, as a minimum suspension, of users or platforms should apply immediately when they
no longer have a need for data access. It is recommended, for data classed as restricted or higher,
that periodic revocation (or account suspension) is provided; clearly, re-activation of access rights
should not be onerous for valid users.
Authorisation is normally associated with the following access rights:

 Read/View. The ability to read data or subsets of data.
 Insert. The ability to either add or append data or subsets of data.
 Update. The ability to amend data or subsets of data.
 Delete. The ability to remove data or subsets of data.
It is the responsibility of those developing an application to ensure that accountability for each of these
functions is provided, in accordance with the wishes of the data (information asset) owner.
The mechanism deployed must support the capability to map the identity assurance level to the
access rights authorised by the data (information asset) owner, either by individual identity or the role
that they are performing. For example, Substantial level identity assurance may be required to perform
the delete function.
To ensure that the authorisation mechanism itself remains secure:

 Wherever possible, the authorisation mechanism will be separate from the main application,
ideally as a separate component.
 Access to the authorisation component must be separate from normal access; i.e. segregation
of duties must occur. If an individual requires access to both, then separate identities must be
issued to indicate this.
 If passwords, PINs, or other means of personal identification are used they must be encrypted
or hashed in transit and should be encrypted or hashed when stored. One-time temporary
(time limited) passwords may be transmitted ‘in the clear’.
 It is recommended, that the information within the authorisation component be considered
either Confidential or Most Confidential. The assurance levels of those having access to the
function is Substantial or higher.
These rules should be implemented in conjunction with section 3.3 i.e. GI approved smartcards and
connectivity via a ISS compliant server both provide sufficient assurance levels for user authentication.
When used in conjunction with Strong passwords assurance is sufficient to access Confidential
Information.
Last saved: 17/05/2009 05:17:00 AM 19/36

Restricted

text?
AR1 Access rights must be agreed by the data (information asset) Y

owner.
AR2 Agreed access rights must cover all communities who require
access. Note that those who require direct access to ‘raw
data’, such as systems or data administrators, must have
separate access controls as indicated by rule DA 3 and
should have additional, comprehensive controls.
AR3 Accounts for accessing the system/application shall either: Y
 Be used by only one user/application; or

 The users shall be provided with a functional account
with access at only application-level (e.g. to a specific
application, or to a web browser), and not at operating-
system-level (e.g. to the operating system prompt), and
it must still be possible to trace usage back to an
individual (e.g. using log-book and/or shift records to
assist with tracing usage to a particular person).
If it is absolutely necessary for more than one person to use

share/use the account (e.g. shared admin or functional
accounts), then either it must be possible to trace usage back
to an individual (e.g. via: electronic logs; shift records; manual
log books), or else the shared account must be restricted as
follows:
 access to only a limited set of business applications

(e.g. an application portfolio ), AND,
 access to applications shall be only allowed based on an
assessment of the security risks involved, AND,
 business-owners of the applications have accepted the
fact that it is not possible to trace back to an individual,
AND,
 access to the operating system and network shall be
prevented, AND,
 allowed applications shall not permit the above
Last saved: 17/05/2009 05:17:00 AM 20/36

Restricted

text?
restrictions to be bypassed.
AR4 Passwords and other identification mechanisms, such as PINs Y
or tokens, should only be known by or allocated to one user.
AR5 If an application or system requires access to another Y

application, database, or system, the application requiring
access must have its own unique id to provide accountability.
This id must conform to normal identity management rules as
outlined above in the supporting text.
AR6 An authorisation mechanism must be selected to manage Y

access.
AR7 Wherever possible, the authorisation mechanism should not Y

be part of the application. This is to aid introduction of Identity
Management systems.
AR8 Access to the authorisation mechanism must be separate Y

from access to the main application. This is to ensure that
segregation of duties are clearly distinguished between those
using the application and those managing access to it.
Provision of this segregation of duties is mandatory.
AR9 Processes must be in place to ensure that issuance, Y

management, and revocation (or as a minimum suspension)
of access rights are provided in accordance with the wishes of
the data (information asset) owner.
AR10 For information classified as Restricted or higher, adoption of Y

periodic revocation (account suspension) should be
implemented, in accordance with the wishes of the data
(information asset) owner. When employed, a process must
be developed for re-activation.
Revocation should take place when an account has not been

used for a reasonable period of time; e.g. two months.
Existing applications must comply with this IF Information is

classified as either Confidential or Most Confidential OR they
are externally facing.
Last saved: 17/05/2009 05:17:00 AM 21/36

Restricted

text?
AR11 Personal authentication credentials, such as passwords, must Y

be encrypted in transit and should be encrypted when stored.
AR12 The authorisation mechanism must restrict access after a Y

number of failed attempts. Existing applications must comply
with this IF Information is classified as either Confidential or
Most Confidential OR they are externally facing.
AR13 Adoption of Strong passwords is mandated for information Y

classified as Confidential or Most Confidential. However,
unless the application is externally facing, password
management should be undertaken by education rather than
application enforcement.
Last saved: 17/05/2009 05:17:00 AM 22/36

Restricted
3.5 Accountability Generic Rules

When data is accessed or changed, it is the responsibility of those developing the application to
ensure that the application, or the database management/file system on its behalf, provides
accountability as per the following guidelines.
Normally this will be via audit logging of both application logon/logoff and specific data access. The
level of audit logging required will depend upon the classification of the information being accessed. As
a guide, consider logging the following:
Logon/Off Read/View Insert Modify/ Delete

Update
Unrestricted X X X
Restricted X X X X
Confidential X X X X X
Most X X X X X
Confidential
The following data is normally kept:

 Identity of the item updated.
 Type of Update: Logon/Logoff/View/Read/Insert/Update/Delete.
 Date/Time. [Ensure the system clock is maintained!]
 Identity of the user.
Where possible, for non-repudiation purposes, the actual identity of the user should be logged rather
than the role used for authorisation. However, the role can be used as long as this can be bound to
the actual identity via the authentication process or other appropriate audit mechanisms.
For systems that employ the use of public key infrastructure, the certificate of person can be used as
the identity by applying a digital signature to the audit log. Further details of Encryption are given in the
ISS controls register (IS220 – Information Security Controls Register).
Data logs must only write/append to provide non-repudiation (i.e. the inability to deny) that an action
has taken place; access rights other than this should be restricted to read only.
Access to audit logs, other than write/append, should be restricted in accordance with the wishes of
the data (information asset) owner, and reflect both the classification of data and the period for which
they must be retained. For some highly sensitive systems, or where governance dictates, some logs
may need to be retained off site. In this case, they must be protected against unauthorised access and
changes.
Last saved: 17/05/2009 05:17:00 AM 23/36

Restricted
Additionally the following may also be of use (refer to Section 10.10.1 of the IS Control Register
(IS220 – Information Security Control Register)):
 In a multi-platform environment, log key events across the platforms. For example, failed
logins, data modification/retrieval, network access, and so forth. Synchronise all system
clocks.
 Agree retention time for each Log file.
 Secure and backup log files.
 Send detailed error messages to the error log.
 Do not log passwords or any other sensitive data unless it is encrypted.

text?
AC1 If required by the data (information asset) owner, then an Y

accountability (logging) regime must be established in
accordance with Information Security Classification Standard.
AC2 If logging is required then a mechanism must be established Y

to ensure that actions can be traced back to an individual.
AC3 Logs must be secured from unauthorised changes. Y
AC4 Retained logs must be protected against over-writing for a Y

reasonable period (e.g. 3 months) as agreed by the data
(information asset) owner.
AC5 Where offsite logs are required, they must be protected Y

against unauthorised access and changes.
Last saved: 17/05/2009 05:17:00 AM 24/36

Restricted
3.6 Securing the Application – Generic Rules
3.6.1 Validate ALL input

Make sure that there is an INPUT data validation process. Data input should be considered as
malicious until proven otherwise. When doing so:
 Do not rely on client-side validation, implement server code validation.
 Consider it a core process on your application design.
 Validate, at least: format, length, range and type. Reject known bad input.
 For critical applications, centralise, if possible, your INPUT Validation process. It will reduce
your development and maintenance cost.
Input validation is mandatory for new and/or externally facing applications.
For existing applications, implementing input validation is based upon risk assessment.
3.6.2 Use Secure Coding techniques

Server side applications can be written in many programming languages. If scripts are not prepared
carefully, however, attackers can find and exercise flaws in the code to penetrate a Web server. An
attacker can find flaws through trial and error and does not necessarily need the source code for the
script to uncover vulnerabilities. Therefore, applications should be written with security in mind by
using secure coding standards. There are several versions available, normally associated with a
particular language. Guidance for establishing likely threats and developing countermeasures is
presented in Appendix A Threat Modelling. New applications should adopt this control.

text?
SA1 Validate ALL input. Ensure that this is tested. This is mandatory Y
for all new and/or externally facing applications.
SA2 For internal development, secure coding standards should be Y

used, wherever possible.
Last saved: 17/05/2009 05:17:00 AM 25/36

Restricted
3.7 Application Deployment Generic Rules
3.7.1 Development Phases

The following diagram illustrates the project lifecycle and is a subset of the Project Delivery
Framework(PDF) application stage gates:
Application Environments
Requirements,
Definition Development Deployment
& Design
Patterns Framework
 The Requirements, Definition & Design Environment. This covers business analysis and
modelling aspects.
 The Development Environment. This covers tools, environments and best practice for systems
build & test.
 The Deployment Environment. This covers the tools, environments, and best practice for
systems deployment into operations.
 The Patterns Framework. These are a set of reusable building blocks that can be used to
facilitate design, development, and deployment of business systems.
Note that for guidance purposes more detailed information regarding the Project Delivery Framework
can be found at the following website: http://sww-deliveryframework.shell.com/index.asp.
In order to maximise the benefits gained from security, it is recommended that security controls are
‘built in’ rather than added at a later stage. In practice, this means ensuring that decisions are made
and actions taken at the appropriate point in the application life cycle.
Note that whilst certain aspects of design and development are not necessarily part of selecting and
deploying a packaged application, fundamental elements of deployment must take place for all
applications. These are indicated where appropriate.
3.7.2 Requirements, Definition & Design

The primary requirement is to ensure that the functionality determined by the business risk
assessment is reflected in the systems design. The primary focus for this is:
Last saved: 17/05/2009 05:17:00 AM 26/36

Restricted
 The communities using the application, defined in terms of Identity Management Standard
Assurance.
 The Information Classification of the data being either accessed or generated.
From this the following security controls can be scoped:

 Provision of an assured identity. How will the application interface with the means of
identification, authorisation, and audit?
 Whether to select or build an authorisation mechanism.
 To determine the authorisation process; how to provide segregation of duties.
 Whether authorisation is to be controlled by identity or role.
 To determine whether encryption is required for sensitive data and how will this be achieved.
 To determine accountability (Audit logging) technology and procedures. What changes are
logged and how? How will evidence be produced?
 To determine where the application will be deployed. To ensure that it is secured from
malicious access or tampering.
For Business Critical systems, the decision of whether to isolate the system, i.e. restrict it to a defined
community, should be made at this point.
Testing criteria should also be agreed at this point. For new applications or major changes to existing
applications, the decision of whether to perform a penetration test should be made at this point.
These actions should be undertaken for both bespoke and packaged applications.
3.7.3 Development
As development is increasingly deployed to external agencies, particularly off –shore, it is important to
ensure that code which accesses sensitive information is trusted.
Therefore, where application code accesses sensitive information, use separation of duties during
development - particularly if encryption is used. Ensure that only a limited number of trusted
developers can understand and use access paths.
Ensure that hardware security measures can be successfully tested before deployment. This requires
that the physical design is finalised as early as possible in the development process.
Environment Segregation
In order to ensure that applications may be deployed securely, without disruption or compromise, it is
recommended that the following segregated environments are established:
Last saved: 17/05/2009 05:17:00 AM 27/36

Restricted
 Development/Unit testing. Where the developers of the code ensure that it performs only
those tasks that it is developed to undertake.
 Integration/Systems testing. Where those who have specified the application ensure that the
integrated system performs only those tasks that it is specified to undertake.
 Business/Pre-production testing. Where the system owner, or their agents, ensure that the
system performs the business logic required.
 Production. Operational/Live running.
As a minimum, Testing and Operational/Live running must be separate.

Note that separate environments does not necessarily imply separate physical systems; for example
mainframes are particularly proficient at segregation of test and production systems. However, where
a single system provides more than one environment, care must be taken to ensure that the
application can be restored in the event of system loss; for example, loss of a data centre through the
use of disaster recovery.
Formal Change Control procedures must be applied as the application progresses through each
environment. This must include the capability to both progress and regress the application; an industry
standard code management system should be used for this purpose. Where possible, use an
independent Quality Assurance ‘Gatekeeper’ whose role it is to ensure system integrity. As a
minimum, follow industry quality standards or best practice for formally undertaking this role at the
staging/production gate.
Environments and change control processes apply equally to both bespoke and packaged
applications.
Testing
Formal testing of the system must be undertaken before handover to deployment, as indicated by the
Group Information Technical Architecture (GITA) testing criteria. Applications passed between
environments must be under full change control processes, ideally administered by an independent
Quality Assurance Gatekeeper.
Testing must ensure that:

 All legitimate routes through the application logic are exercised using ‘use cases’, which
outline and document all legitimate logical routes. Use cases must be determined at the time
of design when logical paths are being mapped.
 All major non-legitimate routes are exercised to ensure that appropriate error responses are
given.
 Ensure that all input and output data streams are validated. Ensure that malicious code or
data is rejected.
Last saved: 17/05/2009 05:17:00 AM 28/36

Restricted
 Ideally, the same group of people should not undertake development and testing. Consider
providing enhanced security through the segregation of duties.
If production data is used as part of the testing process, care should be taken to ensure that
appropriate security controls are applied to the information. In particular, never use production data
that is classified as Confidential or higher or that may contravene privacy or other legislation.
Penetration Testing, or ethical hacking, before deployment, is strongly recommended for deploying
larger systems or where major changes have been made to an existing system. Penetration Tests will
determine both the security of the application code itself and the environment in which it runs.
Web applications should be scanned periodically for vulnerabilities. An annual remote penetration test
is also strongly recommended.
Testing regimes and criteria apply equally to both bespoke and packaged applications.
3.7.4 Deployment
For bespoke applications:
 Ensure that all bespoke code undergoes independent code review by a Quality Assurance
‘Gatekeeper’. The Gatekeeper’s role can ensure that secure coding standards have been
used and that code only undertakes the purpose for which it has been designed; i.e. there are
no ‘Trojan Horses’.
 As checking all code may prove both onerous and costly, consider code sampling; i.e. random
inspection of code. It is strongly recommended, however, that code accessing highly classified
information is always independently checked.
 The Gatekeeper must be allowed to inspect but not alter the code; this way separation of
duties can be assured.
During the deployment phase, physical security measures must be finalised:

 Physical location of devices (e.g. location of servers and network equipment in a restricted
area; location of workstations in the office area);
 Physical security measures for the locations in question (e.g. ISS-compliant protection of the
restricted area, with appropriate door-locks and access controls; regular security checks;
supervision of visitors, whilst working in the restricted area etc.).
Likewise, the "logical" network design must also be finalized at this stage. This should include
considerations, such as the following:
 The appropriate logical location of devices should be carefully considered (e.g. location in the
Shell network, location in DMZ etc.);
Last saved: 17/05/2009 05:17:00 AM 29/36

Restricted
 Ensure that defences such as Firewalls, Intrusion Detectors, Virtual Private Networks (VPNs),
Router Access Control Lists and analysis tools are both installed and working correctly;
 When the design phase risk assessment requires it, undertake a penetration test of the
system.
In addition, management procedural coverage must be established for the systems in question, such
as:
 Operational change control;
 Adding to- and removing from- inventories (including consideration for supporting
components/services)
 Classification;
 Event logging;
 Incident management;
 Etc.
These should also be confirmed with the ISS Focal Point for the location(s), as and where necessary.
Deployment processes apply equally to both bespoke and packaged applications.
Please Note: The following rules only apply to New Developments. This is in effect since the original
publication date of June 2004.

text?
AD1 During a project lifecycle, Security must be built into the Y

product/processes at the correct lifecycle stages, rather than
added on at a later stage.
AD2 Separation of the following life-cycle environments is Y

recommended: Development, Integration, Staging and
Production.
AD3 Separation of the following life-cycle environments is Y

mandated: Test and Production.
AD4 A stage gate process must be established between Y

environments to ensure that the system may be progressed
and regressed. A code management system must be adopted
to provide controlled change management.
Last saved: 17/05/2009 05:17:00 AM 30/36

Restricted

text?
AD5 An Independent Quality Assurance ‘Gatekeeper’ should Y

oversee the stage gate process (AD3).
AD6 All primary decisions regarding Information Security must be Y

made during the design phase based upon the risks identified
during risk assessment. The objective is to develop controls
to mitigate risk to levels acceptable to the system and data
(information asset) owner(s). Formal acceptance of
remaining risks must be undertaken by the system and data
(information asset) owner(s).
AD7 Testing regimes must be determined during the design Y

phase.
AD8 For bespoke developments, where possible, secure coding Y

standards should be adopted.
AD9 When developing a bespoke application that requires access Y

to Confidential or Most Confidential data, coding that
provides this access should be undertaken by more trusted
developers, segregated from the main development team.
AD10 A formal testing phase must be undertaken before handover Y

to production/live running.
AD11 The formal testing phase must ensure that all legitimate Y
routes through the application are tested in accordance with
the test plans determined earlier.
AD12 The formal testing phase must ensure that all identifiable Y
non-legitimate routes are exercised to ensure that
appropriate error responses are given.
AD13 The formal testing phase must ensure that all input and Y
output data streams are validated, to ensure conformance
with ISO 17799. This is mandatory for all new and/or
externally facing applications.
AD14 The formal testing phase must ensure all input is thoroughly Y
checked and does not contain malicious code or data, such
as worms, viruses or other means of application or system
Last saved: 17/05/2009 05:17:00 AM 31/36

Restricted

text?
corruption. This is mandatory for all new and/or externally

facing applications.
AD15 It is recommended that the same group of people should not Y

undertake development and testing as this may lead to
incomplete or inadequate tests. Ensure segregation of duties,
particularly during integration and business testing.
AD16 If production data is used as part of the testing process, care Y

must be taken to ensure that appropriate security controls are
applied to the information being used.
AD17 Production data that is classified as Most Confidential, or that Y

may contravene privacy or other legislation must not be used
for testing under normal circumstances. Confidential Data may
be allowed subject to sufficient compensating controls.
Approval/Agreement must be obtained from both data
(information asset) owner(s) and business application owner
that copies of Confidential production data can be used for
testing. Access controls, as well as accountability controls,
should be implemented where possible for these applications
in accordance with the ISS in the testing environment.
AD18 For bespoke applications, where possible, ensure that all Y

bespoke code undergoes independent code review,
particularly where it accesses sensitive information.
AD19 All primary decisions regarding physical security must be Y

made during the design phase based upon the risks identified
during risk assessment. The objective is to develop controls
to mitigate risk to levels acceptable to the system and data
(information asset) owner(s).
Formal acceptance of remaining risks must be undertaken by

the system and data (information asset) owner(s).
Last saved: 17/05/2009 05:17:00 AM 32/36

Restricted
Appendix A: Threat Modelling

Threat modelling is a useful tool that may assist in developing a secure application. It is presented
here for guidance.
Who Does What?

Designing and building secure applications is a collaborative effort involving multiple roles. The first
step is to build a RACI Chart. RACI stands for:
 Responsible (the role responsible for performing the task)
 Accountable (the role with overall responsibility for the task)
 Consulted (people who provide input to help perform the task)
 Keep Informed (people with a vested interest who should be kept informed)
Develop a RACI chart at the beginning of the project to identify the key security related tasks together
with the roles that should execute each task.
Table 4 illustrates a simple RACI chart. (The heading row lists the roles; the first column lists tasks,
and the remaining columns delineate levels of accountability for each task according to role.)
System Security
Tasks Architect Administrator Developer Tester Professional
Security Policies R I A
Threat Modelling A I I R
Security Design A I I C
Principles
Security Architecture A C R
Architecture and Design R A

Review
Code Development A R
Technology Specific A R
Threats
Code Review R I A
Security Testing C I A C
Network Security C R A
Host Security C A I R
Application Security C I A R
Deployment Review C R I I A
Table 1: RACI Chart
Last saved: 17/05/2009 05:17:00 AM 33/36

Restricted
Identify Threats
In order to deploy successful security countermeasures it is first necessary to understand the threats.
Threats can be external, such as from an attacker on the Internet, or internal; for example, from a
disgruntled employee or administrator. This guide helps you to identify threats in two ways:
 It lists the top threats that affect applications at the network, host, and application layers.
 It presents a threat modelling process to help you identify which threats are relevant to your
application.
An outline of the threat modelling process.
1. Identify assets.
Identify the assets of value that the system must protect.
2. Create an architecture overview.

Use simple diagrams and tables to document the architecture of the application, including
subsystems, trust boundaries, and data flow.
3. Decompose the application.

Decompose the architecture of the application, including the underlying network and host
infrastructure design, to create a security profile for the application. The aim of the security
profile is to uncover vulnerabilities in the design, implementation, or deployment configuration
of the application.
4. Identify the threats.

Keeping an attacker's goals in mind, and with knowledge of the application's architecture and
potential vulnerabilities, identify the threats that could impact the application.
Last saved: 17/05/2009 05:17:00 AM 34/36

Restricted
5. Document the threats.

Document each threat using a common threat template that defines a core set of attributes
that should be captured for each threat.
6. Rate the threats.

Rate the threats to prioritise and address the most significant threats first. These threats are
the ones that present the biggest risk. The rating process weighs the probability of the threat
against the damage that could result should an attack occur. It might turn out that certain
threats do not warrant any action when comparing the risk posed by the threat with the
resulting mitigation costs.
Last saved: 17/05/2009 05:17:00 AM 35/36

Restricted
Appendix B: Document Change History

Action Date Who Action Type Section New Old Value New Value Further Information / Comments
No. Changed Version
1 10 March 2009 William Creation 0.1 ITCI023 IS-SPEC 023 - Application Generic This document is based on the
Kleyweg Specification information contained in ITCI023,
and is intended to provide more
“how” information for IT systems,
in support of the ISS.
2 17 March 2009 William Update 0.2 Update in connection with review

Kleyweg conducted by Stephen Kelly.
Last saved: 17/05/2009 05:17:00 AM 36/36

Restricted

Is-SPEC-APP-023 Application Generic Security Guideline v0.2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Is-SPEC-APP-023 Application Generic Security Guideline v0.2

Загружено:

Авторское право:

Доступные форматы

Information Technology

Release Date: 20 March 2009

Additional ISS related documents can be found here:

Version Revision Date Contributor’s Name Revision Description

Last saved: 17/05/2009 05:17:00 AM 2/36

Last saved: 17/05/2009 05:17:00 AM 3/36

Last saved: 17/05/2009 05:17:00 AM 4/36

1.3 Intended Readership

Last saved: 17/05/2009 05:17:00 AM 5/36

1.4 Relation to ISS

Documents within the ISS can comprise of three general levels:

Last saved: 17/05/2009 05:17:00 AM 6/36

Figure 1: Relation to ISS

This document is an implementation guideline, as it does not concern specific IT components.

1.5 Roles and Responsibilities

Last saved: 17/05/2009 05:17:00 AM 7/36

Last saved: 17/05/2009 05:17:00 AM 8/36

2 Application Generic Security Guideline

Last saved: 17/05/2009 05:17:00 AM 9/36

Last saved: 17/05/2009 05:17:00 AM 10/36

3 Application Generic Rules

3.1 Data Access Generic Rules

These controls can be implemented by the infrastructure or processes.

Last saved: 17/05/2009 05:17:00 AM 11/36

Rule Criterion Supporting Compliant

DA3 These (DA2) communities must have a separate access Y

DA4 These (DA2) communities must have a separate Y

Last saved: 17/05/2009 05:17:00 AM 12/36

3.2 Information Classification Generic Rules

Rule Criterion Supporting Compliant

IC1 The Information being accessed must be classified by the Y

Last saved: 17/05/2009 05:17:00 AM 13/36

Rule Criterion Supporting Compliant

IC2 The Information being generated must be classified by the Y

IC3 For applications accessing or generating Most Confidential Y

3.3 Identity Management Generic Rules

Last saved: 17/05/2009 05:17:00 AM 14/36

Level 0 Level 1 Level 2 Level 3

Last saved: 17/05/2009 05:17:00 AM 15/36

The use of a GI approved smartcard is the preferred mechanism to provide authentication as it

Last saved: 17/05/2009 05:17:00 AM 16/36

Rule Criterion Supporting Compliant

IM1 All members of all communities requiring access to the Y

IM2 An identification process should be provided for all members Y

Existing applications should provide assurance levels

IM3 An authentication process should be provided for all members Y

Existing applications should provide assurance levels

GI approved smartcards and connectivity via a ISS compliant

IM4 An audit process should be provided in accordance with the Y

IM5 If all members of all communities cannot be identified, the Y

Last saved: 17/05/2009 05:17:00 AM 17/36

3.4 Authorisation Generic Rules

To achieve appropriate levels of accountability:

Last saved: 17/05/2009 05:17:00 AM 18/36

Authorisation is normally associated with the following access rights:

To ensure that the authorisation mechanism itself remains secure:

Last saved: 17/05/2009 05:17:00 AM 19/36

Rule Criterion Supporting Compliant

AR1 Access rights must be agreed by the data (information asset) Y

AR3 Accounts for accessing the system/application shall either: Y

 Be used by only one user/application; or

If it is absolutely necessary for more than one person to use

 access to only a limited set of business applications

Last saved: 17/05/2009 05:17:00 AM 20/36