Exploring how SaaS Cloud Security performs penetration testing

November 18, 2024 | 9 minute read
David B. Cross
SVP SaaS Security
Text Size 100%:

For this post, we’re pleased to introduce contributing guest author, Robbie Rader, senior director for Offensive Security Operations in the SaaS Cloud Security (SCS) organization.

 

As customers continue to adopt their cloud strategies and evaluate their cloud service providers, they might ask about the timing and process of penetration testing in the Oracle software-as-a-service (SaaS) cloud. This question is one of many addressed with detailed answers, documentations, and links in the Oracle Fusion Applications Consensus Assessment Initiative Questionnaire (CAIQ). In this blog post, we dive into the topic of penetration testing, a subject of great interest within the community, particularly in the context of Oracle Cloud Applications.

 

Introduction to penetration testing

Penetration testing is a form of security assessment used to identify potential vulnerabilities in an application, network, or infrastructure by simulating cyberattacks against the targeted or in scope systems. This testing provides an organization with valuable insights into the strengths and weaknesses of the in-scope system. This testing should be performed regularly to help ensure the effectiveness of the program because the vulnerability landscape is continuously evolving. 

Penetration testing comes in various forms, such as black box (simulating external hackers), gray box (with limited information provided), and white box (focused on insider threats), but in all cases, the organization is informed before the tests begin. These tests are typically noisy and can trigger alarms for your defensive security teams if not properly communicated. Penetration tests usually operate within a specific testing window defined for the exercise. Unlike traditional penetration tests, red team testing campaigns are stealthy in nature and can last several months or even quarters, as we have discussed in a previous blog post.

 

Types of penetration testing

Two aspects of penetration testing that require explanation. Let’s explain the following types of penetration testing:

  • Black box: Doesn’t include any knowledge of the structure of the system, simulating the approach of an outside attacker.
  • Gray box: Includes only a limited knowledge of the layout of the target, IPs, and so on.
  • White box: Includes complete knowledge of the layout of the targets, source code access, and so on.

Visualization of black, gray, and white box testing in terms of tester’s knowledge of the target and comprehensiveness.

The second pivot worth explaining is when a penetration test should be performed internally versus externally by a third party. Consider the following options:

  • Internal (performed by the SCS organization): Penetration testing is performed as part of the overall software development cycle which requires security design reviews, assessments, architecture reviews, and penetration testing for every major release. All significant changes to our applications, network, or infrastructure for a public release of a new application or module requires an internal penetration test to be performed.
  • External (performed by trusted third party): Conducted at least annually and are used to support both Oracle and customer audit requirements.  

Some of the various audit frameworks that require penetration tests and reporting of results are quite common and demanded in the Oracle Fusion application environment. Several audit frameworks commonly mandated in the Oracle Fusion application environment require penetration testing along with the reporting of results, including the following examples:

  • Government regulations and compliance (US Government FedRAMP, Department of Defense, and UK Government): Annual application, network, and segmentation required. Run by third parties and require coordination of our internal penetration test team.
  • PCI DSS 4.0 (outlined in Section 11.4 of this data security standard): 11.4.1 A penetration testing methodology is defined, documented, and implemented by the entity and includes the following features:
  • Industry-accepted penetration testing approaches
  • Coverage for the entire CDE perimeter and critical systems
  • Testing from both inside and outside the network
  • Testing to validate any segmentation and scope-reduction controls
  • Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4
  • Network-layer penetration tests that encompass all components that support network functions as well as operating systems
  • Review and consideration of threats and vulnerabilities experienced in the last 12 months
  • Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing
  • Retention of penetration testing results and remediation activities results for at least 12 months
  • Service Organization Control (SOC) and Health Insurance Portability and Accountability (HIPAA): The SOC 2 audit requires a penetration test to validate a service provider's controls related to security, availability, processing integrity, confidentiality, and privacy.

 

Penetration testing methodologies

Many different methodologies and approaches to penetration testing exist, and the SCS organization uses the OWASP Top 10 and SANS top 25 frameworks in our internal testing procedures.

Assessment methodology

The penetration testing methodology that the SCS organization uses is designed to simulate a malicious attack by a competent, motivated individual and is not strictly a check-list assessment approach. Oracle SaaS penetration testers employ the same techniques and tools as malicious hackers and have the same access to information about the target environment. The Oracle SaaS view of the system is external and reflects the attacker's point of view. The methodology is based on industry standards and best practices, such as the Open Source Security Testing Methodology Manual from ISECOM, NIST SP 800-115, and OWASP Web Security Testing Guide, and is continuously adapted to any changes in the perceived threat model.

When performing security assessments and penetration tests, Oracle SaaS security generally conducts the following assessment phases:

Security assessment workflow

 

