política faculdade

8/6/2019 Poltica Faculdade

1/31

Restricted

Application Security Kit

IT for CVGM - SOPLA

Rio de Janeiro - BRAZIL

Version 1.1 - Final


2/31

Restricted

Table of Contents

1 INTRODUCTION ........ ........ ........ ........ ........ ........ ........ ........ ......... ........ ........ ...... .... ..... .... 3

1.1 I NTENDED

SCOPE

............................................................................................................. 31.2 T ARGET AUDIENCE .......................................................................................................... 3

2 APPLICATION SUPPORT STANDARDS ......... ........ ........ ........ ........ ........ ....... .... ..... .. 5

2.1 A PPLICATION DEVELOPMENT PRINCIPLES ............................................................................. 5

2.2 A PPLICATION SECURITY GENERIC R ULES ............................................................................ 8

2.3 D ATA ACCESS GENERIC R ULES ......................................................................................... 8

2.4 I NFORMATION CLASSIFICATION GENERIC R ULES ................................................................... 9

2.5 I DENTITY MANAGEMENT GENERIC R ULES ........................................................................... 9

2.6 A UTHORISATION GENERIC R ULES ..................................................................................... 11

2.7 T HE USE OF STRONG PASSWORDS ..................................................................................... 12

2.8 A CCOUNTABILITY GENERIC R ULES ................................................................................... 14

2.9 C LIENTS GENERIC R ULES ................................................................................................ 16

2.10 A PPLICATION DEPLOYMENT GENERIC R ULES ................................................................... 19

2.11 C ONTENT AND DATA - G ENERIC R ULES .......................................................................... 23

2.12 N ON-ERP S PECIFIC STANDARDS ................................................................................... 31

Application Security Kit 2/31


3/31

Restricted

1 Introduction

This document describes the generic Security Application Support standards to be used for

all applications in SOPLA. These standards will ensure that the applications will becompliance with all Global IT Security Standards and Policies.

References:

ISIP - KIT 3ITCI007 - IT4S Application Security Standard - Final Version 1.10ITCI022 - IT4S Application Security Policy - Final Version 1.7ITCI025 - IT4S Data Security Management Standard - Final Version 1.10

ISIP - KIT 6 ITCI023 - IT4S Application Generic Specification - Final Version 1.32ITCI024 - IT4S Data Security Generic Specification - Final Version 1.32ITCI027 - IT4S Web Systems Generic Specification - Final Version 1.3.1

ISIP - KIT 8ITCI037 - IT4S Information Security Classification Standard - Final Version 1.6ITCI041 - IT4S Information Security Classification Guideline - Final Version 1.3Others

ITCI003 - Information Security IT for CVGM Encryption Standard Final Version 1.2ITCI005 - Identity Management Security Standard Final Version 1.5ITCI020 - Information Security System & Network Generic Rules Final Version 1.3.4ITCI055 - Infrastructure Security Event Management Standard Final Version 1.04

1.1Intended Scope Generic applications such as operating systems, application environments (e.g Websphere)or databases are beyond the scope of this document.

On the scope Web applications are defined here as an application accessed by a user via abrowser using the HTTP protocol family. This means applications having another primaryprotocol, e.g., FTP, SMTP are not in scope. In addition, excluded from scope are WebServices which serve automated clients using XML payloads over protocols such asHTTP/SOAP. A web application typically serves both dynamic and static content.

However, web sites serving purely static content are also in scope.Any application developed and operated solely for personal use is not required to conformto this specification.

1.2Target Audience This document is intended for all Project Managers (PM), IT Service Providers, systemarchitects, security managers, developers, systems administrators and vendors. Thisdocument will provide them with the guidance for understanding and applying thesestandards on the development of new applications.

https://sww-knowledge-tw2.shell.com/knowtw2/livelink.exe?func=doc.Fetch&NodeId=2821814https://sww-knowledge-tw2.shell.com/knowtw2/livelink.exe?func=doc.Fetch&NodeId=2821574https://sww-knowledge-tw2.shell.com/knowtw2/livelink.exe?func=doc.Fetch&NodeId=2821814https://sww-knowledge-tw2.shell.com/knowtw2/livelink.exe?func=doc.Fetch&NodeId=2821574


4/31

Restricted



5/31

Restricted

2 Application Support Standards

2.1Application Development Principles Guiding principle: Re-use before buy before build

The existing ERPs are the preferred options and should be evaluated for all the newrequirements. The strategy is to prefer extending or configuring existing strategic Groupapplications, the use of a market service, or purchasing software packages beforedeveloping a custom application. Application development should be limited to specialuse and differentiating business functions.

The decision tree will give explicit guidance on the preferred technology set in order tolimit unnecessary diversity and reduce costs.

Application development is expected to move from a client/server software perspective toa solution based on the emerging Web and Grid Services (service-oriented architecture).The following guidance has been considered for the definition of the preferredarchitecture, and should be taken into account when developing new applications.

Preference for mature technologies, open interface and industry standards;

Prefer service oriented rather than client/server architectures;

Take a component-based approach, with reuse of common components whereverpossible;

Consider restrictions of remote/mobile access when necessary:

o Prefer thin-client to thick-client solutions;

o No business logic in the client presentation, separate the business logicfrom the presentation layer;

Consider web-enabled applications over applications that require client-sideinstallation:

o This allows the delivery of applications to a broader range of devices in amuch simpler way

