Threat Intelligence Sharing with Tines.io

March 15, 2019 in Blog

This is the first blog in a series looking at how companies are consuming and sharing threat intelligence using Security Orchestration and Automation platforms like Tines.io.

In this blog we discuss the process of sharing individual indicators of compromise (IOCs) using tines.io. With Tines it’s easy to share IOCs to common Threat Intelligence platforms like AlienVault, Trustar, Facebook Threat Exchange and PassiveTotal as well as automating sharing IOCs on Pastebin and submitting content to VirusTotal, urlscan.io and Phishtank.

Most information security teams have dozens of security tools, and with dozens of threat intelligence platforms available [0] it’s hard to know which one suits your company best. Unfortunately it’s not always clear which Threat Intelligence tools integrate with other tools in your security stack. Furthermore, it’s important to know which tools your peers and partners are using to share relevant threat intelligence for you can consume. Consequently, the best advice centers around using platforms which are used by your peers. Hence, platforms which have a Rest API for easy sharing, classification and integrations usually have the most use and highest quality indicators. It’s also important to investigate threat intelligence platforms which can link with your SIEM, Endpoint Tools, Firewalls etc. These links can help your security teams detect and block malicious attacks.

Features of Good Threat Intel Platforms

In order for any platform to be successful security teams and analysts must be comfortable using them frequently to keep indicators up to date. Likewise, they require participation and active sharing of threat intelligence by other security teams, either publicly by security vendors or altruistic companies, or privately by ISACs or industry groups, when they come across it.

One of the advantages of the tines.io security automation platform is we don’t rely on any pre-built integrations. Consequently, consuming and sharing to a new threat intelligence source or feed is as simple as signing up for an account, creating an API key, or sending an email. Therefore there’s no need to wait for your SOAR vendor to build an integration or to build one yourself.

This blog discusses how you can use tines.io to automate the sharing of malicious IOCs of your own to multiple threat intelligence platforms.

How to Share Indicators in Tines

Tines provides pre-built stories for security teams to help them automate threat intelligence sharing. In contrast to one-off scripts, using Tines can automate the sharing of indicators with not one but dozens of Threat Intelligence platforms at the same time. We can also easily add other platforms without the need for additional coding or development. The below Story shows just how easy it is to share Threat Intelligence Automatically to a handful of different threat intelligence sources:

  • AlienVault
  • Trustar
  • Phishtank
  • URLScan.io
  • VirusTotal
  • Pastebin
  • Facebook Threat Exchange
  • RiskIQ PassiveTotal

In the example below we have created a Story “Share Indicators of Compromise” and an agent called “IOCs Webhook”. To start this story we’re sending the webhook an event with a malicious URL, along with an indicator type, indicator group, name and a tag. To read more about how to create a Story in Tines click here. In addition, you can download the Story below and upload it to your own trial tenant.

You can generate data in your own webhook via a form or using a simple curl command like below:

Subsequently, your webhook will receive the below event:

AlienVault OTX – Creating Pulses

AlienVault is one of the largest online threat intelligence platforms with over 65,000 participants who contribute more than 14 million threat indicators daily. Data in Alienvault is shared through “Pulses”. Pulses provide a summary of the threat and group related indicators of compromise (IOC) together.

You can create a pulse in AlienVault with a simple curl request:

Similarly, to create a pulse using Tines with the data sent to the webhook, you can create a HTTP Post Agent. When we add the webhook as an “Event Source” this agent receives the event emitted by the webhook agent, and can read the event’s parameters and be referenced using the json path of those paramaters. For example, adding {{.iocs_webhook.ioc}} to the HTTP post agent will send through the URL in the image above in the “name” parameter of the payload. Similarly, {{.iocs_webhook.ioc_type}} will pass through the type above, “url” as the indicator type to AlienVault. This agent then sends the relevant information to AlienVault:

This simple request automatically creates a Pulse in AlienVault OTX. This pulse is public and contains all the information we originally sent to the webhook above:

A pulse created using tines.io

You can augment the above query to send pulses with hundreds of IOCs or update a pulse with more information using a “Patch” command.

For a full list of ways to submit data to AlienVault OTX you can read their full documentation here.

Trustar – Sharing IOCs to an Enclave

Trustar is a another threat intelligence platform popular among “Information Sharing and Analysis Centers” (ISACs) like IT-ISAC or H-ISAC (Health-ISAC). They provide closed-source feeds from entities like Abuse.ch, DHS CISCP, US-Cert, Malware Traffic Analysis and others that can be integrated into your SIEM, Splunk, Endpoint tools etc.

To submit to IT ISAC you need an Enclave ID to which you have “Full Access” and then include that in your request. You’ll also need to login or create an OAuth2.0 App to get a Bearer token which is included in your request, as below.

Once you have a bearer token, you share data with Trustar using curl:

In Tines, a HTTP Request Agent is used to make a Post request to the Trustar API. Similar to the AlienVault agent we are sending Trustar data that was sent to the webhook above:

When Tines runs this agent, the relevant indicator is shared to Trustar. Because we chose an ISAC enclaveID, this indicator has been shared with our partners in the relevant ISAC. We could also share the indicator in our own private enclave.

An indicator shared in a Trustar Enclave

You can also update indicators, delete indicators, share contextual information and more using the Trustar API in Tines. For a full list of ways to submit data to Trustar you can read their full documentation here.

Phishtank – Submitting Phish

Phishtank is a large, collaborative, public repository of online phishing websites managed by OpenDNS.

In contrast to AlienVault and Trustar, Phishtank to not have an API for submitting malicious URLs. They do, however, provide a mechanism submit URLs via email directly. When you create a Phistank account you receive a private submission email address:

In Tines we can create an email agent to submit the malicious URL as part of the email body:

The configuration for an Email Agent to submit data to phishtank

Phishtank is smart enough to extract URL, scan it, and allow community voting on whether or not it is malicious:

A phish submitted by Tines in Phishtank

To read more about reporting Phish to Phishtank click here.

Urlscan – Sharing URLs

Urlscan.io is a free online service which scans and analyse websites. Due to its widespread use and quality of the data it is becoming one of the most popular threat intelligence platforms. Urlscan has an easy to use Rest API, and submitting URLs for scanning is straight forward. To get started you need to sign up for a free account and request an API Key here.

Using Curl you can submit a URL for public sharing and analysis using the below command:

Similarly, the sample agent configuration for submitting to urlscan.io is straight forward:

