Comments URL: https://news.ycombinator.com/item?id=50177438

Points: 13

# Comments: 0

We're doing a pretty good job of making it a lot less common: https://www.unep.org/news-and-stories/story/problem-our-dwin...

There's even such a thing as Sand Theft: https://en.wikipedia.org/wiki/Sand_theft

* PrivacySandboxAdMeasurementEnabled

* PrivacySandboxAdTopicsEnabled

* PrivacySandboxPromptEnabled

* PrivacySandboxSiteEnabledAdsEnabled

Thank you for your patience and quick action as we worked through our response plans and investigation for a security incident we first alerted you about last week. We remain committed to providing transparent and timely information around this event for our customers, partners, and the industry at large. The security threats that we face, as an industry, are unprecedented and require strong collaboration from all constituents.

As a result, today we are publishing details of activity by a sophisticated nation-state sponsored threat actor that gained unauthorized access to our systems to target a small and specific set of our customers. Prior to sharing this information, we notified and worked with the impacted customers. We have also been working with our incident response (IR) partners and law enforcement on both our investigation and steps designed to make our systems and our customers’ operations even more secure. The attack vector used by the threat actor has been mitigated.

Now that our customers are informed and we have taken the appropriate steps to eliminate this threat, we are able to share additional details of the incident in an effort to be transparent and help others take appropriate steps to monitor for and protect against this threat.

On June 27 at 15:13 UTC we discovered anomalous activity on an internal orchestration system which we traced back to a sophisticated spear-phishing campaign perpetrated by the threat actor on June 22. That activity included unauthorized access to a specific area of our infrastructure. We did not see evidence of customer impact at that time. Out of an abundance of caution, we rotated credentials, rebuilt infrastructure, and took a number of other actions to further secure our network and perimeter. Additionally, we activated our prepared incident response plan and worked with our Incident Response (IR) partner to analyze all systems and logs for potential activity. It was also at this time, as part of our IR plan, that we contacted and engaged law enforcement in our investigation.

JumpCloud Security Operations, in collaboration with our IR partners and law enforcement, continued the forensic investigation. On July 5 at 03:35 UTC, we discovered unusual activity in the commands framework for a small set of customers. At this point in time, we had evidence of customer impact and began working closely with the impacted customers to help them with additional security measures. We also decided to perform a force-rotation of all admin API keys beginning on July 5 at 23:11 UTC. We immediately notified customers of this action.

Continued analysis uncovered the attack vector: data injection into our commands framework. The analysis also confirmed suspicions that the attack was extremely targeted and limited to specific customers. What we learned allowed us to create and now share a list of IOCs (Indicators of Compromise) (https://jumpcloud.com/support/july-2023-iocs) that we have observed for this campaign.

These are sophisticated and persistent adversaries with advanced capabilities. Our strongest line of defense is through information sharing and collaboration. That’s why it was important to us to share the details of this incident and help our partners to secure their own environments against this threat. We will continue to enhance our own security measures to protect our customers from future threats and will work closely with our government and industry partners to share information related to this threat.

If you are a customer with additional questions on this incident, please submit a support ticket in your admin console or reach out to your account manager.

Thank you,

Robert Phan CISO

Comments URL: https://news.ycombinator.com/item?id=36706216

Points: 19

# Comments: 7

Long story short, what are good alternatives to PagerDuty?

Comments URL: https://news.ycombinator.com/item?id=34592841

Points: 1

# Comments: 5

Additionally, there's quite a few benefits: - It's all wired, so it's been rock solid; - It's vendor agnostic; - It's entirely local, so there's no subscriptions or even an internet connection dependency; - There's a ton of gateways available that allow me to interface with non-KNX products;

Overall, I'm pretty happy with it. It is just a matter of convenience however, it's hardly a must-have.

That they're quite reasonably priced doesn't hurt either :)

Also, if the alarm is connected to a security provider, a disruption in communication with the car will also cause them to follow up on it.

For production purposes you'd probably want a lossless file format anyway.

The four channels are also quite similar to the EQ section of a DJ mixer which generally controls three frequency ranges (low, mid and high). EQ-ing is heavily used to mix songs together, so by sticking to a similar interface, DJ's can easily pick up this format.

  (i) You must not copy, rip or capture, or attempt to copy, rip or capture,
  any audio Content from the Platform or any part of the Platform,
  other than by means of download in circumstances where the relevant
  Uploader has elected to permit downloads of the relevant item of Content.

Could you elaborate on what you consider to be "bad REST" with regards to using POST in this case? The RFC clearly leaves the definition of the semantics of POST up to the implementation of that particular resource.

The only argument I could come up with, is that POST is not guaranteed to be idempotent or safe, whereas a search query would be. But a lack of guarantee doesn't exclude use cases where it would be.