o Citrix is recommended only on special cases;

Purchased applications should be aligned as much as possible with .NETframework;

Applications must be written in a parameterised way as far as possible. Thisgives flexibility and allows for easier re-use and adaptation to changing businessconditions, in turn reducing the number of enhancements required in future;

Parameters should also be considered for the setup of help files, multi-languageapplications, etc, instead of hard coding;



6/31

Restricted



7/31

Restricted

The strategic architecture for the non-ERP application portfolio will be centred onMicrosoft technologies.

Item Technology to be used

Application Writing The strategic tool set for application development is MicrosoftsVisual Studio .NET;

Language

Custom-written non-ERP applications should be written based onthe MS .NET suite.

C# is the strategic language for .NET;For web applications consider ASP.NET;

Current version of .NET Framework 1.07 (for client and webapplications);

(more details in sub-Section 5.4)

Database

MS SQL Server 2000 is the strategic DBMS for .NET and should

be used for both web and non-web applications;Oracle is the strategic DBMS for ERP applications;

(more details in sub-Section 5.2)

Data Modelling Erwin (currently version 4) should be used for creation of DataModels with the guidance of the Data Analysts;

User Interface The target user interface is the standard GID-supported webbrowser; (Currently Internet Explorer 6.0)

Components It is expected that over time a component repository will bedeveloped holding common components that should be re-usedwherever possible;



8/31

Restricted

Information Analysis

Cognos is the primary toolset for high-end analysis (BI Business Intelligence);

MS Office Suite should be used for low-end reports;

KnowledgeManagement

Global Livelink is the standard for business documentmanagement and should be used for simple document repository / workflow applications;

ApplicationIntegration

Industry XML standards;

MS Data Transformation Services solution;

BizTalk service and Microsoft Message Queuing (MSMQ)depending on costs constraints;

2.2Application Security Generic Rules Nonetheless, those responsible for deploying the application into an operationalenvironment must ensure that appropriate controls are applied in accordance with GroupStandards, in particular:

Application Security Standard - ITCI 007.

Data Security Standard - ITCI 025.

How these controls are applied should be determined during the design phase, or, forpurchased (package) applications during the procurement stage.

Where the web application is deployed within the Group Open Network, additionalcontrols are mandatory for production systems that are hosting the application. These aredescribed in Information Security System & Network Generic Rules (ITCI 20).

2.3Data Access Generic Rules

Rule No.

Criterion

DA1 Ensure that appropriate system and data access permissions have been gainedfrom the data owner.



9/31

Restricted

DA2 As access to raw data is not permitted except for those whose primary role is themaintenance of data quality and integrity.

DA3 These (DA2) communities must have a separate access control mechanism.DA4 These (DA2) communities must have a separate accountability mechanism.

2.4Information Classification Generic Rules All information within the CVGM Group must be classified in accordance with GroupInformation Security Classification Standard. Types of classification required:

Unrestricted : this data is freely available to anyone.

Restricted : this data is freely available to all employees, agents, and trading partnerswithin the CVGM Group or OU.

Confidential : this data is of such sensitivity that unwarranted access would damage theCVGM Group or OU. As such, access to it is restricted only to those who specificallyneed it.

Most Confidential : this data is of such sensitivity that unwarranted access wouldseverely damage the CVGM Group or OU. As such, access to it is highly restricted, tonamed individuals only , who have a need to know.

Full details of Information classification is given in the Group Information SecurityClassification Standard (ITCI 037).

To ensure that security controls reflect the classification of the information being accessedor generated, a data classification exercise must be conducted before or during the designphase in conjunction with the data owner . Use the Group Information ClassificationStandard (ITCI 037) as input to the process to determine the classification level of theinformation contained within the system.

Rule no. CriterionIC1 The Information being accessed must be classified by the data owner in

accordance with the Information Security Classification Standard

IC2 The Information being generated must be classified by the data owner inaccordance with the Information Security Classification Standard

IC3 For applications accessing or generating Most Confidential Information, a risk assessment is required to determine additional controls required.

2.5Identity Management Generic Rules As it is important to understand the nature of the data being accessed by an application, itis equally important to establish the identity of all of those using it, in accordance with theIdentity Management Standard. The following levels of assurance have been agreed as



10/31

Restricted

being appropriate for identity management across all Group businesses: The followingbroad 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 thatthere is some confidence in the asserted electronic identity. Suitable only fortransactions where an error in authentication of identity might lead to minor harm.

Level 2, Substantial Level Identity Assurance. Provides high confidence in theasserted electronic identity. Suitable for transactions where an error in authenticationof identity might cause significant harm.

Level 3, High Level Identity Assurance. Provides very high confidence in the assertedelectronic identity. Suitable for transactions where an error in authentication of

identity might result in considerable harm.

Further details of Identity Management are Given in Information Security IT for CVGMIdentity Management Standard; Report Number: ITCI 005.

When deploying an application, the first step is to establish a full list of all communitiesthat require access to it; To ensure that security controls reflect the assurance associatedwith the community or communities using it, a risk analysis must be conducted before orduring the design phase.

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 outlinedabove. This is discussed fully in ITCI023 Application Security Generic Specification.

Rule no.

Criterion

IM1 All members of all communities requiring access to the application must beidentified.

IM2 For known communities, an identification process must be provided in accordance

