When I listen to security people rant, I can see their points and it's a bit of fun, I like a good rant. But I get the impression that they're continuously discovering new and exciting ways that individual facets of individual pieces of software (and the processes around them) suck. All without ever accepting that the entirety of the software ecosystem sucks (and that they're rarely moving the needle on that front).
All software and the internet combined is a giant ball of mud that just grows and grows as more people add onto it. There's no architecture more than the strict minimum to keep the whole thing from falling apart the moment someone breaths too heavily near it. And that's not even including when commercial interests keep trying to design their chunks of the mudball in unique ways that make themselves more money at the cost of everyone else's chunk getting more complex.
Like everyone else adding mud, security wants to get in, hit their requirements, and get out. I just don't like the chip on their shoulder that nobody else is doing enough to fix the system throughout in a way that helps them achieve their goals with the least fuss.
FYI I am in fact an FP fan, and I use FP principles in a large amount of my code. But I've seen some seriously convoluted and confusing FP code just like I've seen behemoths of objects with twisted internal state manipulation balancing on blind assumptions and false guarantees of order.
This is key. They're not the ones pushing to replace C/C++, even though you'd think that would logically follow. In that way, infosec is the DEA of IT.
As a software engineer, I think this is my experience at every job I've had around systems in general.
As a person sometimes overly distracted by grammar, I would like to thank you for using the "As a [description of subject], [subject] [rest of sentence]" construction correctly. Getting this wrong, which is called a "dangling modifier" error, is common. Examples from today's front-page HN discussions:
As a new (1 year) coder starting out at 39 years old, this sounds very similar to the path I envision for myself.
As another former Googler, yes, searching the entire monorepo was a frequent occurrence.
As a new (1 year) coder starting out at 39 years old, I envision a very similar to the path for myself.
I'm another former Googler. Yes, searching the entire monorepo was a frequent occurrence.
(or maybe I was just adhering to Muphry's law https://en.wikipedia.org/wiki/Muphry%27s_law.)
(I found this mildly interesting!)
It is fascinating to me that the content (written 20 years ago) reads like an up-to-the-minute description of the madness of IT today.
The continual repetition of anti-patterns is so widespread and commonplace that it is clear to me that expediency will almost always win-out against any engineering prudence.
Expediency gets assigned highest priority -- typically without any real reasoning. The negative effects accrue slowly but consistently -- and correcting for the shortcoming gets consistently more difficult.
The condition is then self-perpetuating.
You have to accept that there's no perfect alternative out there, you won't tomorrow magically find a system with no flaws, and system design is hard because the world is constantly changing and you don't have perfect information. If you just chase "something better" because you can't accept things, you'll continue to be disappointed.
Once you accept it, you can start trying to make your little corner of the world better. Not perfect, but better. It's more satisfying than shouting into the void.
There's always more work to do. On almost everything. As a former co-worker liked to say: If it wasn't hard, they wouldn't pay us to do it.
If you thought it was already perfect there would be no reason to.
As a two developer company with four separate products doing nearly $500k in ARR collectively, Kumu  is a living example that it doesn’t have to be this way.
We rely heavily on bash, docker and cloudformation.
We only use Ubuntu LTS and we lag a release behind so there are plenty of tutorials available when it comes time to upgrade.
After experimenting with backbone, coffee script, flow, vue and multiple redux libraries we’ve settled on rewriting everything in typescript and developing our own thin redux abstraction.
Embrace new tech that makes developers’ lives easier while hopefully making things more secure too.
I get it if that’s not possible in large enterprise companies, but please don’t throw all software under the bus. Software is and will always be fun and there are still fun companies to work for if you’re willing to take a little risk.
I can look at the product I develop and rattle off an impressive list of capabilities, talk about how well it is designed, say why it's the best product for the job on the market and talk about successes in the field. But I can also look at it and see a laundry list of design flaws, architectural limitations and unrealized enhancements that may never get time on the schedule.
The second side of the fence exists, and security people inherently spend a lot of time there. Spend enough time there and you see how the system that is the sum of all software is a mess. I'm not even saying it's a bad thing, just that it's the inescapable reality.
Your architecture is like swimming in a school of fish. By moving with the group you benefit from the successes of the group. Ubuntu, docker, typescript and delivering your product as webapp brings a lot of benefits in featureset, maintenance and training that come at a reduced cost. For the same reasons I also prefer to use as much popular off-the-shelf tooling as possible and stick to familiar designs wherever possible.
You're probably doing better than most. But even with all that benefit, the components of your system are fraught with defects and limitations that in a perfect world would already be solved problems. Both in the stack you use and your own software. And you make it work despite that. Great. That's not my point.
To me, most of the critical comments seem to miss the point that your frustration centers around the foolishness of trying "go as fast as possible" while at the same time "your shoelaces are tied together."
Be happy that you have a job that compensates you well, aligns with your values, is flexible to your personal needs, allows you to grow professionally, and enables you to reach for the goals you've set while you're here on earth.
And if that doesn't describe your job, please quit and come work with us or any other company that respects you as a human being first and a sysadmin second. Life's too short to do otherwise.
(I am a maintainer of runc and have contributed to Docker for a long time, as well as collaborated with the LXC folks.)
I am actually working on improving the current state of OCI images by using a snapshot-based tree structure -- which will also solve many problems we have in OCI that are independent from LXD. But it is possible that the LXD folks would be more interested if the OCI format more closely matched what they need.
Though it should be noted that LXC has had an OCI template for several years now (and it actually uses a tool I wrote -- umoci -- to extract the OCI image).
I find the distinction between "system containers" and "application containers" to be a bit arbitrary from a technical perspective. What does it matter what I'm running as PID 1? I find both system containers and application containers to be useful.
It seems like LXD would see larger adoption if it were easy to run docker container images directly (built into the LXD tooling).
2) Department of No doesn't have to be a thing, it just takes some emotional intelligence and pragmatism. 'Always saying no' is as much the fault of the sec eng as it is the system. If you have the will power and general positive mindset, it's more than easy to go through a sec career without getting angry. It just requires not default No, and ....
3) Understand people want to do a good job. If you tell them they're doing a shitty job, they'll tell you to fuck off. If you (sarcasm font) admire what they're doing, and have some stuff that can get added to build an even better product, people are surprisingly amenable to working with you. It seems like 70% of sec folks think their job is to say No, and as a result never get there.
4) This was a huge lesson for me that made me understand the field: to be successful in sec, you must learn that your personal risk tolerance will not always equal the enterprise's risk tolerance. Making money, in a digital field, is an inherently risk-on undertaking. It's crucial to know what to not escalate beyond your team, what to not cause a fuss about, what is just a known risk that will continue to exist, and then have clear requirements for what risk you will escalate and shake cages about.
It seems like all of these sec rants boil down to seeing the system and being unwilling to work within it, vs. seeing the system, accepting it, and figuring out how best to navigate it, and what tools and personal skill sets I'll really have to maximize to succeed in it.
This is the key. Mastering "yes, but" will not only make people like you more, but will also change your personal outlook on situations and avoid burnout like the author. Even if you don't realize it, there's a very different emotional impact between "I had to say no to that proposal" vs "I presented the options for that proposal, and they decided to not go through with it". For lack of a better term, it's no longer "your fault".
From the article:
>No, we can't do that. No, it doesn't support that. No, the vendor doesn't allow for that. No, you don't have the right license. No, no, no. Isn't the point of technology to enable businesses? So why am I saying no so often?
Because you're shit at communicating. Yes, we can do that, but you'll need to (pay for X || do Y || get Z to do this other thing). Yes, but your current vendor doesn't support that, although vendor Q does. Yes, but your current license doesn't do that, you'll need this license instead.
The joke is once you present the "effort" required to do what they want to do, 80% of the time they'll give up on it anyways. It's the same end result. But you didn't have to say no!
Boss: You are advocating spending a lot of money on a configuration management solution, why?
Sec: Well it can help prevent heterogeneity in our environment which can lead to different versions of software being run, some of which may be old and buggy and therefore exploitable.
Dev team: So now we need to do change management meetings and institute even more controls? No, this will slow us down!
Ops: Sigh, another fad system we will have to support, learn, and test.
Boss: This seems like a lot of money and inconvenience for a theoretical problem, no.
Sec: Because it's a win for the business. Our Dev teams can avoid dependency hell and be confident that code they develop on their machines is going to work in production because our production environment will mirror the development environment. This will let them ship faster and spend more time doing real work. Ops will be able to scale much faster and spend less time dealing with configuration issues. Imagine being able to develop a config and spin up 50 servers with it at the same time while you sit back and sip a soda! No more fixing damaged boxes, just replace them! No more fighting with the dev teams! Oh yeah, we also get a security benefit for free while making our lives easier as we won't have to deal with heterogeneous software running on our boxes which presents a security vuln. The ROI for the business will be large.
Everyone: wow sounds great, let's do it!
I think this depends on what kind of infosec work you plan to be doing. I have been a security engineer for the past 4ish years, and while I do have some programming/scripting skills it certainly isn't at the level of a SWE. Most of the projects I work on I end up doing pentesting, risk assessments, remediation for compliance, assisting with policies/procedures, and/or security focused devops work. It would definitely be useful if I could program at the level of an SWE, and I do plan to continue to develop my skills, but I wouldn't say that to be in infosec you have to learn to code at the level of an SWE. I agree with all your other points
I've had at best mixed results with covering people with positivity and admiration in an effort to get them to fix things. It's often easy enough when it's something really small that looks easy and understandable. When you've got a whole architecture predicated on everything accessing everything unchecked, suggesting that maybe this absolutely amazing architecture could be even better with a tiny bit of TLS and authentication is unlikely to get you anywhere.
All of this leads to non-technical sales people becoming the de-facto source of product feedback. Which leads to non-technical middle managers making product decisions with a short-term mindset. It's impossible to do a good job under conditions like this, so folks just check out and clock their 40 per week.
I think this is the cause of a lot of burnout. People get emotionally invested in their work, but the way tech is structured, quality doesn't matter as much as velocity. Individuals don't fully understand how much impact their work has, so it can seem like toiling away in obscurity for years on end. That doesn't feel good to anyone, but when the company is making 35% margins it's really easy for them to ignore the cash bonfire.
Been doing extreme over-hours in the hope of fixing stuff once and for ever, only to realize your job becomes more and more like shit-shoveling, since management starts to feel invincible (and protected by your contributions), which leads them to make even more errors without accountability. I've seen some of them with tears in their eyes when I finally quit. 'nuff said. Profiteurs!
Legal departments have been dealing with this problem forever too. Such is the plight of being in an assurance function.
Induced demand doesn’t just apply to traffic, it turns out. https://en.m.wikipedia.org/wiki/Induced_demand
I'm afraid there's no solution to this. In the end we are all humans. How does one even begin to solve a psychological problem at a large scale like this?
Isn't that when you start earning a lot of money?
This is very dangerous thinking. Figure out why this true if it is not already obvious.
* Not sustainable
* Not healthy
* Not scalable
No sarcasm here. Try to avoid this thinking-trap.
Haven’t been able to put my finger on it exactly (definitely a multi dimensional issue), but I don’t think the issues you outlined will continue to fly if you want something of quality that’s not half baked.
This excerpt from agile manifesto comes to mind as part of the problem that I’ve coming to disagree with (at least how I’ve seen it implemented in the past):
> The best architectures, requirements, and designs
emerge from self-organizing teams.
The product my current employer is working on suffers immensely from a lack of central leadership to the point where each of the pieces of the application have different (and sometimes contradictory!) ideas of what the world looks like.
It's absolutely maddening.
In my experience, central leaders want to impose grand sweeping worldviews that just aren't true when you get into the weeds of particular use cases. The Director gets a pretty architecture diagram but the engineers actually building and maintaining the feature live in a train wreck. And for what? You don't actually need uniformity across unrelated parts of the system. Architecture shouldn't be about a director's view of his kingdom, but about engineers' ability to sustainably deliver business value, which starts with using the right abstractions for the problem at hand.
As a backfill, many orgs are forcing people to pinch hit that are in over their head (not their fault, often times they are also stepping up to help which is great!) The problem is that these people & teams get to the point where they are just trying to survive until the next sprint.
Wash & repeat sprint to sprint, deploy something to check the box but it’s building a house of cards.
Since you want to stick with theoreticals, a lot of great projects come from groups of close friends working together. You need a "fantastic lead/architect/product manager" when a team like that isn't available, and you need to compose one artificially.
Combining my experience with GP, the glib, almost tautological, answer is that you fix the problem by not letting "non-technical middle managers" make technical decisions. Actually implementing this in an organization that already suffers from it is a political problem which I don't have any advice on. For orgs where this isn't a problem yet, the answer is simple. If you're a technical organization, don't hire non-technical managers. Every single person in my management structure started out as an engineer or researcher and it works remarkably well.
Tech is just worse because we haven't unionized like both of those industries did, so the companies are able to operate in a way that is more exploitative of its workers. I think that's actually the source of the outsized margins we see in tech. Agile is just shorthand for "it's too expensive to coordinate things so we'll just make our engineers do that on top of being engineers". The solution is to unionize and start to demand some standards in engineering discipline that allow people to have both a career and a life.
Where can I find this? Sign me up -- please!
In industries where engineers are unionized.
No one in management wants the expense or the overhead of actual security. They want the "theater" of security, the good feeling, the box to check on their resume (as management) so everyone can pretend everything is fine and go back to the business at hand. Then something real happens, a leak of user data, or credit cards or internal memos... suddenly everyones job is security and no one knows what to do. The last problem gets solved, there is more "theater" and a few quickly forgotten changes that get worked around or just ignored in the long run.
Furthermore your average engineer wouldn't eat a ham sandwich handed to them on the street by a stranger but will happily run code from 100's of other people on their servers with out even looking at it. Note: I too am guilty as charged. Sure you can vendor it, and miss out on future security patches (it was already broken). Or you could just pull it from whatever repo you got it from to begin with and pick up new flaws. Never mind the fact that pulling from random places assumes that all those other chains of trust remain un-compromised.
Management and Engineers should be the ones most concerend and most thoughtful regarding security and both seem to ignore it for cost and convenience reasons till it is (far too late and) a REAL problem.
And don't forget the universal elixir that cures all security ills: adding even more rules about which passwords are allowed.
We would however eat one provided by a café that our colleagues recommended.
My biggest burnout was when internal teams I worked with started to feel like external teams. That was more
about engineering teams but another example: I strongly discouraged internal IT from adopting vendor/client language and mentality.
Relationships like that put them on the back foot, become defensive, and when you encounter problems the sense of being able to honestly ask what’s actually going wrong here? evaporates.
I probably wouldn't eat a sandwich from a bootleg café.
The incentive is that if every box was checked and shit hits the fan, insurance is on the hook to pay for stuff and not the company or the responsible party.
This is a natural result of a very competitive market place and, as far as I can tell, its rational if you take that circumstance to be an immutable state of affairs. Its no good stopping to dot the i's and cross the t's if, in doing so, you get completely edged out of the market by a competitor who isn't doing so. And you haven't even made the world a better, safer, nicer place by doing so. You've just left the door open for someone less scrupulous to beat you with a shittier product.
The solutions aren't palatable in the current philosophical mode: much more aggressive penalties (corporate death penalties, for instance, in which shareholders literally lose all their money) or much tighter and well enforced regulations. Move fast and break stuff truly is the philosophy of the day.
If you don't want to break stuff, you have to make moving fast less competitive. As far as I can tell, that's the only way.
We didn't take into account loss of sales and reputation, the equation is not (should not) be that simple
The OP is quoting Tyler Durden, a fictional character of the movie 'fight club'. So take it with a grain of salt.
But don't dismiss the merits of the idea. It's essential Risk Management, which is most certainly a relevant part of Information Security. Specifically, this is a form of Cost-Benefit Analysis (specifically, Qunatativie Risk Analysis), a critical component in proper Risk Management; the reality is you cannot "fix" every issue.
Take a look at methods like Single Loss Expectancy and Annualized Loss Expectancy; you'll find that the Fight Club quote is very close to the real-world methodology. I cannot speak for the Automobile Insurance industry, but given Insurance is founded in Risk Management, it seems likely to be closer to reality than not.
It confounds and mildly pisses me off when people get pissed and get burned out over suits not caring about infosec. I mean,they care about promotions,reputation,bottom line,ROI,KPI,etc... That's what they do. You know why the marketeers and buzzword snakeoil salesmen prosper? It is because they communicate not only risk but especially [fake] solutions better! Infosec is full of user and management blaming, expecting peoppe outside of software developers and infosec practitioners to care about infosec. I am not saying I have it figured out but I am fairly certain users and decision makers need to be told solutions within the context of risk that affects them. And if it doesn't affct them they're not supposed to care.
I'll give you an example, a network is filled with tls1.0,and ssl1.3, how does that affect some mid sized company's bottom line or reputation? How do they get ROI on the man hours and resources spent to upgrade everythig to TLS1.3 with proper cipher suites and key exchange? and what KPI can they use to measure efficiency of resources? How will you tell them security hygeine takes a very long time to show ROI as do many other security concepts?
You don't really have to do all that if you don't want to, plenty of skill demand to where you can progress to more exciting positions.
Security was just not a concern until they had a major breach. The security teams had been screaming bloody murder for a while, but could not get the product teams to allocate sprint bandwidth to the massive, coordinated security hardening effort that needed to happen to prevent a potential headline in the New York Times.
Mgmt/non-sec care about pretty clear, often profit-oriented metrics (ROI, etc.). There is such a clear precedent for successfully internally selling, implementing, and creating buy-in for cost-producing (i.e. infosec) but business-saving practices. Insurance, financial risk departments, legal departments etc. etc. etc. Sec can fall under that too. Sec people don't bother to learn the language 90% of the time. Sec people then burn out because they feel they're paddling nowhere.
Failure to learn that ^ language as a sec eng, means you fail to learn how to successfully implement sec in a way that has lasting buy-in. It's doable. It takes a bit of leadership, a bit of buzzword-learning.
If you want to play ball with mgmt and not be a mindless keyboard monkey sec eng who has no care if people care about sec or not, you must be able to take all those sec thoughts, distill it into 3 power point slides and 120 seconds of 'so what,' and be ok doing it over and over.
Legal constantly fights the same fights. They get those systems put in place because they acknowledge that fighting these fights is a critical aspect of their job and they make sure those control points are in place. Before I became an InfoSec PM I consulted for legal departments to fight those internal fights for them. They’ve had decades to refine and develop best practices around how to do these things.
Also places where everything is blocked by default by legal are generally badly run legal departments and have plenty of handshake agreements and covert business activity going on the same way places with intransigent and uncooperative InfoSec or enterprise architecture ends up with tons of shadow IT. They’ve been moving towards automated review and self-service tools to speed things up for a while now.
Why does legal succeed then? Partially, there are pretty firm laws covering risk, that haven't quite caught up to sec breaches and such (but this is clearly beginning).
However, the big reason: Legal can explain the 'so what' because of that shared common language. Sec folks seem to largely not bother learning how to translate tech jargon to 120 seconds and a power point slide or two that business can understand.
You think a million a year is expensive? It's not - not if it's saving you a $200m fine, and possible class action damages.
All of this sort of thing leads me to think that there is currently a huge mismatch between the security products industry, and how companies implement all the conflicting white paper snake oil, and what the ACTUAL vulnerabilities are. And I know how stupid this mismatch winds up making the average Fortune 500 worker bee's daily life. But that's a topic for another post.
I think it's difficult but there's almost no doubt that Yahoo would have people who understand the problem with security. The problem is, were they, and did they have the power to reign this in at scale?
All too often, you get risk people buying products then asking for all your logs, promising the easy silver bullet. Being a pessimistic engineer, you're unlikely to ever be near a leadership position with people who want easy answers.
I mean, who else is buying a SEIM, asking for all logs, and then hoping it'll take care of everything? That's the CISO, Director, VP, Head Of, etc.
A few months ago everybody was up in arms about a "major" security issue discovered by an auditor (you could see the settings of random users by changing an id in a url).
I've just shown them you can credit money to your account, yet this is low priority and they provided a fix that I'm 100% percent sure didn't fix anything, unfortunately the functionality is down on all but the production environment. I'm tempted to just credit myself 1 monetary unit in production and just show them the statement.
I would be tempted too, though I could bet that this will be a termination of an employment, instead of the problem being fixed.
I would like to be proven wrong on this speculation..
I'm just impatient because it's a really clever and somewhat complex hack that challenges some multi-threading and transactionability assumptions some people mande and I can't really talk about it(which I'd love to share with my peers).
And make sure your contract covers your ass, under production system testing / penetration, or something similar.
The bug that lead to me discovering the security issue was mitigated by another developer, the security issue was also deemed fixed, I am 100% it was not, but there's no way to proove it at the moment, except u production, that's why I said I was tempted to actually do it.
Anyway, there's nothing much to gain by me by antagonising another coleague, the management or the bank. It's not worth the ego boost or frustration scratch, worst case scenario, I don't patch the issue in time and the bank looses money and they start taking security more seriously.
I can understand every piece of the long string of factors that lead to this ridiculous situation where such a serious security issue is not being addressed; any one in particular is not ridiculous, but they all compound to the ridiculous of the end result.
I've fixed another ridiculous security issue in the recent past without making big waves, where only one software architect understood the seriousness of just one option in a maven config file(a whole declarative security module was not being weaved into the bytecode because somone added another module and instead of both being applied, only the most recent one was being applied).
The actual friction will come from Windows sysadmins with no other practical skills.
Techies repeating this should take a lot of the blame for why Windows still sell as well as it does.
A 50 year old electrician convinced me to start using Ubuntu 13 years ago after someone at his kids elementary school or something had told him.
UX wise Linux passed Windows in many areas around the time Ubuntu was introduced.
The only reasons now are prefererence, hard dependencies on Windows only software, stubbornness and incomptence.
Only the two first ones are good reason in my opinion.
Is this something you decided on your own was a fact? If I disagree, would I be wrong, stubborn and/or incompetent?
Things Linux did better at that time:
- installation experience, os: installation of a "pre-installed" Windows laptop could take up to 4 hours before you had finished completely.
- installation experience, additional software: I was good at removing Windows spyware and adware back when that was a local problem. Never had any Linux user with that it problem.
- driver issues: 50/50, since around that time hardware would mostly "just work" unlike Windows were one would typically, again at that time, have to hunt around the Internet or dive for the cd. Reason why Linux don't win hands down was because if something wasn't supported it would often be a dead end until next distro release, sometimes longer.
- end user support, other ux issues: the same, which means Linux probably win with a comfortable margin since Windows had the benefit of everyone "knowing it" and still didn't come out way ahead.
- in addition Linux typically is faster, even to this day, which is a huge issue with some users.
You might have noted I wrote in many areas, not all.
For users who earn their livelihood with Autocad and Photoshop I'll have a hard time recommending Linux. Same goes for people who have tried Linux for a few weeks and still don't like it. It might be preference or it might be stubbornness, I don't care.
But blanket statements like the one I replied to:
> As well as cutting 98% of your workforce as no office employee knows how to work on anything different.
is just plain wrong. The fails here are mostly related to other issues, not dumb users. (I really don't like that idea that all users are so stupid they cannot change adapt.)
Also, I wouldn't conflate UI and UX.
I'm certainly not going to object to you having that view, but if that's how you see it then it's not a very interesting discussion is it? Would be like discussing whether the Beatles were better than the Rolling Stones "in many ways".
For what it's worth, I believe you are very wrong. But I understand and kind of appreciate this view, largely because it keeps me employed.
If anyone needs Excel they get it.
So far I've spotted I one person that probably uses Excel. No complaints that I've heard or seen.
Most of my work with a wildly spread organisations and we can have excel go through US to Russia to Uk Back to Ukraine and then back to me in the UK
This is why I think one of the key things is in stack standardization (choose best in class foss tools that match requirements, for example, I personally have a gpl or gpl compat requirement), and stack size reduction (which means you don't need every fancy sounding tool that you hear about, make sure the use case is justified first).
People have such a stockholm syndrome relationship with MS (and proprietary sw in general) it's absolutely sickening. For example, I think educational institutions should be teaching and using FOSS first.
Some will whine about no one using linux or not knowing how, and one response I use is "you had to learn how to use windows too, and even it changes things up, just look at 7 to 8/10, so why not learn to use gnu/linux and free yourself from MS?"
But from a company's perspective, if they have to pay 1M for an infosec team over five years, or 1M for a breach once every 5 years, what's the difference? You're still paying the same amount of money.
When does infosec start to realize that it's not just about company costs/risks, but the lives of all those users who are going to get screwed when your 'low risk = cheap fix' mentality pays off?
I'm in the Equifax breach (like sooooo many more)... part of my 'general concerns about the world' is whether/when I get my life hacked and have to rebuild.
Let me know where you get hired next, so I can take my business elsewhere.
> lives of all those users
Equifax cares about one thing: earning profits for its shareholders. They got caught with their pants down. Now other companies can look and try to estimate their expected cost of being breached (probability of being breached multiplied by the dollar cost) vs the dollar cost to upgrade their IT systems, infrastructure, management, company policies, etc etc etc. Realistically, Equifax is probably incapable of doing the necessary changes upfront without a complete overhaul of it's people and leadership structure.
The vast majority of companies will spend the least amount of money possible to pretend that they fixed the problem.
You want companies to care? Then create regulation that protects
I believe that is a good reason to be accepting towards the current state of affairs. People just don't care. They have more important issues to deal with, deadlines to meet, problems to face.
If you are frustrated and pissed off, great. That means you get it, and that's great!
Now, meditate -- the journey to a perfect secure world will take some time, like beyond your current life span. It's not until you accept that reality that you will make real change globally. Because it takes time, a lot of time.
Thanks for your effort so far.
Now I realize that my dad is frustrated I never learned something as simple as changing the oil on my car.
My mom does not understand how I can't name more than two flowers and can't bake a pie.
My legal-minded friends are astounded I do not take a day to work on my legal status to pay less taxes. Hell, my wife does the paperwork I am not even sure of the tax rate we are paying.
And yet, I see myself as pretty curious, jack of all trade. I understand many things about CS, mechanics, electronics, manufacturing, politics, economics, ecology... We live in a complex world and we rely on each other to make it work.
Love each other, we really depend on each other, it is easier if we don't consider others stupid for choosing different areas of skills.
Most of their interactions were with local businesses, with people who, like themselves, were part of the local community. The unofficial grapevine worked pretty well for rooting out the good and bad mechanics, lawyers and florists. Your dad could change the oil, but almost certainly knew which mechanics could be trusted to have done what was on the invoice, and the few to avoid at all costs. Mostly if really was OK not to care, because they knew someone who did. The network meant something. Doubly so in smaller towns, and yes, small town life came with some downsides too. :)
That breaks horribly when recommendations are of global mega-multinationals, and most businesses on most high streets are national and international chains. A recommendation counts for nothing for a business of that scale, and an individual vote may be an employee you might never encounter again. The network means nothing, except as something to be gamed. Taking your custom elsewhere means nothing unless a million or two others do too. You have to care as no one else gives a shit about your interests, just the sale or commission. Except precisely none of us have the time for that.
If we want the benefits of larger scale business I think we need to start giving them some responsibilities too. Like a duty of care in law as exists in some areas already, but further reaching to consider the public interest as a priority. Without something the power imbalance is impossible.
Without constraint, large business takes the piss. It's time for some constraint. Then maybe we actually can depend on each other again.
I am the one living in the countryside not far from a middle-sized city. I do know, from local community's word of mouth the reliable and cheap mechanic and florist.
Don't fell in the fallacy that things changed globally because you moved from one place to another ;-)
Tracking reputation has never been easier. If you are interested in it, that is.
Occasionally the wheels come off (maybe literally) and someone with significant power ends up in jail. But realistically - how often?
Which is why software security and quality aren't a thing. There's no pressure to do the job properly and plenty of incentive not to.
I won't name names, but doing some work for some company in IT security space once, I learned that one of the issue they faced in sales is that the product cannot be too good - because if it points out to a possible vulnerability and then that vulnerability gets exploited, the customer may be on the hook financially and legally, as the software could prove they knew about the problem and didn't address it.
Worked in enough safety-necessary environments (military weapon handling, warehouses, shipyard) that the very idea of deliberately whitewashing a possible failure just makes me angry.
Lessons learned briefings were some of the best OJT I ever had.
I'd have filed CVE's on whatever they told you to leave uncovered and damn the consequences.
(I've also never been in a place where I could afford to be let go, so YMMV/MMMV).
Thank you for this insight, particularly the concise manner in which you have articulated it.
If their bank account is drained they will care, and get angry, and then maybe do something (but preferably the bank will recompense them in which case they feel better and go back to not caring).
Some stuff you just can't do; as you say the world's too large, but many people don't want to put in the effort to learn stuff that would benefit them immediately, never mind over the longer term.
I really do not understand people.
Well, then learning more about people's psychology and motivations seems like a thing you could benefit from immediately :)
Given that I do recognise people won't change, would it help if I did learn to understand their builtin magic curtain / SEP field?
I ask with no hope any more, what do you advise?
Being acceptant of that has the upside that you don't need to know the background of a given individual (some people have a rough life, others just don't think they will get it e.g. think they are not smart enough, others are just working 400% and have kids), to accept the fact that they will just use tech and maybe don't care about the inner workings. But is that really a bad thing? Because that's exactly how they are built know adays, ease of use.
I have people around me that I want to explain basic things in life to, but.. even if they actually listen their previous argument float to the surface the next day. People need to change themselves.
In the other end of the park there's a big playground. That's where I sit and design the biggest sand castle I've ever built. I don't care that much about running around, I switch playground when I have too.
Each mindset have their pros and cons. I solve stuff that takes a bit of effort. My SO keeps our life/house running.
So respect and acceptance about others choices is a great way to let go of anger that nobody is interested in the things you are interested in. Finding someone with the same mindset in real life is rare, even on HN. How cool is that?
I take it you're not counting yourself in that group? Have you already learned everything that would benefit you immediately?
"Everything" and "Everything that would benefit you immediately" are not the same thing. But I don't think there's much to gain from more bickering here, let me just retract my comment.
I try to make those tradeoffs consciously. If I decide x is valuable but boring, these days I'll measure it against other priorities, if it wins I force myself to do it.
So I try. It's an acquired skill which I'm still working on.
For people living in the US, that's just basically an act of God now. The refusal to have a decent ID system has made identity theft laughably easy. Even with top-notch computer security, if you have ever shopped online or swiped a card in a shop that doesn't do in-depth background checks of its employee, you are at risk.
If you cared to, you could learn how.
And most importantly, love yourself and don't let others disinterest get to your spirit of making good.
You are interested in economy and politics, yet you don't know how to file taxes. Is that not connected?
If you understand mechanics, yet can't do maintenance on your car, not even talking about fixing anything.
This level of theoretical knowledge that can't overreach to reality to do basic tasks seems just irrelevant to me. What is it good for apart of talking about it?
Based on your respective comments, I'd expect that the writer of the grandparent comment is the former type, while you are more the second type. Both are fine.
There is nothing wrong with being focused on just few issues.
But I have doubts when you claim some knowledge without being able to use it practically, which is what I see here.
If I'd say I'm jack of all trades, as I'm interrsted in software - but i hire a guy to make all the code for me because I don't know how - and that I'm very interested in knives - but my wife sharpens our knives as I don't know how - I have doubts about your actual knowledge if those fields.
I like watching youtube channels like Demolition ranch or Iraqveteran8888 for their technical expertise, viewpoints and just fun. Without any real expectation to ever own a gun to expand on this knowledge. Maybe some nice bow one day (which these channels don't even cover).
Don't expect everybody acting rationally all the time, considering cost/benefit against all activities, or similar.
But if your knowledge can't fulfill your need in same field, what is that knowledge for, or is that even actual knowledge?
Never said he couldn't change the oil on his car, just that he never bothered to.
Didn't say he couldn't do his taxes, just that his wife takes care of it.
Anyway, yes the author says we are worse today, but keep in mind that we "just" connected a few billion devices. It will take a massive effort to get that fixed properly and keep all up to date security wise.
Nevermind that goverments wants to ban security in some places.
Yes exactly this. Information technology has improved at a totally crazy rate, and I think it's unrealistic to expect safety and sanity to keep pace, The internet has only been around for 30 odd years, and getting all this right takes time. To examine another technology, the automobile was invented in 1885, seat belts were invented more than 60 years later, and it was another decade or so until they were made mandatory for new cars (in the US at least).
As a user of technology, I want the exact same thing. I'll do research to build a PC, or install a new OS, and tinker with it until it works to my satisfaction. Then, I never want to touch the internals again and I want them to just work. I get very upset when my product stops working.
Same for cars, cell phones, computers, etc.
As software devs, it's our job to make this possible for users.
Why is software expected to be different? Why should it be? Why does your grandma require a basic understanding of password security anyways?
The author argues that it will never happen because we are WORSE today than we were before and I agree with that.
Seriously. Security decisions that demolish UX can tank entire products.
Recent-ish example: Oracle VirtualBox. Used to love that software and I would recommend it to friends needing VMs. They added a new hardening feature that makes it unusable on my setup for whatever reason (VMs fail to start with "hardening failures"). There is no option to disable the hardening feature short of going into the source code figuring out how to disable it and building from scratch. It's like geez, I don't even care about hardening - I'm not trying to analyze stuxnet or some ransomware virus here, I just want to work on my web app in between classes at school on my windows laptop.
There's a massive FAQ on the VirtualBox forums on how to debug hardening failures. I spent about 5 hours working through the FAQ and troubleshooting before I just said "screw this" and bought VMWare which worked perfectly first try. I no longer recommend VirtualBox to friends - I tell them it will likely give them headaches and to use VMWare or WSL instead.
Note:  is actually pretty entertaining thread with insane security people defending the new terrible hardening issues of VirtualBox.
Ironically they had a serious production incident that almost took the entire (large) company out for a day because they were doing load testing in one environment (they had about 10 separate environments) but they had shared email infrastructure between production and the production-1 environment. The application being tested generated zillions of emails using "real" email addresses that clogged up their production environment.
It was a remarkably risk-averse client.
While I was there it was extremely difficult to transfer a log file from one of their workstations to my laptop for analysis during a debug session. It was also extremely difficult getting new builds into the setup since there was no easy way to get the binary file into their workstations.
It is absolutely true that everything can be hacked if they try hard enough, so the question is — how hard do they need to try, and what resources do they need?
As you reach an answer to that question, you either consider that level of investment a credible threat you need to worry about (in which case you invest in tightening things up) or you don’t (beers at 5?).
Also, the nuanced posture can look like the defeatist attitude if you don't pay attention to the details —and, on the flip side, you need to pay attention to those same details to tell a proactive attitude from security theatre.
Sometimes, the vulnerability was then exploited, and what shocked me was that people were okay with this. I won't name names, but one marketing department I worked with was happier to suffer a customer data leak over having to spend budget during the end of the year to fix the issue. I later learned that the IT department got in trouble for allowing the error to happen, when the system was entirely managed by us and our sole point of contact was with someone in marketing that left their position because they didn't get on with IT.
If there's one thing I learned, it's that the ultimate currency in business is risk, and that the software/IT industry lacks the power to really do anything when a company is found to be negligent. For many, the risk of "being caught" is worth not spending money on preventative issues, and ultimately there's absolutely nothing we can do about it outside of covering our asses when the finger is pointed our way.
You only need to look at the Panera Bread security breach to see that all the badmouthing on Twitter did nothing to stop the company from painting its own narrative. Hell, the WordPress theme/plugin company Pipdig was caught ddosing its rivals with their software, and all they had to do was lay low on social media for a month and lie in a blog post. The worst part was that their non-techie customers were all too happy to back them up, meaning that the WordPress security community had zero clout to really do anything.
I have the utmost respect for anyone that works in security, because you're fighting a battle that no one wants to win, and is often a battle where it feels your partners are silently rooting for the other side.
They didn't actually change the passwords, since that would break too many things at once. So you could just look at the git history to get the plain text password. Or debug the application locally.
Security theater all day. Sigh.
I would love to see a whistle-blower company formed, where you could report software engineering malpractice, and be compensated and/or protected from being punished. Not necessarily a union, but an industry body that could verify your security concerns and either "out" a company for punishing you, or provide you x months of work and a reference to compensate the termination of your employment.
Also, I'm so sorry you had to touch EDI, if you did.
GDPR has put some fear back in, but even today there are loads of companies that simply don't give a shit, and will happily risk it all so that they don't have to adapt their practices from years ago. In my experience, smaller companies are the worst offenders, because they know they are small fry.
Pipdig are a UK company, and have been actively caught using malicious code with proof, yet they're still running without a care in the world. This all happened recently too, so it's not like it's a pre-GDPR or pre-ICO crackdown issue.
And this cannot be avoided while working as an employee, it's part of the system.
The good news is that there is one way to avoid this (the only way AFIK) is to start your own company, there you get to call all the shots for good or for bad.
It doesn't have to be a big company though, it can be just you and a laptop for starters.
Other than that, as an emotional coping mechanism and to preserve their mental sanity, people will simply become disengaged and cynical.
Take longer breaks and try to have a laugh with your colleagues to blow some pressure and make friends.
Also, because things work badly in those environments, there is a lot of blame deflection going on, which is one of the main causes of stress and burnout.
Again, part of the system, not much that you can do about it other than learning to deflect responsibilities to others.
Getting rid of the hot potato is a very important skill in these corporate settings.
Usually on a team, it's always the same people getting the short end of the stick. Try not to be one of them if you can, but often that's easier said than done.
Also, try to get promoted, you will get more responsibility and might even be able to fix some of these things, that's another positive attitude towards chaos that helps a lot of people cope with it.
These days it's doable to at least get a second monitor. But for things such as an SSD drive? At least a couple of years ago it was nearly impossible.
The reason why burnout is frequent, is because in general in most places work conditions are bad and stressful. In my view the problem is the system and not the people.
Your professional setting seems like a good example of how it doesn't have to be like that.
First of all, we live in an imperfect world, so there always needs to be a search for balance. No company is perfect, and if it were, we'd be out of a job, so to speak. The balance needs to be that there are enough things going well enough, for you not to get burned down (burned out, pissed off). Enough of the "problems" must be challenges, and actionable, and still excite you to solve them. If this is not the case at your place, I see three possible outcomes:
1. You be cynical. For a miserably long time to come
2. This is not the right company. My experiences are very different. I get cynical about a thing or two, but on balance I love what I do. So look for a better workplace
3. You're not in the right line of work. No hard feelings. Go do something else, I beg you
You will be stuck with an old slow PC trying to fix some issue until midnight, and that just takes a heavy toll on people.
As things can't work well, there is a lot of responsibility deflection going on, it would be naive to think otherwise.
Also, a lot of these posts in HN assume that the only way to live is to work as an employee for someone else, under similar conditions.
It's important to realize that there are other professional options available, which many people won't even consider.
For your option list, I've seen a lot of 1. As for 2, there are lot more bad companies than good ones, and you can't tell from the interview process and can't also change each 2 months.
As for 3, half the workforce would switch jobs then. The problem is not the people, it's the system.
I would add 4, do contract work and stay while the balance of the good things / bad things about the job make it worth it, then do something else after a year or two when it doesn't.
This relates to 2, sometimes a company is the right company in the beginning, but it's no longer the case later on. For example, I bet you won't work there forever.
I managed to recover from a similar level of burnout/pissed-offedness by changing my domain of software development completely. I got out of high-stakes server-side software and into client-side mobile software. It took some effort to pivot, but in the end it was a great relief. In my experience, Apple's slow approval process is a much better problem to have than getting pinged at 3am for any reason.
It's offensive, and it's not how it should be, it's a "defect/defect" Nash equilibrium when we should be going for "cooperate/cooperate". So kudos to you for fighting the good fight - you deserve to win.
* Understand the true desired outcome
* Own delivering it
People who can't do the former are naive. People who can't do the latter are unambitious. You can go through life just fine being both.
BTW I'm quite wary of "security products" for enterprise; it reeks of antivirus software writ large. That said I can see some benefit to services like audits, or even things like honey pots or "dark net scans" for detecting leaks. But something tells me that's not what you're talking about...
The product itself is quite reasonable on paper . (And, yes, it would provide value even if all of the software industry would ramp up their security practices, so it's not a band aid like antivirus software.) The execution is the problem. Despise selling "nation state attacker secure" appliances, we are not internally focusing on producing a high security product but give priority to certifications and features. The disconnect between marketed identity and day-to-day developer experience is breathtakingly depressing... at least to those of us who have an interest in security. Management doesn't care of course. It sells (because of certification and little alternatives on the market), so all is well.
 Sorry for being so vague. Given the set of statements I've given already, anything more would make me personally identifiable to my coworkers.
Can you elaborate on this? Why would you say there is artificial scarcity for software?
Important note for HN readers: 'driving the price up' is a net benefit for programmers. Artificial scarcity is why you get paid big bucks.
Interestingly, data is legitimately scarce. But that's a discussion for another time...
You are assuming that my software is distributed.
Look 50 years ago you got a catalog from sears. You mailed a check, someone opened it, your order went to the warehouse, the check went to the bank, your items got picked packed and shipped.
The software I spent a good part of my career writing got rid of a LOT of people from that scenario. The hardware and software combination that is the ATM got rid of many tellers. MP3's killed record stores.
If you find a programer old enough, they will insult you by saying "I will replace you with a very small shell script". Many of us built software to replace people, many of us continue that. Our value is literally reducing costs and "enabling scale" at a massive discount. For those of us that do this sort of work, we are massively underpaid when compared to the manual processes that are replaced or never have to happen.
Once you build it, almost the only way to achieve scarcity is through IP law.
Well no, if it is hard to get software written people just won't bother. Most programmers will benefit from a commoditise-the-complement strategy where everyone is using software and need to hire programmers to tweak it to their exact needs.
The money is in support & hardware. Trying to primarily compete on software price is pretty risky; Open Source is quite competitive. The big paying companies in software (Googles, etc, of the world) don't particularly leverage IP law in their strategies. Even with players like Microsoft, artificial scarcity of their traditional primary products (Windows, Office) would be the kiss of death to the company.
I don't think there is much profit in hardware, most companies seem to work on razor thin margins.
Consider that Apple is America's most profitable corporation. They do squeeze people with software restrictions; and it is a core part of their strategy. But the focus of Apple has never been 'our software is rare', it has always been 'faster processor, thinner phone, better screen'. The artificial restrictions on the software aren't at all beneficial to the software or the programmers; they are part of a strategy to make the hardware more valuable. It is a strategic element to help their hardware resist the commodification of smartphones.
If they had inferior hardware then the restricted software strategy would see them crushed under the booted heal of groups like Samsung.
We've added complexity but we haven't increased our capabilities. What software can we make today that we couldn't 10 years ago? I'll even stipulate there could be a few examples, but 99% of the stuff we build today could have been built faster, cheaper and secured easier 10 years ago.
Maybe the market equilibrium means people don't get hurt enough yet.
Miserable in the sense that customers don't care, you have to be paranoid and brilliant at the same time, it can be weeks without an emotional payoff, yet everything is always urgent but rarely important.
Having watched some conference videos on the topic, the bro-toxicity is still strong in that field, too.
Yes, I 100% agree with your assessment of this person's post. They are running into what I would call, "the horrible realities of business", which have nothing to do with putting in too many hard hours at work and everything to do with being forced to deal with unethical/deliberately lazy people in the day to day of being a worker
People don’t give a damn and it’s mind-boggling. All you can do is shake your head and continue with your day.