Best Practices for Software Supply Chain Risk Assessments

um we're uh like to welcome richard brooks uh he will be speaking out best practices for software supply chain risk assessment so without further ado uh looks like you're on so whenever you're ready go ahead and share your screen okay well uh thank you all for hanging in there i know this is uh i'm the only thing between you and your week the rest of your weekend so i'll try to just uh get you through this and hopefully you'll find something useful in this talk my name is dick brooks uh i work quite a bit in the energy industry a lot mostly uh developing energy industry standards for cyber security message secure messaging and and other standards used by the electric

and gas industries uh this talk that i'm doing here was actually presented in uh one of the energy watering holes called energy central uh and uh they've been gracious enough to authorize me to uh show this presentation to you so i'm just gonna go right along and move down the moving down the pipe do you see a screen now that shows global sign

yeah i see that okay thank you uh okay so globalsign was the original sponsor of this talk on energy central i just want to recognize them in this case so today what i want to do is take you down through some software supply chain risks and threats we'll talk specifically about risk that exists we'll talk about value at risk we'll talk about risk assessment steps the the energy industry has a set of security standards uh developed by the north american electric reliability corporation these are called critical infrastructure protection standards and what i'm going to show you here today is effectively designed to address those standards and go beyond by adopting some of the the nist cyber

security framework functionality or capabilities that was not spelled out in the newark standards so this goes beyond what nerc requires but i think it's a more a more appropriate a more comprehensive risk assessment than what you would get if you only use the nerc standard uh and okay let's go so what's the definition of risk i think everyone on this call is already well aware of what risk is and i just use this definition from the department of defense and risk is the likelihood times the consequence of a future cause which if you eliminated it would prevent a potential consequence from occurring so the risk matrix that you see down below with likelihood and consequence is

intended to help you identify those areas of highest risk that you need to focus on and threats uh what is the definition of threats uh so these are real tactics techniques and procedures that are proven to successfully carry out a cyber attack if you're familiar with the miter attack framework they go they use these techniques tactics and procedures to describe behavioral attacks uh but these are bipods these are the threats by parties at various skill levels with the intent capability and opportunity to do so to carry out an attack some threats are known and some are not you're probably very familiar with zero day exploits uh we we also know that the center for internet

security has a maintains a threat level uh on what what's occurring over the internet at any given moment and they try to make people aware of you know what level of what threat level they we are operating at so you can take appropriate mitigating measures so i want to provide a little bit of context is uh so you see what i've shown here is the nist cyber security identification for risk assessments of five and you'll see that it refers to threats vulnerabilities likelihoods and impacts are used to determine risk and those are key concepts those are four key concepts and i'd like to add a couple more which uh i was very fortunate to receive from a

colleague sinclair uh colomai he works at honeywell as an ics engineer very talented fellow but he says that a threat actor carrying out a threat action by exploiting a vulnerability resulting in a consequence that causes an impact in the production process and so the key concept here is that the higher the risk the lower the trust so increased risks negatively impact trustworthiness and trustworthiness is what i try to focus on with the best practices for software supply chain risk assessments now these these concepts cannot all blend together so i want to try to give you a uh a metaphor or an analogy that can help put these these concepts into some context that you can relate to

so i'd like you to imagine that you're driving down the road it's a beautiful sunday weather is perfect everything's great and you're driving down the road in your car and as we all know cars have vulnerabilities whenever you're driving there's a chance that something go wrong and so as you're driving down the street from a side street in front of you pulls out a truck loaded with construction waste and this thing is spewing stuff all over the street and lucky you uh you you you end up having a big old nails right in the road right in front of you right in front of your passenger side right tire so the nail in this case represents the

threat the vulnerability is the tire which is vulnerable to lose its air we look at the likelihood uh and right now that you're driving down the road right at that nail so the likelihood is very high and then we want to talk about the potential impacts and consequences here so the consequence that you face in driving down the road is that you will encounter that threat action uh the vulnerability uh will will be exercise or occur and that will result in a consequence which is a flat tire so there you see the how the threat and the vulnerability and the likelihood and impact all come together through a combination of threat actions and consequences and vulnerabilities

to create a situation that needs to be mitigated ultimately but more importantly what uh what this situation does it also has a impact and impact is really key because that's where the value at risk lies so in the simplest case of the analogy the you get a flat tire you pull over to the side you replace a flat tire one tire lost total value at risk in that case is you know maybe a couple hundred dollars uh but it could be much worse you could be driving down uh the road and the tire goes flat and you lose control and you roll down a cliff and you and now you have a vehicle that is

