Appendix
Due to framework and law changes, this appendix to the book is mandatory. I have also taken the opportunity to briefly introduce you to some quite relevant topics that I hadn’t touched upon in previous chapters, such as Vulnerability Assessment and Penetration Testing (VA/PT). I decided to divide this appendix into different topics.
ISO 27002
The current version of ISO 27002 was issued in 2013 and is now hopelessly out of date. A great deal has changed in the last 8 years! Let’s hope we won’t have to wait another 8 years for the next edition.
As with the previous edition, ISO 27002 is meant to be independent in the sense that it may be utilized by organizations who are uninterested in ISO 27001 and just want a set of information security rules to implement inside their organization. In this regard, it is identical to other control frameworks, such as the CSA’s NIST CSF. Choose your poison!
The new version will go out possibly in the upcoming months where the only significant change is that Annex A will match the new ISO 27002. This introduces 11 new controls, which are as follows:
- Threat intelligence
- Information security for use of cloud services
- ICT readiness for business continuity
- Physical security monitoring
- Configuration management
- Information deletion
- Data masking
- Data leakage prevention
- Monitoring activities
- Web filtering
- Secure coding
Note that the controls I’ve described previously are not the real ones. These are the controls’ names. The control descriptions are included in ISO 27002 and will be included in the new Annex A when ISO 27001 is updated. ISO 27002 also provides implementation guidelines for these measures. For better understanding here, I need to clarify that all of the standards in the ISO 27000 series have a specific focus: while ISO 27001 is designed to build the foundations of information security in your organization and devise its framework; ISO 27002 is designed to implement controls named in Annex A of ISO 27001.
I have already read a great deal on the internet about these new regulations, and one of the most common assertions is that organizations will be required to adopt them. This is not true in my opinion for several reasons:
- ISO 27001 does not require the adoption of any controls. It is up to the organization to choose, based on a risk assessment, whether or not to apply these measures. In other words, these controls may not be required to handle one or more of the information security risks.
- Despite being labeled new, a number of these are already covered by current Annex A restrictions.
- In addition, it is quite probable that organizations are currently implementing at least some of these rules.
- It is absolutely useful to examine this list of new controls and ask, should any of these new controls be required controls to assist in the management of one or more of my information security risks? In this case, you must update your risk assessment and execute the control. When migrating to the new version of ISO 27001, you will have to conduct this inspection.
However, do not trust anybody who says you must implement these new controls.
What is different?
Each control is labeled in a variety of ways, such as whether it is preventative or remedial and whether it pertains to confidentiality, availability, or integrity. It remains to be seen whether this will be beneficial.
It features fewer controls (93 as opposed to 114), with some controls combined and others divided. In addition, it features a variety of additional contemporary measures, such as cloud security, threat intelligence, and web filtering; however, the fundamental concept remains the same. It is a collection of potential information security controls with implementation instructions for each control.
Is it superior to the previous version?
It depends; it attempts to cover certain current controls, such as those pertaining to the cloud. For the provided controls, some assistance is lacking, but the majority are superb.
Is it a standard set of controls for information security?
No, and this is due to the two primary causes listed as follows.
Reason 1: unbalanced coverage of the controls
There are 14 physical security controls, but only one cloud security control and 2 network security controls. There are further instances. This is just imbalanced.
Reason 2: controls are missing
Some of the most prevalent information security measures are buried in the extensive guidelines for other controls or are simply not addressed. There are no distinct controls for Firewall, IDS, Email security, MFA, VPN, WAF, Cyber Insurance, Wireless access, or Third-party library/software management, for instance. Some of them are not mentioned in the text.
Given the necessity of data validation in online applications, there are only a few controls and guidelines for validating data input.
There is just one control at a very high level for cloud computing, although I believe there should be numerous – for example, covering contracts, security obligations, tenant management, and service management. Yes, you may refer to ISO 27017; however, ISO 27002 should include at least the most typical cloud security rules on its own.
There are currently no adequate controls for business continuity management. There are some information security measures for business continuity planning, which are not the same thing. The lack of controls labeled Business Continuity Plan or Exercise Business Continuity Plans continues to perplex me. Yes, you may reference ISO 22301 for business continuity and disaster recovery management, but it makes no sense to me not to have these controls. Given the ubiquity of ransomware, there cannot be many organizations in the world that do not have at least one Business Continuity Plan, and this control is crucial from an information security standpoint.
Given that ISO 27002 is supposed to be utilized independently and fully apart from ISO 27001, it has relatively few governance rules, such as those pertaining to risk assessment, information security committee, and competences.
To be fair, ISO 27002 does state that organizations may need additional controls to enhance the ISO 27002 controls. Sadly, many organizations will not use ISO 27002 in this manner and will instead perceive it as a relatively complete collection of regularly used controls, which it is not!
Moreover, everyone will have their own opinions on what should be included in a list of frequently used information security rules.
What must you do at this time?
If you are just beginning to implement ISO 27001, it may be beneficial to get a copy and use it as a guide for implementing your controls. However, use with caution, even if throughout 2023 there will probably be no need to re-certify your company for the new release, but simply renew it, as usual, according to the certification-cycle of your company (usually 2 years). However, I am about to suggest you some strategies.
If you have previously implemented ISO 27001, you do not need to take any more action; nonetheless, you may find this updated version of ISO 27002 interesting since it contains valuable implementation strategies for various controls – that is, as a kind of quality control for your work.
What must you do when the new Annex A is released with the new ISO 27001 version?
Your certifying body or registrar will inform you of the transition arrangements to the new version, although you will likely have 2 years to completely transfer to the new version.
Depending on your circumstances and your desired strategy, there are two primary transition strategies.
Transition method 1 – do not modify the risk assessment
Why would you use this strategy?
This strategy is appropriate if you want to move to the latest version of ISO 27001 with little effort. In particular, you do not want to alter your risk assessment.
What is this strategy?
This strategy is predicated on continuing to use the previous ISO 27001:2013 Annex A rules. This is permissible since ISO 27001 enables controls to originate from any source, and you may pick the old Annex A controls as your source. Do not allow anybody to convince you that this is impossible. It can happen! The most important aspect of this technique is that it allows you to shift to the new edition of ISO 27001 without modifying your risk assessment.
To implement this strategy, you will need to do the following:
- Compare your controls with the new Annex A and record that you have done so – for example, in an email or as meeting minutes
- Make a few changes to the Statement of Applicability’s format
- These modifications should not need more than a few days of work
Transition method 2 – “complete replacement”
Why would you use this strategy?
This option is appropriate if your risk assessment includes references to the old Annex A controls and you are willing to make all the required adjustments to your Information Security Management System (ISMS) and risk assessment to eliminate all references to the old Annex A.
What is this strategy?
This method eliminates any references to the old ISO 27001:2013 Annex A controls from your ISMS and replaces them with the new Annex A controls. This strategy is much more labor-intensive than the previous method.
Privacy
The General Data Protection Regulation (GDPR) Enforcement Tracker by CMS Law provides a summary of the fines and penalties that EU data protection authorities have issued as a result of the EU’s GDPR. This list will be updated as often as we can. The software is alive on GitHub (to be compiled according to your needs) and all the explanations and linking are at https://www.enforcementtracker.com/.
The GDPR-CARPA, proposed last year by the Luxembourg authority, is a sort of certification for entities to prove that they are GDPR-compliant. The GDPR scheme sets the EDPB authority (European Data Protection Board) as the Central European authority for the whole GDPR process, and then every member state has its own local government authority. The compliance is done via an audit, and, even if at the moment, the certification is just a draft, it could be really interesting, because it would allow any certified entity to be chosen by another one (imagine a data processor). See more details here: https://edpb.europa.eu/news/national-news/2022/cnpd-adopts-certification-mechanism-gdpr-carpa_en.
The plethora of websites that use traffic monitoring services, such as AdSense Analytics (but also Google Fonts, if used in an online mode – i.e., if not downloaded and used offline) need to be, according to the European data protection board, set aside in favor of alternative services.
Some of these, using a nerdy metaphor, call home – I mean, send the requests to Mountain View (Google’s home) without proper authorization.
US President Joe Biden has signed the long-awaited Executive Order that is intended to uphold the Court of Justice of the European Union (CJEU) earlier rulings, more than six months after an agreement in principle between the US and the EU. This aims to get around restrictions on data transfers between the EU and the US. The Executive Order from Biden appears to fall short of both requirements.
VA/PT
In past chapters, there were references to risk management and how to deal with vulnerability, among other things. What happens quite often, in terms of vulnerabilities in a company, is related to a technological gap, in which the most relevant (and therefore unsecure aspects, is related to missing updates. In this case, vulnerability management is the only thing you can do to have a clear view of the company perimeter.
VA
VA (short for Vulnerability Assessment) is a methodical analysis of an information system’s security flaws. It assesses the system’s susceptibility to known vulnerabilities, gives severity ratings to those vulnerabilities, and advises remedy or mitigation as necessary.
Among the risks that may be averted by VA are as follows:
- SQL injection, XSS injection, and more code injection threats
- The elevation of privileges as a result of flawed authentication techniques
- Software that comes with unsafe settings, such as guessable administrator passwords
Various forms of VA exist. They consist of the following:
- Host assessment – the evaluation of mission-critical servers that may be susceptible to assaults if they have not been thoroughly tested or created from a tested machine image
- Network and wireless assessment – the evaluation of policies and procedures designed to prevent unwanted access to private or public networks and network-accessible resources
- Assessment of databases and large data systems for vulnerabilities and misconfigurations, identification of rogue databases and unsecured development/test environments, and classification of sensitive data throughout an organization’s infrastructure
- Application scans — the identification of security flaws in online applications and their source code using automated frontend scans or either static or dynamic source code analysis
Vulnerability identification (testing)
So, if you are ready to fire up your VA machine, it’s time to go, even if I would strongly recommend you ask for help (either internal or external). In the case of external assessment, the company that you are dealing with must sign a Non-Disclosure Agreement (NDA), because they can see security issues that should not be divulged. I also suggest you give the testers all the information you can in terms of your company infrastructure: no one tells you clearly, but if they go blind, there’s a risk that they can break some appliances and since they didn’t know what kind of asset they were dealing with, it’s your fault.
The purpose of this step is to compile an exhaustive list of an application’s vulnerabilities. Security analysts evaluate the security of apps, servers, and other systems by scanning them using automated technologies or by manually testing and analyzing them. Additionally, analysts use vulnerability databases, vendor vulnerability notifications, asset management systems, and threat intelligence feeds to uncover security flaws.
Vulnerability analysis
The purpose of this phase is to discover the underlying cause and origin of the vulnerabilities identified in the first step.
It entails identifying the system components accountable for each vulnerability and the vulnerability’s fundamental cause. For example, an outdated version of an open source library might be the underlying cause of a vulnerability. This gives a clear avenue for repair – the library’s upgrade.
Risk assessment
The purpose of this phase is to rank vulnerabilities by importance. It entails security experts awarding a ranking or severity score to each vulnerability based on the following criteria:
- What systems are impacted?
- What data is in danger?
- Which organizational functions are at risk?
- The simplicity of assault or compromise
- The severity of an assault
- The potential harm caused by the vulnerability
Remediation
The purpose of this phase is to close security holes. Typically, security personnel, development teams, and operations teams collaborate to find the most effective method of repair or mitigation of each risk.
Specific corrective measures may include the following:
- Introduction of new security methods, technologies, or processes
- The implementation of operational or configurational modifications
- Development and deployment of a fix for a security flaw
VA cannot be a one-time occurrence. Organizations must operationalize and regularly repeat this process for it to be successful. DevSecOps, the practice of fostering collaboration between security, operations, and development teams, is equally crucial.
Vulnerability evaluation instruments
The purpose of VA tools is to automatically detect new and current threats that potentially attack your application. Examples of instruments include the following:
- Scanners for web applications that test and replicate known attack patterns.
- Protocol scanners that look for insecure ports, protocols, and network services.
- Network scanners that aid in network visualization and the detection of warning signals, such as stray IP addresses, faked packets, and unusual packet production from a single IP address.
- Schedule frequent, automated scans of all important IT systems as a recommended practice. The findings of these scans should be included in the organization’s continuous process of VA.
PT
PT (short for Penetration Testing, or Pentesting) involves approved, simulated assaults undertaken to assess the security of a computer system. Penetration testers use the same tools, strategies, and procedures as attackers to identify and illustrate the commercial repercussions of a system’s vulnerabilities. Typically, PT replicates a number of assaults that potentially affect a company. It can determine whether a system is resilient enough to survive assaults from authorized and unauthenticated positions, as well as from a variety of system roles. With the appropriate scope, PT may probe every facet of a system.
What advantages does PT offer?
Ideally, software and systems would be created with the intention of avoiding serious security vulnerabilities. PT gives insight into the extent to which this objective was met. PT may help a company do the following:
- Locate systemic vulnerabilities
- Assess the strength of the controls
- Support data privacy and security compliance (e.g., the PCI DSS, HIPAA, or GDPR)
- Provide management with qualitative and quantitative evidence of the existing security posture and budget objectives
How much access do penetration testers have?
Depending on the objectives of PT, testers are granted varying degrees of access to or knowledge about the target system. In certain instances, the PT team adopts a single strategy from the outset. Occasionally, the testing team modifies its approach as its understanding of the system grows throughout PT. There are three access levels for PT:
- Opaque box: The team knows nothing about the target system’s core architecture. It behaves as would a hacker, searching for externally exploitable vulnerabilities.
- Semi-opaque box: The team is familiar with one or more credential sets. It is also familiar with the internal data structures, code, and algorithms of the target. The construction of test cases by penetration testers may be based on comprehensive design documentation, such as architectural diagrams of the target system.
- Transparent box: Penetration testers have access to systems and system artifacts, such as source code, binaries, containers, and occasionally even system servers. This method offers the greatest degree of certainty in the shortest length of time.
What are the steps of PT?
Penetration testers imitate assaults by adversaries with malicious intent. To do this, they normally implement the following steps:
- Reconnaissance: Collect as much information as possible from public and private sources on the target to guide the assault approach. Internet searches, domain registration information retrieval, social engineering, nonintrusive network scanning, and even trash diving are examples of sources. This data assists penetration testers in identifying the target’s attack surface and potential vulnerabilities. Depending on the scope and goals of PT, reconnaissance may be as basic as placing a phone call to explore the system’s functioning.
- Scanning: Utilizing specialized software, penetration testers investigate the target website or system for vulnerabilities, such as open services, application security concerns, and open source vulnerabilities. Based on what they discover during reconnaissance and testing, penetration testers use a range of tools.
- Gaining entry: The motives of an attacker may include stealing, modifying, or destroying data, transferring cash, or just harming a company’s reputation. For each test scenario, penetration testers assess the most effective tools and strategies for gaining access to the system, whether via a vulnerability such as SQL injection, malware, social engineering, or another method.
- Preserving access: Once penetration testers obtain access to the target, their simulated assault must remain connected long enough to exfiltrate data, alter data, or abuse functionality. It is essential to demonstrate the possible effect.
What forms of PT exist?
An exhaustive approach to PT is required for optimum risk management. This requires testing every aspect of the environment:
- Web application testers: Evaluate the efficacy of security safeguards and search for vulnerabilities, attack patterns, and other possible security flaws that might lead to a web application penetration.
- Mobile applications: Using both automated and extensive manual testing, testers search for vulnerabilities in mobile application binaries and their accompanying server-side functionality. Typical server-side web service vulnerabilities are related to session management, cryptographic difficulties, and authentication and authorization concerns, among other things.
- Networks: This testing can find commonplace or significant security flaws in an external network and its associated systems. Experts use a checklist that consists of test cases for encrypted transport protocols, SSL certificate scope difficulties, and the usage of administrative services, among other items.
- Cloud: A cloud environment differs substantially from conventional on-premises setups. Typically, the enterprise utilizing the environment and the cloud services provider share security obligations. Due to this, cloud PT takes a set of specific skills and knowledge to examine the cloud’s setups, APIs, databases, encryption, storage, and security controls, among other components.
- Containers: Docker containers often include vulnerabilities that may be exploited at scale. A frequent risk linked with containers and their environment is also misconfiguration. Both of these threats may be detected by a competent pentester.
- Embedded apparatus/Internet of Things (IoT): Due to their extended life cycles, distant locations, power limits, regulatory requirements, and other factors, embedded or IoT devices such as medical devices, autos, in-home appliances, oil rig equipment, and watches have specific software testing needs. Experts conduct a comprehensive communication analysis as well as a client-server study to discover the faults relevant to the use case.
- Mobile devices: Penetration testers use both automatic and human analysis to identify vulnerabilities in mobile application binaries and the accompanying server-side functionality. Authentication and authorization concerns, client-side trust issues, misconfigured security controls, and cross-platform development framework difficulties are examples of application binary vulnerabilities. Typical server-side web service vulnerabilities include session management, cryptographic difficulties, authentication and authorization concerns, and others.
- APIs: Using both automated and manual testing methodologies, the OWASP API Security Top 10 list is covered. Among the security threats and vulnerabilities that testers search for are broken object-level permission, user authentication, excessive data exposure, lack of resources, rate limitation, and others.
- CI/CD pipeline: Modern DevSecOps procedures include intelligent and automated code scanning technologies into the CI/CD pipeline. In addition to static tools that identify known vulnerabilities, automated PT tools may be included in the CI/CD pipeline to simulate what a hacker could do to compromise an application’s security. Automated CI/CD PT may uncover vulnerabilities and attack patterns that are not uncovered by static code scanning.
What are the advantages and disadvantages of PT?
As the frequency and severity of security breaches continue to rise, companies have never had a greater need for insight into their ability to resist assaults. For compliance with regulations such as the PCI DSS and HIPAA, frequent PT is required. Keeping these factors in mind, the following are the advantages and disadvantages of this sort of defect-finding approach.
Benefits of PT
- Identifies vulnerabilities in upstream security assurance procedures, such as automated tools, configuration and coding standards, architectural analysis, and other lightweight VA operations
- Identifies both known and undiscovered software faults and security vulnerabilities, including tiny problems that on their own aren’t cause for alarm but might cause serious damage as part of a larger attack scheme
- Can attack any system by imitating the behavior of the majority of dangerous hackers, emulating a genuine opponent as closely as possible