2

Mandatory Requirements

In the previous chapter, we spent some time learning what frameworks are and how we can use them to populate these frames (ISO 27001, NIST and so on)

In this chapter, if you were brave enough to follow me through all those acronyms and uncommon wording, you are probably eager to find out what’s next. We will spend the next pages learning how ISO 27001 works in the real world, then we will do the same for the NIST framework, and finally, we will see whether ISO 27001 and NIST can coexist.

In this chapter, we will cover the following topics:

• iSMS, controls, commitment, context, scope policy, and objectives
• Identify, Protect, Detect, Respond, and Recover
• Can ISO 27001 and NIST coexist?

iSMS, controls, commitment, context, scope policy, and objectives

Let’s try to understand what an iSMS is and how to deal with it.

iSMS

You might not have heard the word iSMS.

It isn’t very common outside of Governance, Risk management, Compliance (GRC) nerd slang, but if you want to be part of the club, you should refer to the information Security Management System, or, for short, the iSMS. If your company has implemented (or is on its way to implementing) a risk-based information security management policy, be sure that it was (or it will be) done by using an iSMS, to ensure things are standardized.

The main advantage is that such a system facilitates compliance with several regulations, including the General Data Protection Regulation (GDPR), and focuses on the three critical components we have already seen: confidentiality, integrity, and availability. For the sake of correctness, we should add non-repudiation (you cannot pretend you haven’t received an email, for instance) and reliability (the system, being healthy, has to be reliable too). At some point, NIST introduced the concept of authenticity, which is the property of being genuine and being able to be verified and trusted; but, although correct, it introduces a highly debated topic. I am referring to the old problem of digital copies, where the main question is: can a digital copy (for instance, a PDF file) be considered the original one or a real copy? When you and another person fill in a form either in a private or public environment, which one is seen as the original one? Is any of them to be seen as the original one? Is the master, the file originating all the copies, to be seen as authentic, even though the copies are 100% the same? This has been an ongoing debate within the IT security community for ages, and there is no final answer.

The proliferation of increasingly complex, sophisticated, and global threats to this information and its systems, combined with the compliance requirements of a flood of computer- and privacy-related regulations around the world, is compelling organizations to take a more integrated approach to information security. Individual information security concerns no longer require hardware-, software-, or vendor-driven solutions.

They are, in fact, catastrophically insufficient on their own.

News headlines about hackers, malware, and online fraud are only the tip of the iceberg when it comes to data security. Corporate losses caused by computer breakdown, large interruptions to their data and operating systems, or theft or loss of intellectual property or vital business data are more significant and costly.

The practical upshot of the previously mentioned strategy is an iSMS. Smaller businesses are unlikely to refer to it as such, but it is still an iSMS. At its core, this is nothing more than a collection of controls that minimize the risks that an organization has opted to accept but control to a level compatible with its control standard or risk acceptance criteria, as well as the framework within which those controls function. Every information management system for example, is an iSMS, but not one meant to be ISO27001 certified.

My suggestion is to post your iSMS documentation online, perhaps on the business intranet or a comparable common directory/shared location. This technique has various advantages:

• Anyone with access to a PC on the corporate LAN will be able to access the intranet and hence the iSMS documentation across the enterprise. Other departments can then not only read and refer to your resources but also hyperlink directly to them in their own rules, procedures, and so on. Basically, the idea is to integrate policies, procedures, and standards in a formal methodology, including those, if any, related to secure software development.
• The material may be nicely formatted and presented (for example, brief, easy-to-read summary/intro pages hyperlinked to more thorough supporting pages providing the nitty gritty; embedded images such as process flow charts, mind maps... yeah, and security awareness stuff).
• Controlling the iSMS website is simpler than controlling printed/hardcopy iSMS papers, as long as someone has authority over what is put in the intranet iSMS section (implying some sort of change management process to review and publish stuff). Everyone should understand that the iSMS resources available on the intranet are the most recent, active versions. (You may want to create a distinct “trial” or “draft” section to expose suggested policy modifications for input, but make that area immediately identifiable as such, for example, with a different colored page backdrop and an obvious declaration that these are drafts, not the actual, live versions of your policies.)

However, there are two drawbacks:

• You must have the ability and tools necessary to create, produce, publish, and manage the website, or have easy access to someone who does.
• Because online pages don’t normally print well, you may need to provide printable copies (e.g., PDFs) to download and print from the same websites that cover the format and kind of communication for items that people want to print and refer to, comment on, or whatever. You’ll have to work on developing your writing style. While certain aspects of the iSMS must be defined (e.g., rules), others may be made more user-friendly (e.g., guidelines). It’s totally OK to have some fun with security awareness items that are more creative, such as quizzes, crossword puzzles, seminars/workshops, and prize drawings. The goal is to pull people in and engage them by providing helpful, digestible material, rather than scaring them away with miles of impenetrable red tape.

Implementation tip

Having a uniform style/format for each sort of information, and even better, consistent components across all of them, helps to connect them into a cohesive, professional suite. Do you have an iSMS logo that you could use to “brand” your paperwork and other security awareness materials? Do you hire professional writers? Do they employ templates and styles on a regular basis?

Of course, you’re not obliged to use them, but these kinds of actions can be easily recognized as part of a whole, in terms of management’s commitment.

Statement of applicability, risk treatment plan, and action plan

Another list of acronyms? Yes, but these are really important.

A Statement of Applicability (SoA) is a document that states why you aren’t compliant with all 18 annexes of ISO 27001. It is basically your formal specification of the ISO/IEC 27002 controls that are applicable to your iSMS. There must be some logic to your thinking in order to convince the auditors that significant choices were not taken randomly. Prepare for heated debate with them if you opt not to apply common controls or accept major risks.

It’s very difficult to explain it without an example. Let’s suppose your entity is within the retail industry. In this case, requirement A.15 (concerning supplier relationships) must be your top priority, as shown in the following table:

Table 2.1 – Example of control in supplier relationship (source: ISO 27001)

In the preceding example, we need to identify the side of security protection to implement when dealing with suppliers, either internal (I mean, part of the same company) or third party.

Don’t worry about the jargon or the kind of generic information given; this is ISO, they would, of course, need to include as much information as possible. Remember, this is a framework and you are an individual deciding what you need into this framework, and you will decide on the subject and the author. But then don’t complain if you aren’t satisfied with your framework: it will be entirely your fault. The frame isn’t the content. Therefore, if the framework chosen is not working somehow, it is not the framework to be blamed, but who decided to use it. So, furnish your frame in the best possible way, which doesn’t mean using something more expensive or whatever: just in a more consistent way. It has to be reliable and ready to be used in many different ways, according to your needs and your environment. I’ll get back to the framework later; the table was just meant to give you an idea of what to expect.

The Action Plan (AP) and Risk Treatment Plan (RTP) seem to be synonymous at first look; however, the AP is often a development or reduction of the RTP. The RTP methodically defines the controls required to handle each of the hazards identified in your risk assessment, while the AP (or program or project plans) states what you want to accomplish – who will do it, when, and how. A single control, particularly a baseline control such as physically guarding the organization’s perimeter, may handle several risks and hence appear multiple times in the RTP but presumably just once in the AP when it is created, implemented, validated, and “operationalized” (a dreadful term!).

ISO/IEC 27000 should help clear up any residual ambiguity.

Don’t get too caught up on document abbreviations and titles. Concentrate on their core goal of documenting the relationships between information risks, control goals, and controls.

From an operational point of view, the first thing we need to understand is the importance of an inventory of assets. In a few words, it’s imperative to know and understand what is in our inventory to protect the assets from hostile activity, and they can be protected either manually or using software (needless to say in case of automatic software would avoid us forgetting things).

Controls

Controls are a combination of technological, procedural, and behavioral components that work together to achieve a specified, recognized, and recorded control goal. For example, your desktop user systems are under attack from a harmful combination of viruses, worms, Trojans, and spam, which will jeopardize the availability, confidentiality, and integrity of the data on your desktop. Email, online browsing, and instant messaging are the attack vectors. Among the controls would be the following:

• Anti-virus and anti-spyware software, anti-spam filters, firewalls, and automated updating are examples of technical advances
• Processes including software and firewall configuration, upgrading procedures, incident management procedures, and acceptable usage policies
• Behavioral – user awareness and training in dealing with these risks and techniques of reaction, such as identifying when malicious software attempts to download into a PC