completely totaled and so the impact in that case is much greater so the threats the threats didn't change the vulnerabilities likelihoods didn't change but the impact certainly can change based on uh the various uh outcomes that you can experience as a result of that threat being carried out and i guys i can't see the chat unfortunately the way this is working on my machine so if you're asking questions i would ask someone to vocalize them for me okay so the software supply chain risks um these are the risks that exist when you acquire software object via the internet us so you know some of the risks that are there like spoof download sites uh watering holes

man-in-the-middle attacks open source binary distributions fakes equifax which is a well-known data breach uh blamed its breach on a flaw and outside the software was using it then blamed a malicious download link on its website to get another vendor so this is just one you know some of the examples of the risks that you take when you pull software off of the internet there are also software supplier risks some third-party software is embedded in vendor offerings and there there can be some open source software in fact most software today has some component uh open source components in it and these uh also uh represent a certain element of risk as well then a software vendor may not even be

aware they've been hacked in their distributing tainted software to their customers this happened in the case of asus and also you'll see in the sofos threat report they identify similar cases where a vendor was hacked and they weren't aware of it and they ended up distributing some malware and speaking of malware i really like this framework that hacker combat created because it shows that malware's not just one thing uh it can be one of any number of things like viruses trojans worms spyware root kits adware exploit kits and uh one that's getting a tremendous amount of tension today is ransomware uh it seems like it's just it it is the uh the darling of the uh black hat

community right now to uh from from a malware standpoint it's a definitely earning some people some money so uh uh nurk which is the as i said this is the organization that's responsible for notifying the electricity sector of any risks that may exist they will occasionally send out alerts and back in july they issued an alert on supply chain risks within the energy industry and and the energy industry is frequently under attack it's it's one of those cases where it's foundational if you can take out the power then you can uh carry out a number of other attacks because so much depends on having electricity to power the systems whether it's sensors or you know control access control devices

whatever it may be many of these obviously depend on electricity so it's it is one of the most common the attacked areas in the critical infrastructure as i said ransomware is now your biggest online security nightmare and uh i do think it's about to get worse you can see that's a zdnet article that i referred to from july this was a report in fact it's a very fine report by the atlantic council uh trey herron his folks over there did a really good job at producing a an analysis of some of the supply chain risks and as you can see they identified 115 attacks and disclosures against the software supply chain just in the past

decade so you see i i provide a link there to the atlantic council and trey's uh trey's research study it's very uh it's very well done and it's worth the time to read so looking at some key trends uh these were what was identified in that atlantic council report there's a deep deep impact from state actors or at least 27 different state attacks against the software supply chain abusing trust in code signing this is a absolute big problem uh because there's there's a tendency for people to believe that a signed software object is trustworthy and i assure you that is definitely not the case but there are some people who use you know use some of the rely on some of

these signing certificates to establish trust authenticode is one that is typically uh very is typically abused uh hijacking software updates 20 of 27 of the tax targeted software updates to insert malicious code poisoning of open source also another popular attack vector and targeting app stores 20 22 percent of the attacks targeted app stores like google play and and apple's app store and so forth i'm not really going to spend much time on the sip requirements here because i suspect most folks aren't from the energy industry but suffice it to say that there are standards that require uh electric companies and any party that is in a command and control position within the bulk electric system

to verify the identity and integrity of a software object before making any change to a baseline system uh and that's uh you know that's one of the key uh processes or procedural controls that require users to obtain their software software directly from the developer or vendors preferred delivery methods so some of the guidance that was that was seen as part of that overall effort suggested that um a digitally signed software object could be trusted and and i think that there it takes a bit more than just verifying a signature to confirm that you're you have a safe object to install there are a few more steps and i'll get to those in just a moment

here again this is more information about the energy industry the regulators are pushing the electric industry to adopt more secure uh controls in the software supply chain and so ferc which is the federal energy regulatory commission has been nudging the industry toward using the nist uh cyber security framework which which is uh which i also endorse is part of my best practices as well so one of the difficult problems or challenges is when you start doing these risk assessments with the software and supply chains is how to determine or establish trust so you need to evaluate risk and establish trust and what these practices recommend is that you apply a triangulating approach to corroborating evidence