with the Identity Management Standard. If an Identity Management System isbeing used, this can be assumed.

Existing web applications must provide assurance levels indicated by the GroupInformation Security Classification Standard (ITCI 037).

IM3 For known communities, an authentication mechanism must be provided inaccordance with the Identity Management Standard. If an Identity ManagementSystem is being used, this can be assumed.

Existing applications must provide assurance levels indicated by the GroupInformation Security Classification Standard (ITCI 037).



11/31

Restricted

Rule no.

Criterion

GI approved smartcards provide sufficient assurance levels to access Restrictedinformation as also does connectivity via a baseline conformant server. When

either is used in conjunction with Strong passwords assurance is sufficient toaccess Confidential Information.

IM4 An audit process must be provided in accordance with IT4S Infrastructure SecurityEvent Management Standard (ITCI 055). If an Identity Management System isbeing used, this can be assumed.

IM5 If not all members of all communities can be identified, the risks must beacceptable to the system and data owners.

IM6 Authentication information shall be encrypted to prevent sniffing or replay attacks.This requirement is optional for Internal web applications using Restricted or

Unrestricted data. IM7 For new Intranet web applications hosted on Windows platforms, GI

authentication shall be used for both CVGM and non-CVGM (using externalaccounts) users, unless overriding technical or business considerations exist.

2.6Authorisation Generic Rules It is the responsibility of those deploying the application to ensure that the application, orthe operating system or Data Base Management System on its behalf, provides a

mechanism to permit (or authorise) access to data.

To achieve appropriate levels of accountability: Access rights to the application must be authorised by the data owner. This

includes the use of roles for data access.

All users must have unique identifiers unless there is formal approval for afunctional account. Functional accounts must comply with the Identity ManagementStandard (ITCI 005).

It is the responsibility of each user to ensure the security of their id. Passwordsshould never be shared or divulged.

If inter-platform access is required, for example, where an application accesses adatabase, the requesting platform should have a unique identifier. Where user id andpassword are deployed, a user id must be deployed and maintained for its sole use. In thiscase, it is the responsibility of those maintaining data integrity (on behalf of the dataowner), for example a Database Administrator, to ensure that the identifier, and anyassociated password or PIN, conforms to password policies.

It is the responsibility of those developing an application, on behalf of the dataowner, to ensure a process is in place to issue, manage, and revoke access rights inaccordance with the life-cycle of an end user or platform. Please refer to theIdentity Management Standard (ITCI 005) for further guidance.



12/31

Restricted

Revocation or, as a minimum suspension, of users or platforms should applyimmediately when they no longer have a need for data access. It is recommended,for data classed as restricted or higher, that periodic revocation (or accountsuspension) is provided; clearly, re-activation of access rights should not beonerous for valid users.

To ensure that the authorisation mechanism itself remains secure:

Wherever possible, the authorisation mechanism will be separate from the mainapplication; 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, thenseparate identities must be issued to indicate this.

If passwords, PINs, or other means of personal identification are used they must beencrypted 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 thosehaving access to the function is Substantial or higher.

These rules should be implemented in conjunction with section 4.3 i.e. GI approvedsmartcards and connectivity via a baseline conformant server both provide sufficientassurance levels for user authentication. When used in conjunction with Strong passwordsassurance is sufficient to access Confidential Information.

2.7The use of Strong Passwords (ITCI 023 and SOX 11.11d)

IF passwords are being used, password security must be sufficiently robust to ensure thataccountability remains appropriate to the information classification :

For externally facing systems; when accessing information of Restricted of highersensitivity, the use of Strong passwords is mandated. For internally facing systems;accessing information of Confidential or Higher, requires the use of Strong Passwords.Whilst for internally facing systems the use and implementation of Strong passwords canbe achieved via education, this is not true for externally facing systems. The followingrules, therefore, are provided as guidance:

Passwords must be a minimum of eight characters(Note: minimum for Smartcard/PIN is four characters, although a strong PIN isalso advised by ELIS.)

Ensure that the number of log on attempts is restricted. The user accesspermissions must be locked when this number is exceeded (maximum 4).

User access rights must be revoked when the user no longer has a need.



13/31

Restricted

Password must be reset periodically (password aging); this should be a maximumof 35 days. (Note: PINs are not subject to the aging requirement.)

Do not allow repeat passwords within a reasonable period; 5 is suggested as aminimum. (Note: PINs are not subject to this requirement.)

Note that quality passwords or PINs are not enforced through technology, butclear advice is provided through the education modules of ELIS.

Where this is not possible due to restrictions in system functionality, these requirementsshould be issued as guidance to users and as many of the settings implemented as ispossible (similarly, other applications requirements, such as a list of impermissiblepasswords should be implemented where available).

Rule no. Criterion

AR1 Access rights must be agreed by the data owner.

AR2

Agreed access rights must cover all communities who require access. Note thatthose who require direct access to raw data, such as systems or dataadministrators, must have separate access controls as indicated by rule DA 3 andshould have additional, comprehensive controls.

AR3

Each user should have a unique identifier. Where user id and password aredeployed, a user id must be deployed for their personal and sole use, or, if afunctional account is issued, comply with the Identity Management Standard(ITCI 023 and SOX C11.11c).

AR4 Passwords and other identification mechanisms, such as PINs or tokens, shouldonly be known by or allocated to one user.

AR5

