X

Cloud Security Perspectives and Insights

How Threat Intelligence Complements Security Controls in Oracle SaaS Cloud

David B. Cross
SVP SaaS Security

For this posting, I have a contributing guest author Alida Wilms, who is a Senior Principal Technical Writer in the Oracle SaaS Cloud Security (SCS) organization.

In general, when leaders complete competitive analysis and business intelligence, their conclusions and actions depend on the comprehensiveness and quality of the data that they collect. Similarly, when security professionals look at how to protect their organization’s data, the security controls that they put in place also depend on the comprehensiveness and quality of the security-related data that they collect. This is where threat intelligence provides value: as a source of data in the buildout, deployment, and monitoring of security controls. In this blog, we will describe threat intelligence, its uses during the DevSecOps cycle, and how SaaS Cloud Security applies the threat intelligence lifecycle in its operations.

Introducing Threat Intelligence
Threat intelligence (TI) is information that a security team can use to take action against a threat. Good TI provides context so that a team can accurately protect against an identified threat. Context ensures that the team knows the what, when, where, how, and why of the supplied intelligence.

Threat intelligence often comes from a variety of internal and external third-party sources which may be purchased on demand from TI suppliers. Most security teams, like Oracle SaaS Cloud Security (SCS), use standards and automation to rapidly analyze, correlate, and validate TI feeds. Without automation and deduplication, organizations would find it nearly impossible to productively consume and act on TI feeds in a timely manner. In SCS, we consume and correlate both internal, as well as external, TI feeds in our TI program.

TI is very important when a security bug or issue is discovered in a product or service. TI helps inform decisions such as when to fix an issue, how critical the deployment timing is, and what additional controls may be needed.

The Principles of Threat Intelligence
One of the best ways to understand the value of threat intelligence is to examine three commonly accepted principles of threat intelligence in a computing environment:

1) Evidence-based knowledge: Good threat intelligence is not individual opinions or intuitions. It is based on information that has been purposefully collected and curated to provide factual details on specific events, activities, and behaviors.
2) Asset risk: Threat intelligence should always be correlated with an existing or emerging risk to the assets that you are protecting. For example, TI can point to a potential security event that is related to the theft of high-value data or an existing threat to the availability of critical resources.
3) Actionable: Threat intelligence must be aligned with processes, people, and tools to analyze the threat and to link the information with specific actions that can block, prevent, or mitigate the threat. For example, when a SQL Injection (SQLI) attack occurs, a security response team can introduce a blocking signature in the Web Application Firewall (WAF) or perform a code change and patch a vulnerability.

Threat Intelligence and DevSecOps
Threat intelligence is primarily used by security teams, whether pen testers, security incident responders, or security architects, to defend and mitigate against emerging threats during the operate and monitor phases of the DevSecOps cycle. It’s also a valuable source of information for many roles in a DevSecOps culture and engineering model.

For example, developers and testers can use threat intelligence in the early planning phase to ensure that they can holistically compose threat models and complete security architecture reviews based on the environment and threats that their software might be vulnerable to. In addition, in the build and test phases, they need to make sure their software does not unnecessarily expose the product to other potential attacks or emerging risks. Often, DevSecOps engineers use TI to not only block a potential attack, but also to monitor for attacks.

For security teams, TI is valuable to have in the planning phase as TI enables them to build and implement proactive responses as opposed to focusing on reactive remediations.

TI is a natural complement and source of input to the Architectural Risk Analysis (ARA) that is commonly performed in the code (design) phase of DevSecOps.

Figure 1: Threat Intelligence in a DevSecOps model.

Also, Security Operations Center (SOC) Monitoring can be a source for TI. It allows security teams to gather information about attacks and react quickly to changing tactics.

Support teams also need threat intelligence so that they can properly assess and escalate customer service requests.

Threat Intelligence Goals for Oracle SaaS Cloud Security
Over the past few years, the SCS organization has significantly advanced and matured our threat intelligence program so that we can align with the rapid adoption and growth of cloud-based SaaS applications. At a high-level, the SCS organization has three sustaining TI goals:

1) Ensure we can accurately and consistently identify and assess threats against Oracle SaaS.

2) Adjust the prioritization of security DevSecOps engineering activities and projects based on findings from our threat intelligence program. 

3) Collaborate and share our feeds, analysis, and insights with other security lines of business inside Oracle.

Threat Intelligence Lifecycle
It is not well-known outside of the security community, but threat intelligence has a lifecycle. It is a continuous lifecycle, just like DevSecOps, that adapts and improves over time based on results.

                                                         

Figure 2 Threat Intelligence Lifecycle.

Planning: The threat intelligence lifecycle that SCS uses starts with planning. During this phase, we identify potential TI gaps that may exist and also align our needs with the overall DevSecOps product goals across the broader SaaS Engineering lines of business. TI can often provide a mitigation when auditing or monitoring gaps exist in a given component or service. This mitigation can be more attractive than unnecessarily overloading a system with expensive audit logging functions. The SCS organization performs and completes threat modeling exercises for all SaaS properties. These exercises are open discussions with the SaaS DevSecOps teams to systematically identify potential risks to the product, by examining risks at strategic, operational, and tactical levels.

Collection: After the project goals have been defined, we procure the latest information from both internal and external sources as well as from various partnerships (see Threat Intelligence Sources below).

Processing: Next, we categorize, organize, and filter the information that we have collected, based on our objectives. We explicitly score and prioritize the data and develop appropriate techniques on how it may be monitored or detected using our SIEM and alerting technologies.

Analysis: After processing, we analyze the information and how a particular threat might potentially impact our environment. This analysis can include threat-hunting activities, which are the proactive search for signs of active or historical malicious activity in our infrastructure or applications. SCS uses both structured and unstructured threat-hunting approaches. Structured threat hunting is when we determine what we want to look for and then detect if it is in place. Unstructured threat hunting is dependent on reviewing raw threat intelligence and signals to identify anomalies that may not have been detected in the past.

Dissemination: After analysis, we share the intelligence that we found with various security and DevSecOps organizations in Oracle for further correlation, reporting, and analysis.

Feedback: During this step in the continuous cycle, we collect and incorporate feedback from all stakeholders and incorporate these insights into the next planning cycle.

Threat Intelligence Sources

The SCS organization uses threat intelligence feeds from multiple sources including, but not limited to:

- Open source intelligence sources, which includes information from media, internet, public government data, SANS, CERTand so on. This also includes web scraping and URL scanning tools, or malware-finding tools such as abuse.ch.
- Commercial feeds and subscriptions.
- Ethical hacking and Red Team activities.
- Other Oracle teams, which includes Global Information Security (GIS), other security teams, and our own SaaS Cloud Security Detection and Response Team (DART) team.

Conclusion
Because threat intelligence is always in context, security incident responders can use it to better understand an incident, complete forensic analysis, and ensure adequate mitigation controls are in place. For the best results, threat intelligence requires both highly-skilled security personnel and automation working together in order to be most effective.

In Oracle SaaS, the SCS organization uses the threat intelligence program results, insights, and analysis to maximize benefits and protection for all SaaS customers. As shared above, there are numerous ways to incorporate threat intelligence into the DevSecOps phases – everything from design plans to vulnerability and patch management during configuration and system management cycles.

And, of course, threat intelligence is incorporated and used in the Oracle security incident response program. We value your feedback so we can continue to share our stories and insights with the broader SaaS cloud security community.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.