Cloud Security Perspectives and Insights

Recent Posts

Application Security

How frequent static application testing finds potential vulnerabilities

  For this posting, I would like to introduce my joint guest author Naveen Gupta, who is a Principal Security Engineer in the SaaS Cloud Security (SCS) organization.   Oracle has a long-standing, secure development product lifecycle that is a core component of the Oracle Software Security Assurance (OSSA) program. OSSA is Oracle’s methodology for building security into the design, build, testing, and maintenance of its products, whether they are used on-premises by customers, or delivered through Oracle Cloud. One of the requirements of the OSSA program is to evaluate Oracle functionality throughout the product lifecycle using static analysis tools. As mentioned in this Oracle blog, the Oracle SaaS Cloud Security (SCS) organization completes security testing during the DevSecOps cycle for SaaS applications such as Oracle Fusion Cloud. Static application security testing (SAST) is a white-box method of testing. SAST examines the source code to find software flaws and weaknesses that can lead to security risks. These risks are defined by various governing bodies and standards like OWASP, CWE, NIST, SANS, and PCI. DevSecOps aims to embed security into every part of the development, delivery, and operations processes. As most security vulnerabilities get introduced at the time of the coding, it is essential to identify and fix them at the earliest possible stage of the development cycle. The SCS team completes static analysis during the coding stage. We use SAST tools to analyze the source code of the application and bytecode without executing the application. Benefits of Using SAST Tools in SaaS When it comes to SaaS, secure coding is non-negotiable. Cloud service providers simply cannot afford to implement insecure applications and software systems. In a typical SaaS environment, the software development lifecycle (SDLC) works with the traditional CI/CD (Continuous Integration/ Continuous Deployment) DevOps model. There are multiple advantages that SAST brings to the SDLC for Oracle SaaS applications. Some of these are: (a) SAST tooling examines code in detail in the repository, thereby reducing the time and personnel required to identify potential security defects. Automated SAST tools are faster and can examine code more frequently, which is the very essence of a CI process. (b) Conventional threat modelling cannot anticipate every possible technique that attackers can use  to exploit the vulnerabilities that can exist in software. These vulnerabilities exist because even smart developers can make coding errors that cause vulnerabilities in an application. The use of SAST tools during software development therefore acts as a reliable defense against common application threats and coding errors. (c) SAST tools are integrated into the SDLC for Oracle SaaS. SAST helps to reduce the security risk in the application by enforcing checks at different phases. For example: (d) During the development phase, the applications developers incorporate SAST into their development tooling (with integrated development environment (IDE) plugins) and workflow. (e) At the build phase of the DevSecOps model, SAST tools are integrated into the software engineering system during CI/CD execution. (f) Before deployment, security teams use SAST tools to scan applications for security vulnerabilities. (g) In addition, some SAST tools can integrate with source repositories and automatically report vulnerabilities to defect tracking systems. (1) SAST tools are executed early in the SDLC, minimizing the risk of critical or high vulnerabilities getting into a deployed SaaS application. (2) SAST results are considered as evidence artifacts for SaaS applications that must comply with industry security audits like the Federal Risk and Authorization Management Program (FedRAMP) or Payment Card Industry Data Security Standard (PCI DSS). Types of Vulnerabilities Found with SAST Security vulnerabilities that we identify during the phases of the DevSecOps model often fall into the following types: - Input validation and representation - Application Programming Interface (API) abuse -  Authentication - Authorization - Security features - Errors - Code quality - Encapsulation - Auditing and logging   Figure 1: SAST occurs during the (Plan, Code, Build, Test) phases of the DevSecOps cycle SAST tools work directly on the source code, using an inside-out approach to perform security testing. SCS analyzes the results from the scan reports for multiple vulnerabilities to identify security issues. We use in-memory graphs to identify any untrusted data entry points (sources) and the point where the vulnerability (sink) manifests during code execution. What do SAST tools find? During SAST, we analyze for these vulnerabilities: (a) Buffer overflow vulnerabilities that involve writing or reading more data than a buffer can hold (b) Mistakes, weaknesses, and policy violations in application deployment configuration files like web xml (c) Security violations by checking on dynamic HTML content that includes Java Server Pages (jspx), Javascript (js), Java Server Faces (jsff) files, etc. (d) Time-of-check to time-of-use (TOCTOU) issues that can result in potentially dangerous sequences of operations (e) Vulnerabilities that involve tainted data (user-controlled input) put to potentially dangerous use; for example, issues like injection or cross-site scripting (XSS) (f) De-references of pointer variables that are assigned the null value (g) Dangerous flaws in the structure or definition of the program; for example, violations in secure programming practices such as deprecated code functions, and objects not defined as static or final when required (h) Dangerous uses of functions and APIs at the intra-procedural level; for example, unsafe calls that trigger buffer overflows, format strings, and execution path issues How SCS uses SAST Tools The Security Testing Services (STS) team provides code-scan services using SAST tools for various Oracle SaaS applications. The team helps with analysis of the identified security issues. The team also maintains a repository of scan artifacts in a centralized, role-based access control (RBAC) server for audit and review purposes. During result analysis, a security issue is classified as follows: In addition to running SAST tools, the SCS team works on researching and implementing industry-best practices to reduce false positive issues. The team also trains developers on how to use SAST tools and analyze the results. Development teams that are skilled in using SAST tools can find and fix actual problems faster than teams who must spend additional time in understanding the tool and scraping through false positive results. Millions of lines of code: Automation to the rescue The SCS team builds and deploys SAST automation as part of the Automated SaaS Cloud Security Services (ASCSS) infrastructure at Oracle. We develop this automation to be integrated with existing SaaS applications and upcoming SaaS micro-services.   In Oracle SaaS, we integrate on-demand scan processes with our central build orchestration system. The integrated automation suite triggers scanning jobs on-demand for a given SaaS application such as Oracle Fusion. In addition, for next-generation SaaS micro-services, we added automation into the code scan of a service as part of the Continuous Integration process (see Figure 2).   Figure 2 Example integrated Code Scan report in CI pipeline How do we deal with false positives? Historically, most SAST tools, based on their purpose, generate a lot of false positives. Independent SAST analysis of source code performed by third parties with only indirect knowledge of the specific applications has limited value. Fully leveraging SAST tools require in-depth understanding of how the application is architected and functionally operated in a production environment. Some of the recommended practices to overcome the challenge of false positives is to perform the following tasks: (1) Create custom rules with validations to reduce false positives and apply during the scan time (2) Apply a filter file containing a list of non-issue categories during the scan time (3) Create a set of visibility filters to hide false positives from the audit view While custom rules and scan-time filters remove the issue completely from the scan result file, visibility filters are used to hide the issue from the audit view. SCS follows a set of industry practices for SAST tools to hide the false positive issues while performing the audit for SaaS properties.   Conclusion Application security testing is fundamental to Oracle and all SaaS applications as one of our core DevSecOps principles. It is an engineering area that invokes significant passion and results from security minded engineers. One of the recommended engineering practices is to always have automated SAST testing as a component of the coding phase of a DevSecOps model. The use of SAST by the SCS team is another example of Automated SaaS Cloud Security Services (ASCSS) infrastructure at Oracle. We will continue to provide additional examples of the DevSecOps processes and tools that we use in Oracle SaaS Cloud Security in future blog posts. We welcome your feedback and questions and we will continue to share content and posts based on your requests.    

  For this posting, I would like to introduce my joint guest author Naveen Gupta, who is a Principal Security Engineer in the SaaS Cloud Security (SCS) organization.   Oracle has a long-standing, secure...