so don't rely on one data point to convince you that you can trust a software object you really need to corroborate evidence across a number of a number of inputs input channels so vendor supplied data is a key input software bill of materials which i'm going to get to in a little bit and digital signatures of course that all have to corroborate and ground truth vulnerabilities uh you want to you want to ensure that the data from your s-bahn listing all the objects that are contained in a software object uh have been vetted through you know the nvd or miter whoever you trust to provide you insight into vulnerability so all of these input channels need to come

together to raise a level of trust uh that you that you should that you can use to determine if indeed an object is trustworthy enough to be installed in your critical systems so uh some of the risks that we see within software objects of course is embedded malware like you saw from the hackerone framework vulnerabilities and exploits fakes backdoors third-party embedded objects these open source external dependencies like web apis and i'm sure there are more will discover in time so i mentioned value at risk in the analogy and it's a it is vitally important for us to you know identify what that real value at risk is if if the maximum value at risk was

just a a spare tire uh then you know you you might not have too much of a concern uh but if the value at risk is that your your entire company gets shut down because of a malware incursion and and you're down for a week uh like has been has occurred in you know certain companies uh then your your value risk is significantly higher um and i've seen also credit rating agencies are beginning to factor in cyber security controls uh in their grc assessments and one uh group in particular that i hadn't presented some information to is the moody's time aid uh teammate rather cyber assessment startup uh derrick vidalla and those guys are working on means to

improve the timeliness and accuracy of information into their risk assessments and credit rating scores and board of directors and executives care deeply about credit ratings this uh this determines how much uh it costs them to borrow money so it can have some pretty significant financial impacts and it's just a couple of breaches just to give you a sense of what it can cost uh the north hydro incursion uh was estimated to cost between 64 and 76 million and mursk uh marist rather the the shipping uh company was hit with a non-petty attack and they ended up having to rebuild a whole bunch of their systems at a cost of about 300 million dollars and uh there are some realities that we

also want to keep in mind is that you know some people believe that cyber insurance is all all it takes to put you in put you in the right light and reality is that cyber insurance doesn't always cover all of the risk so here's uh here's a recent article from bloomberg in uh july of 2020 that refers to the hydro attack the north hydro attack and they said as you see there in the end the attack would cost the company more than 60 million dollars way more than the 3.6 million the insurance policy has paid out so far according to an earnings report so you know buying uh cyber insurance is is a hedge against uh financial costs

but it won't address some of the bigger headaches that you'll have to deal with like having to rebuild servers and and and flush out you know all of the nefarious uh software that may be in your systems so let me uh go through the seven uh best practice software risk assessment steps that um that have that have been identified and i present here uh these risk assessment steps have been implemented in a software package uh that is available from my company reliable energy analytics uh and um so it basically does the following for you uh it performs an introspection of software objects looking for risk this is the s bomb piece of the pie we verify download server source

location and certificates perform virus scans of known malware verify digital signatures perform vulnerability searches perform vendor verification using available data we also perform man in the middle attack checks to see if there's any foreign influence or blacklisted sites in the path that could uh perform a man in the middle uh incursion and ultimately when all of these steps are completed we create a trustworthiness score based on that risk assessment and lastly all the materials saved in a results file an evidence file if you will that can be presented to auditors coming in from uh nerc or ferc or or or could even be presented to the folks at a credit rating agency as evidence that a

party is indeed uh implementing their controls to prevent bad software from banking its way into the systems so software introspection this everything has to start with knowing what's in the software and so after acquiring an object it's important to perform a deep inspection in an ideal case a vendor would supply you with a software bill of materials i'm going to go a little bit into that in a moment but in many cases today the software bill of materials isn't provided so you have to essentially examine the software in a way that enables you to identify what's in the package uh as as best you can and uh you can think of this uh s foam sort

of it's sort of like an fda food label so you can imagine if you were you know if you were allergic to peanuts uh you'd want to know what's in the food you're about to purchase at the store to see if there's any risk and it's the same concept here with uh with we with the software bill of materials of any software object that you're contemplating installing in your ecosystem so you definitely want to know what's in there in case there's anything bad that you need to be aware of you want to identify the manufacturer of course and the developer the software determine the name of the product associated with the software along with the version