If an application or system requires access to another application, database, orsystem, the application requiring access must have its own unique id to provideaccountability. This id must conform to normal identity management rules asoutlined above in the supporting text.

AR6 An authorisation mechanism must be selected to manage access.

AR7 Wherever possible, the authorisation mechanism should not be part of theapplication. This is to aid introduction of Identity Management systems.

AR8

Access to the authorisation mechanism must be separate from access to the mainapplication. This is to ensure that segregation of duties are clearly distinguishedbetween those using the application and those managing access to it. Provisionof this segregation of duties is mandatory.

AR9Processes must be in place to ensure that issuance, management, and revocation(or as a minimum suspension) of access rights are provided in accordance withthe wishes of the data owner.

AR10 For information classified as Restricted or higher, adoption of periodic



14/31

Restricted

Rule no.

Criterion

revocation (account suspension) should be implemented, in accordance with thewishes of the data owner. When employed, a process must be developed for re-

activation.Revocation should take place when an account has not been used for areasonable period of time; e.g. two months.

Existing applications must comply with this IF Information is classified as eitherConfidential or Most Confidential OR they are externally facing.

AR11Personal authentication credentials, such as passwords, must be encrypted intransit and should be encrypted when stored.

AR12

The authorisation mechanism must restrict access after a number of failedattempts. Existing applications must comply with this IF Information isclassified as either Confidential or Most Confidential OR they are externallyfacing.

AR13

Adoption of Strong passwords is mandated for information classified asConfidential or Most Confidential. However, unless the application is externallyfacing, password management should be undertaken by education rather thanapplication enforcement.

2.8Accountability Generic Rules When access or changes to data have been made, it is the responsibility of thosedeveloping the application to ensure that the application, or the database management/filesystem on its behalf, provides accountability as per the following guidelines.

Normally this will be via audit logging of both application logon/logoff and specific dataaccess. The level of audit logging required will be dependent upon the classification of theinformation being accessed. As a guide, consider logging the following:

Logon/Of

f

Read/Vie

w

Insert Modify/

Update

Delete

Unrestricted X X X

Restricted X X X X

Confidential X X X X X

MostConfidential

X X X X X

The following data is normally kept:



15/31

Restricted

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 belogged rather than the role used for authorisation. However, the role can be used as longas 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 canbe used as the identity by applying a digital signature to the audit log. Further details of Encryption are given in Information Security IT for CVGM Encryption Standard; ReportNumber: ITCI 003.

Data logs must only be write/append to provide non-repudiation (i.e. the inability to deny)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 thewishes of the data owner, and reflect both the classification of data and the period forwhich they must be retained. For some highly sensitive systems, or where governancedictates so, some logs may require being retained off site; in this case, they must beprotected against unauthorised access and changes.

Additionally the following suggestions may also be of use:

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.

Ruleno. Criterion

Supporting material in

text?

Compliant (Y/N/S)

AC1If required by the data owner, then an accountability(logging) regime must be established in accordancewith Information Security Classification Standard.

Y

AC2If logging is required then a mechanism must beestablished to ensure that actions can be traced back to an individual.

Y

AC3 Logs must be secured from unauthorised changes. Y

AC4 Retained logs must be protected against over-

writing for a reasonable period (e.g. 3 months) as

Y



16/31

Restricted

Ruleno. Criterion

Supporting material in

text?

Compliant (Y/N/S)

agreed by the data owner.

AC5 Where offsite logs are required, they must be protected against unauthorised access and changes.Y

2.9Clients Generic Rules Validate ALL input

Make sure that there is an INPUT data validation process; data input should be consideredas 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.

The data to be checked includes: form fields, hidden form fields, GET querystrings, and Cookies. HTTP headers should not be trusted and should not be usedto make program logic decisions.

Make sure that user cannot bypass your controls changing/manipulating parameters, suchas the URL and so forth. Make sure that the server rather than the client checks theseparameters as the client check may be disabled in the browser.

In event of failure, do not leak information to the client and do not expose any data thatcan lead to information disclosure. This can lead to facilitating of further attacks.

Input validation is mandatory for new and/or externally facing applications. For existingapplications, implementing input validation is based upon risk assessment.

Use Secure Coding techniques.Server side applications can be written in many programming languages. If scripts are notprepared carefully, however, attackers can find and exercise flaws in the code to penetratea Web server. An attacker can find flaws through trial and error and does not necessarilyneed the source code for the script to uncover vulnerabilities. Therefore, applicationsshould be written with security in mind by using secure coding standards; there are severalversions available; normally associated with a particular language. Guidance onestablishing likely threats and developing countermeasures in presented in Appendix A;Threat Modelling.



17/31

Restricted

The Use of Cookies

A cookie is a small piece of information that may be written to a users hard drive when aWeb site is visited.

Note that on the Internet, individual users or companies may not allow cookies to beplaced on their client platform and thus the web site cannot rely on their deployment.

For this reason:

If possible, allow the system to work with or without cookies as they may beswitched off.

Use of cookies to gather information about an individual must be explained in thePrivacy Policy statement, and should be explained in the related user interaction.

Consider the following issues when using cookies:

Cookie Tampering: use cryptographic sealing if this is a concern. Cookie Confidentiality: use encryption if this is concern. The encryption could be of

the channel (SSL) for the entire session if for example the cookie contains a sessiontoken, and session hijacking is a concern. If the client system exposure is to bemitigated, the cookie itself can be encrypted to make it opaque.

