I worked for Marriott for a long time (on the tech side). They have no distain for computer science, it's not "run by business majors", and there is no shortage of security experts. They were one of the more on the ball technology and security operations _for a company of that age and size and legacy_. The company as a whole placed huge focus, resources and energy on information security from well before I joined - it was one of the most risk averse groups I've worked for.
The incident took place on the Starwood network (they bought starwood, a completely separate company with completely separate infrastructure), and this issue was discovered post acquisition and during the long running integration program (starwood had 2 breaches previously, so I guess it's not surprising). From what I've seen, if it wasn't for the controls implemented as part of the integration which formed part of Marriott's standard risk-averse approach to security generally, it probably wouldn't have been found for another 4 years.
It's complicated, and 99% of the "damn fool corporates and their evil ways!" comments are completely off the mark because they don't have the context.
The reality is that integrating another business is unbelievable difficult. Managing the (now significantly higher) infosec risks more so. You inherit a landscape with monsters you don't know about, and you still have to own whatever pops out. It's a really, really bad thing to have happened - make no mistake. And in time, the full story will out and opinions can be reached based on facts. Maybe they did screw it up. Maybe they could have done stuff differently. I don't think it's like equifax with a clear cut cause and effect, but a reasonably complicated ecosystem steeped in legacy systems opaque dependencies that is really hard to change.
It seems to be this generally accepted thing that whenever there is a huge breach, some people (aside from the person doing the breaching) have been utterly negligent, ignored all the obvious and really quite simple (I mean, just encryption all the things, amirite? duh!) and should be rounded up and shot at dawn. Perhaps - just perhaps - it's something that wasn't a result of negligence, and just wasn't foreseen because hard stuff is hard. Hindsight really does create the most impressive armchair strategists.
(no, I don't still work there. I left a few years ago. no, I don't think they're perfect. no, I don't think all corporations are evil incarnate looking to steal our data, only some of them.)
This is how it was explained to me, and the approach we take. YMMV.
Understand what your lawful basis for storing and processing the data is, and that dictates how you need to handle it. Plenty of people throw around large fines and rights to be forgotten and make sweeping statements about "you can't keep X data/we can hash things!/delete all the things". You have a number of potential reasons for storing or processing data. Legal reasons, contractual reasons, consent based reasons - data subjects have different rights depending on the reason you're storing the data (there is a list of these reasons; see below.)
I may be keeping data because I have a contract with a client, and I require the data. An example of this would be an email address stored as a login. My legal basis for storing the information is contractual (I have a contract with my client). Does the data subject (in this case, the user who's email it is) have a right to erasure? No. Can I store the information in my Amazon RDS instance in Virginia? Yes. Provided I've explicitly stated it, and been transparent about how and where I'm storing and processing the data, and my client has agreed. Do I need to secure and look after the data? Yes. Obviously. Do I need to get to get consent from the user? No. That wasn't the legal basis for storing the information.
What about consent based stuff? I may have someone subscribe to my mailing list. I get their consent. Therefore, the legal basis for storing and processing is consent. That consent should be time limited, and I should be transparent about it. I need to give them the means to review, withdraw and act on their consent should they wish to.
What about keeping a record of a person you've deleted because they have requested it? You can store this. Lawful basis is that it's a legal requirement. If you go and use the data for any other purpose, it's not allowed - because that would require their consent.
Trying to wade through one half of the GDPR and its requirements without understanding lawful basis leads to confusion, because you'll keep hitting cases that seem completely unreasonable (because they may not be required). Trying to paint the law vague and unreasonable defeats the point - it will become less vague over time. It makes privacy a first class citizen (something we sorely need), and will become more specific as it's tested in the courts, just like any other law in jurisdictions that value legal precedent.
Get to know it and work with it - this is not your mother's EU cookie law.
1. Corporate business and negotiated rates (a large % of business)
2. Groups (unless you cram 20 - 40 people in an airbnb room?) - this includes conferences, conventions, aircrew, functions, tour groups) (another large % of the business)
This assumes we're talking about city hotels with a normal(ish) business mix, but individual travellers often don't make up the largest portion of business for the hotel (this really does vary, but outside of pure tourist and transit areas it's roughly accurate). Add into the mix the zoning and health & safety requirements, and I'm not sure you could call "doomed" just yet.
There is scope for (ahem) disruption in booking and distribution, which we already see - but the physical product is probably going to be around for some time. Sometimes, you just need a big building with lots of rooms...
hotel IT here: they last for between a year and 18 months and are generally replaced as part of a fixed maintenance cycle (floor by floor over a period of 2 or three months).
Yes, I think it adds (or detracts, in the case of poor copy) from the credibility of the product as a whole. I actually have a use for the product right now, and I must admit the copy errors when I went through the site made me wonder what other errors would come up.
It's a good idea - don't let crappy copy lose you signups.
Likewise, I've seen similar in my environment. I think the difference is that mobile will enlarge the market, not displace full function devices - it's not CD killing the cassette tape (as the original article author seems to imply). Systems catering for mobile consumption will see increased use, but that doesn't mean decreased use for those not.
The change is presenting as a line continuing to blur between computing devices (laptop/tablets/phones/etc)... and that isn't taking much time at all.
yes and no. I attended OSCON[1] in 2005 and 2006 and, like the linked post, I remember a strong focus on BOF sessions and tech-related activities after the main day sessions were over, with a small amount of partying towards the end. Product specific conferences (Oracle, MS etc.) were always more party and less talk, but the audience was very different - I suspect that was the status quo wherever salespeople and corporate folks outnumbered technical people by any margin.
It may be a side effect of the increased popularity of the dev/OSS/startup industry as a whole over the last few years, but I've certainly seen (purely anecdotal, I know) a decrease in productivity and an increase in hangovers & 'remember when bob fell in the fountain' stories the next day...
ZA/Joburg resident here - he was actually located after he SMS'd his girlfriend, and the cops used his mobile phone signal to locate him. It was widely tweeted, but from what I gather it had very little to do with the actual recovery of the gent in question.
this. psychiatric issues, in whatever form they may present, are (a) not really diagnosable from a blog post and (b) often treatable and result in a good quality of life. go and seek professional help. get a referral from a medical professional, not friends or family.
The incident took place on the Starwood network (they bought starwood, a completely separate company with completely separate infrastructure), and this issue was discovered post acquisition and during the long running integration program (starwood had 2 breaches previously, so I guess it's not surprising). From what I've seen, if it wasn't for the controls implemented as part of the integration which formed part of Marriott's standard risk-averse approach to security generally, it probably wouldn't have been found for another 4 years.
It's complicated, and 99% of the "damn fool corporates and their evil ways!" comments are completely off the mark because they don't have the context.
The reality is that integrating another business is unbelievable difficult. Managing the (now significantly higher) infosec risks more so. You inherit a landscape with monsters you don't know about, and you still have to own whatever pops out. It's a really, really bad thing to have happened - make no mistake. And in time, the full story will out and opinions can be reached based on facts. Maybe they did screw it up. Maybe they could have done stuff differently. I don't think it's like equifax with a clear cut cause and effect, but a reasonably complicated ecosystem steeped in legacy systems opaque dependencies that is really hard to change.
It seems to be this generally accepted thing that whenever there is a huge breach, some people (aside from the person doing the breaching) have been utterly negligent, ignored all the obvious and really quite simple (I mean, just encryption all the things, amirite? duh!) and should be rounded up and shot at dawn. Perhaps - just perhaps - it's something that wasn't a result of negligence, and just wasn't foreseen because hard stuff is hard. Hindsight really does create the most impressive armchair strategists.
(no, I don't still work there. I left a few years ago. no, I don't think they're perfect. no, I don't think all corporations are evil incarnate looking to steal our data, only some of them.)