This three-pronged approach is typical of all successful controls; implementing merely two of them exposes a substantial vulnerability that can reverse all that has been put in place. The false sense of security that most businesses gain from having only a partial solution in place may be very damaging.

Of course, this is something we will deep dive into later.

Commitment and project management

To have a decent implementation, there are several requirements, usually, but not only, recorded on paper. One of those not on paper, and arguably the most important of them, is the management commitment. The entity has to believe in what they are willing to do, and C-levels have to show all their support and commitment, agree on finding a team (or a representative to follow the works of the external company), and also show some support on internal and external social media (from the intranet up to social platforms). Also, external commitment can be seen, from a company perspective, as a way to advertise their services throughout the web, aside from, of course, justifying the important investment the company made.

Tip

Management commitment is something really important and has to be seen as a formal act, as well as the request for support from the implementation team, in order not to waste money and engagement.

It’s important to note how project management is important in these cases. If we want to approach the company’s security posture, we need to get through 18 annexes and, therefore, a great planning capacity is needed; moreover, if we want to get a holistic including NIST and other frameworks such as CIS Controls (https://cisecurity.org), the battleplan becomes really interesting. Scope policy and objectives

Although one or more standards can lead to a certification, in our case, as already explained, it helps us to establish objectives and priorities, and in this context, we need to verify what is needed by our company. As you can imagine, some controls count more than others depending on the kind of industry we want to improve the security posture of, and, incidentally, some standards are to be meant for specific industries (for instance, ISO 27011 is specific for telecoms); but this is something that goes beyond the scope of the book and, therefore, has to be taken as a fact only.

Identify, Protect, Detect, Respond, and Recover

In the previous chapter, we had an important (and hopefully good) introduction to the NIST Framework. Let’s talk more about the most important points.

Remember from the previous chapter the most important points related to NIST?

Identify

NIST describes the Identify function as “developing the corporate knowledge to manage cybersecurity risk to systems, assets, data, and capabilities.” As a cybersecurity stakeholder, you may utilize this function to work on creating the groundwork in your business for future successful usage of the framework. The emphasis of Identify is on the company and how it relates to cybersecurity risk, particularly when resources are limited. Some of the result categories linked with this function are as follows:

• Asset Management
• Business Environment
• Governance
• Risk Management
• Strategy for Risk Management

The significance of the Identify function is obvious: it establishes the framework for future cybersecurity-related activities that your firm will take. Identifying what exists, what risks are connected with those settings, and how it connects to your company objectives is critical to the framework’s success.

The successful execution of the Identify function might result in a variety of results, such as the following:

• All assets and environments must be defined
• Identifying the existing and desired states of controls
• Making a strategy to close such gaps
• Prioritizing mitigation approaches in a commercial environment
• Putting all stakeholders’ and business leaders’ needs first, determining how to convey cybersecurity concerns to all parties

Organizations must adapt their cybersecurity processes and put in place the necessary protections to control and mitigate the effects of future cybersecurity events. All digital and physical assets must be tracked, and responsibilities must be specified along with clear communication processes for incidents and risks. The rules and procedures you put in place will offer the stability your cybersecurity program needs as it progresses through all five functions and develops.

Protect

According to NIST, the framework’s purpose is to “assist an organization in expressing its cybersecurity risk management by organizing information, allowing risk management choices, managing risks, and improving by learning from prior operations.”

The Protect function is vital because its goal is to create and execute necessary safeguards to assure the delivery of critical infrastructure services. The Protect function assists in limiting or containing the effect of a possible cybersecurity incident. Identity Management and Access Control; Awareness and Training; Data Security; Information Protection Processes and Procedures; Maintenance; and Protective Technology are examples of result categories under this function, according to NIST.

Protect covers the following categories:

• Access control entails confirming identities and granting access to various systems, facilities, and so on
• Education and training provide workers and others with the capacity to participate in your cybersecurity strategy
• Data security includes managing your data in accordance with corporate standards to reduce cybersecurity risks and secure its availability, integrity, and confidentiality
• Processes and procedures for information protection are for establishing the policies, processes, and procedures required to oversee the protection of your assets
• Maintenance helps to repair and mitigate your information system components on a regular basis
• Protective technology helps to implement the security solutions required to keep companies safe in accordance with business regulations

Organizations must adjust as data breaches become increasingly widespread. By concentrating on the Protect function, you can establish the rules and procedures that will serve as a solid basis for your cybersecurity program as it evolves across all five functions.

Detect

The Detect function necessitates the development and implementation of relevant operations to detect the presence of a cybersecurity incident.

The detect feature allows for the prompt detection of cybersecurity occurrences. Anomalies and Events, Security Continuous Monitoring, and Detection Processes are examples of result Categories under this Function.

Clearly, the Detect function is one of the most critical, since identifying a breach or occurrence might be the difference between life and death for your company. There is no question that using these solutions and adhering to these best practices will assist you in scaling your program and mitigating cybersecurity risk.

Respond

NIST defines Respond as developing and implementing suitable actions to take action in response to an identified cybersecurity event.

The Respond Function helps to limit the effect of a possible cybersecurity event. Response Planning, Communications, Analysis, Mitigation, and Improvements are some examples of result Categories within this Function.

The following are the components of the Respond function and their significance:

• Response planning: To guarantee a prompt response to suspected cybersecurity incidents, response processes and procedures are implemented and maintained.

Analysis is carried out to guarantee a sufficient reaction and assist with recovery actions.

• Mitigation: Activities that are carried out to prevent the spread of an occurrence, minimize its impacts, and eliminate the incident.
• Communications: As needed, response operations are coordinated with internal and external parties, including law enforcement authorities.

Improvements are made to organizational response activities by applying lessons gained from current and prior detection and response operations.

When breaches occur in businesses, an incident response strategy is essential for dealing with the immediate aftermath. Surprisingly, many firms do not have an incident response plan or have not tested the plan that they do have.

Recover

NIST defines the Recover function as the necessity to create and perform the relevant operations to maintain resilience strategies and to restore any capabilities or services that were affected due to a cybersecurity incident.

The Recover function enables the quick return to regular activities in order to mitigate the consequences of a cybersecurity occurrence. Recovery planning, improvements, and communications are some examples of outcomes of this function.

Recovery planning includes testing, executing, and maintaining recovery processes so that your program can lessen the impacts of an incident as quickly as possible.

When events occur, opportunities for improvement are discovered, solutions are developed, and recovery planning and procedures are enhanced. In this case, it’s important to coordinate both internally and externally to improve the structure, detailed preparation steps, and execution.

The Recover function is critical not only for your company or organization in recovering from an assault but also for your consumers or market. A quick recovery managed with elegance and tact will put you in a much better position internally and publicly than you would have otherwise.

Can ISO 27001 and NIST coexist?

Yes, of course. There are many points in common between those frameworks.

As an example of common things between frameworks, here’s a mapping between ISO 27001 and NIST SP 800:

ISO/IEC 27001 (Annex A) CONTROLS	NIST SP 800-53 controls
A.5 Security policy
A.5.1 Information security policy
A.5.1.1 Information security policy document	XX-1 controls
A.5.1.2 Review of the information security policy	XX-1 controls
A.6 Organization of information security
A.6.1 Internal
A.6.1.1 Management commitment to information security	XX-1 controls, PM-2; SP 800-39, SP 800-37
A.6.1.2 Information security coordination	CP-2, CP-4, IR-4, PL-1, PL-6, PM-2, SA-2; SP 800-39, SP 800-37
A.6.1.3 Allocation of information security responsibilities	XX-1 controls, AC-5, AC-6, CM-9. PM-2; SP 800-39, SP 800-37
A.6.1.4 Authorization process for information processing facilities	CA-1, CA-6, PM-10; SP 800-37
A.6.1.5 Confidentiality agreements	PL-4, PS-6, SA-9
A.6.1.6 Contact with authorities	Multiple controls with contact reference (e.g., IR-6, SI-5); SP 800-39; SP 800-37
A.6.1.7 Contact with special interest groups	AT-5
A.6.1.8 Independent review of information security	CA-2, CA-7; SP 800-39, SP 800-37
A.6.2 External parties
A.6.2.1 Identification of risks related to external parties	CA-3, PM-9, RA-3, SA-1, SA-9, SC-7
A.6.2.2 Addressing security when dealing with customers	AC-8, AT-2, PL-4
A.6.2.3 Addressing security in third-party agreements	CA-3, PS-7, SA-9
A.7 Asset management
A.7.1 Responsibility for assets
A.7.1.1 Inventory of assets	CM-8, CM-9, PM-5
A.7.1.2 Ownership of assets	CM-8, CM-9, PM-5
A.7.1.3 Acceptable use of assets	AC-20, PL-4
A.7.2 Information classification
A.7.2.1 Classification guidelines	RA-2
A.7.2.2 Information labeling and handling	AC-16, MP-2, MP-3, SC-16
A.8 Human resources security
A.8.1 Prior to employment
A.8.1.1 Roles and responsibilities	XX-1 controls, AC-5, AC-6, AC-8, AC-20, AT-2,AT-3, CM-9, PL-4, PS-2, PS-6, PS-7, SA-9
A.8.1.2 Screening	PS-3
A.8.1.3 Terms and conditions of employment	AC-20, PL-4, PS-6, PS-7
A.8.2 During employment
A.8.2.1 Management responsibilities	PL-4, PS-6, PS-7, SA-9
A.8.2.2 Awareness, education, and training	AT-2, AT-3, IR-2
A.8.2.3 Disciplinary process	PS-8
A.8.3 Termination or change of employment
A.8.3.1 Termination responsibilities	PS-4, PS-5
A.8.3.2 Return of assets	PS-4, PS-5
A.8.3.3 Removal of access rights	AC-2, PS-4, PS-5
A.9 Physical and environmental security
A.9.1 Secure areas
A.9.1.1 Physical security perimeter	PE-3
A.9.1.2 Physical entry controls	PE-3, PE-5, PE-6, PE-7
A.9.1.3 Securing offices, rooms, and facilities	PE-3, PE-4, PE-5
A.9.1.4 Protecting against external and environmental threats	CP Family; PE-1, PE-9, PE-10, PE-11, PE-13, PE-15
A.9.1.5 Working in secure areas	AT-2, AT-3 , PL-4, PS-6, PE-2, PE-3, PE-4, PE-6, PE-7, PE-8
A.9.1.6 Public access, delivery and loading areas	PE-3 , PE-7, PE-16
A.9.2 Equipment security
A.9.2.1 Equipment siting and protection	PE-1, PE-18
A.9.2.2 Supporting utilities	PE-1, PE-9, PE-11, PE-12, PE-14
A.9.2.3 Cabling security	PE-4, PE-9
A.9.2.4 Equipment maintenance	MA Family
ISO/IEC 27001 (Annex A) CONTROLS	NIST SP 800-53 CONTROLS
A.9.2.5 Security of equipment off-premises	MP-5, PE-17
A.9.2.6 Secure disposal or reuse of equipment	MP-6
A.9.2.7 Removal of property	MP-5, PE-16
A.10 Communications and operations management
A.10.1 Operational procedures and responsibilities
A.10.1.1 Documented operating procedures	XX-1 controls, CM-9
A.10.1.2 Change management	CM-1, CM-3, CM-4, CM-5, CM-9
A.10.1.3 Segregation of duties	AC-5
A.10.1.4 Separation of development, test, and operational facilities	CM-2
A.10.2 Third-party service delivery management
A.10.2.1 Service delivery	SA-9
A.10.2.2 Monitoring and review of third-party services	SA-9
A.10.2.3 Managing changes to third-party services	RA-3, SA-9
A.10.3 System planning and acceptance
A.10.3.1 Capacity management	AU-4, AU-5, CP-2, SA-2, SC-5
A.10.3.2 System acceptance	CA-2, CA-6, CM-3, CM-4, CM-9, SA-11
A.10.4 Protection against malicious and mobile code
A.10.4.1 Controls against malicious code	AC-19, AT-2, SA-8, SC-2, SC-3, SC-7, SC-14, SI-3, SI-7
A.10.4.2 Controls against mobile code	SA-8, SC-2, SC-3, SC-7, SC-14, SC-8, SC-18
A.10.5 Backup
A.10.5.1 Information backup	CP-9
A.10.6 Network security management
A.10.6.1 Network controls	AC-4, AC-17, AC-18, AC-20, CA-3, CP-8, PE-5,SC-7, SC-8, SC-9, SC-10, SC-19, SC-20, SC-21, SC-22, SC-23
A.10.6.2 Security of network services	SA-9, SC-8, SC-9
A.10.7 Media handling
A.10.7.1 Management of removable media	MP Family, PE-16
A.10.7.2 Disposal of media	MP-6
A.10.7.3 Information handling procedures	MP Family, SI-12
A.10.7.4 Security of system documentation	MP-4, SA-5
A.10.8 Exchange of information
A.10.8.1 Information exchange policies and procedures	AC-1, AC-3, AC-4, AC-17, AC-18, AC-20, CA-3, PL-4, PS-6, SC-7, SC-16, SI-9
A.10.8.2 Exchange agreements	CA-3, SA-9
A.10.8.3 Physical media in transit	MP-5
A.10.8.4 Electronic messaging	Multiple controls; electronic messaging not addressed separately in SP 800-53
A.10.8.5 Business information systems	CA-1, CA-3
A.10.9 Electronic commerce services
A.10.9.1 Electronic commerce	AU-10, IA-8, SC-7, SC-8, SC-9, SC-3, SC-14
A.10.9.2 Online transactions	SC-3, SC-7, SC-8, SC-9, SC-14
A.10.9.3 Publicly available information	SC-14
A.10.10 Monitoring
A.10.10.1 Audit logging	AU-1, AU-2, AU-3, AU-4, AU-5, AU-8, AU-11, AU-12
A.10.10.2 Monitoring system use	AU-1, AU-6, AU-7, PE-6, PE-8, SC-7, SI-4
A.10.10.3 Protection of log information	AU-9
A.10.10.4 Administrator and operator logs	AU-2, AU-12
A.10.10.5 Fault logging	AU-2, AU-6, AU-12, SI-2
A.10.10.6 Clock synchronization	AU-8
A.11 Access control
A.11.1 Business requirement for access control
A.11.1.1 Access control policy	AC-1, AC-5, AC-6, AC-17, AC-18, AC-19, CM-5, MP-1, SI-9
A.11.2 User access management
A.11.2.1 User registration	AC-1, AC-2, AC-21, IA-5, PE-1, PE-2
A.11.2.2 Privilege management	AC-1, AC-2, AC-6, AC-21, PE-1, PE-2, SI-9
A.11.2.3 User password management	IA-5

It’s important to note that, as stated on their website, this document from NIST is available for free at https://doi.org/10.6028/NIST.SP.800-53r5.

However, while NIST is free, ISO 27001 is not. I strongly suggest you buy a copy of ISO 27001 standard once you finish reading the book, to better understand both the controls and the jargon.

As you may see, general rules between ISO and NIST are somewhat interchangeable and that’s why it is not only possible but also desirable, at least in some cases, to use the NIST ones. When it comes to asset disposal, for instance (see the highlighted ISO 27001 annex), ISO refers to media only (i.e., USB and hard disk drives), while NIST throws out an impressive number of network devices with a very detailed plan on how to safely dispose of them (considering that they can retain network configurations and a malicious actor can easily copy and use them against our company). The real benefit of using ISO instead of NIST, as mentioned elsewhere in the book, is that you can prove that you are following a standard and this would be highly beneficial for your entity.

Summary

Do you remember The Hitchhiker’s Guide to the Galaxy, one of the funniest sci-fi books of all time? Well, we can imagine ISO 27001 as the famous towel from The Hitchhiker’s Guide to the Galaxy: we can use both the towel and ISO 27001 in several ways, alongside other frameworks, both reassure us, and from time to time we need to clean them to avoid issues.

So, the chapter is over. We covered how to formally (although this is not strictly necessary if your company doesn’t require a certification) write an iSMS with all the bells and whistles, and then moved on to look at how ISO 27001 works in the real world. Then, we did the same for the NIST framework and saw whether ISO 27001 and NIST can coexist.

In the next chapter, we will be covering data protection, with a big focus on GDPR and some mapping with other privacy laws around the globe.