Database Security

How much Database Security is Enough? Know where to start

We often talk about the Maximum Security Architecture (MSA), but the reality is that not every database needs that level of protection. I thought it might be worth spending some time on what a baseline security posture for the Oracle Database should include – what the Minimal Security Architecture should be. Once we know the maximum and minimum, then we can think of database security on a sliding scale, with your database’s security controls adjusted to reflect the value of the data contained within the database, and your organization’s willingness to accept risk to that data.                   We like to see these seven simple things that can be done for ANY Oracle database, including Oracle Standard Edition, without any additional-cost licenses.  Adjust your configuration to remove unnecessary risk Apply security patches in a timely manner Practice good password discipline Reduce account privileges wherever possible Know your data Audit security-relevant activity Encrypt database network traffic These seven baseline security practices form the foundation for follow-on security controls that increase the security posture (and decrease risk) all the way up to the Maximum Security Architecture. Without them, adding additional technical controls may improve security, but it will not result in a truly secure system.  Adjust your configuration to remove unnecessary risk. There are hundreds of database parameters, and many of those impact the security posture for the system. Oracle provides the Database Security Assessment Tool (DBSAT) to help you evaluate your configuration and identify settings that may introduce additional risk. DBSAT is simple to download and run, usually producing usable reports within minutes.  If you are running databases in the Oracle Cloud, you can also use Oracle Data Safe (included with your Database as a Service subscription) to perform the same types of checks DBSAT does for on-premises databases. Apply security patches in a timely manner. Oracle releases security patches quarterly. With each release, we also provide guidance on the type of vulnerabilities being mitigated in the patch, the attack vector/complexity, and the severity. The reality is that once we release a patch, it isn’t long before malicious actors begin reverse engineering the patches to learn more about vulnerabilities and how they can be exploited. In some cases, the gap between our release of a patch and the availability of automated exploits can be as little as a few days. As every experienced IT professional knows, patching carries its own operational risk, and it’s always a balancing act between testing patches and applying them quickly. The important thing is to evaluate each patch and make a decision on your timeline for applying the patch. The decades-old DBA mantra of “if it ain’t broke, don’t fix it” doesn’t match up with modern risk evaluation! If you are not already subscribed to receive notifications of new critical patches, you can do so here. Practice good password discipline. This sounds so very basic that you may think it doesn’t need to be said, but having evaluated hundreds of production databases in real customer environments I can tell you that it IS something you should be paying attention to. The temptation to create accounts with passwords that don’t expire, and without those annoying complexity  requirements or limits of failed logins seems to draw people in. Remember that most database breaches involve compromised account credentials, and don’t neglect this most basic of security checks. DBSAT (or Oracle Data Safe if your database is in the Oracle Cloud) will help you here, letting you know which users have non-expiring passwords, passwords without complexity checks, and accounts that don’t automatically lock after a certain number of failed logins. Reduce account privileges whenever possible. Most database breaches involved compromised account credentials (sound familiar?). That means that you want to reduce the damage a compromised account can do whenever possible. This can be something as simple as reporting on the privileges/roles an account has and doing a manual review. If you are running the Enterprise Edition of Oracle Database you can use the Privilege Analysis feature to report on privileges an account uses, as well as privileges an account has that are not being used. Those unused privileges are excellent candidates for elimination. It’s always good to be cautious before removing privileges from a user, so I’ll usually take a two-step approach, running privilege analysis for a few months to identify unused privileges and then auditing the use of those privileges for several more months just to be sure the user doesn’t just use them infrequently. Know your data. Many have said that “data is the new oil” – but all data is not created equally. Some data has a higher value (with attendant higher security risk) than other data. Know what types of sensitive data your database holds, and almost as important, how much of that sensitive data there is. DBSAT can help here, with its sensitive data discovery module.  If you are running databases in the Oracle Cloud, you can also use Oracle Data Safe’s sensitive data discovery module.  The baseline security posture we’re discussing here is appropriate for databases with very low risk, databases that don’t contain a lot of sensitive data. The more sensitive data, and the more value that data holds, the more you should be doing to protect it. The baseline security posture we’re discussing here is appropriate for databases with very low risk, databases that don’t contain a lot of sensitive data. The more sensitive data, and the more value that data holds, the more you should be doing to protect it. Audit security-relevant activity. Just as important as knowing the types and quantity of sensitive data in your database is knowing how that data and your database are being accessed. The Oracle Database has superb auditing capabilities, and we improve them with every release. You should be auditing database login events, changes to user accounts, grants of database privileges, and changes to database schema. You may hear “I can’t enable auditing, the performance impact is too high” – but if you think about the things I’m saying to audit you’ll see that these are low frequency, high value operations. They shouldn’t be happening often in most databases, and therefore the performance impact will be minimal. Without an audit trail, your ability to detect malicious activity is severely compromised, and your ability to support a forensic investigation is almost non-existent. Encrypt database network traffic. Encryption of data in motion is standard now - websites that don't use HTTPS are the exception, not the rule. The same should be true for databases. Enabling encryption in an Oracle Database is as simple as a single line in a configuration file that will enable Oracle Native Network Encryption (NNE).  These seven simple steps establish a reasonable security baseline and are the foundation you can build on as you increase your security posture towards the Maximum Security Architecture. If you’d like to learn more about Oracle Database Security, please take a look at our third edition of “Securing your Database – A Technical Primer”.    

