1. Home
  2. Training Library
  3. Security
  4. Security Courses
  5. CSSLP Domain 8:1 - Supply Chain Risk Assessment

Intellectual Property

The course is part of this learning path

Start course
Overview
Difficulty
Beginner
Duration
17m
Students
38
Ratings
5/5
starstarstarstarstar
Description

This course covers the supply chain risk assessment process and will prepare you for the first section of CSSLP Domain 8. 

Learning Objectives

  • Understand how to assess risk in your supply chain
  • Learn about intellectual property and compliance in the context of software development
  • Learn how to identify and choose suppliers for your software development supply chain

Intended Audience

This course is intended for anyone looking to develop secure software as well as those studying for the CSSLP certification.

Prerequisites

Any experience relating to information security would be advantageous, but not essential. All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.

 

Transcript

The whole subject of intellectual property is one that is a tangle of legal issues. Here, we're talking about something created by someone else, very likely, that we want to use in a product we want created for us. That means that in some way, software is owned by someone. The module that we want to use had a builder, had a creator, and it's usually the creator that holds the rights to it. There are specific rules around this regarding the ownership and what the owner can do.

The fact that software is a bit of an intangible can make this a very interesting landscape but we have to navigate it by first understanding that software is an owned intellectual property. Normally, what happens is ownership is declared by getting a copyright on it. And then the software is licensed by someone, normally anybody can, and then there are similar rules regarding how that licensee can use it. And that's captured in the software user agreement, the EULA as we call it, the end-user license agreement. When this has been violated, depending upon the context, various legal contests and financial impacts normally result.

Worse is when these happen after the violation is discovered in implemented and in use software that are now or have become critical applications, and these can have catastrophic consequences. Now, this is usually addressed rather effectively in contractual language, but the acquirer should perform or require audits done to assure that all the risks associated are in fact recognized and dealt with, not simply assumed to have been. So the different kinds of intellectual properties that we may have to recognize and cope with involve copyrights, patents, trademarks, trade secrets, and code escrow.

Now, a copyright is basically a work of authorship such as music, the written word, or something of that kind, and software generally falls into this category. There's nothing secret about it, when it's done the owner applies and receives a copyright, and so this is not secret, it's public. A patent is something somewhat different. It's about a novel creation, something that is new and unprecedented, something that is very unique. 

Now, like copyrights which work for written works, this is more about invention, and the owner is granted certain rights under a patent. And those rights include the ability to license the product, sell it to someone else, or make other uses. Patents too are public, not secret. Trademarks, of course, these are things that are used for the recognition of a particular brand. And we see millions of these every day. These are obviously public, intended to be so.

Now, trade secret is slightly different because the secret itself, the trade secret is described and recorded and held in a government office. But the secret is not published to the public. But the knowledge, the record of it, some element of that is, and it's recorded this way so that the owner of this trade secret, and it usually is something that has to do with commercial advantage, a formula, a recipe, a mechanism, or something of that kind, it gives them the ability to defend infringement if they ever encounter it.

Code escrow is something that typically accompanies software but it is something we have to verify that is in place with the code in question. It is entirely possible that the software builder goes bankrupt, or is otherwise going out of business, could be that it's part of a merger and acquisition, a buyout. The users of that software need to have the assurance that that software will continue to serve their needs even in the face of all of this.

So software escrow guarantees them that right for a limited period, which is intended to provide them the ability to come up with a solution. When all is said and done, it may be that the new owner, to continue the example of an acquisition, the new owner decides that they're either gonna retire the software or discontinue it all together. And their choice might include taking it off the market and banning its further use. If that's the case, then those who use it, those who have legally licensed it up to this point, now have to scramble and find a solution. So this is to protect those parties and give them the opportunity to find the solution before the software that they have come to depend on is taken from them.

About the Author
Avatar
Ross Leo
Instructor
Students
5766
Courses
75
Learning Paths
17

Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years.  He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant.  His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International.  A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center.  From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.

 

Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004.   During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide.  He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004.  Mr. leo is an ISC2 Certified Instructor.

Covered Topics