This is pretty much the identity theft nightmare. Imagine someone pwning you early on in your life and then just waiting for retirement or other wealth events to arrive before cashing out.
I think the OP is being metaphorical by saying this hack is like doing that to someone. In this case the big “wealth event” is SolarWinds getting distributed to many high profile government agencies.
The idea is to keep a portfolio of stolen identities and sell them off. There’s plenty of ways to cash in early if you’re willing to take a bit less money upfront.
How many other SolarWinds are there? This company was allowed to install code on highly secure computers, but did not themselves have high levels of security. The practice of allowing random companies with poor security practices to install code is what lead to this breach. Any company that is allowed to do so must have 3rd party security auditing on a continuous basis.
says that SOC2 is (mostly) about sales and little about validating security practices, only that you have them. I find it telling that SOC2 audits are performed by accountants.
Even a financial audit is based on what the company tells the auditors and is about whether the financial reporting conforms to generally accepted principles, not whether it's actually correct.
>SOC2 is pretty heavy duty to achieve and to maintain.
As an auditee who dealt with SOC2 for the last 3 years I'd say that's not true. It's heavy on reviewing documentation and not the true efficacy of your security program.
> SOC2 is pretty heavy duty to achieve and to maintain.
LOL, no. I've gone through SOC2, and it's not hard at all to achieve. SOC2 is basically just about (1) documenting controls and (2) following them. You have a lot of leeway with your auditor on what those controls entail (and remember, you choose and pay your auditor, so there's also a huge conflict of interest here).
We did have to do a yearly security audit, but it's foolish to think that will catch all issues, and it relies a lot on the company being helpful and open with their auditor. You also a lot of leeway in arguing down issue severity.
We got SOC2 certified because many companies require that their vendors have it, but I personally think it has little to no value, and I would not trust a company any more because they've gone through it.
I agree it should be a thing but having been part of a few code audits which were just part of normal company acquisition processes, I know that it takes months to audit the code base of even a moderate sized web application unless it uses a framework whose libraries can be eliminated through md5checks against the originals
You have identified the right problem (a company with security like SolarWinds should not be used on critical systems), but based on your wording likely for a common, but wrong reason. The wording you are using indicates the belief that the breached company, in this case SolarWinds, was uncharacteristically stupid/incompetent and extremely below average and if they just adopted good practices (such as those on the highly secure computers) then the problems would be unlikely to occur. Unfortunately, SolarWinds is, with high probability, above average and above average is, in absolute terms, abysmal. In fact, even the "best" systems are inadequate and effectively useless against credible attackers. FireEye was hacked. Symantec, TrendMicro, McAfee were hacked [1]. Kaspersky was hacked and as part of the hack it was determined that the NSA was previously hacked [2]. Lockheed Martin was hacked and the F-35 blueprints were leaked [3]. That was done using the results from a previous hack months earlier on the company RSA as a part of EMC [4]. The NSA was hacked by The Shadow Brokers who were then themselves hacked [5]. Microsoft Windows gets hacked regularly. The same with MacOS/iOS. Android as well. Hospitals, banks, cars. None of these organizations can protect themselves from their actual foes. In absolute terms, there is no meaningful difference between the "best" and SolarWinds as the difference is like arguing the use of a piece of cardboard as a bulletproof vest since it is more bulletproof than a piece of paper even though neither actual accomplishes the goal of stopping a bullet. So, to answer your question of: "How many other SolarWinds are there?" All of them.
Also, as a secondary point, any security process that allows random, insecure systems to be connected to secure systems without positively identifying if the integration retains the security properties of the secure system is not a security process that creates "secure" systems. That is literally the first step of any good security process as you point out. Therefore, the "highly secure computers" in your example are actually very likely not actually "highly secure" as they were developed by a security process that is incapable of developing high security systems. If they are actually high security, then that would be purely by extraordinary luck as even the most trivial, amateurish of mistakes would violate the security properties and we know experimentally that randomly walking into high security is effectively impossible. A more proper terminology would likely be "high value computers" as they are protecting things that are important, just with inadequate security.
> "How many other SolarWinds are there?" All of them.
This means that maintaining secure systems by ensuring software and processes have no security flaws is pretty much impossible.
A better strategy might be to have air-gapped systems, where you need to have a dedicated physical wire running to your computer if you want to connect to the system. As stuxnet shows, even this is not 100% secure, but it is considerably easier to maintain security if it is not connected to the internet.
That is the correct starting point. However, you must still pair it with a good security process that properly manages and integrates your components otherwise you can still create easily exploitable critical weaknesses. As a trivial example, I remember a proposal by some large networking company to build out a separate parallel network that is exclusively for critical infrastructure devices, thus introducing an air-gap between normal computers and critical infrastructure devices. However, this neglects the fact that there would likely be millions to billions of such devices on the network distributed and likely easily physically accessible which would thus make it easy to still gain access to the "air-gapped" network for nefarious purposes. Maybe not quite as easy a if they were on the same network, but from an objective point of view it would not be a meaningful impediment which would stop any real adversary from defeating it.
What should actually be done is start from an adequate, but possibly impractical or ineffective solution and a process that properly manages the creation of that system then figure out how to make it practical without making it inadequate. If it is impossible to come up with an adequate, but impractical solution to start with, then it is highly unlikely that an adequate practical solution will show itself. This is far easier than starting with a practical, but inadequate solution and making it adequate without making it impractical since, as most engineers know, it is almost always easier to simplify a working design than to bolt things onto a non-working design until it works. If you can not simplify a working design, then it is highly unlikely that you will be able to create a better solution from scratch which is borne out by the continuous failure of pretty much everybody who has ever tried doing so in the cybersecurity industry.
In this particular example, if security is actually important, you should likely start the consideration with an air-gapped system and an adequate security process which assumes that primitive and then see if you can loosen that restriction. But, as I must stress, the key element is actually in having a process that can properly utilize, manage, and reason about the components in a way that can create secure systems. Secure primitives without a good security process can easily create an insecure system. However, a good security process with insecure primitives at least stands a chance (which even ignores the fact that a good security process should filter out insecure primitives that can not be usefully integrated). As for how you can determine if a security process is any good, you can do this by seeing if the process has consistently created systems that reach an adequate objective level of quality given different circumstances. In this case, air-gap based processes have seen material success in actually achieving an adequate level of security in certain circumstances, so it is probably good to start from there though there are actually other potential solutions.
> SolarWinds is, with high probability, above average and above average is, in absolute terms, abysmal.
If what was reported by Reuters is true, SolarWinds had huge holes in its security. None of the companies I've worked for on recent years would keep a FTP server containing critical data on a public network with a guessable password:
"A security researcher told Reuters he warned the IT firm SolarWinds in 2019 that its “solarwinds123” password for its update server could be accessed by anyone."
https://www.businessinsider.com.au/solarwinds-warned-weak-12...
That hardly seems out of the norm to be honest. Plenty of companies make comparably trivial mistakes from what I have seen. Plenty of companies accidentally leave things with their default password. They allow untrusted devices onto their networks. They allow employees unrestricted access to all of their documents on their personal computers. Looking at more specific cases, there was this case where a macOS update allowed anybody to log into root without a password [1]. How about this one where Intel AMT allowed anybody to log in with an empty password [2]. Obviously these are different since these are not internal systems, rather they are systems they shipped to all of their customers that can be trivially compromised, but it is still in the general vicinity of "dumb password" and, in my opinion, is even worse from a security design perspective on Apple and Intel's part. If they would add that to their products, how awful must their internal controls be.
In any event, I will concede that my analysis of SolarWinds is an educated guess on my part, but it is hardly relevant to my overall points in any event. Even if SolarWinds is the dumbest most incompetent organization ever it does not detract from my other point which is that even the "best" is abysmal, so even if they were doing the best that is practically achieved in a working environment it still would not result in a meaningful difference. So, the problem is not actually that SolarWinds was chosen, it is that nobody else would be able to solve it either which is a far bigger problem. It means you need to come up with a novel solution to an unsolved problem, not just use something already known.
To be fair if the FTP was only there to transport data that was already public, and the integrity of the data was ensured by other means than the the transport, the password would perhaps not be seen as very important.
Still even with that in mind one should perhaps never assume that such things are less important.
24 comments
[ 3.4 ms ] story [ 67.2 ms ] threadSurely there are shorter paths to ill gotten gains. Like running for political office.
Just like stocks are traded now, altohugh the payout is in the future.
SOC2 is pretty heavy duty to achieve and to maintain.
But SOC2 is not a guarantee that your company will be impervious to the kinds of mistakes that landed them in hot water this year.
https://latacora.micro.blog/2020/03/12/the-soc-starting.html
says that SOC2 is (mostly) about sales and little about validating security practices, only that you have them. I find it telling that SOC2 audits are performed by accountants.
As an auditee who dealt with SOC2 for the last 3 years I'd say that's not true. It's heavy on reviewing documentation and not the true efficacy of your security program.
LOL, no. I've gone through SOC2, and it's not hard at all to achieve. SOC2 is basically just about (1) documenting controls and (2) following them. You have a lot of leeway with your auditor on what those controls entail (and remember, you choose and pay your auditor, so there's also a huge conflict of interest here).
We did have to do a yearly security audit, but it's foolish to think that will catch all issues, and it relies a lot on the company being helpful and open with their auditor. You also a lot of leeway in arguing down issue severity.
We got SOC2 certified because many companies require that their vendors have it, but I personally think it has little to no value, and I would not trust a company any more because they've gone through it.
Were there any requirements about pentesting one's company somehow?
Did they look at source code?
https://en.wikipedia.org/wiki/Code_audit
And there's a job role called "Source Code Auditor".
Question was if GGP's SOC2 case involved any such source code audits or not.
Now, having read https://latacora.micro.blog/2020/03/12/the-soc-starting.html (linked from a nearby comment, https://news.ycombinator.com/item?id=25489586), seems SOC2 does not include those types of audits. Could still be nice to hear directly from GGP @necubi though. ("yearly security audit"?)
Also, as a secondary point, any security process that allows random, insecure systems to be connected to secure systems without positively identifying if the integration retains the security properties of the secure system is not a security process that creates "secure" systems. That is literally the first step of any good security process as you point out. Therefore, the "highly secure computers" in your example are actually very likely not actually "highly secure" as they were developed by a security process that is incapable of developing high security systems. If they are actually high security, then that would be purely by extraordinary luck as even the most trivial, amateurish of mistakes would violate the security properties and we know experimentally that randomly walking into high security is effectively impossible. A more proper terminology would likely be "high value computers" as they are protecting things that are important, just with inadequate security.
[1] https://arstechnica.com/information-technology/2019/05/hacke...
[2] https://www.washingtonpost.com/world/national-security/israe...
[3] https://www.reuters.com/article/us-usa-defense-hackers/exclu...
[4] https://www.wired.com/2011/08/how-rsa-got-hacked/
[5] https://www.npr.org/2017/11/14/...
This means that maintaining secure systems by ensuring software and processes have no security flaws is pretty much impossible.
A better strategy might be to have air-gapped systems, where you need to have a dedicated physical wire running to your computer if you want to connect to the system. As stuxnet shows, even this is not 100% secure, but it is considerably easier to maintain security if it is not connected to the internet.
What should actually be done is start from an adequate, but possibly impractical or ineffective solution and a process that properly manages the creation of that system then figure out how to make it practical without making it inadequate. If it is impossible to come up with an adequate, but impractical solution to start with, then it is highly unlikely that an adequate practical solution will show itself. This is far easier than starting with a practical, but inadequate solution and making it adequate without making it impractical since, as most engineers know, it is almost always easier to simplify a working design than to bolt things onto a non-working design until it works. If you can not simplify a working design, then it is highly unlikely that you will be able to create a better solution from scratch which is borne out by the continuous failure of pretty much everybody who has ever tried doing so in the cybersecurity industry.
In this particular example, if security is actually important, you should likely start the consideration with an air-gapped system and an adequate security process which assumes that primitive and then see if you can loosen that restriction. But, as I must stress, the key element is actually in having a process that can properly utilize, manage, and reason about the components in a way that can create secure systems. Secure primitives without a good security process can easily create an insecure system. However, a good security process with insecure primitives at least stands a chance (which even ignores the fact that a good security process should filter out insecure primitives that can not be usefully integrated). As for how you can determine if a security process is any good, you can do this by seeing if the process has consistently created systems that reach an adequate objective level of quality given different circumstances. In this case, air-gap based processes have seen material success in actually achieving an adequate level of security in certain circumstances, so it is probably good to start from there though there are actually other potential solutions.
If what was reported by Reuters is true, SolarWinds had huge holes in its security. None of the companies I've worked for on recent years would keep a FTP server containing critical data on a public network with a guessable password: "A security researcher told Reuters he warned the IT firm SolarWinds in 2019 that its “solarwinds123” password for its update server could be accessed by anyone." https://www.businessinsider.com.au/solarwinds-warned-weak-12...
In any event, I will concede that my analysis of SolarWinds is an educated guess on my part, but it is hardly relevant to my overall points in any event. Even if SolarWinds is the dumbest most incompetent organization ever it does not detract from my other point which is that even the "best" is abysmal, so even if they were doing the best that is practically achieved in a working environment it still would not result in a meaningful difference. So, the problem is not actually that SolarWinds was chosen, it is that nobody else would be able to solve it either which is a far bigger problem. It means you need to come up with a novel solution to an unsolved problem, not just use something already known.
[1] https://www.wired.com/story/macos-high-sierra-hack-root/
[2] https://arstechnica.com/information-technology/2017/05/the-h...
Still even with that in mind one should perhaps never assume that such things are less important.
This is the TL;DR to a lot of stuff in life.