Skip to content

Page376

Integrated Product Teams

An Integrated Product Team (IPT) is a customer-focused group that focuses on the entire lifecycle of a project:

An Integrated Product Team (IPT) is a multidisciplinary group of people who are collectively responsible for delivering a defined product or process. The IPT is composed of people who plan, execute, and implement life-cycle decisions for the system being acquired. It includes empowered representatives (stakeholders) from all of the functional areas involved with the product—all who have a stake in the success of the program, such as design, manufacturing, test and evaluation (T&E), and logistics personnel, and, especially, the customer [20].

Integrated Product Teams are a more agile method than traditional hierarchical teams: they “…move away from a pattern of hierarchical decision-making to a process where decisions are made across organizational structures by integrated product teams. It means we are breaking down institutional barriers. It also means that our senior acquisition staffs are in a receive mode—not just a transmit mode. The objective is to be receptive to ideas from the field to obtain buy-in and lasting change” [21].

Software Escrow

Software escrow describes the process of having a third party store an archive of computer software. This is often negotiated as part of a contract with a proprietary software vendor. The vendor may wish to keep the software source code secret, but the customer may be concerned that the vendor could go out of business (potentially orphaning the software). Orphaned software with no available source code will not receive future improvements or patches.

Software escrow places the source code in escrow, under the control of a neutral third party. A contract strictly specifies the conditions for potential release of the source code to the customer, typically due to the business failure of the software vendor.

Code Repository Security

The security of private/internal code repositories largely falls under other corporate security controls discussed previously: defense-in-depth, secure authentication, firewalls, version control, etc.

Public code third-party repositories such as GitHub (https://www.github.com) raise additional security concerns. Beyond the security of the code hosting provider itself, one of the most important controls is secure authentication leveraging dual factor authentication. Accidentally publishing private code as public is a common mistake made by developers. This includes accidentally publishing code that includes passwords or private keys. Many criminals have automated searches for this type of content.

Learn by Example

A Compromised Key Leads to a $6500 Amazon Bill

In 2015 Carlo van Wyk published code to his private GitHub account via Microsoft Visual Studio 2015, and “a simple bug in Visual Studio meant that source code that was destined for a secure and private source code repository was instead published to a public repository. What followed was a sequence of events which left me with a $6,500 bill” [22].

The bug was in the GitHub extension included in Visual Studio 2015, and code marked private was marked public. The code included a private Amazon access key: “To my dismay, I discovered that the repository was created as a public repository. Not only has my source code been compromised, but an Amazon access key for the Alexa web information service, contained in a configuration file, has been exposed in the wild” [22].

The bots soon swarmed in: “As soon as it was out in the wild, it was too late. Bots scan GitHub repositories and it only takes 2 or 3 minutes for some of them to pick this up.” Criminals then spawned many Amazon cloud instances using Carlo’s account, and used them to mine the cryptocurrency Bitcoin.