Book:Comprehensive Guide to Developing and Implementing a Cybersecurity Plan/Develop and create the cybersecurity plan/Identify cybersecurity requirements and objectives

From LIMSWiki
Jump to navigationJump to search

5.3 Identify cybersecurity requirements and objectives

Cybersecurity Strategy 5 Layer CS5L.png

5.3.1 Detail the existing system and classify its critical and non-critical cyber assets

AHIMA recommends you "create an information asset inventory as a base for risk analysis that defines where all data and information are stored across the entire organization."[1] Consider any applications and systems used within the periphery of your operations, including business intelligence software, mobile devices, and legacy systems. Remember that any networked application or system could potentially be compromised and turned into a vector of attack. Additionally, classify and gauge those assets' based on type, risk, and criticality. What are their essential functions? How can they be grouped? How do they communicate: internally, externally, or not at all?[2] As AHIMA notes, you'll be able to use this asset inventory, in combination with a variety of additional assessments described below, as a base for your risk assessment.

5.3.2 Define the contained data and classify its criticality

During the asset inventory, you'll also want to address classifying the type of data contained or transported by the cyber asset, which aids in decision-making regarding the controls you'll need to adequately protect the assets.[2] Use a consistent set of nomenclature to define the data. For example, if you look at universities such as the University of Illinois and Carnagie Mellon University, they provide guidance on how to classify institutional data based on characteristics such as criticality, sensitivity, and risk. The University of Illinois has a defined set of standardized terms such as "high-risk," "sensitive," "internal," and "public,"[3] whereas Carnagie Mellon uses "restricted," "private," and "public."[4] You don't necessarily need to use anyone's classification system verbatim; however, do use a consistent set of terminology to define and classify data.[2] Consider also adding additional details about whether the data is in-motion, in-use, or at-rest.[5]

If you have difficulties classifying the data, pose a series of data protection questions concerning the data's characteristics. One such baseline for questions could be the European Union's definition of what constitutes personal data. For example[2][6]:

  • Does the data identify an individual directly?
  • Does the data relate specifically to an identifiable person?
  • Could the data—when processed, lost, or misused—have an impact on an individual?

5.3.3 Identify current and previous cybersecurity policy and tools, as well as their effectiveness

Unless your business is in the formative stages, some type of technology infrastructure and policy likely exists. What, if any, cybersecurity policies and tools have you implemented in the past? Review any current access control protocols (e.g., role-based and "least privilege" policies) and security policies. Have they been updated to take into consideration recent changes in threats, risks, criticality, technology, or regulation?[1][7][8] In the same way, identify any past security policies and why they were discontinued. It may be convenient to track all these security protocols and policies in a master sheet, rather than spread out across multiple documents. Also, now might be a good time to identify how security-aware personnel are overall.[7] Of course, if protocols and policies aren't in place, create them, remembering to include proper communication, scheduled policy reviews, and training into the equation.

5.3.4 Identify the regulations, standards, and best practices affecting your assets and data

Arguably, most business types will be impacted by regulations, standards, or best practices. Even niche professions like cinema editors are guided by best practices set forth by professional organizations.[9] In the case of laboratories, multiple regulations and standards apply to operations, including information management and privacy practices. Presumably one or more executives in your business are familiar with the legal and professional aspects of how the business should be run. If not, significant research and outside consultant help may be required. Regardless, when approaching this task, ensure everyone understands the distinctions among "regulation," "standard," and "best practice."