We often talk about the Maximum Security Architecture (MSA), but the reality is that not every database needs that level of protection. I thought it might be worth spending some time on what a...

Cloud Infrastructure Security

Why I Love Working with Data Safe and Oracle Database 20c

One of the great things about providing a cloud service is how easy it is to update the service with new features, and Oracle Data Safe is no exception. For example, this week we've added support for Oracle Database 20c. Since we released the service at OpenWorld San Francisco last year, we’ve seen enormous growth and the customer response has been fantastic. If you are running a database in the Oracle Cloud and aren’t already using Data Safe, you really should try it out – Data Safe is included with all of our in-cloud Database as a Service offerings – including Autonomous Database and Exadata Cloud Service – at no additional cost. But, back to my main topic – the ease of updating a cloud service. Comparing the process for enhancing a product or fixing product issues for a cloud service like Data Safe with the same process for an on-premises product is like night and day. For on-premises products, enhancements are scheduled and rolled into a delivery vehicle – usually quarterly or, if it’s a major enhancement, the upcoming annual release. Depending on where in the development cycle the enhancement request comes in, It can take months or even years to bring a new feature to our customers. And the QA cycles before release are long and complex because Oracle is run in so many different server/operating system environments With Data Safe, we roll out fixes and updates every few weeks – it’s a continuous cycle of improvement. Usually these are small improvements – make something easier to understand, fix a typo in some text on screen, add a new sensitive data format to the over 125 existing formats, or a new masking format capability like group-based masking – we are constantly moving the usability and quality of the service higher. Every now and then, it’s a “hot fix” – we spot an issue that is impacting multiple customers and that needs to jump the normal development sprint cycle. In one recent case a report came in about how we were handling large objects from one customer, was confirmed by another customer about eight hours later, and was fixed – with the fix rolled into production for ALL Data Safe customers – less than a day later. This is what I love about cloud services – how quickly we can fix or improve things, and how confident we can be rolling those changes out since the deployment environment is homogenous and controlled. Some recent examples– Automated registration for Autonomous Databases.  I love the Autonomous Database because it lets me get down to business quickly – I don’t have to worry about setting up encryption, separation of duties, patching – the everyday tedium of securing a database. It’s all done for me. But, because it’s all done for me, setting up monitoring tools like Data Safe used to mean I had to figure out what someone else had done for that automation so I could connect my tools into the system. We had several customers who commented on the difficulty of registering an Autonomous Database with Data Safe, so we created the “Easy Button” – the registration is now automated, with network ingress rules, certificate import, credentialing all handled in the background. And we’re working with the Autonomous Database product managers to make things even easier in upcoming releases. But the point is, this great automation that really made a significant difference in the ease of use for Data Safe happened in just a couple of weeks from identifying the issue. And for our customers, that “Easy Button” just appeared on their Autonomous Database console. Federated Logon support. Our initial release of Data Safe required local accounts. During our testing and limited availability program this didn’t seem like a significant barrier to adoption -but once we had Data Safe generally available we received feedback from several customers that they preferred to only use federated identities, no local logins. Here again, in a few short weeks we had the solution developed, tested, and pushed out to our customers. So one day, the requirement for local logins just went away. Private IP address support. Another project we are working on is removing the requirement for a public IP address. The OCI networking team partnered with us on this to create a new network construct called the “Private Endpoint” that allows our customers to grant direct access to Data Safe without having to route that access through a public IP address.  Limited availability for this has been in progress for a few weeks, and so far everyone loves it. One day soon, our customers will just see this new capability appear for them to use with no need for them to apply a patch, install software, upgrade their hardware. Or, our most recent change – Oracle Database 20c (preview edition on Oracle Cloud released this week). With Data Safe, we are able to support Database 20c on the same day it is released! It just doesn’t get much better than this.

