CF13.2.1
Critical spreadsheets should be supported by documented standards / procedures, which cover: a) training of individuals that use spreadsheets
b) validation of information input into spreadsheets
c) protection of spreadsheets and the information they contain.
SPECIALISED
Critical spreadsheets are often developed using spreadsheet programs (eg Microsoft Excel, OpenOffi ce Calc or IBM Lotus 1-2-3). Often, macros (which are small, user defi ned, routines or pieces of code) are developed within the spreadsheet to automate functions like routine tasks, importing data, performing calculations and creating new menus and shortcuts.
CF13.2.2
Individuals that use and develop critical spreadsheets should be trained in how to: a) use them effectively
b) protect the information they store and process
c) develop security-related functionality (eg when writing macros, conducting error checking and performing calculations in cells).
CF13.2.3
Information input into critical spreadsheets should be subject to integrity checks using validation routines, which: a) require particular spreadsheet cells to contain a non-null value (ie the cell contains a value of some type, and
is not empty)
b) restrict the type of information entered (eg requiring entered information to be in the format of date, currency, number or text)
c) use range checks to ensure information entered into the spreadsheet is within a predefi ned range (eg checking that a number that should be positive, is not negative)
d) generate hash totals, to allow the integrity of information to be checked at various stages of being processed e) perform consistency checks (eg on a formula that is repeated throughout a spreadsheet).
CF13.2.4
The risk of inaccurate entry of information should be reduced by the use of:
a) default values (eg pre-agreed values that will automatically be entered when a new record is added)
b) drop-down lists consisting of predefi ned values (eg to help users of spreadsheets select the correct information) c) error messages (eg error codes and descriptive text provided to inform users when a mistake may have
occurred)
CONTROL FRAMEWORK
www.securityforum.org
CF
SPECIALISED
Copyright © 2011 Information Security Forum • 2011 Standard of Good Practice CF13.2
CF13.2 Protection of Spreadsheets
(continued)CF13.2.5
Critical spreadsheets should be protected by:
a) storing them on a central server (eg to reduce the risk of accidental and deliberate modifi cation, and to help ensure spreadsheets are backed up centrally)
b) limiting access to authorised individuals (eg by using password protection and creating access control lists that limit access to spreadsheets or folders that contain spreadsheets)
c) assigning privileges to restrict the functions authorised individuals can perform in spreadsheets (eg by defi ning different passwords for separate functions, such as opening, reading and modifying spreadsheets)
d) using only approved versions of spreadsheets (eg using the current spreadsheet version, or an approved spreadsheet program such as Microsoft Excel, OpenOffi ce Calc or IBM Lotus 1-2-3).
CF13.2.6
The integrity of information contained in spreadsheets should be assured by: a) using separate areas for calculation cells and data entry cells
b) restricting access to calculation areas (eg by using passwords)
c) conducting reconciliations of information entered into the spreadsheet (eg by manually checking against source information or physical records, or by implementing an automated process that checks information as it is downloaded or transferred from another application)
d) restricting access to, or removing standard menus (eg by hiding the standard menus or replacing standard menus with a customised menu to prevent access to developer functions)
e) restricting changes to coding routines that are used to produce additional functionality developed in the spreadsheet (eg writing macros, conducting error checking or performing calculations in cells).
Related areas / topics
CF4 Business Applications
ISF resources
Protecting Information in the End User Environment
CONTROL FRAMEWORK
www.securityforum.org
CF
CF13.3 2011 Standard of Good Practice • Copyright © 2011 Information Security Forum
CF13.3 Protection of Databases
Principle
Critical desktop applications created using database programs should be protected by validatinginput, implementing access control, and restricting access to powerful functionality.
Objective
To assure the accuracy of information processed by critical databases, and protect that informationfrom disclosure to unauthorised individuals.
CF13.3.1
Critical databases should be supported by documented standards / procedures, which cover: a) training of individuals that use databases
b) validation of information input into databases
c) protection of databases and the information they contain.
SPECIALISED
Critical databases are often developed using commercial-off-the-shelf (COTS) database programs (eg Microsoft Access, OpenOffi ce Base or IBM Lotus Approach).
CF13.3.2
Individuals that use and develop critical databases should be trained in how to: a) use them effectively
b) protect the information they store and process c) develop required functionality securely.
CF13.3.3
Information input into critical databases should be subject to integrity checks using validation routines, which: a) require particular database fi elds to contain a non-null value (ie the fi eld contains a value of some type, and
is not empty)
b) restrict the type of information entered (eg requiring entered information to be in the format of date, currency, number or text)
c) use range checks to ensure information entered into the database is within a predefi ned range (eg checking that a number that should be positive, is not negative)
d) generate hash totals, to allow the integrity of information to be checked at various stages of being processed e) perform consistency checks (eg on a calculation that is repeated throughout a database).
CF13.3.4
The risk of inaccurate entry of information should be reduced by the use of:
a) default values (eg pre-agreed values that will automatically be entered when a new record is added) b) drop-down lists consisting of predefi ned values (eg to help users of databases select the correct information) c) error messages (eg error codes and descriptive text provided to inform users when a mistake may have
occurred).
CF13.3.5
The integrity of information in the database should be protected by employing data concurrency methods, to ensure that information is not corrupted when modifi ed by more than one user.
CONTROL FRAMEWORK
www.securityforum.org
CF
SPECIALISED
Copyright © 2011 Information Security Forum • 2011 Standard of Good Practice CF13.3
CF13.3 Protection of Databases
(continued)CF13.3.6
Critical databases should be protected by:
a) storing them on a central server (eg to reduce the risk of accidental and deliberate modifi cation, and to help ensure databases are backed up centrally)
b) limiting access to authorised individuals (eg using password protection and creating access control lists to limit access to databases or folders that contain databases)
c) assigning privileges to restrict the functions authorised individuals can perform in databases (eg defi ning user profi les and user privileges for individuals that need to open, read and modify the contents of databases) d) using only approved versions of databases (eg using the current database version, or an approved database
program, such as Microsoft Access, OpenOffi ce Base or IBM Lotus Approach) e) using passwords to limit access to critical databases.
CF13.3.7
The design of databases (including script code, triggers and schema) should be protected by: a) compiling databases (eg to create a run-time executable)
b) using a separate password to access the design.
CF13.3.8
Access to database functionality should be restricted by using password protection to prevent unauthorised creation of declarations, statements, and procedures that perform operations or calculate values within a database.
CF13.3.9
Information contained in databases should be protected by restricting access to, or removing standard menus (eg by hiding the standard menus or replacing standard menus with a customised menu to prevent access to developer functions).
Related areas / topics
CF4 Business Applications
ISF resources
Protecting Information in the End User Environment
CONTROL FRAMEWORK
www.securityforum.org
CF
CF13.4 2011 Standard of Good Practice • Copyright © 2011 Information Security Forum