Apache Struts Statement on Equifax Security Breach [LWN.net]

The Apache Struts project has put out a statement on the possible role played by a Struts vulnerability in the massive Equifax data breach. "Regarding the assertion that especially CVE-2017-9805 is a nine year old security flaw, one has to understand that there is a huge difference between detecting a flaw after nine years and knowing about a flaw for several years. If the latter was the case, the team would have had a hard time to provide a good answer why they did not fix this earlier. But this was actually not the case here --we were notified just recently on how a certain piece of code can be misused, and we fixed this ASAP. What we saw here is common software engineering business --people write code for achieving a desired function, but may not be aware of undesired side-effects. Once this awareness is reached, we as well as hopefully all other library and framework maintainers put high efforts into removing the side-effects as soon as possible. It's probably fair to say that we met this goal pretty well in case of CVE-2017-9805."

to post comments

Apache Struts Statement on Equifax Security Breach

Posted Sep 10, 2017 17:59 UTC (Sun) by ledow (guest, #11753) [Link] (26 responses)

Much more concerned that a web application has unchecked access to hundreds of millions of credit records, to be honest.

It pretty much doesn't matter what it was written in, how it was deployed, whether it was up to date. Obviously there was no separation of services, or controls to monitor unusual activity.

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 15:12 UTC (Mon) by drag (guest, #31333) [Link] (8 responses)

It is very likely not a single vulnerability that caused the breach.

Modern datacenters are extraordinarily complex systems. They are always going to be vulnerabilities. There are always going to be bad procedures, logs that are missed, applications that are wrong, systems that are in bad health, operators that are asleep or distracted, hard drives failing, etc etc. That's the nature of any complex system.

Once it rises above a certain amount of size and complexity then failures are the norm, not the exception.

In the case of credit cards information... if it's stored and made available to user accounts on the front-end and for billpay or whatever you need that information for.. then it doesn't matter how far and how deep you bury the storage. You could have a hundred networks, a thousand servers, a million firewalls and yet there is going to be a path from external systems to that credit card information. Without such a path it couldn't possibly work.

The only way to come close to 100% secure that sort of information is to never store that information in the first place and even then it's possible to leak numbers out into the wild.

So what happenned here, more then likely (I haven't looked at this particular case closely) is a cascade of failures. If the apache strut problem never existed then maybe the criminals would of just found a different way to exploit all the other failures that existed.

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 18:07 UTC (Mon) by Nelson (subscriber, #21712) [Link] (6 responses)

100% secure is very difficult.

A 100% complete and totally catastrophic failure is kind of difficult too though. You have to be pretty bad at things to have a complete failure like this. Being that their core business is selling queries to their databases, you'd think that just to bill correctly they'd have systems in place that would make it obvious when an unusual amount of traffic was being generated or something like that. There are lots of other questions too, they accept credit cards for payment to their various services, they should supposedly be PCI compliant and have undergone some routine audits; those and the exceptions they may have applied for would be very interesting details. I'd expect all these things to be completely separate concerns in a well architected business and this type of failure would require an APT that exploited numerous internal systems over a long period of time, pinning it on struts would be sort of a joke with that kind of situation.

Funny story about equifax. I have paid for their credit monitoring and fraud protection service for about 12 years (just canceled it over the weekend..) FWIW, the family plan pricing was pretty affordable compared to a lot of the alternatives. About 5 years ago it saved my bacon, a car dealership (I'm very certain of it) leaked my information and in a 3 day period 4 new credit accounts were opened in my name and there were 7-10 credit checks run on me. EFX notified me and I was able to shut it down quickly. It's ironic, I was thinking of ending the service but that happened. It cost me nothing but some stress as it was a Sunday and I had to make a dozen or so phone calls; so some stress and 2 hours on the phone. The next month, I got another alert from them, my credit rating dropped, I want to say about 13 points in Equifax' score but it was still in the great category, it was an inconsequential drop but it sounded and felt big and I watch the stuff like a hawk. I remember working very hard to get above 800 and it took a long time for those last few points. I called EFX up to inquire, I hadn't done anything but shut down some frauds that I reported to them, I was worried something else was going on. They told me that there were too many credit checks done on me and that can lower your credit score, I insisted that that didn't happen but they pointed to the 7-10 credit checks that were done fraudulently and I had reported to them. I won't bore you with the details but they wouldn't fix their own score even though I reported the fraud, they told me the score will naturally recover in time, that's the best they could do. That's the kind of business they are. Again, that goes back to my point about them being able to actually audit the queries to their database and bill correctly for them, cause it potentially hurts consumers with their own algorithms; likewise if they give their entire database to partners for some business reasons, then there are potentially queries that aren't factored in and maybe they should be.

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 19:50 UTC (Mon) by drag (guest, #31333) [Link] (5 responses)

> You have to be pretty bad at things to have a complete failure like this.

Everybody is this bad at this.

Organizations, unless checked by some external force, will have a tendency to grow continuously in complexity and size up until the point where the bureaucracy is reaches a sort of plateau of critical maximum inefficiency. The critical maximum inefficiency is where people have spent so much time dealing with the bureaucracy that they really don't have any time to do anything else... including making the bureaucracy more complicated. PCI compliance and audits and such things are just a example of bureaucratic road blocks to help manage risk. This is natural, often desirable, and are unavoidable in large organizations. But they are not silver bullets.

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 20:10 UTC (Mon) by jebba (guest, #4439) [Link] (2 responses)

Everyone isn't this bad at this.

To find out if you were compromised by Equifax, a PR company set up a Wordpress website with shared SSL certificates, and javascript pulled from multiple outside servers. This is just asking for it.

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 20:38 UTC (Mon) by ssmith32 (subscriber, #72404) [Link] (1 responses)

Even better, a reporter tried putting in random names and numbers to the WordPress site, and the response was the same, regardless..

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 21:05 UTC (Mon) by jebba (guest, #4439) [Link]

And the security PIN they assign at the end of the process is the timestamp, like 0911170330 for 3:30AM on 9/11...

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 21:48 UTC (Mon) by Nelson (subscriber, #21712) [Link] (1 responses)

Not everybody is bad at this stuff, that's just not true. Who else is this bad at it? HBO and Sony are the only examples that come to my mind and they didn't lose my private data. There is another analogue: how many times has Amazon or Walmart shipped something that they sell that wasn't actually bought on their website? Don't forget that they sell access to this data, that's how they make money. There very business model requires auditing access to it, they need to have those kinds of systems in place just to do what they say they do.

I'm not suggesting that PCI compliance is a silver bullet here, I'm simply asking if they were compliant or what exceptions they had. They would have had to undergo a third party audit, Verizon or somebody gave them a stamp of approval.. I think this sort of event might be the external force that checks these guys. Get those names out there, get the details out there.

Apache Struts Statement on Equifax Security Breach

Posted Sep 12, 2017 3:06 UTC (Tue) by drag (guest, #31333) [Link]

Every single company you mentioned had significant data breaches at one point or another.

> I'm simply asking if they were compliant or what exceptions they had.

From my experience working in the financial system.. If there is a regulation or industry standard this company would comply with it. That's just par for the course. Not even a question. They are a core part of how the financial industry in the USA functions on a fundamental level.

When you get to this level the difference between who does the regulation and who is the regulated starts to get very blurry. I don't know the details ,but I entirely expect that Equifax is going to have very close relationship with the major banks in the USA, which are the ones that are responsible for defining and enforcing PCI standards since they are the people that own the credit card companies.

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 20:43 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]

There's no need for one service to have access to ALL the data:
1) each service should only manage a slice of the data; ssn, DL, address, etc. All information is merged on the front end, not in a single service.
2) per connection/per user/per session quotas. It should not be possible to request more than X records, even in the slice of the data that the service manages.

So, yes, it looks like there may have been some really dumb mistakes made.

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 16:14 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (16 responses)

It seems more productive to be concerned that in 2017 a record of plain facts about you is a significant threat. Credit records are unavoidably embarrassing, but we've had decades to get past the point where access to those records should actually put you at risk of fraud for example.

One reason to think this way is that just because the CRAs have industrialised the collection of this data doesn't mean nobody else can get it with a bit of work. You can be a victim of one particular criminal who has targeted you even if you're not one of millions whose data is lost in bulk. So we should fix the actual problem rather than wring our hands every time there's another breach.

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 20:03 UTC (Mon) by rahvin (guest, #16953) [Link] (2 responses)

The best fix here is a legal fix that places strict privacy regulations on the data (something that will never happen). The data can't be stolen if they aren't allowed to store it in the first place.

Apache Struts Statement on Equifax Security Breach

Posted Sep 13, 2017 16:24 UTC (Wed) by ScottMinster (subscriber, #67541) [Link] (1 responses)

You can't just make a law without consequences for breaking it. And some data has to be stored sometimes. So I suggest making the consequence for this sort of breach is that the company would have to compensate each individual affected an amount, say $1000 for each piece of privacy critical information revealed. Include criminal liability for people who try to cover it up. If this were the law, then Equifax would be looking at having to pay out hundreds of billions of dollars. And thus they would have a really good reason to make sure that breaches like this don't happen in the first place. Either through increased security or just not storing data they don't really need in the first place. And the real victims of the breach, the individuals, get some form of compensation.

Apache Struts Statement on Equifax Security Breach

Posted Sep 17, 2017 12:50 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

How would this handle APTs? There's going to be some way in with enough poking pretty much all the time. Should there be insurance? Bailouts with the government going after the culprits (criminal investigation or sanctions for foreign government interference)? I do want there to be fines and such, but they need to be something that companies can actually survive. Percentage of revenue made from the data or in total maybe?

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 20:49 UTC (Mon) by ssmith32 (subscriber, #72404) [Link] (12 responses)

Yeah, but how do you identify the "you" part of "record of plain facts about you".

Even a government-mandated biometric database is just a collection of plain facts about you. But once someone has those facts they can impersonate you. Game over.

Any other neat ideas for identification that I don't know about? I haven't really kept up like I should...

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 22:12 UTC (Mon) by dskoll (subscriber, #1630) [Link] (2 responses)

Credit agencies should be required to keep at least one phone number and one email address in your record. If someone wants to do a credit check on you, they should be required to email, text or call you to let you know (1) who is doing the check, (2) what the purpose of the check is and (3) a random PIN that's good for 24 hours.

If you consent to the check, you phone a number or go to a web site, enter the PIN, and the check goes through. If not, you phone the number or go to the web site, indicate that you don't want the check to go through, and it doesn't.

Can that be hacked? Undoubtedly. But it would raise the difficulty substantially. It would also make it much slower for credit agencies to sell credit checks about you, which is why it'll never happen, even though Google, Yahoo, etc. have used similar schemes for much lower stakes for years.

Apache Struts Statement on Equifax Security Breach

Posted Sep 13, 2017 1:50 UTC (Wed) by ssmith32 (subscriber, #72404) [Link]

A) Stealing phone numbers via (your provider's) website is getting more common. So unless they start offering 2fa for that. Bad idea.

B) Coz most ppl's email is secure? What?

Apache Struts Statement on Equifax Security Breach

Posted Sep 13, 2017 1:58 UTC (Wed) by ssmith32 (subscriber, #72404) [Link]

And you prolly already know (guessing it's where you got the idea from), but for anyone else reading.

Phone + pin = credit freeze, which is already available today.

As for how you deliver a random pin daily, at scale, securely (and that means no UX muck ups) to lower income people most dependent on good credit... I have no idea.

The biggest problem is all these ideas are hardest on people who depend on credit the most. E.g. couldn't make your phone payment? Congrats, your fsck!

Apache Struts Statement on Equifax Security Breach

Posted Sep 12, 2017 8:07 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (8 responses)

Sure, in the 1970s a bunch of people starting with Clifford Cox and eventually including more recognisable names like Ron Rivest came up with Public Key Cryptography. In a public key system we can know a bunch of plain facts (a Public Key) which are enough to recognise a key holder without also knowing their Private Key, stealing these facts does not allow you to impersonate them. Only stealing their key, which they have no reason to let out of their possession, can do that.

Here's how silly this is: If you build a crappy PHP application and "secure" it using a plain password field in your MySQL database with the user's chosen password in it, other PHP developers will know to ridicule you for this design because when inevitably the database gets stolen you lost all the passwords. They all read not to do that and "know better". But if you build a bank, and "secure" it using records of when each customer applied for an account, how much their mortgage payments are each month and what they get paid, industry experts will nod their heads sagely at your brilliant use of data to protect your business.

Bad guys stealing data on this scale don't care about "you". This is a numbers game. Use some stolen records to fill out a thousand loan applications for $5000 each, fifty get approved, ten send the "loan" money abroad to be cashed before the accounts are closed as fraudulent, you now have $50 000 for the trouble of pasting data from one document into another. They're relying on the fact that all the "security" consists of just comparing what was filled in on a form in one place with what's kept in a database in another place. There hasn't been any need to do this for _decades_ but it's what the financial industry is used to, and nobody shows any signs of telling them to knock it off.

Apache Struts Statement on Equifax Security Breach

Posted Sep 12, 2017 23:45 UTC (Tue) by ssmith32 (subscriber, #72404) [Link] (7 responses)

I'm aware of pgp. It does not solve the identity issue without a side channel. Key distribution at any non-trivial scale is hard.

I believe the kernel team does it by having "key parties" where people show up with... wait for it... driver's license and/or passports.

Exactly those things that are the "plain facts" you reject.

Apache Struts Statement on Equifax Security Breach

Posted Sep 13, 2017 14:26 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (6 responses)

> I'm aware of pgp. It does not solve the identity issue without a side channel. Key distribution at any non-trivial scale is hard.

In this case you don't need secure key distribution. You aren't actually trying to associate a particular public key with a real-world identity. You just need to show that the person applying for this loan is the same person who has a history of on-time payments on previous loans, utility bills, etc. The key itself is all the identity you need. When you first start out you just generate a fresh key and are treated as someone with no prior credit history; perhaps others with established credit who trust you (or institutions which know your real-life identity and are willing to back you) co-sign your key to give you a head start. Over time you build up a history of payments associated with your key. When you need a loan you sign the application with your private key to prove to the lender that the person submitting the application has an established credit history.

Apache Struts Statement on Equifax Security Breach

Posted Sep 13, 2017 15:03 UTC (Wed) by farnz (subscriber, #17727) [Link] (5 responses)

The problem with the model you outline is that some people have a bad credit history - the "baseline" of no history is higher than the credit record associated with someone who's taken loans and refused to repay. Without this, you have a bootstrapping issue for people who are credit-worthy but who have no history yet (e.g. homosexuals who've run away from a bigoted home situation) - how do I get credit to prove that I'm trustworthy when no-one will vouch for me because the people who could refuse to do so until I acknowledge that I was "wrong" to be gay?

Thus, you also need some mechanism to either prevent people from creating new identities to defraud the banks with, or some mechanism to demonstrate to a high standard that I've never had credit before - otherwise, the baseline inevitably reduces to "not credit worthy".

And, FWIW, the introduction standard is how credit worked in the dim and distant past - one effect was to limit credit to people from "good" families, as you needed an introduction from someone credit-worthy to yourself be eligible to get credit, and you needed to have credit to become credit-worthy.

Apache Struts Statement on Equifax Security Breach

Posted Sep 13, 2017 18:27 UTC (Wed) by raven667 (guest, #5198) [Link]

> And, FWIW, the introduction standard is how credit worked in the dim and distant past - one effect was to limit credit to people from "good" families, as you needed an introduction from someone credit-worthy to yourself be eligible to get credit, and you needed to have credit to become credit-worthy.

In that time if your reputation was questioned in any way this was death sentence as you cannot operate a business like a farm/plantation without credit, leading to the rise of duels as a way to settle questions of reputation.

Apache Struts Statement on Equifax Security Breach

Posted Sep 13, 2017 19:08 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (3 responses)

> some people have a bad credit history - the "baseline" of no history is higher than the credit record associated with someone who's taken loans and refused to repay

This is a flaw in the current system. You can't presume the ability to identify all bad actors; it's too easy to change one's identity and start over. Someone with no known history _could_ have failed to repay prior debts under another name. The only sane default is to trust no one, and extend significant credit only when there is someone with an established credit history at stake.

I addressed your concerns about the "introduction standard" already, in the form of "institutions which know your real-life identity and are willing to back you". To qualify for a significant loan with no prior history you'll need to find someone willing to cosign, or at least stake their own credit score on your good behavior. That may be someone you know personally, but it could also be a business offering "loan insurance" for a minor fee following a more traditional background check. Alternately, you can start with small amounts of credit, such as utility payments. The utility company already knows where you live and takes on little risk by extending a month's worth of services on credit, making this a simple (and already commonplace) way to bootstrap your credit history.

Apache Struts Statement on Equifax Security Breach

Posted Sep 14, 2017 16:34 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

But the same flaw exists in your system, and is made worse by the requirement to cope with people having lots of legitimate IDs. At least in the current system, it's a criminal offence (not just civil) to create a second ID for the purpose of fraud; in your system, multiple IDs are expected, as I can legally create a new ID at the drop of a hat.

And no, you didn't address my concerns - you completely ignored them. I asked how someone with no prior history (so no institutions that are willing to back you, albeit they know your real-life identity) would get on the credit ladder; your description of "loan insurance" is basically how the current system works. Utilities are no use to someone who's on the bottom of the ladder - they generally don't have utility bills, as those are taken care of as part of their rent on a room in someone else's property; they do pay towards utilities, but they pay a roommate, not a utility firm.

At least in the current system, these people show up as a previously unknown borrower - no added risk from failed credit, but no evidence of good risk either; in your system, such a person ends up in the same pool as people who've refused to pay their debts, making it even harder for someone in a bad situation to get minimal credit to establish their credit-worthiness. Unless, of course, I add in the current system, but described as "loan insurance" and "guarantors" instead...

Ultimately, you're not fixing the issues with the current system, you're just adding a new system on top that adds more issues but doesn't fix the core issues in the current system.

Apache Struts Statement on Equifax Security Breach

Posted Sep 14, 2017 17:38 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (1 responses)

> someone with no prior history ... so no institutions that are willing to back you

Non sequitur. A lack of history does not imply that no institution would be willing to back you. It implies that you are higher-risk, but that risk is easily manageable.

> Utilities are no use to someone who's on the bottom of the ladder - they generally don't have utility bills, as those are taken care of as part of their rent on a room in someone else's property...

For this purpose rent would count as a utility. Anything you have to make regular payments on would serve to establish history.

> At least in the current system, these people show up as a previously unknown borrower - no added risk from failed credit, but no evidence of good risk either...

Which is an error. An unknown borrower should be considered maximum risk, on par with someone who has refused to pay. You know nothing about them, including whether they care about their credit score. As far as you know they have nothing at stake.

Anyway, there are any number of ways to handle the bootstrapping issue and this is getting quite far off-topic. The original point was simply that public key cryptography can be used to establish identity far more securely than the current system of asking you for slightly obscure—but not truly private—information about yourself, such as previous addresses and your Social Security number. If you want a system linked to real-world identity that's not so difficult to do; just have some authority figure endorse the key after running a thorough background check to verify that you are who you say you are. Doing that in one place, once per person, would certainly be an improvement over every lender verifying your identity separately using their own insecure, ad-hoc procedures based on knowledge just about anyone could collect with a bit of effort.

Apache Struts Statement on Equifax Security Breach

Posted Sep 14, 2017 18:03 UTC (Thu) by farnz (subscriber, #17727) [Link]

Note that a lack of history in your system is not distinguishable from bad history - it could be that I have no history, or it could be that I've run away from debts and created a new key. There's no way to distinguish the two situations.

And if rent counts, then what stops me lying and reporting that my kids pay me $10,000 per month in rent reliably? In general, if arbitrary private actors can report, what stops me falsely claiming "good" behaviour for friends - bearing in mind that I can establish new identities as quickly as you can blacklist them? If you whitelist, how do I as head tenant on a flatshare get on the whitelist?

And no, an unknown borrower is not maximum risk - there are legal penalties for trying to disguise your identity to get money, which mean that unknown is lower risk than known bad, since known bad puts you at risk of having to sue, while unknown but with history of not paying lets you get the police forces involved. This is, however, only possible because you are only permitted to have a single identity - as soon as you're allowed to create multiple identities, the system breaks down.

Apache Struts Statement on Equifax Security Breach

Posted Sep 10, 2017 21:36 UTC (Sun) by jebba (guest, #4439) [Link] (2 responses)

This may be a bit out of scope for LWN, but considering the severity of the crack, I thought posting this info would be useful:

Freeze your credit reports. Here is a great overview:

* https://krebsonsecurity.com/2015/06/how-i-learned-to-stop...

* http://krebsonsecurity.com/2015/11/report-everyone-should...

Direct links to freeze pages:

* Equifax --- https://www.freeze.equifax.com/Freeze/jsp/SFF_PersonalIDI...

* Transunion --- https://freeze.transunion.com/sf/securityFreeze/landingPa...

* Innovis --- https://www.innovis.com/securityFreeze/index

* Experian --- https://www.experian.com/freeze/center.html

These people sell your historical info for other slimy junk:

* Chexsystems --- https://www.chexsystems.com/web/chexsystems/consumerdebit...

You can opt out of yet other junk from Experian, Equifax, Innovis, and Transunion here (this is different from credit freeze):

* https://www.optoutprescreen.com

You can get a free annual credit report from this Congress-mandated site:

* https://www.annualcreditreport.com/

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 22:05 UTC (Mon) by pss (subscriber, #39291) [Link]

Thanks very much for this compilation, very useful (and close enough in scope for me anyway)!

Apache Struts Statement on Equifax Security Breach

Posted Sep 13, 2017 2:02 UTC (Wed) by ssmith32 (subscriber, #72404) [Link]

I second the appreciation. Much easier than digging around.

Although I did check the TLS certs on a few links (they looked good - just sayin' best practices for all the other lazy people like me clicking on links on bulletin boards..)

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 13:07 UTC (Mon) by mattdm (subscriber, #18) [Link] (6 responses)

It took me a bit to realize that "Struts" is the name of software, not a description of the attitude with which Apache released its statement.

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 13:39 UTC (Mon) by pboddie (guest, #50784) [Link]

Struts was the in-vogue technology back when I last had Java as the focus of my full-time job (as opposed to taking over the maintenance of colleagues' projects), which was 2005 or thereabouts. Managers would seemingly gladly throw money at shareware-quality add-ons to "help" with Struts application development (in Eclipse, of course) rather than pay for well-maintained Free Software, such was the nature of the Java ecosystem at that point.

Given that other technologies stole Java's thunder in many regards, and that things like Maven didn't come along (or not with any force) until later, and that inertia would prevent the introduction of update strategies in environments where things like Struts have been used, I wouldn't want to think about how many applications there are that are vulnerable. It also doesn't help that things like Tomcat and Jetty are regulars on the vulnerability calendar, either.

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 13:59 UTC (Mon) by SEJeff (guest, #51588) [Link] (3 responses)

Struts was the Rails / Django equivalent when Java was sexy and everyone was building Service Oriented Architectures back in the early to mid 2000s.

Apache Struts Statement on Equifax Security Breach

Posted Sep 11, 2017 17:11 UTC (Mon) by ssl (guest, #98177) [Link] (2 responses)

>Service Oriented Architectures

aren't the current-hip microservices resembling them?

Is that the circle of life?

Apache Struts Statement on Equifax Security Breach

Posted Sep 14, 2017 5:56 UTC (Thu) by nhippi (subscriber, #34640) [Link] (1 responses)

Yes there is an eternal cycle in IT, where old ideas are sneered and forgotten into "legacy bin" - only to be reinvented again by the next generation of coders. Just like we are back to using terminals connected to the time-sharing mainframe called AWS.

All of this has happened before, and all of this will happen again..

Apache Struts Statement on Equifax Security Breach

Posted Sep 15, 2017 2:19 UTC (Fri) by zlynx (guest, #2285) [Link]

"The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again."

Apache Struts Statement on Equifax Security Breach

Posted Sep 12, 2017 16:32 UTC (Tue) by dankohn (guest, #6006) [Link]

In fact, the name Ruby on Rails was a play on Java/Struts, Rails being a faster kind of strut.

Apache Struts Statement - good summary about things to do for security

Posted Sep 12, 2017 15:28 UTC (Tue) by david.a.wheeler (subscriber, #72896) [Link]

This is such a good summary of "good things to do to prepare for unintentional vulnerabilities" that I added it to slide set 8 of my slides on developing secure software.