Project Report

of
DISA 3.0 Course

Conducting Vulnerability Assessment and Penetration Testing Page 1

 Conducting Vulnerability Assessment and

Penetration Testing

Conducting Vulnerability Assessment and Penetration Testing Page 3

 Table of Contents

Details of Case Study/ Project (Problem)

Project Report (solution)

S.No. Index Page No.
A Case Study 5
B Project Report
1 Introduction 6
2 Auditee Environment 6
3 Background 7
4 Situation 7
5 Terms and scope of assignment 8
6 Methodology and strategy adapted for execution of assignment 8-10
7 Documents Reviewed 10-14
8 References 14
9 Deliverables 14-16
10 Recommendations 16-19
11 Deliverables/ Conclusion 19-20

Conducting Vulnerability Assessment and Penetration Testing Page 4

 Project Report

Title: Conducting Vulnerability Assessment and Penetration Testing

A. Details of Case Study/Project (Problem)

The Client “ABC Bank Ltd.” is the largest public sector bank in India and wants to deploy
Banking software across 2000 branches in next 5 years. ABC Bank Limited has signed a
strategic IT partnership with Prosys ABC Bank Limited has licensed Prosys Banking
Software which includes Manage soft-the core banking solution, e-Connect the Financial
Middleware software system, and e-Banker the Internet Banking Solution. ABC Bank
Limited is planning to offer relationship banking to its customers through which customers
of any of its identified branches can transact at any other branch with a single account.
Further, ABC Bank Limited is also planning to offer Internet banking. ABC Bank Limited
has 19000 ATMs which are expected to be connected to the main servers and it intends
to add another 33000 ATMs which are located at different locations. Customers of any
of the 19000 branches can operate their accounts and transact on-line from anywhere.
The latest inspection by RBI has made observations on need for the bank to have
Information System (IS) Audit of the bank’s IT infrastructure primarily focusing on
adequacy of Business Continuity Planning (BCP). The internal audit department of the
bank in the recent audit of the data centre has commented on the need to get independent
IS Audit to confirm the BCP of the bank is comprehensive and meets all the requirements.
The maintenance of IT infrastructure of the bank has great reliance on external vendors
which is governed by SLAs. The senior management has decided to have an independent
IS Audit using the RBI checklist and other best practices.

Conducting Vulnerability Assessment and Penetration Testing Page 5

B. Project Report (solution)

1. Introduction

Vulnerability Assessment and Penetration Testing (VAPT) are two types of vulnerability
testing. The tests have different strengths and are often combined to achieve a more
complete vulnerability analysis. In short, Penetration Testing and Vulnerability
Assessments perform two different tasks, usually with different results, within the same
area of focus.
Vulnerability assessment tools discover which vulnerabilities are present, but they do not
differentiate between flaws that can be exploited to cause damage and those that cannot.
Vulnerability scanners alert companies to the pre-existing flaws in their code and where
they are located. Penetration tests attempt to exploit the vulnerabilities in a system to
determine whether unauthorized access or other malicious activity is possible and identify
which flaws pose a threat to the application. Penetration tests find exploitable flaws and
measure the severity of each. A penetration test is meant to show how damaging a flaw
could be in a real attack rather than find every flaw in a system. Together, penetration
testing and vulnerability assessment tools provide a detailed picture of the flaws that exist
in an application and the risks associated with those flaws.

2. Auditee Environment

SAP deployment in STL posed unique challenges arising out of the need to integrate
multiple units across different locations, involving extensive procedures and large
volumes of data.
The family of business applications provides better insight into enterprise-wide analysis
based on real time data and key performance indicators, improved quality and on-time
delivery, reduction in inventory cost and enhanced customer service. This implementation
has empowered STL to seamlessly connect all its vendors, customers and partners to
achieve improved business efficiency.
SAP-R3 ECC 6.00 Version is deployed across all of STL’s financial, payroll and human
capital functions.
The Modules implemented are PP, MM, FICO, Quality, PM and HR including Pay Roll.
STL has more than 400 sap users across the company. By implementing SAP solutions
STL has achieved superior operational excellence and business agility.

Conducting Vulnerability Assessment and Penetration Testing Page 6

3. Background

