But how did they get such a database in the first place?
SQL injection, malware, physical compromise, buffer overflow, side-channel attack, credential reuse, DNS hijacking, ARP spoofing, unpatched vulnerabilities... Pretty much for any attack vector you can think of, a password database is one of the potential targets.
As an example, let's consider the credentials to a web service, stored in a RDBMS. If that web service is insecure in particular ways, SQL injection can be used to dump the entirety of the database contents to an attacker's screen (which can then be converted into a nice username/email/password table).
And if they could get their hands on the password database (typically a highly protected file), couldn't they already get their hands on any other information they wanted that was on the computer?
Now yes, the SQL injection could probably also be used to manipulate the database in other ways, but that might not be the goal. Modifying the database for a financial service won't make the API calls to move money. It may be necessary to actually use another person's access, necessitating the hash reversal.
Another example, which is much more likely to be encountered in low-security environments, is the problem of credential reuse. If the attacker finds an administrative user in the database, there's a good chance that user's password is also used on internal systems, like that precious ssh server. If that password is weak, the whole enterprise is open to compromise, because of a SQL injection attack.
Even if there are no vulnerabilities (or worthwhile targets) in the company whose database was dumped, there are a lot of other targets that could be impacted. Notably, all those email addresses with usernames and passwords attached. Crack those passwords, then go hit the mail services and try them. Only one login failure per account, but you have thousands of email addresses to try across dozens or hundreds of mail services. With access to an email address, there are a lot of options for a criminal enterprise:
Break a college email account? You probably also have access to the student service portal, and can redirect financial aid reimbursements or tuition refunds... then cancel all classes.
Break a company email account? Read other emails to get a sense of corporate structure, then direct an underling to purchase high-value equipment from your own fly-by-night vendor.
Break a personal email account? Reset passwords to banking websites, PayPal, loyalty programs, Steam, certain video games, or other value-holding services, and take whatever can transfer.
Break a high-value email account, such as a multimillionaire or celebrity? Send emails to friends, family, and finance managers, and arrange a few emergency wire transfers to cover "unexpected expenses while traveling".
Information often isn't the end goal. Very often, database dumps and other attacks are just the intermediate steps in a criminal campaign to find victims for another attack.
I am not sure it really matters all that much if a password is weak or medium or strong.... eventually they can be cracked and get at least some accounts.
Unfortunately, from a user's perspective, this is out of your hands. If a service isn't salting their password hashes, then somebody's credentials are going to be broken quickly. However, it doesn't have to be yours, because you can make your password long and random without a salt, so the use of fast brute-forcing methods won't be effective (and the slow methods will take longer than the lifespan of the universe, with today's technology). In another worst-case scenario, you can assume your password for that service will be broken, and you can only hope for damage control. Turn on multi-factor authentication, enable activity alerts in email or SMS, and make sure your password is unique so it can't be used to get access anywhere else.
Again, because long and unique passwords so drastically improve one's security posture, a password manager is the easy route.
I use KeePass personally, and its built-in password generator has the following options:
Upper case
Lower case
Digits
Minus
Underline
Space
Special (!, $, %, &,...)
Brackets
High ANSI characters
A custom set of user-defined characters, which would meet your "certain non-alphanumeric" rule example
It also has options to only allow characters to appear once at most, forbid look-alike characters like "O" and "0", and simple prohibit certain characters.
The college that conducted the study is in the Philippines. The experiments were run against the college's student email accounts... which does raise a few easily-dismissed ethical concerns, but I digress...
There's really no reason to assume the USA would be involved at all, other than the reference to NIST, which isn't too surprising. Many places refer to NIST standards, just to avoid a certain standardization problem.
Database hash dumps don't care about what online-attack rules you put in place.
Once they have the hashed-password database, it's just a matter of time before the attacker gets somebody's password. The goal is to make sure it's not yours, by using a long and totally-unique password... precisely what a password manager is good at generating and handling.
While the volcano is busy breaking down the plastic to elements, it'll still release a lot of those half-broken molecules as debris and ash, many of which will float on the air over to populated areas. In Hawaii, those areas are also the places that bring in that lovely tourist revenue.
You're essentially suggesting we use a volcano as an incinerator, without bothering to put any filtration or scrubbers on the exhaust. Granted, the heavy stuff will be completely destroyed... but the lighter stuff will be just as bad as any other incineration. It might be possible to capture the released gas and try to filter it, but I suspect the higher heat of the volcano will make building such a structure rather difficult.
Doesn't it seem like this is a problem better handled by cheap, disposable sub-drones that can get close enough to identify a wedding?
Those "cheap, disposable sub-drones" are anything but. If they're disposable, they have to be replaced. That means ongoing expenses and increased supply lines out to forward bases. If they're cheap to the point where quality is compromised, they won't last long enough to complete the mission, and the enemy gets a chance to run away before the actual bomb drops.
Or a bomb that drops but doesn't detonate until a camera on it can verify that it's not a wedding?
So we put a camera on a bomb, hope the camera survives the drop, then wait patiently for the impact dust to clear, then get a video feed... and still need a human or an AI to look around and decide the small area of visible surroundings is or is not a wedding. Gee, I hope none of those terrorists ever get our secret can-of-spray-paint defense system.
We don't need to bring fuzzy logic into this. It's not the solution.
Well, it still seems better than the other ideas you've proposed.
That's pretty much what already happens. Drone operators are told "we have a report of a training camp holding a meeting here... go find it". Then the op flies around looking for a meeting, sees a bunch of gathered people, and with no indication to the contrary, command orders the strike. The idea that it might be a wedding never crosses anyone's mind.
Adding an AI means there is now an unbiased process looking for alternative interpretations. The AI doesn't care what it's "looking for"... it just tries to guess what it's "looking at". It won't get a commendation for finding a good target, and it won't care how much the commander really wants to have a mission. It just says what it sees.
There is still a human there. Maven is just an object-recognition system, that highlights objects in (usually low-resolution) drone video feeds. For example, it'll identify whether the 20-pixel object in the back of a pickup truck is actually a goat or a machine gun. It's still a human who decides whether to actually launch an attack or not.
The sociopaths are the ones using drones to bomb weddings.
Uh... The people using the drones are the ones asking for an AI to tell them "Even though the local informant said this was a training camp, it looks more like a wedding".
The standard defines the protocol and technical details. The alliance defines the legal framework that lets vendors cheaply implement the standard, without worrying about touching each others' patents, or exposing themselves to other liabilities. It also allows vendors to gain the marketable feature of a "works with other brands" logo, and the legal ability to sue others that use that logo without actually being compatible.
In a perfect world where everyone was honest and patient and only implemented standards perfectly, business alliances wouldn't add anything. In this world, however, they add a legal and political safety net for vendors.
Do you think there's anywhere else in the world with existing facilities to build Apple's products at anywhere near the same cost or quality? There are a few places that have the technical ability, but they can't handle the scale of Apple's production.
Even if Apple wants to spend the piles of money needed to enter the fabrication, chemical processing, and manufacturing sectors, they don't have the experienced people on staff currently. They don't have the factories built. They don't have the supplies of raw materials already mined or shipping. All of that takes time, during which Apple would be trying to invest heavily in itself with no revenue stream, and their highly-captive customer base would start migrating elsewhere.
Google is in a different, but similar position. Their hardware isn't so critical to their revenue, so they could afford to simply let product lines die off while encouraging Taiwan to increase capacity. Unfortunately, Google wants to keep their money as a war chest to fight against Amazon for the "ubiquitous information services provider" title. That means they can't invest as much of their own cash into the necessary expansion without some serious compromises, like killing off or reducing their own products for a few years.
However, Google does have a major advantage over Apple: They really aren't in the hardware business much at all. Their Pixel phones, for instance, are actually Google-branded HTC devices. HTC is Taiwanese, so it probably already has a few secret business plans for how to handle being cut off from mainland China, likely involving sourcing chips from other fabricators, or indirectly acquiring parts in such a way that their vendors aren't traced to be supplying Google.
In both cases, though, there would be several years of disruption to normal business, which in turn disrupts American technological progress, and provides an opportunity for Chinese companies to absorb the excess of high-quality parts and expertise locally... You know, exactly the goal of a trade war.
There are a few other similar mechanisms that would make that process feasible, like founding a new company, which then merges with all of ZTE with an appropriate contract to keep everything intact. It'd have to be executed carefully to maintain viability while avoiding the ban, but such things have worked before.
Either way, you are absolutely correct that this is an investment nightmare. Even if a ZTE holding isn't already considered practically worthless, there can't be much confidence left in the current management, so even if they can pull off a restructure through a loophole, I would expect a new round of executives at the top, and certainly down whatever chain broke the sanctions.
So this is not "every piece of personal data is forbidden". That is a huge misconception.
Certainly not "forbidden" by the regulation, but in practice. If I go tell my manager "our server logs have IP addresses", he's not going to launch an inquiry into whether that personal data can be combined with anything else, and he's not going to let me get fully-encrypted storage for our highly-sensitive logs. He's going to say "get rid of them".
Practically, he doesn't have a choice. Keeping the personal data means our lowly web servers are now a focus for compliance, which means even if we do nothing else, we have to have additional process reviews, audits, staffing for those audits... His choices are either a nebulous expense for compliance, or turn off logging and hope the troubleshooting is the less-expensive option.
Also, some kind of personal data are more sensitive and given special status.
While that's true, the GDPR doesn't really distinguish different sensitivity levels. Rather, the GDPR considers even weakly-identifiable information (like an IP address in a webserver log) as still being "personal data", and if it can be combined with anything else (like by correlating timestamps to database entries) in the enterprise to produce an identity, it has to be treated like it's all directly identifiable. Despite it being a data-handling best practice for many years, there is no concept of a "Chinese wall" screening information from different processes.
The huge problem arises when you gather a shit-load of information on people that you really don't need and start data mining that.
In the GDPR text, there is no distinction between "data mining" and any other kind of "processing" on stored data. There is also no limit on scale. If I have a comment form on a website that asks for a name, and that's stored in a database, I am collecting and processing personal data.
That's pretty much my complaint about every part of this thing. It's horribly vague, to the point that normal daily operations become regulated activities. It'd be fine if the "processing" definition had a limit on it like "any operation... for the purpose of inferring more information about the data subject", but there's no such thing. That would arguably cover any data mining or user-tracking process, but leave an exemption for basic things like logging or mostly-anonymous interaction.
Ah, no. The Member States can have their own laws that are stricter if they want, however they cannot make laws that nullify the GDPR or parts of it. But unless they have a law of their own, the GDPR is in effect. That is why the new GDPR is a regulation rather than a directive (which the GDPR was replacing).
I understand that. To clarify, I'm hopeful that the laws are more clear than the GDPR, defining "personal data" and "processing" with a bit more restraint, and allowing for isolation practices. Such things could be written carefully to avoid actually contradicting the GDPR, again mostly because the GDPR just blissfully ignores such concepts entirely.
I've read (the majority of) the regulation text, I've read the analysis articles, and I've sat through the meetings discussing whether or how it applies to my own company. I feel like I've done my effort to educate myself.
So what exactly am I misunderstanding? Where's the authoritative source that says "IP addresses aren't identifiable", or "processing doesn't include that", or any of the other fine details that seem to be curiously missing from the actual regulation text? So far there's a lot of folks commenting to say "you don't understand", but nobody that actually wants to put in the time to explain what I'm missing.
Understood, but I'm rather pessimistic when it comes to business agility, especially regarding compliance.
If it's enforced May 25th, most companies won't aim for compliance before May 24th, because they want as much time for their own changes as possible. Since a company's compliance is dependent on their suppliers also being compliant, there's a cascade effect if a critical supplier isn't able to meet their deadline, or changes plans at the last minute. Notably, I'm expecting chaos when US companies realize in the next few weeks that their biggest customers are actually in the EU, and they have no compliance plans. Their customers will be looking elsewhere for compliant vendors as Americans scramble to understand what's going on.
At this point, it's inexcusable for any company to be caught unaware. Naturally, that won't stop management from making excuses.
There are a few ZIP codes that cross state lines, usually only by a small area. Thus there are combinations of ZIP and state that narrow down to a few dozen people, so knowing the age is enough to uniquely identify those folks. For the majority of people, yes, you'd need something else... but the minimal combination can identify some uniquely.
It makes a great example, because most people will make the same assumptions you have: ZIP codes are big areas, states are big areas, and lots of people share ages. It's not intuitive to think that those vague details could possibly identify someone. However, in these cases, it's not the majority that matters - it's the outliers. The majority of people in this ZIP code don't live in that state, and the majority of people in that small region don't have that age.
To the subject at hand, the notion of "personal data" used in GDPR is broad to the point of absurdity. It refers to a person who "can be identified, directly or
indirectly, in particular". That means that if it's possible to narrow down that person's identity, their data all has to be protected. To ensure compliance, then, you have to account for every possibility, including the chance that a strange combination will identify someone.
In fact, even the city itself can be an identification: Buford, Wyoming has only a single resident, and also has its own ZIP code.
My street address doesn't identify a person, either, but it is certainly personal data.
The problem is what can be done with the data, and whether you can reasonably expect to reach a person with it. A street address might just get you to a household or an office, but you can then ask around and probably find who you're looking for. Similarly, an IP address will get you to a city/region, and with the appropriate other logs (like ISP data, or another website, or the like), you can probably find a good guess for who you're looking for.
From a legal perspective, then, the balance lies between protecting everything that might aid identification (which is what the GDPR does) and protecting only the data that identifies individuals directly. From a security perspective, the latter extreme is practically useless, because it's trivial to correlate unprotected data to produce the protected identity.
This is why I said the GDPR isn't wrong in being broad with definitions. The risk is also broad. My concern with the GDPR is that there seems to have been very little consideration for just how crucial some of the protected data is for infrastructure's functionality.
I'm doing my own homework... and it's simply not agreeing with your assessment.
"Legitimate interest" also isn't mentioned in the FAQ. In the text of the GDPR, "legitimate interest" only comes into play for processing (under Article 6(1), point (f)) when:
processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.
Again, as it's written, logging an IP address would open an enterprise to liability, because they can't be sure that the IP address doesn't identify a child (or other person with required protection). According to Article 11, the enterprise wouldn't have to gather extra data to make that determination, but they first have to demonstrate that they don't have the ability to identify someone from the data they do have. If they have any other identifying information (like the shipping address in the case of the mom-and-pop store), then such demonstration would be impossible, and that limited protection would fall away.
If you look at the FAQ you see that the GDPR does not cover this use of data.
Oh, let me just look at that...
What constitutes personal data?
Any information related to a natural person or ‘Data Subject’, that can be used to directly or indirectly identify the person. It can be anything from... a computer IP address.
Well, crap. Maybe I don't need to worry if it's just a log?
Unfortunately, the actual text doesn't mention logs at all. Neither does it make any exemption for temporary storage, and it also doesn't actually define boundaries for what's "data mining", since it includes no mention of data mining at all. In fact, most of its restrictions are on the "processing" of personal data. Let's look at what that is:
'processing' means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;
In other words, running grep on a log is processing. Looking at Article 6(1) and 6(4), the processing of an IP address (as any other personal data) requires either consent or official authorization... unless the personal data belongs to a child, in which case only official authorization will suffice, but there's very little I see here about what that actually entails.
Now, the GDPR doesn't actually enact law itself; that's up to the Member States. Those laws could be better-written to allow reasonable things like a traffic log where the identifiable information is never intended to be resolved, but under the text of the GDPR, the laws could also be broad enough to forbid such things.
Tell me, what of my personal data beyond billing and shipping data for my most recent order would a Mom and Pop shop need?
IP address, for one.
The GDPR is very broad in what it considers "personal information", and it's not necessarily wrong. There are a lot of ways to identify someone*, and unfortunately some of them are built in to our basic technologies, like the Internet. Under the GDPR, though, all of those potentially-useful bits of information must be protected and scrubbed.
That means your Apache logs can't have any actual log data. It means your shipping labels are handled like highly-sensitive personal information. It means your vendors have to be able to prove GDPR compliance, or you aren't compliant yourself - and you're responsible for checking up on that.
The regulation itself isn't onerous... it's the lack of limits and high penalties that become a double-edged sword. In my opinion, a staggered implementation would have been much more reasonable (such as allowing non-compliant vendors for a year), and tighter definitions with exemptions (like allowing 30 days of incidental logs) would drastically reduce the cost of implementing the remaining regulations.
* In the US, the combination of ZIP code, state, and age can identify someone, and that's all old tech. Now we have IP addresses, connection latency, user-agent strings...
I'm going to guess you've never actually had to report process violations... There's lots of nice words thrown around in training, like "no retaliation", "anonymous reporting", and "immediate stop-work", but the reality that often happens is that the stop-work call is overridden by a senior manager who has a deadline to meet, the anonymity falls away when HR is in an office with a big window at the end of the hall, and if the person you called out has just enough brain cells to realize that the HR processes will take time, they can use it against you.
Never assume that HR will function the way they're supposed to. After all, they are generally there to protect the company, not the employees, and a harassment lawsuit is much scarier than a mere process violation.
But I digress...
...would ask Bob what Alice said SPECIFICALLY.
When an HR department asks (a week after the fact), Bob simply has to lie and say "I don't remember", and "she's always second-guessing me because I'm short". Then HR stops caring about the safety violation, and starts looking at the harassment (after another week), instead. If Alice tries to explain (three weeks in) that there was actually a violation, Bob can simply deny it (a month after it happened), and it looks like Alice is trying to hide her own discrimination.
Sure, eventually the truth might come out if anybody remembers it for that long, but by then it's been two months of time where work keeps pushing forward, without any change to ensure Bob is actually following processes.
He would say, "Alice told me my tie was a safety violation because I was in the robot area." HR would the ask Bob if he was actually wearing a tie in the robot area. Bob would answer "Yes"
Again, in relation to the "insecurity" comment I made earlier, Bob does not necessarily have to intend to lie. You're assuming that Bob is cognizant of his own error after being told. After a few days of justifying his actions to himself, he could tell HR "Alice was yelling at me for being in the robot area, but that's where I was supposed to be working. She's always second-guessing me because I'm short." HR never asks him about wearing a tie, because Bob never mentions it - to him, it's just a normal part of his attire. The scenario then plays out as above, but Bob is a completely-innocent victim in his mind. Again, he has no reason to change, because his mistake was never the focus of any discussion.
you've demanded you be allowed to ascribe intent (that their mistake is through being "lazy") while demanding they should not ascribe intent (belittling) to your ill-chosen words
I don't have to judge what's a stupid failure or not. In my team, pretty much every process is documented. The documentation is available to everyone. There simply is no good excuse to not be following the documented processes.
To be clear, I don't care (and thus don't "ascribe intent") whether someone is actually lazy, inattentive, arrogant, overconfident, or any of the myriad other reasons that would cause someone to screw up a documented process... If you're doing it wrong, then you're doing it wrong, and the reason doesn't matter, and doesn't even need to be discussed.
you've started to label people's races as "insecurities"
No, I said that they can pick an insecurity and claim prejudice against it.
Let's run with an example. The perspective I'm arguing for will be played by "Alice", and the arbitrary teammate will be "Bob". Alice and Bob work on robots. They're big robots, of the kind that will injure and/or kill someone in a few seconds if something bad happens, which is why the processes say that loose clothing is prohibited while working in the robot area. Bob wears a suit and tie to work, goes into the robot area, and Alice notices.
At this point, our hypothetical situation diverges. Under a restrictive conduct policy, Alice has to stop and consider how Bob might be offended if she were to intervene. He's a professional, and must be assumed to be fully competent, regardless of the obvious danger to himself and others that he's caused. Even hitting the e-stop and trying to politely explain the security hazard might be perceived as being condescending, so from the perspective of the conduct policy, the safest option is to let Bob continue to work as he pleases, until a suitably-nice reminder can be sent to the team reminding everyone to follow the safety procedures. Alice can then hope that Bob will be suitably inspired to go read the procedures, and catch the one particular rule that he wasn't following, and learn from his mistake enough to not repeat it.
That's clearly not a good choice. Bob's still in danger, and the opportunity to effectively correct his mistake is lost.
Let's suppose Alice does hit the e-stop, and tells Bob (in reasonably polite terms) that his necktie is essentially a well-behaved noose. Unfortunately, and completely unbeknownst to Alice, Bob is a big fan of fancy clothes. He happens to be rather short-statured, and feels that wearing a suit and tie helps make him appear to be a stronger leader. To Bob, any problem with his attire is just an attack against his height. Bob then goes to the HR and complains about discrimination.
Now, we don't have to assume good faith on Bob's part. He may, for whatever reason, hate Alice intensely, and be looking for a way to get her in trouble. Following much the same logic as above, but without the genuine offense, Bob can go to HR and complain about Alice's supposed discrimination. The result is the same: Either way, Alice is now facing a discrimination complaint, and Bob has dismissed Alice's warnings, not realizing he was actually putting his own life at risk.
Well, it's a government contract, passed through several rounds of subcontracting... In the eyes of management, the risk of having to redo documentation and approvals is scarier than the risk of data loss. There's no risk to reputation, because this architecture was properly approved by the customer back when it was built, when the builds were only a few tens of megabytes. Any failure now is not our problem.
ZFS is not permitted, for reasons mostly boiling down to either "we didn't pay enough money for it" (for anything BSD) or "that's too expensive" (for anything Oracle). Free (as in beer) is a big scary concept according to one of our contract terms, but they still won't approve purchases.
I've been pushing the idea of a BTRFS-based NAS to get most of the same features, but even going to a NAS at all is a big architecture change, enough to require many assurances that "centralized is a good thing" and "this is cheaper in the long run (of the next 2 months)". Add on to that that BTRFS is new and scary, and the guy in charge just wants a nice big RAID 5 array, because that's what he's comfortable with... and I don't have nearly enough rum to discuss this further.
Slashdot Mirror
But how did they get such a database in the first place?
SQL injection, malware, physical compromise, buffer overflow, side-channel attack, credential reuse, DNS hijacking, ARP spoofing, unpatched vulnerabilities... Pretty much for any attack vector you can think of, a password database is one of the potential targets.
As an example, let's consider the credentials to a web service, stored in a RDBMS. If that web service is insecure in particular ways, SQL injection can be used to dump the entirety of the database contents to an attacker's screen (which can then be converted into a nice username/email/password table).
And if they could get their hands on the password database (typically a highly protected file), couldn't they already get their hands on any other information they wanted that was on the computer?
Now yes, the SQL injection could probably also be used to manipulate the database in other ways, but that might not be the goal. Modifying the database for a financial service won't make the API calls to move money. It may be necessary to actually use another person's access, necessitating the hash reversal.
Another example, which is much more likely to be encountered in low-security environments, is the problem of credential reuse. If the attacker finds an administrative user in the database, there's a good chance that user's password is also used on internal systems, like that precious ssh server. If that password is weak, the whole enterprise is open to compromise, because of a SQL injection attack.
Even if there are no vulnerabilities (or worthwhile targets) in the company whose database was dumped, there are a lot of other targets that could be impacted. Notably, all those email addresses with usernames and passwords attached. Crack those passwords, then go hit the mail services and try them. Only one login failure per account, but you have thousands of email addresses to try across dozens or hundreds of mail services. With access to an email address, there are a lot of options for a criminal enterprise:
Information often isn't the end goal. Very often, database dumps and other attacks are just the intermediate steps in a criminal campaign to find victims for another attack.
I am not sure it really matters all that much if a password is weak or medium or strong.... eventually they can be cracked and get at least some accounts.
Unfortunately, from a user's perspective, this is out of your hands. If a service isn't salting their password hashes, then somebody's credentials are going to be broken quickly. However, it doesn't have to be yours, because you can make your password long and random without a salt, so the use of fast brute-forcing methods won't be effective (and the slow methods will take longer than the lifespan of the universe, with today's technology). In another worst-case scenario, you can assume your password for that service will be broken, and you can only hope for damage control. Turn on multi-factor authentication, enable activity alerts in email or SMS, and make sure your password is unique so it can't be used to get access anywhere else.
Again, because long and unique passwords so drastically improve one's security posture, a password manager is the easy route.
I use KeePass personally, and its built-in password generator has the following options:
It also has options to only allow characters to appear once at most, forbid look-alike characters like "O" and "0", and simple prohibit certain characters.
Use a password manager, and you never need to remember what rules were in use where.
The college that conducted the study is in the Philippines. The experiments were run against the college's student email accounts... which does raise a few easily-dismissed ethical concerns, but I digress...
There's really no reason to assume the USA would be involved at all, other than the reference to NIST, which isn't too surprising. Many places refer to NIST standards, just to avoid a certain standardization problem.
Database hash dumps don't care about what online-attack rules you put in place.
Once they have the hashed-password database, it's just a matter of time before the attacker gets somebody's password. The goal is to make sure it's not yours, by using a long and totally-unique password... precisely what a password manager is good at generating and handling.
While the volcano is busy breaking down the plastic to elements, it'll still release a lot of those half-broken molecules as debris and ash, many of which will float on the air over to populated areas. In Hawaii, those areas are also the places that bring in that lovely tourist revenue.
You're essentially suggesting we use a volcano as an incinerator, without bothering to put any filtration or scrubbers on the exhaust. Granted, the heavy stuff will be completely destroyed... but the lighter stuff will be just as bad as any other incineration. It might be possible to capture the released gas and try to filter it, but I suspect the higher heat of the volcano will make building such a structure rather difficult.
Doesn't it seem like this is a problem better handled by cheap, disposable sub-drones that can get close enough to identify a wedding?
Those "cheap, disposable sub-drones" are anything but. If they're disposable, they have to be replaced. That means ongoing expenses and increased supply lines out to forward bases. If they're cheap to the point where quality is compromised, they won't last long enough to complete the mission, and the enemy gets a chance to run away before the actual bomb drops.
Or a bomb that drops but doesn't detonate until a camera on it can verify that it's not a wedding?
So we put a camera on a bomb, hope the camera survives the drop, then wait patiently for the impact dust to clear, then get a video feed... and still need a human or an AI to look around and decide the small area of visible surroundings is or is not a wedding. Gee, I hope none of those terrorists ever get our secret can-of-spray-paint defense system.
We don't need to bring fuzzy logic into this. It's not the solution.
Well, it still seems better than the other ideas you've proposed.
That's pretty much what already happens. Drone operators are told "we have a report of a training camp holding a meeting here... go find it". Then the op flies around looking for a meeting, sees a bunch of gathered people, and with no indication to the contrary, command orders the strike. The idea that it might be a wedding never crosses anyone's mind.
Adding an AI means there is now an unbiased process looking for alternative interpretations. The AI doesn't care what it's "looking for"... it just tries to guess what it's "looking at". It won't get a commendation for finding a good target, and it won't care how much the commander really wants to have a mission. It just says what it sees.
There is still a human there. Maven is just an object-recognition system, that highlights objects in (usually low-resolution) drone video feeds. For example, it'll identify whether the 20-pixel object in the back of a pickup truck is actually a goat or a machine gun. It's still a human who decides whether to actually launch an attack or not.
The sociopaths are the ones using drones to bomb weddings.
Uh... The people using the drones are the ones asking for an AI to tell them "Even though the local informant said this was a training camp, it looks more like a wedding".
The standard defines the protocol and technical details. The alliance defines the legal framework that lets vendors cheaply implement the standard, without worrying about touching each others' patents, or exposing themselves to other liabilities. It also allows vendors to gain the marketable feature of a "works with other brands" logo, and the legal ability to sue others that use that logo without actually being compatible.
In a perfect world where everyone was honest and patient and only implemented standards perfectly, business alliances wouldn't add anything. In this world, however, they add a legal and political safety net for vendors.
...and what do they do in the mean time?
Do you think there's anywhere else in the world with existing facilities to build Apple's products at anywhere near the same cost or quality? There are a few places that have the technical ability, but they can't handle the scale of Apple's production.
Even if Apple wants to spend the piles of money needed to enter the fabrication, chemical processing, and manufacturing sectors, they don't have the experienced people on staff currently. They don't have the factories built. They don't have the supplies of raw materials already mined or shipping. All of that takes time, during which Apple would be trying to invest heavily in itself with no revenue stream, and their highly-captive customer base would start migrating elsewhere.
Google is in a different, but similar position. Their hardware isn't so critical to their revenue, so they could afford to simply let product lines die off while encouraging Taiwan to increase capacity. Unfortunately, Google wants to keep their money as a war chest to fight against Amazon for the "ubiquitous information services provider" title. That means they can't invest as much of their own cash into the necessary expansion without some serious compromises, like killing off or reducing their own products for a few years.
However, Google does have a major advantage over Apple: They really aren't in the hardware business much at all. Their Pixel phones, for instance, are actually Google-branded HTC devices. HTC is Taiwanese, so it probably already has a few secret business plans for how to handle being cut off from mainland China, likely involving sourcing chips from other fabricators, or indirectly acquiring parts in such a way that their vendors aren't traced to be supplying Google.
In both cases, though, there would be several years of disruption to normal business, which in turn disrupts American technological progress, and provides an opportunity for Chinese companies to absorb the excess of high-quality parts and expertise locally... You know, exactly the goal of a trade war.
There are a few other similar mechanisms that would make that process feasible, like founding a new company, which then merges with all of ZTE with an appropriate contract to keep everything intact. It'd have to be executed carefully to maintain viability while avoiding the ban, but such things have worked before.
Either way, you are absolutely correct that this is an investment nightmare. Even if a ZTE holding isn't already considered practically worthless, there can't be much confidence left in the current management, so even if they can pull off a restructure through a loophole, I would expect a new round of executives at the top, and certainly down whatever chain broke the sanctions.
To address your points in reverse order:
So this is not "every piece of personal data is forbidden". That is a huge misconception.
Certainly not "forbidden" by the regulation, but in practice. If I go tell my manager "our server logs have IP addresses", he's not going to launch an inquiry into whether that personal data can be combined with anything else, and he's not going to let me get fully-encrypted storage for our highly-sensitive logs. He's going to say "get rid of them".
Practically, he doesn't have a choice. Keeping the personal data means our lowly web servers are now a focus for compliance, which means even if we do nothing else, we have to have additional process reviews, audits, staffing for those audits... His choices are either a nebulous expense for compliance, or turn off logging and hope the troubleshooting is the less-expensive option.
Also, some kind of personal data are more sensitive and given special status.
While that's true, the GDPR doesn't really distinguish different sensitivity levels. Rather, the GDPR considers even weakly-identifiable information (like an IP address in a webserver log) as still being "personal data", and if it can be combined with anything else (like by correlating timestamps to database entries) in the enterprise to produce an identity, it has to be treated like it's all directly identifiable. Despite it being a data-handling best practice for many years, there is no concept of a "Chinese wall" screening information from different processes.
The huge problem arises when you gather a shit-load of information on people that you really don't need and start data mining that.
In the GDPR text, there is no distinction between "data mining" and any other kind of "processing" on stored data. There is also no limit on scale. If I have a comment form on a website that asks for a name, and that's stored in a database, I am collecting and processing personal data.
That's pretty much my complaint about every part of this thing. It's horribly vague, to the point that normal daily operations become regulated activities. It'd be fine if the "processing" definition had a limit on it like "any operation... for the purpose of inferring more information about the data subject", but there's no such thing. That would arguably cover any data mining or user-tracking process, but leave an exemption for basic things like logging or mostly-anonymous interaction.
Ah, no. The Member States can have their own laws that are stricter if they want, however they cannot make laws that nullify the GDPR or parts of it. But unless they have a law of their own, the GDPR is in effect. That is why the new GDPR is a regulation rather than a directive (which the GDPR was replacing).
I understand that. To clarify, I'm hopeful that the laws are more clear than the GDPR, defining "personal data" and "processing" with a bit more restraint, and allowing for isolation practices. Such things could be written carefully to avoid actually contradicting the GDPR, again mostly because the GDPR just blissfully ignores such concepts entirely.
I've read (the majority of) the regulation text, I've read the analysis articles, and I've sat through the meetings discussing whether or how it applies to my own company. I feel like I've done my effort to educate myself.
So what exactly am I misunderstanding? Where's the authoritative source that says "IP addresses aren't identifiable", or "processing doesn't include that", or any of the other fine details that seem to be curiously missing from the actual regulation text? So far there's a lot of folks commenting to say "you don't understand", but nobody that actually wants to put in the time to explain what I'm missing.
Understood, but I'm rather pessimistic when it comes to business agility, especially regarding compliance.
If it's enforced May 25th, most companies won't aim for compliance before May 24th, because they want as much time for their own changes as possible. Since a company's compliance is dependent on their suppliers also being compliant, there's a cascade effect if a critical supplier isn't able to meet their deadline, or changes plans at the last minute. Notably, I'm expecting chaos when US companies realize in the next few weeks that their biggest customers are actually in the EU, and they have no compliance plans. Their customers will be looking elsewhere for compliant vendors as Americans scramble to understand what's going on.
At this point, it's inexcusable for any company to be caught unaware. Naturally, that won't stop management from making excuses.
There are a few ZIP codes that cross state lines, usually only by a small area. Thus there are combinations of ZIP and state that narrow down to a few dozen people, so knowing the age is enough to uniquely identify those folks. For the majority of people, yes, you'd need something else... but the minimal combination can identify some uniquely.
It makes a great example, because most people will make the same assumptions you have: ZIP codes are big areas, states are big areas, and lots of people share ages. It's not intuitive to think that those vague details could possibly identify someone. However, in these cases, it's not the majority that matters - it's the outliers. The majority of people in this ZIP code don't live in that state, and the majority of people in that small region don't have that age.
To the subject at hand, the notion of "personal data" used in GDPR is broad to the point of absurdity. It refers to a person who "can be identified, directly or indirectly, in particular". That means that if it's possible to narrow down that person's identity, their data all has to be protected. To ensure compliance, then, you have to account for every possibility, including the chance that a strange combination will identify someone.
In fact, even the city itself can be an identification: Buford, Wyoming has only a single resident, and also has its own ZIP code.
My street address doesn't identify a person, either, but it is certainly personal data.
The problem is what can be done with the data, and whether you can reasonably expect to reach a person with it. A street address might just get you to a household or an office, but you can then ask around and probably find who you're looking for. Similarly, an IP address will get you to a city/region, and with the appropriate other logs (like ISP data, or another website, or the like), you can probably find a good guess for who you're looking for.
From a legal perspective, then, the balance lies between protecting everything that might aid identification (which is what the GDPR does) and protecting only the data that identifies individuals directly. From a security perspective, the latter extreme is practically useless, because it's trivial to correlate unprotected data to produce the protected identity.
This is why I said the GDPR isn't wrong in being broad with definitions. The risk is also broad. My concern with the GDPR is that there seems to have been very little consideration for just how crucial some of the protected data is for infrastructure's functionality.
I'm doing my own homework... and it's simply not agreeing with your assessment.
"Legitimate interest" also isn't mentioned in the FAQ. In the text of the GDPR, "legitimate interest" only comes into play for processing (under Article 6(1), point (f)) when:
processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.
Again, as it's written, logging an IP address would open an enterprise to liability, because they can't be sure that the IP address doesn't identify a child (or other person with required protection). According to Article 11, the enterprise wouldn't have to gather extra data to make that determination, but they first have to demonstrate that they don't have the ability to identify someone from the data they do have. If they have any other identifying information (like the shipping address in the case of the mom-and-pop store), then such demonstration would be impossible, and that limited protection would fall away.
If you look at the FAQ you see that the GDPR does not cover this use of data.
Oh, let me just look at that...
What constitutes personal data?
Any information related to a natural person or ‘Data Subject’, that can be used to directly or indirectly identify the person. It can be anything from ... a computer IP address.
Well, crap. Maybe I don't need to worry if it's just a log?
Unfortunately, the actual text doesn't mention logs at all. Neither does it make any exemption for temporary storage, and it also doesn't actually define boundaries for what's "data mining", since it includes no mention of data mining at all. In fact, most of its restrictions are on the "processing" of personal data. Let's look at what that is:
'processing' means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;
In other words, running grep on a log is processing. Looking at Article 6(1) and 6(4), the processing of an IP address (as any other personal data) requires either consent or official authorization... unless the personal data belongs to a child, in which case only official authorization will suffice, but there's very little I see here about what that actually entails.
Now, the GDPR doesn't actually enact law itself; that's up to the Member States. Those laws could be better-written to allow reasonable things like a traffic log where the identifiable information is never intended to be resolved, but under the text of the GDPR, the laws could also be broad enough to forbid such things.
Tell me, what of my personal data beyond billing and shipping data for my most recent order would a Mom and Pop shop need?
IP address, for one.
The GDPR is very broad in what it considers "personal information", and it's not necessarily wrong. There are a lot of ways to identify someone*, and unfortunately some of them are built in to our basic technologies, like the Internet. Under the GDPR, though, all of those potentially-useful bits of information must be protected and scrubbed.
That means your Apache logs can't have any actual log data. It means your shipping labels are handled like highly-sensitive personal information. It means your vendors have to be able to prove GDPR compliance, or you aren't compliant yourself - and you're responsible for checking up on that.
The regulation itself isn't onerous... it's the lack of limits and high penalties that become a double-edged sword. In my opinion, a staggered implementation would have been much more reasonable (such as allowing non-compliant vendors for a year), and tighter definitions with exemptions (like allowing 30 days of incidental logs) would drastically reduce the cost of implementing the remaining regulations.
* In the US, the combination of ZIP code, state, and age can identify someone, and that's all old tech. Now we have IP addresses, connection latency, user-agent strings...
A competent HR department...
I'm going to guess you've never actually had to report process violations... There's lots of nice words thrown around in training, like "no retaliation", "anonymous reporting", and "immediate stop-work", but the reality that often happens is that the stop-work call is overridden by a senior manager who has a deadline to meet, the anonymity falls away when HR is in an office with a big window at the end of the hall, and if the person you called out has just enough brain cells to realize that the HR processes will take time, they can use it against you.
Never assume that HR will function the way they're supposed to. After all, they are generally there to protect the company, not the employees, and a harassment lawsuit is much scarier than a mere process violation.
But I digress...
...would ask Bob what Alice said SPECIFICALLY.
When an HR department asks (a week after the fact), Bob simply has to lie and say "I don't remember", and "she's always second-guessing me because I'm short". Then HR stops caring about the safety violation, and starts looking at the harassment (after another week), instead. If Alice tries to explain (three weeks in) that there was actually a violation, Bob can simply deny it (a month after it happened), and it looks like Alice is trying to hide her own discrimination.
Sure, eventually the truth might come out if anybody remembers it for that long, but by then it's been two months of time where work keeps pushing forward, without any change to ensure Bob is actually following processes.
He would say, "Alice told me my tie was a safety violation because I was in the robot area." HR would the ask Bob if he was actually wearing a tie in the robot area. Bob would answer "Yes"
Again, in relation to the "insecurity" comment I made earlier, Bob does not necessarily have to intend to lie. You're assuming that Bob is cognizant of his own error after being told. After a few days of justifying his actions to himself, he could tell HR "Alice was yelling at me for being in the robot area, but that's where I was supposed to be working. She's always second-guessing me because I'm short." HR never asks him about wearing a tie, because Bob never mentions it - to him, it's just a normal part of his attire. The scenario then plays out as above, but Bob is a completely-innocent victim in his mind. Again, he has no reason to change, because his mistake was never the focus of any discussion.
I think you've missed a good part of my point...
you've demanded you be allowed to ascribe intent (that their mistake is through being "lazy") while demanding they should not ascribe intent (belittling) to your ill-chosen words
I don't have to judge what's a stupid failure or not. In my team, pretty much every process is documented. The documentation is available to everyone. There simply is no good excuse to not be following the documented processes.
To be clear, I don't care (and thus don't "ascribe intent") whether someone is actually lazy, inattentive, arrogant, overconfident, or any of the myriad other reasons that would cause someone to screw up a documented process... If you're doing it wrong, then you're doing it wrong, and the reason doesn't matter, and doesn't even need to be discussed.
you've started to label people's races as "insecurities"
No, I said that they can pick an insecurity and claim prejudice against it.
Let's run with an example. The perspective I'm arguing for will be played by "Alice", and the arbitrary teammate will be "Bob". Alice and Bob work on robots. They're big robots, of the kind that will injure and/or kill someone in a few seconds if something bad happens, which is why the processes say that loose clothing is prohibited while working in the robot area. Bob wears a suit and tie to work, goes into the robot area, and Alice notices.
At this point, our hypothetical situation diverges. Under a restrictive conduct policy, Alice has to stop and consider how Bob might be offended if she were to intervene. He's a professional, and must be assumed to be fully competent, regardless of the obvious danger to himself and others that he's caused. Even hitting the e-stop and trying to politely explain the security hazard might be perceived as being condescending, so from the perspective of the conduct policy, the safest option is to let Bob continue to work as he pleases, until a suitably-nice reminder can be sent to the team reminding everyone to follow the safety procedures. Alice can then hope that Bob will be suitably inspired to go read the procedures, and catch the one particular rule that he wasn't following, and learn from his mistake enough to not repeat it.
That's clearly not a good choice. Bob's still in danger, and the opportunity to effectively correct his mistake is lost.
Let's suppose Alice does hit the e-stop, and tells Bob (in reasonably polite terms) that his necktie is essentially a well-behaved noose. Unfortunately, and completely unbeknownst to Alice, Bob is a big fan of fancy clothes. He happens to be rather short-statured, and feels that wearing a suit and tie helps make him appear to be a stronger leader. To Bob, any problem with his attire is just an attack against his height. Bob then goes to the HR and complains about discrimination.
Now, we don't have to assume good faith on Bob's part. He may, for whatever reason, hate Alice intensely, and be looking for a way to get her in trouble. Following much the same logic as above, but without the genuine offense, Bob can go to HR and complain about Alice's supposed discrimination. The result is the same: Either way, Alice is now facing a discrimination complaint, and Bob has dismissed Alice's warnings, not realizing he was actually putting his own life at risk.
Well, it's a government contract, passed through several rounds of subcontracting... In the eyes of management, the risk of having to redo documentation and approvals is scarier than the risk of data loss. There's no risk to reputation, because this architecture was properly approved by the customer back when it was built, when the builds were only a few tens of megabytes. Any failure now is not our problem.
ZFS is not permitted, for reasons mostly boiling down to either "we didn't pay enough money for it" (for anything BSD) or "that's too expensive" (for anything Oracle). Free (as in beer) is a big scary concept according to one of our contract terms, but they still won't approve purchases.
I've been pushing the idea of a BTRFS-based NAS to get most of the same features, but even going to a NAS at all is a big architecture change, enough to require many assurances that "centralized is a good thing" and "this is cheaper in the long run (of the next 2 months)". Add on to that that BTRFS is new and scary, and the guy in charge just wants a nice big RAID 5 array, because that's what he's comfortable with... and I don't have nearly enough rum to discuss this further.