This will publicly submit the URL we sent to the webhook to urlscan.io:

For a full list of Urlscan.io API commands and documentation click here.

VirusTotal – Sharing IOCs

Similar to Urlscan.io, VirusTotal is another one of the most popular threat intelligence platforms for sharing intelligence publicly. All urls submitted publicly are shared and analyzed by up to 60 different anti-virus engines. They are given an aggregate score based on the number who detect the URL as malicious.

Through Tines it’s simple to integrate with the VirusTotal API as outlined previously here. To submit a URL to VirusTotal using curl you can use the below command:

We can use a HTTP Request Agent to submit a Get request with the URL in the same way:

Submitting to VirusTotal allows over 60 different anti-virus companies to scan the page.

To read more about the VirusTotal API click here.

Pastebin – Creating Pastes

For large scale malware and phishing campaigns, several threat intelligence and malware researchers share indicators on the Pastebin platform. For instance, researchers frequently share indicators from Hancitor, Trickbot, Emotet, Ursnif and others campaigns for security teams to analyze and track.

Automating the sharing of indicators to Pastebin is free and easy. Once you sign up for pastebin account you should generate a “userkey”. You can do this with your username, password and API Developer Key which is available in the API Documentation. Pastebin have created an easy form to generate the userkey here.

After generating the userkey, you can create a paste using curl by copying the below command:

Similarly, using the API Developer Key and Userkey, you can create a HTTP Request Agent to create a Paste on Pastebin using Tines:

This will result in a public paste with the Indicator and some context:

You can read more about the Pastebin API here.

Facebook Threat Exchange – Creating Indicators

Facebook Threat Exchange is a private threat intelligence api for security professionals to share threat intelligence more easily, learn from each other’s discoveries, and make their own systems safer. It is built on Facebook Graph, and has over 800 members who share and submit indicators publicly and privately.

Unsurprisingly, submitting indicators to threat exchange is easy using the Facebook Graph API:

Likewise, to share inidcators in Facebook Threat Exchange through Tines we can create a HTTP Request Agent with the below configuration:

This will then submit the content publicly to Facebook Threat Exchange:

With Facebook Threat Exchange it’s also possible to submit privately, or submit to specific industry sharing groups you’ve created. Furthermore, if you make a mistake you can easily update the indicator and mark it as non-malicious.

For a full list of ways to interact with Facebook Threat Exchange you can read their documentation here.

RiskIQ PassiveTotal – Creating Artifacts

RiskIQ PassiveTotal is another popular threat intelligence platform which has integrations with Splunk, QRadar, McAfee SIEM, Check Point Firewalls and dozens of other security tools. By sharing with RiskIQ you can often integrate directly into your own tools, in addition to helping the RiskIQ security community.

Before submitting any data to RiskIQ you have to create a Project, however this can be done using the UI, or using the API. An agent to create a public project using the RiskIQ API is included in the downloadable Story. Once you have created a project you can easily add IOCs to that project using the curl command below.

In Tines, we can create a HTTP request agent to do the same thing, however as PassiveTotal relies on domain intelligence rather than URL intelligence we first use a Tines Event Transformation agent to extract the associated domain. This agent configuration is also included in the downloadable Story. Once the domain has been extracted it’s easy to share the URL in PassiveTotal using a HTTP Request Agent:

This will create an IOC in the associated RiskIQ Project

You can read more about the PassiveTotal API here.

Conclusion

Using Tines it’s easy to automate the sharing of indicators to dozens of threat intelligence platforms in addition to the above eight. To download this story for your own Tines tenant to see how easy it is for yourself, please click here. The completed story looks like this:

To learn more about how to integrate your environment with any Threat Intelligence platforms you can start a free trial, or contact us hello@tines.io

Sources:

[0] Cyberscape Threat Landscape https://momentumcyber.com/docs/CYBERscape.pdf

Phishing Automation: Automating URL Analysis with Phish.ai and Tines.io

March 5, 2019 in Blog

A partner blog between Phish.ai and Tines.io

According to the latest Verizon Data Breach report Phishing is involved in 93% of breaches and email continues to be the most common vector (96%) in successful cyber attacks [0]. These figures indicate that malicious email detection software and employee security awareness training are no longer sufficient on their own to deal with the volume of attacks, even at a small scale. In addition, the process to review suspicious emails and examine suspicious URLs is both time consuming and error prone. Furthermore is one of the most frequent causes of alert overload and analyst fatigue. Phishing Automation using SOAR platforms like Tines and Phishing analysis tools like phish.ai helps companies tackle these problems.

In a world where detecting and responding to incidents quickly is a key metric for any security program, automating the collection and analysis of suspicious URLs can reduce mistakes and improve response times. Above all, it will make your analysts more efficient, effective and happier.

What steps should I take to automate the analysis of suspicious URLs?

The first step in building out automation is to identify sources for collecting suspicious URLs for your environment. Common sources of malicious URLs include:

  • Customer Abuse boxes (You can read more about using Tines to manage your Abuse Inbox here)
  • URLs blocked by your email security solution like Proofpoint, FireEye ETP, Barracuda, Mimecast or Microsoft APT.
  • DMARC failures or rejects
  • Suspicious uncategorized or punycode URLs from your firewall logs or DNS logs
  • New SSL Certificates registered with domains similar to your brand (e.g. from crt.sh)
  • Threat Intel sources like the Phish.ai threat intel feed which generates feeds based on the brands attacked
  • Free feeds of malicious urls like Phishtank, Openphish, phishstats.info or Urlhaus. Note, these feeds are often are high-reputation so don’t necessarily need to be further analyzed.

Using Tines’ Phishing Story it’s easy to collect suspicious urls from over a dozen of different sources automatically. Once these feeds are in Tines it’s easy to deduplicate and classify urls to prevent alert overload and to generate more accurate metrics.

Once Tines has deduplicated the URL feed, it’s time to perform a real-time URL analysis using a tool like phish.ai.

Phish.ai is a premium service which proactively indexes websites of top brands around the world to create an up-to-date computer vision database. Phish.ai’s real-time web crawler will index all URLs submitted and compare the site image against the known bad database. (Note, to submit privately you’ll need to sign up for a basic plan. Basic plans allows scanning of up to 10,000 URLs each month).

Integrating Phish.ai with Tines in your phishing automation process

