Policies to Know when Deploying Custom Software 110519

  • Slides: 17
Download presentation
Policies to Know when Deploying Custom Software 11/05/19 Cassandra Ladino

Policies to Know when Deploying Custom Software 11/05/19 Cassandra Ladino

Overview ● ● ● ● FITARA Fed. RAMP CHS first policy SORNs Authorization of

Overview ● ● ● ● FITARA Fed. RAMP CHS first policy SORNs Authorization of Software Installations Git. Lab and Federal Source Code Policy USGS Software Management Website

Deploying Software ● Software that is hosted or otherwise made available as an application

Deploying Software ● Software that is hosted or otherwise made available as an application and accessible to others in a runtime state (i. e. http or. exe) ● Distribute and Deploy are NOT the same action and are NOT equivalent in the software product release process ● The practice of Dev. Ops is often associate, but not always Software Management Website: https: //www. usgs. gov/products/software-management/deployment-best-practices

Federal Information Technology Acquisition Reform Act (FITARA) Scope: Purchasing and management of computer technology.

Federal Information Technology Acquisition Reform Act (FITARA) Scope: Purchasing and management of computer technology. USGS Manual Policy: Describes authorities of the Associate Chief Information Officer (ACIO), Tim Quinn - Office of Enterprise Information https: //prd-wret. s 3 -us-west 2. amazonaws. com/assets/palladium/production/atoms/files/FITARA%20 Authorities%20 Survey%20 Manual%20 Chapter. pdf ● ● Responsible for managing all aspects of IMT governance, including acquisition, budget formulation, budget execution, human capital, and the overall Bureau management structure, and for coordinating these activities among other Bureau offices Authority to review all IMT investments in the Bureau portfolio Responsible for ensuring the Bureau operates within the approved annual IMT plan Responsibility for ensuring IMT Security and Privacy

How Does it Work - Acquisition Requirements Toolkit (ART) ● Developed for the USGS

How Does it Work - Acquisition Requirements Toolkit (ART) ● Developed for the USGS Office of Acquisition and Grants (OAG). ● All science centers and offices are required to submit an IMT plan in ART. ● Used for the combined OAG Annual Advanced Procurement Plan and the OEI IMT Acquisition Strategic Plan. ● Data entry is August 1 -31 for ‘planning’ data entry. ○ ○ IMT goods or services of any dollar value (to include purchase card transactions, acquisitions, grants and cooperative agreements). non-IMT goods or services greater than $150, 000 (to include acquisitions, grants and cooperative agreements). ● USGS ACIO office review and approval of IMT plans in September. ● Particular attention on servers, storage, network, software and cloud.

How does this apply to USGS Custom Software Development? ● Deploying software is considered

How does this apply to USGS Custom Software Development? ● Deploying software is considered an optional step in the release process ● Deploying software requires the use of computer technology resources; therefore it is subject to FITARA and oversight by the ACIO. Best Practice: ● Take advantage of established Dev. Op teams and approved computing infrastructure.

Fed. RAMP and FITARA The Federal Risk and Authorization Management Program (Fed. RAMP) is

Fed. RAMP and FITARA The Federal Risk and Authorization Management Program (Fed. RAMP) is a US government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. ● Not the same as FITARA, but often used interchangeably when talking about software (i. e. COTS) acquisition, since software itself is a computer technology resource.

How does this apply to USGS Custom Software Development? ● We all use various

How does this apply to USGS Custom Software Development? ● We all use various software to write, manage, and sometimes deploy software as code. ● Fed. RAMP dictates which software as a service products are approved for use. ● Example: Git. Hub (free version) ○ ○ ○ NOT Fed. RAMP compliant DOI has the authority to block at any time USGS offers Git. Lab on internal servers that is Fed. RAMP compliant

CHS and Authorized Cloud In 2016, the USGS put in place a memorandum for

CHS and Authorized Cloud In 2016, the USGS put in place a memorandum for Governance of Cloud Solution to comply with FITARA. ● Cloud Hosting Solutions (CHS) provides the official approved cloud computing environment for USGS. ● Requests to use other cloud solutions must be approved by the USGS Associate Chief Information Officer (ACIO). ● Possible Iaa. S and Paa. S alternatives to CHS include ○ ○ Geoplatform. gov - provides various services, applications, communities, data, etc. managed under FGDC Pangeo. io - Scientific software community that also provides a cloud Paa. S for scientific applications, HPC, and big data analytics. “Deployments” can be downloaded and installed on -prem or in other clouds and customized.

How does this apply to USGS Custom Software Development? ● It is best practice

How does this apply to USGS Custom Software Development? ● It is best practice to deploy software in the cloud to take advantage of the scalability and efficiency that come with cloud deployments. ● Cloud also provides more immediate access to emerging software deployment technology such as containerization, automation, orchestration, devops, and serverless architecture. ● All cloud service onboarding must start with a cloud service request to CHS: https: //taskmgr. chs. usgs. gov/servicedesk/customer/portal/10/user/login? destination=portal%2 F 10 ● Any cloud requests not serviceable by CHS will be referred to OEI to assist with identifying viable cloud alternatives.