and verify that the developer and product information match the information that you uh acquired when you started your procurement discussions with the vendor so you're going to want to capture some information from the vendor when you are when you before you actually sign the contract you're going to want to know you know give me information about what digital certificate you will use to sign the objects and tell me where the source location is that i can always you know that's the trusted source location so you need to get a good bit of information from the vendor beforehand which you use in corroborating the evidence so what's an s form uh so an s bomb is

essentially a nested inventory and the fine folks working over at the department of commerce uh ntia the national telecommunications and information administration our work have been working on this challenge for a couple years now and what they've got is essentially a core set of common concepts or terms that should be should exist within any s bomb and right now there are a few s bomb formats standards if you will that exist and ntia is working to reconcile that into some common so you know set of terms that you that every s-bomb should uh shouldn't in fact uh contain and of course along with that of the semantics of what those individual uh items mean like

you look on the screen there i show you supplier name uh you know what exactly is that and so the you know the standard the s-bomb standards would you know go into some level of depth and say that this is like a legal uh a legal name of a party uh as opposed to just like an acronym it's like it wouldn't be ibm it would be international business business machines incorporated as an example so s bombs are becoming a very important part of the risk assessment equation and one important format that i'll mention here because of the connection to the owasp community is that os does indeed have a very fine uh s bomb format and standard um

and the slides that i'm sharing with you here today come from uh steve springett and steve is the uh he's sort of the high priest of the cyclone dx world uh but he's he's very involved in uh in oas with a number of different areas and he provided these so i want to thank steve for that um as you can see here he gives a little bit of history about where where cycle cyclone ds came from and it started with the os dependency tracker uh and we're now at cyclone uh dx version 1.2 i i believe they're getting close to 1.3 so we we may see that before the end of the year i'm not

entirely sure but but i know they're working on okay and so as i and you see there down below i tell you about all of steve's credentials he's the real mccoy he uh he's a guy that knows cyclone dx better than anyone on the planet so he'd be the guy to go to uh this is sort of uh you know motherhood apple pie but it's it's worth stating is it you know this is what their design approach was is they wanted it to be easy to adopt and they wanted this uh s-bond the cyclone dxs bomb to help you in identifying risks uh uh to as many adopters as possible and as quickly as possible

so risk risk assessments was front and center when steve and company were creating the cyclone dx s bomb and there are other uses as well but anyway they want you know also avoid any and all blockers that prevent the identification of risk continuous improvement is one of their key philosophies they encourage innovation they try to be backwards compatible and they from what i've seen they are achieving that they look for facts that's that's key that's a key component of their philosophy and it's full stack s ball so what that means is if you have a software package um that was written in python and it relies on some python packages uh cyclone dx is is a rich enough

uh taxonomy to be able to define all those you know those platform level dependencies so it's it is it is a very robust uh language for describing software bill materials so some of the use cases uh for s-bomb and cyclone dx in particular is to describe a complete and accurate inventory of your software identify security vulnerabilities integrity verification software package evaluation a big one is also license identification and asset management parties uh you know run afoul of some of their licenses some some open source software licenses can be problematic and so knowing about those is is important to know where your risks are um and of course you know it describes some really some of the complexities of some of

these projects i've seen some some packages with with literally thousands of objects embedded in it node.js is okay is a great example of one of those uh it also shows uh this you know component pedigree and there's an element of provenance as well that's being captured um and it also shows you any reliance on services this is really important a lot of you know software on software objects today or applications rely on external web services and knowing that you have those dependencies in an application is critical you need to know if those dependencies if those web services go away yours your software may not work so it's important to know that you have those dependencies

and and there are a bunch of s bomb examples i'll just point you to them this is the link to the s1 examples site on github for cyclone dx i encourage you to go there it's quite daunting though these these can be really really large and complicated looking because they many times these software packages do include quite a number of objects that need to be described okay so you also need to verify that source location in the vendor so you always want to parse the ssl digital certificate for identification information is the issuing ca performing thorough investigations of identity before issuing the certificate some people uh you know create self-signed certificates and they use those for their ssl connections and

uh or servers and uh web service and you know candidly there's really no trust uh you really need to have a trusted third party in the case of the energy industry we have a set of what we call accredited certificate authorities and these are cas that have taken on an additional level of diligence and completing the requirements of the energy industry which are quite you know more rigorous than you know many industries uh many uh you know cases where people using certificates the energy industry only has a handful of these accredited cas but they're vital to ensuring that the right or the authorized party is accessing the servers and systems that are used to run the

