P. 1
Jpdf0906 Online Application

Jpdf0906 Online Application

|Views: 0|Likes:
Published by jbascribd

More info:

Published by: jbascribd on Jan 25, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

01/29/2013

pdf

text

original

Journal Online

Application Security Controls: An Audit Perspective
Alagammai Adaikkappan, cisA, cisM, is the principal (technology audit) at the National Australia Bank, Melbourne, Australia. In her role, she is involved in IT audits, IT risk reviews and security audits. Her experience in this field spans more than 10 years. She specialises in IT risk management, security management and IT governance. In her current role, she specialises in information technology audits in corporate and institutional banking. Her other areas of expertise include data management, BCP/DR, application development and project management. Adaikkappan can be reached at alaguadai@gmail.com

The assurance objective of performing an application security audit is to ensure that application security controls are operating effectively to protect the confidentiality, integrity and availability of information. Application security is concerned with maintaining confidentiality, integrity and availability of information at the application layer. Of the key application controls that are reviewed as part of any application audit, application security is utmost important. This also translates as ‘restricted access’ in financial audit assertions. The risk associated with a compromise of application security can lead to security-related frauds that may give rise to financial and reputation losses. This article adopts a layered approach to auditing application security. Excluded from the scope of this article is security over databases, operating systems, middleware and network layers. The article provides general guidelines to auditing application security, and some of the key controls that need to be tested to obtain a high level of assurance. Prerequisites for Auditing APPlicAtion security It is of paramount importance for an auditor to obtain a clear understanding of the underlying business process for which the application has been designed. It is also important to understand the different sources of data input to and output from the application. Interfaces to and from the applications should be understood to identify data flows. Most applications are accessed through individual user IDs and passwords to the application. However, other forms of login, such as single sign-on mechanisms, have become increasingly popular, given the magnitude of applications used in a corporate environment. The design of the application for user provisioning should be understood upfront. Some applications are designed with an application security module, which is used for user

provisioning within the application. On the other extreme, in some applications, user accounts need to be hard-coded into the application logic. The controls that operate in these two environments could be significantly different due to the difference in the way they are provisioned. The various roles, descriptions, user profiles and user groups that can be created within an application should be obtained. This includes system administration accounts, security administration accounts, privileged accounts and service accounts. Organisationwide policy for obtaining user access and supporting standards and procedures needs to be reviewed upfront. This is required in order to understand the level of guidance available and to gauge the extent to which the information security policies and standards are embedded in the application layer. Having obtained a thorough understanding of the systems, policies, processes and procedures around application security, the auditor can then step through the various control points in an application security audit as detailed here. APPlicAtion security lAyers A layered approach is used for analysing application security (figure 1). In information security terms, this is a typical defense-in-depth approach. The application security profile can be classified into three layers: 1. Operational layer—This is the core of application security and is generally controlled through the security module of the application. 2. Tactical layer—This is the next management layer above the operational layer. This includes supporting functions such as security administration, IT risk management and patch management. 3. Strategic layer—This layer includes the overall information security governance, security awareness, supporting information security policies and standards, and the overarching IT risk management framework.
ISACA JOURNAL VOLUME 6, 2009

1

