Business people need to understand the psychology of risk more than the mathematics of risk.
—Paul Gibbons
The previous chapter emphasized the importance of the kick-off meeting with the implementation teams. This chapter focuses on meeting the team members to conduct the initial risk assessment.
This chapter lays the foundation for the initial risk identification and assessment and talks about the importance of preparing and presenting the findings report.
Meeting the Team
To plan the meeting or risk assessment sessions, first meet with the individual teams one by one. That way, you can focus on the areas that each team is responsible for, and it will reduce the chances of missing a key security area.
Meeting all the teams at the same time in a group might not be easy to handle because the security controls for each team may vary. Some have more or less compliance issues. Some teams might lose interest in the first meeting as they may feel their contribution is small. So be careful when implementing big projects.
Identified risks should be reviewed together with all the teams that are affected by those risks, in order to have better risk management plans. Although you can get the help of subject matter experts, it’s better if the risk is identified by those people who are the process owners, as in ISMS/ISO 27001 implementation, the emphasis is more on your process steps, your information flow, or your storage.
You might wonder which team to meet with first. This is a common question across different organizations, as information security teams must meet with many departments to conduct organization-level risk assessment exercises. Most of the time, information security team/CISO just sets up the team.
When most of the members are new to the team or if you are new to the organization, it’s important that you involve someone who understands the business context of the company. In previous chapters, you learned about the importance of knowing the business context.
Hence, the information security team might hesitate when they need to analyze risk of large organizations or reach out to people who have presence in multiple locations. It becomes easier for teams that have some experience (a year minimum) and have started to implement some key security controls. They already know people or different teams and can start to know about the information security team, which will help to build rapport with other teams.
In some organizations, information security is an area that they are hearing about for the first time; they do not know what is expected from them. In that case, knowing people and building relationships will help to overcome the challenges.
Some departments aren’t even aware that an information security department exists within their organization, which is a problem because they cannot work in isolation. Hence it is the responsibility of the information security department to meet all the relevant departments as soon as possible.
The next sections discuss how to analyze gaps with the different teams. In these cases, you are starting to determine the gaps using the control provided in the ISO/IEC 27001 standard.
Annex 5: Information Security Policies
Defined information security policies.
Communicated these policies to employees and other relevant stakeholders.
Reviewed the policies at regular intervals.
During the assessment, you need to check the levels of implementation and assess what is missing.
Note
In most organizations, these steps aren’t performed prior to the ISMS/ISO 27001 implementation.
Annex 6: Organization of Information Security
Defined and allocated information security responsibilities.
Clearly segregated duties. There should be no conflict of duties or areas of responsibility that overlap, creating dual roles.
Defined procedures to maintain appropriate contacts with relevant authorities.
Maintained contact with special interest groups for knowledge improvement purposes.
Identified and addressed risks in information security during the project’s lifecycle.
Ensured proper mobile device use and safe telecommuting. Check how this policy has been defined and implemented.
During the assessment, you check the levels of implementation and assess what is missing.
Annex 7: Human Resources Security
- Before employment
Conduct employee background verification checks.
Look for any report prepared in reference to background checks.
Ensure that terms and conditions of employment are communicated properly to employees and contractors.
- During employment
Check how management responsibilities are implemented.
Ensure that employee/contractor education and training has been conducted and recorded.
Check how the disciplinary process is established and communicated to employees and contractors and whether any disciplinary action is taken once they have committed an information security breach.
- Termination and change of employment
Ensure that employee and contractor termination or change of employment practices are conducted and managed properly.
Annex 8: Asset Management
Check how assets are identified and whether there is inventory throughout the asset lifecycle.
Check how ownership of assets is defined and allotted to the asset owner.
Check how acceptable usage policies are defined and communicated to all asset users.
Check how employees and contractors return company assets upon their termination.
Check how information classification is done for the various types of information generated in your organization to prevent its unintended disclosure.
Check whether a procedure is defined to label information (electronic format) and any related physical assets.
Check whether a procedure is defined for handling various types of assets.
Ensure that media is removed properly when it is no longer required.
Ensure that media is disposed of properly when it is no longer needed.
Check how media is protected from unauthorized access, misuse, or corruption when transported out of the office.
Annex 9: Access Control
Check for the access control policies that segregate the access control roles. For example, access requests, access authorizations, and access administration.
Check whether all important passwords and credentials are stored securely.
Check that everyone in the organization has only role-based access and they can view or modify only what they are supposed to.
Check that the access rights are associated with all the systems, tools, or software that employees use and have proper access management.
Check the development environment and ensure that the source code is restricted to authorized users only.
Annex 10: Cryptographic Control
Do you still store or transport business confidential information in pen drives, hard drives, and other external drives? If the answer is yes, consider the potential impact of losing that data or it being stolen by a competitor. To avoid these scenarios, it’s smart use cryptographic control.
Does the organization have an encryption policy that defines the proper use of encryption tools and defines the strength and quality of encryption algorithm? The policy document should also address key management and define methods for dealing with protecting keys and information.
Check how the keys are managed after their generation and how they are stored and distributed.
Check for rules, regulations, and restrictions regarding the use of cryptographic controls in the country where you are implementing ISMS.
Check that all your web applications are secured and configured with the latest TLS and SSL.
Check how your payment information is encrypted during the transaction and how you store the payment information in your database.
By asking these questions, you can determine if any gaps exist regarding this control.
Annex 11: Physical and Environmental Security
Check that the office is well protected against unauthorized access and that all the doors and windows are properly locked during non-office/non-activity hours.
Check that the security and fire alarms are configured and tested.
Check that your company maintains visitor logs, with details like their time in, time out, purpose of meeting, etc.
Check that all the employees have an access card to enter the premises and that highly sensitive zones like server rooms and other zones identified by your organization are also protected by biometrics.
Check that the fire alarms, smoke detectors, water sprinklers, and fire extinguishers are installed and regularly tested. Also, check that the fire safety drill training has been conducted.
Check that business-critical equipment is protected from unauthorized access.
Check how the supporting utilities, such power supply, water, ventilation, and air conditioning are managed during an interruption.
Check how the cabling security is managed to prevent damage.
Check that all the supporting utilities or the equipment have undergone regular maintenance and that the records are maintained.
Check how the removal of asset such as equipment, information, and software and its return to the organization is managed.
Check for procedures or policies regarding when employees can work from home.
Check how you manage transferring equipment from the office premises to external vendors.
Check if you have a policy to dispose of or re-use equipment. Check whether you need third-party help or your organization can do it.
Check how users’ unattended equipment is protected and managed.
Check if you have implemented a policy regarding clear desk and screens.
Note All these points need to be checked thoroughly to identify initial risks, as there could be organizational obligations to implement them.
Annex 12: Operations Security
Check that there are documented standard operating procedures so that teams know how to perform their daily work.
Check how the change-management practices are implemented.
Check how the capacity management practices (for applications, systems, databases, and environment) are planned and implemented.
Check how you differentiate between environments (for development, testing, and production/live).
Check what controls are implemented against malware detection, prevention, and recovery. Also, check for a policy that forbids the use of unauthorized software.
Check that there is a policy that defines how to properly back up data.
Check how the logs are maintained and reviewed for various events that occur during day-to-day operations.
Check how the organization protects log information such as audit logs and various system logs.
Check how the system administrator logs have been protected and reviewed regularly.
Check how the clocks of all relevant information processing systems have been configured.
Check that all installed operational software is licensed and check that they are installed, maintained, and upgraded on a regular basis.
Check how your team conducts the vulnerability assessment test on your applications before they are released to production/live environment.
Check which restrictions are implemented to prevent the installation of software packages without approval.
Check that a policy has been implemented to perform an audit test on your day-to-day operations.
Annex 13: Communications Security
Communications security emphasizes the communication channel and the transfer of information by various means. The communication channel must be protected to secure your information.
Check what control has been implemented to protect the company network for secure transfer of information.
Check whether the network service providers are in-house or external to the organization. If they are external, check for the agreement and the service level agreed to protect the network.
Check whether any network segregation levels are done.
Check that information transfer practices have been implemented for transferring information within and outside the organization.
Check which control has been implemented to protect information transfer via electronic messaging such as email, electronic data interchange, and social networking sites.
Check how the non-disclosure agreement (NDA)/confidentiality agreement has been designed and implemented in your organization .
The next sections discuss analyzing the gaps in system acquisition, development, and maintenance.
Annex 14: Security Requirements of Information Systems
In any organization that has an IT department , this security control is applicable, as it emphasizes the security needed when building a software product or application.
The service delivery team makes up the program managers, project managers, business analysts, and QA managers. They are involved in the collection of products and applications during the requirement elicitation phase. They also communicate with the client or stakeholders daily. Hence, it is easier for them to understand what security requirements need to be built for the software.
The service delivery team is the right stakeholder to ask about this security requirement control. They have more clarity about whether this control is implemented per the standards, whether it is only partially implemented, or whether it’s not implemented at all. Sometimes teams are not aware of which security requirements they need to collect as part of the requirement elicitation phase. Sometimes they are collecting a few, but they are not aware as what to collect as part of the security requirements. Because of this, the software applications could be easily hacked or compromised.
How and where do you collect security requirements? This is usually covered in the business requirement document or in the software requirement specification. They are sometimes referred to as BRS and SRS documents. Some organizations use software tools such as Jira Asana to store their product requirements. Hence, during the assessment of the security control, it is advised to go through the requirement descriptions to determine whether security requirements have been captured. This will help you assess the gaps in the current implementation.
Level of access provided to the users. For example, you need to show some sensitive information to an authorized customer or user after validating their authenticity. It can be a payment page which will appear only when the user is successfully logged in to the system. The user must be authorized and authenticated to the defined role to access the information.
Encryption of sensitive data. For example, if you are collecting payment from the customer, the payment page must be encrypted so that the information transferred to the server will not leak or get hacked before reaching the payment gateway. If the information is leaked, it will not be of use to the hacker as it is encrypted. Another example is how you store customers’ sensitive information such as credit card numbers and passwords. They also must be stored in encrypted format.
Session management. Session management is mandatory for the stateless protocol HTTP as it authenticates the validity of authorization. The security requirement may be to see the inactivity of the user and close the session. In such a scenario, the user needs to log in again to validate authenticity.
There may be different security requirements based on the application or the software product you are working on. The standard makes it mandatory to collect those requirements and to comply with the regulations.
Security in Development and Support Processes
The objective of Clause 14.2 is to ensure that when the development team works, the development lifecycle will remain secure throughout the development or product’s/application’s life.
Define a Secure Development Policy
Securing the coding environment, including the development environment and server, testing environment and server, and the production environment and server. As per the standard, these environments must be separate, and their access must always be protected and monitored.
Secure coding guidelines. Developers should use secure coding methods when writing the code and commit fewer mistakes. This will help protect the code against virus and malware attacks. They need to install the latest security patches as well.
Secure repositories, such as SVN, CVS, and GIT, by ensuring versions are maintained and controlled at all times. From time to time, developers must be trained in the secure coding practices.
System change control. Changes must be incorporated using the change control procedures and with the approval of the change control board. The board should approve all changes. It is never safe to allow any one individual to decide to make such changes.
Technical review. This refers to reviewing an application after any operating platform changes. This is to ensure that all business-critical applications have been reviewed/tested and are not compromised in any manner.
Restriction of changes to software packages. It should not be allowed by the users on their own. It must be done by the IT members authorized to maintain all the software licenses. It is advisable to use the vendor supplied software packages. From time to time, the software should get updates and approved patches.
Secure system engineering principles should be written according to your organization’s in-house development activities. Security should be built at all levels and if any new technology or designs are added, they must be reviewed for security risks.
Outsourced development. Whenever development needs to be outsourced, there are many controls to be placed. When we share code with other companies, it must be protected. The ownership of the code must be ensured and intellectual property rights must be respected.
System security testing. There needs to be thorough testing of newly developed and updated systems. For in-house development, the development team should perform the testing first and then an independent testing team should test the product or the application.
System acceptance testing must be done for all new systems or upgrades. Testing must be done in a real environment to ensure that the system does not have any security vulnerabilities.
Test Data
The objective of Clause 14.3 is to ensure that the test data is selected carefully, protected, and controlled.
The main point is to remember while performing testing, is to avoid personal identifiable information and confidential information. Once the testing is done, all data must be immediately erased from all the testing environments.
Annex 15: Supplier Relationships
Check whether signed non-disclosure agreements are available from all vendors and suppliers.
Check how security parameters (such as legal and regulatory requirements, intellectual property rights, and copyright) are covered in the agreement signed with your suppliers/vendors.
Check how the supplier agreements about supply chain security and appropriate security practices throughout the supply chain have been implemented.
Check whether your organization is regularly monitoring, reviewing, and auditing the supplier service delivery for the services procured or outsourced.
Check how changes to the supplier services are managed.
Annex 16: Information Security Incident Management
Check whether any roles and responsibilities are defined that manage security incidents.
Check how information security incidents are reported in the organization.
Check how suspected weakness are observed and reported in the organization by responsible departments and by suppliers or vendors.
Check how information security incidents are identified and reported to the information security incident reporting team (ISIRT).
Check how the information security incidents are responded to and documented.
Check whether your organization has a knowledgebase to refer to security incidents that occurred in the past.
Check how information security incidents are collected and stored.
Annex 17: Information Security Aspects of Business Continuity Management
Check whether business service continuity plans (for disasters like floods, earthquakes, fires, etc.) are defined and implemented.
Check whether a policy is defined and documented to implement information security continuity.
Check that your organization is verifying, reviewing, and evaluating information security continuity on a regular basis as per the defined policy if any.
Check whether information-processing facilities are redundant to ensure failover from one component to another.
Annex 18: Compliance
Check whether all applicable legislation and contractual requirements have been identified for each location, country, etc.
Check whether procedures are defined to prevent the misuse of intellectual property rights.
Check which practices are implemented to protect and maintain the various record types that are generated.
Check which practices are implemented to protect the privacy and protection of personally identifiable information.
Check that the usage of cryptographic controls comply with all the relevant legislation and regulation.
Check whether independent security reviews are conducted from time to time.
Check how department managers conduct reviews of the defined policies and procedures from time to time.
Check whether technical compliance reviews are planned and conducted from time to time to ensure that various hardware and software security controls are implemented in the right manner.
The purpose of explaining the controls from Annex 5 to Annex 18 is to help you easily understand them and be able to identify the gaps in your current practices,. which can further help you identify the initial risk assessment. You will read more about them in coming chapters, where you will read the detailed control execution.
Preparing the Analysis Report
So far, you have done the risk assessment exercise by meeting all the teams. Now it is time to prepare the report based on the identified gaps. This will tell you the level of control you have already implemented and are following, but will also show the areas that need work (gaps). The report acts as a picture of every department based on the international standard practices.
Sample gap analysis report
Now for every department and all the controls, you can depict in the same manner as shown for the HR control. This will act as a gap analysis report with the risks to work on.
Presenting the Report to Management/Teams
Once the report is ready, you must plan a session and present the report to the steering committee. It’s important to get their opinion and support about the risks that the analysis classified as major. It is very important to know what your management’s expectations are. The steering committee will be interested in knowing where the gaps exist in the system and what is required to close them. Some businesses are critical, and any open gaps can hamper their business in a way that’s difficult to recover from. Hence critical gaps must not be hidden from the steering committee. For example, medical and defense organizations cannot keep gaps open for very long.
Sample finding chart of control groups
Summary
This chapter talked about how to conduct the initial risk assessment with all the teams and what to check for as a part of controls in the standard. You also learned that the analysis report is important from a management perspective, as management wants to know the areas with gaps. This report will also track actions for everyone.