Information gathered in earlier phases determine the actions and tools employed in later phases. For less familiar or uncommon environment technology stacks, more research can be conducted during the “Review and identification of false positives” phase to identify relevant testing techniques and tools available in the public domain.

  1. Planning: In the planning phase, systems in scope are identified and documented, notifications are sent out, and testing goals are set. If the system is identified in Oracle SaaS as having been subject to a previous assessment, findings are included in the current assessment for verification.
    Based on the environment information gathered, a credible threat model is determined, which is used to prioritize and optimize attacks. No active testing against identified targets occurs in this phase, but the output is used to guide the testing conducted in the subsequent assessment phases.
  2. Segmentation testing and validation (required for PCI Assessments): During this step, Oracle SaaS verifies that the required segregation controls are implemented based on the Oracle Software Security Assurance (OSSA) policies and procedures. Port scans are performed from both the internet and Oracle's internal network. If exploitable vulnerabilities or misconfiguration are identified, Oracle SaaS continues to scan and attack the systems from inside the defined environment. If the tested environment contains many systems, a representative subset of devices will be tested to reduce the number of checks and amount of time expended.
  3. Vulnerability scanning: This phase consists of the following stages:
  • Service enumeration: A comprehensive network scan of the target environment is conducted, and the available asset inventory is queried to determine network zones hosting the servers. The primary goal of this stage is to determine all open services presented by the virtual IP (VIP) and physical tiers comprising the assessment environment (open firewall ports), in addition to the collection of any applicable service versions.
  • Service scanning: This phase introduces the first vulnerability scanning actions. The physical tiers are scanned internally for local OS vulnerabilities using OCI’s web scanning infrastructure, compiling a list of potentially vulnerable services and candidate exploits within the assessment environment.
  • Application-level scanning: The application is accessed using the provided credentials and scanned using various that act as local proxy servers between the web browser and the server-based application. The tools record all URLs, session cookies, URL parameters, form POSTs, and related parameters. They then “fuzz” those items with signatures designed to elicit a response, indicating vulnerabilities, such as SQL-Injection flaws and cross-site scripting (XSS) flaws.
  • Review and identification of false positives: The information collected from all the phases is reviewed, and any duplicates are noted. Reports from the service and application vulnerability scanning tools are reviewed, with likely positive candidates identified and obvious false positives rejected through confirmation checks.
  1. Penetration testing: Manually conducted attacks are a critical component of the penetration testing process. During this phase, we verify scanner-reported vulnerabilities by attempting to exploit them, with the intention of demonstrating a bypass of the service access controls. If successful, the vulnerability is documented, and security controls are identified to mitigate the associated exposure. This phase also attempts to gain unauthorized access to the assessment environment, including the operating system, backend databases, middle-tier administrative infrastructure, and the application itself.
    Additionally, several tests are performed on the network components to better understand the environment, test ingress and egress filtering to the asset network zones, and to identify potential vulnerabilities at this layer.
  2. Documenting results: A comprehensive document detailing the assessment, including itemized findings and mandatory remediation steps, are created for internal impacted teams to review, confirm findings, and implement the necessary actions. Unsuccessful attack attempts are documented in the observations section of the report, as well as any other suggestions to improve system security. If the environment in scope was tested in a previous engagement, Oracle SaaS provides a remediation status update on previous reported vulnerabilities.
  3. Remediation confirmation: All outstanding findings will be tracked by Oracle SaaS through the remediation process. The SCS organization conducts more checks to confirm any issues have been addressed, attempting to reexploit the identified vulnerabilities. Oracle SaaS informs the system owner if the item has been resolved or remains exploitable. Testing is repeated until all critical and serious findings are no longer exploitable.

 

How are identified vulnerabilities managed?

Oracle’s strategic priority in handling vulnerabilities is to remediate identified issues based on their severity and the risk they pose within the context of the specific application or service. The CVSS Base Score is one of the key criteria used to assess the relative severity of vulnerabilities. All identified vulnerabilities are tracked in a defect tracking system, and each fix undergoes thorough testing to prevent issues in production before each major release of an application. Oracle performs security testing and uses formal security criteria before bringing any new release into production.

 

The value of regular penetration testing

Penetration testing in the production environment is performed at least annually by a trusted third-party company, and summary reports are available upon request for existing SaaS customers. At Oracle, this testing is done throughout our development and production lifecycles and includes static application security testing (SAST), dynamic application security testing  (DAST), and software composition analysis (SCA), among other types of scanning and analysis activities, as we have shared in the blog post, Remaining Vigilant: Security Scanning Throughout the Oracle SaaS Application Lifecycle.

We know that transparency is crucial in developing strong partnerships with our customers. So, each penetration testing report also provides an Oracle response containing Oracle’s position for each finding discovered, the Common Vulnerability Scoring System (CVSS) score, and the target timeline to remediate each finding. We also frequently rotate the external third-party penetration test providers to ensure the widest and most diverse experience coverage against the Oracle SaaS applications.

 

How to get a penetration test report

Penetration testing in a production environment is performed at least annually by a trusted third-party company, and summary reports are available upon request for existing SaaS customers. You can contact your Oracle customer success or account manager for the latest security assessment report.

Oracle SaaS doesn’t permit customers to contract or perform independent testing of SaaS cloud services because our services are complex multitenant infrastructure deployments and independent testing can result in potential unintended impacts unless approval is received. For more information, see the Security testing frequently asked questions.

 

Summary

In Oracle SaaS Cloud, penetration testing and vulnerability management are integral parts of our broader DevSecOps model. To be most effective, these processes require the collaboration of both highly skilled security personnel and automation working together. Within Oracle SaaS, the SCS organization uses and effectively incorporates penetration testing results, insights, and analysis across multiple development security operations programs to maximize customer benefits and protections. We hope that these reports provide you with the confidence and assurance you need to adopt the right solution for their application and data needs.

 

 

David B. Cross

SVP SaaS Security

David is the Senior Vice President for the Oracle SaaS Cloud Security engineering and operations organization.  Previously, David was the public Cloud Security Engineering Director in the Google Security and Privacy organization and his preceding 18 years were spent with Microsoft in numerous security cloud, product and engineering leadership roles.  David holds a B.S. in Computer Information Systems as well as an MBA with a Management Information Systems concentration and is a longtime advocate of security application and technology stemming back to his US military service.

Show more

Previous Post

Enabling developer collaboration with pull requests in OCI DevOps code repositories

Saurabh Shah | 5 min read

Next Post


Now Generally Available: The Largest, Fastest AI Supercomputer in the Cloud

Sagar Zanwar | 3 min read
Oracle Chatbot
Disconnected