STL Group has been using Information Technology as a key enabler for facilitating business
process Owners and enhancing services to its customers. The senior management of STL
has been very proactive in directing the management and deployment of Information
Technology. Most of the mission critical applications in the company have been computerized
and networked. STL selected SAP Business Suite to bring a more integrated and seamless
approach to internal processes.
This implementation has empowered STL to seamlessly connect all its vendors, customers
and partners to achieve improved business efficiency. SAP-R3 ECC 6.00 Version is deployed
across all of STL’s financial, payroll and human capital functions. The Modules implemented
are PP, MM, FICO, Quality, PM and HR including Pay Roll. STL has more than 400 sap
users across the company. By implementing SAP solutions STL has achieved superior
operational excellence and business agility.

4. Situation

The STL selected and purchased the Finance, Production and Human Resource module
incorporating “PP, MM, FICO, Quality, PM and HR Module” to replace its core legacy financial
and human resource systems. The project took a two phase approach for implementing these
SAP modules.

- Phase one implemented the finance and production module;

- Phase two implemented the human resources module.

Due to complications with the Production component of the Finance & Production module,
implementation of the Production component was delayed. The go-live schedule for the various
phases is described in the table below.

Table 1: Initial Completion Schedule vs. Start date Scheduled Actual “Go-
Actual Completion Phase Name “Go-Live” live” date
date
Finance and Production Nov 2009 March 2010 March 2010
Human Capital Management (Human April 2010 October 2010 October 2010
Resources)
Production (A component of the Finance & Nov 2009 March 2010 August 2010
Production module)

Conducting Vulnerability Assessment and Penetration Testing Page 7

5. Terms and Scope of Assignment

The audit scope is to proper planning, evaluation, implementation and controls of ERP software
for all the departments.
IS Audit scope is to provide comfort on the adequacy and appropriateness of controls and mitigate
any operational risks thus ensuring that the information systems implemented through SAP
provide a safe and secure computing environment.
The IS Audit of SAP deployment would be conducted at IT department at corporate office at
Bangalore.
Further, specific areas of improvement would be identified by benchmarking with the globally
recognized best IT practices of COBIT framework. The initial assignment could primarily focus on
the identified areas of SAP Implementation. The proposed scope of review and the terms of
reference as laid down in the following paragraphs are given in annexure. These terms of
reference are based on the preliminary discussion the assignment team had with the STL team
and is subject to further modification as required.
Broadly the scope of review primarily from security\controls and would involve:

A. Review of IT Resources as relevant

a. Operating Software: Access controls

b. Telecommunications Software: Access Controls
c. RDBMS Database: Access Controls
d. SAP - Major focus area: Configuration of Parameters and Access Controls
e. Application controls at various stages such as Input, Processing, Output, Storage, Retrieval
and transmission so as to ensure Confidentiality, Integrity and Availability of data.

B. Organization structure policies, procedures and practices as mapped in the information

systems.

C. Review of policies, procedures and practices as relevant to areas of audit.

6. Methodology and Strategy adapted for execution of assignment

The following audit scope was developed using the ISACA standards, IT practices of COBIT
framework and guidelines and applicable Auditing Standards of ICAI following a risk based
methodology.

The proposed phases and areas of audit are mentioned below

A. SECURITY AUDIT
B. USER AUTHENTICATION AND AUTHORIZATION
C. AUDIT TRAILS
D. CHANGE MANAGEMENT (PRODUCTION SYSTEM INTEGRITY)
E. SYSTEMS MONITORING
F. BUSINESS PROCESS CONFIGURATION

Conducting Vulnerability Assessment and Penetration Testing Page 8

AUDIT RESULT:

RISK AREA AND INCLUDES THE FOLLOWING AREAS

DISCLOSURES :
Category for Review
Project & Contract Deliverable & Issue Management, Project Team Training,
Management Governing Documents, Project Requirements, and Blueprint
Management
Integration Testing Integration Testing Cycles
Data Conversion Conversion Strategies, Cross Walk, Mock Conversion
Testing Cycles
Reporting Roll-out Strategy, Requirements prior to go-live, post go-live
support and roll-out
Cut-Over and Stabilization Strategy, Support Level Requirements & Delivery
Methodology
Training and Communication Training Roll-out, Methodology, Key Areas Addressed
Retiring Systems Historical Data Storage, Access, System Phase Out
Security Security Implementation Strategy, Governing Documents,
Role Mapping, Access Controls, Process Controls

In the review of each section, we employed the following methodology customized for each
primary area reviewed.

1. We first determined components within each category to review based on risk to the
implementation completion, intended functionality, and schedule;

