User:Shawndouglas/sandbox/sublevel28 - Revision history

Shawndouglas at 20:31, 16 August 2023

2023-08-16T20:31:36Z

← Older revision		Revision as of 20:31, 16 August 2023
Line 3:		Line 3:
	\| type = notice		\| type = notice
	\| style = width: 960px;		\| style = width: 960px;
	\| text = This is ~~sublevel27~~ of my sandbox, where I play with features and test MediaWiki code. If you wish to leave a comment for me, please see [[User_talk:Shawndouglas\|my discussion page]] instead.<p></p>		\| text = This is sublevel28 of my sandbox, where I play with features and test MediaWiki code. If you wish to leave a comment for me, please see [[User_talk:Shawndouglas\|my discussion page]] instead.<p></p>
	}}		}}

	==Sandbox begins below==		==Sandbox begins below==

Shawndouglas: Replaced content with "
TOC
{{ombox | type = notice | style = width: 960px; | text = This is sublevel27 of my sandbox, where I play with features and..."

2023-08-16T20:31:24Z

Replaced content with "<div class="nonumtoc">__TOC__</div> {{ombox | type = notice | style = width: 960px; | text = This is sublevel27 of my sandbox, where I play with features and..."

← Older revision		Revision as of 20:31, 16 August 2023
Line 1:		Line 1:
	===~~6.2 What should your lab look for in a cloud provider?~~===		<div class="nonumtoc">__TOC__</div>
	~~Admittedly, it may appear that the previous section sets a relatively high bar for providers of cloud services. The reality~~ of ~~some cloud providers may be less than that ideal, however. For example, customer service may be lacking in some companies~~, ~~or the agent assigned to work~~ with ~~you is having a rough patch~~ and ~~isn't addressing your lab's needs that well~~. The CSP's contract language may not be clear, the warranty less than ideal, or the security lacking for your lab's needs. It's even possible that the CSP doesn't have much experience working with laboratories to begin with. This requires strong initial reconnaissance (i.e., due diligence) on the part of your laboratory and its cloud project stakeholders, finding available options and running them through iterative filters to better vet those CSPs who are most likely to ~~meet the lab's needs. And even then, after that internal due diligence—which may include~~ a ~~request~~ for ~~information (RFI)—it's possible that what those CSPs are offering doesn't completely agree with your lab's stated requirements~~, ~~requiring careful evaluation of the differences in order to understand the potential effects and internal changes to organizational goals and service expectations~~.<~~ref name="FFIEC_Out04"~~>~~{{cite web \|url=https:~~//ithandbook.ffiec.gov/media/274841/ffiec_itbooklet_outsourcingtechnologyservices.pdf \|archiveurl=https://web.archive.org/web/20220201011601/https://ithandbook.ffiec.gov/media/274841/ffiec_itbooklet_outsourcingtechnologyservices.pdf \|format=PDF \|title=Outsourcing Technology Services \|author=Federal Financial Institutions Examination Council \|publisher=FFIEC \|date=June 2004 \|archivedate=01 February 2022 \|accessdate=23 May 2021}}~~</ref>~~		{{ombox
			\| type = notice
			\| style = width: 960px;
			\| text = This is sublevel27 of my sandbox, where I play with features and test MediaWiki code. If you wish to leave a comment for me, please see [[User_talk:Shawndouglas\|my discussion page]] instead.<p></p>
			}}

	~~What should these initial filters look like? Aspects of the answer have been touched upon already in prior chapters, and some haven't. Let's break it down.~~		==Sandbox begins below==

	'''Service and deployment models offered''': We've already talked at length about the various service and deployment models, their benefits and risks, and what they bring to the table for laboratories. In the end, the specifics of this important filter will be decided by the goals and requirements decided upon in your laboratory's cloud project planning.

	'''Technologies used''': Though cloud providers largely have relatively agnostic open-source architecture components, each may have a few nuances that would affect your deployment onto their service. Your laboratory's cloud project planning will have ideally identified any technology-specific nuances to your applications and data, which will further guide your filters. If other Google applications play a significant role in your organization's operations, Google Cloud may have a slight edge as far as integrations go.

	'''Compliance offerings and security''': Most labs work in some sort of regulatory environment. Those regulations may vary slightly from industry to industry (e.g., the regulatory demands for the cannabis testing lab will differ from those of the clinical testing lab), and how each cloud provider addresses them will differ, sometimes significantly. One would assume that, for example, a SaaS vendor offering a cloud-based [[laboratory information management system]] (LIMS) has baked in all the necessary regulatory considerations into their offering and underlying infrastructure, but this can't necessarily be taken for granted. This is where you ask the public cloud provider for their documented compliance certifications, attestations, alignments, and frameworks relevant to your lab that qualify their infrastructure, or ask the SaaS vendor to provide their own documentation on how their software—and, if applicable, any third-party [[infrastructure as a service]] (IaaS)—remains compliant or betters lab compliance in the cloud. Additionally, how the SaaS software vendor handles validation may be an important filter to consider.<ref name=~~"BradyAGuide19">{{cite web \|url~~=~~https://www.compliantcloud.com/a-guide-to-validated-software-as-a-service-saas/ \|archiveurl~~=~~https://web.archive.org/web/20201107225517/https://www.compliantcloud.com/a-guide-to-validated-software-as-a-service-saas/ \|title~~=~~A Guide to Validated Software as a Service (SaaS) \|author=Brady, N. \|work=Compliant Cloud \|date=06 August 2019 \|archivedate=07 November 2020 \|accessdate=21 August 2021}}</ref>~~

	'''Shared responsibility''': Whether through an outright model or by explaining in contract language, a CSP should be able to make clear the differences in responsibility for the security of a cloud service offering. It's always a plus when the CSP provides this information on their website, but you may have to ask a representative to explain the CSP's approach. Those who can't, or those whose responsibility burden isn't compatible with your laboratory's needs may get stuck in the filter.

	'''Risk management and insurance''': While your laboratory will most certainly need to address its own risk management practices, as well as whether or not cybersecurity insurance makes sense, don't forget to investigate these matters with any potential CSP. Are they willing to discuss their risk management strategies as applied to their software and infrastructure? Do they have cyber insurance, and if so, what are the details? These may not be deal-breakers, per se, but if you're splitting hairs between two providers, one with a solid cyber insurance policy and one not so much, it may be a determining factor.

	'''Interoperability and portability''': The question of interoperability and portability—the vendor lock-in question—may or may not be considered a major risk factor for your laboratory. But if ensuring your laboratory can pick up its data and applications and move them relatively painlessly to another CSP is a concern, you'll investigate these matters before deciding on your CSP. This may be particularly tricky with a SaaS provider; you may be able to extract your data from their application if they go bankrupt or you decide to move to a new application, but how portable will it be for the next migration?

	'''Pricing, warranty, and support''': Transparency at every pricing step is important for any laboratory trying to determine what the current and future budget for cloud services will be. It's especially imperative for laboratories funded in part by grants. As Navale and Bourne note in their discussion on cloud computing for biomedical science, "[c]loud vendors are seeking an all-in model. Once you commit to using their services, you continue to do so or pay a significant penalty. This, combined with being a pay-as-you-go model, has implications when mapped to the up-front funding models of typical grants."<ref name="NavaleCloud18">{{cite journal \|title=Cloud computing applications for biomedical science: A perspective \|journal=PLoS Computational Biology \|author=Navale, V.; Bourne, P.E. \|volume=14 \|issue=6 \|at=e1006144 \|year=2018 \|doi=10.1371/journal.pcbi.1006144 \|pmid=29902176 \|pmc=PMC6002019}}</ref> As such, your lab will not only look for clear pricing but will also ask about any unanticipated "gotcha" fees and penalties that may apply to your use of the service. Investigating CSPs for their approaches to warrantying their services and products, and supporting them when things go wrong, should also not be overlooked.

	'''Software development practices''': Writing for CSols, a [[laboratory informatics]] consultancy, consultant Bob McDowall emphasizes several areas of a developer's software development practices that laboratories seeking a SaaS solution should consider. Can the SaaS vendor<ref name="McDowallClouds20">{{cite web \|url=https://www.csolsinc.com/blog/clouds-or-clods-software-as-a-service-in-gxp-regulated-laboratories/ \|title=Clouds or Clods? Software as a Service in GxP Regulated Laboratories \|author=McDowall, B. \|work=CSols Blog \|publisher=CSols, Inc \|date=27 August 2020 \|accessdate=15 August 2023}}</ref>:

	* describe their software development life cycle and how it benefits your lab?
	* provide reliable support for their application?
	* explain the virtual IT infrastructure running the software?
	* describe the GxP and other regulatory-based training staff have?
	* explain how the application is configured prior to laboratory validation?
	* explain its approach to risk management with any underlying IaaS supplier?
	* define in a clear manner the work to be performed and how it's expressed in any agreement?
	* batch "agile" cloud software releases into a single annual upgrade, vs. updating every quarter, for validated environments such as pharmaceuticals?

	'''Trust and reputation''': This may be one of the more difficult, or at least time-consuming, investigative steps when considering CSPs. Most CSPs will have a trust center or document explaining the myriad ways you, the customer, should put trust in their services (a one-to-one opinion). However, reputation is based on an aggregate of opinions from a community towards the CSP, which is, broadly speaking, based on experiences concerning the transparency, accountability, and value provided by the CSP.<ref name="HuangTrust13">{{cite journal \|title=Trust mechanisms for cloud computing \|journal=Journal of Cloud Computing \|author=Huang, J.; Nicol, D.M. \|volume=2 \|at=9 \|year=2013 \|doi=10.1186/2192-113X-2-9}}</ref> The CSP usually supplies you with information concerning trust, but reputation is discovered not only through, e.g., case studies supplied by the CSP but also by having conversations with past and current clients of the CSP. In both cases, though a non-trivial process, your lab should take the time to pass any prospective CSPs through these filters.

	'''Service-level agreement''': A service-level agreement (SLA) defines the service expectations between the laboratory and the CSP, how meeting those expectations should be measured, and what should happen if those expectations are not met.<ref name="OverbyWhatIs17">{{cite web \|url=https://www.cio.com/article/274740/outsourcing-sla-definitions-and-solutions.html \|title=What is an SLA? Best practices for service-level agreements \|author=Overby, S.; Greiner, L.; Paul, L.G. \|work=CIO \|date=05 July 2017 \|accessdate=21 August 2021}}</ref> Let's talk a bit more about that in the next subsection.

	~~====6.2.1 Service-level agreements====~~
	At various points in this guide we've talked about various contracts and agreements, but only a little bit about SLAs. Last chapter we said the SLA essentially defines all the responsibility the cloud provider holds, as well as your laboratory, for the supply and use of the CSP's services. This is the "meat and potatoes" of the service paperwork that will cross your eyes. The SLA, in a sense, offers a set of primary legal protections and, ideally, clearly expresses the expectations placed at the feet of both parties. With a well-crafted, signed SLA, neither party can say they were unaware of a stipulation, responsibility, or expectation. By signing the SLA, the laboratory also admits that the document is largely representative of the technological or organizational goals of the lab, and the CSP of its goals.

	SLAs will have numerous components to it addressing both the implementation and use of the service and the management aspects of the service, indicating what services are provided and excluded, the conditions of availability for the provided services, any differing service levels, each party's responsibilities, reporting processes, escalation and dispute procedures, remediation and indemnification methods, cost compromises, and contract change management.<ref name="OverbyWhatIs17" /> It would be beyond the scope of this guide to provide broad information about all the elements of an SLA and how to approach them; entire books have been written about the subject over the years.<ref name="WiederService11">{{cite book \|title=Service Level Agreements for Cloud Computing \|editor=Wieder, P.; Butler, J.M.; Theilmann, W. et al. \|publisher=Springer \|year=2011 \|isbn=9781461416159}}</ref><ref name="RussoTheCloud18">{{cite book \|title=The Cloud Service Level Agreement: A Supplement for NIST 800-171 Implementation \|author=Russo, M.A. \|publisher=Syber Risk \|year=2018 \|isbn=9781983156533}}</ref> However, let's look at a few of those aspects, from the perspective of the laboratory examining a CSP's SLA.

	In early 2020, laboratory informatics and scientific consultancy Astrix provided some key insights about SLAs for labs moving to the cloud. Astrix president Dale Curtis emphasized that when examining any SLA, ensure that it's largely addressing "what" questions rather than digging into the minutia of "how" questions; too much "how" and you start losing the other benefits inherent to the SLA.<ref name="CurtisConsid20">{{cite web \|url=https://astrixinc.com/considerations-for-cloud-hosting-your-laboratory-informatics-systems/ \|title=Considerations for Cloud Hosting Your Laboratory Informatics Systems \|author=Curtis Jr., D. \|publisher=Astrix, Inc \|date=24 January 2020 \|accessdate=21 August 2021}}</ref> Does the SLA address "what"<ref name="CurtisConsid20" />:

	* the specific parameters of the business-significant services offered to your laboratory are, and what happens when those parameters are not met?
	* the ownership rights to service data are for both parties, including discussion of the data request and return processes and their timelines, the format the data will be returned in, the retention times of your data after a CSP closure or contract termination, and the penalties for non-compliance?
	* your laboratory's rights to continue and discontinue services are "within and outside of contract renewal timelines," and what the associated costs and penalties may be?
	* the standards and regulatory requirements affecting the CSP's cloud service(s) are, giving you any rights to audit the service for compliance?
	* the incident resolution process looks like, and how long it will take to complete?
	* the change management process for updates and upgrades looks like, including how it will be communicated and scheduled?
	* the CSP's disaster recovery process is and what you, the lab, should expect in case of various risks and disasters being realized?

Shawndouglas at 23:43, 15 August 2023

2023-08-15T23:43:10Z

← Older revision		Revision as of 23:43, 15 August 2023
Line 18:		Line 18:
	'''Pricing, warranty, and support''': Transparency at every pricing step is important for any laboratory trying to determine what the current and future budget for cloud services will be. It's especially imperative for laboratories funded in part by grants. As Navale and Bourne note in their discussion on cloud computing for biomedical science, "[c]loud vendors are seeking an all-in model. Once you commit to using their services, you continue to do so or pay a significant penalty. This, combined with being a pay-as-you-go model, has implications when mapped to the up-front funding models of typical grants."<ref name="NavaleCloud18">{{cite journal \|title=Cloud computing applications for biomedical science: A perspective \|journal=PLoS Computational Biology \|author=Navale, V.; Bourne, P.E. \|volume=14 \|issue=6 \|at=e1006144 \|year=2018 \|doi=10.1371/journal.pcbi.1006144 \|pmid=29902176 \|pmc=PMC6002019}}</ref> As such, your lab will not only look for clear pricing but will also ask about any unanticipated "gotcha" fees and penalties that may apply to your use of the service. Investigating CSPs for their approaches to warrantying their services and products, and supporting them when things go wrong, should also not be overlooked.		'''Pricing, warranty, and support''': Transparency at every pricing step is important for any laboratory trying to determine what the current and future budget for cloud services will be. It's especially imperative for laboratories funded in part by grants. As Navale and Bourne note in their discussion on cloud computing for biomedical science, "[c]loud vendors are seeking an all-in model. Once you commit to using their services, you continue to do so or pay a significant penalty. This, combined with being a pay-as-you-go model, has implications when mapped to the up-front funding models of typical grants."<ref name="NavaleCloud18">{{cite journal \|title=Cloud computing applications for biomedical science: A perspective \|journal=PLoS Computational Biology \|author=Navale, V.; Bourne, P.E. \|volume=14 \|issue=6 \|at=e1006144 \|year=2018 \|doi=10.1371/journal.pcbi.1006144 \|pmid=29902176 \|pmc=PMC6002019}}</ref> As such, your lab will not only look for clear pricing but will also ask about any unanticipated "gotcha" fees and penalties that may apply to your use of the service. Investigating CSPs for their approaches to warrantying their services and products, and supporting them when things go wrong, should also not be overlooked.

	'''Software development practices''': Writing for CSols, a [[laboratory informatics]] consultancy, consultant Bob McDowall emphasizes several areas of a developer's software development practices that laboratories seeking a SaaS solution should consider. Can the SaaS vendor<ref name="McDowallClouds20">{{cite web \|url=https://www.csolsinc.com/blog/clouds-or-clods-software-as-a-service-in-gxp-regulated-laboratories/ \|title=Clouds or Clods? Software as a Service in GxP Regulated Laboratories \|author=McDowall, B. \|work=CSols Blog \|publisher=CSols, Inc \|date=27 August 2020 \|accessdate=21 August ~~2021~~}}</ref>:		'''Software development practices''': Writing for CSols, a [[laboratory informatics]] consultancy, consultant Bob McDowall emphasizes several areas of a developer's software development practices that laboratories seeking a SaaS solution should consider. Can the SaaS vendor<ref name="McDowallClouds20">{{cite web \|url=https://www.csolsinc.com/blog/clouds-or-clods-software-as-a-service-in-gxp-regulated-laboratories/ \|title=Clouds or Clods? Software as a Service in GxP Regulated Laboratories \|author=McDowall, B. \|work=CSols Blog \|publisher=CSols, Inc \|date=27 August 2020 \|accessdate=15 August 2023}}</ref>:

	* describe their software development life cycle and how it benefits your lab?		* describe their software development life cycle and how it benefits your lab?

Shawndouglas at 22:50, 27 July 2023

2023-07-27T22:50:57Z

← Older revision	Revision as of 22:50, 27 July 2023
Line 1:	Line 1:
		===6.2 What should your lab look for in a cloud provider?===
		Admittedly, it may appear that the previous section sets a relatively high bar for providers of cloud services. The reality of some cloud providers may be less than that ideal, however. For example, customer service may be lacking in some companies, or the agent assigned to work with you is having a rough patch and isn't addressing your lab's needs that well. The CSP's contract language may not be clear, the warranty less than ideal, or the security lacking for your lab's needs. It's even possible that the CSP doesn't have much experience working with laboratories to begin with. This requires strong initial reconnaissance (i.e., due diligence) on the part of your laboratory and its cloud project stakeholders, finding available options and running them through iterative filters to better vet those CSPs who are most likely to meet the lab's needs. And even then, after that internal due diligence—which may include a request for information (RFI)—it's possible that what those CSPs are offering doesn't completely agree with your lab's stated requirements, requiring careful evaluation of the differences in order to understand the potential effects and internal changes to organizational goals and service expectations.<ref name="FFIEC_Out04">{{cite web \|url=https://ithandbook.ffiec.gov/media/274841/ffiec_itbooklet_outsourcingtechnologyservices.pdf \|archiveurl=https://web.archive.org/web/20220201011601/https://ithandbook.ffiec.gov/media/274841/ffiec_itbooklet_outsourcingtechnologyservices.pdf \|format=PDF \|title=Outsourcing Technology Services \|author=Federal Financial Institutions Examination Council \|publisher=FFIEC \|date=June 2004 \|archivedate=01 February 2022 \|accessdate=23 May 2021}}</ref>

		What should these initial filters look like? Aspects of the answer have been touched upon already in prior chapters, and some haven't. Let's break it down.

		'''Service and deployment models offered''': We've already talked at length about the various service and deployment models, their benefits and risks, and what they bring to the table for laboratories. In the end, the specifics of this important filter will be decided by the goals and requirements decided upon in your laboratory's cloud project planning.

		'''Technologies used''': Though cloud providers largely have relatively agnostic open-source architecture components, each may have a few nuances that would affect your deployment onto their service. Your laboratory's cloud project planning will have ideally identified any technology-specific nuances to your applications and data, which will further guide your filters. If other Google applications play a significant role in your organization's operations, Google Cloud may have a slight edge as far as integrations go.

		'''Compliance offerings and security''': Most labs work in some sort of regulatory environment. Those regulations may vary slightly from industry to industry (e.g., the regulatory demands for the cannabis testing lab will differ from those of the clinical testing lab), and how each cloud provider addresses them will differ, sometimes significantly. One would assume that, for example, a SaaS vendor offering a cloud-based [[laboratory information management system]] (LIMS) has baked in all the necessary regulatory considerations into their offering and underlying infrastructure, but this can't necessarily be taken for granted. This is where you ask the public cloud provider for their documented compliance certifications, attestations, alignments, and frameworks relevant to your lab that qualify their infrastructure, or ask the SaaS vendor to provide their own documentation on how their software—and, if applicable, any third-party [[infrastructure as a service]] (IaaS)—remains compliant or betters lab compliance in the cloud. Additionally, how the SaaS software vendor handles validation may be an important filter to consider.<ref name="BradyAGuide19">{{cite web \|url=https://www.compliantcloud.com/a-guide-to-validated-software-as-a-service-saas/ \|archiveurl=https://web.archive.org/web/20201107225517/https://www.compliantcloud.com/a-guide-to-validated-software-as-a-service-saas/ \|title=A Guide to Validated Software as a Service (SaaS) \|author=Brady, N. \|work=Compliant Cloud \|date=06 August 2019 \|archivedate=07 November 2020 \|accessdate=21 August 2021}}</ref>

		'''Shared responsibility''': Whether through an outright model or by explaining in contract language, a CSP should be able to make clear the differences in responsibility for the security of a cloud service offering. It's always a plus when the CSP provides this information on their website, but you may have to ask a representative to explain the CSP's approach. Those who can't, or those whose responsibility burden isn't compatible with your laboratory's needs may get stuck in the filter.

		'''Risk management and insurance''': While your laboratory will most certainly need to address its own risk management practices, as well as whether or not cybersecurity insurance makes sense, don't forget to investigate these matters with any potential CSP. Are they willing to discuss their risk management strategies as applied to their software and infrastructure? Do they have cyber insurance, and if so, what are the details? These may not be deal-breakers, per se, but if you're splitting hairs between two providers, one with a solid cyber insurance policy and one not so much, it may be a determining factor.

		'''Interoperability and portability''': The question of interoperability and portability—the vendor lock-in question—may or may not be considered a major risk factor for your laboratory. But if ensuring your laboratory can pick up its data and applications and move them relatively painlessly to another CSP is a concern, you'll investigate these matters before deciding on your CSP. This may be particularly tricky with a SaaS provider; you may be able to extract your data from their application if they go bankrupt or you decide to move to a new application, but how portable will it be for the next migration?

		'''Pricing, warranty, and support''': Transparency at every pricing step is important for any laboratory trying to determine what the current and future budget for cloud services will be. It's especially imperative for laboratories funded in part by grants. As Navale and Bourne note in their discussion on cloud computing for biomedical science, "[c]loud vendors are seeking an all-in model. Once you commit to using their services, you continue to do so or pay a significant penalty. This, combined with being a pay-as-you-go model, has implications when mapped to the up-front funding models of typical grants."<ref name="NavaleCloud18">{{cite journal \|title=Cloud computing applications for biomedical science: A perspective \|journal=PLoS Computational Biology \|author=Navale, V.; Bourne, P.E. \|volume=14 \|issue=6 \|at=e1006144 \|year=2018 \|doi=10.1371/journal.pcbi.1006144 \|pmid=29902176 \|pmc=PMC6002019}}</ref> As such, your lab will not only look for clear pricing but will also ask about any unanticipated "gotcha" fees and penalties that may apply to your use of the service. Investigating CSPs for their approaches to warrantying their services and products, and supporting them when things go wrong, should also not be overlooked.

		'''Software development practices''': Writing for CSols, a [[laboratory informatics]] consultancy, consultant Bob McDowall emphasizes several areas of a developer's software development practices that laboratories seeking a SaaS solution should consider. Can the SaaS vendor<ref name="McDowallClouds20">{{cite web \|url=https://www.csolsinc.com/blog/clouds-or-clods-software-as-a-service-in-gxp-regulated-laboratories/ \|title=Clouds or Clods? Software as a Service in GxP Regulated Laboratories \|author=McDowall, B. \|work=CSols Blog \|publisher=CSols, Inc \|date=27 August 2020 \|accessdate=21 August 2021}}</ref>:

		* describe their software development life cycle and how it benefits your lab?
		* provide reliable support for their application?
		* explain the virtual IT infrastructure running the software?
		* describe the GxP and other regulatory-based training staff have?
		* explain how the application is configured prior to laboratory validation?
		* explain its approach to risk management with any underlying IaaS supplier?
		* define in a clear manner the work to be performed and how it's expressed in any agreement?
		* batch "agile" cloud software releases into a single annual upgrade, vs. updating every quarter, for validated environments such as pharmaceuticals?

		'''Trust and reputation''': This may be one of the more difficult, or at least time-consuming, investigative steps when considering CSPs. Most CSPs will have a trust center or document explaining the myriad ways you, the customer, should put trust in their services (a one-to-one opinion). However, reputation is based on an aggregate of opinions from a community towards the CSP, which is, broadly speaking, based on experiences concerning the transparency, accountability, and value provided by the CSP.<ref name="HuangTrust13">{{cite journal \|title=Trust mechanisms for cloud computing \|journal=Journal of Cloud Computing \|author=Huang, J.; Nicol, D.M. \|volume=2 \|at=9 \|year=2013 \|doi=10.1186/2192-113X-2-9}}</ref> The CSP usually supplies you with information concerning trust, but reputation is discovered not only through, e.g., case studies supplied by the CSP but also by having conversations with past and current clients of the CSP. In both cases, though a non-trivial process, your lab should take the time to pass any prospective CSPs through these filters.

		'''Service-level agreement''': A service-level agreement (SLA) defines the service expectations between the laboratory and the CSP, how meeting those expectations should be measured, and what should happen if those expectations are not met.<ref name="OverbyWhatIs17">{{cite web \|url=https://www.cio.com/article/274740/outsourcing-sla-definitions-and-solutions.html \|title=What is an SLA? Best practices for service-level agreements \|author=Overby, S.; Greiner, L.; Paul, L.G. \|work=CIO \|date=05 July 2017 \|accessdate=21 August 2021}}</ref> Let's talk a bit more about that in the next subsection.

		====6.2.1 Service-level agreements====
		At various points in this guide we've talked about various contracts and agreements, but only a little bit about SLAs. Last chapter we said the SLA essentially defines all the responsibility the cloud provider holds, as well as your laboratory, for the supply and use of the CSP's services. This is the "meat and potatoes" of the service paperwork that will cross your eyes. The SLA, in a sense, offers a set of primary legal protections and, ideally, clearly expresses the expectations placed at the feet of both parties. With a well-crafted, signed SLA, neither party can say they were unaware of a stipulation, responsibility, or expectation. By signing the SLA, the laboratory also admits that the document is largely representative of the technological or organizational goals of the lab, and the CSP of its goals.

		SLAs will have numerous components to it addressing both the implementation and use of the service and the management aspects of the service, indicating what services are provided and excluded, the conditions of availability for the provided services, any differing service levels, each party's responsibilities, reporting processes, escalation and dispute procedures, remediation and indemnification methods, cost compromises, and contract change management.<ref name="OverbyWhatIs17" /> It would be beyond the scope of this guide to provide broad information about all the elements of an SLA and how to approach them; entire books have been written about the subject over the years.<ref name="WiederService11">{{cite book \|title=Service Level Agreements for Cloud Computing \|editor=Wieder, P.; Butler, J.M.; Theilmann, W. et al. \|publisher=Springer \|year=2011 \|isbn=9781461416159}}</ref><ref name="RussoTheCloud18">{{cite book \|title=The Cloud Service Level Agreement: A Supplement for NIST 800-171 Implementation \|author=Russo, M.A. \|publisher=Syber Risk \|year=2018 \|isbn=9781983156533}}</ref> However, let's look at a few of those aspects, from the perspective of the laboratory examining a CSP's SLA.

		In early 2020, laboratory informatics and scientific consultancy Astrix provided some key insights about SLAs for labs moving to the cloud. Astrix president Dale Curtis emphasized that when examining any SLA, ensure that it's largely addressing "what" questions rather than digging into the minutia of "how" questions; too much "how" and you start losing the other benefits inherent to the SLA.<ref name="CurtisConsid20">{{cite web \|url=https://astrixinc.com/considerations-for-cloud-hosting-your-laboratory-informatics-systems/ \|title=Considerations for Cloud Hosting Your Laboratory Informatics Systems \|author=Curtis Jr., D. \|publisher=Astrix, Inc \|date=24 January 2020 \|accessdate=21 August 2021}}</ref> Does the SLA address "what"<ref name="CurtisConsid20" />:

		* the specific parameters of the business-significant services offered to your laboratory are, and what happens when those parameters are not met?
		* the ownership rights to service data are for both parties, including discussion of the data request and return processes and their timelines, the format the data will be returned in, the retention times of your data after a CSP closure or contract termination, and the penalties for non-compliance?
		* your laboratory's rights to continue and discontinue services are "within and outside of contract renewal timelines," and what the associated costs and penalties may be?
		* the standards and regulatory requirements affecting the CSP's cloud service(s) are, giving you any rights to audit the service for compliance?
		* the incident resolution process looks like, and how long it will take to complete?
		* the change management process for updates and upgrades looks like, including how it will be communicated and scheduled?
		* the CSP's disaster recovery process is and what you, the lab, should expect in case of various risks and disasters being realized?

Shawndouglas: Blanked the page

2021-09-06T13:11:51Z

Blanked the page

Show changes

Shawndouglas: /* 5.3.8 Declare and describe objectives based on the outcomes of the above assessments */

2020-07-23T19:10:35Z

5.3.8 Declare and describe objectives based on the outcomes of the above assessments

← Older revision		Revision as of 19:10, 23 July 2020
Line 112:		Line 112:
	After performing all that research, it's finally time to distill it down into a clear set of cybersecurity objectives. Those objectives will act as the underlying core for the actions the business will take to develop policies, fill in security gaps, monitor progress, and educate staff. The objectives that come out of this step "should be specific, realistic, and actionable."<ref name="NARUCCyber18" /> In a world where cyber threats are constantly evolving, being "100 percent secure against cyber threats" is an unrealistic goal, for example.<ref name="NARUCCyber18" />		After performing all that research, it's finally time to distill it down into a clear set of cybersecurity objectives. Those objectives will act as the underlying core for the actions the business will take to develop policies, fill in security gaps, monitor progress, and educate staff. The objectives that come out of this step "should be specific, realistic, and actionable."<ref name="NARUCCyber18" /> In a world where cyber threats are constantly evolving, being "100 percent secure against cyber threats" is an unrealistic goal, for example.<ref name="NARUCCyber18" />

	One way to go about this process is to go back to the cybersecurity ~~goals~~ you created (see 5.1.3) and place your objectives under the goals they support. Perhaps one of your goals is to promote a culture of cybersecurity awareness among all employees and contractors. Under that goal you could list objectives such as "improve subject-matter expertise among leadership" and "support and encourage biannual cybersecurity training exercises throughout the business." You may also want to, at this point, make mention of what prioritization the objectives have and what progress measurement mechanisms can and should be put in place. Finally, work a certain level of adaptability into the objectives, not only in what they should achieve but also how they should be evaluated and updated. Technology, attack vectors, and even business needs can change rapidly. The objectives you develop should take this into consideration, as should the review and update policy for the cybersecurity plan itself (discussed later).		One way to go about this process is to go back to the cybersecurity strategy you created (see 5.1.3) and place your objectives under the strategic goals they support. Perhaps one of your goals is to promote a culture of cybersecurity awareness among all employees and contractors. Under that goal you could list objectives such as "improve subject-matter expertise among leadership" and "support and encourage biannual cybersecurity training exercises throughout the business." You may also want to, at this point, make mention of what prioritization the objectives have and what progress measurement mechanisms can and should be put in place. Finally, work a certain level of adaptability into the objectives, not only in what they should achieve but also how they should be evaluated and updated. Technology, attack vectors, and even business needs can change rapidly. The objectives you develop should take this into consideration, as should the review and update policy for the cybersecurity plan itself (discussed later).

	It's important to note that at this point of identifying cybersecurity requirements and objectives, and into the subsequent two steps of identifying policies and selecting and refining controls, the concept of risk management should be front and center. In a 2016 letter to the U.S. Commission on Enhancing National Cybersecurity, computing experts Lipner and Lampson emphasized the difficulty of cybersecurity risk management<ref name="LipnerRisk16">{{cite web \|url=https://www.nist.gov/system/files/documents/2016/09/16/s.lipner-b.lampson_rfi_response.pdf \|format=PDF \|title=Risk Management and the Cybersecurity of the U.S. Government - Input to the Commission on Enhancing National Cybersecurity \|author=Lipner, S.B.; Lampson, B.W. \|date=September 2016 \|accessdate=23 July 2020}}</ref>:		It's important to note that at this point of identifying cybersecurity requirements and objectives, and into the subsequent two steps of identifying policies and selecting and refining controls, the concept of risk management should be front and center. In a 2016 letter to the U.S. Commission on Enhancing National Cybersecurity, computing experts Lipner and Lampson emphasized the difficulty of cybersecurity risk management<ref name="LipnerRisk16">{{cite web \|url=https://www.nist.gov/system/files/documents/2016/09/16/s.lipner-b.lampson_rfi_response.pdf \|format=PDF \|title=Risk Management and the Cybersecurity of the U.S. Government - Input to the Commission on Enhancing National Cybersecurity \|author=Lipner, S.B.; Lampson, B.W. \|date=September 2016 \|accessdate=23 July 2020}}</ref>:

Shawndouglas: /* 5.3.8 Declare and describe objectives based on the outcomes of the above assessments */

2020-07-23T19:08:09Z

5.3.8 Declare and describe objectives based on the outcomes of the above assessments

← Older revision		Revision as of 19:08, 23 July 2020
Line 118:		Line 118:
	<blockquote>"It is impossible to measure precisely either the amount of security a given investment buys or the expected consequences of less than perfect security. Thus, decision makers must make security investments whose benefits are very uncertain. This makes it tempting to spend less on security and more on new programs or other alternatives with more visible benefits."</blockquote>		<blockquote>"It is impossible to measure precisely either the amount of security a given investment buys or the expected consequences of less than perfect security. Thus, decision makers must make security investments whose benefits are very uncertain. This makes it tempting to spend less on security and more on new programs or other alternatives with more visible benefits."</blockquote>

	Despite these difficulties, the process of translating gap analysis and risk analysis into actionable and realistic objectives must be done. But you're close to or already have made the inroads to reaching this point. You've inventoried and examined the hardware and network settings you already use (5.3.1). You've examined your existing (and possibly even future) data and declared its criticality (5.3.2) in the context of the regulations, standards, and best practices affecting your assets and data (5.3.4). And you've reviewed your existing policies, looking for areas of improvement (5.3.3). You know where you are and where you want to go. Now the risk management components arrive in the form of objectives (5.3.8) that align with your overall cybersecurity strategy (5.1.3), the policies ~~required for~~ creation and modification (5.3.9), and the security controls chosen to support those objectives and policies (5.3.10). If you realize this full approach, cybyersecurity risk management should come naturally, by extension.		Despite these difficulties, the process of translating gap analysis and risk analysis into actionable and realistic objectives must be done. But you're close to or already have made the inroads to reaching this point. You've inventoried and examined the hardware and network settings you already use (5.3.1). You've examined your existing (and possibly even future) data and declared its criticality (5.3.2) in the context of the regulations, standards, and best practices affecting your assets and data (5.3.4). And you've reviewed your existing policies, looking for areas of improvement (5.3.3). You know where you are and where you want to go. Now the risk management components arrive in the form of objectives (5.3.8) that align with your overall cybersecurity strategy (5.1.3), the tangential cybersecurity policies requiring creation and modification (5.3.9), and the security controls chosen to support those objectives and policies (5.3.10). If you realize this full approach, cybyersecurity risk management should come naturally, by extension.

	====5.3.9 Identify policies for creation or modification concerning passwords, physical security, etc., particularly where gaps have been identified from the prior assessments and objectives====		====5.3.9 Identify policies for creation or modification concerning passwords, physical security, etc., particularly where gaps have been identified from the prior assessments and objectives====

Shawndouglas: /* 5.3.8 Declare and describe objectives based on the outcomes of the above assessments */

2020-07-23T18:58:11Z

5.3.8 Declare and describe objectives based on the outcomes of the above assessments

← Older revision		Revision as of 18:58, 23 July 2020
Line 116:		Line 116:
	It's important to note that at this point of identifying cybersecurity requirements and objectives, and into the subsequent two steps of identifying policies and selecting and refining controls, the concept of risk management should be front and center. In a 2016 letter to the U.S. Commission on Enhancing National Cybersecurity, computing experts Lipner and Lampson emphasized the difficulty of cybersecurity risk management<ref name="LipnerRisk16">{{cite web \|url=https://www.nist.gov/system/files/documents/2016/09/16/s.lipner-b.lampson_rfi_response.pdf \|format=PDF \|title=Risk Management and the Cybersecurity of the U.S. Government - Input to the Commission on Enhancing National Cybersecurity \|author=Lipner, S.B.; Lampson, B.W. \|date=September 2016 \|accessdate=23 July 2020}}</ref>:		It's important to note that at this point of identifying cybersecurity requirements and objectives, and into the subsequent two steps of identifying policies and selecting and refining controls, the concept of risk management should be front and center. In a 2016 letter to the U.S. Commission on Enhancing National Cybersecurity, computing experts Lipner and Lampson emphasized the difficulty of cybersecurity risk management<ref name="LipnerRisk16">{{cite web \|url=https://www.nist.gov/system/files/documents/2016/09/16/s.lipner-b.lampson_rfi_response.pdf \|format=PDF \|title=Risk Management and the Cybersecurity of the U.S. Government - Input to the Commission on Enhancing National Cybersecurity \|author=Lipner, S.B.; Lampson, B.W. \|date=September 2016 \|accessdate=23 July 2020}}</ref>:

	"It is impossible to measure precisely either the amount of security a given investment buys or the expected consequences of less than perfect security. Thus, decision makers must make security investments whose benefits are very uncertain. This makes it tempting to spend less on security and more on new programs or other alternatives with more visible benefits."		<blockquote>"It is impossible to measure precisely either the amount of security a given investment buys or the expected consequences of less than perfect security. Thus, decision makers must make security investments whose benefits are very uncertain. This makes it tempting to spend less on security and more on new programs or other alternatives with more visible benefits."</blockquote>

	Despite these difficulties, the process of translating gap analysis and risk analysis into actionable and realistic objectives must be done. But you're close to or already have made the inroads to reaching this point. You've inventoried and examined the hardware and network settings you already use (5.3.1). You've examined your existing (and possibly even future) data and declared its criticality (5.3.2) in the context of the regulations, standards, and best practices affecting your assets and data (5.3.4). And you've reviewed your existing policies, looking for areas of improvement (5.3.3). You know where you are and where you want to go. Now the risk management components arrive in the form of objectives (5.3.8) that align with your overall cybersecurity strategy (5.1.3), the policies required for creation and modification (5.3.9), and the security controls chosen to support those objectives and policies (5.3.10). If you realize this full approach, cybyersecurity risk management should come naturally, by extension.		Despite these difficulties, the process of translating gap analysis and risk analysis into actionable and realistic objectives must be done. But you're close to or already have made the inroads to reaching this point. You've inventoried and examined the hardware and network settings you already use (5.3.1). You've examined your existing (and possibly even future) data and declared its criticality (5.3.2) in the context of the regulations, standards, and best practices affecting your assets and data (5.3.4). And you've reviewed your existing policies, looking for areas of improvement (5.3.3). You know where you are and where you want to go. Now the risk management components arrive in the form of objectives (5.3.8) that align with your overall cybersecurity strategy (5.1.3), the policies required for creation and modification (5.3.9), and the security controls chosen to support those objectives and policies (5.3.10). If you realize this full approach, cybyersecurity risk management should come naturally, by extension.

Shawndouglas: /* 5.3 Identify cybersecurity requirements and objectives */

2020-07-23T18:57:12Z

5.3 Identify cybersecurity requirements and objectives

← Older revision		Revision as of 18:57, 23 July 2020
Line 113:		Line 113:

	One way to go about this process is to go back to the cybersecurity goals you created (see 5.1.3) and place your objectives under the goals they support. Perhaps one of your goals is to promote a culture of cybersecurity awareness among all employees and contractors. Under that goal you could list objectives such as "improve subject-matter expertise among leadership" and "support and encourage biannual cybersecurity training exercises throughout the business." You may also want to, at this point, make mention of what prioritization the objectives have and what progress measurement mechanisms can and should be put in place. Finally, work a certain level of adaptability into the objectives, not only in what they should achieve but also how they should be evaluated and updated. Technology, attack vectors, and even business needs can change rapidly. The objectives you develop should take this into consideration, as should the review and update policy for the cybersecurity plan itself (discussed later).		One way to go about this process is to go back to the cybersecurity goals you created (see 5.1.3) and place your objectives under the goals they support. Perhaps one of your goals is to promote a culture of cybersecurity awareness among all employees and contractors. Under that goal you could list objectives such as "improve subject-matter expertise among leadership" and "support and encourage biannual cybersecurity training exercises throughout the business." You may also want to, at this point, make mention of what prioritization the objectives have and what progress measurement mechanisms can and should be put in place. Finally, work a certain level of adaptability into the objectives, not only in what they should achieve but also how they should be evaluated and updated. Technology, attack vectors, and even business needs can change rapidly. The objectives you develop should take this into consideration, as should the review and update policy for the cybersecurity plan itself (discussed later).

			It's important to note that at this point of identifying cybersecurity requirements and objectives, and into the subsequent two steps of identifying policies and selecting and refining controls, the concept of risk management should be front and center. In a 2016 letter to the U.S. Commission on Enhancing National Cybersecurity, computing experts Lipner and Lampson emphasized the difficulty of cybersecurity risk management<ref name="LipnerRisk16">{{cite web \|url=https://www.nist.gov/system/files/documents/2016/09/16/s.lipner-b.lampson_rfi_response.pdf \|format=PDF \|title=Risk Management and the Cybersecurity of the U.S. Government - Input to the Commission on Enhancing National Cybersecurity \|author=Lipner, S.B.; Lampson, B.W. \|date=September 2016 \|accessdate=23 July 2020}}</ref>:

			"It is impossible to measure precisely either the amount of security a given investment buys or the expected consequences of less than perfect security. Thus, decision makers must make security investments whose benefits are very uncertain. This makes it tempting to spend less on security and more on new programs or other alternatives with more visible benefits."

			Despite these difficulties, the process of translating gap analysis and risk analysis into actionable and realistic objectives must be done. But you're close to or already have made the inroads to reaching this point. You've inventoried and examined the hardware and network settings you already use (5.3.1). You've examined your existing (and possibly even future) data and declared its criticality (5.3.2) in the context of the regulations, standards, and best practices affecting your assets and data (5.3.4). And you've reviewed your existing policies, looking for areas of improvement (5.3.3). You know where you are and where you want to go. Now the risk management components arrive in the form of objectives (5.3.8) that align with your overall cybersecurity strategy (5.1.3), the policies required for creation and modification (5.3.9), and the security controls chosen to support those objectives and policies (5.3.10). If you realize this full approach, cybyersecurity risk management should come naturally, by extension.

	====5.3.9 Identify policies for creation or modification concerning passwords, physical security, etc., particularly where gaps have been identified from the prior assessments and objectives====		====5.3.9 Identify policies for creation or modification concerning passwords, physical security, etc., particularly where gaps have been identified from the prior assessments and objectives====

Shawndouglas: Added section

2020-07-23T18:19:56Z

Added section

← Older revision		Revision as of 18:19, 23 July 2020
Line 8:		Line 8:

	Finally, the various steps of this plan will recommend the development of a variety of other policies, procedures, and documents, e.g., a communications plan and a response and continuity plan. As NIST notes in its SP 800-53 framework, effective security plans make reference to other policy and procedure documents and don't necessarily fully contain those actual policies and procedures themselves. Rather, the plan should "provide explicitly or by reference, sufficient information to define what needs to be accomplished" by those policies and procedures. All of that is to say that when going through the steps below, be cognizant of that advice. Recommendations to make a communications plan or response plan don't necessarily mean those plans should be an actual portion of your overall cybersecurity plan, but rather a component external to the plan yet referenced and detailed sufficiently within the plan.		Finally, the various steps of this plan will recommend the development of a variety of other policies, procedures, and documents, e.g., a communications plan and a response and continuity plan. As NIST notes in its SP 800-53 framework, effective security plans make reference to other policy and procedure documents and don't necessarily fully contain those actual policies and procedures themselves. Rather, the plan should "provide explicitly or by reference, sufficient information to define what needs to be accomplished" by those policies and procedures. All of that is to say that when going through the steps below, be cognizant of that advice. Recommendations to make a communications plan or response plan don't necessarily mean those plans should be an actual portion of your overall cybersecurity plan, but rather a component external to the plan yet referenced and detailed sufficiently within the plan.

			'''''An Example Cybersecurity Plan'''''

			The following instructional template for developing a cybersecurity plan is admittedly a lot of information to take in at once. Some people are much better understanding a concept through examples. As such, what is modestly called ''An Example Cyberssecurity Plan'' has been developed to accompany this guide. That example plan includes an introduction to provide more context concerning its creation, as well as a simple outline of the following steps 5.1 through 5.10. The example plan itself comes afterwards, presented from the persepctive of fictional environmental laboratory company ABC123 Co. This example is slightly unorthodox in that it presents a cybersecurity plan in an iterative state of development, emphasizing the "living document" aspect of cybersecurity plan. The document demonstrates the concepts emphasized in this guide, including the concept of referencing other relevant policies and documents without duplicating them within the cybersecurity plan. Note that while a separate document, ''An Example Cybersecurity Plan'' is released under the same Creative Commons license as this guide, and those license requirements should still be followed.

	===5.1. Develop strategic cybersecurity goals and define success===		===5.1. Develop strategic cybersecurity goals and define success===

User:Shawndouglas/sandbox/sublevel28 - Revision history

Shawndouglas at 20:31, 16 August 2023

Shawndouglas: Replaced content with "__TOC__ {{ombox | type = notice | style = width: 960px; | text = This is sublevel27 of my sandbox, where I play with features and..."

Shawndouglas at 23:43, 15 August 2023

Shawndouglas at 22:50, 27 July 2023

Shawndouglas: Blanked the page

Shawndouglas: /* 5.3.8 Declare and describe objectives based on the outcomes of the above assessments */

Shawndouglas: /* 5.3.8 Declare and describe objectives based on the outcomes of the above assessments */

Shawndouglas: /* 5.3.8 Declare and describe objectives based on the outcomes of the above assessments */

Shawndouglas: /* 5.3 Identify cybersecurity requirements and objectives */

Shawndouglas: Added section

Shawndouglas: Replaced content with "
TOC
{{ombox | type = notice | style = width: 960px; | text = This is sublevel27 of my sandbox, where I play with features and..."