Remember that while regulators may dictate how you manage your cybersecurity assets, setting policy that goes above and beyond regulation is occasionally detrimental to your business. Data retention requirements, for example, are important to consider, not only for regulatory purposes but also data management and security reasons. To be sure, numerous U.S. Code of Federal Regulations (e.g., 21 CFR Part 11, 40 CFR Part 141, and 45 CFR Part 164), European Union regulations (e.g., E.U. Annex 11 and E.U. Commission Directive 2003/94/EC), and even global entities (e.g., WHO Technical Report Series, #986, Annex 2) address the need for record retention. However, as AHIMA points out, records shouldn't be kept forever[1]:

Healthcare organizations have been storing and maintaining records and information well beyond record retention requirements. This creates significant additional security risks as systems and records must be maintained, patched, backed up, and provisioned (access) for longer than necessary or required by law ... In the era of big data the idea of keeping “everything forever” must end. It simply is not feasible, practical, or economical to secure legacy and older systems forever.

This example illustrates the idea that while regulatory compliance is imperative, going well beyond compliance limits has its own costs, not only financially but also by increasing cybersecurity risk.

5.3.5 Identify and analyze logical and physical system entry points and configurations

This step is actually closely tied to the next step concerning gap analysis. As such, you may wish to address both steps together. You've already identified your critical and non-critical assets, and performing a gap analysis on them may be a useful start in finding and analyzing the logical entry points of a system. But what are some of the most common entry points that attackers may use?[10][11][12][13]

  • Inbound network-based attacks through software, network gateways, and online repositories
  • Inbound network-based attacks through misconfigured firewalls and gateways
  • Access to systems using stolen credentials (networked and physical)
  • Access to peripheral systems via communication protocols, insecure credentials, etc. through lateral movement in the network

From email and enterprise resource planning (ERP) applications and servers to networking devices and tools, a wide variety of vectors for attack exist in the system, some more common than others. Analyzing these components and configurations takes significant expertise. If internal expertise is unavailable for this, it may require a third-party security assessment to gain a clearer picture of the entry points into your system. Even employees and their lack of cybersecurity knowledge may represent points of entry, via phishing schemes.[1][13] This is where training and internal random testing (addressed later) come into play.[1]

Physical access to system components and data also represent a significant attack vector, more so in particular industries and network set-ups. For example, industrial control systems in manufacturing plants may require extra consideration, with some control system vendors now offering an added layer of physical security in the form of physical locks that prevent code from being executed on the controller.[11] Cloud-based data centers and field-based monitoring systems represent other specialist situations requiring added physical controls.[2][1][8] That's not to say that even small businesses shouldn't worry about physical security; their workstations, laptops, USB drives, mobile devices, etc. can be compromised if made easy for the general public to access offices and other work spaces.[8] In regulated environments, physical access controls and facility monitoring may even be mandated.

5.3.6 Perform a gap analysis

A gap analysis is different from a risk analysis in that the gap analysis represents a high-level, narrowly-focused comparison of the technical, physical, and administrative safeguards in place with how well they actually perform against a cyber attack. As such, the gap analysis can be thought of as introduction to potential vulnerabilities in a system, which is part of an overall risk analysis.[14] The gap analysis asks what your cyber capabilities are, what the major threats are, and what the differences are between the two. Additionally, you may want to consider what the potential impacts would be if a threat were realized.[15]

The gap analysis can also be looked at as measure of current safeguards in place vs. what industry best practice controls dictate. This may be done by choosing an industry-standard security framework—we're using the NIST SP 800-53, Rev. 5 framework for this guide—and evaluating key stakeholder policies, responsibilities, and processes against that framework.[16]

5.3.7 Perform a risk analysis and prioritize risk based on threat, vulnerability, likelihood, and impact

With cybersecurity goals, asset inventory, and gap analysis in hand, its time to go comprehensive with risk assessment and prioritization. Regardless of whether or not you're hosting and transmitting PHI or other types of sensitive information, you'll want to look at all your cybersecurity goals, systems, and applications as part of the risk analysis.[1] Functions of risk analysis include, but are not limited to[2][14][17]:

  • considering the operations supporting business goals and how those operations use technology to achieve them;
  • considering the various ways the system functionality and entry points could be abused and compromised (threat modeling);
  • comparing the current system's or component's architecture and features to various threat models; and
  • compiling the risks identified during threat modeling and architecture analysis and prioritizing them based on threat, vulnerability, likelihood, and impact.

Additionally, as part of this process, you'll also want to examine the human element of risk in your business. How thorough are your background checks of new employees and third parties accessing your systems? How easy is it for them to access the software and the hardware? Is the principle of "least privilege" being used appropriately? Have any employee loyalties shifted drastically lately? Are the vendors supplying your IT and data services thoroughly vetted? These and other questions can supplement the human-based aspect of cybersecurity risk assessment.

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

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."[15] In a world where cyber threats are constantly evolving, being "100 percent secure against cyber threats" is an unrealistic goal, for example.[15]

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[18]:

"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 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

Say you previously noted your business has a few password and other access management policies in place, but they are relatively weak compared to where you want to be. If you haven't already, now is a good time to start tracking those and other policies that need to be updated or even created from scratch. Note that you may also discover additional policies that should be addressed during the next step of selecting and refining security controls. Consider performing this step in tandem with the next to gain the clearest idea of all the policy updates the business will require to meet its cybersecurity objectives.

5.3.10 Select and refine security controls for identification, protection, detection, response, and recovery based on the assessments, objectives, and policies above

According to cybersecurity solutions company Tenable, 84 percent of U.S. organization turn to to at least one cybersecurity framework in their organization, and 44 percent work with more than one.[19] This is done in part to comply with a mix of regulations affecting organizations today, as well as provide a baseline of security policies and protocols, even for the smallest of organizations. In that regard, it makes sense to heavily involve cybersecurity frameworks and controls in the development of your cybersecurity plan.

For the purposes of this guide, the NIST control descriptions found in NIST Special Publication 800-53, Revision 5: Security and Privacy Controls for Information Systems and Organizations are used. Most of the "Low" baseline controls, as well as select "Moderate" and "High" baseline controls, are highly worthy of consideration for organizations. Additionally, a simplified version of controls was derived from 800-53 in the form of NIST Special Publication 800-171, Revision 2: Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. One of the benefits of this set of NIST controls is that it maps to both NIST SP 800-53 and the ISO/IEC 27001:2013 controls. And many of the cybersecurity groups and frameworks listed above have at their base—or are mapped to—those same two groups of controls.

You'll probably want to refer to Appendix 1 of this guide. There you'll find the "Low" baseline controls of NIST SP 800-53, as well as select "Moderate" and "High" baseline controls. For basic organizations working with non-federal data, these controls should prefer a perfectly useful baseline. The control descriptions have been simplified somewhat for quick reading, and any references or additional recommend reading is also added. Finally, you'll also see mapping to what's known as "LIMSpec," an evolving set of software requirements specifications for laboratory informatics systems. If you're not in the laboratory industry, you may not find that mapping entirely useful; however, LIMSpec still includes many specifications that could apply to a broad array of software systems.

Regardless of which frameworks and control groups you choose, you'll want to choose at least one and browse through the controls. Select the controls that map readily to the assessments, objectives, and policies you've already developed. You should even notice that some of the controls match to elements of the cybersecurity plan development steps found in this guide. The NIST control "IR-1 Incident response policy and procedures," for example, ties into step 5.8 of this guide, discussed later.


  1. 1.0 1.1 1.2 1.3 1.4 1.5 1.6 Downing, K. (December 2017). "AHIMA Guidelines: The Cybersecurity Plan" (PDF). American Health Information Management Association. Archived from the original on 19 January 2022. Retrieved 21 March 2023. 
  2. 2.0 2.1 2.2 2.3 2.4 2.5 Lebanidze, E. (2011). "Guide to Developing a Cyber Security and Risk Mitigation Plan" (PDF). National Rural Electric Cooperative Association, Cooperative Research Network. Retrieved 21 March 2023. 
  3. "Data Classification Overview". Cybersecurity. University of Illinois System. 2019. Retrieved 21 March 2023. 
  4. "Guidelines for Data Classification". Information Security Office Guidelines. Carnegie Mellon University. 16 November 2022. Retrieved 21 March 2023. 
  5. Bowie, K. (9 April 2019). "SEC Cybersecurity Guidance: Data Loss Prevention". Adelia Associates, LLC. Archived from the original on 30 November 2019. Retrieved 21 March 2023. 
  6. Koch, R. (1 February 2019). "What is considered personal data under the EU GDPR?". Proton Technologies AG. Retrieved 21 March 2023. 
  7. 7.0 7.1 Lago, C. (10 July 2019). "How to implement a successful cybersecurity plan". CIO. IDG Communications, Inc. Retrieved 21 March 2023. 
  8. 8.0 8.1 8.2 "How to Develop A Cybersecurity Plan For Your Company (checklist included)". Copeland Technology Solutions. 17 July 2018. Retrieved 21 March 2023. 
  9. "ACE Best Practices Guide for Post Production". American Cinema Editors. 2017. Retrieved 21 March 2023. 
  10. Kumar, A.J. (6 September 2016). "Discovering Entry Points". InfoSec Institute. Retrieved 21 March 2023. 
  11. 11.0 11.1 Ahmed, O.; Rehman, A.; Habib, A. (12 May 2019). "Industrial control system (ICS) cybersecurity advice, best practices". Control Engineering. CFE Media LLC. Retrieved 21 March 2023. 
  12. Bonderud, D. (11 June 2019). "Podcast: Lateral Movement: Combating High-Risk, Low-Noise Threats". SecurityIntelligence. IBM. Retrieved 21 March 2023. 
  13. 13.0 13.1 "Incident Classification Patterns and Subsets". 2019 Data Breach Investigations Report. Verizon. 2019. Retrieved 21 March 2023. 
  14. 14.0 14.1 Norton, K. (21 June 2018). "Similar but Different: Gap Assessment vs Risk Analysis". IntrapriseHEALTH. Retrieved 21 March 2023. 
  15. 15.0 15.1 15.2 Cadmus Group, LLC (30 October 2018). "Cybersecurity Strategy Development Guide" (PDF). National Association of Regulatory Utility Commissioners. Retrieved 21 March 2023. 
  16. Sell, C. (28 January 2015). "How To Conduct An Information Security Gap Analysis". CIO. IDG Communications, Inc. Retrieved 21 March 2023. 
  17. Talamantes, J. (6 September 2017). "Does Your Cybersecurity Plan Need an Update?". RedTeam Knowledge Base. RedTeam Security Corporation. Retrieved 21 March 2023. 
  18. Lipner, S.B.; Lampson, B.W. (September 2016). "Risk Management and the Cybersecurity of the U.S. Government - Input to the Commission on Enhancing National Cybersecurity" (PDF). Retrieved 21 March 2023. 
  19. Watson, M. (17 January 2019). "Top 4 cybersecurity frameworks". IT Governance USA Blog. GRC International Group plc. Retrieved 21 March 2023.