2. Reviewed component implementation methodology and plans for sufficiency (such as the
strategy for Integration Testing, and sampled the planned tests to perform);

3. Observed components implementation and tracked to planned methodology to ensure

that there was no disconnects between what was planned and documented and the work
that was actually performed;

4. Reviewed implemented components using judgmental sampling to confirm that the end
result came out as planned, or was appropriately adjusted;

5. Reported issues discovered throughout the process based on risk, and conveyed
recommendations directly to the implementation component lead. Due to the nature of the
ERP implementation, reporting issues in a timely manner presented unique challenges as
compared to a standard audit. As is the case with system implementation audits, issues
present a moving target. Our reporting process takes into account the fact that issues are
expected to occur during an implementation and do not necessarily present a risk to the
project. Further, management had several methods available at any given time during the
project to identify and remediate issues. As a result of the fast pace of the implementation

Conducting Vulnerability Assessment and Penetration Testing Page 9

 and the immediate management need for information, we developed the following
reporting process;

6. Initially, we approach each potential issue with the appropriate section team lead. Medium
and low risk issues are not formally reported though may be presented to a higher level of
management if required. This results in quick response times to most issues and quick
resolution of the larger amount of smaller issues as they arise;

7. High risk issues, based on potential impact to project, are brought to management’s
attention. Issues that could have a potential impact to the project’s implementation are
formally reported at a high level if they are not remediated in a short time frame or carry a
significant risk to the project’s adequate and on-time completion;

8. High risk issues are communicated defining the condition, criteria, cause, and effect. Our
focus on reporting exists for the purpose of first, ensuring that project management is
independently aware of any issues that arise. We further developed a process to ensure
that any high risk issues which could potentially affect the adequate and on-time project’s
completion are reported to the audit committee regardless if the management states that
they will remediate it. The issues reported to the committee are high level, such as
requiring a policy verses the technical details of what needs to be implemented, while
those presented to the team leads will contain the required details for appropriately
addressing the issue.

7. Documents reviewed

Address Security & Privacy Requirements Security and privacy are two of the issues that
concern cloud service customers the most. Depending on the sector, these may be just
above or below concerns about availability and performance as highest priority. At the
same time, cloud service customers should remember that many of the security and
privacy concerns raised by cloud computing have existed since the first forms of IT
outsourcing were introduced.
Security involves multiple concerns. It includes such aspects as:
 How hard is it for an intruder to steal confidential data from the cloud provider’s
systems (external threat)?
 If this happens, will you even know it?
 Can you trust the provider’s personnel, especially system administrators who have
many privileges over the systems you use (internal threat)?
 What does the SLA promise you in terms of security measures?
 What is the impact on your business of a denial-of-service attack, which may not
endanger your data but prevents users from accessing the application?
 How do you authorize an employee to access a system or application in the cloud?
How do you unauthorized them, and how quickly can you do that in a serious
situation (termination for cause, etc.)? What levels of trust do you grant different
users, and how do you identify and authenticate trusted users?

Conducting Vulnerability Assessment and Penetration Testing Page 10

  How do you prove to a client or an auditor that adequate security measures are in
place, now that this is not only your problem, but a shared responsibility between
you and a cloud provider?
 How can you verify that the virtualization platform or cloud management software
running on the systems you use, which you did not install and do not control, does
not contain malware?
 How can you protect yourself from malware that could be introduced by another
customer in a multi-tenant environment?
 What is the risk that your data will be delivered to a domestic or foreign law
enforcement agency by the cloud service provider in response to a legally binding
request?
Privacy is closely related to security, but it carries with it the additional burden that a
violation of privacy, for example the disclosure of PII about your own users or customers
to people who do not have a right to access it, will cause major damage to your company,
including:

• Loss of business
• Legal action by the people whose information has been disclosed
• Non-compliance with government regulations

In addition, data subjects may have rights to inspect and correct PII that relates to them,
which will need to be supported by the application even when it runs in a cloud service.
Now that we have examined all the risks and threats that arise when migrating an
application to the cloud, it turns out that doing so may, in fact, increase its security. This
statement is based on two facts:

• Cloud service providers have, in all likelihood, more expert resources at their disposal
than many of their customers. They need to make that investment because a successful
attack could damage their entire business. Therefore, customer data may be safer in the
cloud provider’s custody than in customer’s in-house systems. This is the same principle
that leads people to rent a safe deposit box at their bank rather than keeping their
valuables at home.

