topic Re: Why InfoSec has to be integrated into the purchasing process ... in Industry News

Why InfoSec has to be integrated into the purchasing process ...

Flyslinger2 — Thu, 04 Oct 2018 11:57:48 GMT

Several big name companies purchased corrupt gear from a manufacturer. Of course China is involved.

The purchasing process has to embed InfoSec into it. Strong language needs to be added to procurement contracts that protect the interests of the end user-whether personal, civilian or Federal. You would also hope that there are process in place to test the gear to confirm that no suspicious activities were taking place.

Re: Why InfoSec has to be integrated into the purchasing process ...

CraginS — Thu, 04 Oct 2018 14:11:40 GMT

The process Mark @Flyslinger2 is promoting here is called Supply Chain Risk Management (SCRM). For the U. S. Federal government, the guidelines are found in NIST Special Publication (SP) 800-161, Supply Chain Risk Management Practices for Federal Information Systems and Organizations (2015). The SCRM effort began under President George W. Bush in January 2008 as Initiative #11 of the classified Comprehensive National Cybersecurity Initiative (CNCI) under National Security Presidential Directive 54/Homeland Security Presidential Directive 23 (NSPD-54/HSPD-23). The CNCI was later declassified and continued under President Obama. President Obama further extended the focus in 2013 in Executive Order (EO) 13636 Improving Critical. Infrastructure Cybersecurity and in 2014 in Presidential Policy Directive (PPD) 21, Critical Infrastructure Security and Resilience.

While all of those documents are written for the government, obviously many of the principles found in them can, and should be followed by commercial enterprises. In particular, note that most of the critical infrastructure of the U.S. is owned, maintained, and operated not by any government entity but by private or commercial organizations.

More recently the international standards community has added guidance for SCRM with Open Trusted Technology Provider Standard (O-TTPS) is ISO Standard 20243:

ISO/IEC 20243-1:2018, Information technology -- Open Trusted Technology ProviderTM Standard (O-TTPS) -- Mitigating maliciously tainted and counterfeit products -- Part 1: Requirements and recommendations

and

ISO/IEC 20243-2:2018
Information technology -- Open Trusted Technology ProviderTM Standard (O-TTPS) -- Mitigating maliciously tainted and counterfeit products -- Part 2: Assessment procedures for the O-TTPS and ISO/IEC 20243-1:2018

I was directly involved in CNCI 11 during the initial phases in 2008 to 1010. One of our early challenges was helping educate participants in a shift in the meaning of the term supply chain risk. For decades the logistics community has used the term to refer to risks TO the supply chain. Under CNCI 11 and subsequent work of SCRM, the term means risks to the mission (or the infrastructure) THROUGH the supply chain.

As a side comment, I noticed that two of the four authors of SP 800-161 have been involved in the SCRM effort since those early days ten years ago.

Re: Why InfoSec has to be integrated into the purchasing process ...

Flyslinger2 — Thu, 04 Oct 2018 16:35:13 GMT

Here is the Bloomberg write up that Fox news referenced. It is very interesting.

Re: Why InfoSec has to be integrated into the purchasing process ...

rslade — Fri, 12 Oct 2018 16:56:04 GMT

> Flyslinger2 (Contributor II) posted a new reply in Industry News on 10-04-2018

> Here is the Bloomberg write up that Fox news referenced.

I started out, more than 30 years ago, researching malware and other forms of
covert interference (including a number of instances involveing hardware). While
the possibility of a hardware attack similar to this is quite possible, the details of
this story are quite suspect.