With Tines it’s simple to make a single API call to submit these URLs for analysis using Phish.ai’s API. The configuration to make these calls in Tines is below, using a “HTTP Post Request Agent”. In this example, {{.explode_urls-array.url}} represents the url to be sent for analysis. Moreover this can be done in a totally secure manner. The parameter {% credential phish_ai %} is the phish.ai API key which is encrypted and sent along with the request.

A HTTP Request Agent configuration to submit urls to phish.ai

This request returns a unique “scan_id” parameter:

The event response information from a phish.ai scan

In the next step, Tines sends this parameter to phish.ai to retrieve the results of the analysis. Similar to the request above, a HTTP Request Agent is used.

Another HTTP Request Agent configuration to retreive the results of phish.ai scan

This call returns the results of the analysis by phish.ai:

The results returned by phish.ai

In the background, phish.ai has compared the image of the crawled page against its collection of known bad images. Subsequently, phish.ai has correctly detected that this particular site submitted through Tines is a phishing website. In the event emitted above, not only has phish.ai has successfully identified the site as malicious, it has also identified the target as “National Bank”. Importantly, this information can also be used to help analysts decide on the priority of an incident. For example, this information can help analysts identify more targeted attacks or phishing using brands used by employees.

Analysts can also use the phish.ai dashboard to view more information about the detection or a screenshot of the phishing page.

The phish.ai Dashboard UI

What’s Next?

Once your phishing automation process has completed analysis of the phishing URL it’s possible to automate dozens of other interactions in Tines.io. For instance, traditional next steps include scanning for any traffic to the identified malicious in firewall logs and endpoint logs etc.; blocking the domain; removing the particular email from inboxes; performing a header analysis etc. Other companies also use Tines to respond to reporters confirming a site is malicious. Another popular use case is to use phish.ai’s threat feeds in combination with other public and private feeds to detect brand abuse and send takedown notices to hosts requesting they remove the infringing content.

An excerpt from the Tines Phishing Automation Story

In conclusion, Phishing Automation using a security automation platform like Tines in combination with a real-time phishing analysis platform like Phish.ai, can help your security team scale and keep your analysts focused on more impactful efforts, leaving them happier.

You can read more about this step in the process in part three of our “automating your abuse inbox” blog series.


To date Phish.ai has scanned over 21 million URLs and identified over 85,000 zero day phishing attacks.  You can read more about the Phish.ai api here.

Tines.io is an Security Orchestration, Automation and Response (SOAR) platform used by Fortune 10 companies, global banks and large public and private SaaS companies.

[0] Verizon Data Breach Investigations Report 2018


Security Automation: Getting Started

February 20, 2019 in Blog

What Should I Automate First?

In Tines we pride ourselves on having developed a Security Orchestration Automation and Response platform that’s easy for any analyst to use, even with no coding experience, and which operates with every API using Direct Integration. We also assign every new customer a dedicated Customer Success Representative to provide Security Automation training for your team.

Not all SOAR platform deployments are a success, however, as without help or training, engineers and analysts can get stuck developing over-complicated response stories. Other teams find their SOAR platform can lack the pre-built integrations necessary to make their implementation successful. Even more teams just don’t know where to get started.

The question needs to be asked- if you’re trialing a Security Automation platform, what should you automate first?

Where are you spending your time?

The quickest way to decide what to automate first is to ask your analysts what tasks they’re spending the most time on. With 79% of security teams overwhelmed by the number of security alerts [0] we predict you’ll hear about the challenges of time-consuming investigations involving dozens of manual steps and where a high percentage of incidents are false positives.

The most frequent answers to this question that we hear are:

  • Processing employee or customer Abuse Inbox reports
  • Running, and analyzing the results of, vulnerability scans
  • Triaging low level security incidents like adware
  • Gathering contextual information for alerts for noisy detections like
    • Data Loss Prevention alerts
    • Live off the land tool use
    • Suspicious login events
    • Brute force access attempts etc.
  • On-boarding and off-boarding users
  • Processing ticket escalations from VIPs
  • Standardizing or synchronizing ticket information in Case Management Systems
  • Reviewing phishing page visits or CEO Fraud
  • Writing incident notes and shift handovers

While none of these tasks are particularly complex, they all have several things in common – they’re frequent, they’re time-consuming and they’re not interesting cases for your analysts and engineers. Above all, security professionals have known for years what steps should be taken to investigate them, but until now they weren’t able to automate those steps.

Using the Tines Security Orchestration and Automation Platform there are a few immediate use cases teams can automate to take the pain out of dealing with these common incidents.

1. Deduplicate Alerts

Alerts are noisy, and even with the best tuning your teams may still see the same alert pop up over and over again causing alert overload. It could be an alert for Powershell encoded command use by a user in Product Operations, a payroll analyst sending bank account details to an external email address, or a Business Intelligence team member exporting a large number of rows from a CRM tool triggering a DLP event. These incidents are easy to handle but still take time to review. With Security Automation platforms like Tines, it’s simple for analysts to create Stories to deduplicate incidents against multiple fields.

In the example below, we deduplicate alerts using an “Event Transformation Agent” in Tines on the fields “Hostname” and “IOC Value” emitted from the “explode EDR alerts array” agent. This deduplication flow means the same indicator won’t alert on the same machine twice. Using a security automation platform to automate these steps helps minimize alert overload and, above all, help keep your analysts focused on higher impact engineering efforts.

Security Automation Agent Configuration
An Event Transformation Agent set up to Deduplicate alerts

2. Enrich & Provide Context

Reducing the mean time to action an alert is a key metric for any security team. Additional context helps analysts determine whether the incident is truly bad, a false positive, or something in between. For example, enriching suspicious login events with threat intelligence, researching when a domain was registered, running malware in a sandbox for additional analysis or performing real-time analysis on a URL are all actions that can be automated with Security Automation platforms like Tines and included up-front in an incident ticket.

Security Automation Workflow Diagram
An adware story in Tines

A good example of a simple enrichment flow that can be automated immediately is a suspicious binary download detected by your Anti Virus, Firewall or EDR tool. With Tines it’s very simple for analysts to create a flow to first deduplicate and then enrich detections with binary information (from VirusTotal or elsewhere) to see exactly how dangerous the binary is and to take workload off analysts if they’re classified as Unwanted or Adware. If the binary is classified as adware then Tines can automatically send the incident details to IT for remediation. Using this method we have seen analysts, with no coding background, automate a process in just a few hours that immediately freed up 10-20% of their time.

3. Correlate Alerts