• Once your data is held in a cloud service, an attacker who specifically wants to gain
access to your information no longer knows exactly where to attack. Even if they
successfully penetrate the network of the cloud provider, there may be thousands of
virtual servers whose names do not reveal whose data they contain.
Knowing all the above, here are some logical steps to follow (again, see the “Security in
the Cloud” white paper for more information). Note that as a result of performing these
tasks, you will never be 100% protected, and after a risk analysis you may even end up
deciding that you cannot in fact migrate certain data or applications. But they will certainly
increase the chances of success.

1. Understand exactly what data (including what code, since code may be the confidential
asset to protect) will be migrated to the cloud service.

Conducting Vulnerability Assessment and Penetration Testing Page 11

2. Map this data to your security classification. If a security classification does not exist,
or if it does not specify where and in which format (cleartext vs. encrypted) data may be
held on the basis of its classification, this is an issue that must be resolved.

3. Identify which information raises privacy concerns – for example, account numbers,
dates of birth, addresses, etc.

4. Examine applicable regulations (especially in the finance and health domains) and
determine what needs to be done to meet these regulations, and whether it is possible to
meet these demands while migrating to cloud computing.

5. Perform the normal risk management tasks of assessing the risk of security or privacy
violations, and the impact on the business.

6. Review the cloud providers’ security/privacy measures (including physical security,

personnel screening, incident notifications, etc., not just the technical security protection
measures), and make sure that they are documented in the cloud SLA.

7. Determine whether the results of these steps actually allow the project to continue.

8. Consider and implement ways in which the information can be protected in four different
situations:

a. During the bulk migration of data from the on-premises system to the cloud service,
when the cloud service is provisioned. This can be a weak point of the whole
process, as an entire database backup may be carried physically, or shipped via
courier, to the cloud service provider’s site.
b. “Data at rest,” while stored in the cloud. An obvious solution for sensitive data is to
encrypt the data, and the practical question is whether the provider can perform
this service, or whether the client needs to research and implement a solution.
c. “Data in motion,” during the routine exchange of data that occurs while using the
cloud based application. Encrypting data in transit is advisable, but runs into some
issues: the cloud provider must support the encryption chain, cryptographic keys
may need to be installed at both ends (requiring a key management solution), and
on-the-fly encryption may affect transfer speeds.
d. “Data in use,” that is when the data is actually read and processed by an
application. For sensitive data, it may be advisable for the application to encrypt
the data. This may not be possible if the migrated application is a commercial one
that can only read the data in clear text from a database. A customer written
application, on the other hand, can be modified to read/write encrypted data, so
that only some temporary memory buffers will contain clear text data. The handling
of encryption keys is a concern.

Conducting Vulnerability Assessment and Penetration Testing Page 12

9. Design how to authenticate and authorize users. For systems that have their own sign-
on facility, there may be no impact (as long as passwords are not sent in clear text from
the user’s workstation to the cloud-based system, which should not be the case even for
an on-premises system). But if there is any form of Enterprise or Single Sign-On (SSO)
facility, making this work from an application running in a cloud service may require
integration work. An enterprise identity and access management system (IdAM) needs to
be accessible from the application migrated to the cloud service. You will need to
understand which protocols are supported by the IdAM and by the cloud service –
additional integration components may be required to enable them to interoperate.
The silver lining is that once that effort has been made for the first migration, it should
make future migrations easier.

10. Regardless of the solution chosen for authentication and authorization, you need to
make sure that your user de-provisioning process can be executed quickly. Disabling a
user’s credentials for access to cloud systems may be even more critical than disabling
their access to an on-premises system. The reason is that access to an internal system
may be made immediately impossible or more difficult if someone has been escorted out
the door; but might still be able to access the login page of a cloud application from the
browser on their smartphone.

Service Levels

In addition to assessing the costs of application migration, it is equally important to ensure

that the level of service provided by the cloud-based application will be comparable to
current service levels. The required service levels should be agreed with the cloud service
provider and explicitly documented in the cloud service agreement. In fact, the service
levels provided by an internal IT department to its business customers are often not well
specified, or not specified at all. Migrating an application to cloud computing places a
spotlight on those essential commitments. Refer to the CSCC Practical Guide to Cloud
Service Agreements and the CSCC Public Cloud Service Agreements: What to Expect
and What to Negotiate for specific considerations that need to be taken into account when
developing an enterprise strategy for cloud computing.