(First of all, you mention that Faux News is interested. That *automatically*
raises alarms 🙂

There is the issue that this relates to a separate chip found on the circuit boards.
If you are smart enough to make a chip that can do everything this superchip is
supposed to do, you should be smart enough to put the functions into another chip
on the the system (perhaps the system management controller that the superchip
is supposed to control) so that an extraneous chip won't raise alarms.

Then there are all the functions this superchip is supposed to do. It is supposed to
manage communications. It is supposed to subvert the operating system.
(*Which* operating system? How would they know that would be the one used?)
It is supposed to divert password checks.

Oh, right. It's supposed to subvert the system controller. I once reviewed a
supposed antiviral system that Western Digital used as a demonstration of their
new system controller chip. They made a total hash of it. Even system
controllers don't have the kind of reference monitor function that this superchip
would rely on.

Other parts of the story refer to other chips, some as small as a pencil tip, that
could be layered into the circuit board itself. Yes, it could. But how would you
make contacts with it? (And you'd need multiple contacts ...)

While the spy parts of the story sound reasonable, the tech parts don't. Now, it
may be that there are similar types of hardware attacks mounted. It may even be
that almost the whole story it true, but that the "sources" lied to Bloomberg about
the tech for reasons of their own. But this smacks, to me, of the tale of the
Desert Storm Virus of 1991. An April Fools joke that deceived the author of a
book about the 1991 Desert Storm campaign--and also the Pentagon press office.
(Because they'd read the book ...)

> It is very
> interesting.

No. It's not.

And I like the little tagline: "Bloomberg LP has been a Supermicro customer.
According to a Bloomberg LP spokesperson, the company has found no evidence
to suggest that it has been affected by the hardware issues raised in the article."

Yeah, right. Like they'd know ...

====================== (quote inserted randomly by Pegasus Mailer)
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org
What's most interesting about these ciphers is how robustly lousy
they are. - Bruce Schneier (on the GSM cryptographic algorithms)
victoria.tc.ca/techrev/rms.htm http://twitter.com/rslade
http://blogs.securiteam.com/index.php/archives/author/p1/
https://is.gd/RotlWB

Re: Why InfoSec has to be integrated into the purchasing process ...

CraginS — Fri, 05 Oct 2018 10:34:27 GMT

Mark @Flyslinger2 & Rob @rslade ,

The US government is moving forward with embedding SCRM into information systems management by adding SCRM content to the Risk Management Framework (RMF). See the Final Public Draft of NIST SP 800-37, Revision 2, Risk Management Framework for Information Systems and Organizations--A System Life Cycle Approach for Security and Privacy. Public comment period on this draft is open until October 31.

Re: Why InfoSec has to be integrated into the purchasing process ...

Flyslinger2 — Fri, 05 Oct 2018 11:23:39 GMT

Current federal customer is not happy with my mentioning this to them. All they can see is more intrusion into their project, higher costs, and more delays.

Not well met where the rubber meets the road. Not surprised. "Whats wrong with business as usual?"

I laugh.

Re: Why InfoSec has to be integrated into the purchasing process ...

CraginS — Fri, 05 Oct 2018 12:52:20 GMT

@Flyslinger2 wrote:
Current federal customer is not happy with my mentioning this to them. All they can see is more intrusion into their project, higher costs, and more delays.

Not well met where the rubber meets the road. Not surprised. "Whats wrong with business as usual?"

Mark, et al.,

The standard benchmark priorities for most projects, and especially government acquisitions, are described by the three-legged stool of Cost, Schedule, and Performance. While the training materials and reference documents use language and illustrations trying to present those three as co-equal, in reality they never are. My observation has been that Cost is most often dominant over both schedule and performance. Occasionally, Schedule assumes dominance, especially when an agency head has personally promised a completion date in public testimony to one or more committees of Congress. I have never seen Performance be the dominant concern in the triad.

When either cost or schedule are threatened, the solution is generally to reduce the performance requirements. Secondary requirements, not directly related to mission performance, tend to be loosened first, then direct mission performance functions. Security and privacy requirements fall under the Performance group, and are almost always secondary to mission. Thus, those security and privacy requirements get redefined as "desirements" and are discounted.

The only path I have figured out on how to overcome the attitude Mark described is to show clearly and concretely how failure to meet directed security capabilities will negatively impact both Cost and Schedule by delaying system authorization (Schedule) when the first system assessment is failed and adding post-production Cost to go back and bolt on the security features that should have been built in in the first place.

Enjoy!