Notification services
In keeping with our commitment to security and transparency we wanted to inform you that our provider for SMS, Twilio, has alerted our security team to an incident that occurred. Below is the statement we received from Twilio which gives a detailed account of the incident and what has been done:
—--------------------------------------
Twilio has been notified by one of our backup carriers, iBasis, that IdentifyMobile inadvertently exposed certain SMS-related data sent by iBasis publicly on the internet that included personal data. We are writing to inform you that some of your personal data and non-personal data (such as data related to marketing campaigns) was accessed by a security research group while it was publicly exposed by IdentifyMobile.
Although this incident was outside Twilio’s control, we take it very seriously and are committed to helping you understand the full impact.
What do you need to know?
In order to deliver messages in specific regions, Twilio relies on numerous carriers to maximize deliverability to their final destinations. Twilio was notified that iBasis (a Twilio backup carrier) had used IdentifyMobile (iBasis's further backup carrier) who inadvertently enabled public access on an AWS S3 Bucket during development work. Information contained in this bucket was made public from May 10-15, 2024, and accessed between May 13-14, 2024. Based on a joint investigation between IdentifyMobile and Amazon AWS, we learned that a portion of this data was accessed by the Chaos Computing Club (CCC). CCC is a security research group that identifies security issues; CCC has confirmed that they are not holding any data downloaded from the AWS S3 Bucket. We do not have evidence that allows us to confirm that no other third party accessed the data.
Twilio does not own this bucket, and none of our systems have been compromised in connection with this data exposure. This incident was the result of actions taken by IdentifyMobile and outside of Twilio’s control.
While we continue collaborating with these carriers to bring you the most accurate information regarding this exposure, the portion of data exposed by IdentifyMobile related to SMS sent between January 1, 2024 and May 15, 2024, and included:
Mobile number
SMS message content
SMS Sender ID
SMS Timestamp
What have we done so far?
Twilio initiated our incident response process to rapidly investigate this matter.
Twilio escalated this issue to the iBasis executive team; subsequently, we’ve done an analysis on the data logs that were compromised to provide you with as much information as possible.
Out of an abundance of caution, we have ceased sending traffic to iBasis where possible. iBasis informed Twilio that it has stopped routing with IdentifyMobile.
We will continue working with our 3rd party carriers to get you any additional details that may arise from this incident.
What do you need to do?
We recommend reviewing the SMS traffic you sent between January 1, 2024 and May 15, 2024, discussing the implications of an exposure with your internal team(s) and deciding if you need to engage with impacted individuals. If you need additional information regarding this incident, we are here to support you throughout this situation.
We deeply regret any inconvenience this may cause and appreciate your understanding and cooperation.
—--------------------------------------
What has StatusCast done?
Once StautsCast’s security team was alerted an audit was performed to try and determine the potential impact this had on our service. Based on Twilio’s report it is possible that some notifications sent through StatusCast’s service would have been sent using the iBasis carrier. Based on the report data would have included the recipient's phone number as well as the SMS message. SMS notifications in StatusCast are designed to be brief and to drive users to the status page. SMS messages do not include recipients name or other personal identifiable information(PII).
As always in StatusCast you have the right to choose whether SMS notifications are sent or not. SMS options can be controlled in the Settings and Integration sections of the application if you wish to review your configurations. At this time there are no additional action items for StatusCast to take in regards to its application or infrastructure, however we will maintain close communication with Twilio and if any additional information is released we will pass it along through our own status page.
StautsCast has partnered with Twilio for years and they have maintained a strong commitment to security and transparency. We will take that as well as this incident into consideration as we continue to offer SMS notifications in the application. If you have any additional questions please reach out to us at support@statuscast.com
We are very excited to announce that StatusCast has been acquired by 4Me! Since 2013 we have been working hard to close the gap between service outages and those who are impacted, and this acquisition is one large step further in our journey of providing critical information to those who need it most.
The inclusion of StatusCast's features will aid 4Me in it's mission to modernize service management for organizations. Click here to read more!
The StatusCast team will be performing a maintenance on December 17, 8:00am EST, the estimated duration is 2h. We do not expect any impact to your service but in some cases there may be a brief interruption.
This maintenance has been completed.
Starting August 30th, 2023 for Public Status Pages that allow SMS subscriptions StatusCast will now require that a valid email address be confirmed before a person can fully establish a new SMS subscription.
This change in subscription workflow is to help prevent malicious parties from attempting to commit SMS fraud which has become a growing concern for many SaaS companies dealing with mass notifications. We here at StatusCast have witnessed this trend, in the past 6 months the quantity of malicious traffic attempting to commit SMS fraud has increased drastically. While we have continued to implement industry best practices to safeguard against this sort of activity, ultimately real user confirmation is the most effective way to prevent such unwanted attention.
StatusCast's engineers were alerted that schedule maintenance events created from StatusCast's legacy application("V2") were not properly auto-closing after their estimated duration had been reached. After an initial investigation engineers have confirmed the cause on the service responsible and a patch was performed to correct the error. Any maintenance that was overdue for closure should have been resolved and StatusCast's engineers will continue to monitor the legacy process for this to ensure no other issues occur.
StatusCast’s engineers were alerted that some SMS and email
notifications had an unusual delay in their delivery. The team immediately
began investigating and determined that one of the notification processors was
experiencing a failure that resulted in a queued backup of notifications. This
did not impact all notifications sent through StatusCast, only a subset that
were assigned to the instance in question.
Once the instance was isolated the backup of requests were
offloaded and the instance itself taken out of rotation. Even though the
instance itself did not enter an unhealthy state our engineers have
re-evaluated certain health checks to account for queue backups as well as other
performance attributes. Additionally, our engineers have scaled out the number
of instances to help reduce the load on any single processor at a given time. At
this time all notification services are running as expected but we will
continue to monitor the system closely.
StatusCast’s engineers were alerted that some incident notifications were either slowly being delivered or appeared to not get delivered at all. After an initial review our engineers determined that the service processing notifications was experiencing performance issues, resulting in a queued backlog of notifications.
At this time StatusCast’s engineers have scaled out this service to allow the backlog to clear itself up in as an efficient manner as possible. Notification processing at this is has returned to it’s normal state and we will continue to monitor this closely. A root cause analysis will be posted when more information has become available.
At this time notification services are performing normally.
Summary of impact: Between 1:06PM and 1:59PM EDT on 29 June 2020, some customers may have experienced latency with incident notifications getting delivered. All notification services were recovered by 1:59PM EDT.
Preliminary root cause: Engineers identified the underlying root cause as a server delegation change affecting DNS resolution and resulting in a backlog of notifications getting queued. This issue impacted a subset of StatusCast’s customers who were delegated to the server in question. Availability to status pages and the administrative portal remained at 100% throughout the incident
Mitigation: To mitigate, engineers corrected the server delegation issue. To expedite the processing of the server’s backlog, engineers scaled out the service to efficiently distribute the backlog of incidents. Once the backlog was cleared the service remained at its normal operating state.
Moving Forward: StatusCast is committed to providing its customers a highly reliable and available service. Anytime an issue is reported that potentially affects availability of the status page or the integrity of notification delivery, we treat it with the utmost urgency. Moving forward we have established new monitoring protocols for our notification system to ensure that latency created backlogs are properly reported to our engineering staff. We have also taken this as an opportunity to evaluate the current scale of this service and how we can improve upon the functionality.
StatusCast is deeply committed to the protection and responsible use of data; we’ve made a few updates to our privacy policy to help you better understand how we collect and use information. We hope these changes more clearly articulate our responsibility to you.
By continuing to use our services on or after March 25, 2020, you indicate your agreement with each of the updated and new terms and policies that are effective as of that date. If you have any questions or concerns, please email support@statuscast.com or reply to this email.
The StatusCast team will be performing a maintenance on Saturday July 27th 2019 at 7:00 AM EDT, the estimated duration is 1 hour. We do not expect any impact to your service but in some cases there may be a brief interruption.