For each application being migrated to cloud computing, consider the following
application characteristics:

• Application availability. The criticality of the application to business operations will

determine the availability requirements that must be clearly specified in the cloud SLA.

• Application performance. Depending on the performance requirements of the

application, specific performance targets may need to be achievable with the cloud
service.

• Application security. Moving an application to the cloud will require due diligence on the
part of the cloud service customer to ensure proper security controls are in place and
operating effectively.

Conducting Vulnerability Assessment and Penetration Testing Page 13

• Privacy. Personally Identifiable Information (PII) handled by a cloud-based application
must be properly stored and maintained. Access to PII stored in a cloud service must be
restricted as required, including from cloud service provider personnel.

• Regulatory compliance. Government and industry regulations may require additional

measures, such as restricting the migrated applications and data to reside in a specific
geographic region.

8. References

An ERP implementation consists of taking a commercial enterprise product and customizing the
selected modules to replace and improve business functionality over the systems being replaced.
An implementation of this magnitude is a very complex process, and presents unique challenges
to each implementation. However, there are standard aspects to each implementation as well. A
system implementation is a part of a standard process known as the System Development Life
Cycle (SDLC). The Information Systems Audit and Control Association (ISACA) define the SDLC
as:
The system development life cycle is the process, involving multiple stages (from establishing the
feasibility to carrying out post implementation reviews), used to convert a management need into
an application system, which is custom-developed or purchased or is a combination of both.
ISACA further provides standards and guidelines for performing audits of these implementations.
Our Scope was developed incorporating ISACA’s Control Objectives for Information and related
Technology (COBIT) standards, SDLC Review Guidelines (ISACA Document G23) and ERP
Systems Review Guidelines (ISACA Document G21). This approach allows us to review the
standard implementation components, as well as providing a standardized methodology for
reviewing the unique challenges within this implementation.

Additional References
Study material issued by ICAI.

9. Deliverables

We found that Management was generally quick and proactive in identifying and addressing risks
in project management, integration testing, data conversion, reporting, cut-over, and retiring
legacy systems. However, the City needs to address concerns related to system security, controls
associated with vendor payments, and training for City staff. By so doing, the City can fully utilize
its significant investment in the One SD ERP system. Specifically, we found the following issues
still requiring attention –

Security Issue – Monitoring over ERP support department staff system access controls have not
been fully implemented,

Payment Controls Issue – Controls against the creation of vendors and payment of invoices
should be strengthened,

Training Issue – Inconsistent on-going City training for utilizing the ERP system, and

Conducting Vulnerability Assessment and Penetration Testing Page 14

Previously Reported Issues – Two of seven previously reported issues, primarily in security,
remain outstanding.

In order to correct the identified deficiencies, we recommend management

Result of Testing

 It was found that the STL Limited does not have a defined monitoring program for general
and technical user segregation within the ERP system. Individuals’ access to various
important areas leads to the risk that unauthorized ERP any staff can eradicate the data
or modify the ERP system without any appropriate authority.

 Presently, the Company does not have a consistent monitoring program over both
general and technical users within the ERP system to ensure that unauthorized access
will be recognized. The problem of access existing on the STL’s new financial system
will ruin the reputation of company.

 Finally, the production department does not use of complex passwords for authentication
as required by policy of company. Lack of strong password increase the risk of hacking
of financial data.

 The Information Systems Audit and Control Association (ISACA) specifies in its Control
Objectives for Information and related Technology (COBIT) that monitoring function over
the security implementation to enable early prevention of abnormal activities.

 Company’s new financial system, special attention should be given to the ERP support
department’s access to the system, as they will always have more access than a standard
user. Accordingly, this requires that the highest risk areas be identified and monitored
using appropriate methods to mitigate the correlating risk.

On identification of discrepancies, following opinion to management:

Opinion 1:
Security monitoring implementation over ERP software staff access in the production department.
Management is recommended to:

a. Perform analysis of risk and cost benefit analysis on the system and access functions that have
the large risks in determining which controls would be the best to the related expenses of
generating trails or using employee’s time to review constantly. Automated review, like the use of
biometric to identify certain unauthorized access or high risk situations should be used.

b. Various check points should have an automated trigger to maintain proper controls on critical
places or alert such as SMS or mails generated from the use of unwanted access repeatedly, and
sent to the appropriate person for action and control.

Conducting Vulnerability Assessment and Penetration Testing Page 15