One of the great things about providing a cloud service is how easy it is to update the service with new features, and Oracle Data Safe is no exception. For example, this week we've added support for...

Database Security

Silent Disco? Not Quite, but Looks Like it at OpenWorld

If you’re in San Francisco at OpenWorld and stopped by Moscone South - Esplanade Ballroom, you may have thought you joined a silent disco.  No, nobody was dancing to silent music through those multi-colored headsets.  Instead, OpenWorld San Francisco appears to have embraced a new trend in conferences, with open-air presentation rooms and attendees listening to the sessions via headsets. I’m looking forward to our session on Wednesday, when I have the honor to present with Bill Kleyman from Switch, Simon Pane from Pythian, and Hamid Habet from Allianz to present about Oracle Autonomous Database security.  There have been some great announcements already from Larry Ellison and our latest press release.  Join us in our session as we unpack more about the announcements, the latest security updates to Autonomous Database security and hear directly from Allianz and Pythian about their experiences with Data Safe today!  And, if we’re lucky, maybe we’ll have some disco music too.  See you Wednesday at the session: Mitigating Risk with Oracle Autonomous Database [PRO4944] Wednesday, September 18, 04:45 PM - 05:30 PM Moscone South (Esplanade Ballroom) –   156C

If you’re in San Francisco at OpenWorld and stopped by Moscone South - Esplanade Ballroom, you may have thought you joined a silent disco.  No, nobody was dancing to silent music through those...