User profiles are generally created upfront. password non-repetition and automated lockout after three to five attempts should be set as a minimum. security measures such as secure connection. the auditor should consider if the principle of least privilege was applied while granting access. Service accounts may or may not be interactive. When appropriateness of user access is tested as part of the audit. offsite locations. Privileged and service accounts are sometimes treated as mystery accounts. Accounts that have elevated access rights (including system administration) are referred to as privileged accounts. encryption and monitoring of remote login activity should be considered for auditing. accounts manager). It is often noted that such accounts tend to remain in the applications for an extended period of time. 2009 . rm at andion Se Sta cuit nda y P rds olici Se es cur and ity A dm Ma in nag ist em ratio ent n Tactical Layer Info User Accounts Operational Layer Segregation of Duties Password Controls it ud g . Remote logins should be strictly controlled.figure 1—Application security layered Approach Strategic Layer Fr IT am R ew isk or Ma ka n nd age IT Gu me Ri sk ide nt Ma lin na es ge m en t Access Rights an application security perspective. password minimum length. A user profile is a skeleton of user access rights that represents a particular role (e. there is an inherent risk that new user accounts may inherit excessive access rights that may not be appropriate for their role. including login from mobile devices (wireless). test or other generic accounts should be reviewed.g. An auditor should also review the authorisation records for granting privileged user rights. Use of guest. Auditors should also check for duplicate/multiple accounts belonging to the same/shared users. home and other remote mechanisms. Regular monitoring of the use of these accounts serves as an adequate control from Se cu rit yA wa 2 ISACA JOURNAL VOLUME 6. especially for critical applications that transmit payments or sensitive information. Some off-the-shelf applications may not have strong password controls. An auditor should always ensure the use of unique user IDs that can be traced back to individuals. Service accounts are generally used for interfaces. auditors need to look for compensating controls in the form of layered security (via network login. An auditor should test the controls that monitor the usage of these privileged accounts. Password controls over privileged accounts and service accounts should be reviewed to ensure compliance with the organisationwide security policy. vendor accounts and third-party accounts should be reviewed. A in ce ity tor an ur oni c rn Se d M ve ing e n Go rt fac a ity o er ing ur ep Int ogg ec nd R S L on s a ati ric rm Met o Inf h atc n P nt tio me ca e pli nag Ap Ma ren es s Operational Layer The operational layer includes: • User accounts and access rights—Creating unique user accounts and providing them access rights appropriate to their roles and responsibilities is a well-regarded best practice in application security. password strength (mix of alphanumeric characters). User accounts are then created by copying the existing profiles in the application. In general. Where existing user profiles are copied to new users for granting access. Regular management review of user access appropriateness and user access authorisation records to user accesses is the key control to be tested under this domain. Encryption of passwords is another key control. Likewise. batches or other maintenance type activities. Various login mechanisms. Application password controls need to be strengthened to prevent hacking of user accounts. then application login) or other mechanisms where application passwords are well protected. In these instances. users and applications should be uniquely identifiable.. even if they are rarely or never used. In all instances. password age. should be analysed from a control standpoint. In essence. • Password controls—Organisationwide security policy generally dictates password controls applicable to the different layers of technology.

etc. this is considered to violate the SoD principles. users have access to a number of applications that may be appropriate to their role.1 In an application security review. Timeliness of this activity is important to ensure that users ISACA JOURNAL VOLUME 6.. All formal approvals need to be stored in a centralised repository for future reviews and reference. This is typical in small organisations with limited staff numbers. For example. a user may have purchase order access rights in the the enterprise resource planning (ERP) system and payment approval rights in a payment application. smaller technology shops cannot afford to have a separate security administration function. Societe Generale incident in January 2007). etc. This is an explicit violation of SoD principles. A3. A holistic approach needs to be adopted while performing this testing. A1. a clear understanding of this concept is important. For example. the access rights within user profile A1 for application A are indicated as A1. application design may not cater to separate functions for administering the system and security. the security administration function is often combined with application support function/business function. In addition. a user may have payment and authorisation user profiles allocated within the same application. 2009 3 . authorisation and submit user access rights. compensating controls.3. Understanding these access rights available to each user profile is important to ensure that those rights do not violate segregation of duties principles. – Segregation of duties between security administration and other functions—In large/mature organisations. Again. thereby explicitly violating SoD principles. an auditor needs to have a very good understanding of the organisationwide applications being used and the nature of user profiles in those applications (represented as applications A. To perform this testing. auditors may choose to perform SoD testing at various levels. A2. In those instances.g. – Segregation of duties within user profiles/accounts— Some applications are designed in a way to allow for more than one user account for the same user to reflect the multitude of roles performed by the user. The user profiles are depicted as A1. in the figure. Tactical Layer The operational layer includes: • Security administration—Timeliness of user provisioning activities such as creating/deleting and changing of user accounts is important in this fast-moving world. For example. If the profile also includes accounting entry input access rights. User access change requests need to be performed immediately after an employee is transferred to other divisions within the same organisation. B and C in figure 2). An auditor should ensure that user accounts are created only after formal approval from the employee’s manager. However. should be reviewed for adequacy and effectiveness. Figure 2 depicts the various levels of segregation of duties testing to be performed. if any. testing of access rights over these multiple user accounts within an application should be performed to ensure that there is no violation of SoD principles between such allocations of user profiles to the same user. Quite often in poorly designed applications. the importance of this control has heightened. In figure 2. This violates SoD principles. – Segregation of duties across multiple applications—In large organisations. Segregation of duties is defined as: A basic internal control that prevents or detects errors and irregularities by assigning to separate individuals responsibility for initiating and recording transactions and custody of assets to separate individuals. SoD needs to be tested at the following levels to provide a high level of assurance: – Segregation of duties in the user access rights—The user profile within the application provides various access rights associated with the user profile. Depending on the level of assurance required. Therefore. auditors tend to find a lack of synchronisation between access rights and associated user profiles. a centralised/decentralised security administration function is in place to perform user provisioning.• Segregation of duties (SoD)—With recent occurrences of security-related frauds around the world (e. to ensure that access rights of the user in those applications do not violate SoD principles.1. A1. Before an auditor ventures into testing of this control.. an account manager user profile can have review.2.

1 Access Rights A3.2 Access Rights B3.3 Access Rights A2.1 Access Rights B4. Application patching needs to be performed regularly. etc.3 Access Rights B4.3 Access Rights C4. as this could potentially lead to violations of SoD principles.1 Access Rights A1.3 Access Rights C1.3 Access Rights B1.3 Access Rights A4. 2009 – Conducting a regular security awareness programme on application users – Enabling application users to perform a self-assessment/ complete compliance checklist questionnaire to gauge the users’ understanding about application security – Reviewing application patches before deployment and regularly monitoring critical application logs – Monitoring peripheral security in terms of updating antivirus software.2 Access Rights C2.2 Access Rights C3. Application C User Profile C1 User Profile C2 User Profile C3 User Profile C4 Security Admin.2 Access Rights C1. do not inherit their previous access rights for an extended period of time.1 Access Rights C5. It is a . especially when disgruntled employees leave the organisation.3 Application A Application B User Profile B1 User Profile B2 User Profile B3 User Profile B4 Security Admin.3 Access Rights C5.1 Access Rights C1. System Admin.1 Access Rights A4. if they are moving roles that could potentially lead to such situations.3 Access Rights B3.figure 2—segregation of duties controls testing Applications User Profiles Within Applications User Profile A1 User Profile A2 User Profile A3 User Profile A4 Security Admin.1 Access Rights B3.2 Access Rights A2. revoking access rights at other layers in a timely manner is also important to ensure protection from unauthorised logins. Deleting of user access needs to be timely. An auditor should understand the risk associated with each application. • Application patch management—Organisations tend to focus on patching at the database or operating-system level.2 Access Rights A4. While disabling access rights at the network is seen as a compensating control. The supporting security administration procedures and security configuration of the application need to be documented for application support and future reference.1 Access Rights B2.3 Access Rights C3.2 Access Rights C4. System Admin.3 Access Rights B2.2 Access Rights B1.1 Access Rights C4.2 Access Rights B2.2 Access Rights B4. • IT risk management—Some of the key functions performed by IT risk management in relation to application security are: – Assessing risk over key application controls 4 ISACA JOURNAL VOLUME 6. System Admin.1 Access Rights B1. Access Rights Associated With User Profiles (Granular Level) Access Rights A1.1 Access Rights C3.2 Access Rights A1.3 Access Rights C2.2 Access Rights C5. This may be obtained through review of the reports on periodic risk assessment on the application or self-assessment/compliance reports on the application.1 Access Rights A2.3 Access Rights A3.2 Access Rights A3.1 Access Rights C2.

Some of the key metrics that can be used for auditing application security are shown in figure 3. the application security principles described here should be applied at length in auditing application security at the service provider. Third-party Security Controls As the world rapidly drifts towards an outsourcing environment. ISACA JOURNAL VOLUME 6. The alignment of the service provider’s security policy and the organisation’s security policy needs to be reviewed to understand the degree of alignment and/or discrepancy. amber and red is done based on a predefined basis. These are often good indicators of the security health of an organisation. database and operating system layers. 2009 5 . integrity and availability of information based on business requirements and risk analysis. • Interface security—An auditor needs to understand that data flow to and from the application. The security policy should be supported by detailed standards and guidelines. User listing of the associated interfaces supporting the application needs to be reviewed to ensure no unauthorised access to interfaced data. they are seldom monitored. Application security metrics serve as useful key performance indicators (KPIs) to assess the maturity of the function.must to ensure that key applications are in ‘vendor support’ mode at all times. especially when unencrypted methods of transmission are used for data transmission. Strategic Layer An information security programme can be defined as: The overall combination of technical. Security of the interfaced data is also important. Patches can be analysed in consultation with IT risk and only those necessary for applications should be deployed. Therefore. Assurance is generally figure 3—Application security Metrics for the quarter ended 31 March 2009 december 2008 Application security Metrics Number of user accounts created without appropriate approvals Number of user access requests provisioned in excess of service level agreement time Number of user access revocation requests not processed within 24 hours Number of user access change requests not processed within 24 hours Number of security incident/breaches reported due to unauthorised access Percent of security incidents/breaches that remain unresolved Number of external/internal unauthorised attempts Actual 2 16 15 2 0 2 0 status Amber Green Green Amber Green Amber Green March 2009 Actual 0 12 12 0 0 5 2 status Green Green Green Green Green Amber Red Note: Hypothetical figures have been used for the purpose of this example.2 This includes clear allocation of roles and responsibilities. which can then drive the appropriate level of security at the application. It is often noted that while critical activities are logged. Likewise. Status categorisation into green. One of the key responsibilities of the IT risk management function is to promote ongoing security awareness to the organisation’s users. This renders the control futile. an auditor needs to understand the business-critical data pertaining to any application. • Audit logging and monitoring—Monitoring the audit logs of every single user and transaction becomes impractical in large organisations. if any. governance structure and management reporting. and management structures implemented to provide for the confidentiality. Audit logging may typically be performed at the application or database level. Security metrics are now becoming popular to gauge the performance of the security management function. as security patches will be released by the vendor only when the applications are supported. a comprehensive IT risk management framework including a security risk management framework is essential to support the overall information security programme of an organisation. operational and procedural measures. A comprehensive information security programme fully supported by top management and communicated well to the organisation is of paramount importance to succeed in information security.

70 Type 1 and Type 2 reports. An auditor needs to review the thirdparty report to identify and analyse the gaps between standard assurance processes and the third-party report.3 Identity management. surveillance and monitoring. stAndArds And guidAnce As identity thefts increase and information security becomes more difficult. 2009 . Likewise. including DS5.3 • ITAF™: A Professional Practices Framework for IT Assurance4 provides more guidance (including value drivers and risk drivers) on how to use CobiT to support the IT assurance/audit activities relevant to managing security. the risk of failure/weakness in the operating effectiveness of the key application security controls at the operational layer is described in figure 4 along with the risk associated with such failure. DS5. produced by the service provider’s auditors. risks AssociAted With fAilure/WeAk APPlicAtion security controls Based on the key controls described previously. there has been a growth in the number of standards. Some of the standards and guidance that are available on application security are: • Control objectives for application security are more specifically defined in CobiT® 4.obtained through Statement on Auditing Standards (SAS) No. the third-party report can also be used to gauge the service provider’s adherence to the security controls/ procedures prescribed by the organisation in accordance with the outsourcing contract.4 User account management and DS5.1.5 Security testing.5 which is as a valuable reference for auditing application security. An auditor may need to perform additional audit procedures to validate the gap analysis. figure 4—risk Associated With failure/ineffective operation of key Application security controls risk Associated With failure/ineffective operation inappropriate Access/ Violation of sod ineffective security Management Process key Application security controls Use of unique/individual user accounts Access rights granted according to ‘least privilege’ principle Strong password controls Segregation of duties principle followed during user provisioning Periodic management review of appropriateness of user access rights Periodic review of application users against authorisation records Security administration function independent of application support function Authorisation for grant of privileged and service (interactive) accounts Periodic monitoring over activities performed through privileged and service (interactive) accounts Regular monitoring of audit logs Timeliness of security administration function unauthorised Access u u u u u u u u u u u u u u u u u u u u u u u u u u u 6 ISACA JOURNAL VOLUME 6. guidelines and compliance requirements. Access Controls. • ISACA® has published IT Audit and Assurance Guideline G38.

org/itaf 5 ISACA.isaca. While technological developments occur endlessly.pcisecuritystandards. USA. 3 ISACA.org/glossary 2 Ibid.isaca. IT Audit and Assurance Guidelines.isaca. 2007.org 1 The ISACA Journal is published by ISACA. ITAF: A Professional Practices Framework for IT Assurance. volume.isaca. Access Controls.. www. For other copying. CobiT 4.isaca. Where necessary. the control objectives and principles behind auditing application security remains the same as described in the article. Send payment to the CCC stating the ISSN (1526-7407). ‘Develop and maintain secure systems and applications’ and Security Principle 8. to photocopy articles owned by ISACA. Copying for other than personal use or internal reference. 2009 7 . www. G38.• The Payment Card Industry (PCI) Data Security Standard (DSS)6 has prescribed two security compliance requirements that are specifically relevant to application security: Security Principle 6.org/cobit 4 ISACA. a voluntary organization serving IT governance professionals. Membership in the association. or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited. conclusion Information security is a journey. All the key controls identified need to be tested to provide the right level of assurance to the executive board and audit committees. © 2009 ISACA. They may differ from policies and official statements of ISACA and/or the IT Governance Institute® and their committees. or the editors of this Journal.50 per article plus 25¢ per page. www.org/standards 6 PCI Security Standards Council. reprint or republication. and first and last page number of each article. Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. Glossary. Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. 2008. www. for a flat fee of US $2. permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC). An auditor can contribute to the success of this journey by adopting a proactive approach to analysing and auditing information security.org ISACA JOURNAL VOLUME 6. permission must be obtained in writing from the association. and from opinions endorsed by authors’ employers. ISACA Journal does not attest to the originality of authors’ content. Salem. All rights reserved. ‘Assign a unique ID to each person with computer access’. date.1. endnotes ISACA. • The ISO/IEC NP 27034 ‘Guidelines for application security’ was under development at the time of this writing. entitles one to receive an annual subscription to the ISACA Journal. www. 27 Congress St. MA 01970. www.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->