Cookie Forging: use random numbers in a large data space (e.g., for session tokens) if this is a concern.

Cookie Authentication: use IP address, password controlled access, or signature basedmethods, if this is a concern.

OneCVGM.com has a comprehensive section on legal matters covering requirements forprivacy policies and specifically the use of cookies on Internet sites: http://sww-oneweb.CVGM.com/resource_centre/our_services/legal/legal.html . This is thedefinitive source for cookie-related policy information.

Active Content

Active content refers to interactive elements processed at the client (Web browser). If notimplemented correctly, active content can present a serious threat to the end user. For

example, active content can take actions without the express permission of the user.When considering the deployment of client side active content, carefully consider the risksto end users, as the use of active content often requires the user to reduce the securitysettings on their Web browser.

Varieties of active content technologies exist. Some of the more popular examplesinclude: ActiveX, Java, VBScript, and JavaScript.

When deploying client side code it is very important to let the end user know that it hascome from a valid source. For this reason, code deployed on Externally facing sitesshould:



18/31

Restricted

Be digitally signed as being legitimate. Code signing requires that the WebApplication has a Digital Certificate registered for code signing. This certificateneeds to be recognised by all browsers that will access the code; normally this isachieved by buying a certificate from a vendor who is recognised by the browser,such as Thawte or Verisign.

A weaker alternative (since it doesnt protect against malicious insiders) to codesigning is to make sure that all sessions are secured using SSL/TLS, as this willdetermine that the server is under CVGM Groups domain.

Rule no.

Criterion

CS1 All input from a client must be validated on the server . Ensure that a user cannotbypass your controls by changing or manipulating parameters.

For existing systems that are solely internally facing, then this is recommended bestpractice. All new and externally facing systems must comply with this control.

CS2 In event of failure, do not leak information to the client and do not expose any datathat can lead to information disclosure.

For existing systems that are solely internally facing, then this is recommended bestpractice. All new and externally facing systems must comply with this control.

Suggested practice: write failure details to disk on server, and pass only a handle tothat location to the client.

CS3 Back-end subsystems should not be compromised in any circumstance.CS4 All sensitive data in transit must be secured using encryption, such as the SSL/TLS

protocol, in conjunction with appropriate encryption certificates.

All new and externally facing applications must use SSL/TLS when the data isRestricted or Higher.

All internally facing systems must use SSL/TLS when the data is Confidential orHigher.

CS5 The use of Strong Passwords is:

Mandated for access to Restricted, Confidential, or Most Confidential informationby non-CVGM users. This control must be implemented by the application orsystem.

Mandated for new systems accessing Confidential, or Most Confidentialinformation internally. This control must be implemented by the application orsystem.

For existing systems that are solely internally facing, then this is recommended bestpractice. This control should be implemented through user education.

CS6 For all externally facing systems, if Active Content technologies are used, the

source of the code must be validated using code signing or via the use of a secured



19/31

Restricted

Rule no.

Criterion

session. The Code signing authority shall be held by the minimum number of authorized CVGM representatives to mitigate the risk of malicious payloads in

CVGM active content.This is not required for systems that are solely internally facing.

CS7 Unless there are overriding client infrastructure constraints, all new applicationsproviding active content shall be built with .NET or Java technologies.

2.10 Application Deployment Generic Rules Development

As development is increasing deployed to external agencies, particularly off shore, it isimportant to ensure that code which accesses sensitive information is trusted.Therefore, where application code accesses sensitive information, use separation of dutiesduring development - particularly if encryption is used. Ensure that only a limited numberof 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 be finalised as early as possible in the developmentprocess.

Segregation of Duties / Segregation of Environments

(SOX C11.11f)

The following scenarios are required to be used in order to guarantee segregation of dutiesand environments:

2 Staff SoD with 3 Environments SoE

Environment Staff

Development Development Team

Test Development TeamProduction Promote to Production Team

2 Staff SoD with 2 Environments SoE

Environment Staff

Development & Test Development Team

Production Promote to Production Team



20/31

Restricted

The Support Services Area, with the objective to evaluate if the effectiveness of thesegregation of duties for the environments is in accordance with this policy and securitybest practices, must assess the environments at least quarterly. After the assessment iscompleted a report with his findings and required chain of action is built to be used asbasis for required actions plans.

Testing

Formal testing of the system must be undertaken before handover to deployment.

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 bedetermined at the time of design when logical paths are being mapped.

All major non-legitimate routes are exercised to ensure that appropriate errorresponses are given.

Ensure that all input and output data streams are validated. Ensure that maliciouscode or data is rejected.

Ideally, development and testing should not be undertaken by the same group of people. Consider providing enhanced security though the segregation of duties.

If production data is used as part of the testing process, care should be taken to ensure thatappropriate security controls are applied to the information being used. 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 fordeploying 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 theenvironment in which it runs.

Web applications should be scanned periodically for vulnerabilities. An annual remotepenetration test is also strongly recommended.

Deployment

For bespoke applications: Ensure that all bespoke code undergoes independent code review by a Quality

Assurance Gatekeeper. The Gatekeepers role can ensure that secure codingstandards have been used and that code only undertakes the purpose for which ithas 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 codeaccessing 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.



21/31

Restricted

Change Management Council is in charge of approving the final acceptance beforea new application goes live as defined in the C11.2-Change Request Initiation andControl process.