c. As suggested periodic review on regular intervals of documentation on monitoring controls
should be done to check the effectiveness of running or working of systems.

d. Frequency of review of controls / risks should be implemented and documented as per the ERP
policy of Company.

e. the user should be given access for day to day workings with restricted access only so that
they can perform their duties and not access all the systems and information of organization

f. Generic accounts without any authority should be removed from the system.

g. All the roles should be standardized in ERP environment with proper approvals for authorized
person.

h. Access roles should be reviewed periodically with set standards as per ERP environment.
Checklist should be prepared for the roles at each level management.

i. Logs should be reviewed periodically and sign-off by the manager given when they are in use.
These logs should be automatically generated and no one should have access to edit those logs.

10. Recommendations

Recommendation # 1:
Training of staff in ERP software

Training is most important part of implementation and making successful running of system
depends upon the effective education/ training of employees. The primary component of
successful running is employee’s acceptance and making the use of system effectively and
accurately, which is possible only with help of training about system.

Training is the process of making familiar to STL employees with new methods of performing
their duties within ERP. Training is always complicated because change is not acceptable to
everyone easily. Although introducing employees with new system helps them making
familiar with interface so that the fundamental concepts of ERP are exposed to them.
Communication assisted training as well as general preparation for the implementation of the
ERP system and type of material they expect for the various departments. The
communication strategy employed included two methods in various department
communication levels among employee and allowed information to bring in the department
as well as providing feedback to the project team. In case of Project Action Committee the 2
way communication to be kept at each department updated about existing level of
achievements as well as feedback of management at each departments. The communication
will be complete only if it is flowing both ways i.e. the level of achievement is to be decided
on the basis of feedback of working from management of every department.

Results of Testing

Conducting Vulnerability Assessment and Penetration Testing Page 16

As per our observations, training programmes are not being regularly implemented in various
departments consequently in some departments ERP system are not being completely utilized
which affecting the performance of employees and decision making of management due to not
receipt of proper reports from employees. Even on such huge investment by company returns are
not generated from the System on the other hand it is demanding more investment.

Recommendation # 2:

To complete the review for delivering centralized on-going training and ensure that classes
addressing the functions of ERP and its interface should be provided on a regular interval basis
and made available to all the departments and specifically to management
- Schedule of training for specific role based on the results of the checklist they had done.
- Training schedule should be made available to employees by using means such as webinar
/email or intranet sites. After the training is completed feedback should be taken from employees
to know the effectiveness of training and if any change is required in the method of training.

Documentation
Standardizing security parameters within the ERP environment has not been
documented
Security policy describing the expected security standards and criteria to ensure complete
security on a regular interval basis has not been created.

Recommendation # 3:

ERP Security comprises of both automated security processes through logs and manual security
processes through SOPs. Automated security processes must be documented to ensure they are
adequate and the manual processes documented in such a manner that there is no overlapping
of processes. Manual security process has high risk as well as they require consistent updating
by personnel. All the requirements must be documented to ensure that security personnel know
all their daily, weekly, monthly, and annual requirements as well as to allow review of timely to
know the updates available and meet the compliance policy of organization.
ERP Security Policy should include Standard User Provisioning (SUP), General Controls
approach (GCA), and General User and Transaction Monitoring (GUTM). General User
provisioning overall is being managed through security provisioning methodology and policy
controls progress in mapping and managing current company’s controls through their policy
Controls over Financial Reporting project.
Greatest risk area are managed and controlled through proper policies defined in the system by
the management in technical roles, including Support, Security, Development and Security as
well as the mitigation of the separation of duty conflicts inherent within defined roles.

Stabilized use for each department within the ERP environments as well as greatest risk
exceptions to the use:

• Development
• Controls
• Quality Assurance
• Risk Analysis

Conducting Vulnerability Assessment and Penetration Testing Page 17

• Production
• All severe controls over technical access including standard access restriction
• Monitoring appropriate to each department must be defined method of monitoring as well
as frequency of monitoring.

Generic Monitoring should always be documented as well as detection of circumvented daily user
access. Due to lack of documentation process vague manual security practices are developed
which affect the system in running for long tenor and develop inconvenience in later stage of
growth in business.

On our review it appears that policy documentation has not been created due to the various other
prioritizations in the project. Consequently, lack of this policy may result into:
• Lack in security systems such as overdue reliance on automated security and inadequate
manual security;
• Sub-standard of controls such as standardized access monitoring.

