6 ms·

This article recommends using SOC2 compliant vendors. I wouldn't put faith an a SOC2 certificate. A vendor who's infrastructure consists of almost entirely of h

This article recommends using SOC2 compliant vendors. I wouldn't put faith an a SOC2 certificate. A vendor who's infrastructure consists of almost entirely of hardware and software that's been EoL for years (and wasn't up-to-date before support expired) can pass SOC2, so long as they show that their firewall does NAT for security. Okay, I'm being somewhat hyperbolic, NAT for security is not the only box a company has to tick to get a SOC2 cert. But I'm being less hyperbolic about long-EoL kit passing SOC2 audits. IMO, a vendor running unsupport(-ed|-able) kit should be an immediate disqualifier.

adrr 6y ago
A lot of banks are running core banking systems on mainframes with 40+ year old software. Core banking system may get updates but the underlying technology and systems haven't been updated for decades.
- projektfu 6y ago
  Yeah, but it’s running on system Z, and if they decide it needs beefier security at the interface, they can add it pretty easily. Just like you can put TLS on the boundary of a generally insecure local system.
colechristensen 6y ago
Legacy hardware can be fine, and in many cases better than constant replacement with new trends. There’s no such thing as EOL if you have enough money. Sometimes computer people can be as bad as fashion snobs about wearing last seasons trends. When was the last time you heard of actual production issues caused by sticking with legacy systems? One often hears rumors about enormous entities running on ancient hardware and software but from the public side those entities seem to be doing very well.
- user5994461 6y ago
  There is a fair amount of issues caused by ancient hardware and software, that can't be sourced anymore or the code was lost. It is a very real issue. This seemingly works fine so it gets ignored until it explodes and there is nothing that can be done about. Maybe the motherboard finally died, maybe the network stack can't speak the recent TLS stack so can't connect to anything anymore. Hardware do die and disappear over decades. Few vendors continue to provide newer replacement at a 100 times markup (maybe IBM and mainframes) the rest is dead in the water (maybe Solaris, Titanium, AIX)
NoPicklez 6y ago
As someone who has performed SOC2 compliance reviews, these are not small tasks. I've performed them on companies that manage core banking systems for other banks and credit unions. Currently, across quite a lot of critical infrastructure there are legacy systems which are EoL. However, there are aspects or layers to the software which are not, or are protected by higher layers of security. If your vendors ENTIRE environment is almost EoL software and hardware then yes that is highly concerning and would make it very difficult for them to demonstrate appropriate security controls. However, the reality is that most of the environments I have assessed have only a small portion of their software/hardware environment that is EoL. That is often protected by significant layers of security above that.
- JustARandomGuy 6y ago
  Out of curiosity, when you're doing a SOC2 compliance review, are your relying on their documentation of security measures, or would you check to see that the documentation matches the security measures that are in place?
  - NoPicklez 6y ago
    Documentation of security controls means very little, yes having a framework with a suite of policies and procedures is important. But a proper SOC 2 review is all about actually seeing it in place. We do a deep dive, where we understand all of the security controls, we then test the design of these security controls through reviewing security configurations within the systems themselves. Then testing the effectiveness of these controls. So yes, we review documentation and then perform an independent review of the security measures/controls in place. For instance, understanding how batch processes are configured, then testing that the appropriate security controls in relation to batch processes operated effectively.
  - user5994461 6y ago
    Both usually. The auditor have a list of a thousand and they want to verify. Not enough to say that you have a list of active devices, need to show them an inventory. Not enough to say there is authentication, need to show them that they can't access the homepage.
Khaine 6y ago
That is not correct. The problem with SOC reports is that it is up to the company to scope what controls they want to be tested as part of the SOC2 report. Therefore in your example, the company is unlikely to include asset management controls (EoL / EoS) as in scope for their SOC report. Companies can also choose to only include the components of controls that are known to be effective, to avoid having a qualified report. You are right that you shouldn't just blindly put faith into an organisation because they have a SOC report. To rely on a SOC report, you need to review it in detail, and understand the controls they have tested, and look for what has been omitted.

adrr 6y ago

A lot of banks are running core banking systems on mainframes with 40+ year old software. Core banking system may get updates but the underlying technology and systems haven't been updated for decades.

projektfu 6y ago
Yeah, but it’s running on system Z, and if they decide it needs beefier security at the interface, they can add it pretty easily. Just like you can put TLS on the boundary of a generally insecure local system.

colechristensen 6y ago

Legacy hardware can be fine, and in many cases better than constant replacement with new trends. There’s no such thing as EOL if you have enough money. Sometimes computer people can be as bad as fashion snobs about wearing last seasons trends. When was the last time you heard of actual production issues caused by sticking with legacy systems? One often hears rumors about enormous entities running on ancient hardware and software but from the public side those entities seem to be doing very well.

user5994461 6y ago
There is a fair amount of issues caused by ancient hardware and software, that can't be sourced anymore or the code was lost. It is a very real issue. This seemingly works fine so it gets ignored until it explodes and there is nothing that can be done about. Maybe the motherboard finally died, maybe the network stack can't speak the recent TLS stack so can't connect to anything anymore. Hardware do die and disappear over decades. Few vendors continue to provide newer replacement at a 100 times markup (maybe IBM and mainframes) the rest is dead in the water (maybe Solaris, Titanium, AIX)

NoPicklez 6y ago

As someone who has performed SOC2 compliance reviews, these are not small tasks. I've performed them on companies that manage core banking systems for other banks and credit unions. Currently, across quite a lot of critical infrastructure there are legacy systems which are EoL. However, there are aspects or layers to the software which are not, or are protected by higher layers of security. If your vendors ENTIRE environment is almost EoL software and hardware then yes that is highly concerning and would make it very difficult for them to demonstrate appropriate security controls. However, the reality is that most of the environments I have assessed have only a small portion of their software/hardware environment that is EoL. That is often protected by significant layers of security above that.

JustARandomGuy 6y ago
Out of curiosity, when you're doing a SOC2 compliance review, are your relying on their documentation of security measures, or would you check to see that the documentation matches the security measures that are in place?
- NoPicklez 6y ago
  Documentation of security controls means very little, yes having a framework with a suite of policies and procedures is important. But a proper SOC 2 review is all about actually seeing it in place. We do a deep dive, where we understand all of the security controls, we then test the design of these security controls through reviewing security configurations within the systems themselves. Then testing the effectiveness of these controls. So yes, we review documentation and then perform an independent review of the security measures/controls in place. For instance, understanding how batch processes are configured, then testing that the appropriate security controls in relation to batch processes operated effectively.
- user5994461 6y ago
  Both usually. The auditor have a list of a thousand and they want to verify. Not enough to say that you have a list of active devices, need to show them an inventory. Not enough to say there is authentication, need to show them that they can't access the homepage.

Khaine 6y ago

That is not correct. The problem with SOC reports is that it is up to the company to scope what controls they want to be tested as part of the SOC2 report. Therefore in your example, the company is unlikely to include asset management controls (EoL / EoS) as in scope for their SOC report. Companies can also choose to only include the components of controls that are known to be effective, to avoid having a qualified report. You are right that you shouldn't just blindly put faith into an organisation because they have a SOC report. To rely on a SOC report, you need to review it in detail, and understand the controls they have tested, and look for what has been omitted.