During the deployment phase, both non-technical and physical security measures must befinalised:

Ensure that defences such as Firewalls, Intrusion Detectors, Virtual PrivateNetworks (VPNs) and analysis tools are both installed and working correctly.

Ensure that appropriate processes and procedures are in place and tested.

Ensure that communications networks are in place and provide appropriate levelsof confidentiality and integrity.

When the design phase risk assessment requires it, undertake a penetration test of the system.

Applications transferred into live running must be under full change controlprocesses administered by the Gatekeeper.

If the Application is web based, extra countermeasures may be required; these shall bedetermined through Business Risk Analysis in conjunction with the Web Systems GenericSpecification: ITCI 0027.

Ruleno. Criterion

AD1 The Group IT Architecture Lifecycle must be adopted to ensure that security is built in rather than added.

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

AD3 Separation of the following life-cycle environments is mandated: Test andProduction.

AD4 A stage gate process must be established between environments to ensure thatthe system may be progressed and regressed. A code management system must

be adopted to provide controlled change management.

AD5An Independent Quality Assurance Gatekeeper should oversee the stage gate

process (AD3).

AD6

All primary decisions regarding Information Security must be made during thedesign phase based upon the risks identified during risk assessment. Theobjective is to develop controls to mitigate risk to levels acceptable to thesystem and data owner(s). Formal acceptance of remaining risks must beundertaken by the system and data owner(s).

AD7 Testing regimes must be determined during the design phase.

AD8 For bespoke developments, where possible, secure coding standards should be



22/31


23/31

Restricted

2.11 Content and Data - Generic Rules Overview

Because of the public accessibility, content on publicly accessible Web servers isinherently more vulnerable than information that is inaccessible from the Internet. Thisgives two major choices:

1. The most obvious is not to place any sensitive information on a Web server.2. The second is to make sure that information placed upon the web site has adequate

security controls in place.

Classified Information

All data must be classified before any publication in accordance with the InformationClassification System, and appropriate controls and identity management processes mustbe implemented. This applies to both internal and external web sites.

The following publishing rules apply:

Unclassified information may be held on Intranet (Internal Access only), Extranet(Access via Trading Partners and Joint ventures), or Internet (External Access)web sites.

Restricted information may be held on Intranet, Extranet and Internet sites as longas appropriate accountability rules are in place.

Confidential information should only be held on Intranet and Intranet-equivalentExtranet sites (as long as appropriate accountability rules are in place).Confidential Information can be held on an Internet Site if a critical business needrequires this, but it must be secured using at-rest encryption.

Most Confidential information may be held on Intranet and Intranet-equivalentExtranet sites if a critical business need requires this, but it must be secured usingat-rest encryption. Most confidential information must NOT be held on an Internetsite.

Web Content

Web Content refers to the (static) data that is presented to the end user to provide thecontext in which specific (dynamic) data appears; for example, web pages, web frames,text and images, which form the user interfaces presentation style. Some dynamic scriptsand applications may also be treated as content, but in this context they must benonvolatile.

Web Content access control can be separated into two main areas:

Providing basic security controls to prohibit access from the web application tocontent.



24/31

Restricted

Providing authorised access to permit content to be added or changed.

Providing Basic Content Security

For all new and Externally facing systems, the following basic Security Controls must beput in place to make sure that content cannot be directly accessed from a web server:

Install or enable only necessary services.

Install Web content on a dedicated hard drive or logical partition. Limit uploads to directories that are not accessible by the Web server. Define a single directory for all external scripts or programs executed as part of

Web content. Disable the use of hard or symbolic links. Define a complete Web content access matrix that identifies which folders and

files within the Web server document directory are restricted (to web users) andwhich are accessible

Disable directory listings. Use user authentication, digital signatures, and other cryptographic mechanisms as

appropriate. Consider segregation of data using tier separation (see Network and

Communications).

Providing authorised access to ContentAccess to content in order to change it must be via an Authorisation Component.Authorisation is the process of mapping identity against a series of access rights, whichwill be granted by the content owner.

Authorisation includes the following access rights: Read/View. The ability to read data or subsets of data. For content access, this is

generally associated with proof reading. Insert. The ability to either add or append data. Update. The ability to amend data. Delete. The ability to remove data

In order to ensure effective Content Security, separation of duties needs to apply:

An electronic identity will be required for access to the content; this must conformto the Identity Management Generic Rules set out above in IM1 through IM3.

Authorisation to access content will be given by the content owner, who will agreeto the access rights. Access rights may be granted by role.

Access Control management, including management of approved roles, will beundertaken by the system or data owner, or an agent acting on their behalf. The



25/31

Restricted

authorisation component and access to it will be logically separate from the systemor application itself.

When appropriate authorisation has been granted, it is the responsibility of the webapplication or web publishing system to make sure that appropriate audit logs are kept of

specific content access in accordance with the Event Management Standard (ITCI 055).When data is published; i.e. moved from a secured area to a public facing area, the identityof the content author must be retained in a log to provide accountability for all publicfacing information.

Consider the use of digital signing for this purpose; more sophisticated publishing toolswill only deliver signed content. This may, however, increase both costs and degradeperformance. The option of signing content should be determined by risk analysis.

Content Presentation

All content, for both internal and external sites, must:

Comply with CVGM branding Policies. Comply with Business Communication Principles. Comply with the SITI Policy for Privacy and Data Protection and associated