electric system so you also want to verify the validity of the digital certificate confirm that the vendor and source location match what was given to you during your procurement discussion so this again goes back to the corroborating evidence to ensure that you can trust an object before installing it and any source locations that lack ssl digital certificates should never be trusted so that's a that's a red flag right right out of the shoot and you really need to be very selective when choosing a ca this is why in the energy industry we we identify only a handful that are accredited because they are agreeing to some very uh rigid requirements that like they would never get away with

doing what's what's being done here uh you know you've got less than 42 hours to regenerate these certs um you know there are provisions in those accreditation standards um that would you know that would require that the um you know the they work with the companies in the energy industry to agree on some reasonable time frame to address any issues you just can't shut down the electric system so you know if you if you're if your cert if your shirt is all of a sudden uh revoked and you can't you know schedule your electricity across a circuit um there are worse things that can happen so now we're in vulnerabilities i i call these out because uh

i've heard some people kind of use them interchangeably and they're very really very different um so malware is really a deliberate attempt by a hacker to implant software in a victim's computing ecosystem in order to gain a foothold or perform various nefarious acts like ransomware and you'd see a few listed there there's just so many i couldn't even list them all uh which so malware is different from vulnerabilities and vulnerabilities are unintentional software imperfections which a hacker uses to access a victim's computing ecosystem using non-exploits in order to gain a foothold to nefarious acts now this is obviously a gray area and i i will say that any party that installs a back door i

would say is actually installing a vulnerability and we see this happen occasionally actually more more than we should i think where a vendor will put in a back door so that their support staff can get access to uh whatever they need to in order to carry out a support function and so it was sort of fallen to i would put those in the vulnerabilities area just because they are exploitable um and you know vulnerabilities are and exploits are often used to implement malware so these are not mutually exclusive concepts one one can be used to leverage the other so that's another way to think about this so what do you do in your software risk

assessment well you got to perform a malware scan using trusted and up-to-date antivirus software and any discovered malware automatically results in a trust score of zero you perform a search for non-vulnerabilities and exploits uh using um some of the you know using the well-known uh sources of this like mind rc miter and cbe in this mvd i did make a proposal to the folks at a rapid seven to improve their attacker kb search results by aligning some of the metadata with what's being discussed in s-bomb standardization so ideally someday what i'd like to do is get to the point where i can submit an s-bomb to a a cve vendor service and have a complete report come back

that list all the vulnerabilities for each of the components within that bill of materials that would that would save me a tremendous amount of work and uh and it would also improve the quality of the results the the results coming back from these cve databases today is very very noisy and so uh it would be great if we could find a way to improve the signal-to-noise ratio and have less false positives coming out of those systems um and just in terms of the antivirus uh my software sag-pm uses uh virustotal because it is an ensemble of virus scanners uh that you know it's better it's better to have one voice you know one set of eyes looking i have

a multiple set of eyes looking at for four risks and that has proven to be very valuable to me and of course any discovered malware or vulnerability risk result in a trust score of zero software object provenance um here again we mentioned you got to look for you know man in the middle attacks and foreign influence and blacklisted ips are a great example and so in my case the software identifies any foreign presence in the in in the path used to acquire a software object also have to verify the digital signature looking for any indication of expired certificates that would be a red flag also want to look at the freshness of the digital certificate

if it's too old then the software object may not be trustworthy because you know things happen over time and new vulnerabilities are discovered all the time in fact i i saw a paper just uh last week uh where it's called catch me if you can and it will say it was it was the best paper award at the acm conference on cps and iot cyber security that was on november 9th and they said that in their analysis and they looked at empirical data that the average vulnerability operates in the wild for about 5.2 years that's a lot of risk so you know this is another case where you know you could have a digital signature

from you know 10 years ago but there's a vulnerability that could still exist there so lack of a digital certificate over a software object is is also a reason to reduce trust to zero some people said well you can use a hash value and that's true you can use a hash value to verify integrity but the hash has no real application in terms of identity and authentication so here are some of the very real experiences i've had as a as i've you know been operating uh you know maintaining and managing the sag pm software now for about a year that ssl certs have been encountered uh untrustworthy ssl starts um list listencraft litzencrypt is a great example of one

