In 2021’s first quarter, nearly 140 organizations reported being impacted by a supply chain attack, which saw an increase of 42% during the period compared with the prior quarter, according to the nonprofit Identity Theft Resource Center (ITRC).
Long-time cyberveteran with the USAF and currently Federal Practice Lead at A-LIGN, Tony Bai and Joe Cortese, Penetration Testing Practice at A-LIGN, an experienced ethical hacker and corporate cyber defense specialist, navigate the complex future of supply chain security and discuss who should be responsible for supply chain protection.
Security: What is your background? And current responsibilities?
Bai: I spent over 27 years managing IT systems including over 20 in the United States Air Force. I have specialized in risk assessments for government agencies and Fortune 500 companies across multiple industries, including auditing, scanning, and mitigation. At A-LIGN, I run our Federal Practice and oversee all our NIST-based engagements, including FedRAMP, FISMA, 800-171, and the upcoming CMMC certification program.
Cortese: I am the Penetration Testing Practice Lead here at A-LIGN. I have over 15 years of specialized cyber experience across the defense, healthcare, and retail industries, with an extensive background in Dev-Ops, cybersecurity, research & development, incident response, and zero-day exploitation. I’m also a Certified Ethical Hacker with a particular interest in security for mobile, embedded, wireless, and web-enabled devices.
Security: The recent Colonial Pipeline and JBS cyberattacks have proven that threats to the supply chain are increasing. Companies must protect themselves, but how much responsibility should fall on the vendor versus the organization?
Bai: I believe responsibility should be split equally between vendors and organizations. Every vendor is a customer of some other vendor. From that perspective, every organization needs to “trust but verify” not just that all their sensitive data and systems are protected appropriately, but also that their vendors are providing adequate protection for any components, interconnections or shared data.
Cortese: I would love to put more responsibility onto the vendors, but one of the things SolarWinds, Colonial, and JBS taught us is that putting too much faith in other entities to solve your security issue can be dangerous. As a CISO, the buck stops with me. I need to do my due diligence on software in use, while assuming my environment is vulnerable and building the right access controls, policies, and detection and response capabilities to address incidents when they happen. No one else is going to do it for me.
Security: Should vendors be held to stricter processes, and required to implement the CI/CD process to deliver safer software to their customers? And to create more secure products?
Bai: I don’t think a stricter process is needed. I don’t believe any vendor is providing insecure software out of maliciousness. It’s a matter of vendors making security a priority. This is an ongoing problem – companies often struggle to justify the expense of ensuring security is properly implemented and maintained – especially when under pressure. The CI/CD process by itself doesn’t guarantee safer software; security must be fully integrated into the CI/CD process to achieve that result. As we’ve known for decades, security needs to be built-in and not bolted on.
Cortese: Tony hit the nail on the head, security should never be an afterthought. However, requiring companies to adhere to a specific process is fraught with challenges, especially in an industry as diverse and complicated as software development. A better idea is transparency. Years ago, security incidents were rarely disclosed – companies didn’t want to admit they were happening. Today, companies demand transparency around security processes as a pre-requisite to doing business – which is why we see public incident reporting, threat sharing, and third-party security assessments. This has the same effect of pushing vendors to create more secure products.
Security: Should organizations assume that any software they bring in-house is potentially exploitable and assume the costs and risks of a cyberattack?
Bai: Yes, within reason. When you are defending a system, you need to succeed every time, while the attacker only needs to succeed once. The costs and implications of a successful exploit should always be taken into account as part of a company’s risk management process. The impact and probability of a successful attack must be considered as companies decide what they can and should do to ensure they and their customers are properly protected. This degree of analysis and planning is a critical part of a well-run cyber program.
Cortese: While I agree they must, it’s really a moot point. Security teams already assume the costs and risks of any cyberattack, no matter how it’s executed. Best practices for cybersecurity dictate a layered security model that includes redundant defensive techniques, so that a failure in one control can be caught by another control in a different layer. The problem comes when organizations let their guard down, relaxing controls and taking shortcuts. Stay aware of your security systems, keep your infrastructure up-to-date, and implement layered security to catch the threats that creep through the cracks.
Security: Is Zero Trust the only safe way to stop future supply chain attacks?
Bai: Zero Trust is a design concept and as with anything it isn’t a silver bullet. Zero Trust is one tool in company’s bag to ensure they protect their “crown jewels” to the level that makes sense. Cybersecurity is about people, processes, and technology and how they integrate with each other to create a holistic approach in which strengths in a company’s cybersecurity program are enhanced and weaknesses are minimized.
Cortese: I’m a big believer in Zero Trust architecture, but it will take time and effort to get there. Zero trust is a design principle that really needs to be built into an environment from the outset. It’s very difficult to retrofit zero-trust concepts into legacy applications –and most companies end their Zero Trust thoughts right there. My advice would be to implement Zero Trust in small increments, rather than flipping a switch. Review your architecture and environment and decide where you can best start your migration to Zero Trust. Determine what the level of effort will be, building a layered security model around everything. By identifying and prioritizing where you can implement small incremental progress, you will get closer to Zero Trust and simultaneously lower your threat surface from attacks.