Differentiating between legitimate and illegitimate detections for commonly used tools can be both hard and time consuming. Alerts for a macro being run in Office, PII being downloaded from a CRM or BI system or Powershell being used can differ dramatically in severity based on who the user is, but writing hard rules for this is difficult. Often the first thing an analyst does when investigating an alert is search in internal tools for additional context:

  • Who owns an asset
  • what’s their job title
  • where are they based
  • how long have they been with the company
  • has this user done anything like this before
  • have we seen an alert on this device recently

With Tines it’s possible to include this information directly in an alert ticket by correlating alert information with particulars found in other tools. By giving this information to your analysts you empower them to quickly make a decision on an incident.

Using a SOAR platform like Tines to enrich AntiVirus, EDR, DLP, firewall, and other alerts with asset owner information, user role, user location, and correlating with previous alerts (for example, has an alert fired for this hostname in the past 24 hours) can reduce the time needed for analyst to triage and make a determination on the severity of an incident. In addition, automating the process reduces the chances of responders making simple mistakes during the investigation.

4. Supercharge Responses with Prompts

Once responders have enough information to triage an incident the next steps are to contain, eradicate and recover. This remediation can involve dozens of different individual steps for an analyst, but for many incidents there are a few common steps that can be automated using a SOAR platform like Tines – isolating machines, blocking domains, resetting passwords, sending a machine for forensics, replying to an end-user’s email etc.

Security Automation Prompts
Prompt Actions within a ticket allowing analysts to instantly isolate a machine or lock an account

With Tines’ “Prompts” feature we enable responders to automatically take an action in any workflow by simply clicking a link. These Prompts can be launched from anywhere, for example in an incident ticket, in a text or email, in Slack etc. They allow analysts take the next step in an investigation without opening up different tools, contacting other teams, or leaving their environment. When a responder clicks a “Prompt” this re-releases an event in Tines and sends it down a new remediation workflow. These prompts super-charge analysts responses.

5. Crowdsource Suspicious Activity

With an ever increasing number of security tools, new attacks and alerts it’s hard to quickly respond to every incident. To combat this, many teams begin turning off noisier or lower-fidelity detections regardless of how useful they might be. Using Security Orchestration and Automation platforms like Tines it’s possible instead to “crowdsource” noisy alerts and activity.

A crowdsourced security automation alert
A crowdsourced suspicious VPN login alert

For example, as a small security team (or small company) with just a few security tools it’s possible to investigate every suspicious VPN login, or contact every new user provisioned export rights or admin rights. As the team expands and builds out higher-fidelity detections, however, these alerts become noisier and the ratio of true to false positive means it’s not practicable to follow up every one. Instead of turning off these alerts Tines takes these incidents, enriches them, and allows users themselves detect potentially malicious activity.

Examples of crowdsourced reports include users:

  • logging in from a new location for the first time
  • provisioned new access rights
  • downloading large amounts of PII
  • requesting a new VPN token
  • changing payment details in their Payroll
  • visiting suspicious websites
  • uploading or downloading a large number of files

By crowdsourcing these alerts, Tines customers can quickly find true-positives among the noise.

Have a question on how you can automate your own security workflows? Contact us here or sign up for a free trial!

[0] https://www.enterprisemanagement.com/research/asset.php/3441/InfoBrief:-A-Day-in-the-Life-of-a-Cyber-Security-Pro

Storing G Suite logs in ELK

January 17, 2019 in Blog

As businesses of all sizes continue to embrace G Suite, security teams’ ability to detect and respond to malicious activity in G Suite tenant is more important than ever. Thankfully, Google provides admins with comprehensive reporting and logging which security teams can interrogate to detect suspicious behaviour. However, moving these logs from G Suite to a centralised logging environment (e.g.: a SIEM) often requires a software engineering project. In this post, we’ll explore how Tines can be used to take logs from G Suite and forward them to ELK (Elasticsearch, Logstash, Kibana) for analysis and alerting.

Prerequisites

To follow along, you’ll need the following:

  • A Tines tenant (free trial available here)
  • An G Suite admin account
  • An ELK stack with a Logstash HTTP Input configured to send logs to Elasticsearch

What logging is available in G Suite?

From the G Suite Reports portal, admins can view and search logs related to the following activity in a G Suite account.

  • Admin actions
  • Logins
  • SAML
  • LDAP
  • Calendar
  • Token
  • Groups
  • Hangouts Chat
  • Google+
  • Hangouts Meet
  • User Accounts
  • Email Log Search

G Suite report logs

Enabling the G Suite Admin SDK API

All the information available in the reports portal is also available via APIs in the G Suite Admin SDK. To begin, we need to enable the Admin SDK APIs. From console.cloud.google.com choose “APIs & Services”, “Library”.APIs and Services

Next, search for “Admin SDK” and press “Enable”.

Creating a Service Account

  1. In the top-left corner of the GCP console, click Menu.
  2. Click IAM & Admin > Service accounts.
  3. Click Create Service Account and in the Service account name field, enter a name for the service account.
  4. (Optional) Enter a description of the service account.
  5. Click Create.
  6. (Optional) Assign the role of Project viewer to the new account.
  7. Click Continue > Create Key.
  8. Ensure the key type is set to JSON and click Create. You’ll see a message that the service account JSON file has been downloaded to your computer.
  9. Make a note of the location and name of this file.
  10. Click Close > Done.

Adding the service account to G Suite

  1. Go to your G Suite domain’s Admin console.
  2. Click Security.
  3. Click Advanced settings.
  4. From the Authentication section, click Manage API client access.
  5. Open the JSON key file downloaded in step 8 above.
  6. In the Client Name field, enter the Client ID for the service account. This can be taken from the JSON key file.
  7. In the One or More API Scopes field, enter the list of scopes that your application should be granted access to. In our case, we need the following to access the reports API:
  8. Click Authorize.

Creating the Tines credential

Finally, we’ll create a corresponding credential so Tines can authenticate to G Suite, we’ll use a JWT-type credential. For detailed instructions on how to use JWTs with G Suite, see here. The payload for the JWT will resemble the following:

Building the automation story

Now that we’ve laid the necessary groundwork, we can start to build the automation story. To get started, we’ll use a HTTP Request Agent to get an authentication token which we’ll use to fetch the logs. The options block for this agent is shown below:

With the authentication token emitted by this agent, we can now use it to fetch the report data. We’ll use an example of how to fetch Login Activity Reports. The options block for this HTTP Request agent is shown below. In this example, we’re fetching all logins since January 1st, 2019, of course we could also use the now and minus liquid filters to fetch logs in the last 24 hours, 5 minutes, etc.