and they they're the certificate signing practice makes this very clear they don't really do any authentication at all you know a verification of one's identity it is purely to ensure that a an encrypted channel can be established and in their case they ended up they issued a bunch of search without verifying the ca authorization field in the dodes domain so they had a little over three million certificates that they had to uh revoke because of that fact so you really want to be very careful in who you select for ca and this is one of the reasons why the energy industry specifically uh has accredited those those few who pass the test like you know they like the navy seals you know

the green berets these are the best of the best and uh and they uh they support the energy industry and we appreciate what they do so here's another case uh here's a case where um and this is a screenshot from sag pm where uh this this was a a software object was submitted to virustotal and virustotal came back and reported specific uh uh you know specific results of malware presence of software or objects that could be uh could could uh potentially be harmful um and in some cases uh in in the next next blocks down you see in some cases only one of the available engines in this case 73 engines that examined an object

was able to identify a potential risk so having the ensemble of virus scans scanning engines look at these software objects is is much better than having a single object which made a single virus scanner which may or may not have the most up-to-date signatures at their disposal digital risk signature risk as i mentioned um the asus uh the asus incursion was one where they were using the hackers were using an actual certificate from asus an older certificate that was no longer used but it was still valid and so here's a case where you know you want to identify if there are any expired certs in a signature chain and you also want to examine the the

freshness of the signature here down below you see where i have the warning it says this signature is more than one year in the past and you can see that's from 2011 that signature so nine years have passed since the software object that was signed with this certificate was placed into service so a lot could have happened between in those nine years vulnerabilities and exploits and one of our premier software vendors is osisoft and manufacturers use osisoft as well they have a historian product that is it's the cream of the crop and i'm not picking on osisoft here osisoft is is a very proficient software vendor and they take extremes to ensure that their software's secure but

even they can be you know caught up in some vulnerabilities that might exist and and they can happen very they can be simple you know a buffer overflow is a is it can be easily implemented by a young programmer who may not have you know be aware of the need to you know check for buffer overflows and and so even the best vendors can be subject to this to this uh issue provenance i've already uh mentioned is you know here you i show you a case where um this is an example of a site in iran that's the ir you see on the dns blacklist and you see it's a blacklisted site and it's outside

the united states in this case it's in iran so this uh this would immediately reduce the trust level uh in the trust score that sag pm will create um and of course watering holes wordpress is a great example um they have a it's you know github of course is well known for you know providing lots of software but it's all over the place wordpress is one there's another one of those sites that has tons of software available um and and spoofed software locations uh the nso group from israel is very famous for having created a uh an impersonate or impersonating facebook and uh in providing providing downloads software for cell phones that could be used to extract some sensitive

information so uh nate that's a that's an example of a nation-state uh uh in firm doing work on behalf of a nation-state actually some of the common misconceptions about software is that a digitally signed a verify a verified digitally signed software object is always trustworthy and that's just simply not true you know the digitally signed software objects are a veil of trust that it may not be justified and you can see a few examples here for you like authentico certificates are a great example people think that if they have an authentic code signed object or sent the code a certificate signed object that it's completely trustworthy to be installed and that is absolutely not the case um

you know you can get an authentic code certificate from you know uh you know from a number of different uh vendors i think digicert is one and it's only about 500 bucks so it doesn't take a lot of resources to to get a pentacode certificate software vendors always patch known vulnerabilities immediately and this is absolutely not the case and this was a from a posting in may of 2020 where that microsoft was issuing fixes to vulnerabilities from 1996 and of course the paper i cited earlier uh which was uh created by the folks at the university of bristol and the university of birmingham birmingham in the uk it's called catch me if you can and it's got a long title

but it goes into some really good details about what they found about problems with cves and how long vulnerabilities uh can exist in the wild and as i mentioned they found that on average it's 5.2 years that a vulnerability can be out there and exposed and potentially exploited all vendors follow secure coding standards and that is definitely not true and here's a paper from nist that talks about you know what you should look for in a software development life cycle that has secure software development framework built in to the process so if you're curious about that then this paper is available for you to look at and that was just released in april of this year

okay we're getting close to the end the real bottom line here is you must protect yourself you cannot be assured that a vendor is aware of the risks that are inherent in this software or the supply chain used by your company to acquire their software you know i've had fingered a number of urls and brought me to places i just didn't want to be and you know if you if you did that and downloaded software then you may not be happy with the object you're about to install so it's easy enough to happen you've got to have controls in place to ensure that those things aren't happening to you and if a breach does occur