System of Records Notice (SORN) A system of records is defined as any group

System of Records Notice (SORN) A system of records is defined as any group of records under the control of an agency from which information is retrieved by the name of the individual or by some identifying number, symbol, or other identifying particular assigned to the individual 5 U. S. C. 552 a(a)(5). ● ● The USGS has 12 systems of records, which are found on the U. S. Geological Survey Systems of Records Notices webpage The Department of the Interior has a number of department-wide systems of records, and some agencies. Agencies publish a list of their system notices in the Federal Register. The DOI SORNs are found on the Privacy Act Systems of Records Notices webpage. Employees have the right to see most records about themselves if the records are in a system of records. Employees have the right to request amendment of information that is inaccurate, irrelevant, untimely, or incomplete. If there is no established system of records, access by personal identifiers is prohibited.

How does this apply to USGS Custom Software Development? Each System Manager is responsible

How does this apply to USGS Custom Software Development? Each System Manager is responsible for maintaining and protecting records in a system of records by ensuring that the system notice is accurate, that the use of the records complies with the intended purpose, and that the records are safeguarded and released in accordance with the provisions of the Privacy Act. 1. 2. 3. 4. 5. 6. A system of records is required if there is an indexing or retrieval capability using identifiers built into the system and the agency retrieves records about individuals by reference to some personal identifier. Under a system of records, authorized individuals are given access to the data according to the terms established. An individual should have access to only their own data (which they can amend) in a system of records. There are 10 exemptions to this, mostly related to law-enforcement activities. When computer matches are made with other Federal or state government agencies (i. e. , when matches are used to verify eligibility for federal benefits programs) refer to the DOI OCIO Directive 2001 -002 Guidance on Inter-Agency Sharing of Personal Data, and Privacy Protection Measures in System Development and Applications. When contractors are provided for the operation of a system of records on behalf of the USGS, refer to DOI Regulations at 43 CFR § 2. 228 “Government contracts. ” For help with privacy contract clause requirements, refer to DOI Acquisition Regulations DIAR 1452. 224 -1. NTK: https: //atthecore. usgs. gov/science-support/information-technology-it-security/system-records-notice-sorn

Authorization of Software Installations Downloads, installations, and usage of unauthorized software is inherently risky

Authorization of Software Installations Downloads, installations, and usage of unauthorized software is inherently risky and must be avoided at all cost to prevent infection, compromise to host and other systems on the network. It is a policy violation per the Rules Of Behavior (ROB) and DOI and USGS security guidance. ● Applies to all OS for COTS, Cloud, and USGS-developed software ● SCCM / Big. Fix - applications that manage software installation and versioning at Center and enterprise levels. ● In the near future DOI will be running an application that scans computers for unauthorized software.

How does this apply to USGS Custom Software Development? ● Applies to desktop applications

How does this apply to USGS Custom Software Development? ● Applies to desktop applications development ● Applies to software you may want to install on your computer as part of the development process. ● Software Applications must be digitally signed. ● Software Applications must be acquired from known or leading vendors. ● User should first find and utilize enterprise supported and recommended alternative from BWTST or BUTST site. ● Monitor notifications from Technical Support Team. ● Local IT staff can provide guidance and use the SCCM client to deploy needed software.

Federal Source Code Policy With limited exceptions, all source code associated with USGS software

Federal Source Code Policy With limited exceptions, all source code associated with USGS software must be made available at a minimum for Federal Government-wide reuse. Prior to starting a new software project, a strategic analysis of mission goals and existing open, mixed, and proprietary software solutions free of preconceived preferences must be considered to comply with the 2016 Federal Source Code Policy (as described in OMB M-16 -21). Custom-developed code may only be considered if existing solutions do not adequately satisfy USGS needs or the purpose of science and innovation. https: //sourcecode. cio. gov/ ● ● ● Applies to all custom developed code Required to release publicly a minimum of 20% custom developed source code and encouraged to release as much as possible No current DOI or USGS policy interpretation… yet. Associated code repository - https: //code. gov/ JSON metadata

How does this apply to USGS Custom Software Development? ● Official version of source

How does this apply to USGS Custom Software Development? ● Official version of source code needs to be maintained in an official USGS repository ○ ○ Open. Source Git. Lab (code. usgs. gov) Inner. Source Git. Lab (code. chs. usgs. gov) ● Include a code. json metadata file in the root of the repository ○ The required fields are name, organization, description, version, status, permissions, URL links, tags, languages, contact name and email, and date.

Software Management Website ● Updates coming soon! ● High level overview of relevant USGS

Software Management Website ● Updates coming soon! ● High level overview of relevant USGS information and best practices https: //www. usgs. gov/products/software-management