management guidelines (Personal Data Management) Comply with CVGM site look and feel. Comply with Domain naming Policy (GI standard, consistent approach used

for WWW by CVGM Group). Individuals OUs must register any CVGM site. Have Terms & Conditions and Private Policy available on its first page.

Give the user enough information so he/she can decide to follow a web link or not. The Web links must follow the same CVGM Guidelines with regard tocontent and web security. Have a named owner.

Access Types

Unlike most systems, a web application must be able to differentiate between anonymoususe, limited assurance, and those with higher privileges. Three types of access have beenidentified:

Anonymous; unknown user without credentials. Non Assured; where the user may have either self registered or been registered

through an agent outside CVGMs domain. User/id and password supplied ascredentials.

Known; where the user has been identified and authenticated in accordance withthe Identity Management Generic Rules set out above in IM1 through IM3.

It is recommended anonymous users are restricted to:

Unrestricted information only. For internal systems, this may be extended toRestricted information.

Read/View of Information.



26/31

Restricted

Insertion of information, with strong input validation processes.It is recommended non-assured users are restricted to:

Unrestricted information only. For internal systems, this may be extended toRestricted information.

Read/View of Information. Insertion of information, with strong input validation processes. The ability to change data that either relates to their personal needs (personal

information, presentational interface changes (the use of cookies, graphics etc).Data changes must not affect other users of the system. All input must bevalidated.

Access Controls

For users with a higher level of assurance, to ensure that appropriate security controlsreflect the relationship between their identity and data sensitivity, a risk analysis should beconducted before or during the Web application design phase.

As for content, user access to data must be via an Authorisation Component. The accessrights to a data entry, or series of data entries, are granted by the data owner to either anindividual or role dependent upon both the:

Degree of assurance provided by the identity (Identity Management Assurance). Degree of sensitivity of the data (Information Classification).

Again, separation of duties needs to apply:

The electronic identity must conform to the Identity Management Generic Rules

set out above in IM1 through IM3. Authorisation to access data must be given by the data owner. Access rights may

be granted by role. Access Control management, including management of approved roles, must be

provided by the system or data owner. The authorisation component and access toit must be logically separate from the system. This can be accomplished by the useof the capabilities of DBMS, Operating System, or special security managementapplications.

Access controls must conform to the rules set out Application GenericSpecification (ICI 023).

When appropriate authorisation has been granted, it is the responsibility of the web systemowner to ensure that appropriate audit logs are kept of specific data access in accordancewith the Event Management Standard (ITCI 055).

Storage Controls

Data must be secured in accordance with its value as determined by the InformationClassification Standard: ITCI 037.

For publicly available (unclassified) information, the controls outlined with regardto securing the operating system and application will suffice.



27/31

Restricted

For information of a restricted nature, however, segregation of the database shouldbe adopted. This can be achieved using firewalls, switches, or VLANs as indictedby the section on Network and Communications.

For Confidential information, the inherent vulnerability of a web application

should be addressed. Encryption of stored data is strongly recommended for thispurpose on internal systems and must be used on externally facing systems.

Most Confidential information should not normally be stored on a web site, andnever on an externally facing web site.

If data encryption is used, unless a full PKI system is available for all users, encryptionmust be undertaken by the web application in conjunction with the base software toprovide segregation of responsibilities. Clearly, the keys must be highly secured for thispurpose.Options for encryption include but are not limited to:

Database based encryption at field or table level Operating System based encryption, e.g., Encrypting File System, Windows DPAPI For the highest security level, Hardware Security Module or a similar hardware deviceFurther details of Encryption are presented in Information Security IT for CVGMEncryption Standard; ITCI 003.

Auditing and Logging

Within a Web environment, logging applies to all components and not just the database;this includes the network where Intrusion Detection Logs are an intrinsic part of overallsecurity. There are several techniques available and these must be chosen at the designstage to make sure that overall security is maintained. Similarly, the responsibility for loganalysis, along with access rights should be made at this time, before systemimplementation.

All data logs must be write/append only to provide accountability or non-repudiation. Thefollowing data is normally kept:

Identity of the item updated. Type of Update: Insert/Update/Delete. For systems that are more sensitive

Read/View may also be logged. Date/Time. Identity of the user.

The following tips may be of use: Log key events across web application tiers (failed logins, data

modification/retrieval, network access, etc) Synchronise all Web system clocks including: Firewall, Web, Application,

Database server and other network hardware

Agree retention time for each Log file.



28/31

Restricted

Secure and backup log files. Send detailed error messages to the error log. Do not log passwords or any other sensitive data.

Data Transmission Controls

Data must be secured in accordance with:Its value as determined by the Information Classification Standard: ITCI 037The data transmission rules set out in the Data Management Generic Specification (ITCI024).

Unclassified information may be freely transmitted Restricted information may be freely transmitted over trusted networks such as the

Group Open Network but must be protected in transit across untrusted networks;

e.g. the Internet itself. Encryption is mandated for this purpose. Confidential information must be encrypted for transmission across all networks. Most Confidential information must not be held on or transferred to/from an

Internet web site.

Further details of Encryption are presented in Information Security IT for CVGMEncryption Standard; ITCI 003.

Personal DataIt is imperative that systems holding personal information need to be designed andmanaged securely to meet the requirements of Data Privacy Legislation. Normally,personal information should be classed as Confidential.

Individuals have a right to view and correct personal information held by all parts of theCVGM Group of Companies. To comply with most existing and emerging privacy laws,web systems should comply with the following guidelines:

Do not hold personal information unless it is necessary. Allow individuals to view all data relating to them. This applies equally to

employees, agents, and the public. Where individuals have personally supplied information (for example, address,

phone number etc) allow them to change this directly. Where CVGM Group has supplied the information (for example salary,

outstanding payments, etc) ensure there is a mechanism to have the informationchanged if an individual believes it is inaccurate.

All personal data must be held and transmitted securely. In case of failure, do not expose clients/individuals information that could lead to

information disclosure.Additional advice and guidance is available in the SITI Policy for Privacy and Data

Protection and associated management guidelines.



29/31

Restricted

Common Threats

Buffer Overflow : This can result in a DoS attack, or running of attackers choice of codeon the server. To mitigate this:

Use managed code (.NET or Java) for the web application as much as possible. Performs data type and bounds checking at every opportunity starting from user input

processing.

SQL Injection : These attacks result from malicious input from the user conjoined with theSQL query constructed by the web application or back end. To mitigate this risk:

Always use of parameterized queries or stored procedures. Do not build SQL by string concatenation. Scrub the user input of all unexpected characters, e.g., quote

Canonicalization : This attack takes advantage of the fact that a given resource hasmultiple valid syntactical representations. To mitigate this:

Do not accept file, path, or URL inputs from the user. If you must accept such input, do not make logic decisions based on its content. If you must make such decisions, use a proven canonicalization module to transform

the input into a canonical form prior to using it in a decision.

Cross-Site Scripting : This attack allows a web application to be used as a vehicle to run ascript on the client (via user clicking on a malformed link to your site), generally to stealcookies or other user input for malicious reuse. To mitigate this:

Always validate all GET/POST input, e.g., by using regular expressions. All HTML output that may contain user data should be escaped (e.g., via

HTMLEncode) to render any embedded script code inactive.

Rule no. Criterion

DS1 All content must have a defined owner, and the data/content owner mustauthorise access to the data or content.

DS2 Information and the data that underpins it must be classified in accordance withthe Information Classification Standard (ITCI 0037) as part of risk assessment.

DS3 Access criteria must be defined during the risk analysis for all communities thatrequire access to the web application, Specifically, unknown and non-assuredaccess should be identified.

DS4 All content must have ACLs set at the least privilege required for the application



30/31

Restricted

Rule no.

Criterion

to function correctly.

DS5 Data Classification profiles derived during the risk assessment (DS2 and DS3)must be identified and documented.

DS6 For web based applications anonymous read access is permitted to:

Unrestricted information on any system.

Restricted information on systems that are solely internally facing.

All known users must have a unique identifier in accordance with the rules setout in the Generic Application Specification (ITCI 023)

DS7 Authorisation mechanisms must be selected to manage access to both contentand data. The authorisation mechanism must restrict access after a number of failed attempts. This requirement is optional on the Internally facing systemsholding data classified as Unrestricted or Restricted.

DS8 Access to each mechanism must be separate from access to the main application.i.e. segregation of duties must be provided between application access andaccess management.

DS9 When storing sensitive data, encryption must be used: For externally facing systems Confidential or higher. For internally Facing systems Most Confidential.

DS10 If Encryption is used, keys (or a component of the keys, in case of multi-component keys) must be segregated from the encrypted data.

DS11 If an untrusted network is being used both confidentiality and integrity must beprovided, for all information other than Unrestricted, through the use of encryption.VPN, SSL and application level encryption all provide effective encryption.

DS12 Most Confidential Information must not be transmitted over an untrustednetwork.

DS13 If sending Confidential or Most Confidential Information over the Open GroupNetwork, confidentiality must be provided using encryption via SSL/TLS.

DS14 All data must conform to Security requirements set out in Regional and NationalLegislation.

DS15 All personal data must conform to the SITI Policy for Privacy and DataProtection to establish appropriate data security controls to comply with dataprivacy legislation.

DS16 The web application should run at the least privilege required to perform itsfunction. An Internet web application must not run with an Administratorprivilege.



31/31

Restricted

2.12 Non-ERP Specific Standards Internet Visual Identity Standards - http://sww-soplalivelink.CVGM.com/livelink.exe?func=ll&objId=2523361&objAction=browse&sort=name

Microsoft .NET framework - http://www.microsoft.com/net/basics/framework.asp /

http://msdn.microsoft.com/netframework/programming/ / http://www.microsoft.com/net/ technical/
http://sww-soplalivelink.shell.com/livelink.exe?%20func=ll&objId=2523624&objAction=Open%20http://sww-soplalivelink.shell.com/livelink.exe?%20func=ll&objId=2523624&objAction=Open%20http://msdn.microsoft.com/netframework/programming/http://www.microsoft.com/net/%20technical/http://www.microsoft.com/net/%20technical/http://sww-soplalivelink.shell.com/livelink.exe?%20func=ll&objId=2523624&objAction=Open%20http://sww-soplalivelink.shell.com/livelink.exe?%20func=ll&objId=2523624&objAction=Open%20http://msdn.microsoft.com/netframework/programming/http://www.microsoft.com/net/%20technical/http://www.microsoft.com/net/%20technical/

política faculdade

Documents