in your company then you will be the one accountable for the damage it costs to recover not the software event or the supplier uh or along with any other non-compliance fines which are you know quite common in the electric industry and you can't outsource all the cost of a breach you know like to a cyber insurance company it just it's not possible you will be on the hook for recovery efforts and harm to your reputation from a successful cyber attack on your company but you can try to detect these risks and that's what this seven step uh risk assessment software uh software supply chain risk assessment uh is is all about uh and i'm a father

of two daughters so this is uh this next one is you know i try to warn them about taking a drink from a stranger in a bar and uh the software should be viewed in the same way don't just guzzle that drink away you just need to you know implement or apply some due diligence and run you know run a software risk assessment before you think about installing it anywhere and uh my tagline is that you never trust software always verify and report uh and of course they're you know this is not a one and done deal uh vulnerabilities can be discovered um on a regular basis and usually are so once you've done that first risk

assessment it's imperative that any software you do install that you have a constant uh monitoring feature or function to ensure that no new vulnerabilities have been identified so you know on a regular basis whether it's nightly or you know some at least at least once a day i would recommend uh go through and have sang pm so you can automate the script and have it go through all the existing installed software and check for just vulnerabilities to see if there are any new ones so wrapping up software supply chain breaches are costly to recover from and can adversely affect your company's finances and reputation and your own career so apply prudent risk management controls following the nist cyber

security framework best practices to detect these risks and no no risk management control is guaranteed to protect you from harm but some are useful and you know um you know sag pm is uh i keep improving it in order to make sure that it continually uh keeping up to date with new changes and improvements in best practice and so forth so it is a constant effort uh so your software supply chain risk assessment should include really both a vendor-centric analysis assessment as well as a software center risk assessment and you can't rely on vendors to protect you from harm so this is a great case i i got this from sans in one of their use cases

this is actually what happened uh in this uh with the ukraine electric system uh which we all know is well known um had a well-known blackout uh occur and from a nod petya attack and it and before they were attacked you can see their risk ranking on the left uh it was based on following factors uh we don't you know our organization doesn't use these protocols or the organization doesn't use vendor products and so on and so forth and the reality is as you can see on the right there the reality is that they were indeed vulnerable and so they elevated their uh their risk assessment into the red zone um let me hold that i just do want to

acknowledge tom aldrich who helped me with some of the sip 13 materials and just a little bit of information about uh about my company reliable energy analytics we're located in westfield massachusetts so we're right up the street from our friends in connecticut who uh hopefully watching this uh and as i said we do have soft patent pending software assurance guardian point man or sag dash pm as i mentioned i do a lot of work in the energy industry and i worked at iso new england to develop their advanced data analytics solutions as well and the pki implementation okay so there's my contact information and i'm going to try and make my way back to the track here

okay i i don't see any questions is there any other any questions for me

okay um i know i i went through that pretty quickly um but as i said at the beginning i recognize that i'm the only thing between you and your the rest of your weekend so i hope you got something useful out of it and if anyone has any uh uh if anyone has any uh anything they'd like to you know they're welcome to contact me i'll put my email here if you really want to get in touch with me let me stop screen sharing first okay

i think i stopped screen channel yes i hope i have [Music] okay

okay for some reason it seems my screen is freezing up on me here let me try it this way let's get out of it that way let's see if that helps okay okay

all right i was on mute there all right it looks like there you are i'm back sorry about that okay cool uh yeah do you have anything else to say or or we can get started with the closing remarks i no i i think that covers it i know this was energy industry specific but you know some of the concepts should be of use others as well so hopefully you found some value yeah definitely telling other people but you don't know who belongs to so valuable i've definitely been burned by that one and i'm sure many other people have as well all right well thank you dick for that uh talk that was very interesting especially to see on the

energy sector side i'm glad to see somebody's protecting our our energy grid over here hopefully we do lots and lots of people yeah hopefully like the ukrainians are with uh forced blackouts and whatnot yeah well you know there's been a lot of a lot of interest that you know in the energy industry we had a transformer that was uh absconded it is it was enroute to its uh to its eventual party because it was concern of foreign influence and risk associated with it so you just um everyone's on on the edge trying to ensure that we're not going to become a victim yeah yeah yeah because physical supply chain got you make sense in the cyber supply chain

another factor too is huge awesome well if anybody else has any questions for dick uh feel free to post them in the discord uh i imagine if you're in there and we can continue the conversation on there