An event emitted by the above agent is shown below. We can see the event contains an array called “items” which contains all the login occurrences in the G Suite tenant.

Sample G Suite Login Event from Tines

For ease of downstream analysis, we’d like every individual event to be an individual log in ELK. Therefore, before pushing the events to Logstash, we’ll use an Event Transformation Agent in Explode mode to create individual events for every login. This explode agent’s options block should be similar to the following:

The resultant event, emitted by the Event Transformation Agent is shown below:

Sample event showing single login event from G Suite

Sending login events to Logstash and ELK

To send the login data to ELK, we’ll use Logstash’s HTTP Input plugin. The plugin creates a listener which will convert data it receives over HTTP(S) into log events, which can later be sent to a number of destinations, including, in our case, Elasticsearch. As a result, we can easily use the below HTTP Request Agent to post login events to Logstash. In the example, below our Logstash HTTP plugin is listening at https://elk.tines.xyz on port 4999. Additionally, we use the “as_object” liquid filter to ensure that the formatting of the event is retained.

Our finished automation story will look like the following:

Searching G Suite report data in ELK

As a result of this automation, we can see how these events look in ELK by searching Kibana. Consequently, we can build alerts to trigger for suspicious behaviour.

G Suite Logs in Kibana

Conclusion

The benefits of centrally storing G Suite events in ELK for indexing, searching and alerting are obvious. The Tines advanced security automation platform provides security teams with a quick, reliable and scalable mechanism to extract, transform and deliver this critical source of information. All, of course, without writing a single line of code.

To see this automation story in action, request a demo with one of our security automation experts.

CEO Fraud – Security Automation Response

December 5, 2018 in Blog

It can be extremely challenging for security teams to detect and respond to CEO fraud. As traditional security gateways and perimeter defenses are often ineffective against this vector, security teams rely upon employees to spot CEO fraud-related emails. In this post we explore how the Tines Security Orchestration Automation and Response (SOAR) platform can be used in conjunction with out-of-the-box features provided by GSuite and Microsoft Exchange to amplify CEO Fraud detection and response.

What is CEO Fraud?

In a typical CEO fraud attack, a malicious actor will impersonate your organisation’s CEO or another senior executive. They will send an email to a member of your staff and attempt to convince them to wire funds, or, as in a recent wave of attacks, send gift voucher codes.

CEO Fraud Sample Email

CEO Fraud Email from SpiderLabs

To make their attacks more convincing, malicious actors research their targets up-front. Using LinkedIn, Twitter, Facebook, etc., the fraudsters glean information like email addresses, roles and locations. If the cyber criminals are looking for money, they may target staff in the accounts payable department. If they are looking for tax information, they may target human resources.

Why is CEO Fraud difficult to detect/prevent?

Unlike standard phishing, CEO fraud emails are unlikely to contain malicious links or attachments. As such, they will likely pass through traditional email gateways. Additionally, email validation systems such as DMARC may not prevent the delivery of CEO fraud emails either as attackers may not spoof your company’s domain directly; sending the malicious email from your-c0mpany.com (with a zero) rather than your-company.com.

As the CEO fraud email will likely originate from outside your organisation, displaying a warning to the recipient indicating the message is from an external source may be helpful. However, if the target receives many external emails, it’s likely they will habituate or “tune out” security warnings like the below.

Replying to external sender example

Using Tines to automate response to CEO fraud

Using G Suite content compliance or Exchange Transport rules we can create a list of keywords and/or regular expressions that are common in external CEO fraud emails. A list of useful keywords is available in this Git repo, however, the most important are your CEO and senior executives’ names. If an email originates from outside your organisation and claims to be from your CEO or a senior exec, forward a copy to your monitoring inbox.

Use a Tines IMAP Agent to read emails flagged as CEO Fraud

The Tines IMAP Agent will emit events when it detects new emails in a specified inbox.

When an emitted event is related to a potential CEO Fraud email. The IMAP agent will emit flagged emails in events similar to that shown below. Here we can see the fraudster is using a GMail account to impersonate our CEO, Kate Jones.

Automating victim reach out

When an event is emitted, we can use a simple Email Agent to contact the targeted employee and warn them that they may be in correspondence with a fraudster. We could also send the employee an instant message. Let’s use Slack to demonstrate how this could work.

The following HTTP Request Agent will find an employee’s Slack profile from their email address:

When the above agent runs, the emitted event will contain an “id” field which we’ll use to contact the target via DM.

Next, we’ll use another HTTP Request agent to contact the user on Slack. Our Slack message will warn them that they received a suspicious email. We’ll also include a Prompt widget so that they can let us know whether the email was expected. The options block for this HTTP Request Agent is shown below.

Now, when one of our users receives a potential CEO fraud email, seconds later, they will receive a Slack message similar to the following:

Slack CEO Fraud notification via Tines

When the “This email was unexpected” button is clicked by the user, Tines emits a corresponding event. The automation story can then continue in any number of ways, for example:

  • Create an incident ticket in InfoSec’s case management system.
  • Page the InfoSec on-call responder if out of hours.
  • Blacklist the malicious sender.
  • Share the email address as an IOC with peers.

Conclusion

For Information Security teams, detecting and responding to CEO fraud can be challenging. However, by leveraging Tines and tools you already have at your disposal, i.e.: G Suite content compliance and Exchange transport rules, we can quickly flag and automate security response to suspicious emails.

As always, with the Tines Advanced Security Automation Platform, it’s easy to adjust automation stories as our processes adapt and our capabilities mature. For example:

  • Before contacting the user, check if the sender has been seen in our environment in the last 30 days.
  • Add additional response options in the Slack message for “This email is legitimate” and “I’ve already replied to this email”.
  • If a user interacts with a CEO fraud email, send them security awareness content.

For more info on how Tines can help automate your response to CEO fraud and Phishing, let’s talk.

SOAR Tools and the Crayon Problem

November 19, 2018 in Blog

The single most important feature of a Security Orchestration Automation and Response (SOAR) tool is its ability to integrate with other tools and systems. For example: SIEMs, case managers and threat intelligence feeds. The data collected from these external systems builds context. The SOAR tool then uses this context to determine the threat-level and remediation actions required for the alert. In this post, we describe the challenges presented by the pervasive app-based integration model used by the majority of SOAR tools. We also explore how the Tines security automation platform‘s direct integration model tackles these challenges.

