181–190 of 193 posts
Earlier quoted context omitted.
As licensed professionals, they work under the knowledge that there are practices and outcomes that can cause them to lose their licenses.
Once again, may be it is time for such a thing to exist for software engineers who aren't web devs.
Earlier quoted context omitted.
Or CEO/CTO's buddy's company
The CSO apparently graduated with a music major. Not that it should it disqualify them, many in tech didn't graduate with a CS degree but in light of the incident one has to wonder.
Reasons are:
• It's hard to find technically skilled people who want to spend all day doing management tasks.
• It's easy to find essentially unskilled people who do want to spend all day doing management tasks.
• There is a large set of unwritten rules and social expectations that the people who created and run such companies use as proxies for competence. Do you dress nice, can you play an enjoyable game of golf, are you married, how old are you, etc. These proxies invariably de-select the kinds of people who have a deep understanding of their field (i.e. single young men who are able to devote enormous hours to their craft).
Edit: note the recommendations in her LinkedIn page. Every single one talks about her collaboration and communication skills, not a single mention anywhere of technical skills. It's tempting to shoot "Susan M" here but the real issue is a boardroom culture in which management is seen as a skill entirely divorced from the effort being managed.
This is embarrassing at this point; a credit authority printing dividends is too busy placating shareholders to even pretend to give a shit about the data of the people who _involuntarily_ have their PII stored on their platform. Whoever files a class action should make a motion such that anyone can purge their PII from a credit authority that's experienced a public hack such that their PII was exposed, or some other…
>purge their PII from a credit authority I can't see that happening if they do any kind of offsite back up and archiving. They will purge you from the current master, say they purged you, and you'll be none-the-wiser.
Then, purging a person's data would come down to deleting that key from the system and from all backups of the keys.
That makes it a bit easier; the set of all keys will typically be a few orders of magnitude smaller than the data, and could be backed up using separate systems. Those systems wouldn't have to be updated often and access could be better controlled.
You would still need procedures checking nobody writes out non-encrypted data (including database keys), but that's doable; a first level scan would just run strings on your raw disks.
Disadvantage is that this would affect performance, especially for reporting services (a query gathering statistics over your customers would have to fetch all your customers' decryption keys)
A step up would be to hand out not bare decryption keys, but pairs (decryption key, expiration time stamp) encrypted with a private key that only your database knows the matching public key of. That allows your database to detect when your applications reuse decryption keys for too long. Depending on application architecture, that pair could even be a triple (decryption key, session key, expiration time stamp), and 'encryption' of course should use a salt.
Earlier quoted context omitted.
>What if management doesn't hire a security team? That's clearly negligence. >What if management hires incompetent security team? That's harder to do because you have to establish competence, which has led to a bunch of hazing rituals via whiteboard for general software development and a lot of other insecurities. Being a security professional isn't regulated by law, so you can't check the law to determine if someone…
>What if management doesn't hire a security team? "That's clearly negligence." Great so you just made it illegal or impossible to create a start up, congratulations.
All of this is under the context you'd be handling a lot of PII or sensitive information, in which case, yes, I don't want just any start up to work with PII without some kind of security team.
Earlier quoted context omitted.
I think one of the problems is that it's just not societally necessary for 95% of software. If a game is shitty or an order entry system crashes occasionally, nobody dies. Nobody really even cares. Normal social and market mechanisms mean most software at least approaches adequacy. In at least some of the areas where we really care about software quality (e.g., banking, medical devices) there are existing regulators…
That would be acceptable if we were talking about buildings, a blue collar job. But if you try to apply it to a white collar executive you're going to run into social resistance of a great magnitude. White collar crime is a social norm and only very rarely even lightly punished. It is, to a degree, expected. White collar crime kills more people and does much more economic damage every year compared to street crime, b…
I would love to see that change. Right now, though, we're in a big wave of "inequality is great", which I think strongly contributes to this problem. Let's hope that wave crashes, letting us start to hold executives and managers accountable.
Earlier quoted context omitted.
This concept is really not at all portable to software, especially security. It's a tempting analogy, but an invalid one.
No, it's not even an analogy. The precise methods and regulations are almost directly transferable. People are doing it. It works. It just needs to be industry-wide.
Earlier quoted context omitted.
The data isn't public if it's in encrypted form. When you apply for credit, you'd decrypt it with your own private key and re-encrypt it with the creditors private key and send it to the creditor, they would then decrypt privately, process the application, and discard the data.
> you'd decrypt it with your own private key and re-encrypt it with the creditors private key and send it to the creditor Creditor's public key, not private key.
Earlier quoted context omitted.
>What if management doesn't hire a security team? That's clearly negligence. >What if management hires incompetent security team? That's harder to do because you have to establish competence, which has led to a bunch of hazing rituals via whiteboard for general software development and a lot of other insecurities. Being a security professional isn't regulated by law, so you can't check the law to determine if someone…
>What if management doesn't hire a security team? "That's clearly negligence." Great so you just made it illegal or impossible to create a start up, congratulations.
Earlier quoted context omitted.
You don't own your own data, unfortunately. At least not in the US.
I mean...you consent when you hand your details over to a financial institution. How credit reporting agencies end up with your information is very straight-forward. Save the alarmist rhetoric for the headlines.
https://www.nytimes.com/2017/09/08/technology/seriously-equi...
That sounds to me like I don't own my own data.
The only solution is to put the data in our hands only and we authorize access to it on an as needed basis. It should not be centralized anywhere.