Status
The Security Policy which is documented provided for audit on October, 2010 and will be reviewed
overall on our current audit follow-up process.

Reported high/ greatest risk issues

Integration Testing

Integration Testing is the stage in the project where the various components that have been
designed and built are tested together. The team does this by developing testing scripts
designed to run business processes on the newly integrated components to ensure they work
as intended.
Our review of Integration Testing included

• Review of Integration Testing management strategy and methodologies;

Live observation of testing process to ensure that testing followed defined practices and
results as well as to confirm testing results;

• Randomized attendance of daily meetings reviewing progress and issues encountered;

• Review of testing scripts;
• Review of issue identification, escalation, and resolution;
• Management review and oversight.

Integration testing, we observed that the Integration Testing team had a very strong issue
resolution processes, were very well prepared for the testing, and adjusted quickly where
necessary. No high risk issues were identified during our review of integration testing. We
conveyed identified low and medium risks as well as improvement recommendations to the
appropriate team leads during the implementation as defined within our standard reporting
process.

Conducting Vulnerability Assessment and Penetration Testing Page 18

Contract & Project Management
Contract management is the process of defining what tasks need to be performed to complete
the project, and who is responsible for completing them. It addresses timetables as well as
methods for resolving issues and disputes. Project management governs the execution of
those tasks, and is arguably the most important group in the implementation of the project.
Our review of Contract and Project Management included:
• Review of Contractual and Project Governance documents such as the SAP Statement of
Work, the Project Charter and SDDPC related contractual documents. Our goal was to ensure
that the project was adequately defined to meet the Company’s requirements;
• Tracking of Project progress and deliverables according to the contractual documents;
• Tracking of project organization based on contractual documents;
• Review of project issue resolution processes, both documented and in practice;
• Participation in relevant project meetings for different aspects of the project;
• We further performed reviews of project and contract management for each tested area of
the implementation.

During our review, we identified 5 high risk issues in the areas of deliverables, governing
contractual documents, and insufficient delivery, which we reported in our June 2009 update.
These issues have since been corrected. We identified any low and medium risks as well as
made recommendations to address these risks to the appropriate management during the
project.

11. Conclusion/ Deliverables

We found that the STL does not have a defined and consistent monitoring program for technical
users within the ERP system. Specifically, individuals retain unfettered access to critical areas
exposing the STL to the risk that unauthorized SAP IT Support staff can steal data or modify the
ERP system without proper authority, or worse, without the STL’s knowledge.
Currently, the STL does not have a defined and consistent monitoring program over technical
users within the SAP System to ensure that misuse of technical access will be identified. For
example, we found that an IT user had created a “generic user” with “SAP_ALL” access. The
problem with this type of access existing on the STL’s new financial system lies in the fact that
this access allows the user to do anything in the system without being able to see who did it.
Further, overlap exists between technical user types. For example, security team members have
access to system administrative type functions normally restricted to “BASIS” users, or SAP
system administrators1. In the extreme case, as occurred in June of 2010, where an IT user had
“SAP_ALL” access using a generic account (an account not directly tied to anyone) – that user
essentially had the access of every type of user in the system. This type of access includes access
to all payroll, personnel, and IT system administration staff, essentially creating a Segregation of
Duties (SOD) problem. The ERP support department is implementing additional controls to
prevent this from happening again.

The Information Systems Audit and Control Association (ISACA) specifies in its Control
Objectives for Information and related Technology (COBIT) that a logging and monitoring function
over the security implementation should be implemented to enable the early prevention and/or
addressing abnormal activities. In the case of the STL’s new financial system, special attention
should be paid to the ERP support department’s access to the system, as they will always have

Conducting Vulnerability Assessment and Penetration Testing Page 19

more access than a standard user. Accordingly, this requires that the highest risk areas be
identified and monitored using appropriate methods to mitigate the correlating risk.
If the IT user was malicious, he or she would be able to steal, delete or modify financial data in
the system without being detected. According to the Identity Theft Resource Center, there were
at least 662 data breaches in 2010, exposing more than 16 million records. Internal data theft was
among the leading causes. The data stolen primarily consisted of personal and financial data with
the estimated average annual cost of 3.4 million per compromised organization per year. The
actual number of breaches is most likely much larger as many organizations do not disclose data
breaches.

*******END OF THE PROJECT*******

Conducting Vulnerability Assessment and Penetration Testing Page 20