App-based integration in SOAR tools

Almost without exception, current SOAR tools rely on an app-based integration model. In this model, the SOAR platform provides pre-built integrations, usually called “apps”, “plugins”, “applets”, “modules”, or “integrations” to interact with the target tool. For example, if you need to perform an elasticsearch query, you will leverage an elastic search app. If you need to block an IP address on a Juniper firewall you’ll use a Juniper app.

SOAR Tools crayon-problem

App-based integration is problematic for several reasons, including a reliance on vendors to keep apps up-to-date. However, the most significant issue is what we call “the crayon problem”. When you buy a box of crayons, you’re restricted to using the colors that come in the box. If you need a colour that’s not in the box, well, too bad. Similarly, if as part of your automation workflow you want to integrate with a target tool and the SOAR tool doesn’t have a corresponding app, well, too bad.

This problem is compounded when we consider how quickly the quantity of security tools being used by enterprises is increasing. Cisco recently reported that 41% of organizations are using technologies and services from as many as 50 different vendors. The below image from Momentum Cyber attempts to depict the current state of the cyber security vendor landscape. We’re going to need more crayons!

Cyber Security Tools Lanscape

Furthermore, if you’re part of a high-demand security team, you’ve likely built many of your own tools. You may also need to automate interaction with bespoke tools created by other teams in your organisation. The likelihood of SOAR tools having a dedicated app to support you in these situations is minimal.

SOAR platforms that leverage app-based integration typically try to overcome the crayon-problem by providing an SDK that allows you to build your own custom apps. This requires significant software development skills, however, and so a software developer (or the vendor’s professional services team) need to be engaged.

Tines direct integration

Unlike other SOAR tools, Tines does not rely on pre-built apps to integrate with external systems. Instead, the HTTP Request Agent (one of the six agents available in Tines) provides direct integration with the target tool. This means consistent integration with any tool, regardless of the vendor, regardless of whether it’s open or closed-source, and regardless of whether it’s commercial off the shelf or custom built.

To schedule a Tines demo, click here.

Automating Customer Demos with Tines SOAR

October 29, 2018 in Blog

10 minutes of awkward introductions. 30 minutes of stock-slides. A 15-minute vanilla product demo (the only part you’re actually interested in). And finally, 5-minutes of rushed questions before your hard-stop at the top of the hour. Sound familiar? From our experience, this is how a vendor demo typically goes. We want demos of the Tines security automation platform to be different. In this post, we explore how we use our SOAR platform to automate customer demo preparation, ensuring we provide as valuable an experience as possible.

Tines security automation platform - demo preperation

Screenshot of Tines Security Automation platform showing customer demo automation story

Automating customer demo scheduling

(Left hand flow in story diagram)
In Automating Trial Creation, we described how we use Tines to automate interaction with non-traditional security tools like DigitalOcean and SendGrid. Another great example of the flexibility that the Agent-event integration architecture provides is how we use Calendly. When a customer books a Tines demo either on compare.tines.io or tines.io, a Webhook agent receives the details from Calendly.

Depending on the event type from Calendly, Tines creates or removes an appointment on a shared calendar where we track customer demos. In addition, Tines updates our CMS, Hubspot, with the customer’s details.

Using the Tines Security Automation platform to customise demos

(Centre flow in story diagram)

Tines supports an unlimited number of automation use-cases. To ensure our demos are focused on a use-case that matters to the customer, we let them choose an automation story which we then walk through during their demo.

48 hours before their demo is scheduled, the customer will receive an email similar to the below.

Tines demo email sent to customer

By including a link to the Tines employee’s LinkedIn profile and a slide deck describing Tines, its core features and differentiation points, nine times out of ten we can skip the long intros and jump straight into the most valuable part: the product demo.

This email also allows the customer to “choose their own adventure”. Each of the story links uses a Tines Security Automation Platform prompt widget which will emit an event in our HQ Tines tenant when clicked. Although there are other ways we could collect this feedback, by using the prompt widget, we try our best to ensure the customer has had some exposure to the Tines Security Automation Platform before the demo even starts!

 

Automating customer context collection with the Tines SOAR platform

(Right hand flow in story diagram)
Allowing the customer choose the subject of their demo is a great start, however, there’s many more pieces of information that would help us tailor the demo with more granularity. For example: how mature is the customer’s security program, what tools do they use, and what are their current priorities?

Without asking the customer, there’s no way to know the answers to these questions. However, we can automate passive collection of open source intelligence that will at least help us develop a clearer understanding of the customer’s security program.

For example, in advance of a customer demo, we automate collection of the following with Tines HTTP Request Agents:

  • Basic information about the company (size, location, revenue)
  • Best guess at the demo requester’s LinkedIn profile
  • Previous Tines trials for both the demo requester and others at the company
  • Whether the company submits attributable suspicious URLs to public sandboxes
  • Current security-related job openings (these will often provide insight into tools the company uses)
  • Whether the company has DMARC enabled on their domain
  • Number of customer employees that have been included in known data breaches
  • Who is the company’s email provider
  • Where is the company’s website hosted

The end result is that 24 hours before the customer demo, the Tines employee scheduled to provide the demo will receive an email similar to that shown below:

Sample of Tines email sent to employee in advance of demo

Summary

The impact of a vendor demo is still largely reliant on the person providing the demo. Their ability to engage the customer, understand their requirements and answer their questions clearly and effectively is crucial. However, automating large parts of the demo preparation up-front, means we avoid many of the common pitfalls all too common in vendor demos.

The kind of laid-back shortcut described in this post isn’t going to change the world, but the efficiency and improved customer experience it provides adds up. With the Tines SOAR platform there is virtually no limit to the automation possibilities available. The agent-event integration architecture provides a consistent integration experience regardless of the target system. This is increasingly important as security teams automate interaction with non-traditional security tools.

To schedule your own Tines demo, click “Book a demo” from the main menu.

Developing a security automation proposal for fun and profit

October 24, 2018 in Blog

Information security analysts and engineers often feel the most direct benefits when a company deploys a security orchestration automation and response (SOAR) platform. There’s a reduction in repetitive work, less false positives to chase down, and the volume of alerts requiring investigation decreases. However, if you work in security operations teams, convincing your management team to undertake a SOAR trial isn’t always straightforward. Especially if you’re more used to PCAPs than value props.

In this post we share a methodology security operations center analysts and engineers can use to help them develop a compelling SOAR proposal. We also share a deck based on the methodology, which you can use to develop your pitch.

