Airliners are not a Heroku dyno that you can "push code" into. There aren't APIs you can call, pull requests or Docker containers. We're not talking about a webserver or a couple of rails apps. We're talking about stuff being physically separated, non TCP, non IP, non Ethernet, uni-directional connectivity. Your OSI model doesn't apply here. Your API command list doesn't apply here. Your very notion of networking doesn't apply here. This is not about releasing early and iterating. We're talking about systems with a lot of redundancy and actual physical backups where efficiency is not an issue. The devops mentality does not work in this case.
Yeah, but I think that the main message is that there are pilots in the cockpit who can easily override any weird input. Even if it is theoretically possible (hey, you never know, right?) to impersonate avionics and mess up with the FMS/ECU/EICAS, there's no such thing as a pilot going "holy crap! the plane is going sideways and there's nothing I can do!". I'm pretty comfortable calling this whole "hacking the engines from the in-flight entertainment system" fiction.
It's important to put things to the test, but I tend to listed to people who are actually qualified and know what they're talking about. Even that RenderMan talk at DEFCON 20 came with a bunch of caveats. If you don't want to watch the whole thing, the TL;DW version is: Boeing and Airbus are not stupid, a 787 is not a D-Link wireless router and you pretty much can't get to the flight controls from the in-flight entertainment system. https://www.youtube.com/watch?v=Uy3nXXZgqmg
>This is the issue. Chances are Heroku has a very secure infrastructure, but the world will never know unless it allows various audits to be generated for compliance purposes.
Exactly. And, personally, I think this is rather odd. They could solve this in a heartbeat.
>Not true, see below:
Duly noted and thanks for the link, but here's the thing, though: what if you're not eligible for a self-assessment?
The Heroku situation is more nuanced than it seems. This is not a PCI DSS 3.0 issue. The thing is that Heroku provides a platform and this platform is not PCI DSS compliant (1.21, 2.0, 3.0, you name it) and Heroku is not willing to let QSAs verify their compliance on behalf of their clients (and, yes, I have first hand experience with this very scenario). There's a caveat, however: if your payment platform is completely segregated from your Heroku environment, you might be good to go. Let's say you use a payment gateway and cardholder data never touches your Heroku environment (e.g. you're redirected to Payment Gateway XYZ's app to enter your payment information). In this case your Heroku environment would be potentially out of scope, as you're not transmitting, storing or processing cardholder data. If you're handling cardholder data in any capacity in your Heroku environment, then, yes, you're in for a big compliance surprise.
QSA here. In a nutshell, I'd say don't. PCI compliance is enforced by the card brands and acquirers, so it's not up to you to raise a flag here. Maybe they have compensating controls in place to address those issues (one can be PCI compliant while storing cardholder data in clear-text) and, depending on the line of business, they might have a business justification for storing security codes (unusual, but it can happen). Ultimately, it's not your call. What you might perceive as a violation could very well be a known issue with several compensating controls in place to minimize the risk and, if that's OK with the card brands and/or acquirers, your competitor is doing nothing wrong. Leave it to their QSA to determine their compliance status and to their acquirer to make sure that they're compliant.
And that's why you don't make games that need to be online 100% of the time to function (and charge $60 for it). Also, it should be noted that paying $400 for a console only to be told that you can't use it because some teenagers are bored is a bad investment. Sony and Microsoft should know better. They are both big and juicy targets, but there are bigger and juicier targets out there that are able to weather those lame attacks. It's Christmas day and a lot of people who got Sony and MS products are unable to fully utilize those products. Those guys are ripping Sony a new one every other day since 2011. Sony learns nothing and remains awful in incident response and recovery.
I'm just gonna copy & paste my comment on another site about this: As a Brazilian, I can tell you that this is more than moral panic. Those balloons are a major fire hazard. There are many, many instances of fires breaking out because of balloons in forests, houses, warehouses... They're also a huge air traffic hazard (listen to ATC near Brazilian airports and you're pretty much guaranteed to hear pilots complaining about them). Just last week a balloon "landed" in the tarmac of Brazil's largest airport, barely missing an airliner. To top that off, they're annoying. These balloons usually carry fireworks and are launched late at night, so you'll wake up at 2 AM to the awesome sounds of fireworks. Sure, they're pretty to look at, but they're also a really bad idea.
For sure. If you're getting your weather data via METAR/TAF, you should be able to read it :). And one can always resort to this (even though it won't decode everything). http://heras-gilsanz.com/manuel/METAR-Decoder.html
Well done. I can see this working well for aviation enthusiasts (i.e. X-Plane folks) who like to use real world data. However, METAR/TAF are not the friendliest of formats. Have you considered including a METAR/TAF decoder?
Writing "The group simply called “CCC”" when referring to Chaos Computer Club, one of the most important hacker collectives in the world, around for 30+ years and responsible for the largest hacker conf in Europe makes me wonder if the OP has any knowledge about the security industry in general and biometrics in particular.