Skip to content
Try it Free Request Your Demo
    August 31, 2021

    How The Biden EO On Cybersecurity Will Change Vendor Risk Management

    The mandates laid out by the Biden Administration’s Executive Order on Improving the Nation’s Cybersecurity are specific to federal agencies, but the impact they’ll have on the greater market could lay the groundwork for new vendor evaluation standards across the board. 

    With our omnipresent interconnectivity today, we’re unwittingly piling the risk to our vendors on top of our own, creating third-party risk; as well as the risk of our vendors’ vendors– known as 4th party risk. That risk is becoming glaringly more dangerous as day in and day out we see organizations falling victim to supply chain breaches. 

    Since the Biden E.O. aims to tackle the fundamental risk that comes with having a supply chain, it’s no surprise to see organizations outside of the government looking to this mandate as their guiding light for vendor risk management. But what does that mean for security and compliance teams across the nation?

    A CISO, Risk Expert, and Software Engineer Walk into a Webinar ...

    On Wednesday, August 11th, we had the pleasure of hosting a webinar panel to discuss the implications of the Biden E.O. with industry experts Marc French, CISO, Product Security Group; Desarie Green, Senior Manager, IS Risk, Hologic Inc.; and Vipul Sawant, Principal Engineer, Uptycs. Moderated by Matt Kelly of Radical Compliance, the panelists had a chance to discuss a range of topics, including:

     

    • How supply chain risk has become the focus of cybersecurity
    • Who owns vendor risk management at an organization
    • Market preparedness for significant change in risk measurement
    • How a business can strengthen their technical processes to demonstrate good vendor risk management practices to their customers and suppliers 

    * Watch the webinar on-demand, now! *

    Having such a diverse panel really allowed us to dive into the differing implications between security teams, compliance teams, and software providers, and while we recommend giving the webinar a watch for yourself, we’ve extracted some key takeaways for you:

    1. You could do everything right to protect your perimeter and still fall victim to a supply chain attack.
        • "You are probably more likely to get compromised by things that you have, than things that you did. Meaning, if you think about all of the things that have happened over the course of the last five years or so, Solarwinds, etc., those are likely because you had something in your environment that you got from somebody else, as opposed to something that you did [or didn't do] on the perimeter [i.e. firewall wasn't configured correctly]." - Marc French, CISO, Product Security Group
    2. Vendor risk evaluation will become much more about what you’re distributing and less about what you’re running in your environment.
        • "If you look back at what most folks do to try to achieve accreditation, say, I got my SOC 2 or my PCI, it's going to be much more about what you're shipping and a little less about what you're running. So there's going to be a huge increase in the amount of application security work that's going to need to get done…it's not going to be enough anymore just to get your SOC 2." - Marc French, CISO, Product Security Group
    3. Threat intel sharing as part of the E.O. is a vital component to managing supply chain risk.
        • "The problem is, some of the[se organizations] tend to pay the ransomware ransom money, as any public acknowledgement of such attacks is either too embarrassing for them, or sometimes it's the fear of negative associations with [it]… Because of this, there is actually an increase in targeted ransomware attacks because the attackers are making easy money… Because of a fear of public acknowledgement, shame or embarrassment, these kinds of attacks are swept under the rug. If we looked at those attacks through forensic analysis, that threat intel could be used to prevent any future or similar attacks on other organizations." – Vipul Sawant, Principal Engineer, Upytcs
    4. Implementing, managing, and monitoring these new practices will be tough, particularly because it is unclear which teams should own the responsibility. 
        • "I think that is where a lot of organizations are running into problems because you haven't really built out either. They don't have an enterprise risk management structure, or they don't have risk management even within the cybersecurity or the IT functionality. So now it's, 'does procurement own that? Who owns that risk management piece?’ And looking at it from that vendor management perspective, I'm sure a lot of organizations, either their procurement function or another functionality, whether you have a dedicated risk management team that's looking at a vendor, they may be looking at it from a different standpoint. Procurement may be looking at it from a contractual view, 'are we getting the best bang for our buck?' Legal may be looking at it through a different lens, but is your IT or cybersecurity team actually looking at the vendors from, 'are they're going to have access to our network or access to our data? Are we looking at a SIG, are we getting their SOC 2 report?' Even once you do your onboarding due diligence and risk assessment of the vendor, what does it look like after that? You've onboarded them, and I think a lot of people stop at that point." – Desarie Green, Senior Manager, IS Risk, Hologic, Inc. 
    5. As part of the E.O., vendors must verify their software source codes, ensuring any vulnerabilities or exploits found are remediated and checked for regularly. 
        • "That is a really tough problem to crack because, you know, procurement and your traditional vendor risk programs are going to be focused in on, 'I bought this product, give me your SOC 2 report.' They are not in the business of taking that third party library that does your crypto algorithms and figuring out the provenance of that and making sure that someone didn't inject malicious code in that environment downstream. So, there's even this evolution within the security function because the traditional vendor risk program has been wholly focused in on 'I'm buying stuff.' Now it's not just what I'm buying, but also what I'm cutting and pasting into my environment that I'm using for the software that I'm deploying." - Marc French, CISO, Product Security Group
    6. Ascertaining the provenance of third-party code will be difficult, especially when considering open-source code.
        • “Using open-source code is a big problem. First, there are licensing issues, number one. Number two, for most of these open-source libraries there are two ways you can grab the source code. You compile on your own and maintain it, or most of these technologies, like Java or Python, there are third party repositories available. You pay, you get the compiled library itself, but that's compiled by somebody else. So that's a big risk… What we have to do is spread awareness that whenever you are dealing with software, either procuring it from a vendor or even building it in-house, when you are using third-party libraries, you are dealing with a supply chain. You are grabbing from some other third-party source.” – Vipul Sawant, Principal Engineer, Upytcs
    7. You may not even realize the mandates apply to you.
        • “If you've had a breach, there are new reporting requirements for anybody that has a federal contract. It used to be that a lot of the breach notification laws at the federal level were pushed through DFARS on the defense side, but they broadened that out for anybody that has a federal contract out there. Which the reality of it is, you may or may not know you have one. You could be one of those second or third or fourth ordered persons that has flow-down terms afar, and you don't have a direct government contract, but your vendor’s vendor does. And they've somehow buried that in your contract. And all of a sudden, huzzah! You're now responsible for this.” - Marc French, CISO, Product Security Group
    8. Smaller organizations with light IT teams should start with focusing their efforts on vulnerabilities that are mission critical.
        • “A company that may be smaller in scale, maybe there are only two people sitting in the IT department and they may not even have an internal audit function, that may be a harder pill to swallow. So I think that really is where looking at, ‘what is our biggest risk’ and then scoping based on that, you have to start somewhere. And I think for smaller companies, possibly starting and looking from the viewpoint of ‘we're going to do everything,’ that seems overwhelming and insurmountable. Whereas if you're scoping, ‘what is our biggest risk’ and taking that approach, I think that might help people actually start to build a program if they don't have one in existence right now.” - Desarie Green, Senior Manager, IS Risk, Hologic, Inc.
        • “Yeah, there was a big assumption there too, Matt, that you actually have a CISO, because as Desarie said, in many corporations, you don't. There's only one person sitting in IT somewhere, who's your help desk person and your sys admin and everything else. So, generally what I recommend to clients as they come on board is figure out what your business-ending event is. What is it? You're a healthcare company, it's the loss of your PHI information. You're a FinTech company, it's your exposure of your credit card risk. What's going to put you out of business tomorrow? Then, as things come in from a vendor perspective, if you had to prioritize, pick the things that are going to put you out of business first, and if it's, ‘if this tool could actually put you out of business,’ you should probably go look at that. Everything else is just noise.” - Marc French, CISO, Product Security Group
    9. Continuous vulnerability assessments and auditing of your environments, especially as a software provider, is essential.
        • “Today, people are trying to use open source because there's a fundamental shift in software vendors where they are trying to follow agile practices for software development to add continuously new features and provide their customers the experience that they are looking for. So the vulnerability assessment that you do today may not be up to date a week after that. It has to be dynamic. Similarly, the audits that you are doing for compliance, since this is happening across the board, what you are updating in your environment needs to be audited clearly. Especially now, everything is cloud-based, so your infrastructure is, many times, elastic. It's growing based on need or shrinking when there is no need, right? For example, if you have web servers, if you have [a high volume of] traffic then you are launching more instances, and at the end of the day, because there's less traffic, to save money you will shrink that. So the problem is you can't have a static audit, right? So, if today I had, let's say, a thousand machines, tomorrow I might have 200 machines. And if there are some problems, like breaches, then, because that infrastructure is elastic, the first thing is to maintain a dynamic list of all the resources that were created and run compliance. Not at a particular interval, but in cases of elastic infrastructure, run those vulnerability scans or compliance audits whenever those resources are created, and gather that evidence and keep them for a longer duration.” - Vipul Sawant, Principal Engineer, Upytcs

    * Watch the webinar on-demand, now! *

    Federal mandates aside, the need for vendor risk management reform is clear. We are all playing a big part in improving the cybersecurity of our nation, whether we believe to be or not. Because in some form or another, we are all connected, and we’ve already seen that it takes just one weak link to break the whole chain. 

    To learn about how Uptycs can help you audit your environment and monitor for vulnerabilities, threats and more, schedule a demo.

    See for yourself

    Kelley Kirby

    Other posts you might be interested in