In Tines, we’ve successfully used this methodology when working with customers and prospects on their own security automation proposals.

Downloading and using the Security Automation Pitch Deck

The template pitch deck is available in Google Slides here. You can export to Powerpoint by clicking File -> Download As. How you use the deck will depend on you, your company culture, your leadership, etc. The slides provide a foundation you can build off when making your pitch.

Developing the SOAR proposal

Start with the problem statement

First we define the problem that our security automation and orchestration initiative will solve. When pitching a multi-purpose platform, like Tines, it’s tempting to compile an exhaustive list of problems the platform will solve. From our experience this will actually dilute the impact of your proposal. Instead, focus on a single problem you/your team feel today. Remember, your goal is to convince management to undertake a SOAR trial.

Problem statements and goals should always be SMART. For example, the following are actual problem statements we’ve seen companies address with Tines:

  • How can we ensure 100% of new incident response analysts are on-boarded with the correct access and tool permissions by next quarter?
  • What mechanisms can we deploy to ensure every suspicious email reported by employees is analysed for malicious content, in multiple sandboxes, by the end of this year?
  • Can we increase coverage of detection and response metrics by 50% in the next 12 months?
  • How can we ensure that any potential incidents reported by the executive leadership team are actioned within a strict SLA, by end of next quarter?
  • How do we increase utilisation of our existing threat intel investments by 25% in the next three months?
  • Can we increase our SOC analysts engagement by 50% in the next six months?
  • What steps should we take to ensure all standardized workflow steps in SOPs are being followed in 80% of cases within the next 3 months?
  • How do we ensure all analysts have at least 5 hours per week to spend threat hunting new data sources/threat intelligence feeds by this time next year?

Pick the problem which you feel most acutely in your organisation. In the deck we’ve chosen the following:

How do we reduce the volume of incidents requiring analyst investigation by 50% in the next 6 months?

Structure the problem

Although there’s probably a few different ways to tackle that problem, let’s suppose you believe that the best way is by automating incident investigation and response using a security automation platform. Your hypothesis therefore is:

We can reduce the volume of incidents requiring analyst investigation by 50% in the next 6 months by implementing a SOAR platform to automate repetitive analyst workloads.

To test this hypothesis, we’ll use a hypothesis tree. Here we’re defining all the statements which would have to hold true in order for our hypothesis to be valid. We also define how we test those statements.

Security Automation Platform Return on Investment

During analysis, if we prove even a single statement false, we prove the entire hypothesis to be incorrect. For example, if after performing the analysis (described in the next step) of historical incidents it’s revealed that only a tiny percentage are false positives, then a SOAR platform is not the solution to this problem. Of course, that’s not to say that a security automation platform isn’t the solution to another problem you’re experiencing.

Conduct analysis

Now that we have our completed hypothesis tree, we need to perform analysis to validate the supporting statements. For each statement, write down the corresponding question(s) that you need to answer in order to prove that statement true or false. Next define the type of analysis you need to perform in order to answer that question. The analysis can be quantitative (counting repetitive steps in security processes) and qualitative (speaking to analysts). Finally, what data do you need to support the analysis and where will you find it?

Security Automation Platform RoI Analysis

During the analysis step, it’s crucial that we avoid confirmation bias. A biased analysis brings your credibility into question and your pitch will be a lot less impactful.

Synthesise information and insights into action and buy-in

After answering all the questions through analysis, you should now have a compelling data set. As a next step, we’ll synthesis that data into insights that encourage action and buy-in. Related data points are grouped and rolled-up into insights which address the governing thought or problem statement.

Security Automation Platform efficiencies

Communicate your SOAR-focused solution

When you’ve completed your analysis and established insights that relate directly to the problem you’re aiming to solve, the final step is to package your proposal into a recommended solution. In this case, a trial of a security automation platform.

Security automation platform proposal

Conclusion

By applying the methodology described in this post, you’ll produce a much more convincing Security Automation Orchestration and Response trial proposal. Starting with a real problem felt by your security team and rigorously testing your proposed solution will ultimately demonstrate the value-add a SOAR initiative could produce.

If you’d like to discuss crafting a SOAR pitch for your organisation, we’d love to help, contact us here.

G Suite Alert Center

October 19, 2018 in Blog

In the last few days, Google began rolling out the G Suite Alert Center to all G Suite customers. It provides extensive visibility into threats detected in G Suite tenants. In this post, we explore how G Suite administrators and security teams can leverage security orchestration automation and response (SOAR) platforms, like Tines, to centralise, triage and respond to alerts from the G Suite Alert Center.

What is the G Suite Alert Center?

When Google announced the launch of G Suite Alert Center it was with the stated aim of providing “a single, comprehensive view of essential notifications, alerts, and actions across G Suite”. Admins can manage alerts more efficiently through the unified view that the alert center provides. Additionally, it provides insights that help them assess their organization’s exposure to internal and external security issues at the domain and user levels.

Out of the box, G Suite Alert Center includes the following types of alerts:

Accessing G Suite Alert Center

When logged into the G Suite Admin portal click “Security” and then chose “Alert Center”.

Accessing the G Suite Alert Center

On the next page, the G Suite Alert center displays all the alerts for your G Suite tenant. From this view, G Suite admins can view details of the alerts. Additionally, G Suite customers on the Enterprise plan can perform remediation actions from within the G Suite Alert Center itself. Later in this post, we’ll show how Tines can be used to automate the same remediation actions in real time regardless of your G Suite plan.

G Suite Alert Center Screenshot

Tines and the G Suite Alert Center

The alerts produced by the G Suite Alert Center provide valuable insight into potential security issues in G Suite tenants. However, the alerts are at their most valuable when, rather than being treated in isolation, we include them as part of a larger threat detection and response effort. By automating interaction with the G Suite Alert Center through Tines, we can use the alerts as both a threat source and as source of additional context when investigating other incident types. By using Tines to integrate with the G Suite Alert Center, we’re also centralising our response and aligning it to existing security response processes.

Connecting Tines to the G Suite Alert Center

In a previous blog post, we described the steps required to connect Tines to G Suite, we’ll use a similar method to connect to the Alert Center.

Enabling the G Suite Alert Center API