Oracle OpenWorld 19 Daily Report - Tuesday

Hello OpenWorld attendees! I'm writing from the field of Oracle Park with a front row view of Mission: Impossible Fallout! What an exciting event enjoying movie snacks and good company. I hope everyone had an exciting start to OpenWorld and perhaps a few of you reading this were out watching the movie with me. Don't forget to join FitFest.19 this morning to work off the pretzels and popcorn! Tuesday is full of exciting sessions you won't want to miss, but first, I wanted to point out a few of the key announcements and sessions from today! With so much going on at OpenWorld, we know it isn't possible to catch every session, so visit us here each morning for a little recap of the night before and a few key to dos for the day. A few recaps from the day: Announcing Oracle Data Safe Today was an exciting day for Oracle Database Security, the week kicked off with several sessions including Vipin Samar's session, Database Security in 2019: The Innovation Rate Accelerates where Vipin shared that data breaches are up 54% in 2019. Attacks are more pervasive than ever and over 107 countries have now implemented data privacy laws. Oracle is happy to announce Oracle Data Safe.Product Manager, Bettina Schaeumer gave us a first look at Data Safe and there is more to come. Join the Oracle Database team for their Hands-on Labs to get a first look at product hands on and join Michael Mesaros, Director, Database Security Product Management, on Thursday from 9am-9:45am in Moscone South (Espalande Ballroom) Room 155B. The session, Oracle Data Safe: Securing Databases in Oracle Cloud, covers the exciting new cloud service, which provides you with a single pane of glass to assess configuration risk and evaluate database users. We Learned That Security Can Be an Enabler to the Cloud Vice President of Product Marketing for Security, Fred Kost, sat down with a panel of customers and security professionals to hear their perspectives on moving to the cloud securely. It was a great conversation covering what it takes for organizations to move to the cloud, including getting key stakeholders to buy in, considering your compliance needs early, and dreaming big about the possibilities you have in the cloud. The participants in the panel suggested the importance of understanding the shared responsibility model, setting expectations with your cloud provider, and understand your compliance needs across your multi cloud environment. Oracle Cloud Infrastructure Gen2: Stronger Than Ever "It isn't about whether the cloud is secure….it's about how securely you are using it" Laurent Gil, Product Strategy Architect for OCI Development,. A variety of sessions covered the great work customers have been doing with the Oracle Cloud Infrastructure, as innovations continue to be made in industries around the world, Oracle continues to invest money and resources in the best and brightest personnel for the Oracle Cloud Infrastructure. Access our blog covering some of the new announcements for OCI and Oracle Security's press release. Don't miss for Tuesday: Oracle Cloud: A Path and Platform Tuesday,11:15am-12:00pm | YBCA Theater Cloud technologies are beginning to reshape how we think about and interact with the world around us. The opportunities that the cloud presents are real and present today, and they are providing the building blocks for companies to pioneer groundbreaking innovations and disrupt entire industries. Today, we’re seeing emerging technologies and automation permeate every aspect of work and life. The real opportunity of these technologies—which include AI, machine learning, IoT, blockchain, containers and serverless, and human interfaces—is to embrace these technologies on a scale we’ve never before. In this session learn how Oracle Cloud drives new innovation and real change for customers. Securing Business Critical Cloud Workloads: Threats, Implications, and Outcomes Tuesday, 3:15pm - 4pm | Moscone South - Room 209 The next security threat may be something that we have not yet imagined or even considered as a possibility. Beyond attacks against corporations and elections, what other threats exist from nation states, rogue actors, cybercriminals, and others that may threaten our institutions, economy, or way of living? In this session learn about the next security threat and how the direction of technology and the adoption of cloud computing, AI/ML, and other technologies might aid both defenders and attackers. Get a look from the perspective of cloud security and see what’s needed from cloud platforms and security services to protect business-critical workloads and applications as they migrate to cloud platforms. Looking forward to seeing you there! 

Hello OpenWorld attendees! I'm writing from the field of Oracle Park with a front row view of Mission: Impossible Fallout! What an exciting event enjoying movie snacks and good company. I hope...