Note from Tom: If you’re only looking for
today’s pandemic post, go to my new blog (and if you’re not
subscribing to that blog, sign up for it. This blog will increasingly be
devoted to cybersecurity/NERC CIP discussions, although I’ll continue to post
the pandemic posts here as well – but they won’t get picked up by the email
feed on days when I post on both topics). If you’re looking for my cyber/NERC
CIP posts, you’re come to the right place.
As you probably know, CIP-013-1
R1.2.5 requires “Verification of software integrity and authenticity of all
software and patches provided by the vendor for use in the BES Cyber System.”
And CIP-010-3 R1.6 requires NERC entities with High and Medium impact BES Cyber
Systems, “when the method to do so is available to the Responsible Entity from
the software source”, to:
1.6.1. Verify the identity of the software source; and
1.6.2. Verify the integrity of the software obtained from the software
source.
Of course, all three of these
requirement parts focus on the “vendor”. In the case of open source software,
there is no vendor. A vendor is (or at least should be) ultimately responsible
for making sure you have a way to verify that you downloaded the software from
their site wasn’t tampered with on its way to you. But there’s nobody who is
directly responsible for performing this function for open source software;
whether you will get a digital signature and/or a hash value to verify
authenticity and integrity is never certain. Does this mean you don’t need to
worry about open source software when you verify software integrity and
authenticity?
The recent NERC Supply Chain FAQ
includes a question “Is open source software in scope for CIP-013-1 and
CIP-010-3?” The answer is “The Supply Chain Standards are silent on
terms and conditions for procured products or services that registered entities
may install. A registered entity should implement its risk identification and
assessment methodology for all procurements and installations of open-source
software on applicable BES Cyber Systems.”
Further down in the FAQ, the question
is asked “How do you perform authenticity checks for open source software?”
The answer is “The ERO Enterprise also recognizes not all software sources
have secure methods for verifying the integrity of the software, so it
recommends the registered entity document these exceptions in the supply chain
cyber security risk management plan. If there is an instance where a method is
not available to verify the integrity and authenticity of software, the ERO
Enterprise recommends the registered entity to document the exception and any
mitigating measures afforded internally to reduce the supply chain risk of introduction
of malware or counterfeit software. Some examples include, but are not limited
to, thoroughly research where the software is being downloaded, ensure the name
of the file downloaded from the source matches what is being installed, and
verify the checksum values and signature files if available. Pursuant to
CIP-013-1, Requirement R1, Part 1.2.5, the registered entity should document
its verification process of the authenticity of the open source software. In
instances where authenticity checks are unavailable, the registered entity
should consider documentation outlining the risk factors identified and
security controls used to prevent impact to reliability and security. Some
example evidence may include change tickets, checklists, results of the
evaluation, etc.”
I think these two answers are
good. They’re essentially just variations of the basic answer I give whenever
someone asks whether something should be “in scope” for their CIP-013 supply chain
cyber security risk management plan. I always answer “Could this pose any risk
to the BES, if you procure (although “obtain” might be a better word when it
comes to open source software) and install the product?” If so this should be
in your plan. If not, it shouldn’t.
As an aside, sometimes someone will acknowledge that the
item in question (in this case, the integrity and authenticity of open source
software) definitely poses a risk to the BES, but they’ll say the risk “doesn’t
apply to us” for one reason or another (e.g. “We never do X”, or “We never
allow Y”). My response to that is always “All legitimate BES supply chain cyber
risks – that could apply to any North American electric power organization –
apply to you. However, in many cases (perhaps most), you will have mitigated
the risk already, or perhaps your environment has done it for you.”
To use the current example, you might say “Well, we don’t
allow open source software to be installed on BCS in the first place, so this risk
doesn’t apply to us.” I always respond “This risk applies to you, but you’re
saying that you have already mitigated it – in this case, by not allowing open
source software to be installed in the first place. Rather than simply remove
this risk from your list and not mention it at all in your CIP-013 program, I
have a better idea: List this as a risk, and then show that you’ve mitigated it
with your policy to forbid open source software. That way, you’ll get brownie
points for mitigating another supply chain cyber risk to the BES, even though
you didn’t have to do anything more than you were already doing!”
There are probably at least as
many risks that apply to open source software as apply to commercial software.
The risk of downloading a patch that is unauthentic or compromised in transit
is certainly one you need to consider (in fact, since it’s required by the two
requirement parts mentioned above, you don’t have the option not to consider
it). If you think the risk is already mitigated in your environment – for example,
if you don’t allow open source software to be installed on BCS in the first
place - document that!
But let’s say this risk isn’t already
mitigated in your environment; what options do you have to verify integrity and
authenticity of open source software? I used to think they were really limited,
unless you were an enormous software geek. However, in November I met Dick
Brooks, who spent a long career with ISO New England, when we both spoke at the
IEEE Smart Grid Security conference in Atlanta (do you remember face-to-face
meetings? It sometimes seems like they were a great thing we used to do in the
last century, but nowadays we wouldn’t think of doing them anymore. I seriously
wonder if we’ll have face-to-face meetings again, at least for a long time).
Dick is a software engineer with
a very impressive resume,
who worked for ISO New England from 2004 until he retired last year (I believe)
and formed his own company, Reliable
Energy Analytics. Dick has been after me to look at his SAG-PM product for
verifying software authenticity and integrity. I frankly resisted him at first,
since I thought most NERC entities would be content with the digital signatures
and hash values provided by many (most?) commercial software vendors. However,
two things led me to pay much more attention to his product:
- A number
of people brought up the question of verifying authenticity and integrity
of open source software, including in the Supply Chain Working Group’s webinar
yesterday on guidelines for Procurement Language (which ended up being a
more general – but good – discussion of risk management, since the guidelines
themselves are still being drafted).
- I had
assumed this would be a fairly pricey service, since it will allow you to
verify authenticity and integrity for all software, not just open source.
However, when I asked Dick what it cost yesterday, his answer blew me away
(I won’t say what he said, since he’s still working out the details of his
offering. You can reach him at dick@reliableenergyanalytics.com).
You might not be able to put together the annual cost by rummaging in your
couch for spare quarters, but it’s not too far from that.
Dick provided me with a good
demonstration of what SAG-PM can do, shown below. While this is a long printout,
he summarized what makes it a very interesting demonstration of what SAG-PM can
do: “Notice the Suricata example I sent to you contains a good digital
signature, but there is a malware warning, from Virus Total. This is why you
can’t trust digitally signed software and the key to a trustworthy outcome is
based on corroborating evidence, which is a key philosophy built into the
SAGScore algorithm.”
Here is one example of SAG-PM
output of the open source Suricata IDS software, downloaded from (Source
Location): https://www.openinfosecfoundation.org/downloads/windows/Suricata-4.1.4-1-64bit.msi
SAG Point Man performs a risk
analysis on 7 control functions that results in a SAGScore (trustworthiness
score):
- Perform introspection of software object looking for risk
- Verify Download Server Source Location/Certificate
- Perform Virus Scan using online Service
- Verify Digital Signature of software object
- Perform Vulnerability (CVE) Search
- Perform Vendor Verification using Questionnaire data
- Perform Man in the Middle Check
- Generate SAGScore™ (Trustworthiness Score)
- Generate CIP-010-3 R1, Part 1.6 Proof of Verification/Evidence
record, SAGPOV™
- Save all findings and results in F850CR evidence file
Here are the SAG-PM results from
the Suricata software object that was downloaded:
C:\Users\Dick>sag comprehensive
\Users\Dick\Downloads\Suricata-4.1.4-1-64bit.msi
ReliableEnergyAnalytics\SAG_Output
Starting SAG-PM(TM) at: 2020-04-27
18:59:34.815452 using Version: BETA_20200501_3
Please provide the URL of the
Server that provided this software object: https://www.openinfosecfoundation.org/downloads/windows
Performing program introspection
for risks...
*************** PROPERTIES *******************
----> Manufacturer Open Information Security Foundation
----> ProductCode {42AB4288-8940-4B7D-97E2-75901A1D188F}
----> ProductName Suricata IDS/IPS 4.1.4-1-64bit
----> ProductVersion 4.1.4
*************** FILES AND COMPONENTS *******************
----> Executable; FileName: suricata.exe in
module: MainExecutable
----> Executable; FileName:
-heb0dku.dll|liblzma-5.dll in module: MINGW64_liblzma_5.dll
----> Executable; FileName: msvcrt.dll in
module: MINGW64_msvcrt.dll
----> Executable; FileName:
l9yzergb.dll|libpcre-1.dll in module: MINGW64_libpcre_1.dll
----> Executable; FileName: zlib1.dll in
module: MINGW64_zlib1.dll
----> Executable; FileName:
gryxskud.dll|libwinpthread-1.dll in module:
MINGW64_libwinpthread_1.dll
----> Executable; FileName: liblz4.dll in
module: MINGW64_liblz4.dll
----> Executable; FileName:
pakgywbh.dll|WinDivert.dll in module: MINGW64_WinDivert.dll
----> Executable; FileName:
2slm-vhk.dll|libGeoIP-1.dll in module: MINGW64_libGeoIP_1.dll
----> Executable; FileName: lua53.dll in
module: MINGW64_lua53.dll
----> Executable; FileName: libnspr4.dll in
module: MINGW64_libnspr4.dll
----> Executable; FileName: nss3.dll in
module: MINGW64_nss3.dll
----> Executable; FileName: nssutil3.dll in
module: MINGW64_nssutil3.dll
----> Executable; FileName: libplc4.dll in
module: MINGW64_libplc4.dll
----> Executable; FileName:
mqsrvtkk.dll|libyaml-0-2.dll in module: MINGW64_libyaml_0_2.dll
----> Executable; FileName: libplds4.dll in module:
MINGW64_libplds4.dll
----> Executable; FileName:
qx4jerae.dll|libjansson-4.dll in module: MINGW64_libjansson_4.dll
----> Executable; FileName: batch.bat in
module: Win_suricata_batch.bat
A trust score
of: 87.0 has been calculated for this step. Do you wish to
assign a passing grade (Y)/N?
Verifying Source Server ...
---->Company Name:*.openinfosecfoundation.org
---->Issuer Name: DigiCert Inc
---->WARNING: Vendor: Open
Information Security Foundation Not Found in database
A trust score
of: 22.0 has been calculated for this step. Do you wish to
assign a passing grade (Y)/N?
Performing Malware Scan(this takes
a few moments...)
('---->Engine: ESET-NOD32', 'result:', True,
'reason:', 'a variant of Win64/WinDivert.A potentially unsafe')
---->Vulnerabilities found: 1 Total Scans
performed: 62
A trust score
of: 0.0 has been calculated for this step. Do you wish to
assign a passing grade (Y)/N?
Verifying Digital Signature on
Software Object...
----> :Verifying: \Users\Dick\Downloads\Suricata-4.1.4-1-64bit.msi
----> :Unable to verify this file using a catalog.
----> :Signature Index: 0 (Primary Signature)
----> :Hash of file (sha1):
5D7B378B7D105AF0E1B0CEA2ABF25766BB2FD925
----> :Signing Certificate Chain:
----> : Issued to: COMODO RSA Certification
Authority
----> : Issued by: COMODO RSA Certification
Authority
----> : Expires: Mon Jan 18
19:59:59 2038
----> : SHA1 hash:
AFE5D244A8D1194230FF479FE2F897BBCD7A8CB4
----> : Issued to:
COMODO RSA Code Signing CA
----> : Issued by:
COMODO RSA Certification Authority
----> :
Expires: Mon May 08 19:59:59 2028
----> : SHA1 hash:
B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47
---->
: Issued to:
OPEN INFORMATION SECURITY FOUNDATION INC.
---->
: Issued by:
COMODO RSA Code Signing CA
---->
:
Expires: Sat Jul 11 19:59:59 2020
---->
: SHA1 hash:
BF84333A357D0136EB4E89197494BC11629620E5
----> :The signature is timestamped: Tue May 14 02:30:33 2019
----> :Timestamp Verified by:
----> : Issued to: Thawte Timestamping CA
----> : Issued by: Thawte Timestamping CA
----> : Expires: Thu Dec 31
19:59:59 2020
----> : SHA1 hash:
BE36A4562FB2EE05DBB3D32323ADF445084ED656
----> : Issued to:
Symantec Time Stamping Services CA - G2
----> : Issued by:
Thawte Timestamping CA
----> :
Expires: Wed Dec 30 19:59:59 2020
----> : SHA1 hash:
6C07453FFDDA08B83707C09B82FB3D15F35336B1
---->
: Issued to:
Symantec Time Stamping Services Signer - G4
---->
: Issued by:
Symantec Time Stamping Services CA - G2
---->
:
Expires: Tue Dec 29 19:59:59 2020
---->
: SHA1 hash:
65439929B67973EB192D6FF243E6767ADF0834E4
----> :Successfully verified:
\Users\Dick\Downloads\Suricata-4.1.4-1-64bit.msi
----> :Number of files successfully
Verified: 1
----> :Number of warnings: 0
----> :Number of errors: 0
---->WARNING: Unable to match
digital signature with Vendor Database: VERY HIGH RISK
A trust score
of: 67.0 has been calculated for this step. Do you wish to
assign a passing grade (Y)/N?
Performing Common Vulnerability
Search (this takes a few moments ...)
----> Mitre search string:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Suricata IDS/IPS 4.1.4-1-64bit
CVEID_1 Suricata before 4.0.4 is prone to an HTTP detection
bypass vulnerability in detect.c and stream-tcp.c. If a malicious server breaks
a normal TCP flow and sends data before the 3-way handshake is complete, then
the data sent by the malicious server will be accepted by web clients such as a
web browser or Linux CLI utilities, but ignored by Suricata IDS signatures.
This mostly affects IDS signatures for the HTTP protocol and TCP stream
content; signatures for TCP packets will inspect such network traffic as usual.
CVE-2018-6794
Suricata before 4.0.4 is prone to an HTTP detection bypass
vulnerability in detect.c and stream-tcp.c. If a malicious server breaks a
normal TCP flow and sends data before the 3-way handshake is complete, then the
data sent by the malicious server will be accepted by web clients such as a web
browser or Linux CLI utilities, but ignored by Suricata IDS signatures. This
mostly affects IDS signatures for the HTTP protocol and TCP stream content;
signatures for TCP packets will inspect such network traffic as usual.
CVE-2015-2878
Multiple cross-site request forgery (CSRF) vulnerabilities in
Hexis HawkEye G 3.0.1.4912 allow remote attackers to hijack the authentication
of administrators for requests that (1) add arbitrary accounts via the name
parameter to interface/rest/accounts/json; turn off the (2) Url matching, (3)
DNS Inject, or (4) IP Redirect Sensor in a request to interface/rest/dpi/setEnabled/1;
or (5) perform whitelisting of malware MD5 hash IDs via the id parameter to
interface/rest/md5-threats/whitelist.
CVE-2014-3402
The authentication-manager process in the web framework in Cisco
Intrusion Prevention System (IPS) 7.0(8)E4 and earlier in Cisco Intrusion
Detection System (IDS) does not properly manage user tokens, which allows
remote attackers to cause a denial of service (temporary MainApp hang) via a
crafted connection request to the management interface, aka Bug ID CSCuq39550.
CVE-2014-2103
Cisco Intrusion Prevention System (IPS) Software allows remote
attackers to cause a denial of service (MainApp process outage) via malformed
SNMP packets, aka Bug IDs CSCum52355 and CSCul49309.
Press enter to continue...
CVE-2007-2734
The 3Com TippingPoint IPS do not properly handle certain
full-width and half-width Unicode character encodings in an HTTP POST request,
which might allow remote attackers to evade detection of HTTP traffic.
CVE-2007-2690
Multiple IBM ISS Proventia Series products, including the A, G,
and M series, do not properly handle certain full-width and half-width Unicode
character encodings, which might allow remote attackers to evade detection of
HTTP traffic.
CVE-2007-2689
Check Point Web Intelligence does not properly handle certain
full-width and half-width Unicode character encodings, which might allow remote
attackers to evade detection of HTTP traffic.
CVE-2007-2688
The Cisco Intrusion Prevention System (IPS) and IOS with
Firewall/IPS Feature Set do not properly handle certain full-width and
half-width Unicode character encodings, which might allow remote attackers to
evade detection of HTTP traffic.
CVE-2006-4910
The web administration interface (mainApp) to Cisco IDS before
4.1(5c), and IPS 5.0 before 5.0(6p1) and 5.1 before 5.1(2) allows remote
attackers to cause a denial of service (unresponsive device) via a crafted
SSLv2 Client Hello packet.
Press enter to continue...
CVE-2005-2695
Unspecified vulnerability in the SSL certificate checking
functionality in Cisco CiscoWorks Management Center for IDS Sensors (IDSMC) 2.0
and 2.1, and Monitoring Center for Security (Security Monitor or Secmon) 1.1
through 2.0 and 2.1, allows remote attackers to spoof a Cisco Intrusion
Detection Sensor (IDS) or Intrusion Prevention System (IPS).
----> More than 10 vulnerabilities found - stopping search
----> Total Vulnerabilities Found: 10
A trust score
of: 0.0 has been calculated for this step. Do you wish
to assign a passing grade (Y)/N?
Performing Vendor Verification...
---->WARNING: Vendor Data Missing: VERY HIGH RISK
---->WARNING: Vendor Questionnaire Data Missing: VERY
HIGH RISK
---->WARNING: Unable to verify software product information
in Vendor Questionnaire: VERY HIGH RISK
A trust score
of: 0.0 has been calculated for this step. Do you wish
to assign a passing grade (Y)/N?
Performing Man in the Middle
Trace(this takes a few moments...): www.openinfosecfoundation.org
---> ('<DNSBLResult: 52.14.249.179 (0/52)>',
'AMAZON-02, US')
---> 192.168.1.1 is a Reserved Address
---> ('<DNSBLResult: 208.236.210.1 (0/52)>', 'WGELD-ASN,
US')
---> 172.17.1.146 is a Reserved Address
---> ('<DNSBLResult: 40.131.63.252 (0/52)>',
'WINDSTREAM, US')
---> ('<DNSBLResult: 40.136.115.30 (0/52)>',
'WINDSTREAM, US')
---> ('<DNSBLResult: 40.128.249.56 (0/52)>',
'WINDSTREAM, US')
---> 99.82.180.98 is a Reserved Address
---> 52.93.4.91 is a Reserved Address
---> 52.93.4.36 is a Reserved Address
---> 150.222.243.213 is a Reserved Address
---> 54.239.45.238 is a Reserved Address
---> ('<DNSBLResult: 52.95.1.122 (0/52)>',
'AMAZON-02, US')
---> ('<DNSBLResult: 52.95.1.133 (0/52)>',
'AMAZON-02, US')
---> ('<DNSBLResult: 52.95.1.216 (0/52)>',
'AMAZON-02, US')
---> ('<DNSBLResult: 52.95.1.195 (0/52)>',
'AMAZON-02, US')
---> ('<DNSBLResult: 52.95.1.4 (0/52)>',
'AMAZON-02, US')
Man in the Middle Trace Process Failed
A trust score
of: 0.0 has been calculated for this step. Do you wish to
assign a passing grade (Y)/N?
Final
SAGScore: 14.35 Please assign a final grade for this verification (PASS)/FAIL:
You MUST
provide a reason for assigning this grade, enter your reason here: Very poor
results due to missing vendor data and poor SNR on CVE search
Cut and paste the following Proof
of Verification into your Change Management System, then press Enter to continue
------------------------------------------------
{'TransactionID':
'2020-04-27_22_59_35_477048_ONLINE_08753f13-3b25-4959-ab5e-2cdfa31f36ee',
'SAGScore': 14.35, 'FINAL GRADE': 'PASS', 'FinalGradeReason': 'Very poor
results due to missing vendor data and poor SNR on CVE search', 'Product':
'Suricata IDS/IPS 4.1.4-1-64bit', 'Version': '4.1.4', 'Filename':
'\\Users\\Dick\\Downloads\\Suricata-4.1.4-1-64bit.msi', 'Licensor': 'Open
Information Security Foundation', 'SAGPOVID':
'fae6b436-7c6c-4af0-9be7-1f54bd95200b'}
------------------------------------------------
Press Enter to continue, AFTER
copying SAGPOV to CM System...
Saving F850CR Evidence File...
F850CR Contents have been saved to file:
ReliableEnergyAnalytics\SAG_Output//2020-04-27_22_59_35_477048_ONLINE_08753f13-3b25-4959-ab5e-2cdfa31f36ee.txt
Any opinions expressed in this blog post are strictly mine
and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment
on what you have read here, I would love to hear from you. Please email me at
tom@tomalrich.com. Are you working on your CIP-013 plan and you would like some
help on it? Or would you like me to review what you’ve written so far and let
you know what could be improved? Just drop me an email!
No comments:
Post a Comment