Follow these steps, based on those from developers.google.com to set up the Alert Center API:

  1. Create a service account that can be used by your G Suite application (see instructions on creating a service account).
  2. Download the key file, it will be a JSON file containing your private key and other sensitive information.G Suite Service Account Key File
  3. Enable the Alert Center API (for instructions, see section on enabling and disabling APIs).Enable G Suite Alert Center API
  4. Grant domain-wide access to the application, and therefore domain-wide delegation of authority to the associated service account (note that the 3-legged OAuth won’t work for the Alert Center API):
    1. Go to your G Suite domain’s Admin console (see instructions on signing in to your Admin console).
    2. Click Security.
      If you don’t see Security listed, select More controls at the bottom of the page, then click Security.
    3. Click Advanced settings.
    4. From the Authentication section, click Manage API client access.
    5. In the Client Name field, type the Client ID for the service account. This can be taken from the key file, in our example, this is a long number starting with 116.G Suite Admin API Access Pixelated
    6. In the One or More API Scopes field, enter the list of scopes that your application should be granted access to. In this case, type the following value: https://www.googleapis.com/auth/apps.alerts.
    7. Click Authorize.

Creating a Tines Credential

Before Tines can connect to the G Suite Alert Center API, we need to configure a JWT credential type. For detailed instructions on how to use JWTs with G Suite, see here.

Use the information from your service account key file to fill in the required JWT fields. When you’re finished, the credential page will resemble the below.

G Suite Alert Center Tines Credential

After saving the credential, we can begin automating interaction with the G Suite Alert Center.

G Suite Alert Center Automation Story

Get a G Suite Auth Token

To begin orchestrating and automating activities in the G Suite Alert Center, we first need to retrieve an auth token. This will allow us interact with the Alert Center API. We’ll do this with a HTTP Request agent, configured as shown below:

When this agent runs, it will emit an event containing a bearer token which we will use in subsequent agents.

Get All Alerts from G Suite Alert Center

The G Suite Alert Center API is available at https://alertcenter.googleapis.com. We’ll use the list call in a HTTP Request Agent to get all alerts associated with our G Suite tenant.

When this agent runs and there are alerts in our tenant, the G Suite Alert Center API will return an array of alerts.

Get alerts in last five minutes

Additionally, we can use filters to find alerts that match certain criteria. For example, the below HTTP Request Agent uses the date liquid filter to find alerts created in the last 5 minutes (current time in seconds – 300 seconds, converted into Google’s preferred Timestamp format: RFC 3339).

Get alert details from the G Suite Alert Center API

We can also use a HTTP Request Agent configured as below to find details about a specific alert, using its ID.

A sample automation story

G Suite Alert Center Tines Story Diagram

In the above automation story, we’ve created a blueprint for getting started with automatic handling of G Suite Alert Center threats. To begin, at five minute intervals, we fetch all alerts. Next, an Event Transformation Agent is used to explode the array of alerts so each alert can be treated individually. Then we use several Trigger agents to emit events based on the alert type. Finally, we create an incident ticket based on the alert’s priority (this could be in Jira or another case management system) and add the alerts details to the ticket.

From here, it would be trivial add additional threat intelligence sources or automate data gathering log searches in a SIEM. We could also automate remediation activity like blocking malicious senders, quarantining devices and resetting compromised accounts all without requiring human intervention.

Conclusion

When considering threat detection tools for their technology stack, it’s easy for security operation teams and security operation centers to overlook assets like the G Suite Alert Center. However, as enterprises continue their move to the cloud, these non-traditional sources of threat intelligence and security alerts are becoming increasingly valuable.

By using security automation and orchestration tools like Tines to respond to threats surfaced by data sources similar to the G Suite Alert Center, an enterprise incident response team can ensure their standardized workflow is followed. Additionally, their detection and response is smarter, quicker and less prone to human-error.

 

To talk to a Tines rep about security automation and the G Suite Alert Center, contact us here.

Automating Tines trial creation

October 15, 2018 in Blog

No prizes for guessing that at Tines we rely heavily on automation to power our DevSecOps program. The Tines platform is not only at the heart of our internal security, IT and CI/CD programs, we also use it to manage customer trials. This includes automated droplet creation and destruction in Digital Ocean, automating Hubspot actions for contact and lead tracking, and even automated creation of DNS records.

In this post we describe some of the DevSecOps design decisions we’ve made and why Tines is a great platform if you need to automate your own complex processes.

Introduction

Automation is a crucial component of DevSecOps. As you can see from the above diagram, we automate interaction with the following services to support Tines trials:

  1. Digital Ocean: used to host trial infrastructure including DNS.
  2. Hubspot: Tracks trial creation and allows us mange trial life cycle.
  3. Sendgrid: Sends welcome email to trial user and updates Tines support if something goes wrong.

Automating Digital Ocean Droplet Creation

All customer tenants, including Tines trials, are single-tenant and have their own dedicated infrastructure. We use Digital Ocean as our primary infrastructure provider. Additionally, to interact with the Digital Ocean API we use HTTP Request agents.

To speed-up the provisioning of trial tenants, Tines maintains a pool of pre-configured droplets labelled “trial-pending”. When a trial is requested (middle flow in the above diagram), Tines receives the request via a Webhook agent. After deduplicating the request, Tines takes a trial-pending droplet from the pool and begins to configure it based on the requesting user’s details (we use a simple deployment script for this). When no trial-pending droplets are available, an Event Transformation agent delays the flow while a droplet is built.

As part of the configuration process, Tines removes the “trial-pending” label and applies a “trial” label. Tines receives the deployment result via another Webhook agent (left hand side of the diagram), once the deployment is complete. Additionally, a new “trial-pending” droplet is created and added to the pool.

The deployment script sends the details to Tines via a Webhook agent (right hand side of the diagram) when it has completed. Tines uses the Digital Ocean API again to apply a label and create a new DNS entry for the droplet. Finally, Tines powers off the droplet while we wait for a new trial request.

Hubspot Automation

Once Tines has completed trial deployment, we use a HTTP Request Agent and the Hubspot API to check if the contact already exists. If it does, we associate the new trial to the contact. If the contact is new, we add their details to Hubspot and then associate them to the new trial.

SendGrid Automation

We use SendGrid to send transactional emails such as the welcome email we send when a trial is ready for the requester (sample below).

Tines welcome email automation devsecops

Additionally, if something goes wrong, for example, there’s no trial-pending droplets available, Tines support are notified using an Email agent.

 

For a detailed walkthrough of this story, talk to us here.

This is an updated walkthrough of how we manage Tines trials as part of our DevSecOps program. The original version is available here