ISO 27001:2013 Clause 6.2 Information Security objectives

by Pretesh Biswas,

Business managers expect information security to protect the information in business systems and prevent the systems from being interrupted. Information security supports the business in achieving its objectives. To begin the development of a strategic plan for security it is essential to understand the business objectives and the key elements of the information security function. Business objectives can be analyzed to identify dependencies on security. The security objectives can then be defined in terms of business objectives. The security objectives are then impacted on by business and environmental constraints, and by threats and vulnerabilities. Metrics are developed to allow comparison between current security capability and the capability required to meet business requirements. Strategies can be developed to fill the gap between current and planned capability while allowing for environmental constraints and threats. A strategy is a direction or approach taken to meet one or more objectives. Strategies do not have priorities: they are mutually exclusive. Each strategy is supported by one or more initiatives. An initiative is the implementation of an operational plan that achieves part or all of the security objectives. The overall objective is to implement a range of initiatives that collectively achieve all of the security objectives. Your security policy defines what you want to protect and the security objectives are what to expect of users.  Each network service that you use or provide poses risks to your system and the network to which it is connected. A security policy is a set of rules that apply to activities for the computer and communications resources that belong to an organization. These rules include areas such as physical security, personnel security, administrative security, and network security. Your security policy defines what you want to protect and what you expect of your system users. It provides a basis for security planning when you design new applications or expand your current network. It describes user responsibilities, such as protecting confidential information and creating nontrivial passwords. Your security policy should also describe how you will monitor the effectiveness of your security measures. Such monitoring helps you to determine whether someone might attempt to circumvent your safeguards. To develop your security policy, you must clearly define your security objectives. After you create a security policy, you must take steps to put into effect the rules it contains. These steps include training employees and adding the necessary software and hardware to enforce the rules. Also, when you make changes in your computing environment, you should update your security policy. This is to ensure that you discuss any new risks that your changes might impose.
When you create and carry out a security policy, you must have clear objectives. Security objectives fall into one or more of the following categories:

  1. Resource protection
    Your resource protection scheme ensures that only authorized users can access objects on the system. The ability to secure all types of system resources is a System strength. You should carefully define the different categories of users that can access your system. Also, you should define what access authorization you want to give these groups of users as part of creating your security policy.
  2. Authentication
    The assurance or verification that the resource (human or machine) at the other end of the session really is what it claims to be. Solid authentication defends a system against the security risk of impersonation, in which a sender or receiver uses a false identity to access a system. Traditionally, systems have used passwords and user names for authentication; digital certificates can provide a more secure method of authentication while offering other security benefits as well. When you link your system to a public network like the Internet, user authentication takes on new dimensions. An important difference between the Internet and your intranet is your ability to trust the identity of a user who signs on. Consequently, you should consider seriously the idea of using stronger authentication methods than a traditional user name and password login procedures provide. Authenticated users might have different types of permissions based on their authorization levels.
  3. Authorization
    The assurance that the person or computer at the other end of the session has permission to carry out the request. Authorization is the process of determining who or what can access system resources or perform certain activities on a system. Typically, authorization is performed in the context of authentication.
  4. Integrity
    The assurance that arriving information is the same as what was sent out. Understanding integrity requires you to understand the concepts of data integrity and system integrity.

    1. Data integrity: Data is protected from unauthorized changes or tampering. Data integrity defends against the security risk of manipulation, in which someone intercepts and changes information to which he or she is not authorized. In addition to protecting data that is stored within your network, you might need additional security to ensure data integrity when data enters your system from untrusted sources. When data that enters your system comes from a public network, you need security methods so that you can perform the following tasks:
      • Protect the data from being sniffed and interpreted, typically by encrypting it.
      • Ensure that the transmission has not been altered (data integrity).
      • Prove that the transmission occurred (nonrepudiation). In the future, you might need the electronic equivalent of registered or certified mail.
    2. System integrity
      Your system provides consistent and expected results with expected performance. For the i5/OS operating system, system integrity is the most commonly overlooked component of security because it is a fundamental part of i5/OS architecture. i5/OS architecture, for example, makes it extremely difficult for a hacker to imitate or change an operating system program when you use security level 40 or 50.
  5. Nonrepudiation
    The proof that a transaction occurred, or that you sent or received a message. The use of digital certificates and public-key cryptography to sign transactions, messages, and documents support nonrepudiation. Both the sender and the receiver agree that the exchange takes place. The digital signature on the data provides the necessary proof.
  6. Confidentiality
    The assurance that sensitive information remains private and is not visible to an eavesdropper. Confidentiality is critical to total data security. Encrypting data by using digital certificates and Secure Socket Layer (SSL) or virtual private network (VPN) connection helps ensure confidentiality when transmitting data across untrusted networks. Your security policy should conclude how you will provide confidentiality for information within your network as well as when information leaves your network.
  7. Auditing security activities
    Monitoring security-relevant events to provide a log of both successful and unsuccessful (denied) access. Successful access records tell you who is doing what on your systems. Unsuccessful (denied) access records tell you either that someone is attempting to break your security or that someone is having difficulty accessing your system.

6.2 Information security objectives and planning to achieve them

The organization must establish information security objectives at relevant functions and levels. The information security objectives must be consistent with the information security policy. If practicable it must be measureable. It must take into account applicable information security requirements, and results from risk assessment and risk treatment. It must be communicated and updated as appropriated.  The organization must retain documented information on the information security objectives.
When planning how to achieve the quality objectives, the organization must determine what will be done; what resources will be required; who will be responsible; when it will be completed; how the results will be evaluated.

Set Objectives

Sect. 6.2 of the standard essentially boils down to the question; ‘How do you know if your information security management system is working well?’ To do this you need to arrive at a set of objectives keeping in mind clause. 4.1, 4.2, 4.3 and 6.1 and determine how you will evaluate and measure performance against each of those objectives. Consider the objectives you want to achieve as an organization in relation to information security. Some examples could be

  • “Delivery of a secure, reliable cloud service for users and other interested parties who need confidence and assurance the platform is fit for their purpose of sharing and working with sensitive information.”
  • “Provide a pragmatic digital paperless ISMS for staff (and other interested parties who need to access it), integrated into their day to day work practices to ensure it becomes a habit for good performance, not an inhibitor to getting their work done.”
  • How can you write measurable objectives?
    Plans by their nature are largely concerned with change or an effort to maintain valued aspects of the current situation. The extensive process of information collection and analysis, consultation, validation, and priority setting is used to identify where you think the effort needs to be focussed. When it comes to writing these into objectives, there should be a clear logic between objectives and the goal they are pursuing. Objective statements will follow a general form: ‘To do what, for whom, by when?’. Careful selection of the language used to express objectives can provide a clearer intention of what will be done and what you hope to achieve. Strong, clear verbs describe the ‘do’ component and are the key to setting the tone and commitment of the objective. The list of verbs below provides some examples of words that are action-oriented applied to common interventions.
    Caution is recommended against the over-use of words such as ‘develop’, ‘facilitate’ or ‘support’. These are less descriptive and can dull the tone of a plan if over-used. However, they should not be replaced with inferior, vaguer words or at the other extreme, technical terms or jargon. Avoid words like ‘enhance’, ‘commit’, which are not specific and hence more difficult to measure. Also, avoid multiple verb use for objectives: For example:
    Not: ‘To explore opportunities to increase access to…’
    Try: ‘To increase access to …’
    In this case, ‘exploring opportunities’ is probably a step towards ‘increasing access’. However, you don’t need to include the steps you will take to achieve your objective in the objective statement. If it warrants it, this will be described at the strategy level (which, as stated above, are the actions taken to reach these objectives). Words like ‘explore’, ‘discuss’, ‘commence’ , seek, and ‘encourage’ are often used in this way and should be avoided. If these words cannot be eliminated in favor of a more direct word, the likelihood is that you are describing a strategy, not an objective, or you are not clear enough in your own mind about what you propose to do.
  • How can you keep your objectives consistent?
    One of the challenges of plan writing is creating a consistent relationship between plan statements so that they are pitched at a consistent level. It is confusing if an objective in one part of a document is a broad statement while in another it is quite specific (more like a strategy). One way of checking whether your objectives are pitched at the right level is to ask ‘why?’ The answer will test the theory behind your objective and should lead you to a health and wellbeing goal – whether stated or implied. If the goal is more than one step away from the statement the likelihood is that is pitched at a strategic level. The verbs used might not provide any clues to the appropriate level. Words like ‘increase’ and ‘decrease’ are also likely to be used at the goal level and a strategic level. However, at a goal level ‘increase’ is likely to be applied to the quality of life and ‘decrease’ to the incidence of illness or disease. At a strategy level, both are likely to be applied to features of service systems or standards. Other words might fit an objective or strategy level, however, some will suggest that the statement is better included as a strategic level. Words more common at a strategy level include:
  • How can I check my objectives?
    A good way to test your objectives is to use the SMART technique. SMART statements have the following characteristics.
    S specific: it indicates clear action on a determinant, population group, and setting.
    M measurable: it includes features that will help you tell whether it has succeeded.
    A attainable: it can be realistically achieved on time and within available resources.
    R relevant: it is a logical way to achieve your goals.
    T time-framed: it indicates a timeframe for action.

Determine the metrics system

Once you have those objectives, consider the key things that should and shouldn’t be happening if you were to meet each one of them and how you would go about measuring those things. For example, a key measure of success could be the availability of systems for customers to use. So you can have an uptime objective of 99.5% (or SLA with customers) as one of the measures we track each month using our uptime monitoring systems. When you are thinking about what to measure have in mind the three key principles that run through ISO27001 of Confidentiality, Availability, and Integrity. So, for example, some of the things we looked at to measure ourselves against were;

  • System uptime with a target of 99.5% (availability)
  • Any failures in our backups with a target of none (integrity)
  • Number of corrective actions with a target of none (all)

The philosophy of ISO 27001 is PDCA management cycle (Plan-Do-Check-Act). The concept of measurement is also best explained through this PDCA cycle:

  • In the Plan phase, you need to set the objectives
  • In the Do phase, you must figure out how to measure up to which point your objectives are achieved
  • In the Check phase you need to start the actual measurement, and finally
  • In the Act phase, once you realized you haven’t achieved your objectives (which is very often the case), you need to make certain improvements

So how can you measure backup or firewall? The secret lies in setting objectives which are easy to measure – you might have heard of the S.M.A.R.T. concept: objectives need to be Specific, Measurable, Achievable, Relevant, and Time-based.

  • So, what would it look like for the firewall? Something like ‘We want our firewall to stop 100% of unwanted network traffic’. Is it measurable? Yes – you will find out, sooner or later, whether some unwanted traffic has passed through the firewall.
  • Another example – backup. The objective could be ‘We want to achieve our loss of data is a maximum of 6 hours.’ Measurable? Yes – and you don’t have to wait for data loss to happen, you can test your backup and see how much of the data you can restore.
  • An example of the objective for the whole ISMS could be ‘We want to decrease the number of information security incidents by 50% in the next year’. Again, pretty specific and therefore measurable.

Setting the objectives and measuring them is a rather new and unexplored aspect of information security. It is very often considered as an overhead because of the lack of knowledge in the first place, not so much because of practical reasons.

Here is the example of the Information Security objectives

S. No. Parameter Objective Periodicity Responsible Team
1 Average Minor  Non-conformities per AUDIT Cycle (per department) <=5 Every 6 months (Post Audit) ISMS
2 Impact on assets/human resources  due to  Fire Accidents =100% compliance Every 6 months ISMS
3 Internet Downtime (on Working days in working hours) >=99% availability Every 6 months IT Team
6 Infected file status (new + still infected) count because of virus and spyware <=3 Every 6 months IT Team
5 Overall High priority Incidence Occurrence Rate
Admin +Facilities
IT
HR(should include incidents related to POSH)
Customer Delivery/Project
<=5
<=5
<=5
<=5
Every 6 months (Pre-audit) ISMS
6 Customer Satisfaction on Internal infrastructure >=90% Every 6 months (Pre- Audit) Support/ Delivery/ IT
7  License Issues =100% compliance Every 6 months IT
8 IP/Legal issues =100%  compliance Every 6 months Management/ Directors
9 Repetition of Audit Findings in next Internal Audit <=2 Every 6 months (Post Audit) ISMS
10 Count of residual risks <=10 Every 6 months (Pre-audit) ISMS
11 Full back up failures <=2 times Every 6 months IT Team
12 Downtime due to power failure (during working hours) <=6 hours Every 6 months Admin team
13 Number of employees relieved/ terminated without execution of HR Exit checklist =100% compliance Every 6 months HR team
14 Security testing for all projects =100% compliance Every 6 months Delivery team

Information security key performance indicators

A key performance indicator (KPI) is a metric used to evaluate factors that are crucial to the success of an organization. It differs from an objective in that an objective is something you want to achieve, while a KPI is something used to verify if your efforts are leading you toward the defined objective. For example, if 60 mph is the speed objective, the speedometer helps you to achieve and maintain this speed. In a scenario where decision-makers are surrounded by information and have limited resources to work on objectives, to define those most relevant (the KPIs) and how and when they should be presented is a good way to help monitor results and make proper decisions. Besides the verification, if one is on course to achieve the proposed objectives, KPIs may be used to support ISO 27001 by helping to communicate the importance of information security management and objectives. Though there are many criteria you can use for KPI selection, some aspects are common to them and they can make your task easier:

  • Business relevant: the indicator should be aligned to clear business objectives or legal requirements, which makes it easier for people to understand why it should be measured and evaluated. ISO 27001 has some requirements that may be attended by the use of indicators related to effectiveness and compliance, but an organization should consider efficiency indicators, too; for example, the Return On Security Investment (ROSI) can show how well the resources are Used to support security planning.
  • Process integrated: activities to collect the necessary data for a KPI should add the least amount of work possible, compared to the usual activities required to deliver the product/service, and the information (e.g., marking a step as completed or recording the time to perform an activity) needed should be in the same forms already used by the process.
  • Assertive: the indicator should be capable of pinpointing relevant issues (e.g., process steps, organizational areas, resources, etc.) that need attention. For example, a KPI related to the number of failed login attempts explicitly limits the scope to the login process.

Examples of performance indicators

The following examples cover a complete PDCA (Plan-Do-Check-Act) sequence, showing how different indicators can be used to get a full view of the performance of the processes related to information security management.

  1. Plan
    Percent of business initiatives supported by the ISMS: indicator that shows the ISMS’s level of alignment and integration with the business. The higher the value, the more optimized the ISMS resources, since management resources are being used over more aspects of the organization. You can use the ISMS Scope Document, compared to all services/processes of the organization, to obtain this information.

    1. Percent of information security initiatives containing cost/benefit estimates: an indicator that shows the organization’s maturity on risk treatment. The higher the value, the more the risk treatment decisions are based on facts. You can use the Risk Assessment and Treatment Report and the Risk Treatment Plan, compared to all security initiatives implemented, to obtain this information.
    2. Percent of agreements with information security clauses: indicator that shows how services and products, provided by you or supplied to you, are legally supported considering information security aspects (e.g., availability, confidentiality, integrity, and continuity). The higher the value, the better supported your relationships with clients and suppliers are. You can use Non-Disclosure Agreements and SLAs with information security clauses, compared to all agreements related to services and products, to obtain this information.
  2. Do
    The number of security-related service downtimes: downtimes related to information security issues directly reflect the effectiveness of the ISMS. This information can be obtained from operational reports. Duration of service interruptions: as important as the number of downtimes, the average duration of downtimes is an important measurement of ISMS effectiveness. This information can be obtained from operational reports. Incident resolution time: another important measurement of ISMS effectiveness, this information can be obtained from operational reports.
  3. Check
    Percent of controls assessment performed: an indicator that gives you a view of how many security measures are being reviewed. The higher the value, the more controls are being analyzed in terms of effectiveness, efficiency, and opportunities for improvement. You can use the Risk Treatment Plan, compared to Training Plans, Incident Logs, Audit Reports, and Management Review Minutes, to obtain this information.
  4. Act
    The number of improvement initiatives: an indicator that shows the proactivity of an organization’s ISMS with respect to changes in the environment and the opportunities identified. Changes with the objective to improve results or prevent losses, instead of correct errors or problems, are good examples that reflect a high value on his KPI. You can use the Audit Reports and Management Review Minutes to obtain this information.

Proper monitoring to improve results and avoid problems

Organizations are under constant pressure to achieve results and to do so, it is essential that they can count on proper navigational instruments that can show them if they are on the right course and allow timely adjustments. But, it is also essential that these instruments are well-chosen and calibrated, or else you may find yourself attacking the wrong problems and turning a bad situation into something worse.

Steps to establish Information Security Objective

1. Establishing a Strategy Plan

The purpose of a strategic plan for security is to provide management with the necessary information to make informed decisions about investment in security. The strategic plan links the security function with the business direction. The strategy must present a business case that describes key business benefits and outcomes related to security, with recommended strategies for achieving those outcomes. Strategies for security help achieve business objectives by identifying and addressing security requirements in business functions and initiatives and providing infrastructure, people and processes that meet those requirements. Although driven by business requirements, strategies must take into account other factors that may impact on the achievement of those outcomes. The strategies must be revised periodically to allow for changes in the business direction and in the constraining factors.

2. Security functions

As the strategy describes business outcomes related to security, the scope for security strategy is defined by an organization’s definition, or scope, of its security function. The security function should be defined by objectives. The key functional areas defined are security policy, security organization, personnel security, asset classification and control, physical and environmental security, computer and operations management, system access control, system development and maintenance, business continuity planning, and compliance.
E.g. The objective of security at <organization> is to protect information and information systems and prevent unauthorized access, unauthorized modification or damage, or interruption to business functions.
Under company law, directors are obliged to take reasonable actions to protect company assets. Reasonable action can be demonstrated by aligning an organization’s security functions with industry standards. Security functions can be strategic, tactical or operational. Security functions are implemented in terms of technology, processes, and people. Security functions should be documented with accountability against organizational roles. Accountability for security functions may be concentrated in a single security group, or allocated to other areas that have common objectives. For example, the accountability for business continuity may be allocated to an operational support group. A security strategic plan should include objectives for all security functions regardless of where they are placed within the organization

3. Business objectives

Business objectives are the highest level, or fundamental, objectives of the organization. At the conceptual level, these objectives relate to the prosperity of the organization and all of its stakeholders. When enumerated by the business the objectives become more descriptive and may include the following:

  • to reduce costs by efficiency gains
  • to reduce potential costs through risk reduction
  • to protect assets
  • to create opportunities for revenue growth by enhancing or creating customer services and products by creating competitive advantage and to extend the customer bench.
  • to create opportunities for revenue growth by enhancing or maintaining a reputation in the marketplace, reducing time to market and by marketing/advertising and channel management

Business objectives are implemented through a range of business strategies. Strategies will vary greatly between organizations. Example business strategies may include the following:

  • Building infrastructure to provide extended customer functions
  • Joint venture or mergers to improve market position
  • Outsourcing to achieve flexibility and cost reduction
  • Business strategies will be achieved through the implementation of a range of business initiatives.

4. Security objectives

  1. Determining Security objectives

    Security objectives are the sub-set of the business objectives that can be achieved by the application of the security functions. To determine the security objectives, evaluate the potential for each business objective or initiative to be impacted by each security function. For example, consider the business objective of increasing revenue through reduced time to market.
    How does security policy impact on time to market?
    The policy provides a statement of acceptable risk. If security policy does not define protection requirements for sensitive information, then development may be delayed while the risk is assessed and security controls defined. At the same time, stringent policy requirements may also delay the development of system enhancements, and may even preclude some business initiatives as excessively risky. The security objective would be to optimize between the policy that defines the minimum controls – giving the best time to market, minimum cost and maximum business enablement – while keeping residual risk below an acceptable threshold.
    How does security organization impact on time to market?
    Security organization ensures that accountability for security functions has been allocated to organizational roles. If security functions have not been effectively allocated, delays could be incurred at any point of the development lifecycle that depends on a security function. For example, if inadequate resources have been allocated for security assessment, there may be delays in getting approval to promote a system into production. The security objective would be to ensure that security functions are supported adequately to prevent delays in getting products and services into production. Continuing the evaluation to assess the impact of each security function on each business objective will produce security objectives directly aligned with business objectives. This method may be more relevant when revenue and growth is a priority.

    An alternative method may be. We can start with each of the security functions and create a scenario showing the potential impacts to the organization should the security fail. The security objectives for each scenario are then to implement security that prevents those impacts. For example, consider the security function to manage access. In a scenario where access management fails, a hacker might gain access to an internal server and expose information from business partners. Information may be commercial in confidence and also contain information subject to information privacy legislation. Resulting impacts could include:

    • Parties whose information is exposed seeking penalties for breach of the non-disclosure agreement, and also seeking to recover subsequent losses;
    • Customers using alternative service providers. The organization’s reputation and revenue is adversely impacted;
    • Exposure resulting in the breach of privacy legislation, litigation costs, penalties and impact on reputation.

    The security objectives of this scenario could include:

    • to prevent hackers from gaining unauthorized access to internal servers;
    • to ensure adequate controls are in place to reduce the risk of claims under privacy legislation should exposure result in such claims.

    Scenarios should be developed to cover each security function. Multiple impacts may be associated with each function. Further validation can be attained by including scenarios for actual losses previously incurred by the organization, or by including potential losses from risks identified in recent audits or recorded in risk registers. In addition to event-based scenarios (e.g. failure of security controls) also consider pre-event scenarios. Using the security assurance function as an example, if customers perceive that security in a web service is inadequate they may not take it up, resulting in lost revenue. This method may be more relevant when reducing cost is a priority.

  2. List of strategic security objectives

    Having determined the security objectives using either (or preferably both) of the methods above, the rationalized list of security objectives now describes the purpose of the security function. Security objectives must be achievable by security functions. Security objectives will vary across organizations. A list of possible security objectives, including how they are achieved by security functions follows:

    • Objective – to reduce security events
      Security functions can alter the likelihood and impact of security events. For example, access management can prevent unauthorized access. Reduction in security events will reduce system interruptions, reduce costs arising from
      business interruptions and from recovery, protects the reputation and existing revenue streams, reduce information exposure and damage, and reduce legal penalties.
    • Objective – to provide security infrastructure that reduces development costs
      • Security functions can implement security infrastructure (e.g. authentication services, access management and provisioning, identity management, key management) that can be re-used by multiple systems. Re-use reduces development costs and also reduces complexity.
      • Infrastructure may provide revenue-generating opportunities through product differentiation.
    • Objective – to reduce operational costs
      • Security functions can reduce operation costs by increasing the efficiency of providing services, such as access control mechanisms.
      • Security functions can reduce insurance costs by reducing the risk profile of the organization.
    • Objective – to reduce development costs
      Security functions can reduce development costs by imposing minimal security controls, by providing infrastructure to reduce the cost of developing controls, by providing the policy that reduces the need for risk assessments,

5. Measuring security outcomes

  1. Metrics
    Once security objectives have been identified, an organization must choose methods that demonstrate when those objectives have been met or not met. Metrics must be established that show if security is effectively achieving the security objectives. Strategies for implementing security cannot be achieved unless their impact on security objectives can be assessed either qualitatively or quantitatively. The typical management process includes planning for an outcome, implementing a process to achieve the outcome, measuring the results, and using the results as a measure of effectiveness to improve on the original plan. The process for the management of security is atypical in this regard. Security assurance cannot be measured in terms of the “results” where there are none. Major security events may never occur or occur very infrequently. There are also limitations on assessing security in terms of the likelihood of impacts occurring. Consider a scenario in which there is a one in a million chance in any given year that there will be a security breach resulting in a Rs 50 crore loss. The probabilistic loss rate is Rs 5000 per year. Therefore any mitigation plan to reduce the risk must cost less than Rs 5000 per year to provide a positive return. For straight-line risk tolerance, the definition of acceptable risk levels is limited by the difficulty in determining the true probability of the event and the true loss that may occur. In practice, risk tolerance is non-linear. Organizations tend to exhibit an increasing aversion to high-level impacts despite the very low likelihood of occurrence. Furthermore, security events are not as simple as the product of likelihood and impact as often used. Due to the nature of security incidents, they are typically based on a number of successive events. A simple vulnerability may result in a low impact event. There is a lower probability that this will be exploited into a higher impact event. Successively unlikely events will result in successively higher impacts. Therefore, a security event has a risk probability function showing decreasing likelihood with increasing impact. Likelihood may be indicated by a history of previous events if available. Typically there is no history of high impact events. Security assurance needs to be measured in terms of the reduction in this risk probability function. Security assurance also needs to be measured in terms of each of the security objectives. For example, metrics for the first security objective derived above (to reduce security events) are described as follows:
    Objective – to reduce security events
    Metric – The reduction in the risk of security events can be measured in the following terms:

    •  Security can be measured by a system’s resistance to a range of penetration and/or vulnerability tests.
    • Security can be measured against benchmark implementations. For example, the security of a Window server could be measured by assessing compliance with the CIS Benchmarks.
    • Security controls can be measured analytically. This might be done by measuring the number of Top 20 twenty vulnerabilities occurring across critical services within the organization.

    Metrics should be customized to reflect organizational objectives and values. This assessment should be continued to establish metrics for each security objective. This task is demanding but essential to providing the context for risk assessment. As the requirements for security controls change rapidly in response to changes in business initiatives, legislative requirements, customer expectations, and new technology, measurement of security should also distinguish between the effectiveness of existing controls and the capability of the organization to maintain the desired level of security assurance. Each security measure should be assessed in terms of the current effectiveness, and the organization’s ability to maintain that level of effectiveness. Taking the first metric above (resistance to penetration and vulnerability testing) as an example, the capability would be measured in terms of the processes, technology, and resources in place to plan, implement and respond to penetration and vulnerability tests.

  2. Current security capability
    Once the security metrics have been established it is possible to assess the current (point-in-time) security capability of the organization. Each of the measures described above should be applied to the organization to produce a statement of capability. This can serve as the baseline against which enhancements and changes to security can be planned and measured. A sanitized version of this statement of capability could be used to represent capability to customers and business partners.
  3. Current outcomes
    Current outcomes are a measure of the actual security events rather than assurance. Information is collected in regard to actual events impacting on each of the security objectives. For example for the objectives of reducing security events, the current outcomes will be the number of recorded security breaches and the actual costs arising from that event. For the objective of minimizing litigation, the outcome would be the number of litigations raised against the organization and the actual costs arising from such litigation. Some objectives will always be difficult to measure, such as reputation. Customer surveys may indicate levels of satisfaction in existing customers. The current outcomes are used in conjunction with the current capability to define the baseline for security planning.

6 Security vision

The vision is the picture of the future environment, showing how people, process and technology, with work together to overcome constraints and threats, and meet all security objectives. For example, the vision for fulfilling the security objective of reducing risk to litigation (e.g. obligation for due care under company law) will be achieved by establishing comprehensive policy, procedures and training that either reduce events of information disclosure or transfer the responsibility to the individual. For example, the vision for fulfilling the security objective of reducing security events (e.g. in response to increased attacks from the internet and exploitation of vulnerabilities in new technology) will be achieved by a combination of system hardening, segregation of sensitive systems, and enhanced perimeter security that will reduce vulnerabilities to an absolute minimum. Continue the process and create a vision of the future environment that meets all security objectives.

7 Constraints

In addition to the business objectives and initiatives driving security, there is also a range of constraints that inhibit or prevent the achievement of security objectives. These factors may be internal to the organization and controllable, or external and beyond the control of the organization.

  1. External constraints
    • Emerging technology (e.g. wireless networking) creates business opportunities but also brings new vulnerabilities and risks.
    • Legislation (e.g. information privacy) may increase the potential costs arising from exposure of sensitive information and may create new obligations for providing controlled access to information.
    •  Customer requirements (e.g. increased connectivity) may increase vulnerability and complexity in internal systems.
  2. Internal constraints
    • Cost – organizations tend to vary their level of risk acceptance in response to growth or retraction in the market.
    •  Architecture – (e.g. authentication systems) may restrict the use of strong authentication or inhibit adequate monitoring.
    • Culture – organizations with a strong culture of trust may fail to recognize weak security systems. Attitude and awareness play a key role in building effective security.
    • Complexity – organizations that are highly responsive to customer requirements may create solutions with increasing complexity and
      interdependence.

8. Threats and vulnerability

Threats and vulnerability also impact on the organization’s ability to achieve its objectives. Vulnerability is a weakness in a system that can be exploited. A threat is something that may act to exploit the vulnerability. Threats to an organization should be identified and allowed for in setting security objectives. Typical threats include external hackers (script kiddies, criminal, competitors), disgruntled staff and contractors, viruses and other malicious code, and inadvertent action by authorized operators.  Typical vulnerabilities include published system vulnerabilities, poor configuration, inconsistent application of processes and untrained staff. Security strategies must allow for vulnerabilities and threats.

9 Strategies

Strategies are the plans for moving from the current environment towards the vision. Strategies do not have priorities: they are mutually exclusive. A strategy is a direction, plan or approach to achieving the security objectives while allowing for the influence of the constraining factors. Use the business objectives, security objectives, and measures of the current capability to identify security objectives that are not fully met. Create strategies to meet those objectives while allowing for constraints and threats. For example, the business objective is to generate more revenue. The business strategy is to create additional connectivity with customers to provide value-added services. One security objective is to allow the connectivity while mitigating the risk of hacker and virus infiltration to an acceptable level. Another security objective is to ensure that customer expectations for integrity and availability can be met. The vision includes comprehensive perimeter monitoring and access controls. The current capability meets existing needs but will require enhancement to protect new communication channels used to provide the planned increase to connectivity. External constraining factors could include the technology (e.g. inherent weakness in wireless networking), and the obligation to protect customer information that is subject to information privacy legislation. Internal constraining factors could include the complexity of internal systems. Adding new connectivity may require additional resources to cover essential security monitoring. The security strategies might be:

  • to increase monitoring of external connections. This will mitigate some risk associated with increased connectivity.
  • to increase the security “hardening” of all customer-facing systems.
  • to provide redundancy for critical production system components to improve the availability of services.

Continue the process to identify strategies for all security objectives. Each strategy must support at least one objective. In total, all of the strategies must meet all of the objectives. Examine each security objective and ensure that it will be fully achieved if the strategies are fully implemented. If not, further strategies are required.

10 Initiatives

  1. Setting Initiatives
    Initiatives are the operational plans for the implementation of processes, technology and people that achieve the security objectives. Each initiative must support at least one strategy. Initiatives, if fully implemented, should completely achieve the strategy and its objectives. If the initiatives do not meet all of the objectives, further initiatives should be prepared. For example, with a strategy of hardening all customer-facing systems, the initiatives might be:

    • to configure all customer-facing servers in accordance with CIS security benchmarks ;
    • to replace network bridges with switches; relocated inside the organizations trusted network;

    Each initiative must include assessment of the expected benefits (reduction in residual risk), costs (allocation of funding and resources to achieve changes in technology, process, and people), priorities and interdependencies. In the example above, consider if customer-facing systems will be adequately hardened when these initiatives are fully implemented. If there are further measures that can be taken to harden these systems, multiple initiatives should be identified. Multiple initiatives provide further opportunity for senior management to determine the appropriate level of investment and an acceptable risk by choosing between initiatives. Owing to the inter-dependencies between strategies and initiatives, changes to timing or acceptance of one initiative may impact on others. For example delays to virtual private networking may impact on the delivery of a single-sign-on solution using the same infrastructure (directory service and certificate authority). Initiatives can be validated against best-practice. Cost-effective outcomes may be achieved by following the approach other organizations have used in similar situations and leveraging off their experience to avoid costly errors. Continue this process to include initiatives for all security objectives. The strategic security plan should include a summary showing that the initiatives in total meet the strategic objectives, and also produce the future vision as described earlier.

  2. Accountability and governance
    The security function cannot be made responsible for the achievement of business objectives outside of its area of control. For example, a security objective may be to provide certification to international standards so that the business can differentiate services on that basis. The security staff cannot be held accountable for revenue generation: that is the sales team’s responsibility. The security team can be accountable for the achievement of the certification. When completed, the strategic security plan will have input from business areas to ensure alignment with business direction, and input from information technology, legal services, personnel, and other support areas to ensure that the plan is realistic and feasible. Governance of the security process should be included in the organization’s governance process along with risk management. Security reporting should be consistent with risk reporting. The organization’s senior officers will be seeking to demonstrate reasonable care. The question that could be expected might include the following. At this point, the strategic security plan should be able to answer all of these questions except for the question of the appropriate level of investment. This must be answered by senior management. The plan provides the rationale behind each of the strategies and initiatives and allows management to invest in security based on the financial position of the organization and the level of risk considered acceptable by senior management. Senior management will be looking for a comparison of the security in their organization against organizations of similar ilk to validate the strategic plan. An approach to determining the cost of security and comparative industry costs follows.

    • Is Management confident that security is being adequately addressed in the company?
    • What are other people doing and how is the enterprise placed in
      relation to them?
    • Does management have a view on how much the enterprise should invest in IT security improvements?
  3. Cost of security
    The cost models for security are still evolving. Models supported by security consulting firms tend to emphasize operational costs backed up by the potential cost of disastrous events in order to generate sales of security services. Such models may understate the significance of other security objectives such as asset protection or legal risk mitigation. Security costs can be described as being made up of planned costs and potential (risk) costs.
  4. Planned costs
    Planned costs are incurred regardless of the occurrence of actual security events and can be direct or indirect costs. Direct costs are associated with planning, implementing, and operating security functions. This includes salaries, depreciation on security assets, and maintenance and service charges related to the supply of security functions. Indirect costs include the cost of insurance (premiums may vary with the level of security assurance). A strategy showing an increase in planned security spending should demonstrate a reduction in the overall risk profile to the organization, or containment of escalating risk. A reduction in security spending should be reflected in the acceptance of a higher risk profile
  5. Potential Costs
    Potential costs are only incurred if security events occur. Potential costs are tied into the strategy as optional implementation plans. Different implementations have different probabilities and impacts. Senior management can adjust the risk/investment balance by choosing between initiatives. Potential costs need to take into account all of the security objectives and include security events (response and recovery, loss of business, reputation etc), interruption to operations, loss of operational data, exposure of confidential data, contract claims for non-performance, cost of litigation and legal penalties for breach of obligations regarding privacy, copyright, trades practice, company governance, etc.

Example of Objective and plan

Hacking and Unauthorised Interception

Developing an IS Objectives plan
The purpose of an‟ IS Objectives plan‟ is to set out how an intended action will be achieved, who will undertake it and how it will be measured.
Objectives to be achieved

  • Issues to be addressed
    Our current firewalls are old and are insufficient to prevent new threats. “Hacking and Unauthorised Interception‟ – This is the deliberate interception or collection of data or voice traffic on our network. Competitors or thieves seek to gather personal information that enables them to commit fraud. Although we have not detected this happening as yet, it is a real and present concern. The main ways this is done are:

    • External parties gaining access to our IT systems
    • Staff finding ways to access restricted information internally
  • Proposed Actions
    Replace our existing external firewalls with Enterprise-grade products that offer state-full inspection capabilities. The design must contain the most advanced firewall capabilities, including:

    • proxies (including SOCKS)
    • stateful inspection or dynamic packet filtering
    • network address translation
    • virtual private networks
    • Internet Protocol version 6 or other non-Internet Protocol versions 4 protocols
    • network and host intrusion detection technologies
  • External Firewall deployment steps
    Prepare:  Ensure network diagrams are up to date
    Configure:

    1. Select and acquire firewall hardware and software as above
    2. Acquire firewall documentation, training, and support
    3. Install firewall hardware and software
    4. Configure IP routing
    5. Configure firewall packet filtering
    6. Configure firewall logging and alert mechanism

    Test:

    1. Test the firewall system
    2. Install the firewall system
    3. Phase the firewall system into operation
  • Internal Intellectual Property control deployment steps
    Implement internal Intellectual Property Controls based on information signatures.
    Prepare:

    1. Information signatures identification – credit card details, personal information.
    2. Assign approved locations for information types
    3. Approve staff access structure
    4. Select and acquire agents and management application

    Configure:

    1. Implement tracking agents onto PC‟s and servers
    2. Acquire firewall documentation, training, and support
    3. Configure physical server
    4. Configure logging and alert mechanisms

    Test: Test the system
    Deploy: Enable the live the IP system

  • Accountability
    John Bishop IT Manager is responsible for the approval of this plan. Chris Flood, IT Analyst is responsible for plan implementation.
  • Resources and responsibilities
    1. Management will provide a budget (to be set) for the purchase of new Firewalls, the budget is still pending. The objective is on hold.
    2. IT will project manage the process but a specialist supplier will undertake this work.
  • Completion schedule:  Implementation Resource Estimates
    The following rough-order-magnitude timeframes represent the calendar time required by staff/supplier to implement each of the practices described in the “Proposed Actions section‟.

    1. Design the firewall system 3 months
    2. Acquire firewall hardware and software 2 months
    3. Acquire firewall documentation, training, and support 1 month
    4. Install firewall hardware and software 1 month
    5. Configure IP routing 1 week
    6. Configure firewall packet filtering 3 weeks
    7. Configure firewall logging and alert mechanisms 2 weeks
    8. Test the firewall system 2 weeks
    9.  Install the firewall system 1 week
    10.  Phase the firewall/IP system into operation 2-3 months
  • Evaluating results
    1. Internal and external penetration testing (undertaken by a third party) will be undertaken to ensure a successful deployment.
pdf Example of template of Information security objective register and plan

Back to Home Page

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion is also welcome.

 

Advertisements

ISO 27001:2013 Clause 6 Planning

by Pretesh Biswas

An understanding of risk and the application of risk assessment methodology is essential to being able to efficiently and effectively create a secure computing environment. The fundamental precept of information security is to support the mission of the organization. All organizations are exposed to uncertainties, some of which impact the organization in a negative manner. The organization must manage these uncertainties. Managing uncertainties is not an easy task. Limited resources and an ever-changing landscape of threats and vulnerabilities make completely mitigating all risks impossible. Therefore, the organization must have a toolset to assist them in sharing a commonly understood view with IT and business managers concerning the potential impact of various IT security-related threats to the mission. This toolset needs to be consistent, repeatable, cost-effective and reduce risks to a reasonable level. Risk management is nothing new. There are many tools and techniques available for managing organizational risks. There are even a number of tools and techniques that focus on managing risks to information.

6 Planning

6.1 Actions to address risks and opportunities

6.1.1 General

While planning for the information security management system, the organization must consider the internal and external issues as identified in Clause 4.1 (Understanding the organization and its context) and the  requirements of the interested parties relevant to information security referred to in 4.2 (Understanding the needs and expectations of interested parties) to determine its risks and opportunities. The organization must ensure the information security management system can achieve its intended outcomes, prevent, or reduce, undesired effects; and achieve continual improvement. The organization must plan adequate actions to address these risks and opportunities. The organization must also plan to integrate and implement the actions into its information security management system processes and evaluate the effectiveness of these actions.

6.1.2 Information security risk assessment

The organization must define and apply an information security risk assessment process by establishing and maintaining information security risk criteria that include the risk acceptance criteria and criteria for performing information security risk assessments; The organization must ensure that repeated information security risk assessments produce consistent, valid and comparable results. The organization must identify information security risks. The organization must apply the information security risk assessment process to identify risks associated with the loss of confidentiality, integrity, and availability for information within the scope of the information security management system and must identify the risk owners. The organization must analyze information security risks. The organization must assess the potential consequences that would result if the risks identified were to materialize. The organization must also assess the realistic likelihood of the occurrence of the risks identified, and determine the levels of risk. The organization must evaluate information security risks. They must compare the results of risk analysis with the risk criteria established and prioritize the analyzed risks for risk treatment. The organization must retain documented information (keep records) about the information security risk assessment process.

6.1.3 Information security risk treatment

The organization must define and apply an information security risk treatment process. It must select appropriate information security risk treatment options, taking account of the risk assessment results. It must determine all controls that are necessary to implement the information security risk treatment options chosen. The organization can choose to design controls as required or identify them from any source. A comprehensive list of  Control objectives and controls are listed in Annex A of ISO 27001:2015 ( Reference control objectives and controls). While determining controls for the organization, it must verify that no necessary controls have been omitted or overlooked. Control objectives are implicitly included in the controls chosen. The control objectives and controls listed in Annex A are not exhaustive and additional control objectives and controls may be needed. The organization must  produce a Statement of Applicability that contains the necessary controls  and justification for inclusions, whether they are implemented or not, and the justification for exclusions of controls from Annex A. The organization must  formulate an information security risk treatment plan; and obtain risk owners approval of the information security risk treatment plan and acceptance of the residual information security risks. The organization must retain documented information(keep records) about the information security risk treatment process.

What Is Risk With Respect To Information Systems?

ISO 27000 defines Risk as “effect of uncertainty on objectives”, where the effect is a deviation from the expected – positive or negative and  Uncertainty is the state, even partial, of deficiency of information related to understanding or knowledge of, an event, its consequence, or likelihood. Risk is often characterized by reference to potential events and consequences, or a combination of. these, Risk is often expressed in terms of a combination of the consequences of an event including changes in the circumstances and the associated likelihood of occurrence. In the context of information security management systems, information security risks can be expressed as the effect of uncertainty on information security objectives. the information security risk is associated with the potential that threats will exploit vulnerabilities of an information asset or group of information assets and thereby cause harm to an organization

.Risk is the potential harm that may arise from some current process or from some future event. Risk is present in every aspect of our lives and many different disciplines focus on risk as it applies to them. From the IT security perspective, risk management is the process of understanding and responding to factors that may lead to a failure in the confidentiality, integrity or availability of an information system. IT security risk is the harm to a process or the related information resulting from some purposeful or accidental event that negatively impacts the process or the related information. Risk is a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability and the resulting impact of that adverse event on the organization.

Threats

According to ISO 27001, Threats can be defined as “potential cause of an unwanted incident which may result in harm to a system or organization”. It has also be defined as “The potential for a threat source to accidentally trigger or intentionally exploit a specific vulnerability.” Threat source can be defined as “Intent and method targeted at the intentional exploitation of a vulnerability  a situation and method that may accidentally trigger a vulnerability.”
The threat is merely the potential for the exercise of a particular vulnerability. Threats in themselves are not actions. Threats must be coupled with threat-sources to become dangerous. This is an important distinction when assessing and managing risks, since each threat-source may be associated with a different likelihood, which, as will be demonstrated, affects risk assessment and risk management. It is often expedient to incorporate threat sources into threats. The list below shows the example of some of the possible threats to information systems.

Examples of Threats with Threat Sources Taken into Consideration

Vulnerability:

ISO 27001 defines Vulnerability as” weakness of an asset or control that can be exploited by one or more threats.” The vulnerability can also be defined as a flaw or weakness in system security procedures, design, implementation, or internal controls that could be accidentally triggered or intentionally exploited and result in a security breach or a violation of the system’s security policy. The vulnerability can be a flaw or weakness in any aspect of the system. Vulnerabilities are not merely flaws in the technical protections provided by the system. Significant vulnerabilities are often contained in the standard operating procedures that systems administrators perform, the process that the help desk uses to reset passwords or inadequate log review. Another area where vulnerabilities may be identified is at the policy level. For instance, a lack of a clearly defined security testing policy may be directly responsible for the lack of vulnerability scanning. Here are a few examples of vulnerabilities related to contingency planning/ disaster recovery:

  • Not having clearly defined contingency directives and procedures
  • Lack of a clearly defined tested contingency plan
  • The absence of adequate formal contingency training
  • Lack of information (data and operating system) backups
  • Inadequate information system recovery procedures, for all processing areas (including networks)
  • Not having alternate processing or storage sites
  • Not having alternate communication services

How Is Risk Assessed?

The principle reason for managing risk in an organization is to protect the mission and assets of the organization. Therefore, risk management must be a management function rather than a technical function. It is vital to manage risks to systems. Understanding risk, and in particular, understanding the specific risks to a system allow the system owner to protect the information system commensurate with its value to the organization. The fact is that all organizations have limited resources and risk can never be reduced to zero. So, understanding risk, especially the magnitude of the risk, allows organizations to prioritize scarce resources.
Risk is assessed by identifying threats and vulnerabilities, then determining the likelihood and impact of each risk. It’s easy, right? Unfortunately, risk assessment is a complex undertaking, usually based on imperfect information. There are many methodologies aimed at allowing risk assessment to be repeatable and give consistent results. The general process of risk assessment is discussed below.

1 Quantitative Risk Assessment
Quantitative risk assessment draws upon methodologies used by financial institutions and insurance companies. By assigning values to information, systems, business processes, recovery costs, etc., impact, and therefore risk, can be measured in terms of direct and indirect costs. Mathematically, quantitative risk can be expressed as Annualized Loss Expectancy (ALE). ALE is the expected monetary loss that can be expected for an asset due to a risk being realized over a one-year period.

ALE = SLE * ARO

Where:

  • SLE (Single Loss Expectancy) is the value of a single loss of the asset. This may or may not be the entire asset. This is the impact of the loss.
  • ARO (Annualized Rate of Occurrence) is how often the loss occurs. This is the likelihood.

Mathematically, this gets complicated very quickly, involving statistical techniques. While utilizing quantitative risk assessment seems straightforward and logical, there are issues with using this approach with information systems. While the cost of a system may be easy to define, the indirect costs, such as the value of the information, lost production activity and the cost to recover is imperfectly known at best. Moreover, the other major element of risk, likelihood, is often even less perfectly known. For example, what is the likelihood that someone will use social engineering to gain access to a user account on the accounting system?
Therefore, a large margin of error is typically inherent in quantitative risk assessments for information systems. This might not always be the case in the future. As the body of statistical evidence becomes available, trends can be extrapolated on past experience. Insurance companies and financial institutions make excellent use of such statistics to ensure that their quantitative risk assessments are meaningful, repeatable and consistent. Typically, it is not cost-effective to perform a quantitative risk assessment for an IT system, due to the relative difficulty of obtaining accurate and complete information. However, if the information is deemed reliable, a qualitative risk assessment is an extremely powerful tool to communicate risk to all level of management. Quantitative risk measurement is the standard way of measuring risk in many fields, such as insurance, but it is not commonly used to measure risk in information systems. Two of the reasons claimed for this are 1) the difficulties in identifying and assigning a value to assets, and 2) the lack of statistical information that would make it possible to determine the frequency. Thus, most of the risk assessment tools that are used today for information systems are measurements of qualitative risk.

2 Qualitative Risk Assessment
Qualitative risk assessments assume that there is already a great degree of uncertainty in the likelihood and impact values and defines them, and thus risk, in somewhat subjective or qualitative terms. Similar to the issues in quantitative risk assessment, the great difficulty in qualitative risk assessment is defining the likelihood and impact values. Moreover, these values need to be defined in a manner that allows the same scales to be consistently used across multiple risk assessments. The results of qualitative risk assessments are inherently more difficult to concisely communicate to management. Qualitative risk assessments typically give risk results of “High”, “Moderate” and “Low”. However, by providing the impact and likelihood definition tables and the description of the impact, it is possible to adequately communicate the assessment to the organization’s management.

3. Identifying Threats
As was alluded to in the section on threats, both threat-sources and threats must be identified. Threats should include the threat-source to ensure accurate assessment. Some common threat-sources include:

  • Natural Threats—floods, earthquakes, hurricanes
  • Human Threats—threats caused by human beings, including both unintentional (inadvertent data entry) and deliberate actions (network based attacks, virus infection, unauthorized access)
  • Environmental Threats—power failure, pollution, chemicals, water damage

Individuals who understand the organization, industry or type of system (or better yet all three) are key in identifying threats. Once the general list of threats has been compiled, review it with those most knowledgeable about the system, organization or industry to gain a list of threats that applies to the system.
It is valuable to compile a list of threats that are present across the organization and use this list as the basis for all risk management activities. As a major consideration of risk management is to ensure consistency and repeatability, an organizational threat list is invaluable.

 The above Table presents the typical threat agents that can adversely affect the information security of an agency’s information assets. They are categorized into threat groups to enable agencies to consider whether they need to define a risk statement for each individual threat agent, a group of threat agents or a combination of the two. For example, it may be sufficient for an agency to consider the threats from employees and external attackers rather than each type of individual or external organizations threat agents but they may need to consider each type of technical, accidental and natural event.

A threat agent’s motivation may be accelerated or moderated by other factors such as their capability (e.g., equipment, expertise, experience, etc.) and whether there is an opportunity (e.g., the employee has full access to source code or the information system is exposed to the Internet, etc.) for them to exploit vulnerabilities in the agency’s information system or service. Therefore agencies should also consider the factors that may influence a threat agent’s intention to attempt to exploit a vulnerability.

4. Identifying Vulnerabilities
Vulnerabilities can be identified by numerous means. Different risk management schemes offer different methodologies for identifying vulnerabilities. In general, start with commonly available vulnerability lists or control areas. Then, working with the system owners or other individuals with knowledge of the system or organization, start to identify the vulnerabilities that apply to the system. Specific vulnerabilities can be found by reviewing vendor web sites and public vulnerability archives, such as Common Vulnerabilities and Exposures or the National Vulnerability Database. If they exist, previous risk assessments and audit reports are the best places to start. Additionally, while the following tools and techniques are typically used to evaluate the effectiveness of controls, they can also be used to identify vulnerabilities:

  • Vulnerability Scanners – Software that can examine an operating system, network application or code for known flaws by comparing the system (or system responses to known stimuli) to a database of flaw signatures.
  • Penetration Testing – An attempt by human security analysts to exercise threats against the system. This includes operational vulnerabilities, such as social engineering
  • Audit of Operational and Management Controls – A thorough review of operational and management controls by comparing the current documentation to best practices (such as ISO 17799) and by comparing actual practices against current documented processes.

It is invaluable to have a base list of vulnerabilities that are always considered during every risk assessment in the organization. This practice ensures at least a minimum level of consistency between risk assessments. Moreover, vulnerabilities discovered during past assessments of the system should be included in all future assessments. Doing this allows management to understand that past risk management activities have been effective

5.Relating Threats to Vulnerabilities
One of the more difficult activities in the risk management process is to relate a threat to a vulnerability. Nonetheless, establishing these relationships is a mandatory activity, since risk is defined as the exercise of a threat against a vulnerability. This is often called threat-vulnerability (T-V) pairing. Once again, there are many techniques to perform this task. Not every threat-action/threat can be exercised against every vulnerability. For instance, a threat of “flood” obviously applies to a vulnerability of “lack of contingency planning”, but not to a vulnerability of “failure to change default authenticators.” While logically it seems that a standard set of T-V pairs would be widely available and used; there currently is not one readily available. This may be due to the fact that threats and especially vulnerabilities are constantly being discovered and that the T-V pairs would change fairly often. Nonetheless, an organizational standard list of T-V pairs should be established and used as a baseline. Developing the T-V pair list is accomplished by reviewing the vulnerability list and pairing a vulnerability with every threat that applies, then by reviewing the threat list and ensuring that all the vulnerabilities that that threat-action/threat can act against have been identified. For each system, the standard T-V pair list should then be tailored.

 6. Defining Likelihood
Determining likelihood is fairly straightforward. It is the probability that a threat caused by a threat-source will occur against a vulnerability. In order to ensure that risk assessments are consistent, it is an excellent idea to utilize a standard definition of likelihood on all risk assessments. Be very careful in setting up the likelihood definitions.

Sample Likelihood Definitions

The table above shows a qualitative scale that can be used to assess the likelihood of a risk eventuating. As shown in the above Table it is important to define what each rating level means. This ensures that risks can be assessed in a consistent manner by providing workshop participants with a standardized framework for assigning a likelihood rating. Where information is available about the frequency of an incident in the past it should be used to determine the likelihood of the risk eventuating. However, where such information does not exist it does not necessarily mean that the likelihood of the risk eventuating is low. It may merely indicate that there are no controls in place to detect it or that the agency has not previously been exposed to the particular risk. The most important thing is to make sure that the definitions are consistently used, clearly communicated, agreed upon and understood by the team performing the assessment and by organizational management.

7.Defining Impact
In order to ensure repeatability, the impact is best defined in terms of impact upon availability, impact upon integrity and impact upon confidentiality.

Simple Impact Scale

The Figure above (Simple Impact Scale) illustrates a workable approach to evaluating impact by focusing attention on the three aspects of information security. However, in order to be meaningful, reusable and easily communicated, specific ratings should be produced for the entire organization. The figure below (Detailed Impact Scale) shows these specific values.

Detailed Impact Scale

There are advantages and disadvantages to each approach. For example, it is easier to create a simple impact scale. However, simple scales are typically more difficult to use when assessing and rating risks, as workshop participants are more likely to interpret the definitions based on their own experience. Conversely, it requires more effort to define a detailed scale. However, workshop participants are more likely to consistently assess the impact of the identified risks when using a detailed scale, as the descriptions are not so easy to misinterpret. All impacts need to be seen in a business context, and be informed by the business. The effect of a risk event materializing should be assessed using the agency’s approved risk rating scales. If a risk has multiple potential consequences then the impact with the largest effect must be used to rate the risk. However, where multiple consequences for a single risk are assessed at the same level the impact may be evaluated as being higher than the individual impact statements (e.g., a risk that has two moderate impacts might be judged to have a significant impact when they are combined). Rating the impact of a risk should include a consideration of any possible knock-on effects of the consequences of the identified risks, including cascade and cumulative effects.

8 Assessing Risk
Assessing risk is the process of determining the likelihood of the threat being exercised against the vulnerability and the resulting impact from a successful compromise. When assessing likelihood and impact, take the current threat environment and controls into consideration. Likelihood and impact are assessed on the system as it is operating at the time of the assessment. Do not take any planned controls into consideration. 

Risk Matrix

The table above presents a 5×5 matrix for assigning a risk rating to a risk. It is used by mapping the likelihood and impact ratings. The rating is the point where the likelihood and impact ratings intersect.The table below provides an example of risk escalation and reporting table. It defines who must be informed and has the authority to accept risk based on its magnitude.

Risk Escalation and Reporting

Risk Assessment Process

A risk assessment process is designed to enable Organizations to systematically identify, analyze and evaluate the information security risks associated with an information system or service together with the controls required to manage them. The figure below presents the risk management lifecycle

Risk Management Lifecycle

The process has incorporated the Establish Context phase into the risk assessment process. This ensures that risks are analyzed and evaluated within the relevant business context. The output of the risk assessment process is a report that captures the information security risks associated with the information system or service taking into consideration the agency’s business context.

1.Establishing the Context

During a risk assessment, it is essential to establish the business and technical context of the information system being reviewed. Establishing the context ensures that the businesses objectives are captured and that the internal and external factors that influence the risks are considered. It also sets the scope for the rest of the process.
Business Context
Meet with the business owner of the information system to establish the business context. During the meeting the business owner is responsible for identifying and defining the:

  • Information Classification – the official information stored, processed and/or transmitted by the information system must be assigned an official classification based on Security in the Government Sector (SIGS).
  • Business Processes Supported – the business processes and objectives supported by the information system. This should include any secondary, dependent or supporting processes.
  • Users of the System – the different types of users of the information system. This should include the level of privileges they require to perform their duties or to use the system. Users may include business users, operations support staff and external users of services such as members of the public or another agency’s staff.
  • Security and Compliance Requirements – the confidentiality, integrity, availability (CIA) and privacy requirements of the system together with any relevant laws and/or regulations that need to be met by it.
  • Information Protection Priorities – the business owner’s prioritization of the confidentiality, integrity, availability, and privacy of the information stored, processed or transmitted by the information system.

Technical Context
Establish a technical context to provide a basic understanding of the security posture of the information system. A risk assessment may be performed for an information system that is already in production or as part of the development lifecycle of a new information system. The following provides guidance on who should be involved in establishing the technical context:

  • Service Owner – the service owner (or their nominated delegate) is responsible for identifying the components and defining the boundaries of an information system that is the scope of the risk assessment.
  • Enterprise or Solution Architect – the Architect is responsible for identifying the components and defining the boundaries of an information system that is within the scope of the risk assessment.
  • Subject Matter Experts – ICT operations staff responsible for the ongoing support and maintenance of the information system that is within the scope of the risk assessment.

The technical context discussions should focus on identifying the following attributes of the information system to provide an understanding of the overall security profile of the system:

  • Logical Architecture – a system and component level view of the logical architecture of the information system. This should include the security domains where system components are located, the system interfaces and information flows (i.e., where and how data is stored, transmitted and processed).
  • System Components – the hardware and software components that the information system is comprised of. This should include all direct and indirect components including servers, switches, firewalls, operating systems, applications, and databases.

2 Risk Identification

The risk identification phase seeks to create a comprehensive list of events that may prevent, degrade or delay the achievement of the businesses objectives. Comprehensive identification is critical because a risk that is not identified at this stage will not be included in the risk analysis phase. Although there are numerous tools and techniques that can be used to facilitate the identification and analysis of risks it is recommended that a multidisciplinary workshop discussion be used. The workshop should include the business and service owners (or their nominated delegates) and subject matter experts from both the business and ICT. In order to manage risk, the potential threats to the information systems need to be identified. This is achieved by defining risk scenarios. Risk scenarios are methods of determining if any risks exist that could adversely affect the confidentiality, integrity or availability of the information system and therefore affect the business objectives. They generally consist of a threat exploiting a vulnerability resulting in an undesirable outcome.  This approach can ensure that all the possible threats to the information system are considered, whilst ensuring that only those that are applicable are actually assessed.
The following provides an overview of the techniques that should be used to ensure that comprehensive lists of relevant risk are identified:

  • People with appropriate knowledge should be involved in the identification of risks. Discussions must include the business owner and subject matter experts who can provide relevant and up-to-date information during the process; and
  • Group discussions and workshops to facilitate the identification and discussion of the risks that may affect the businesses objectives.

When identifying risk, it is important to clearly describe it so that it can be assessed and evaluated. For example, assessing the likelihood and impact of a risk stated as: “Fraud may occur” is difficult if not impossible. However, assessing the same a risk stated as: “An employee commits fraud resulting in financial loss and reputation damage as fraud detection processes are not robust” is more straightforward. Therefore the description of risks identified should use the following structure (or a variation of it, providing that the three elements are included):

(Uncertain event) occurs, leading to (effect on objectives), as a result of (definite cause).

For example:

  • A hacker gains unauthorized access to information stored in the system by performing a brute force password guessing attack. They use the information to commit identity fraud that leads to an investigation by the Privacy Commissioner, and reputational damage to the Organization. The attack is successful because the system does not enforce strong passwords or account lockout policies and does not log failed login attempts.
  • The loss of a laptop leads to official information being disclosed to an unauthorized party, and reputational damage to the Minister and agency as disk encryption has not been enabled on all laptop devices.

Once the risk description has been defined and documented consideration should be given to the risk drivers. Capturing the risk drivers is useful when identifying and selecting controls to manage the risk. The business and technical context normally inform the risk drivers, for example, a risk may only exist because the information system is Internet-facing. It is important to also note that there may be multiple risk drivers related to risk. The following provides some example risk drivers:

  • The information system is deployed as an Internet-facing service.
  • The information system is an attractive target for criminals/hacktivists.
  • Patches may not be applied in a timely manner.
  • Default accounts/passwords are not changed or removed.
  • User accounts are not disabled or removed in a timely manner when a staff member leaves the  Organization.

Although the risk statement captures the consequences (i.e., the effect on objectives) of the risk eventuating it is useful to document them separately as well. The consequences should be stated in business not technical terms. For example:

  • Reputational damage to the Organization;
  • IN CONFIDENCE information is disclosed to an unauthorized party;
  • Breach of the IT Act 2000;
  • Service delivery is impacted due to a loss of productivity;
  • Loss of confidence in the service by key stakeholders.

3. Risk Analysis

Once the relevant risks have been identified the likelihood and impact of them eventuating must be assessed and rated. Typically the likelihood and impact of a risk eventuating are rated using a qualitative scale.

  1. Impact Assessment
    Assess the impact of the risk eventuating with no controls in place. This will inform the gross risk rating and enable the effectiveness of any current controls that reduce the impact of a risk event that occurs to be assessed. Although there may be multiple impact statements documented for risk, only one impact rating can be assigned to the risk. As a result, the highest-rated impact statement should be used to determine the impact rating of the risk.
  2. Likelihood Assessment
    Assess the likelihood of the risk eventuating with no controls in place. This will inform the gross risk rating and enable the effectiveness of any current controls that reduce the likelihood of a risk event occurring to be assessed. Where historic information is available about the frequency of an incident’s occurrence it should be used to help determine the likelihood of the risk eventuating. However, it must be noted that the absence of such information does not necessarily mean that the likelihood of the risk eventuating is low. It may merely indicate that there are no controls in place to detect that it has occurred.
  3. Risk Rating 
    The risk rating is evaluated using a risk matrix. The risk rating without any controls in place have been assessed is called the gross risk. Typically risks that are assessed as being 1 to 3 on the rating scale without any controls in place are considered acceptable to the business and may not require the implementation of any controls to manage them. However, because the risk is rarely static they should be added to the agency’s risk register so that they can be monitored and re-assessed on a regular basis to ensure that the likelihood and/or impact do not change.

Controls Identification and Assessment
Regardless of whether the risk assessment is being performed for an information system that is in production or as part of the development lifecycle process for a new information system, there will already be controls in place to reduce the likelihood and/or impact of some of the risks that have been identified. A control can reduce the risk by reducing the likelihood of an event, the impact or both. Assessing the effect that the control has on the overall risk leads to determining the residual risk rating. The figure below can be used to identify the effect each type of control has on the likelihood or impact of a risk. Typically deterrent and preventive controls reduce the likelihood of a risk eventuating whereas detective and corrective controls reduce the impact should it eventuate.


Types of controls

The following provides a brief description and some example for each type of control

  • Deterrent Controls – are intended to discourage a potential attacker. For example, establishing an information security policy, a warning message on the login screen, a lock or security cameras.
  • Preventive Controls – are intended to minimize the likelihood of an incident occurring. For example, a user account management process, restricting server room access to authorized personnel, configuring appropriate rules on a firewall or implementing an access control list on a file share.
  • Detective Controls – are intended to identify when an incident has occurred. For example, review of server or firewall security logs or Intrusion Detection System (IDS) alerts.
  • Corrective Controls – are intended to fix information system components after an incident has occurred. For example, data backups, SQL transaction log shipping or business continuity and disaster recovery plans.

It is recommended that a multidisciplinary workshop be used to identify and assess the controls that are currently in place to reduce the likelihood and/or impact of the risks eventuating. The business owner and subject matter experts who can identify and describe the current controls that are in place to manage the identified risks must be involved in assessing their efficacy. Where information is available that provides evidence about the effectiveness of the current controls it should be considered during the controls assessment phase.
During the risk assessment, a control may be identified as being ineffective, not sufficient or simply not relevant to the risk it is supposed to be mitigating. If this is the case, an analysis should be performed to determine whether it should be removed and replaced by another more suitable control or whether it should remain in place and be supplemented with additional controls. The residual risk rating is derived by assessing the effect that the current controls have on the gross risk and using the risk matrix. For example:

  • A risk scenario with likelihood rating of Possible but Unlikely and impact rating of Severe would result in an overall risk rating of 19. A control currently in place is highly effective at reducing the impact of the risk. The impact rating is revised to Moderate with the control in place, therefore the residual risk rating is 9;
  • A risk scenario with a likelihood rating of Possible and an impact rating of Severe would result in an overall risk rating of 22. A control currently in place is effective at reducing the impact of the risk. The impact rating is revised to Significant with the control in place, therefore the residual risk rating is 18; and
  • A risk scenario with a likelihood rating of Almost Certain and an impact rating of Minor would result in an overall risk rating of 16. A control currently in place is very effective at reducing the likelihood of the risk. The likelihood rating is revised to Possible with the control in place; therefore the residual risk rating is 8.

4. Risk Evaluation

Once the risk analysis has been completed the residual risks can be evaluated against the agency’s risk tolerance levels. Risk evaluation seeks to assist the business owner in making decisions on which risks requirements treatment, and the priority for implementing a risk response. Residual risks that are assessed as being between 1 and 3 on the rating scale are generally considered to present an acceptable level of risk to the business and do not require any further evaluation. However, because the risk is rarely static they should be added to the agency’s risk register so that they can be monitored and assessed on a regular basis to ensure that the likelihood and/or impact do not change.
All residual risks that are evaluated as being between 4 and 25 on the rating scale need to be evaluated and prioritized. Typically the higher the risk rating is the higher its priority. However, there may be two or more risks with the same risk rating. If it is not clear which risks have a higher priority the information protection priorities defined by the business owner when establishing the business context for the system should be used to determine the priority for the implementation of additional controls.

Statement of Applicability

Having conducted the risk assessment and taken decisions regarding the treatment of those assessed risks, the results need to be documented. This produces two documents:

  • Statement of Applicability, and
  • Risk Treatment Plan.

The first lists all the controls listed in Annex A of ISO 27001 and documents whether or not they have been applied within the ISMS, and also identifies additional controls that have been applied. The second maps the selected treatments (and the measures by which they are to be implemented) to the specific risks they are intended to address and is, in effect, a control implementation plan. The Statement of Applicability forms the main link between your risk assessment and the information security you have implemented. The purpose of the Statement of Applicability is to document which controls (security measures) from ISO 27001 Annex A (and thereby the ISO 27002 standard for information security) you will implement, the reason they have been chosen – and for those that have not been chosen – the justification for their exclusion. While the standard does not directly specify this, it has become good practice to also include the following in the Statement of Applicability document:

  • The status of implementation for existing controls
  • A link to the control documentation or a brief description of how each control is implemented
  • A cross-reference to the sources of other requirements, necessitating the controls chosen

Thus, by preparing a good quality Statement of Applicability, you will have a thorough and full overview of which controls you need to implement, why they are implemented, how they are implemented, and how well they are implemented. The two primary sources for the Statement of Applicability are the risk assessment and Annex A of the standard (in reality the Table of Contents of the ISO 27002 standard). Other sources are the controls that currently exist in the organization and external security requirement that the organization has to comply with.

Drafting the Statement of Applicability

As the controls are selected, the Statement of Applicability (SOA) can start being drawn up. This SoA is documentation of the decisions reached on each control in light of the risk assessment and is also an explanation or justification of why any controls that are listed in Annex A have not been selected. This exercise, of reviewing the list of controls and documenting the reasons numbering as in Annex A of the Standard and this statement explains which controls have been adopted, and identifies those which have not been adopted and sets out the reasons for these decisions. able to coordinate the implementation of the complete range of information security controls. A separate forum for information security coordination has not been created as it is considered more effective for this to be handled through the management
The Statement of Applicability will also list those additional controls that the organization has determined, following its risk assessment, are necessary to counter specifically identified risks. These controls should be listed, either within those control sections whose objectives are supported by the additional controls, or within additional control sections added after those contained in lSO 27001 Appendix A. These additional controls should adopt the Appendix A numbering scheme. it would also be worth documenting how the additional controls were selected.

Road to Statement of Applicability

1. Identify and Analyse Risks

To ensure that the controls that are implemented reflect the risks that the organization faces, a risk analysis must be undertaken. The risk analysis starts with an identification of the risks. The identification consists of the following activities

  1. Identify the risks associated with the loss of:
    • Confidentiality
    • Integrity
    • Availability
  2. Identify the risk owners. Secondly, the risks must be analyzed and evaluated. The analysis consists of the following activities:
  3. Assess the potential consequences that would result if the risks identified were to materialize
  4.  Assess the realistic likelihood of the occurrence of the risks identified
  5. Determine the levels of risk
  6. Compare the analyzed risks with the organization’s risk acceptance criteria and establish priorities for treatment

Select Controls

Where the analysis has determined that the risks are not acceptable, proper action must be taken. The risk treatment options typically are:

  1. Applying appropriate controls
  2. Knowingly and objectively accepting risks
  3. Avoiding risks, or
  4. Sharing the associated business risks with other parties, e.g. insurers or suppliers

For those risks where the option a) above is chosen, proper controls must be selected. Fortunately, ISO 27002 provides us with a very good catalog of control objectives and controls for the treatment of risks as well as good guidance on how to implement the controls. In addition to the risk analysis, numerous other sources may come into play when you select controls. Other sources may be:

  • Industry-specific regulatory requirements
  • Contractual security requirements
  • Corporate or Group security requirements which a subsidiary must adhere to

It is recommended that if the organization wishes to adhere to ISO 27001, the Statement of Applicability is organized according to ISO 27002 and that the various other security requirements are then mapped into the ISO 27002 framework. The Statement of Applicability should for each chosen control document:

  1. The source of the requirement which has led to the selection of the control
  2. The maturity or level of compliance of the control
  3. A reference to where in the source the need for this control is stated OR The reason that the control has not been selected
  4. A short description of the control or a reference to where the control is described

Analyze Gaps

While this is not a strict requirement of the ISO 27001 standard, it is recommended that once the required controls have been selected, a gap analysis is performed to establish the current state of the implementation of the controls. To ensure the evaluation of the controls is consistent and coherent

1. Writing the Statement of Applicability

After having selected the controls and performed a gap analysis on the selected controls, we now have all the information needed to write the Statement of Applicability itself. It is recommended that a structured tool is used to document the Statement of Applicability. That way, it will be possible to work with the content of the Statement of Applicability and, for instance, sort and filter based on compliance level, the source for requirements and other parameters. Examples of relevant tools to write the Statement of Applicability are spreadsheets, databases, etc. It should be noted, that the Statement of Applicability must not be a one-off exercise, but must be updated when there are changes to the controls, to the compliance level or to the requirements that necessitate the controls.

2. Plan Risk Treatment

As noted in the introduction, the Statement of Applicability is a very central document in the information security management system. After the initial version of the Statement of Applicability has been developed, it will be used both when developing the risk treatment plan and when implementing the controls that have been selected during the ‘Select Controls’ activity. The risk treatment plan could be said to be the organization’s security implementation plan, and the primary goal of the plan is to achieve the organization’s security goals.
When planning the implementation the following factors should be considered:

  1. What will be done?
  2. What resources will be required?
  3. Who will be responsible?
  4. When will it be completed?
  5. How will the results be evaluated?

Another important factor to consider when planning the security implementation is the importance of the controls that are being implemented, so the security activities must be prioritized according to:

  • The consequences associated with the risks
  • The likelihood of the risks
  • Legal and other regulatory requirements

3. Implement Controls

Once the risk treatment planning has been done, the actual security work starts. Depending on how wide the gap is between the actual and the necessary security levels, this might be both work-intensive and time-consuming task. Therefore it is not unusual to see risk treatment plans that stretch several months or even years. During the implementation of the controls, the maturity of the ISMS is improved, and therefore the Statement of Applicability must be updated according to this progress.

4. Maintaining the Statement of Applicability

As noted above, the Statement of Applicability must be continually updated, and previous major updates should be kept so that the improvements in control implementation and compliance can be documented. Also, as the organization’s risk management approach matures, it is likely that recurring risk assessments may result in updates to the overall risk picture and therefore also to the Statement of Applicability. An updated Statement of Applicability is very useful to document the overall implementation level of the ISMS as well as the effectiveness of the controls that have been implemented.

pdf Example of  Statement of Applicability
Example of Template for  Statement of Applicability

Risk Treatment

According to its definition, Risk Treatment is the process of selecting and implementing measures to modify risk. The purpose of assessing risk is to assist management in determining where to direct resources. There are four basic strategies for managing risk: mitigation, transference, acceptance, and avoidance.  For each risk in the risk assessment report, a risk management strategy must be devised that reduces the risk to an acceptable level for an acceptable cost. For each risk management strategy, the cost associated with the strategy and the basic steps for achieving the strategy must also be determined.

1.Mitigation
Mitigation is the most commonly considered risk management strategy. Mitigation involves fixing the flaw or providing some type of compensatory control to reduce the likelihood or impact associated with the flaw. Common mitigation for a technical security flaw is to install a patch provided by the vendor. Sometimes the process of determining mitigation strategies is called control analysis.

2. Transference
Transference is the process of allowing another party to accept the risk on your behalf. This is not widely done for IT systems, but everyone does it all the time in their personal lives. Car, health and life insurance are all ways to transfer risk. In these cases, the risk is transferred from the individual to a pool of insurance holders, including the insurance company. Note that this does not decrease the likelihood or fix any flaws, but it does reduce the overall impact (primarily financial) on the organization.

3.Acceptance
Acceptance is the practice of simply allowing the system to operate with a known risk. Many low risks are simply accepted. Risks that have an extremely high cost to mitigate are also often accepted. Beware of high risks being accepted by management. Ensure that this strategy is in writing and accepted by the manager(s) making the decision. Often risks are accepted that should not have been accepted, and then when the penetration occurs, the IT security personnel are held responsible. Typically, business managers, not IT security personnel, are the ones authorized to accept risk on behalf of an organization.
The measures (i.e. security measurements) can be selected out of sets of security measurements that are used within the Information Security Management System (ISMS) of the organization. At this level, security measurements are verbal descriptions of various security functions that are implemented technically (e.g. Software or Hardware components) or organizationally (e.g. established procedures).

4. Avoidance
Avoidance is the practice of removing the vulnerable aspect of the system or even the system itself. For instance, during a risk assessment, a website was uncovered that let vendors view their invoices, using a vendor ID embedded in the HTML file name as the identification and no authentication or authorization per vendor. When notified about the web pages and the risk to the organization, management decided to remove the web pages and provide vendor invoices via another mechanism. In this case, the risk was avoided by removing the vulnerable web pages

Steps for Risk Treatment

1. Identification of Options

Having identified and evaluated the risks, the next step involves the identification of alternative appropriate actions for managing these risks, the evaluation, and assessment of their results or impact and the specification and implementation of treatment plans. Since identified risks may have varying impact on the organization, not all risks carry the prospect of loss or damage. Opportunities may also arise from the risk identification process, as types of risk with positive impact or outcomes are identified. Management or treatment options for risks expected to have positive outcome include:

  • starting or continuing an activity likely to create or maintain this positive outcome;
  • modifying the likelihood of the risk, to increase possible beneficial outcomes;
  • trying to manipulate possible consequences, to increase the expected gains;
  • sharing the risk with other parties that may contribute by providing additional resources which could increase the likelihood of the opportunity or the expected gains;
  • retaining the residual risk.

Management options for risks having negative outcomes look similar to those for risks with positive ones, although their interpretation and implications are completely different. Such options or alternatives might be:

  • to avoid the risk by deciding to stop, postpone, cancel, divert or continue with an activity that may be the cause for that risk;
  • to modify the likelihood of the risk trying to reduce or eliminate the likelihood of the negative outcomes;
  • to try modifying the consequences in a way that will reduce losses;
  • to share the risk with other parties facing the same risk (insurance arrangements and organizational structures such as partnerships and joint ventures can be used to spread responsibility and liability); (of course one should always keep in mind that if a risk is shared in whole or in part, the organization is acquiring a new risk, i.e. the risk that the organization to which the initial risk has been transferred may not manage this risk effectively.)
  • to retain the risk or its residual risks;
    In general, the cost of managing risk needs to be compared with the benefits obtained or expected. During this process of cost-benefit judgments, the Risk Management context established in the first process (i.e. Definition of Scope and Framework) should be taken into consideration. It is important to consider all direct and indirect costs and benefits whether tangible or intangible and measured in financial or other terms.

More than one option can be considered and adopted either separately or in combination. An example is the effective use of support contracts and specific risk treatments followed by appropriate insurance and other means of risk financing. In the event that available resources (e.g. the budget) for risk treatment are not sufficient, the Risk Management action plan should set the necessary priorities and clearly identify the order in which individual risk treatment actions should be implemented.

2. Development of Action Plan

Treatment plans are necessary in order to describe how the chosen options will be implemented. The treatment plans should be comprehensive and should provide all necessary information about:

  • proposed actions, priorities or time plans,
  • resource requirements,
  • roles and responsibilities of all parties involved in the proposed actions,
  • performance measures,
  • reporting and monitoring requirements.

Action plans should be in line with the values and perceptions of all types of stakeholders (e.g. internal organizational units, outsourcing partner, customers etc.). The better the plans are communicated to the various stakeholders, the easier it will be to obtain the approval of the proposed plans and a commitment to their implementation.

3. Approval of Action Plan

As with all relevant management processes, initial approval is not sufficient to ensure the effective implementation of the process. Top management support is critical throughout the entire life-cycle of the process. For this reason, it is the responsibility of the Risk Management Process Owner to keep the organization’s executive management continuously and properly informed and updated, through comprehensive and regular reporting

4. Implementation of Action Plan

The Risk Management Plan should define how Risk Management is to be conducted throughout the organization. It must be developed in a way that will ensure that Risk Management is embedded in all the organization’s important practices and business processes so that it will become relevant, effective and efficient.
More specifically, Risk Management should be embedded in the policy development process, in business and strategic planning, and in change management processes. It is also likely to be embedded in other plans and processes such as those for asset management, audit, business continuity, environmental management, fraud control, human resources, investment and project management. The Risk Management plan may include specific sections for particular functions, areas, projects, activities or processes. These sections may be separate plans but in all cases, they should be consistent with the organization’s Risk Management strategy (which includes specific RM policies per risk area or risk category). The necessary awareness of and commitment to Risk Management at senior management levels throughout the organization is mission-critical and should receive close attention by:

  • obtaining the active ongoing support of the organization’s directors and senior executives for Risk Management and for the development and implementation of the Risk Management policy and plan;
  • appointing a senior manager to lead and sponsor the initiatives;
  • obtaining the involvement of all senior managers in the execution of the Risk Management plan.

The organization’s board should define, document and approve its policy for managing risk, including objectives and a statement of commitment to Risk Management. The policy may include:

  • the objectives and rationale for managing risk;
  • the links between the policy and the organization’s strategic plans;
  • the extent and types of risk the organization will take and the ways it will balance threats and opportunities;
  • the processes to be used to manage risk;
  • accountabilities for managing particular risks;
  • details of the support and expertise available to assist those involved in managing risks;
  • a statement on how Risk Management performance will be measured and reported;
  • a commitment to the periodic review of the Risk Management system;
  • a statement of commitment to the policy by directors and the organization’s executive.

Publishing and communicating a policy statement of this type demonstrate to the organization’s internal and external environment the commitment of the executive board to Risk Management and clearly specifies roles and accountability on a personal level. The directors and senior executives must be ultimately responsible for managing risk in the organization. All personnel is responsible for managing risks in their areas of control. This may be facilitated by:

  • specifying those accountable for the management of particular risks, for implementing treatment strategies and for the maintenance of  controls;
  • establishing performance measurement and reporting processes;
  • ensuring appropriate levels of recognition, reward, approval, and sanction.

As it becomes apparent, the actual implementation of security measurements for the underlying IT platform is not part of this activity. Rather, the implementation of action plans is concerned with the actions to be performed to reduce the identified risks. The work necessary at the level of the technical implementation of security measures is conducted within the ISMS, that is, outside the Risk Management process. Last but not least, an important responsibility of the top management is to identify requirements and allocate necessary resources for Risk Management. This should include people and skills, processes and procedures, information systems and databases, money and other resources for specific risk treatment activities. The Risk Management plan should also specify how the Risk Management skills of managers and staff will be developed and maintained.

5. Identification of Residual Risks

Residual risk is a risk that remains after Risk Management options have been identified and action plans have been implemented. It also includes all initially unidentified risks as well as all risks previously identified and evaluated but not designated for treatment at that time.
As highlighted in the Controls Identification and Assessment section there are different types of controls that can be implemented to reduce the identified risks to an acceptable level. It is important to ensure that any recommended control will reduce the residual risk. For example, if a risk has a residual risk rating of 15 (i.e., a likelihood of Almost Never and an impact of Severe) recommending a control that reduces the likelihood of the risk eventuating will not reduce the residual risk. However, recommending a control (or a combination of controls) to reduce the impact of the risk eventuating will.

Examples of recommended controls to reduce residual risks to an acceptable level are:

  • Implement appropriate access control lists on shares, folders, and files to ensure only authorized personnel can access information stored within the folders.
  • Review the patch management process to ensure that it includes all operating systems, applications and firmware. Ensure monthly maintenance windows are defined and agreed with the business to ensure that patches are implemented regularly and in a timely manner.
  • Implement additional servers and load balancing hardware to ensure that the service scales to meet the businesses requirements and that it meets the availability requirements in the event of a server failure.
  • Implement an operational procedure to test the restoration of data from the backup media to ensure that critical data can be restored.

It is important for the organization’s management and all other decision-makers to be well informed about the nature and extent of the residual risk. For this purpose, residual risks should always be documented and subjected to regular monitor-and-review procedures.

Communicating Risks and Risk Management Strategies

Risk must also be communicated. Once risk is understood, risks and risk management strategies must be clearly communicated to organizational management in terms easily understandable to organizational management. Managers are used to managing risk, they do it every day. So presenting risk in a way that they will understand is key. Ensure you do not try to use “fear, uncertainty, and doubt.” Instead, present risk in terms of likelihood and impact. The more concrete the terms are, the more likely organizational management will understand and accept the findings and recommendations. There must be a two-way dialogue between the stakeholders with the focus on consultation rather than a one-way information flow. Effective communication between stakeholders is essential to ensure that risks are understood and decisions about risk response selection are appropriate. The perception of risk can vary significantly. Stakeholders are likely to make judgments on the acceptability of the risk-based on their own experience of it, therefore it is important to ensure that their perceptions of the risk, as well as their perceptions of the benefits, are identified and documented and the underlying reasons for their position are clearly understood and addressed. Information about risk may be distributed to a large number of different stakeholders within the agency. To be effective, all information relating to the management of risks should be:

  • Clear and Concise – ensure that the information can be understood by all recipients and does not overwhelm them with extraneous detail;
  • Useful – any communication related to risk must be relevant. Technical information that is too detailed or sent non-technical recipients will likely impede, rather than enable, a clear view of risk;
  • Timely – timely communications enable decisions and actions to be taken at the appropriate time in the risk management process;
  • Targeted – information must be communicated at the right level of aggregation and adapted for the audience to enable informed decisions to be made. However, the aggregation of the information must not hide the root cause of a risk;
  • Controlled – information related to risks should be made available on a need-to-know basis.

Only parties with a genuine need should have access to risk reports, risk management plans, and the risk register. With a quantitative risk assessment methodology, risk management decisions are typically based on comparing the costs of the risk against the costs of risk management strategy. A return on investment (ROI) analysis is a powerful tool to include in the risk assessment report. This is a tool commonly used in business to justify taking or not taking a certain action. Managers are very familiar with using ROI to make decisions. With a qualitative risk assessment methodology, the task is somewhat more difficult. While the cost of the strategies is usually well known, the cost of not implementing the strategies is not, which is why a qualitative and not a quantitative risk assessment was performed. Including a management-friendly description of the impact and likelihood of each risk and risk management strategy is extremely effective. Another effective strategy is showing the residual risk that would be effective after the risk management strategy was enacted.

Sample Risk Management Table

A Plan Of Action & Milestones (POAM) should be part of the risk assessment report presented to management. The POAM is a tool to communicate to management on the proposed and actual completion of the implementation of the risk management strategies. The first step in implementing risk management strategies is to get management to approve the POAM. Afterward, the various individuals and teams report upon their progress. This, in turn, is reported to management and tracked as part of the ongoing process of risk management. The POAM contains the risk, the risk management strategy, the Point Of Contact (POC) responsible for implementing the strategy, the resources required and the various milestones that comprise the implementation. For each milestone, a target completion date and an actual completion date is listed. Note that the POAM is a tool to communicate to management, rather than a project management plan.

Sample PAOM

pdf Example of  Risk Assessment Methodology
pdf Example of a Risk Treatment Plan

Back to Home Page

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion are also welcome.

 

ISO 27001:2013 Clause 5.2 Information security policies

by Pretesh Biswas

Information Security Policies (ISP)  is a set of rules enacted by an organization to ensure that all users or networks of the IT structure within the organization’s domain abide by the prescriptions regarding the security of data stored digitally within the boundaries the organization stretches its authority. An ISP is governing the protection of information, which is one of the many assets a corporation needs to protect.  Putting to work the logical arguments of rationalization, one could say that a policy can be as broad as the creators want it to be: Basically, everything from A to Z in terms of IT security, and even more. Characteristics of good security policies include conciseness, readability, actionability, enforceability, and flexibility. Policies are short and to the point in conveying principles that guide activity within the organization. Policies contain a minimum of specialized vernacular and acronyms; clearly explain any industry-specific terms. Employees at all levels will read the security policies to discern how they should act in the best interest of the organization; therefore, the policy should be actionable at every level of executive strategic planning, management of operations, and actual performance of tasks. The policy must allow for determination of compliance with the policy and enforcement of noncompliance. Moreover, policies should potentially apply to the organization for years and not become outdated with the end of life of any product supporting the policy. Any mention of specific product use is in a standard, not a policy. Explanations on how to use products are in procedures, not in policy.

Review your information security policies on a regular basis, with no more than 12 months from the last review. Define trigger events for a policy review. The first trigger event is the last review plus 12 months. Other trigger events may include a change in the business environment, like a merger, acquisition, or new business venture. Certainly, new legislation or regulatory reform will prompt policy review. Include a statement of review/revision trigger events in the information security policy. A key question is why to capture all this detail in written documentation. Just like a contract, written documentation ensures a meeting of the minds. The organization is working off a common understanding of the expectations (e.g., the SMF interpretation guide) and a common understanding of terms (e.g., organization-specific security glossary or risk management glossary). Moreover, the key point is for the organization to capture the policy, standards, procedures, interpretations, and definitions that ensure these details are not just in the minds of a few individuals. It is possible to have excellent security practices in organizations that do not have a single written procedure. Although the practice is good, it is only as good and as enduring as the individual that practices it. The loss of that individual through retirement, resignation, or being hit by the proverbial bus implies a loss (or at least a degradation) of that excellent practice to the organization. Documentation captures knowledge and promotes the learning organization, where proven good practice by one becomes good practice available to all.

Out of carelessness mostly, many organizations without giving a much thought choose to download IT policy samples from a website and copy/paste this ready-made material in an attempt to readjust somehow their objectives and policy goals to a mould that is usually crude and has to broad-spectrum protection. Understandably, if the fit is not quite right, the dress would eventually slip off. A high-grade ISP can make the difference between a growing business and a successful one. Improved efficiency, increased productivity, clarity of the objectives each entity has, understanding what IT and data should be secured and why identifying the type and levels of security required and defining the applicable information security best practices are enough reasons to back up this statement. To put a period to this topic in simple terms, let’s say that if you want to lead a prosperous company in today’s digital era, you certainly need to have a good information security policy. The initial process in developing an information security policy is to identify which laws, regulations, and information security drivers are applicable to your organization.

  1. Perform a high-level gap analysis of each regulatory requirement and driver that is applicable to determine where policy is needed.
  2. Develop a prioritized action plan that will help you organize your efforts.
  3. Prepare a summary document of the impact that the information security policy or policies will have on the organization. The document should:
    1. Describe the policy
    2. Communicate the reason or business justification for the policy, as well as the risks and negative impact of not implementing the policy
    3. Identify regulatory, technical, cultural, and organizational dependencies for implementation of the policy
    4. Identify milestones and possible roadblocks of implementation, compliance, and enforcement
    5. Identify impacted stakeholders
  4. Develop the policy in collaboration with other key stakeholders at your organization.
  5. Ensure the policy is vetted by impacted subject matter experts and business owners, including information security, legal counsel, human resources, and any other applicable steering committees.
  6. Review resources such as the standards and regulations that address specific requirements (e.g., PCI DSS 3.0, HIPAA, GLBA).
  7. Publish, communicate, train, and implement.

Clause 5.2 Policy

Top management must establish an information security policy that is appropriate to the purpose of the organization and must include information security objectives or provides the framework for setting information security objectives. It must also include a commitment to satisfy applicable requirements related to information security and a commitment to continual improvement of the information security management system. The information security policy should be available as documented information. It must be communicated within the organization and be available to interested parties, as appropriate.

An information security policy is the cornerstone of the information security Management system. It should reflect the organization’s objectives for security and the agreed-upon management strategy for securing information. In order to be useful in providing authority to execute the ISMS, it must also be formally agreed upon by executive management. This means that, in order to compose an information security policy document, an organization has to have well-defined objectives for security and an agreed-upon management strategy for securing information. If there is debate over the content of the policy, then the debate will continue throughout subsequent attempts to enforce it, with the consequence that the information security program itself will be dysfunctional. The Information Security Policy actually serve as the main link between your top management and your information security activities, especially because ISO 27001 requires the management to ensure that ISMS and its objectives are compatible with the strategic direction of the company (clause 5.2 of ISO 27001). The policy is probably the best way to do this. The elements of Information security policies are

1.Purpose

  • To establish a general approach to information security
  • To detect and forestall the compromise of information security such as misuse of data, networks, computer systems, and applications.
  • To protect the reputation of the company with respect to its ethical and legal responsibilities.
  • To observe the rights of the customers; providing effective mechanisms for responding to complaints and queries concerning real or perceived non-compliances with the policy is one way to achieve this objective.

2. Scope
ISP should address all data, programs, systems, facilities, other tech infrastructure, users of technology and third parties in a given organization, without exception.

3. Information security objectives
An organization that strives to compose a working ISP needs to have well-defined objectives concerning security and strategy on which management have reached an agreement. Any existing dissonances in this context may render the information security policy project dysfunctional. The most important thing that a security professional should remember is that his knowing the security management practices would allow him to incorporate them into the documents he is entrusted to draft, and that is a guarantee for completeness, quality, and workability.
Simplification of policy language is one thing that may smooth away the differences and guarantee consensus among management staff. Consequently, ambiguous expressions are to be avoided. Beware also of the correct meaning of terms or common words. For instance, “musts” express negotiability, whereas “shoulds” denote a certain level of discretion. Ideally, the policy should be briefly formulated to the point. Redundancy of the policy’s wording (e.g., pointless repetition in writing) should be avoided as well as it would make documents long-winded and out of sync, with illegibility that encumbers evolution. In the end, tons of details may impede the complete compliance at the policy level. So how management views IT security seems to be one of the first steps when a person intends to enforce new rules in this department. Furthermore, a security professional should make sure that the ISP has an equal institutional gravity as other policies enacted within the corporation. In cases where an organization has sizeable structure, policies may differ and therefore be segregated in order to define the dealings in the intended subset of this organization. Information security is deemed to safeguard three main objectives:

  • Confidentiality – data and information assets must be confined to people authorized to access and not be disclosed to others;
  • Integrity – keeping the data intact, complete and accurate, and IT systems operational;
  • Availability – an objective indicating that information or system is at disposal of authorized users when needed.

4. Authority & Access Control Policy
Typically, a security policy has a hierarchical pattern. It means that inferior staff is usually bound not to share the little amount of information they have unless explicitly authorized. Conversely, a senior manager may have enough authority to make a decision what data can be shared and with whom, which means that they are not tied down by the same information security policy terms. So the logic demands that ISP should address every basic position in the organization with specifications that will clarify their authoritative status.
Policy refinement takes place simultaneously with defining the administrative control, or authority in other words, people in the organization have. In essence, it is the hierarchy-based delegation of control in which one may have authority over his own work, the project manager has authority over project files belonging to a group he is appointed to, and the system administrator has authority solely over system files – a structure reminiscent of the separation of powers doctrine. Obviously, a user may have the “need-to-know” for a particular type of information. Therefore, data must have enough granularity attribute in order to allow the appropriate authorized access. This is the thin line of finding the delicate balance between permitting access to those who need to use the data as part of their job and denying such to unauthorized entities.
Access to company’s network and servers, whether or not in the physical sense of the word, should be via unique logins that require authentication in the form of either password, biometrics, ID cards, or tokens, etc. Monitoring on all systems must be implemented to record login attempts (both successful ones and failures) and exact date and time of logon and logoff.
Speaking of evolution in the previous point – as the IT security program matures, the policy may need updating. While doing so will not necessarily be tantamount to improvement in security, it is nevertheless a sensible recommendation.

5. Classification of Data
Data can have a different value. Gradations in the value index may impose separation and specific handling regimes/procedures for each kind. An information classification system, therefore, may succeed to pay attention to the protection of data that has significant importance for the organization and leave out insignificant information that would otherwise overburden an organization’s resources. A data classification policy may arrange the entire set of information as follows:
a) High-Risk Class – data protected by state and federal legislation (the Data Protection Act, HIPAA, FERPA) as well as financial, payroll, and personnel (privacy requirements) are included here.
b) Confidential Class – the data in this class does not enjoy the privilege of being under the wing of law, but the data owner judges that it should be protected against unauthorized disclosure.
c) Class Public – This information can be freely distributed.
Data owners should determine both the data classification and the exact measures a data custodian needs to take to preserve the integrity in accordance with that level.

6) Data Support & Operations
In this part we could find clauses that stipulate:

  • The regulation of general system mechanisms responsible for data protection
  • The data backup
  • Movement of data

7) Security Awareness Sessions
Sharing IT security policies with staff is a critical step. Making them read and sign to acknowledge a document does not necessarily mean that they are familiar with and understand the new policies. A training session would engage employees in a positive attitude to information security, which will ensure that they get a notion of the procedures and mechanisms in place to protect the data, for instance, levels of confidentiality and data sensitivity issues. Such an awareness training should touch on a broad scope of vital topics: how to collect/use/delete data, maintain data quality, records management, confidentiality, privacy, appropriate utilization of IT systems, correct usage social networking, etc. A small test at the end is perhaps a good idea.

8) Responsibilities, Rights and Duties of Personnel
General considerations in this direction lean towards the responsibility of persons appointed to carry out the implementation, education, incident response, user access reviews, and periodic updates of an ISP. Prevention of theft, information know-how and industrial secrets that could benefit competitors are among the most cited reasons why a business may want to employ an ISP to defend its digital assets and intellectual rights.

8) Reference to Relevant Legislation

10) Other Items that An ISP May Include:
Virus Protection Procedure, Intrusion Detection Procedure, Remote Work Procedure, Technical Guidelines, Audit, Employee Requirements, Consequences for Non-compliance, Disciplinary Actions, Terminated Employees, Physical Security of IT, References to Supporting Documents and so on.

Template for an information security policy

Information security policy
Introduction
[ORGANISATION]’s computer and information systems underpin all [ORGANISATION]’s activities, and are essential to [ENTER MAIN BUSINESS/FUNCTIONAL OBJECTIVES HERE].
The [ORGANISATION] recognizes the need for its members, employees, and visitors to have access to the information they require in order to carry out their work and recognizes the role of information security in enabling this.
Security of information must, therefore, be an integral part of the [ORGANISATION]’s management structure in order to maintain continuity of its business, legal compliance and adhere to the University’s own regulations and policies.
 Purpose
 This information security policy defines the framework within which information security will be managed across the [ORGANISATION] and demonstrates management direction and support for information security throughout the [ORGANISATION]. This policy is the primary policy under which all other technical and security related policies reside. [ENTER ANNEX LINK HERE] provides a list of all other policies and procedures that support this policy.
 Scope
This policy is applicable to and will be communicated to [EXAMPLE: all staff, customer and other relevant parties including senior and junior members, employees, visitors, and contractors]. It covers, but is not limited to, any systems or data attached to the [ORGANISATION]’s computer or telephone networks, any systems supplied by the [ORGANISATION], any communications sent to or from the [ORGANISATION] and any data – which is owned either by the University or the [ORGANISATION] – held on systems external to the [ORGANISATION]’s network.
 Organisation of information security
The [HEAD OF DEPARTMENT] is ultimately responsible for the maintenance of this policy and for compliance within the [ORGANISATION]. This policy has been approved by [SENIOR MANAGEMENT GROUP] and forms part of its policies and procedures. [SENIOR MANAGEMENT GROUP] are responsible for reviewing this policy on an annual basis. They will provide clear direction, visible support and promote information security through appropriate commitment and adequate resourcing. The [INFORMATION SECURITY ROLE] is responsible for the management of information security and, specifically, to provide advice and guidance on the implementation of this policy.
[OPTIONAL DEPENDING ON ORGANISATION SIZE]
The [INFORMATION SECURITY ADVISORY GROUP] comprising representatives from all relevant sections of the [DEPARTMENT/ OTHER UNIT] is responsible for identifying and assessing security requirements and risks. It is the responsibility of all line managers to implement this policy within their area of responsibility and to ensure that all staff for which they are responsible are 1) made fully aware of the policy, and 2) given appropriate support and resources to comply. It is the responsibility of each member of staff to adhere to this policy.
 Policy Statement
 The [ORGANISATION] is committed to protecting the security of its information and information systems. It is also committed to a policy of education, training, and awareness for information security and to ensuring the continued business of the [DEPARTMENT/ other units]. It is the [ORGANISATION]’s policy that the information it manages shall be appropriately secured to protect against breaches of confidentiality, failures of integrity or interruptions to the availability of that information and to ensure appropriate legal, regulatory and contractual compliance. To determine the appropriate level of security control that should be applied to information systems, a process of risk assessment shall be carried out in order to define security requirements and identify the probability and impact of security breaches.
Specialist advice on information security shall be made available throughout the [DEPARTMENT/OTHER UNIT] and advice can be sought via the Organization’s Information Security Team [ADD URL] and/or [ADD ADDITIONAL URLS, if required]. It is the [UNIT NAME]’s policy to report all information or IT security incidents or other suspected breaches of this policy. The [UNIT NAME] will follow the Organization’s advice for the escalation and reporting of security incidents and data breaches that involve personal data will subsequently be reported to the Organization’s Data Protection Officer. Records of the number of security breaches and their type should be kept and reported on a regular basis to the [SENIOR MANAGEMENT GROUP/INFORMATION SECURITY ROLE].
Failure to comply with this policy that occurs as a result of deliberate, malicious or negligent behavior, may result in disciplinary action.

Example of Security Policy

Annex A: Control objectives and control

A.5 Information security policies

A.5.1 Management direction for information security

Objective:
To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations.

A. 5.1.1 Policies for information security

Control
A set of policies for information security should be defined, approved by management, published and communicated to employees and relevant external parties.

At the highest level, organizations should define an “information security policy” which is approved by management and which sets out the organization‘s approach to managing its information security objectives. Information security policies should address requirements created by:

  1. Business strategy;
  2. Regulations, legislation, and contracts;
  3. The current and projected information security threat environment.

The information security policy should contain statements concerning:

  1. Definition of information security, objectives, and principles to guide all activities relating to information security;
  2. Assignment of general and specific responsibilities for information security management to defined roles;.
  3. Processes for handling deviations and exceptions.

At a lower level. the Information security policy should be supported by topic-specific policies. which further mandate the implementation of information security controls and are typically structured to address the needs of certain target groups within an organization or to cover certain topics.
Examples of such policy topics include:

  1. Access control;
  2. Information classification and handling ;
  3. Physical and environmental security;
  4. End user-oriented topics such as:
    1. Acceptable use of assets ;
    2. Clear desk and clear screen;
    3. Information transfer :
    4. Mobile devices and teleworking ;
    5. Restrictions on software installations and use ;
  5. Backup;
  6. Information transfer :
  7. Protection from malware ;
  8. Management of technical vulnerabilities;
  9. Cryptographic controls
  10. Communications security;
  11. Privacy and protection of personally identifiable information:
  12. Supplier relationships.

These policies should be communicated to employees and relevant external parties in a form that is relevant, accessible and understandable to the intended reader. e.g. in the context of an “information security awareness. education and training program”. The need for internal policies for information security varies across organizations. Internal policies are especially useful in larger and more complex organizations where those defining and approving the expected levels of control are segregated from those implementing the controls or in situations where a policy applies to many different people or functions in the organization. Policies for information security can be issued in a single “information security policy” document or as a set of the individual but related documents. If any of the information security policies are distributed outside the organization, care should be taken not to disclose confidential information. Some organizations use other terms for these policy documents, such as ‘Standards’, “Directives” or “Rules”.

A Formal Approach to establish policy

The adoption of one or more information security policies is the first step that organization takes to express their commitment to the protection of their information resources and the information entrusted to them by their and partners. The policy statement should clearly communicate the organization’s beliefs, goals, and objectives for information security.
The information security policy also provides Organization’s leaders with an opportunity to set a clear plan for information security, describe its role in supporting the missions of the organization, and its commitment to comply with relevant laws and regulations. The policy should be brief, clear to understand, enforceable and focused on desired behaviors and outcomes, and most importantly, balanced in affording security while enabling and preserving productivity.
An overarching information security policy document is often (though not always) drafted through a consensus-building process with solicitation and feedback from all identified stakeholders. Once approved and published, its effective communication and periodic reviewing and updating ensure that the policy stated intent and corresponding expectations are consistent and relevant over time to reflect changes in technology, laws, business practices, and other factors.
Prior to starting the policy development process, it is important to understand the difference between policies, procedures, guidelines, and standards. Institutional policies are typically broad, short statements that reflect the philosophies, attitudes, or values of an organization related to a specific issue. Procedures are more detailed and generally mandatory, describing how to accomplish a task or reach a goal. Guidelines sometimes referred to as best practices, contain information about how to accomplish a task or reach a specific goal, but may not be mandatory. Standards establish a rule from a recognized authority, with no deviation allowed.

Difference between Policy standard, Guidelines, Procedure, and checklist.

What’s in a name? We frequently hear people use the names “policy”, “standard”, and “guideline” to refer to documents that fall within the policy infrastructure. So that those who participate in this consensus process can communicate effectively, we’ll use the following definitions.

  • A policy is typically a document that outlines specific requirements or rules that must be met. In the information/network security realm, policies are usually point-specific, covering a single area. For example, an “Acceptable Use” policy would cover the rules and regulations for appropriate use of the computing facilities. Policies are statements that reflect the philosophies, attitudes, or values of an organization related to a specific issue. They are generally represented in a paragraph or perhaps two but not pages. They might say “what” but not “how”. Checklists, procedures, standards, and guidelines all must implement, reflect, and support the applicable policy or policies. The entire set of statements is sometimes considered to be the “Policy.”
  • A standard is typically a collection of system-specific or procedural-specific requirements that must be met by everyone. Standards are statements dictating the state of affairs or action in a particular circumstance. They establish a rule from a recognized authority, with no deviation allowed. For example, you might have a standard that describes how to harden a Windows 8.1 workstation for placement on an external (DMZ) network. People must follow this standard exactly if they wish to install a Windows 8.1 workstation on an external network segment. In addition, a standard can be a technology selection, e.g. Company Name uses Tenable SecurityCenter for continuous monitoring, and supporting policies and procedures define how it is used.
  • A guideline is typically a collection of system-specific or procedural specific “suggestions” for best practice. They are not requirements to be met but are strongly recommended. in other words, they are not mandatory, but a good idea. Effective security policies make frequent references to standards and guidelines that exist within an organization. Guidelines contain information about how to accomplish some task or reach a specific goal.   They may also contain an element of “best practice” — alternate actions might be available and might work, but what is being provided have proven to be the fastest, cheapest, etc. The more explanatory text is usually involved.
  • Procedures contain one or more sentences describing how to accomplish a task or reach a goal – i.e., directive statements. The specified actions are generally mandatory for a specific situation. The more explanatory text is usually involved. A sequence is not necessary but sometimes is important.
  • Checklists contain one or more statements dictating how to accomplish a task – i.e., “commands”. The items are applicable to immediate circumstance and mandatory in that situation. They are typically immediately at hand and written in simple language with no amplifying text. The sequence is always important. Flowcharts are also used as a method for conveying similar information.

Some organization has developed a “policy on policies” that provide an organizational statement and set of procedures about how policies are formatted, who develops them, and how they get approved. The benefit of a formal approach is that it makes policy development consistent and recognizes policy development and policy approval authorities. The formal approach can contain the following stages: 1) identify issues, 2) conduct analysis, 3) draft language, 4) get approvals, 5) determine distribution/education, 6) solicit evaluation and review, and 7) plan measurement and compliance. Stages 1 and 2 are considered “pre-development”. Stages 3-5 are part of “development”. Stages 6 and 7 are “maintenance”.
First, issue identification contains a proactive component and is designed to build upon a security risk analysis, including the identification of existing information or data security policies. Second, the identification of the policy owner, policy path, and team to develop the policy is critical to ensuring the ultimate success of the security policy. There are mixed views about whether or not to include legal counsel as part of the policy drafting team or whether they should be a part of a subsequent review process to determine the legal sufficiency of policy documents. There is a danger that security policy could become too legalistic or written in terms too complex for users or employees. On the other hand, lawyers should be knowledgeable about security requirements under Federal or state law. Third, drafting language and getting approvals is a strategic and political process at most institutions. Because of the urgency of computer and network security for our institutions, it may be more expedient to issue “guidelines” or “interim policies and procedures” to protect assets and ensure legal compliance while using shared governance processes for formal review and adoption of institutional policy. Fourth, increasing education and awareness of security issues and corresponding policies and procedures is critical. A policy that no one knows about or worse yet a policy that is not followed can do more harm than good. Finally, the maintenance stage underscores the importance of regularly evaluating security policies to ensure that they are effective and evolve as technology changes.

Policy Elements

If the goal of institutional policies is to direct individual behavior and guide institutional decisions, then the effectiveness of formal policy statements will depend upon their readability and usefulness. Many organization suffers from the lack of a common and consistent approach or format to writing organizational policies. The outline below suggests some common elements that should be included in any security policies.

  1. Rationale or Purpose. The rationale or purpose statement expresses “why” the policy is being written. The rationale or purpose may also contain or cross-reference “background” materials or more explanatory details regarding legal, regulatory, or other factors that led to the development of the policy.
  2. Policy Statement. The policy statement should be a concise statement of “what” the policy is intended to accomplish. The policy should only be a one or two-sentence description of general organization intent with respect to the specific topic of the policy. The policy statement should be general enough to provide some flexibility and accommodation to periodic changes in technology.
  3. Scope of Policy. The scope of the policy can set important parameters such as to whom will the policy apply (e.g., faculty, staff, customers, vendors, and guests) and to what (e.g., paper and electronic records, information and computer assets, etc.)
  4. Procedures. The procedures will detail “how” the policy statement will be attained. Procedures may include information on how to report computer security incidents. Procedures may also describe enforcement provisions or methods for appeal. Procedures are some times provided in a separate document or left for local determination to provide greater flexibility for updates as well as local control.
  5. Roles and Responsibilities. The procedures may contain details about who is responsible for what. The policy should also identify who is responsible for enforcement or compliance and who will provide interpretations in the event of the need for clarification or when there is a dispute.
  6. Definitions. Policies should be precise and easy to understand. Some times terms will need to be defined to clarify meaning. However, the policy should attempt to convey messages in simple yet precise terms; excessive definitions may make a policy document unreadable or subject it to greater scrutiny.
  7. References. It is possible that there are other policies or organizational documents that complement, supplement, or help explain the provisions contained within the current policy. References to other policies or organizational documents and citations to statutory or regulatory items can improve the usefulness of the policy.
Few Examples of Security policies
pdf Example of Security policy of Punjab State Power Corporation Ltd (PSPCL)
pdf Example of Cyber Security policy of Food Corporation of India (FCI)
pdf Example of Security policy of British Columbia

A. 5.1.2 Review of the policies for information security

Control
The policies for information security should be reviewed at planned intervals or if significant changes occur to ensure their continuing suitability, adequacy, and effectiveness.
Each policy should have an owner who has approved management responsibility for the development, review, and evaluation of the policies. The review should include assessing opportunities for improvement of the organization’s policies and approach to managing information security in response to changes to the organizational environment, business circumstances, legal conditions or technical environment. The review of policies for information security should take the results of management reviews into account. Management approval for a revised policy should be obtained.

If a policy is a statement of intent (according to most definitions), then a policy for information security can be defined as a formal high-level statement that embodies the course of action adopted by an institution regarding the use and safeguarding of institutional information resources. The policy statement should clearly communicate the institution’s beliefs, goals, and objectives for information security.
To be effective an information security policy must:

  • Require compliance (i.e., it should be mandatory to the intended audience)
  • Be implementable (e.g., impact on legacy systems and current infrastructure)
  • Be enforceable. (i.e., failure to comply should result in disciplinary actions)
  • Be brief and easy to understand
  • Balance protection with productivity

Also, the information security policy should:

  • State why the policy is needed (i.e., business reasons)
  • Exemplify the organization’s commitment to information security
  • Express leadership support for the role of information security in the carrying out of the organization’s missions,
  • Focus on desired behaviors (e.g., acceptable use) and outcomes
  • Define roles and responsibilities
  • Outline the standards and procedures to be followed.

A careful balance must be reached to ensure that the policy enhances organizational security by providing enough detail that community members understand their expected role and contribution but not so much detail that the organization is exposed to unnecessary risk.

Policies for Information Security

There are a number of methods that can be used as a foundation for an organization’s information security policy framework.  Choosing the right policy framework is all about what will work best for the organization and its missions. The organization should consider the following when selecting a framework for its information security policy:

  • What works for the Organization?
  • What has not worked before?
  • What fits the organization’s culture?
  • What regulatory requirements must be met?
  • What are the organizational drivers?
  • What future technology is on the organization’s roadmap?
  • What resources (staff, budget, skillsets) are needed to obtain the desired outcomes?

It is important to keep in mind that one of the main goals of an information security policy is to issue directives. The difficult part is deciding on the appropriate level of control to exert. The appropriate level should be informed by the following facts:

  • If policies are too restrictive or hard to implement, people will find ways to circumvent the controls.
  • Technical controls are not always possible or, at times, desirable.
  • Ensure that directives are ‘top-down’—i.e., fully supported by top management.

Organizational Drivers

Since most information security practitioners would agree that it is impossible to protect everything the same way all the time, organizations should identify the business and technical drivers that will guide the creation and implementation of the information security policy as well as assist in its vetting, approval, and socialization. These drivers can be high-level statements that convey the organization’s priorities and direction and help stakeholders make the right decisions regarding what standards to require, what technology to deploy, and how to build the architecture required to implement the policy.
The information security CIA triad exemplifies the highest level driver – to preserve the confidentiality, integrity, and availability of organizational information resources. More specific examples include:

  • Uniquely identify and authenticate all users and entities affiliated with the organization.
  • Provide users the least access required to perform their job function
  • Adopt information security industry standards where appropriate.
  • Implement mitigating controls proactively and based on risk and cost of risk mitigation
  • Identify what information the organization maintains, where is it located, and who owns is responsible for it
  • Classify the organizational data and safeguard it based on risk
  • Balance the business needs to offer and deploy new applications and services against the security risks it might pose to the institution

Review of Information Security Policy

Most organization will have a documented periodic policy review process in place (e.g., annually) to ensure that policies are kept up to date and relevant. In some case, a policy manager would be the individual who would determine the need for a new policy or the update to an existing policy. In a small organization, the role of policy manager may be played by the Business Owner (e.g., the Chief Information Security Officer may be the owner/manager of the information security policy.)

Policy Review and Update Drivers

The information security policy owner or manager will review and update the policy at the required intervals or when external or internal drivers require the review and update of the policy. The following are the most common drivers that would prompt a review of the institution’s information security policy.

  • Changes in Federal or State laws and regulations
  • Changes in technology (e.g., increased use of mobile devices on campus)
  • Major information security project deployments (e.g., deployment of Mobile device Management (MDM)
  • Audit findings
  • Policy format changes (e.g., new policy management function and process)
  • Increased reliance on third-party service providers (e.g., outsourcing, cloud)
  • New business practices (e.g., online education, telecommuting, telemedicine)

Policy Review and Update Process

The process to review and update the information security policy should include the following steps:

  1. Document needed changes
  2. Make changes to a draft version of the policy
  3. Are the changes significant or alter the intent of the original policy?
  4. If Yes, ensure the changes are vetted by impacted subject matter experts and business owners, information security, legal counsel, human resources if applicable, any other applicable steering committee
  5. Publish, communicate, train, and implement

Back to Home Page

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion are also welcome.

ISO 27001:2013 Clause 5 Leadership

by Pretesh Biswas

This clause places requirements on ‘top management’ which is the person or group of people who directs and controls the organization at the highest level. Demonstrating leadership in regard to the ISMS is a core aspect of the IEC 27001 standard. Note that if the organization that is the subject of the ISMS is part of a larger organization, then the term ‘top management’ refers to the smaller organization. The purpose of these requirements is to demonstrate leadership and commitment by leading from the top. A particular responsibility of top management is to establish the information security policy, and the standard defines the characteristics and properties that the policy is to include. Finally, the clause places requirements on top management to assign information security-relevant responsibilities and authorities, highlighting two particular roles concerning ISMS conformance to ISO 27001 and reporting on ISMS performance. It is essential that top management provide the appropriate level of leadership in terms of direction, authority, policy, governance, and organization. Good leadership defines the business purpose of information security, creates the mission statement, sets the strategy, provides staff focus on what is important with regard to the information security for the business and what the priorities are, motivates and inspires confidence and trust in the workforce that it is committed to protecting the business and nurtures security culture and security skills. Good ISMS leadership is needed to build a team that will successfully take forward the implementation of the ISMS, which will empower and motivate staff to be proactive followers and supporters in helping to protect the organization. A good ISMS leader will be passionate about being successful in managing the information security risks the organization faces. ISMS leadership should strive to inspire others to see information security as a business enabler, with the vision of turning information security risks into a business opportunity. Leadership is different than management—the former motivates and inspires, creates the vision and points people in the right direction, while the latter administers, controls and follows the vision and organizes people. Both ISMS leadership and ISMS management together achieve an effective, robust, resilient ISMS. Leadership will be the champion of the ISMS, and management will control and manage the ISMS.

The “Leadership” clause has three sub-clauses ie
Clause 5.1  Leadership and Commitment
Clause 5.2 Policy
Clause 5.3 Organizational roles, responsibilities and authorities.

5.1 Leadership and commitment

Top management must demonstrate leadership and commitment by ensuring the information security policy and the information security objectives are established and are compatible with the strategic direction of the organization. The top Management must ensure the integration of the information security management system requirements into the organization’s processes. The top Management must make available the resources needed for the information security management system. The top management must communicate the importance of effective information security management and of conforming to the information security management system requirements. The top Management must ensure that the information security management system achieves its intended outcome which preserves the confidentiality, integrity, and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed. Top Management must direct and support persons to contribute to the effectiveness of the information security management system. They must also support other relevant management roles to demonstrate their leadership as it applies to their areas of responsibility. They must promote continual improvement. 

The organization’s Top Management must provide leadership and show their support for ISMS. They must demonstrate a commitment to ISMS.  Ensure that ISMS policies are established. Ensure that ISMS objectives are established.  Ensure that ISMS achieves its intended outcomes.  Ensure that ISMS requirements become an integral part of the organization’s processes. Ensure that necessary ISMS resources are available when they are needed. Must communicate a commitment to ISMS.  Make sure that people understand how important information security actually is.  Encourage managers to demonstrate their leadership and commitment to information security within their own areas.

Implementing a Security Strategy

An effective information security strategy for an organization must take into account the overall strategic objectives of the Organization. Even when focusing on critical processes and legal mandates, it is necessary to extend protective measures beyond the underlying IT systems and associated administrative staff. For example, the marketing department has access to customer records, and this access must be considered when assessing the security risks associated with these data. A failure to provide marketing executive with securely configured workstations increases the risk of sensitive data being exposed via their computers. This risk can also be reduced by implementing a middleware solution to properly control which records each executive can access and to minimize the amount of sensitive data stored on their computers. Also, to be effective, security practices cannot rely completely on technological solutions. Continuing the example, policies are required to clearly define each employees responsibilities relating to s data and the security of their workstations. Also, awareness programs aimed specifically at employees and their responsibilities to safeguard information might be developed, possibly in conjunction with the CISO(Chief Information Security Officer)
To complicate matters, the operational needs of the Organization often directly conflict with security practices such as perimeter firewalls, port authentication, centralized configuration management, and strong authentication. Organizational  networks must, therefore, be designed to balance security and privacy requirements while accommodating a wide variety of end-users and their needs – e.g., visitors, new employees arriving with computers, employees sharing large quantities of data with members of the organizations, remote access to a variety of network services for individuals who are traveling or telecommuting, and mobile users moving between classrooms, libraries, and indoor and outdoor study spots on campus. Although firewalls are becoming widely used to protect critical systems on organizations networks, their use at the perimeter is less common because it is difficult to reconcile their restrictiveness with the need for an open networking environment that supports research, learning, and high-speed networking. Although centralized management is feasible for certain hosts on organizations network, this approach is not suitable for most computers and many systems. In the end, security and privacy practices need to be integrated into operational practices in a way that makes the most sense.

Effective Organizational governance of the information security function is critical to a successful program. It can be both the “proof of the pudding…” with regard to management commitment and provide necessary guidance when deciding where to allocate scarce resources. This well-researched section draws from experts in the field and provides useful background and advice which can be adapted to a wide variety of cultures.

Management Policy

The organization must establish an information security policy for the organization. The Top Must ensure that information security policy is appropriate and supports the organization’s purpose. The information security policy must include security objectives or can be used to establish these objectives. The information security policy must make a commitment to comply with all relevant information security requirements. An important aspect of conformance to the requirements of ISO 27001 and of achieving a successful ISMS development and implementation and ongoing management is that such task should be driven and led from the top, by top management. Top management should start by defining an appropriate information security policy for the ISMS. The policy should be a clear management statement of its intentions, objectives, and goals regarding information security and the protection of its information systems. This policy should reflect top management commitment and support for the ISMS to satisfy the requirements in Section 4.1 and address the issues in Section 4.2. It should be a directive from above that typically should address at least the following:

  • The scope of information security, its importance to the business, and clarity about what the business information security objectives are (e.g., regarding the protection of the confidentiality, integrity, and availability of its information);
  • The need for stall awareness: stall should be aware of their duties and responsibilities regarding the risks (e.g., their responsibility to handle and process sensitive company information in a way that protects it from compromise);
  • What is acceptable and not acceptable with regard to behavior and use of its resources (e.g., acceptable use of the company email system);
  • Its obligations to carry out its business in compliance with the laws and regulations, contractual obligations, best practices and standards that stall also need to comply with (e.g., compliance with laws on copyright, data privacy/protection and computer use/misuse/abuse);
  • Reference to any other documents that stall needs to be aware of and comply with (e.g., more detailed security policies and procedures as well as any other relevant proceedings not directly related to security). This could be industry-specific policies such as those businesses that need to deal with environmental issues, aspects of health care, production of pharmaceutical products or food safety.

This management information security policy should be written in a way that the style and content are independent of any particular skill, process or technical knowledge. For example, the content should be understandable by someone that is not an IT specialist, someone not trained in company finances or legal affairs or does not have human resources skills. in other words, it should state information security objectives that are generally understood by all stall not just people with highly technical backgrounds or certain professional qualifications or skills.

Approval, Communication, and Awareness

This management policy needs to be approved and signed by the CEO (or someone of similar management authority and accountable status) since the aim is to indicate management commitment and support. The policy needs to be communicated across the organization to all staff and interested parties. This could be in paper form or by electronic means or both. Some organizations display their policies on the walls of offices, computer rooms, and other areas to ensure they are continually accessible and visible. Other organizations resort to using ICT to distribute and have available their policies and procedures via their internal network. Others may choose to distribute it in paper only for the stall to keep at their own place of work. Whatever the method used, the policy should not be hidden away and forgotten. Stall need to read, understand, and refresh their memories every so often about its contents and what it says about their specific information security responsibilities and duties. This policy needs to be reviewed and updated as necessary to take account of the changing nature of the information security risk environment and evolving organizational developments and changes. There needs to be a review process for maintaining this policy, as is the case with all policies and procedures, as part of the ISMS continual improvement process. This management policy is a high-level policy that “sets the scene,” and typically there will more detailed policies, which will give more specific rules and instructions on the implementation of information security protection. For example, policies on access control cover the rules of access to different organizational resources and facilities such email servers, databases, network services, applications as well as physical access to buildings, offices, rooms, and storage equipment.

5.3 Organizational roles, responsibilities and authorities

Top management must ensure that the responsibilities and authorities for roles relevant to information security are assigned and communicated. Top management must assign the responsibility and authority for ensuring that the information security management system conforms to the requirements of this International Standard, and reporting on the performance of the information security management system to top management.  Top management may also assign responsibilities and authorities for reporting performance of the information security management system within the organization.

Roles and Responsibilities

Involvement from top management is critical to the design and effectiveness of any information security program. The definition of “top management” can vary from organization depending on size and structure, but in general, “top management” should involve members of the senior executive team responsible for making strategic decisions within the organization. The intent of involving top management within the information security program is to ensure that enterprise governance is aligned with the information security governance framework. Components of a well-designed information security governance program include leadership, structure, and processes designed to protect an organization’s information security assets. Effective information security governance requires that top management have clear expectations about what to expect from the information security program, how to evaluate the organization’s risk posture, and how to define information security objectives that are in alignment with the strategic direction and goals of the organization. Top Management must allocate responsibility and authority for carrying out information security roles to the appropriate people within the organization. Top Management must communicate all relevant information security management roles, responsibilities, and authorities. Top management’s involvement with the information security program includes ensuring that the intended outcomes of the information security program are achieved, which could include the following:

  • Alignment with business strategy to meet the organization’s strategic objectives.
  • A risk management program that identifies and mitigates the impacts to an organization’s resources and assets.
  • Effective and efficient resource management
  • Timely and useful metrics reporting
  • Value-added information security initiatives

Security is ultimately the responsibility of all employees within an organization; however, the most successful information security programs demonstrate effective leadership from top management by setting a “tone at the top” and championing the importance of information security through well-designed policy and direction. The result can be an organization with information security ingrained as part of its culture. The ISO 27001 standard requires that organizations demonstrate leadership and commitment from top management as outlined in Clauses 5 (Leadership) and 9.3 (Management review). The focus within Clause 5 is on the design the information security management system (ISMS) which requires involvement from top management and includes the establishment of the information security policy and an organizational structure where the responsibilities and roles relevant to information security are defined and communicated. The focus within Clause 9.3 is to establish procedures for top management to be continually involved in the evaluation of the ISMS to ensure its effectiveness. The members of top management that are involved with the leadership of the ISMS should consider the scope of the ISMS. Involvement from top management can vary by organization, but the scope of the ISMS should be considered when determining who from top management will be involved from a leadership and commitment standpoint. Typically, organizations begin by selecting a committee responsible for overseeing the design, operation, maintenance, and improvement of the ISMS. The committee should include members from top management and members from the information security team.
An organization that is able to successfully implement the requirements of Clause 5 will establish an ISMS program with the oversight, support, and direction of top management; an information security policy that includes information security objectives and is appropriate to the organization; and an organizational structure that incorporates information security with upstream channels so that information security performance is effectively reported to top management. In addition to involving top management in the design of the ISMS, they are required to review and evaluate the performance of the ISMS on a continual basis. The frequent involvement of top management during the evaluation phase of the ISMS is a critical requirement. The intent is to provide regular feedback on the performance of the ISMS so that changes in the environment or processes not performing as expected are identified promptly so that corrective action can be successfully implemented. An organization that can successfully implement the requirements of Clause 9.3 will be able to consistently and continually evaluate the operation of the ISMS, with input from top management to ensure the intent and objectives of the ISMS are being achieved and that the improvements are implemented where necessary.

Day-to-day working and operational activities functioning effectively, and the proper management of staff, at all levels throughout the organization, can contribute to an effective information security business environment. In part, this requires a good information security culture within the organization to be in place, with appropriate awareness and understanding of the problems of information security risks and clear lines of responsibility and accountability. It is essential that roles and responsibilities for protecting specific types of information or information systems or for carrying out specific information security-related processes are clearly defined and allocated. For example:

  • The owner of an information system should be given the information security responsibility and accountability for that system (of course,  these owners may delegate that day-to-day implementation of security to another individual or to a service provider, but they remain ultimately accountable for the protection of the system and the management of the information security risks);
  • Personal data manager;
  • Business owner—a specific department/group (ensures implementation of policy and procedures, defines information usage and classification for information in their custody, allocates information custodians,defines access roles and privileges, conducts staff training and awareness and provides protection of personal data under their control);
  • Chief information security officer (CISO);
  • Information security incident response team;
  • Business continuity manager;
  • Internal auditors;
  • Human resource manager;
  • IT services manager (IT service management, IT disaster recovery, involvement in incident management);
  • IT and network administrators/managers (network management, secure network technologies, involvement in incident management);

Authorized users of information systems. In addition, all staff will have general responsibility for information security related to their day-to-day work. For example, reporting of unusual or suspicious behavior either related to their use of IT, network services or related to other staff or visitors. Also, all individual staff needs to be aware of their responsibility for keeping their passwords and other types of access codes secure, to ensure that they are using organizational resources in accordance with the acceptable usage policy (e.g., rules for using email for sending file attachments).

Resources

As with any successful business venture, it is important to have the right types of resources for the jobs that need to be done. Having stall with the right competence to do a job properly, efficiently and effectively is key to the overall success of the business. If it is a technical job, then the stall involved need to have the right level of knowledge and skill to handle technical requirements of the job at hand, to resolve technical problems and to be able to use techniques, methods, equipment, and procedures relevant to the technical area in question. If it’s a customer service job, then the staff involved must have the relevant skills needed to deal with customers (e.g., they are able to listen and respond effectively to customer’s questions and queries, they are able to satisfactorily resolve customer queries and problems, follow up on feedback from customers and generally be able to meet the expectations of the organization’s customers). Management needs to ensure that for specific information security tasks, it has the right people, with the right skills and knowledge and experience. This can mean recruiting people who have the right existing skills and experience or recruiting people and providing a training program for them to develop the right skills and experience. In addition, all staff working in the field of information security, whether those with experience or those in training, need to keep up to date as the issues and risks in information security continually evolve, as does technology and business practices. Every organization strives to have human resources with certain core competence, and many organizations seek staff with information security skills. The market is expanding, becoming more buoyant and becoming highly competitive. For many years, organizations have recruited information security personnel with hands-on experience, practical knowledge, and appropriate references. Even though this is still the general basis of recruitment, more and more organizations have started to request applicants have market-proven professional qualifications, personal certifications and in some cases university qualifications or a combination of both. The current education and training market provides certified qualifications, for example, in areas such as:

  • information security auditing;
  • information security management;
  • Risk management;
  • Information assurance;
  • Governance
  • IT security;
  • Physical security.

Training and Awareness

The organization needs to ensure that staff are aware of information security risks and have sufficient understanding to support the organization’s information security policy to undertake their normal work functions and tasks. Staff should be trained in the use of information security policies and procedures, security controls applicable to their job function and the correct use of IT (e.g., log in procedures, keeping passwords safe, appropriate use of IT). Training should take place during:

  • Induction training for new staff upon joining the organization. This should cover the company’s information security policies, procedures and routine practices, whom to contact for help and support regarding information security matters and whom to report security problems to, initial familiarization with the common types of risk malware, hacking, protection of commercially sensitive information and the protection of personal data, fraud, use of email and so on.
  • On-the-job training providing specifically tailored instructions on information security suited to the individual’s job function.
  • Annual (or more frequent) refresher training to keep stall up to date with new developments and to provide organization-wide reminders or more immediate remedial training as the result of a security incident or an emerging risk.

An organization can deploy a variety of methods to deliver effective information security awareness and training to its staff. The methods that an organization selects will depend on the business culture and it’s operational needs. Therefore, an information security awareness and training program should be tailored to the specifics of the organization. You should alternate between different methods, perhaps introducing an element of motivational instruction together with practical interactivity.

  • Classroom-based training can be highly interactive—such training can vary from half-day/one-day induction/beginners training course, through to various intermediate/advance three-to-five-day training courses covering a range of specific topics.
  • Computer-based/online web-based training and awareness is a good method for reinforcing information security principles and specific topics. Such training can be delivered as a set of modules, interactive or noninteractive, and be accessible to staff at a time and place convenient to the individual.
  • Seminars, workshops, round-table discussions, and presentations are especially well suited for introducing the new subject matter and for organizations with multiple sites;
  • Videos are also an effective way to provide training on various topics.
  • Posters provide visual reinforcement of information security principles and specific topics.
  • On-the-job/desktop training is available.
  • Internal emails can be used to remind, reinforce and provide updates on organizational policies and procedures.

ISMS-Related Topics

Implementing the requirements of ISO/1EC 27001 covers many different tasks, activities, and processes that need to be carried out, and these are associated with a number of specific topics that information security professionals, practitioners and other staff will need to have knowledge of and develop experience in, depending on their particular job function. For example, an internal ISMS auditor will require knowledge of the auditing process and methods, whereas an ISMS risk manager would need knowledge and skills of the principles of risk management. These include:

  • Principles of risk management
  • Risk assessment;
  • Risk treatment.
  • Information security controls:
  • Generic controls eg, as found in ISO 27002, NIST SP 800 etc;
  • Sector-specific controls eg, as found in ISO 27010, 27011,27015, 27017, 27018, 27019.
  • Performance evaluations:
  • Measuring and monitoring methods and techniques eg, as found in ISO 27004
  • ISMS auditing process and methods (eg., as found in 1S0 19011 and 27007).
  • Certification and auditing
  • Certification eg, as found in ISO 27006, ISO 17021;
  • Auditing (e.g., as found in ISO 27007, ISO 19011).
  • Legislation and regulations related to information security and privacy
  • National and regional laws and directives;
  • Standards covering privacy leg, as found in ISO 29100, 29134, 29190).
  • Other specific security-related processes
  • Incident handling (e.g., as found in ISO 27035, NIST SP 800-61);
  • Business continuity e.g., as found in ISO 22301, ISO 27031
  • Operational resilience e.g., as found in B5 16000.
  • Specific IT security controls and mechanisms
  • Network security (e.g., as found in ISO 27033);
  • Applications security (e.g., as found in ISO 27034);
  • Malware (eg. as found in NIST SP 800-83);
  • Firewalls, IDS, IPS;
  • Access control.

Annex A: Control objectives and control

A.6 Organization of information security

A.6.1 Internal organization

Objective:

To establish a management framework to initiate and control the implementation and operation of information security within the organization.

A.6.1.1 Information security roles and responsibilities
Control
All information security responsibilities should be defined and allocated.
Implementation guidance

Allocation of information security responsibilities should be done in accordance with the information security policies. Responsibilities for the protection of individual assets and for carrying out Specific information security processes should be identified. Responsibilities for information security risk management activities and in particular for acceptance of residual risks should be defined. These responsibilities should be supplemented, where necessary, with more detailed guidance for specific sites and information processing facilities. Local responsibilities for the protection of assets and for carrying out specific security processes should be defined. Individuals with allocated information security responsibilities may delegate security tasks to others. Nevertheless, they remain accountable and should determine that any delegated tasks have been correctly performed. Areas for which individuals are responsible should be stated. In particular, the following should take place:

  1. The assets and information security processes should be identified and defined.

2. The entity responsible for each asset or information security process should be assigned and the details of this responsibility should be documented

3. Authorization levels should be defined and documented

4. To be able to fulfill responsibilities in the information security area the appointed individuals should be competent in the area and be given opportunities to keep up to date with developments

Coordination and oversight of information security aspects of supplier relationships should be identified and documented.

Other information

Many organizations appoint an information security manager to take overall responsibility for the development and implementation of information security and to support the identification of controls. However, responsibility for resourcing and implementing the controls will often remain with individual managers. One common practice is to appoint an owner for each asset who then becomes responsible for its day-to-day protection.

Information security is the responsibility of everyone at the institution. It is important to establish roles and responsibilities for staff, managers, and contractors/vendors so that everyone knows what is expected of them when handling information. Leadership is also very important, and many institutions have at least one person who is primarily responsible for organizing the information security program. Typically this is a Chief Information Security Officer (CISO), Information Security Officer (ISO), Director of Information Security, although the title may vary depending on the Organization. No matter what title is selected, there should be someone at the organization who can provide a high level of decision-making support to leadership when considering information security issues and solutions. It is also important to establish data ownership and data handling roles (e.g., data owners, stewards, custodians, and users). Many institutions formally identify and document these roles within their information security policies and data management frameworks.

A.6.1.2 Segregation of Duties

Control

Conflicting duties and areas of responsibility should be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization’s assets.

Implementation guidance

Care should be taken that no single person can access, modify or use assets without authorization or detection. The initiation of an event should be separated from its authorization. The possibility of collusion should be considered in designing the controls. Small organizations may find segregation of duties difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls such as monitoring of activities, audit trails and management supervision should be considered.

Other Information

Segregation of duties is a method for reducing the risk of accidental or deliberate misuse of an organization’s assets.

Segregation of duties reduces the risk of intentional manipulation or error and increases the element of checking.  Functions that should be separated include those of authorization, execution, custody, and recording and, in the case of a computer-based accounting system, systems development and daily operations. Segregation of duties is the concept of having more than one person required to complete a task. Today’s automated solutions and information and communication technologies allow a few people to handle a great deal of information and processes (e.g., stock exchange operators and air traffic controllers). While this is good to improve productivity, a potential side effect is that these few people may end up gathering excessive knowledge and/or privilege over the operating environment and, in case they are absent or have malicious intent, this can prove to be an unacceptable risk, which must be handled.  This is a best practice, especially in cases where sensitive data is being handled. This is seemingly obvious, but often difficult to do in practice. Essentially try to eliminate processes or situations where someone can access, change or use information assets without detection. For example network access and logging should be conducted by someone different from those authorized to use the data. If in doubt – no-one holds the keys to something from which they could gain.

Segregation of duties is a control put in place by many organizations to mitigate the risk of an insider threat or accidental employee mistakes. Sometimes this isn’t practical or possible, but the institution should be aware of the risks of a single person having too much access. Ideally, critical processes or activities should be split up between multiple people. For example, the initiation of a process, its execution, and authorization should be separated when possible. When this is not possible, monitoring and auditing critical processes are very important. Segregation of duties refers to practices where the knowledge and/or privileges needed to complete a process are broken up and divided among multiple users so that no single one is capable of performing or controlling it by himself.

The main reason to apply segregation of duties is to prevent the perpetration and concealment of fraud and error in the normal course of the activities, since having more than one person to perform a task minimizes the opportunity of wrongdoing and increases the chances to detect it, as well as to detect unintentional errors. Wrongdoing requires three factors to be possible: means, motive, and opportunity. Extremely lean processes increase the risk of wrongdoing by concentrating means and opportunity (access to and privileges over the process). By implementing segregation of duties, an organization minimizes the risk by splitting knowledge and privileges. However, the benefits of segregation of duties to security must be balanced with the increased cost/effort required. By using the ISO 27001 requirements for risk assessment, an organization can identify the most vulnerable and the most mission-critical elements of the business to which segregation of duties will represent real added value to the business and other interested parties.

The principles that can be applicable to segregation of duties are:

  • Sequential separation, when an activity is broken into steps performed by different persons (e.g., solicitation, authorization and implementation of access rights)
  • Individual separation, when at least two persons must approve an activity before it is done (e.g., contractor payment)
  • Spatial separation, when different activities are performed in different locations (e.g., locations to receive and store raw material)
  • Factorial separation, when several factors contribute to activity completion (e.g., two-factor access authentication).
  • These principles can be used in isolation or together, depending upon the security an organization requires to protect its processes.

Segregation can be implemented by:

1.Identification of functions that are indispensable to the organization’s activities, and potentially subject to abuse, considering either business drivers or regulatory compliance (e.g., SOX)

2.Division of the function into separate steps, either considering the knowledge necessary for the function to work or the privileges that enable that function to be abused

3. Definition of one or more segregation principles to be applied to the functions. Examples of functions and segregation principles to be applied are:

    1. authorization function (e.g., two people need to authorize a payment)
    2. documentation function (e.g., one person creates a document and another approves it)
    3. custody of assets (e.g., backup media creation and storage in different sites)
    4. reconciliation or audit (e.g., one person takes inventory and another validates it )

Sometimes the segregation of duties is impractical because the organization is too small to designate functions to different persons. In other cases, breaking down tasks can reduce business efficiency and increase costs, complexity, and staffing requirements. In these situations, compensating controls should be in place to ensure that even without segregation of duties the identified risks are properly handled. Examples of compensating controls are:

1Monitoring activities: these allow activities to be supervised while in progress, as a way to ensure they are being properly performed.

2 Audit trails: these enable the organization to recreate the actual events from the starting point to its current status (e.g., who initiated the event, the time of day and date, etc.).

A.6.1.3 Contact with authorities

Control

Appropriate contacts with relevant authorities should be maintained.

Implementation guidance

Organizations should have procedures in place that specify when and by whom authorities (e.g. law enforcement, regulatory bodies, supervisory authorities) should be contacted and how identified information security incidents should be reported in a timely manner (e.g. if it is suspected that laws may have been broken).

Other Information

Organizations under attack from the Internet may need authorities to take action against the attack source. Maintaining such contacts may be a requirement to support information security incident management or the business continuity and contingency planning process. Contacts with regulatory bodies are also useful to anticipate and prepare for upcoming changes in laws or regulations, which have to be implemented by the organization. Contacts with other authorities include utilities, emergency services, electricity suppliers and health and safety. e.g. fire departments (in connection with business continuity), telecommunication providers (in connection with line routing and availability) and water suppliers (in connection with cooling facilities for types of equipment)

The organization needs to maintain useful contact information with appropriate authorities. Obviously, with more significant organizations, the need for this is greater as the interruption of service to a larger part of the population increases. Particularly relevant to utilities, telecoms, banking organizations and the emergency services (and for smaller companies these might be on your list). Where attacks stem from the internet various authorities and providers may need to be called to action in order to divert /suppress/mitigate the threat. You can’t fix everything, but you can be ready should the need arise. This will help with business continuity and security incident management. A protocol for engagement with law enforcement can be a part of the security incident response plan or a broader crisis management procedure for the organization. The plan should be clear about which situations require working with law enforcement, such as when laws are broken. The plan should also clearly state who contacts authorities and under what circumstances (e.g., when law enforcement should be contacted by the information security officer or safety officer).

6.1.4 Contact with special interest groups

Control

Appropriate contacts with special interest groups or other specialist security forums and professional associations should be maintained.

Implementation guidance

Membership in special interest groups or forums should be considered as a means to:

 1.improve knowledge about best practices and stay up to date with relevant security information;

2.ensure the understanding of the information security environment is current and complete;

3. receive early warnings of alerts, advisories, and patches pertaining to attacks and vulnerabilities;

4. gain access to specialist information security advice;

5. Share and exchange information about new technologies, products, threats or vulnerabilities;

6.provide suitable liaison points when dealing with information security incidents

Other Information

Information sharing agreements can be established to improve cooperation and coordination of security issues. Such agreements should identify requirements for the protection of confidential information.

An Information Security Management System (ISMS) is only as good as its ability to keep up with the requirements of the business and provide adequate protection against the risks the organization is exposed to. To accomplish this, information about the environment must be evaluated constantly, but who will do this? Moreover, where can this information be found? The truth is that no one in your organization, not even dedicated teams, can do that by themselves. With the use of critical information getting broader and broader (e.g., by the use of teleworking, virtual teams, etc.), IT demands became more complex, and ISMS and security needs along with it. This means that the level of effort required to cover information related to every single security aspect of your organization would make the costs prohibitive. But, you still have to monitor this information. So, how to do it? Fortunately, ISO 27001 suggests an alternative: contact with special interest groups, control A.6.1.4 of Annex A of the standard.
In a general way, you can define a special interest group as an association of individuals or organizations with interest in, or acting in a specific area of knowledge, where members cooperate/work to solve problems, produce solutions, and develop knowledge. In our case, this area of knowledge would be information security. examples are manufacturers, specialized forums, and professional associations. The government is another example of a special interest group.
An organization’s ISMS needs to keep up with business requirements and organizational risks. To cover these issues, the A.6.1.4 control from Annex A suggests the following issues for you to identify a special interest group to help you:

  • Best practices adopted by the market: policies, procedures, guidelines, and checklists that you can adapt to your organization’s needs.
  • Market and security trends related to your industry: laws and regulations, customers’ requirements, suppliers situations your organization has to be aware of or comply with.
  • News and alerts about threats, vulnerabilities, attacks, and patches: you need these to check your defenses because it is better to learn from others’ mistakes and misfortunes than your own, isn’t it?
  • News related to new technologies and products: what can you use to improve your security, or to achieve the same level with reduced costs and/or effort?
  • Specialized consultancy: you may not have the expertise, or time, to make the solution or resolve the problem by yourself, so who can help you?
  • Specialized support to handle information security incidents (e.g., other organizations, police, government security agencies, etc.): when you have a problem and need help to resolve it, who can help you?

The government as a special interest group is a unique case, because of its access to additional resources (like police, emergency services, firefighters, etc.), and, depending on the legal requirements of each country, its involvement is mandatory.
Some of these issues you can identify for free (accessing the public content on the Internet, signing up for a regular newsletter, or identifying the person/job title to be in contact with a professional association or state agency), and some you have to pay for (consultant or support services). However, in the latter case, it would be recommended to establish contact with potential suppliers through your procurement process (it is always better to have a previous relationship than to call only in an emergency).
Since the information you will be working with could have a great impact on your ISMS (over management and/or security controls), you should be careful about which special interest groups you interact with, considering:

  • The quality of the information provided: Not all of them have precise or updated information (some only repost news or information from other sources).
  • The availability of the information: what is the update frequency of the information? If the source you use takes too much time to update its info, your organization could be exposed to a problem or risk for a longer period.
  • The legitimacy of the source: Not all of them are authorized representatives of the one responsible for the information (e.g., manufacturers have specific forums to communicate with their clients or to provide patches). Another case is if security peers recognize the group as a reliable source of information.

In the cases where you have to send or receive information, be sure to verify whether there is an agreement about how the shared information will be protected.

Example of Security Roles and Responsibilities of the Postal service

Information security is the individual and collective responsibility of all Postal Service personnel, business partners, and other authorized users. Access to information resources is based on an individual’s roles and responsibilities. Only authorized personnel are approved for access to Postal Service information resources. All information technology managers are responsible for securing the Postal Service computing environment, which includes information resources and infrastructure, by implementing appropriate technical and operational security processes and practices that comply with Postal Service information security policies. All officers, business and line managers, and supervisors, regardless of functional area, are responsible for implementing information security policies. All officers and managers must ensure compliance with information security policies by organizations and information resources under their direction and provide the personnel, financial, and physical resources required to appropriately protect information resources. All Postal Service personnel are responsible for complying with all Postal Service information security policies.

Consolidated Roles and Responsibilities

1) Executive Vice President and Chief Information Officer

The executive vice president and chief information officer (CIO) are responsible for the following:

1.Acting as the senior information technology (IT) decision-maker and corporate change agent to securely integrate the key components of business transformation: technology, processes, and people.

2. Providing advice and assistance to senior managers on information security policy and their compliance-based performance.

3.Promoting the implementation of an information security architecture to mitigate information security-related risk.

4. Promoting the protection of corporate information resources across postal Service organizations and business partners

5. Together with the vice president of the functional business area (data steward) and chief privacy officer (CPO), approving the removal of portable electronic devices or media containing sensitive-enhanced or sensitive information from a Postal Service facility. If this responsibility is delegated, notice to that effect must be writing.

2) Chief Postal Inspector

The chief postal inspector is responsible for the following:

1.Establishing policies, procedures, standards, and requirements for personnel, physical, and environmental security.

2. Approving the identification of sensitive positions.

3. Conducting background investigations and granting personnel clearances.

4. Conducting site security reviews, surveys, and investigations of facilities containing Postal Service computer and telecommunications equipment to evaluate all aspects of physical, environmental, and personnel security.

5.Providing technical guidance on physical and environmental security activities that support information security, such as controlled areas, access lists, physical access control systems, and identification badges; providing protection of workstations, portable devices, and media containing sensitive-enhanced, sensitive, or critical information.

6. Providing security consultation and guidance during system, application, and product development to assure that security concerns are addressed and information and/or evidence that may be needed for an investigation is retained by the information resource.

7. Assisting the manager, Corporate Information Security Officer (CISO), with reviews, as appropriate.

8. Investigating reported security incidents and violations.

9.Conducting revenue/financial investigations including theft, embezzlement, or fraudulent activity.

10. Providing physical protection and containment assistance and investigating information security incidents as appropriate.

11. Funding CISO investigative efforts outside of those normally required.

12. Managing, securing, scanning, and monitoring the Inspection Service’s network and information technology infrastructure.

13. Defining high-risk international destinations where personnel are prohibited from traveling with their standard-issue Postal Service computers and communications equipment (including laptops, notebook computers, external hard drives, Blackberry devices, USB devices, etc.)

14 Providing temporary equipment to use when traveling to high-risk international destinations

3) Vice President, Information Technology

The vice president, IT, is responsible for the following:

1. Sponsoring information security and business continuity management programs and ensuring that financial, personnel, and physical resources are available for completing security and business continuity tasks.

2.Ensuring confidentiality, availability, and integrity of information processed by IT applications.

3. Ensuring compliance with the information security certification and accreditation processes.

4. Together with the vice president of the functional business area, accepting, in writing, residual risks of information resources under their control. The VP IT may delegate this authority to the applicable Business Relationship Management manager. If this authority is delegated, notice to that effect must be in writing. e. Reporting to senior management on the status of an incident with a major IT application.

5. Defining and documenting secure coding best practices.

4)  Manager, Computer Operations

The manager of Computer Operations is responsible for the following:

1. Sponsoring information security and business continuity management programs and ensuring that financial, personnel, and physical resources are available for completing security and business continuity tasks.

2. Ensuring confidentiality, availability, and integrity of information processed at IT sites.

3. Ensuring the protection and secure implementation of the Postal Service IT infrastructure.

4. Supporting information security certification and accreditation processes.

5.  Together with the vice president of the functional business area (data steward) and CPO, approving the removal of portable electronic devices or media containing sensitive-enhanced or sensitive information from an IT facility.

6. Reporting to senior management on the status of an incident at a major IT facility.

7.  Reviewing and utilizing C&A documentation in the IT Artifacts Library.

8. Resolving identified vulnerabilities.

5) Manager, Corporate Information Security Office

The manager, CISO, is responsible for the following:

1. Setting the overall strategic and operational direction of the Postal Service information security program and the program’s implementation strategies.

2. Engaging at any point on any level for issues related to information security that impact the Postal Service.

3. Recommending members to the Information Security Executive Council.

4. Developing and disseminating information security policies, processes, standards, and procedures.

5. Managing the certification and accreditation (C&A) process.

6. Providing guidance on application security, reviewing the C&A documentation package, and accrediting sensitive-enhanced,

7. sensitive, and critical information resources developed for, endorsed by, or operated on behalf of the Postal Service.

8. Managing the Network Connectivity Review Board (NCRB) process.

9. Authorizing temporary access to information resource services.

10. Conducting site security reviews or providing support to the Postal Inspection Service during its site security reviews, as requested.

11. Providing consulting support for securing the network perimeter, infrastructure, integrity controls, asset inventory, identification, authentication, authorization, intrusion detection, penetration testing, and audit logs and for information security architecture, technologies, procedures, and controls.

12. Approving encryption technologies.

13. Providing leadership of the security initiatives for the Enterprise Architecture Forum.

14. Developing and implementing a comprehensive information security training and awareness program that is mandatory for all employees at time of hire and annually thereafter.

15. Serving as the central point of contact for all information security issues and providing overall consultation and advice on information security policies, processes, standards, procedures, requirements,

16. controls, services, and issues.

17. At least semi-annually, assessing the adequacy of information security policy and process to reflect changes to business objectives and the operating environment (including technology infrastructure, threats, vulnerabilities, and risks).

18. At least annually, assessing the adequacy of information security controls and recommending changes as necessary.

19. Establishing evaluation criteria and recommending security hardware, software, and audit tools.

20. Approving the establishment of shared accounts

21. Ensuring compliance to information security policies and standards through inspections, reviews, and evaluations.

22 Providing support to the Office of the Inspector General (OIG) and the Inspection Service during the conduct of investigative activities

23. concerning information security, the computing infrastructure, and network intrusions, as requested.

24. Providing support to the chief postal inspector during the conduct of facility/site security reviews, as requested.

25. Escalating security issues to executive management and promulgating security issues and recommended corrective actions across the Postal Service.

26. Authorizing monitoring and surveillance activities of information resources.

27 Authorizing (in case of threats to the Postal Service infrastructure, network, or operations) appropriate actions that may include viewing and/or disclosing data to protect Postal Service resources or the nation’s communications infrastructure.

28. Confiscating and removing any information resource suspected of inappropriate use or violation of Postal Service information security policies to preserve evidence that might be used in forensic analysis of a security incident.

29 Reviewing and approving information security policy for mail processing equipment/mail-handling equipment (MPE /MHE).

6) Information Security Executive Council

The Information Security Executive Council consists of appropriate Postal Service representatives and serves as a steering committee advising the CISO and promulgating information security throughout the Postal Service.

7) Vice Presidents, Functional Business Areas

The vice presidents of Postal Service functional business areas are responsible for the following:

1. Ensuring resources are available for completing information security tasks.

2. Ensuring the security of all information resources within their organization.

3.  Together with the VP IT, accepting, in writing, residual risks of information resources under their control. The vice presidents of functional business areas may delegate this authority to the applicable executive sponsor. If this authority is delegated, notice to that effect must be in writing.

4. Ensuring that contractual agreements require all suppliers, contractors, vendors, and business partners to adhere to Postal Service information security policies.

5. Together with the CIO and CPO, approving the removal of portable electronic devices or media containing sensitive-enhanced or sensitive information from a Postal Service facility. (If this responsibility is  delegated, the delegation of responsibility must be writing.)

8) Vice President, Engineering

The vice president, Engineering, is responsible for ensuring the security of  information resources used in support of the MPE/MHE environment,  including technology acquisition, development, and maintenance.

9) Vice President, Network Operations

The vice president, Network Operations, is responsible for the security of the  mail and information resources used in support of MPE/MHE strategies and logistics.

10) Officers and Managers

All officers, business and line managers, and supervisors, regardless of functional area, are responsible for the following:

1. Implementing information security policies, ensuring compliance with information security policies by organizations and information resources under their direction, and invoking user sanctions as required.

2. Identifying sensitive information positions in their organizations and ensuring that personnel occupying sensitive positions hold the appropriate level of clearance.

3. Managing access authorizations and documenting information security responsibilities for all personnel under their supervision.

4. Ensuring all personnel under their supervision receive information security training commensurate with their responsibilities upon hire and annually thereafter, and maintaining auditable training records when there isn’t an automated system.

5. Ensuring all personnel under their supervision comply with Postal Service information security policies and procedures.

6. Including employee information security performance in performance evaluations.

7. Supervising information security responsibilities of their onsite contractor personnel.

8. Processing departing personnel appropriately and notifying the appropriate system and database administrators when personnel no longer require access to information resources.

9. Initiating a written request for message data content or Internet usage monitoring and sending it to the CPO for approval.

10. Approving or denying requests, by personnel under their supervision, for access to information resources beyond temporary information resource services and reviewing those access authorizations on a semiannual basis.

11. Ensuring that all hardware and software are obtained in accordance with official Postal Service processes.

12. Protecting information resources and ensuring their availability through business continuity activities including plans, procedures, off-site backups, periodic testing, workarounds, and training/cross-training essential and alternate personnel.

13. Ensuring that personnel under their supervision who remove a portable electronic device or media from a Postal Service facility are aware of their responsibility for its security and have a place to secure the device or media when it is not being used. Ensuring compliance with Postal Service information security policy and procedures.

14. Reporting suspected information security incidents to the Computer Incident Response Team (CIRT) immediately, protecting information resources at risk during security incidents, containing the incident, and following continuity plans for disruptive incidents

11) Executive Sponsors

Executive sponsors, as representatives of the vice president of the functional business area, are the business managers with oversight (e.g., funding, development, production, and maintenance) of the information resource and are responsible for the following:

1. Consulting with the CPO for determining information sensitivity and  Privacy Act applicability.

2. Ensuring a business impact assessment (BIA) is conducted to determine the sensitivity and criticality of each information resource under his or her control and to determine the potential consequences of information resource unavailability.

3. Providing resources to ensure that security requirements are properly addressed and information resources are properly protected.

4. Ensuring completion of a site security review, if the facility hosts an information resource designated as sensitive-enhanced, sensitive, or critical.

5. Ensuring that contract personnel under their supervision comply with Postal Service information security policies and procedures.

6. Ensuring that all information security requirements are included in contracts and strategic alliances.

7. Ensuring compliance with and implementation of the Postal Service privacy policy; data collection, retention, and destruction policies; customer or employee privacy notices; and software licensing.

8. Appointing, in writing, an information systems security representative (ISSR).

9. Ensuring completion of security-related activities throughout the Information resource C&A life cycle.

10. Ensuring that information resources within their purview are capable of enforcing appropriate levels of information security services to ensure data integrity.

11. Preventing residual data from being exposed to unauthorized users as  information resources are released or reallocated.

12. Authorizing access to the information resources under their control and reviewing those access authorizations on a semiannual basis.

13. Maintaining an accurate inventory of Postal Service information resources and coordinating hardware and software upgrades.

14. Ensuring appropriate funding for proposed business partner connectivity, including costs associated with the continued support for the life of the connection.

15. Initiating and complying with the network connectivity request requirements and process as documented in the Information Security Network Connectivity Process.

16. Notifying the NCRB when the business partner trading agreement ends or when network connectivity is no longer required.

17. On a semiannual basis, reviewing and validating business partner connectivity to the Postal Service intranet.

18. Funding application recovery (including but not limited to hardware/  software licenses required, continuity plan development, testing, and maintenance) for applications.

19. If the VP functional business area delegated this authority to the executive sponsor, the executive sponsor will work jointly with the VP IT (or the Business Relationship Management manager if this authority is delegated) to review the C&A documentation package, accept the residual risk to an application, and approve the application for production or return the application to the applicable life cycle phase for rework.

20. Reporting suspected information security incidents to the CIRT immediately, protecting information resources at risk during the security incident, containing the incident, and following continuity plans for disruptive incidents.

21. Coordinating the resolution of identified vulnerabilities with the appropriate IT organization (e.g., Computer Operations, Business Relationship Management, Solutions Development and Support, etc.).

12) Functional System Coordinators

The functional system coordinator (FSC) role is an ad hoc activity assigned by a data steward and is not a position or job function. An FSC has expert knowledge of the information resource and is familiar with the people and levels of access being requested. The FSC role may be required for all information resources registered in eAccess. The FSC role is restricted to Postal Service employees. An FSC is responsible for approving or denying a request based on the role or access level requested. If access to sensitive information is requested, the requestor must have a sensitive clearance. The FSC has the last level of  approval before a request is sent to the log-on administrator to create the account, which will then become active.

13) Business Relationship Management Portfolio Managers

Business Relationship Management portfolio managers are responsible for the following:

1. Supporting the executive sponsor in the development of information resources and the C&A process, including the BIA, risk assessment, and business continuity plans.

2. If an ISSR has not been assigned by the executive sponsor, appointing an ISSR to perform security-related activities.

3. Providing coordination and support to executive sponsors and disaster recovery (DR) service providers for all matters relating to business continuity planning.

4. Reviewing the C&A documentation package and completing a risk mitigation plan for risks identified as high or medium. If a documented high or medium vulnerability will not be mitigated, preparing and signing a Risk Acceptance Letter as part of the C&A process.

5. Business Relationship Management portfolio managers are responsible for the following: If the VP IT delegated this authority to the Business Relationship Management portfolio manager, the Business Relationship Management portfolio managers will work jointly with the vice president of the functional business area (or the executive sponsor, if this authority is delegated) to review the C&A documentation package, accept the residual risk to an information resource, and approve the information resource for production or return the information resource to the applicable life-cycle phase for rework.

6. Ensuring that the information resource is registered in eAccess.

7. Accepting personal accountability for adverse consequences if the information resource was placed in production before the C&A process was completed.

8. Managing projects through their project managers who are responsible for the following:

  1. Developing and maintaining C&A documentation as required.
  2. Incorporating the appropriate security controls in all information resources. Ensuring that the information resource is entered in the Enterprise Information Repository (EIR) and updated as required.
  3. Filing C&A documentation in the IT Artifacts Library and maintaining the hard copies and electronic copies for the appropriate retention periods

9. Notifying the NCRB when the business partner trading agreement ends or when network connectivity is no longer required.

10. On a semiannual basis, reviewing and validating business partner connectivity to the Postal Service intranet.

11. Completing along with their staff the annual C&A training.

12. Resolving identified vulnerabilities.

14) Managers of Information Technology Solution Centers

The managers of Information Technology Solution Centers are responsible for the following:

1. Sponsoring information security and business continuity management programs and ensuring that financial, personnel, and physical resources are available for completing security and business continuity tasks.

2, Ensuring confidentiality, availability, and integrity of data.

3. Ensuring the protection and secure implementation of the Postal Service IT infrastructure.

4. Ensuring compliance with the information security C&A processes.

5. Together with the vice president of the functional business area, accepting, in writing, the residual risk of applications and approving deployment.

6. Together with the vice president of the functional business area, approving the removal of portable electronic devices or media containing sensitive-enhanced or sensitive information from a Postal Service facility. (If this responsibility is delegated, notice to that effect must be writing.)

7. Managing projects through their project managers who are responsible for the following:

  1. Incorporating the appropriate security controls in all information resources.
  2. Notifying the NCRB when the business partner trading agreement ends or when network connectivity is no longer required.
  3. On a semiannual basis, reviewing and validating business partner connectivity to the Postal Service intranet.
  4. Functioning as the incident management team leader for their facility.
  5. Identifying and training key technical personnel to provide support in business continuity planning for their facility, information resources housed in their facility, and the alternate DR facilities.
  6. Resolving identified vulnerabilities.

15) Installation Heads

Installation heads are in charge of Postal Service facilities or organizations, such as areas, districts, Post Offices, mail processing facilities, parts depots, vehicle maintenance facilities, computer service centers, or other installations. Installation heads are responsible for the following:

1. Designating a security control officer (SCO) who is responsible for personnel and physical security at that facility, including the physical protection of computer systems, equipment, and information located therein.

2. Implementing physical and environmental security support for information security, such as the protection of workstations, portable devices, and media containing sensitive-enhanced, sensitive, or critical information.

3. Controlling physical access to the facility, including the establishment and implementation of controlled areas, access lists, physical access control systems, and identification badges.

4. Funding building security equipment and security-related building modifications.

5. Maintaining an accurate inventory of Postal Service information resources at their facilities and implementing appropriate hardware security and configuration management.

6. Maintaining and upgrading all security investigative equipment, as necessary.

7. Ensuring completion of a site security review, providing assistance to the Inspection Service and CISO as required, and accepting site residual risk.

8. Ensuring that the Postal Service security policy, standards, and procedures are followed in all activities related to information resources (including procurement, development, and operation) at their facility.

9. Ensuring that all employees who use or are associated with the information resources in the facility are provided information security training commensurate with their responsibilities and take appropriate action in response to employees who violate established security policy or procedures.

10. Cooperating with the Inspection Service to ensure the physical protection of the network infrastructure located at the facility.

11. Developing, maintaining, and testing:

  1. Workgroup Recovery Plan required for each business function.
  2. Emergency Action Plans required for each facility to ensure personnel are safely evacuated and provides for the protection of the employees.
  3. Incident Management Facility Recovery Plan required for each major IT site.
  4. Disaster Recovery Plan (DRP) (business information systems disaster) documents required for each critical system that supports essential (core) business functions.

12. Implementing and managing the following plans and team members:

  1. Emergency Action Plan.
  2. Incident Management Facility Recovery Plan.
  3. Workgroup Recovery and “Beyond” Continuity of Operations(COOP) Plans.
  4. DRP (business information systems disaster) documents.

13. Reporting information security incidents to the CIRT immediately, containing the incident, following continuity plans for disruptive incidents, and assessing damage caused by the incident.

14. Resolving identified vulnerabilities.

16) Chief Privacy Officer

The CPO is responsible for the following:

1. Developing policy for defining information sensitivity and determining information sensitivity designations.

2. Providing guidance on privacy issues to ensure Postal Service compliance with the Privacy Act, the Freedom of Information Act, Gramm-Leach-Bliley Act, and Children’s Online Privacy Protection Act.

3. Developing privacy compliance standards, customer or employee privacy notices, and customer data collection standards, including cookies and Web-transfer notifications.

4. Developing appropriate data record retention, disposal, and release procedures and standards.

5. Approving requests for message data content or Internet usage monitoring.

6. Consulting on and reviewing the BIA and approving the determination of information sensitivity.

7. Providing guidance throughout the investigation of a mass data compromise relating to the privacy of customer and employee/contractor personal information.

8. Developing communications to transmit to impacted parties to amass data compromise.

17) Inspector General

The inspector general is responsible for the following:

1. Conducting independent financial audits and evaluation of the operation of the Postal Service to ensure that its assets and resources are fully protected.

2, Preventing, detecting, and reporting fraud, waste, and program abuse.

3. Investigating computer intrusions and attacks against Postal Service information resources per agreement with the Inspection Service.

4. Investigating the release or attempted release of malicious code onto Postal Service information resources.

5. Investigating the use of Postal Service information resources to attack external networks.

6. Promoting efficiency in the operation of the Postal Service.

7. Funding CISO investigative efforts outside of those normally required.

8. The manager, Technical Crimes Unit (TCU), is responsible for the following:

  1. Functioning as an ongoing liaison with the CIRT.
  2. Serving as a point of contact between the CIRT and law enforcement agencies.
  3. Conducting criminal investigations of attacks upon Postal Service networks and computers.

18) Manager, Business Continuance Management

The manager, Business Continuance Management, is responsible for the following:

1. Protecting the health and safety of Postal Service employees.

2. Ensuring the continuity of business, expediting recovery from a loss of a single critical system or a major disruption to business functions.

3. Reviewing and assessing Business Continuity Management (BCM) program plans.

4. Defining, planning, developing, implementing, managing, assuring the testing and exercising, and monitoring for compliance of a sustainable BCM program for the Postal Service.

5. Ensuring appropriate Business Continuity Plans (BCPs) are developed, tested, and exercised for business functions and information technology services.

6. Ensuring appropriate DRP documents are developed and business information systems are tested for all critical and business functions and services.

7. Certifying all DRP test and BCP exercise.

8. Developing and implementing lines of communication to the IT organization about BCM matters.

9. Promoting BCM awareness and providing training for Postal Service personnel.

10.Ensuring compliance with BCM and information security policies.

11. Establishing a BCM policy and strategy.

19) Manager, Telecommunications Services

The manager, Telecommunications Services (TS), is responsible for the following:

1. Implementing and maintaining operational information security throughout the network infrastructure including timely security patch management. Critical security patches for PCI-related information resources must be installed within 30 days of release.

2. Recommending and deploying network hardware and software based on the Postal Service security architecture.

3. Operational monitoring and tracking of all physical connections between any component of the Postal Service telecommunications infrastructure and any associated information resource not under Postal Service control.

4.Implementing security controls and processes to safeguard the availability and integrity of the Postal Service intranet including physical access to network infrastructure and the confidentiality of sensitive enhanced and sensitive information.

5.Implementing the network perimeter firewalls, demilitarized zones, secure enclaves, and proxy servers.

6. Designating TS representative to the NCRB.

7.Ensuring secure and appropriate connectivity to the Postal Service intranet.

8. Ensuring network services and protocols used by Postal Service information resources provide the appropriate level of security for the Postal Service intranet and the information transmitted.

9. Implementing secure methods of remote access and appropriate remote access controls.

10. Implementing two-factor authentication and the associated infrastructure for network management.

11. Implementing only Postal Service-approved encryption technology.

12. Implementing appropriate network security administration and managing accounts appropriately.

13. Maintaining the integrity of data and network information resources.

14. Supporting the implementation of approved security incident detection and prevention technologies (e.g., virus scanning, intrusion detection systems, and intrusion prevention systems) throughout the perimeter.

15.Maintaining an accurate inventory of Postal Service network information resources.

16.Monitoring network security alerts and logs and providing network security audit logs to the CISO ISS.

17.Ensuring that recovery plans and sufficient capacity are in place for the recovery of the telecommunications infrastructure for the IT-supported Postal Service sites.

18. Identifying and training key technical personnel to provide support in BCM for information resources housed in IT-supported Postal Service sites.

19. Monitoring network traffic for anomalies, conducting perimeter scanning for viruses, malicious code, and usage of nonstandard network protocols, and immediately reporting suspected information security incidents to the CIRT.

20. Protecting information resources at risk during security incidents (if feasible) and providing support for CIRT incident containment and response.

21. Approving all wireless technology before any implementation activities are initiated.

22. Implementing and managing wireless local area network connectivity.

23. Detecting unauthorized access points.

24. Resolving identified vulnerabilities.

20) Managers Responsible for Computing Operations

The managers responsible for computing operations are responsible for the following:

1. Implementing information security policies, procedures, and standards and ensuring compliance.

2. Coordinating and implementing standard platform configurations based on the Postal Service security architecture.

3. Creating and maintaining a timely patch management process and deploying patches to resources under their control. Critical security patches for PCI-related information resources must be installed within 30 days of release.

4. Maintaining an accurate inventory of Postal Service information resources, tracking and reacting to security vulnerability alerts, coordinating hardware and software upgrades, and maintaining appropriate records.

5. Deploying and maintaining anti-virus software and recognition patterns to scan for malicious code and usage of nonstandard network protocols.

6. Supporting the C&A process for internally managed information resources.

7.  Ensuring that remote access is appropriately managed.

8. Implementing appropriate security administration and ensuring that accounts are managed appropriately.

9. Maintaining the integrity of data and information resources and ensuring the appropriate level of information resource availability.

10. Ensuring the installation of the authorized internal warning banner

11. Disseminating security awareness and warning advisories to local users.

12Reporting suspected information security incidents to the CIRT immediately, protecting information resources at risk during security incidents, implementing containment, and assisting in restoring information resources following an attack.

13. Resolving identified vulnerabilities.

21) Manager, Corporate Information Security Office, Information Systems Security

The manager, CISO ISS is responsible for the following:

1. Determining the requirements and standards for secure enclaves.

2. Assessing information resources to determine the need for placement in a secure enclave.

3. Recommending and approving standard configurations and hardening standards for Postal Service information resources.

4. Approving two-factor authentication (e.g., digital certificates, digital signatures, biometrics, smart cards, and tokens) and the associated infrastructure for network management.

5. Approving and managing intrusion detection systems and intrusion prevention systems.

6. Approving, managing, and ensuring appropriate perimeter penetration testing and network vulnerability scans and testing.

7. Providing support to the OIG during the conduct of investigative activities concerning information security, the computing infrastructures, and network intrusion as requested.

8. Approving the use of networking monitoring tools, except those used by the OIG.

9.  Providing support to the chief postal inspector during his or her conduct of site security reviews as requested.

10. Conducting monitoring and surveillance activities.

11. Collecting, correlating, and reviewing all Postal Service security audit log files and security alerts.

12. Reviewing information security policy and processes for MPE/MHE.

13. Developing and maintaining an information security architecture and coordinating a secure Postal Service computing infrastructure by setting standards and developing the security processes and procedures.

14. Removing network connectivity from any computing device that does not meet the defined operating system and anti-virus software and recognition pattern thresholds.

15. Managing the NCRB to control connectivity to the Postal Service computing infrastructure.

16. Designating the chairperson of the NCRB and additional ISS representatives to the NCRB, as required.

17. The NCRB is responsible for the following:

  1. Managing the Postal Service network connectivity process through the implementation of the Information Security Network Connectivity Process.
  2. Developing system connectivity requirements for Postal Service connections to external systems, externally facing information resources (e.g., FTP servers), and connections via the Internet to Postal Service development, production, and internal networks.
  3. Developing standard connectivity and documentation criteria to expedite approval of connectivity requests without additional board action.
  4. Requesting additional information, security reviews, or audits about proposed or approved connections, if deemed necessary.
  5. Evaluating connectivity and firewall change requests and approving or rejecting them based upon existing policy, best practices, and the level of risk associated with the request.
  6. Consulting with executive sponsors on network information security requirements.
  7. Assisting the requester in identifying alternative solutions for denied requests that are acceptable to the requester and the Postal Service.
  8. Reviewing new information resource, infrastructure, and network connections and their effects on overall Postal Service operations and information security.
  9. Recommending and approving network services and protocols.
  10. Recommending changes to the business partner network. In situations where high-risk factors exist, issuing mitigating requirements for connectivity.

18. Ordering the disabling of an information resource or network connection that does not comply with Postal Service policies, procedures, and standards or which is found to pose a significantly greater risk than when originally assessed.

19, Managing the CIRT to help the Postal Service contain, eradicate, document, and recover following a computer security incident and return to a normal operating state.

20. The CIRT is responsible for the following:

  1. Providing an immediate and effective response to computer security incidents as they occur.
  2. Working with an organization to contain, eradicate, document, and recover following a computer security incident.
  3. Engaging other Postal Service organizations including, but not limited to, the OIG and Inspection Service.
  4. Escalating information security issues to executive management as required.
  5. Conducting a post-incident analysis, where appropriate, and recommending preventive actions.
  6. Maintaining a repository for documenting, analyzing, and tracking Postal Service security incidents until they are closed.
  7. Interfacing with other governmental agencies and private-sector computer incident response centers.
  8. Participating in and providing lesson learned information from information security incidents into ongoing information security awareness and training programs.
  9. Developing and documenting processes for incident reporting and management.
  10. Providing support to the OIG and the Inspection Service, as requested.
  11. Designating an information security policy and process program manager who is responsible for establishing, documenting, and disseminating information security policies, standards, and processes.

22) Managers, Help Desks

The managers, Help Desks, are responsible for the following:

1. Creating the entry for the problem tracking management system for security incidents reported to the Help Desks.

2. Providing technical assistance for responding to suspected virus incidents reported to the Help Desks.

3. Escalating unresolved suspected virus events to the CIRT.

23) Contracting Officers and Contracting Officer Representatives

Contracting officers and contracting officer representatives are responsible for the following:

1. Ensuring that information technology suppliers, contractors, vendors, and business partners are contractually obligated to abide by Postal Service information security policies, standards, and procedures.

2. Thoroughly vetting service providers for PCI services prior to engagement that includes a risk analysis and documentation to reflect due diligence to the PCI assessor.

3. Updating the PCI Program Management Office (PMO) with status information on service providers for the PCI environment.

4. Verifying that information technology suppliers, vendors, and business partners responsible for storing, processing, or transmitting Postal Service payment card information complete an annual Letter of Attestation providing an acknowledgement of their responsibility for the security of payment card data, under the current PCI DSS.

5. Monitoring service provider PCI compliance at least annually.

6. Verifying that all contracts and business agreements requiring access to Postal Service information resources identify sensitive positions, specify the clearance levels required for the work, and address appropriate security requirements.

7. Verifying that contracts and business agreements allow monitoring and auditing of any information resource project.

8. Verifying that the security provisions of the contract and business agreements are met.

9.Confirming the employment status and clearance of all contractors who request access to information resources.

10. Verifying all account references, building access, and other privileges are removed for contractor personnel when they are transferred or terminated.

11. Notifying the CIRT of any security breaches reported to them by the service providers.

24) General Counsel

The general counsel is responsible for the following:

1. Ensuring that information technology contractors, vendors, and business partners are contractually obligated to abide by Postal Service information security policies, standards, and procedures.

2. Ensuring that contracts and agreements allow monitoring and auditing of Postal Service information resource projects.

25) Business Partners

Business partners may request connectivity to Postal Service network  facilities for legitimate business needs. Business partners requesting or using connectivity to Postal Service network facilities are responsible for the following:

1. Initiating a request for connectivity to the Postal Service executive who sponsors the request.

2. Complying with Postal Service network connectivity request requirements and process.

3. Abiding by Postal Service information security policies regardless of where the systems are located or who operates them. This also includes strategic alliances.

4. Protecting information resources at risk during security incidents, if feasible.

5.  Reporting information security incidents immediately to the CIRT, the executive sponsor, and the information systems security officer (ISSO) assigned to their project.

6. Taking action, as directed by the CIRT, to eradicate the incident, recover from it, and document actions regarding the security incident.

7. Allowing site security reviews by the Postal Inspection Service and CISO.

8.  Allowing audits by the OIG.

26) Accreditor

The manager, CISO, functions as the accreditor and is responsible for the following:

1. Reviewing the risk mitigation plan and supporting C&A documentation package together with business requirements and relevant Postal Service issues.

2. Escalating security concerns or preparing and signing an accreditation letter that makes one of the following recommendations: accepting the information resource with its existing information security controls, requiring additional security controls with a timeline to implement, or deferring deployment until information security requirements can be met.

3. Forwarding the accreditation letter and C&A documentation package to the Business Relationship Management manager and executive sponsor.

27) Certifier

The manager, Security Certification and Accreditation Process, who is appointed by the manager, CISO, functions as the certifier and is responsible for the following:

1. Managing and providing guidance to the ISSOs.

2. Reviewing the C&A evaluation report and the supporting C&A documentation package.

3. Escalating security concerns or preparing and signing a certification letter.

4.  Forwarding the certification letter and C&A documentation package to the accreditor.

5. Maintaining an inventory of all information resources that have completed the C&A process.

28) Security Control Officers

SCOs ensure the general security of the facilities to which they are appointed, including the safety of on-duty personnel and the security of mail,  Postal Service funds, property, and records entrusted to them . SCOs are responsible for the following:

1. Establishing and maintaining overall physical and environmental security at the facility, with technical guidance from the Inspection Service.

2. Establishing controlled areas within the facility, where required, to protect information resources designated as sensitive-enhanced, sensitive, or critical.

3.  Establishing and maintaining access control lists of people who are authorized access to specific controlled areas within the facility.

4. Ensuring positive identification and control of all personnel and visitors in the facility.

5. Ensuring the protection of servers, workstations, portable devices, and information located at the facility.

6. Consulting on the facility COOP plans.

7. Conducting annual facility security reviews using the site security survey provided by the Inspection Service.

8. Reporting suspected information security incidents to the CIRT and providing support for incident containment and response, as requested.

9. Responding to physical security incidents and reporting physical security incidents to the Inspection Service.

10. Interfacing with CIRT, Inspection Service, CISO, or OIG, as required.

29) Information Systems Security Representatives

ISSRs are appointed in writing by the executive sponsors or the Business Relationship Management portfolio manager and are members of the information resource development or integration teams. The role of the ISSR can be performed in conjunction with other assigned duties. If an ISSR is not assigned, the project manager assumes the role. ISSRs are responsible for the following:

1.Providing support to the executive sponsor and Business Relationship Management portfolio manager, as required.

2. Promoting information security awareness on the project team.

3. Ensuring security controls and processes are implemented.

4. Notifying the executive sponsor, Business Relationship Management portfolio manager, and ISSO of any additional security risks or concerns that emerge during development or acquisition of the information resource.

5. Developing or reviewing security-related documents required by the C&A process as assigned by the executive sponsor or Business Relationship Management portfolio manager.

6. Working with the ISSO to complete the eC&A artifacts in the eC&A system and sending other required artifacts (e.g., TAD, operational training, etc.) or their location (i.e., URL) to the ISSO.

30) Information Systems Security Officers

ISSOs are responsible for the following:

1. Chairing the C&A team.

2. Ensuring that a BIA is completed for each information resource.

3. Ensuring that the responsible project manager records the sensitivity and criticality designations in EIR.

4. Advising and consulting with executive sponsors, Business Relationship Management portfolio managers, and ISSRs during the BIA process so they know the background for

  1. baseline security requirements that apply to all information resources and
  2. Recommending security requirements to executive sponsors and Business Relationship Management portfolio managers during the BIA process, based on generally accepted industry practices and the risks associated with the information resource.

5. Providing guidance on how information resources are vulnerable to threats, what controls and countermeasures are appropriate, and the C&A process.

6. Conducting site security reviews or helping the Inspection Service conduct them.

7. Reviewing the C&A documentation package.

8. Preparing and signing the C&A evaluation report and forwarding the evaluation report and C&A documentation to the certifier.

31) System and Network Administrators

System and network administrators are technical personnel who serve as computer systems, network, server, and firewall administrators, whether the system management function is centralized, distributed, subcontracted, or outsourced. System and network administrators are responsible for the following:

1.Implementing information security policies and procedures for all information resources under their control, and also for monitoring the implementation for proper functioning of security mechanisms.

2. Implementing appropriate platform security based on the platform specific hardening standards for the information resources under their control.

3. Complying with standard configuration settings, services, protocols, and change control procedures.

4. Applying approved patches and modifications in accordance with policies and procedures established by the Postal Service. Ensuring that security patches and bug fixes are kept current for resources under their control.

5. Implementing appropriate security administration and ensuring that log-on IDs are unique.

6. Setting up and managing accounts for information resources under their control in accordance with policies and procedures established by the Postal Service.

7. Disabling accounts of personnel whose employment has been terminated, who have been transferred, or whose accounts have been inactive for an extended period of time.

8. Making the final disposition (e.g., deletion) of the accounts and the information stored under those accounts.

9. Managing sessions and authentication and implementing account time-outs.

10. Preventing residual data from being exposed to unauthorized users as information resources are released or reallocated.

11. Testing information resources to ensure security mechanisms are functioning properly.

12. Tracking hardware and software vulnerabilities.

13. Maintaining an accurate inventory of Postal Service information resources under their control.

14. Ensuring that audit and operational logs, as appropriate for the specific platform, are implemented, monitored, protected from unauthorized disclosure or modification, and are retained for the time period specified by Postal Service security policy.

15. Reviewing audit and operational logs and maintaining records of the reviews.

16. Identifying anomalies and possible internal and external attacks on Postal Service information resources.

17.Reporting information security incidents and anomalies to their manager and the CIRT immediately upon detecting or receiving notice of a security incident.

18. Protecting information resources at risk during security incidents, assisting in the containment of security incidents as required, and taking action as directed by the CIRT.

19. Participating in follow-up calls with the CIRT and fixing issues identified following an incident.

20. Ensuring that virus protection software and signature files are updated and kept current for resources under their control.

21. Ensuring the availability of information resources by implementing backup and recovery procedures.

22. Ensuring the compliance with Postal Service information security policy and procedures.

23. Monitoring the implementation of network security mechanisms to ensure that they are functioning properly and are in compliance with established security policies.

24. Maintaining a record of all monitoring activities for information resources under their control.

25. Assisting with periodic reviews, audits, troubleshooting, and investigations, as requested.

26. Resolving identified vulnerabilities.

32) Database Administrators

Database administrators (DBAs) are responsible for the following:

1.Implementing appropriate database security based on the platform specific hardening standards for the information resources under their control.

 2. Implementing information security policies and procedures for all database platforms and monitoring the implementation of database security mechanisms to ensure that they are functioning properly and are in compliance with established policies.

3. Applying approved patches and modifications, in accordance with policies and procedures established by the Postal Service.

4. Maintaining an accurate inventory of Postal Service information resources under their control.

I5. Implementing appropriate database security administration and ensuring that log-on IDs are unique.

6. Setting up and managing accounts for systems under their control in accordance with policies and procedures established by the Postal Service.

7. Disabling accounts of personnel that has been terminated, transferred, or have accounts that have been inactive for an extended period of time.

8. Making the final disposition (e.g., deletion) of the accounts and the information stored under those accounts.

9. Managing sessions and authentication and implementing account time-outs.

10.Preventing residual data from exposure to unauthorized users as information resources are released or reallocated.

11.Testing database software to ensure that security mechanisms are functioning properly.

12.Tracking database software vulnerabilities, and deploying database security patches.

13.Ensuring database logs are turned on, logging appropriate information, protected from unauthorized disclosure or modification, and retained for the time period specified.

13.Reviewing database audit logs and maintaining records of log reviews.

14.Assisting with periodic reviews, audits, troubleshooting, and investigations, as requested.

15.Ensuring the availability of databases by implementing database backup and recovery procedures.

16. Identifying anomalies and possible attacks on Postal Service information resources.

17. Reporting information security incidents and anomalies to their manager and the CIRT immediately upon detecting or receiving notice of a security incident.

18.Protecting information resources at risk during security incidents, assisting in the containment of security incidents as required, and taking action as directed by the CIRT.

19. Resolving identified vulnerabilities.

33) All Personnel

All personnel, including employees, suppliers, consultants, contractors, business partners, customers who access nonpublicly available Postal Service information resources (e.g., mainframes or the internal Postal Service network), and other authorized users of Postal Service information resources are responsible for the following:

1.Complying with applicable laws, regulations, and Postal Service information security policies, standards, and procedures.

2. Displaying proper identification while in any facility that provides access to Postal Service information resources.

3.Being aware of their physical surroundings, including weaknesses in physical security and the presence of any authorized or unauthorized visitor.

4.Protecting information resources, including workstations, portable devices, information, and media.

5. Always using their physical and technology electromechanical access control identification badge or device to gain entrance to a controlled area.

6.Ensuring no one tailgates into a controlled area on their badge.

7.Performing the security functions and duties associated with their job, including the safeguarding of their log-on IDs and passwords.

8.Changing their password immediately, if they suspect that the password has been compromised.

9.Prohibiting any use of their accounts, log-on IDs, passwords, personal information numbers (PINs), and tokens by another individual.

10.Taking immediate action to protect the information resources at risk upon discovering a security deficiency or violation.

11.Only using licensed and approved hardware and software.

12.Protecting intellectual property.

13.Complying with Postal Service remote access information security policies, including those for virtual private networks, modem access, dial-in access, secure telecommuting, and remote management and maintenance.

14.Complying with acceptable use policies.

15. Maintaining an accurate inventory of information resources for which they are responsible.

16.Protecting information resources against viruses and malicious code.

17.Calling the appropriate Help Desk for technical assistance in response to suspected virus incidents.

18. Immediately reporting to the CIRT via telephone or email and, as appropriate, to their immediate supervisor, manager, or system administrator, any suspected security incidents, including security violations or suspicious actions, suspicion or occurrence of any fraudulent activity; unauthorized disclosure, modification, misuse, or inappropriate disposal of Postal Service information; and potentially dangerous activities or conditions.

19.Taking action, as directed by the CIRT, to protect against information security incidents, to contain and eradicate them when they occur, and to recover from them.

20. Documenting all conversations and actions regarding the security incident and completing PS Form 1360, Information Security Incident Report, or an acceptable facsimile. If an individual removes a portable electronic device from a Postal Service facility, he or she must do the following:

  1. If the device contains sensitive-enhanced or sensitive information, request approval in writing from his or her functional area vice president (data steward), CPO, and the VP IT Operations or their designees.
  2.  Reporting any missing or stolen device or media immediately to his or her manager, the CIRT via e-mail to uspscirt@usps.gov, and to the local Inspection Service office. If the device has been stolen somewhere other than Postal Service premises, report the theft to the local police as well.

———————————End of example———————————————

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com  You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion are also welcome.

ISO 27001:2013 Clause 4 Context of the organization

by Pretesh Biswas

Clause 4: Context of the organization

As per  ISO, the definition of Context of the Organization is “business environment“, “combination of internal and external factors and conditions that can have an effect on an organization’s approach to its products, services and investments and interested Parties“. The concept of Context of Organization is equally applicable to Not for profit organization, public service organization and governmental organization. Also in normal language, this concept is also known as the business environment, organizational environment or ecosystem of an organization.

Information security management is a major issue worldwide. It describes the behaviors of commercial organizations and government bodies, many of whom are seizing opportunities to analyze their records of customer and citizen personal information. Merging this with volumes of traded ‘anonymized’ data, these organizations aim to harvest new insights, seeking competitive advantages and efficiencies. There is also a wider black market trade that includes personal account IDs and passwords, credit card details, commercial intellectual property, and sensitive financial data. The value of that information is motivating theft, funding organized crime, satisfying nation-state espionage and driving evolution of globally-dispersed technical threats to challenge established operational principles and practices. Organizations are increasingly embracing online opportunities to promote their business and consolidate their position in the marketplace through the use of mobile device applications and social networking presence. Mobile devices and ‘the internet of things’ have dissolved traditional organizational perimeters and are dispersing information both geographically and logically across the internet. This presents a wide exposure to diverse and sophisticated technical threats.

Clause 4 requires an organization to establish the context of its ISMS. It has to determine its needs and expectations and those of interested parties and decide the scope of the ISMS. The new “context” clause requires an understanding of the organization and its needs, determine external and internal issues and consider interested parties and their requirements. Requirements of interested parties may include legal and regulatory requirements and contractual obligations. Context determines the information security policy and objectives and how the organization will consider risk and the effect of risk on its business. An appropriate scope for the ISMS is now required. This clause in part addresses the depreciated concept of preventive action and in part establishes the context for the ISMS. It meets these objectives by drawing together relevant external and internal issues (i.e. those that affect the organization’s ability to achieve the intended outcome(s) of its ISMS) with the requirements of interested parties to determine the scope of the ISMS. It should be noted that the term ‘issue’ covers not only problems, which would have been the subject of preventive action in the previous standard, but also important topics for the ISMS to address, such as any market assurance and governance goals that the organization might set for the ISMS. Note that the term ‘requirement’ is a ‘need or expectation that is stated, generally implied or obligatory’. Combined with Clause 4.2, this in itself can be thought of as a governance requirement, as strictly speaking an ISMS that did not conform to generally-accepted public expectations could now be ruled non-conformant with the standard. The final requirement (Clause 4.4) is to establish, implement, maintain and continually improve the ISMS in accordance with the requirements the standard.
To establish an ISMS the organization needs to define the ISMS which includes the following steps:

4.1 Understanding the organization and its context

The organization must determine its external and internal issues which should be relevant to its purpose and can affect its ability to achieve the intended outcome of its information security management system. While determining these issues the organization can refer to establishing the external and internal context of the organization as given in Clause 5.3 of ISO 31000:2009. ISO 31000 is a standard that provides guidelines for risk management, and this is what it suggests could be included when identifying internal and external issues. Please note that ISO 31000 gives guidelines only; therefore, they are not mandatory.

The idea of the context of the organization’s overall business is maintained here. There is an explicit requirement to consider both internal and external issues which might impact the organization’s purpose and affect its ability to achieve the expected outcomes of the ISMS. External and internal issues have to be determined that are relevant to the organization’s purpose and that affect its ability to achieve the intended outcome(s) of its information security management system. There are expectations that these considerations and resulting conclusions will need to be documented. To reinforce the theme that runs throughout the Annex SL there is a note referencing ISO 31000 Risk management – Principles and guidelines. Here you have to understand your organization and its context. Identify and understand your organization’s context before you establish its information security management system (ISMS).  Identify the internal issues that are relevant to your organization’s purpose and consider the influence these issues could have on its ability to achieve the outcomes that its ISMS intends to achieve. You have to determine the influence your internal stakeholders could have. Determine the influence your approach to governance could have.  Determine the influence your organization’s capabilities could have.  Determine the influence your organization’s culture could have. Determine the influence your organization’s contracts could have. You have to identify the external issues that are relevant to your organization’s purpose and consider the influence these issues could have on its ability to achieve the outcomes that its ISMS intends to achieve. You have to determine the influence environmental conditions could have. Determine the influence key trends and drivers could have.  Determine the influence external stakeholders could have.

An organization’s risk assessment process should address the strategic, organizational and security risk management contexts. Security risk management is applicable across all facets of an organization’s functions, or activities. In particular, the risk assessment needs to be appropriate to the prevailing and emerging risk environment. Establishing the context is critical as it sets the basis on which all subsequent risk assessment activities are conducted. The Step in establishing the context could include:

1. Communication & Consultation

Communication and consultation with external and internal stakeholders should take place during all stages of the establishing Organizational context. Therefore, plans for communication and consultation should be developed at an early stage. These should address issues relating to the ISMS itself, its causes, its consequences (if known), and the measures being taken to treat it. Effective external and internal communication and consultation should take place to ensure that those accountable for implementing the management process and stakeholders understand the basis on which decisions are made, and the reasons why particular actions are required. A consultative team approach may:

  • help establish the context appropriately;
  • ensure that the interests of stakeholders are understood and considered;
  • help ensure that risks are adequately identified;
  • bring different areas of expertise together for establishing context;
  • ensure that different views are appropriately considered when determining organizational context, defining risk criteria and in evaluating risks;
  • secure endorsement and support for a treatment plan;
  •  enhance appropriate change management during the whole  process; and
  • develop an appropriate external and internal communication and consultation plan.

Communication and consultation with stakeholders are important as they make judgments based on their perceptions. These perceptions can vary due to differences in values, needs, assumptions, concepts, and concerns of stakeholders. As their views can have a significant impact on the decisions made, the stakeholders’ perceptions should be identified, recorded, and taken into account in the decision making the process. Communication and consultation should facilitate truthful, relevant, accurate and understandable exchanges of information, taking into account confidential and personal integrity aspects.

2. Establishing the context of ISMS

By establishing the context, the organization articulates its objectives, defines the external and internal parameters to be taken into account when managing risk, and sets the scope and risk criteria for the remaining process. While many of these parameters are similar to those considered in the design of the Information Security management framework, when establishing the context for the ISMS processes, they need to be considered in greater detail and particularly how they relate to the scope of the particular management process.

3. Establishing the external context
The external context is the external environment in which the organization seeks to achieve its objectives. Understanding the external context is important in order to ensure that the objectives and concerns of external stakeholders are considered when developing its Security risk criteria. It is based on the organization-wide context, but with specific details of legal and regulatory requirements, stakeholder perceptions and other aspects specific to the scope of the Information Security management process. The external context can include, but is not limited to:

  • the social and cultural, political, legal, regulatory, financial, technological, economic, natural and
  • competitive environment, whether international, national, regional or local;
  • key drivers and trends having an impact on the objectives of the organization;
  • and relationships with, perceptions and values of external stakeholders.

4. Establishing the internal context

The internal context is the internal environment in which the organization seeks to achieve its objectives. The Information Security management process should be aligned with the organization’s culture, processes, structure, and strategy. Internal context is anything within the organization that can influence the way in which an organization will manage its Security risk. It should be established because:

  1. risk management takes place in the context of the objectives of the organization;
  2. objectives and criteria of a particular project, process or activity should be considered in the light of objectives of the organization as a whole; and
  3. some organizations fail to recognize opportunities to achieve their strategic, project or business objectives, and this affects ongoing organizational commitment, credibility, trust, and value.

It is necessary to understand the internal context. This can include, but is not limited to:

  • governance, organizational structure, roles, and accountabilities;
  • policies, objectives, and the strategies that are in place to achieve them;
  • capabilities understood in terms of resources and knowledge (e.g. capital, time, people, processes, systems, and technologies);
  • the relationships with and perceptions and values of internal stakeholders;
  • the organization’s culture;
  • information systems, information flows and decision-making processes (both formal and informal);
  • standards, guidelines, and models adopted by the organization and form and extent of contractual relationships.

5. Establishing the context of the risk management process

The objectives, strategies, scope, and parameters of the activities of the organization, or those parts of the organization where the risk management process is being applied, should be established. The management of risk should be undertaken with full consideration of the need to justify the resources used in carrying out risk management. The resources required, responsibilities and authorities, and the records to be kept should also be specified. The context of the risk management process will vary according to the needs of an organization. It can involve, but is not limited to:

  • defining the goals and objectives of the risk management activities;
  • defining responsibilities for and within the risk management process;
  • defining the scope, as well as the depth and breadth of the risk management activities to be carried out, including specific inclusions and exclusions;
  • defining the activity, process, function, project, product, service or asset in terms of time and location;
  • defining the relationships between a particular project, process or activity, and other projects, processes or activities of the organization;
  • defining the risk assessment methodologies;
  • defining the way performance and effectiveness is evaluated in the management of risk;
  •  identifying and specifying the decisions that have to be made;
  • and identifying, scoping or framing studies needed their extent and objectives, and the resources required for such studies.

Attention to these and other relevant factors should help ensure that the risk management approach adopted is appropriate to the circumstances, to the organization and to the risks affecting the achievement of its objectives.

6. Defining risk criteria

The organization should define criteria to be used to evaluate the significance of the risk. The criteria should reflect the organization’s values, objectives, and resources. Some criteria can be imposed by, or derived from, legal and regulatory requirements and other requirements to which the organization subscribes. Risk criteria should be consistent with the organization’s management policy, be defined at the beginning of any management process and be continually reviewed. When defining risk criteria, factors to be considered should include the following:

  • the nature and types of causes and consequences that can occur and how they will be measured;
  • how likelihood will be defined;
  • the time-frame of the likelihood and/or consequence;
  • how the level of risk is to be determined;
  • the views of stakeholders;
  • the level at which risk becomes acceptable or tolerable;
  • and whether combinations of multiple risks should be taken into account and, if so, how and which combinations should be considered.

The ISO 27001 standard is structured according to the “Plan-Do-Check-Act” (PDCA) model. In the Plan phase, an ISMS is established, in the Do phase the ISMS is implemented and operated, in the Check phase the ISMS is monitored and reviewed, and in the Act phase, the ISMS is maintained and improved. In the Plan phase, the scope and boundaries of the ISMS, its interested parties, environment, assets, and all the technology involved are defined. In this phase also the ISMS policies, risk assessments, evaluations, and controls are defined. Controls in the ISO 27001 are measures to modify risk. Context of the organization  starts with a gathering of information about the organization. The next activity is the context establishment. This initial step is important for all following steps and is responsible, whether the risk management can be implemented to a sufficient extent and on a sufficient level of detail. The next step is risk identification, that determines the potential loss. Then risk estimation tries to rate the consequences of loss on a qualitative or quantitative scale as well as the likelihood of occurrence. The risk evaluation step compares the level of risks against the risk acceptance criteria, defined during the context establishment. Then, the risk treatment step sets up the controls. In the risk acceptance step, residual risks have to be accepted by managers of the organization.

For example, let us consider an ICT(Information and Communication Technology) system. An ICT system is a software system that processes data for stakeholders. The software system consists of resources that have a location and the system consists of hardware and software. The system is embedded in a direct system environment, which contains stakeholders that have a direct relation to the system. The direct system environment is further embedded in the indirect system environment, which contains stakeholders that have no direct relation to the system. The System Owner owns the ICT system, the Administrator maintains the resources of the software system. Developers develop software for the ICT system. The system has an Internal Users that work for the System Owner and exchanges data with the ICT system. In addition, External Users work for a Customer of the System Owner. The stakeholder of the indirect environment is the legislator, a set of all relevant laws from a specific country. The template can be instantiated with multiple legislators of all the countries relevant for the ICT system. The domain represents a set of all relevant regulations for, e.g., the finance domain.

The first step is about gathering information about the organization. This can be done by systematically gathering domain knowledge about the direct and indirect system environments based upon the stakeholders’ relations to the system and other stakeholders.

Let us take an example for Administrator.

  • Name: Administrator
  • Description: The administrator repairs the system and he/she executes maintenance efforts.
  • Relations to the ICT system: The administrator has access to the entire data in the system.
  • Motivation: The administrator earns money by maintaining the resources of the ICT system.
  • Relations to other direct stakeholders: The administrator has a contract with the System Owner to maintain the system. There might also be further contracts, e.g., preventing the administrator from accessing the Customers data.
  • Assets: The administrator has no direct assets in the ICT system. However, if the ICT system does not exist, he/she would not earn money. Hence, the system itself could be considered the asset of the administrator.

When the gathering of information about the organization is done, a context establishment as a next step. It consists of the basic criteria, the scope and boundaries and the organization of information security risk management (ISRM).

The basic criteria are instantiated with a set of resources, which have to be elicited before the instantiation. Resources are all relevant elements of an organization to the ISRM. The basic criteria require further that information assets have to be derived from the set of resources. Afterwards, the resulting set of information assets has to be refined to classes of similar information assets. For each of these classes, an assessment of security breaches has to be conducted. This shall be done for at least the following kinds of security issues: CIA breaches, financial and business loss, compliance breaches. Afterward, criteria have to develop for each class of information assets based on the assessed breaches and losses. Those criteria should include risk evaluation criteria, impact criteria, and risk acceptance criteria. The scope and boundaries have to be instantiated with collected information artifacts about the organization. These artifacts have to be collected from business objectives, strategies, information security policies, business processes, organizational functions and structure, legal and contractual requirements, stakeholders and their expectations, socio-cultural environment, and interfaces between environment and organization. For each collected information artifact, it has to be decided whether it shall be included in the scope and boundaries (or not). An information security risk management process has to be defined and documented, as part of the description of the organization of the ISRM. Such a process should contain the stakeholders of the system, the roles they enact, the activities they execute, the relations between stakeholders, roles and the organization, and the records to be kept.

Stakeholder As defined above.

1.Roles

  • Rolename: A short name of the role
  • Description: A summarizing description of the role
  • Stakeholder: A list of stakeholders which can enact the role
  • Precondition: Conditions to be fulfilled to enact this role.
  • Responsibilities: A description for which assets and resource the role is responsible
  • Rights: A description of rights the role has to have to fulfill the responsibilities.
  • Excluded roles: A list of roles which are not allowed to be bound to a stakeholder, who enacts the role at hand, at the same time.

2. Resources And Assets

  • Name:  Identifier for the resource or asset.
  • Description: A summarizing description of the resource or asset.
  • Stakeholder: A list of stakeholders, which have a relation to the resource or assets. The relation has also to be described

3. Records

  • Identifier: Identifier for the record
  • Description: A summarizing description of record
  • Template: A template to generate a record

4. Activities

  • Activity: A short name of the activity.
  • Description: A summarizing description of the activity.
  • Precondition: Activities and constraints to be fulfilled before this activity can be executed.
  • Affected Stakeholders: A list of stakeholders which are affected by the activity.
  • Roles: The roles which are allowed to execute this activity.
  • Resources and Assets: A list of resources and assets which are necessary for the activity.
  • Records: List of records to be generated when this activity is executed.
  • Postcondition: Activities and constraints to be fulfilled after this activity has been executed

The context of the organization can include, but is not limited to:

  • governance, organizational structure, roles, and accountabilities
  • The organization should consider what aspects of strategic context are relevant to their situation, and factor these into their risk assessment process. These can include, but are not limited to:
    • relevant Governmental legislation, regulation, and policy, including responsibility for safeguarding information.
    • foreign laws and potential jurisdictional access to information, and
    • the potential benefits of outsourcing and other arrangements.

Identifying risk

This step is used to comprehensively determine all applicable sources of risk and potential events that could impact Organization business. Each risk should be described in as full a manner as possible so that decision-makers can fully understand the situation. The organization should identify risks to the confidentiality, availability, and integrity of Government information subject to their ICT arrangements. The criteria for determining an organization’s risk tolerance should be done during the ‘Establishing the context’ phase of the risk assessment process. Determining risk tolerance will be highly dependent on the organizational context of the Organization and its Top management.  The level of tolerance for risk is the sum of the Organization’s risk appetite. The risk tolerance is based on the principle of managing risk to a level that is as low as reasonably practicable, while still allowing scope for flexible and innovative business practices. An organization’s tolerance can be affected by certain changing evaluation criteria. Therefore, an Top Management’s appetite for risk can vary depending upon:

  • prevailing political and community sensitivities and expectations.
  • the nature of the security incident (e.g. terrorist act, hacking)
  • existing or emerging security incidents trends (trusted insider, cyber-attacks)
  • strategic or business priorities
  • resource availability for treatment, and
  • the ability of the organizations or individual to absorb losses.

In most cases determining an organization’s risk tolerance can be understood as a gradient, where the risk may become progressively less tolerable as the risk level is increased. Organizations may also use their security plans as a source of information as the risk tolerance determined as part of that plan should be broadly consistent with risk assessments undertaken for outsourced or offshore arrangements.

Risk Tolerance

Understanding the nature of the relevant or potential threat, criticality and vulnerabilities is an essential component of establishing context. Below are a series of considerations and questions that can facilitate this process:

  • How could the confidentiality, integrity, and availability of information be affected?
  • What is the aggregated value of the information holdings to the Organization?
  • What would an unintended disclosure look like? What would an event or incident look like?
  • What would be the impact of the loss of confidence in the integrity of your information? For example, the integrity of the customer record.
  • How could an unintended disclosure of information occur in an outsourced or offshore arrangement? What are the sources of risk?  What threats are there?
  • When searching for information to inform the risk identification process, agencies should take into account individual agency security plans, as these are a ready source of information on risks to agency information.

Below are the top nine threats to Cloud service as identified by the Cloud Security Alliance’s The Notorious Nine: Cloud Computing Top Threats in 2013. The organization should not limit its consideration exclusively to this list but use this list to inform their assessment of the use of outsourcing or offshoring information.

  • Data Breaches – sensitive internal data is stolen, leaked or accessed by external unauthorized entities.
  • Data Loss – the permanent loss or deletion of data by accident or malicious activity.
  • Account or Service Traffic Hijacking – external entities eavesdropping on your activities, transactions, manipulating data, return falsified information, through phishing, fraud, and exploitation of software vulnerabilities still achieve results.
  • Insecure Interfaces and Application Programming Interface (API ) – vulnerable interfaces can be exploited both accidentally and maliciously in an attempt to circumvent the security process.
  • Denial of service (DoS) – DoS attacks can prevent users from accessing their data or applications while forcing the victim to consume inordinate amounts of finite system resources.
  • Shared Technology Vulnerabilities – Cloud infrastructure (CPU caches, GPU, etc) that is not designed to offer a multi-tenant architecture is vulnerable to scalable sharing practices. This vulnerability is dangerous because it can affect an entire Cloud at once.
  • Malicious Insider – a current or former employee, contractor or other business partners who has or had authorized access to an organization’s network, system, or data and intentionally exceeded or misused that access in a manner that negatively impacts the organization’s information systems.
  • Abuse of Cloud Services – this threat is more an issue for Cloud service providers, but Cloud services can facilitate malicious agendas through the exploitation of Cloud infrastructure.
  • Insufficient Due Diligence –entering into ICT arrangements with Cloud services providers without effectively understanding the full scope of the undertaking, its weakness, and vulnerabilities.

Due to the evolving nature of technology the threat environment is constantly changing. As a result, there is a need for ongoing oversight and management of the threat  environment and its potential impact and consequences

Assessing risk

To fully understand the potential of the risks identified, the organization should develop a clear understanding of the vulnerabilities that are apparent from each risk event. This is essential to gauge the consequence and likelihood of these risk events to inform the risk assessment. This process will also help in the prioritization of the identified risks, and guide the allocation of resources in mitigating their impacts. The organization should  consider the following for each identified risk:

  • What is the likely outcome of the risk eventuating?
  • When and how frequently can the risk happen?
  • Where is the risk likely to impact?
  • Who could be impacted by the occurrence of the risk event?
  • Who are the stakeholders of the risk event? What is the impact on them?
  • What catalysts could lead to the risk event?
  • How can eventuality of the risk be mitigated?
  • How can the consequences of the risk event be mitigated?
  • How reliable is the information that this risk assessment is being based on?

Once the range of relevant risks has been identified, the risk assessment process should determine the level of risk. To achieve this, the potential consequences of the risk event, the likelihood of it occurring, and the acceptable levels of tolerance should be evaluated holistically. The sources of risk events and the effectiveness of existing controls to prevent or reduce the consequences of risk events should be considered in assessing the likelihood and consequence levels. This includes the level of oversight and control agencies have on the management of their information. As an example, all Organization information should be assessed in relation to Confidentiality, Integrity, and Availability, including aggregation. For each of these areas, risks events must be assessed against the potential of their impact for-Whole of organization, their Department/Agency, and their customer. The chance of the risk event occurring and whether there are extant controls or measures in place to reduce the effects of the event needs to also be considered.

1. Guidance on determining potential consequences

The consequence of unintended disclosure of information will depend on the profile of that information. For example, unintended disclosure or compromise of an organization’s  information could affect the:

  • organization’s capacity to make decisions or operate
  • privacy and integrity of personal information about employees
  • the safety of persons
  • public’s confidence in organizations
  • market stability and commercial interests
  • the competitive process, and
  • compliance with legislation.

  2. Guidance on determining the likelihood

The likelihood is the chance or probability of an event or incident occurring resulting in the unintended disclosure or compromise of organization information.  When considering the likelihood, the organization should consider the timeframe in which the risk could potentially occur.  The organization may represent likelihood on a predetermined scale, for example, low, medium and high.  Alternatively, it can be presented as a percentage.

3. Guidance on rating risk

Determining the risk rating is the sum of combining the defined likelihood and consequence estimations. The risk rating should be between the level of “Extreme” and “Low”. While initial estimations of likelihood and consequence can present risks identified as “extreme” or “low”, the overall risk rating should be the sum of all identified risks calculated together. It is appropriate when rating risk to use the ‘most credible’ scenario to determine the overall

LIKELIHOOD CONSEQUENCES
Insignificant Negligible Moderate Major Extreme
Remote VERY LOW VERY LOW LOW MEDIUM HIGH
Unlikely VERY LOW LOW MEDIUM MEDIUM HIGH
Possible VERY LOW LOW MEDIUM HIGH VERY HIGH
Likely VERY LOW LOW MEDIUM HIGH VERY HIGH
Almost certain LOW LOW MEDIUM HIGH VERY HIGH

Evaluating the risks of unintended disclosure of the organization’s information involves considering the risks within the context of the organization’s risk tolerance and potential treatment options. In some circumstances, the risk of unauthorized access or disclosure of information can be quantified almost entirely in financial terms based on a loss of revenue. In these circumstances, determining the risk is a matter of financial calculation. However, in most circumstances, the should consider a wider range of factors, including the potential reputational cost of disclosure due to a loss of citizens’ or businesses’ data. In these circumstances, calculating the risk is a more complex process and the acceptance of that risk resides with the agency head.  There may be circumstances where the factors for consideration and judgments required are so complex that the risk of is incalculable. If the risk is determined to be incalculable, it will not be possible to manage it and Top Management should not enter into these arrangements.

Security is not absolute.  Efforts to treat risks will not remove them completely but should aim to make the risk levels more tolerable. When selecting risk treatments the allocation of resources should be conducted proportionally to the determined risks rating level. This includes a six-step process where the organization

  1. Prioritize intolerable risks.
  2. Establish treatment options.
  3. Identify and develop treatment options.
  4. Evaluate treatment options.
  5. Detailed design and review of chosen options, including the management of residual risks.
  6. Communication and implementation.

Example of External issues relevant for ISMS

  1. Legal and regulatory.
    XXX recognize there are legal and regulatory requirements over and above the requirements as established by our internal requirements.
LEGISLATION IS REQUIREMENTS
1. Contract law A contract is a legally enforceable exchange of promises. Any agreement we enter into must follow a set format or it could be invalid
2. Information Technology Act 2000 and its Amendment, 2008 Legislation Covering IT Act 2000 and its amendment 2008, We must ensure that all the requirements of these acts are covered.

2. Cultural

  • Personal data – There is a known external demand for personal data (especially financial i.e. Credit card details, address details and dates of birth) and significant inducements can be offered to staff for the collection of information this could affect “confidentiality‟.
  • Hacking and unauthorized interception of communications is an issue we know about targeting contact centers, this could affect “confidentiality”.
  • Wages in our industry are low and so bribery is an ever-present threat, this could affect “confidentiality‟.

3. Connectivity

  • Power and connectivity – utility failures are common and have occurred in the past. We have had power cuts due to local power demand increases that have interrupted mains power (new building and expanding businesses: the infrastructure cannot cope). IT connectivity has also been interrupted by this high demand. This could impact on ‘integrity’.
  • International clients are also expecting state of the art technology, fast connection speeds for sales and call handling report visibility (statistics). This has an impact on our commitments contained in our service level agreements.

4. Location

  •  Physical location, our location is in an area of high criminality (due to many hi-tech businesses located nearby) and adjacent offices have been attacked by thieves which could have an impact on “confidentiality‟.
  • Environmental – no particular flooding or storm damage is anticipated.

5. Competition

Employees could take XXX or customer information to a competitor. There are many competitors located close to our office. Staff can often move from our company to a competitor quickly. This could affect “confidentiality‟.

6. Economic pressures

  • It is understood that when some of our competitors are under pressure for new revenue, they may be more likely to illicit sources of information on our customers from our key employees. This could also entail poaching key members of staff and securing access to confidential information. The loss of a key member of staff with the customer data they have access to could impact us heavily. This could affect  “confidentiality‟ and the viability of XXXX.
  • In tight financial times, customers are seeking cost-saving alternatives, we are therefore seeing a large increase in sales inquiries putting pressure on our internal resources and IT and IS systems.

Example of Internal issues relevant for ISMS

1.Information systems

Some of our systems are old and due to be replaced. New systems will be more complex and possibly harder to support. Possible “integrity‟ issues.

2. Organization’s culture

Historically our company has been sales driven, the need to bring in work has outweighed other considerations such as “confidentiality‟. This has resulted in a misalignment between its strategic direction and IS policy. The integration of IS into the organization‟s sales processes may not be strictly adhered to and top management support to demonstrate leadership in IS may be compromised when large orders are at stake.

3. Relationships and perceptions and values of internal stakeholders

  • Historically we have had a high turnover in staff and this means staff could take data with them on departure. We understand that the skill sets of our call center staff are limited and as such documented processes and guidance are more important. Also comprehending the nature of IS policies and their importance and consequences may not be fully recognized and hence information security incidents are more likely.
  • Many skills and decision-making authorities are restricted to a very few senior staff who know each other very well, this has led to a competence and documentation „gap‟ through informality.

4. Human Resource Security and Capabilities (knowledge)

The high staff turnover has caused XXXX difficulties in retaining core knowledge, such as system support and customer relations. This may cause issues. Staff is recruited form the local workforce and because of the low wages and skills expectation, they may not be well off financially or well educated. This may leave them more vulnerable to bribery and corruption.

5. Governance, organization and roles and responsibilities

As a small company, responsibilities have been retained by a small management team. As we grow this may be difficult to achieve but is needed.

6. Standard working procedures and guides

Processes have not been documented because of their retention and ownership by senior individuals only. As we grow this lack of documentation may cause problems.

7. Contractual relationships with our suppliers

As a small new business, our purchasing power and influence is restricted; as we are not able to include IS requirements in contracts, also some suppliers do not have formal contracts with us. Hence the scope of our ISMS excludes all IS outsourced processes. As ‘Data Cleansing’ is a current outsourced process, this naturally causes our clients concerns around “Confidentiality‟ and “Integrity‟.

4.2 Understanding the needs and expectations of interested parties

The organization must determine the interested parties and their requirement that are relevant to the information security management system;  The requirements of interested parties may include legal and regulatory requirements and contractual obligations.

The organization shall determine interested parties that are relevant to the information security management system and the requirements of these interested parties relevant to information security. The organization must identify all of the parties that have an interest in your organization’s ISMS. and must also identify their requirements including their needs and expectations.  Let’s start with understanding what interested parties are – they are nothing else but stakeholders, i.e., persons or organizations that can influence your information security/business continuity or persons or organizations that can be affected by your information security or business continuity activities. So, typically, interested parties could include:

  • employees
  • shareholders/owners of the business
  • government agencies/regulators
  • emergency services (e.g., firefighters, police, ambulance, etc.)
  • clients
  • employee families
  • media
  • suppliers and partners
  • … and anyone else that you consider important for your business.

How can you identify them? Just ask your top executives, as well as heads of departments about who is important for their business, and then assess whether they could be interested in your information security or business continuity. Also, chances are that your existing documentation (e.g., business plans) already contains such information.
Having identified its interested parties, there are now demands on an organization to consider their needs and expectations. However, these needs and expectations are only those relevant to information security. There are expectations that these interested parties and their requirements will need to be documented. Previously the involvement of interested parties was restricted to feedback and communication; now they are at the heart of the ISMS. There is a note clarifying that legal and regulatory requirements and contractual obligations may be included in the requirements of interested parties. The identification of interested parties is not as important as the second step: identification of their requirements. Here’s why it is important: you need to know what all the interested parties want from you, and you need to figure out how to satisfy all these requirements in your ISMS. For example, shareholders want the security of investment and a good return, clients want you to comply with security clauses in the contracts you signed with them, government agencies want you to comply with information security continuity laws and regulations, the media want quick and accurate news related to your incidents, etc. However, you have to be more specific than this – you have to specify exactly which laws and regulations, which security or continuity clauses exist in the contracts, and so on. The best way to collect this information is to study their written requirements (legislation, contracts, etc.) and/or interview their representatives. Once you have all this information, you will need to “configure” your information security or business continuity to be compliant with your stakeholder expectations – this means you’ll have to identify the requirements before you start developing the details of your ISMS.  A good practice is to write a procedure that defines who is in charge of identifying all the interested parties and their legal, regulatory, contractual and other requirements and interests; such a procedure also needs to define who is in charge of updating this information and how often this is done. If you work in a larger organization, such organizations usually have compliance departments or compliance officers – they would be the most natural department/person to do this kind of a job. If not, you can try to negotiate whether your legal department could do this job – if not them, then you, the information security or business continuity coordinator, will have to do it yourself. Once the requirements are clearly identified, you need to define who is in charge of complying with them – these responsibilities could be very different: IT department would be in charge of complying with technical requirements, human resources department for, e.g., confidentiality statements, information security coordinator with new policies and procedures, etc.

Examples of Understanding the Needs and Expectations of Interested Parties

The interested parties that are relevant to the ISMS of XXX have been determined below with their individual expectations.

1.Customer:
Requirements are as follows:

  1. To provide products, services, and maintenance support in accordance with contractual requirements.
  2. To provide products, services, and maintenance support in the event of any disruption.
  3. To Provide provide products, services and maintenance support in  accordance with applicable legal requirements.
  4. To Provide provide products, services, and maintenance support in accordance with any additional, applicable industry, third party or end-user requirements (e.g. NHS Digital, IGSoC approval).
  5. To provide products, services, and maintenance support at any time (24/7/365).
  6. ISO 27001 Compliance
  7. 99.9% Availability of Systems
  8. Meeting SLA (4hr response – contact center)
  9. PCI DSS Requirements 9 & 12
  10. To provide products, services, and maintenance support that add value.

2. End Users
Our products and services interact with various groups of end-users.
Requirements are as follows:

  1. Products and services that we directly provide, and those that our customers provide (using our systems), are available when required.
  2.  Our products and services are reliable and simple (to use).
  3. There is a simple and effective process to enable lone workers to specify accurate, complete and up-to-date personal details.
  4. Our products and services adequately protect personal data (contact details) and sensitive personal data (medical details).
  5. We can support our products and services at all times.
  6. In the event of a disruption, we can continue the operation of products and services that we directly provide, and continue to provide support for those that customers provide (using our systems).

3, Partners:
These may be agents or system partners, recruitment companies or others. Their reputations may be damaged if we have a breach, we may be damaged if they have a breach. Our contracts with some key partners may have or need IS clauses.
Requirements are as follows:

  1. We provide any correct and complete technical information that they require, to enable them to amend, enhance, and rectify any faults in, their Application Programming Interface (API), in order to enable us to develop software that communicates and exchanges data with their API, in accordance with our requirements.
  2. We develop software in accordance with any mutually agreed schedule.
  3. Our relationship is not adversely affected by the departure or absence of any of our workers.
  4. We comply with any confidentiality and non-disclosure agreements.
  5. We provide required training, to enable the reseller to sell our products and services.
  6. We efficiently expedite orders.
  7. Adherence to contractual agreements

4. Suppliers and Contractors
Even a supplier may be affected by an incident if our use of their systems results in negative publicity for the supplier they may not want to supply us. Data suppliers may not trust us with marketing lists
Requirements are as follows:

  1. We purchase their products and/or services.
  2. Where applicable, we provide complete and accurate information when we require their technical support.
  3. Where applicable, we subscribe to their technical support.
  4. Adherence to contractual agreements
  5. Adherence to payment terms

5. Employees
We currently have approximately 30 employees, in roles of management, software development, computer and telephony engineering, sales, telemarketing, account management, finance, and administration.
Requirements are as follows:

  1. The company is profitable and provides secure work.
  2. The company provides a safe and appropriate work environment.
  3. The company provides the required training and support.
  4. The company clearly specifies its requirements and expectations of workers.
  5. Workers believe that they can positively contribute to the success of the company.
  6. The company facilitates dialogue with workers so that they are aware of their contribution.
  7. The company protects their personal information.
  8. The company pays fairly for work.
  9. The company provides opportunities for continuity of employment
  10. The company provides opportunities for advancement

6. Insurers
If fines or damages were the results of an incident (breach of contract or regulator) this would affect profits and so investors and owners. Our insurer may be liable to contribute depending on insurance wording.
Requirements are as follows:

  1. The Company should be meeting policy requirements
  2. The Company should be making timely payment of premiums
  3. The company should be reporting changes in circumstances

7. Management/Shareholders
Breaches could affect our share price or our investors could withdraw. The professional reputation of the company and its management could be questioned if we had a breach.
Requirements are as follows:

  1. Return on capital

8. Trade bodies/associations
Although we are not members of any trade bodies/associations we may seek to join at a later date. Organizations such as the Direct Marketing Association (DMA) have security requirements that we would need to follow.
Requirements are as follows:

  1. Membership requirements
  2. Meeting standards to which the organization adheres
  3. Provision of guidance
  4. Terms and Conditions for the workers

9. Regulators
We are not directly subject to any industry-specific regulatory authority, but we are subject to various legal requirements from applicable legislation.

10. Government agencies
With recent government breaches, government departments have to be squeaky clean, they have not inspected us yet but may in the future. The governments IL2/3/4 requirements around IS may affect us if we take on that sort of work.
Requirements are as follows:

If a breach broke the law we could be fined, face restrictions or directors face imprisonment.

10)  Media / Commentators
Interest in Information Security is growing, we should expect any incident to be reported and suffer bad publicity, perhaps suffering the loss of customers as a result.

4.3 Determining the scope of the information security management system

The organization must determine the boundaries and applicability of the information security management system to establish its scope. When determining this scope, the organization should take into account its  the external and internal issues referred to in 4.1; It must also take into account the requirements of its interested parties identified in clause 4.2; It must consider the  interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations. ISO 27001 requires you to write a document for the ISMS scope.

ISMS scope and boundaries determine the extent to which the ISMS is applied in an organization. Scoping is a critical part of planning the roll-out and implementation of an information security management system (ISMS). Identifying the right ISMS scope is crucial because it will assist organizations in meeting their security requirements and planning for ISMS implementation, for the organization e.g. determining resources, timeline, and budget required. Figure out what your organization’s ISMS should apply to and what its boundaries should be. However, if the scope is not accurately defined, this will result in unnecessary wastage of resources (in terms of time, cost, and effort) because, when risk assessment exercises are conducted on different scopes, it will result in inaccurate identification of information security risks. Furthermore, if the ISMS scope is not aligned with the organization’s security requirements, the organization may find that ISMS is a waste of time and resources; thus not valuing the benefits of implementing it. The scope of ISMS can be defined in terms of the organization as a whole, or parts of the organization. Use boundaries and applicability information to clarify the scope of your organization’s ISMS. The selected ISMS scope should be critical to the organization in meeting its business objectives. In general, the ISMS scope should cover the end-to-end process to deliver services and/ or produce products. It should cover the complete elements of people, process and technology and relevant assets within the process. The ISMS scope should be derived from organizational known risks. For example, in a financial institution, the risks of unauthorized access to online transactions may give critical impact to its business operations. Thus, the ISMS scope for this financial institution can be defined as online transaction services. Examples of questions that can guide organizations when defining the ISMS scope and boundaries:

  1. Which service in your organization will be covered by the ISMS?
  2. How and why is the selected service critical to your organization?
  3.  What are the characteristics of the selected service; i.e. business, the organization, its locations, assets, and technologies to be included in the ISMS?
  4. Will you require external parties to abide by your ISMS?
  5.  Are there any interfaces or dependencies between activities performed by the organization; and those performed by another? Should they be considered?

The amount of effort required to implement ISMS is dependent upon the magnitude and complexity (among others) of the scope to which it is to be applied. Nevertheless, organizations should consider factors such as information security and business requirements, expectations from stakeholders and the expected resources when defining the ISMS scope. To ensure that the ISMS is implemented effectively, it should be viewed as an enabler to achieve organizational business objectives. In order to identify ISMS scope and boundaries, organizations should perform the following activities:

  1. Consider the organization’s information security requirements which have been identified in Clause 4.1 – Define Information Security Requirements;
  2. Consider any interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations;
  3. Consider critical services that can cause a major impact on the organization and/or nation arising from losses of confidentiality, integrity or availability;
  4. Define the organizational scope and boundaries;
  5. Define Information Communication Technology (ICT) scope and boundaries,
  6. Define physical scope and boundaries; and
  7. Integrate elementary scope and boundaries to obtain the ISMS scope and boundaries.

For clarity, organizations may seek the advice of a Certification Body (CB) on the proposed ISMS scope and boundaries, as and when the need arises. Ensure that the ISMS scope is documented and approved by the top management. Control your organization’s ISMS scope document.

Purpose of formal scope definition

The scope definition serves the purpose of stating exactly what it is that an organization does that is certified to be effectively controlled by the requirements of the standard. Without a formal scope definition, the statement of an organization being ISO 27001 certified could mean a great deal or not much at all. The scope statement should state exactly what it is that an organization does that is certified to the standard.
A bad Example of scope could be XYZ company’s information security system.
This provides no details as to what products or services the company provides that has been found to meet the requirements of the standards.

An Example for scope could be The development, operation, and administration of the scheduling and planning Software as a Service platform provided by company XYZ.
This scope statement tells us that the fictional organization has been certified in not just the operation and administration of its SaaS platform, but also the development as well. This also means that the people and information systems associated with the development, operation, and administration of the system are in scope and need to meet the requirements of the standard as well. In the event this fictional company also provided other services, such as consulting, there should be no confusion or assumption that this separate service meets the requirements of the standard as it is not documented in the formal scope and wouldn’t have been subject to the certification audit.

Strategies for Determining and Defining the boundaries of your ISMS

  • First – Understanding your organization and the issues that are most relevant to it, and the needs and expectations of people and organizations who have the most interest in it. Please note that the requirements of people and organizations interested in your company should include any legal or regulatory requirements your organization is subject to. For example – if your company provides financial consulting, it would make sense to ensure that the people, processes, systems, and information involved with your client’s data is in scope. It would also make sense to ensure that your company is not in violation of any laws or regulations specific to financial consulting, or to the countries/states/counties, etc. you operate your business in. It would not make sense for the same business to have a scope that only includes their sales department, who do not have access to or influence on any customer data or its security. In short, you want to be sure you are meeting the requirements and/or wishes of those who have the most influence on the ability to reach the organization’s goals.
  • After considering the details and parties most relevant to your organization and its goals, you should have a good idea of what information should be within the scope of your system.
  •  Now the boundaries of the ISMS must be determined, which can be thought of as a perimeter serving as a demarcation between a trusted controlled environment, and the outside world.
  • In many cases, the easiest and safest way to determine your boundaries is to include the whole organization. All of its people, processes, systems, and physical locations would be included. For smaller organizations with a single office, or those only offer one product or service, it will most likely be less resource-intensive to take this approach. Determining the people and processes to be included in this case is easy, as it is everyone who is part of the organization. Similarly, the physical perimeter for your location(s) is also easily identifiable.
  • Determining the logical boundaries for your data network can be aided by identifying where the demarcation points for entry and exit exist, or where your organization has control and visibility of the network and where it does not.
  • If it exists, an organizational chart may easily identify the departments/people that are involved with the specific product or service that is in scope. However, if there are individuals that are out of scope but occupy the same offices or buildings, they will have to be treated the same as any other person outside of scope and controlled as such. This could include separate physical areas secured to only allow in scope personnel have access, separate information systems, putting contracts in place with other organizational units to define and enforce information security-related requirements, etc. Any physical locations wherein scope personnel work from,  or that are involved with the data and systems used for the in-scope good or service will need to be included in the scope.
  • For limited scopes, a strategy for determining the logical boundaries of the ISMS is to create a high-level data flow chart that illustrates a logical mapping of the associated data. It isn’t necessary to identify each unique server/ router/ switch/ storage array etc. at this point. For example, if you have 27 database servers in geographically diverse locations where in scope data could end up, just identify database servers as a single point on the map. Start with all of the possible ways the data enters your systems/buildings, all of the potential places it will go to be stored/ processed/archived, and all possible exit points. Also, note the possible ways it can get between these locations. After you have created the high-level map you can go back and drill down each potential system the data could end up at to each unique instance of the resource in order to end up with a comprehensive list of the systems that would need to be in scope. Working with this list of systems, you can then identify the physical locations they reside, methods of transport between them, and individuals with access to these systems.
  • Narrowing the scope of your ISMS can reduce its initial cost in resources, or potentially, increase it. Being able to roll out the ISMS at a single location can certainly be much less daunting then implementing at multiple, but due to the ease with which data networks can cross-organizational and geographical boundaries, it may not be realistic. I suggest that you should first determine what it is that your organization does that would have the greatest benefit for your interested parties by being controlled by an ISO 27001 certified ISMS, and then working from there to identify the people, processes, systems, and data that are involved in it.
  • The feasibility and sensibility of limiting the scope of your ISMS will greatly depend on the specifics of your organization and its context. The key point to remember is that, with a limited scope, organizational assets outside of the scope must be treated the same as those external to your company.

Different scopes

Scoping is a critical part of planning the roll-out and implementation of an information security management system (ISMS). An organization is often sub-divided into smaller ISMS scopes (e.g. an ISMS relating to a particular project, service, audit or policy, etc). In either case, the scope determines the boundaries and applicability of information security management and controls. Scope will be shaped by:

  • the business of an organization
  • the needs and expectations of relevant interested parties
  • the organizational structures that are currently in place.

It is important to correctly define and agree with the scope with the relevant senior stakeholders at the outset, so as to manage expectations, agree in advance what is (and is not) to be achieved, and ensure that applicable security requirements for relevant systems are identified and implemented. An organization will typically have multiple scopes relating to information security. For example, the overall scope for information security is likely to be considered as the entire organization. However, in most Higher Education environments it would be difficult to tackle the whole organization in one go. Similarly, it would be an almost impossible task to certify the entire organization against an ISO/IEC 27001 standard or other standards like PCI DSS. Thus the organization should consider having multiple, smaller, scopes, each of which is tailored to the protections required for the information it encompasses. For example, the scope of a PCI DSS audit is determined by protecting only payment cardholder data. Starting with a reduced scope (as opposed to trying to tackle too much too quickly) may also increase the chances of success, and of achieving the objectives of the ISMS in a reasonable time. Examples of scopes include:

  • scope of an ISMS for the purposes of ISO/IEC 27001 certification
  • scope to which a policy applies
  • system components potentially affecting the security of cardholder data for PCI DSS compliance
  • scope of an audit
  • scope of specific information security projects and services
  • scope of responsibility in contractual agreements.

How to define the scope of an ISMS

1. Identify what needs to be protected
One of the first questions to ask is “what needs to be protected”? It is likely that there will be many information assets that need to be protected in order to support the organization in achieving its business objectives. It is important to understand which of these the organization considers to be most important, and so a risk-based, prioritized approach should be taken to scoping. In order to establish that assets are actually worth protecting, the organization should justify why each asset requires protecting. The scope of an ISMS may initially be defined to include only specific processes, services, systems or particular departments. Success stories can then be presented as a business case for expanding the scope of the ISMS or creating another, separate scope with different requirements and protections. In order to make the scope entirely clear, especially to third parties, it is a useful exercise to identify what is not in scope (e.g. the activities of the HR department). Either way, the scope should clearly define what is being included, based on the business objectives and information assets to be protected, and it should be clear that anything else is out of scope.

2. Monitor and review
The scope of an ISMS, policy, audit or project is not static and may evolve over time as circumstances, threats, technologies, and requirements develop. Therefore scoping is not something that should be done once at the beginning of a project and then forgotten about. Rather, the scope should be monitored and reviewed at regular intervals and/or in the light of significant changes. In the event of an audit (be it for internal control or certification purposes) one of the first things an auditor should do is to review and assess the appropriateness of the scope. Factors that might affect/change the scope of an ISMS include:

  • time dependencies: e.g. the scope of a particular ISMS and/or security project may only be applicable for a particular time period
  • change in the regulatory environment
  • changes/updates to standards and/or third-party requirements
  • change in the organization (e.g. organization structure changes)
  • identification of non-conformities and/or incidents indicating the incorrect scope
  • the overall maturity of ISMS (scope may increase over time)
  • change in processes and practices (e.g. ceasing certain activities)
  • outsourcing services.

Outsourcing and third parties

Outsourced may be defined as “Any element that is not wholly controlled, managed, built, implemented and maintained by staff employed by the organization.”
Cloud services may be defined as  “A shared computer-based storage solution for data that is based on a virtualized computing environment.” Cloud services can describe any shared environment, which can be provided both locally or outsourced.
All organizations will outsource some activities to third parties. Some third parties are taken so much for granted that, when questioned, staff do not remember them – e.g. the cleaning teams, waste removal contractors, and potentially accountants or auditors. Their activities may not be under scrutiny, yet they may have the highest levels of access.
There are many reasons why an organization may want or need to outsource some (or all) of its IT provision. As information technology changes and evolves extremely quickly, it can be more cost-effective to outsource some of an organization’s IT solution or to use cloud storage or services. Economies of scale mean that large data warehouse-style storage facilities can offer cheap storage and extremely good availability. Externally hosted services may also provide specialist IT knowledge and support that is not available within the organization. If managed properly, outsourced IT or cloud technology carries no greater risk and arguably less risk than managing an in-house IT environment. However, poorly sourced or managed outsourcing, or inappropriate cloud provision, can be extremely risky. When cloud services are used, there can be multiple parties involved in the production of the overall service. For example, infrastructure and software services can be provided by different organizations. Scoping in this context will involve having a clear understanding of the system components involved and the security responsibilities of each service provider. These security requirements should be included in any contractual agreements. Responsibility for implementing security may be outsourced, but the accountability cannot be, and so it is, therefore, important to understand the scope of an ISMS in this context. Put simply, when it comes to meeting certain security requirements, outsourced functions or processes will be in scope for an ISMS, but the suppliers are unlikely to be. It is up to the organization to decide how it may be assured that the services provided are of an appropriate standard.
Understanding an organization’s relationship with third parties is extremely important to ensure security for the business and the information that it holds, especially where information security may be put at risk by third party activities, even though their activities are not obviously related to information (e.g. cleaners). When working with any third party, it is important for information security that the following are defined:

  • Legal responsibility, accountability, and insurance: all the parties’ responsibilities must be detailed and understood. Running through a risk assessment process will uncover many areas where accountability needs to be defined. Disaster planning and incident response is also a good way of verifying that ownership and insurance responsibilities are correctly scoped.
  • Access and authorization: it is essential to make sure the rules and regulations for who can access what are clearly defined. If the organization is allowing contractors into buildings, it should understand who has the keys or access codes; and who ensures the staff is trained and things are secure. Out of hours office cleaning staff often have more physical access to an organization than even the most trusted day staff. Access to IT systems and data should also be considered.
  • Disclosure and privacy: the organization should define and categorize the information that is being used and shared, and specify the applicable rules and regulations.
  • Contract terms: The terms of contracts with third parties should be clearly defined to make sure that all parties are clear on the expectations of the work to be conducted, and sanctions or liabilities in the event of default are assigned.

When selecting a third party, questions such as the following should be considered:

  • What data are going to be on the outsourced system? Do the data include any sensitive information, or have special requirements?
  • What laws or regulations applicable to the service provider who is supplying the IT provision? If it is a company outside of the EU, how will that interact with the requirements of the data which it will handle? Where will the data itself be stored?
  • Who needs access to the IT solution? Is it something that needs a lot of physical involvement or does it not need any attention for many months?
  • Are there restrictions on who administers the system? Who will the administrators be and who controls the access rights?
  • Where is the system physically housed? Is the facility secured, who is it shared by, and who controls the access?
  • Does the outsourced service provider themselves outsource any of their provision (e.g. off-site back-ups)?
  • How do they manage the security controls which their third parties are handling?
  • What service level is expected or provided? What levels of assurance for confidentiality, availability, and integrity of data are there? Check the policies in place within your organization.
  • At the end of the business relationship, how will it be possible for the organization’s information to be extracted from the third party environment in a usable form?
  • What provisions (if any) are in place for compensating the organization for the impact of a business continuity incident or disaster (e.g. loss or exposure of information)?

Examples of Scope

1. Voice Connect design, develop, supply and support the following:
Integrated telephony and multiple media computer messaging products and services;
An Alarm Receiving Centre (ARC) that provides a lone worker monitoring service;
A Payment Portal that enables a cardholder to use a touch-tone phone to make payments.

2. The company is committed to protecting its information and that of its customers. To achieve this goal, the company has implemented an Information Security Management System in accordance with ISO/IEC 27001: 2013. The company’s ISMS is applicable to the following areas of the business:

  • Finance department
  • Internal IT systems and networks used for back-end business (such as email, timesheets, contract development and storage, and report writing)
    (Note: IT systems on which company software is developed and stored are part of the Software Development ISMS. Refer to the Software Development Security Manual for more information.)

3. The ISMS offers protection to all information processed stored in the E-commerce servers or transmitted through it and desktops connected to E-commerce servers through a dedicated LAN.
The e-commerce server and the desktops are located at the 3rd floor of MSTC LTD H.O. having its address at 225C, AJC Bose Road, Kolkata-700 020. It also includes the following :

  1. Law, HR and Admin functions associated with e-commerce.
  2. DR site located at 607 Raheja Centre, Nariman Point, Mumbai – 400 021.
  3. Development Server located at the 3rd floor of MSTC LTD H.O. having its address at 225C, AJC Bose Road, Kolkata-700 020

4. This ISMS applies to all information assets used or supported by Lancashire County Council in the course of its business. In the main, this refers to the information and record-keeping systems of the five Directorates and the three Direct Service Organisations but the specific areas covered by the ISMS are as follows.
Areas covered by this ISMS:

  • Corporate network and all assets connected to it including Pensions Scheme
  • All hardware-software and information records held by employees or agents of Lancashire County Council for Lancashire County Council business purposes
  • People’s Network
  • The LGFL network
  • Shared sites where facilities are supported by Lancashire County Council
  • Facilities owned by Lancashire County Council and connected to its networks but operated from the premises of other organizations.
  • Privately owned equipment used in the course of employment with the County Council
  • The Contact Centre
  • Telephony network

Areas not covered by the ISMS

  • LCDL
  • Organizations for which Lancashire County Council is merely the accountable body
  • Schools

4.4 Information security management system

The organization must establish, implement, maintain and continually improve an information security management system, in accordance with the requirements of this International Standard.

Organizations of all types and sizes:

1.collect, process, store, and transmit information;

2. recognize that information, and related processes, systems, networks, and people are important assets for achieving organization objectives;

3. face a range of risks that may affect the functioning of assets; and

4. address their perceived risk exposure by implementing information security controls.

All information held and processed by an organization is subject to threats of attack, error, nature (for example, flood or fire), etc., and is subject to vulnerabilities inherent in its use. The term information security is generally based on information being considered as an asset which has a value requiring appropriate protection, for example, against the loss of availability, confidentiality, and integrity. Enabling accurate and complete information to be available in a timely manner to those with authorized needs is a catalyst for business efficiency. Protecting information assets through defining, achieving, maintaining, and improving information security effectively is essential to enable an organization to achieve its objectives, and maintain and enhance its legal compliance and image. These coordinated activities directing the implementation of suitable controls and treating unacceptable information security risks are generally known as elements of information security management. As information security risks and the effectiveness of controls change depending on shifting circumstances, organizations need to:

1.monitor and evaluate the effectiveness of implemented controls and procedures;

2. identify emerging risks to be treated; and

3. select, implement and improve appropriate controls as needed.

To interrelate and coordinate such information security activities, each organization needs to establish its policy and objectives for information security and achieve those objectives effectively by using a management system.
An Information Security Management System (ISMS) consists of the policies,  procedures, guidelines, and associated resources and activities, collectively managed by an organization, in the pursuit of protecting its information assets. An ISMS is a systematic approach for establishing, implementing, operating, monitoring, reviewing, maintaining and improving an organization’s information security to achieve business objectives. It is based upon a risk assessment and the organization’s risk acceptance levels designed to effectively treat and manage risks. Analyzing requirements for the protection of information assets and applying appropriate controls to ensure the protection of these information assets, as required, contributes to the successful implementation of an ISMS. The following fundamental principles also contribute to the successful implementation of an ISMS:

  1. awareness of the need for information security;
  2. assignment of responsibility for information security;
  3. incorporating management commitment and the interests of stakeholders;
  4. enhancing societal values;
  5. risk assessments determining appropriate controls to reach acceptable levels of risk;
  6. security incorporated as an essential element of information networks and systems;
  7. active prevention and detection of information security incidents;
  8. ensuring a comprehensive approach to information security management; and
  9. continual reassessment of information security and the making of modifications as appropriate.

Information

Information is an asset that, like other important business assets, is essential to an organization’s business and consequently needs to be suitably protected. Information can be stored in many forms, including digital form (e.g. data files stored on electronic or optical media), material form (e.g. on paper), as well as unrepresented information in the form of knowledge of the employees. Information may be transmitted by various means including courier, electronic or verbal communication. Whatever form information takes, or the means by which the information is transmitted, it always needs appropriate protection. In many organizations, information is dependent upon information and communications technology. This technology is often an essential element in the organization and assists in facilitating the creation, processing, storing, transmitting, protection and destruction of information.

Information security

Information security includes three main dimensions: confidentiality, availability, and integrity. Information security involves the application and management of appropriate security measures that involves consideration of a wide range of threats, with the aim of ensuring sustained business success and continuity and minimizing impacts of information security incidents. Information security is achieved through the implementation of an applicable set of controls, selected through the chosen risk management process and managed using an ISMS, including policies, processes, procedures, organizational structures, software, and hardware to protect the identified information assets. These controls need to be specified, implemented, monitored, reviewed and improved where necessary, to ensure that the specific information security and business objectives of the organization are met. Relevant information security controls are expected to be seamlessly integrated with an organization’s business processes.

Management

Management involves activities to direct, control and continually improve the organization within appropriate structures. Management activities include the act, manner, or practice of organizing, handling, directing, supervising, and controlling resources. Management structures extend from one person in a small organization to management hierarchies consisting of many individuals in large organizations. In terms of an ISMS, management involves the supervision and making of decisions necessary to achieve business objectives through the protection of the organization’s information assets. Management of information security is expressed through the formulation and use of information security policies, procedures, and guidelines, which are then applied throughout the organization by all individuals associated with the organization.

Management system

A management system uses a framework of resources to achieve an organization’s objectives. The management system includes organizational structure, policies, planning activities, responsibilities,  practices, procedures, processes, and resources.
In terms of information security, a management system allows an organization to:
a) satisfy the information security requirements of customers and other stakeholders;
b) improve an organization’s plans and activities;
c) meet the organization’s information security objectives;
d) comply with regulations, legislation and industry mandates; and
e) manage information assets in an organized way that facilitates continual improvement and adjustment to current organizational goals.

Process approach

Organizations need to identify and manage many activities in order to function effectively and efficiently. Any activity using resources needs to be managed to enable the transformation of inputs into outputs using a set of interrelated or interacting activities – this is also known as a process. The output from one process can directly from the input to another process and generally this transformation is carried out under planned and controlled conditions. The application of a system of processes within an organization, together with the identification and interactions of these processes, and their management, can be referred to as a “process approach”.

Establishing, monitoring, maintaining and improving an ISMS

1.Overview
An organization needs to undertake the following steps in establishing, monitoring, maintaining and improving its ISMS:

  1. identify information assets and their associated information security requirements
  2.  assess information security risks and treat information security risks
  3. select and implement relevant controls to manage unacceptable risks  and
  4. monitor, maintain and improve the effectiveness of controls associated with the organization’s information assets.

To ensure the ISMS is effectively protecting the organization’s information assets on an ongoing basis, it is necessary for mentioned steps to be continually repeated to identify changes in risks or in the organization’s strategies or business objectives.

2. Identifying information security requirements
Within the overall strategy and business objectives of the organization, its size, and geographical spread, information security requirements can be identified through an understanding of:

  1. identified information assets and their value;
  2. business needs for information processing, storage and communication; and
  3. legal, regulatory, and contractual requirements.

Conducting a methodical assessment of the risks associated with the organization’s information assets will involve analyzing: threats to information assets; vulnerabilities to and the likelihood of a threat materializing to information assets; and the potential impact of any information security incident on information assets. The expenditure on relevant controls is expected to be proportionate to the perceived business impact of the risk materializing.

3. Assessing information security risks
Managing information security risks requires a suitable risk assessment and risk treatment method which may include an estimation of the costs and benefits, legal requirements, the concerns of stakeholders, and other inputs and variables as appropriate. Risk assessments should identify, quantify, and prioritize risks against criteria for risk acceptance and objectives relevant to the organization. The results should guide and determine the appropriate management action and priorities for managing information security risks and for implementing controls selected to protect against these risks. Risk assessment should include the systematic approach of estimating the magnitude of risks (risk analysis) and the process of comparing the estimated risks against risk criteria to determine the significance of the risks (risk evaluation). Risk assessments should be performed periodically to address changes in the information security requirements and in the risk situation, e.g. in the assets, threats, vulnerabilities, impacts, the risk evaluation, and when significant changes occur. These risk assessments should be undertaken in a methodical manner capable of producing comparable and reproducible results. The information security risk assessment should have a clearly defined scope in order to be effective and should include relationships with risk assessments in other areas, if appropriate.

4. Treating information security risks
Before considering the treatment of risk, the organization should decide the criteria for determining whether or not risks can be accepted. Risks may be accepted if, for example, it is assessed that the risk is low or that the cost of treatment is not cost-effective for the organization. Such decisions should be recorded. For each of the risks identified following the risk assessment, a risk treatment decision needs to be made. Possible options for risk treatment include:

  1. applying appropriate controls to reduce the risks;
  2. knowingly and objectively accepting risks, providing they clearly satisfy the organization’s policy and criteria for risk acceptance;
  3. avoiding risks by not allowing actions that would cause the risks to occur;
  4. sharing the associated risks to other parties, e.g. insurers or suppliers.

For those risks where the risk treatment decision has been to apply appropriate controls, these controls should be selected and implemented.

1.Selecting and implementing controls
Once information security requirements have been identified, information security risks to the identified information assets have been determined and assessed and decisions for the treatment of information security risks having been made, then selection and implementation of controls for risk reduction apply.  Controls should ensure that risks are reduced to an acceptable level taking into account:

  1. requirements and constraints of national and international legislation and regulations;
  2. organizational objectives;
  3. operational requirements and constraints;
  4. their cost of implementation and operation in relation to the risks being reduced, and remaining proportional to the organization’s requirements and constraints;
  5. they should be implemented to monitor, evaluate and improve the efficiency and effectiveness of information security controls to support the organization’s aims. The selection and implementation of controls should be documented within a statement of applicability to assist with compliance requirements.
  6. the need to balance the investment in implementation and operation of controls against the loss likely to result from information security incidents.

The controls specified in ISO/IEC 27002 are acknowledged as best practices applicable to most organizations and readily tailored to accommodate organizations of various sizes and complexities. Other standards in the ISMS family of standards provide guidance on the selection and application of ISO/IEC 27002 controls for the information security management system. Information security controls should be considered at the systems and projects requirements specification and design stage. Failure to do so can result in additional costs and less effective solutions, and maybe, in the worst case, the inability to achieve adequate security. Controls can be selected from ISO/IEC 27002 or from other control sets, or new controls can be designed to meet the specific needs of the organization. It is necessary to recognize that some controls may not be applicable to every information system or environment, and might not be practicable for all organizations. Sometimes it takes time to implement a chosen set of controls and during that time the level of risk may be higher than can be tolerated on a long term basis. Risk criteria should cover the tolerability of risks on a short-term basis while controls are being implemented. Interested parties should be informed of the levels of risk that are estimated or anticipated at different points in time as controls are progressively
implemented. It should be kept in mind that no set of controls can achieve complete information security. Additional management actions should be implemented to monitor, evaluate and improve the efficiency and effectiveness of information security controls to support the organization’s aims. The selection and implementation of controls should be documented within a statement of applicability to assist with compliance requirements.

2. Monitor, maintain and improve the effectiveness of the ISMS
An organization needs to maintain and improve the ISMS through monitoring and assessing performance against organizational policies and objectives and reporting the results to management for review. This ISMS review will check that the ISMS includes specified controls that are suitable to treat risks within the ISMS scope. Furthermore, based on the records of these monitored areas, it will provide evidence of verification, and tractability of corrective, preventive and improvement actions.

3. Continual improvement
The aim of continual improvement of an ISMS is to increase the probability of achieving objectives concerning the preservation of the confidentiality, availability, and integrity of information. The focus of continual improvement is seeking opportunities for improvement and not assuming that existing management activities are good enough or as good as they can. Actions for improvement include the following:

  1. analyzing and evaluating the existing situation to identify areas for improvement;
  2. establishing the objectives for improvement;
  3. searching for possible solutions to achieve the objectives;
  4. evaluating these solutions and making a selection;
  5. implementing the selected solution;
  6. measuring, verifying, analyzing and evaluating results of the implementation to determine that the objectives have been met;
  7.  formalizing changes.

Results are reviewed, as necessary, to determine further opportunities for improvement. In this way, improvement is a continual activity, i.e. actions are repeated frequently. Feedback from customers and other interested parties, audits, and review of the information security management system can also be used to identify opportunities for improvement.

ISMS critical success factors

A large number of factors are critical to the successful implementation of an ISMS to allow an organization to meet its business objectives. Examples of critical success factors include:

1 information security policy, objectives, and activities aligned with objectives;

2. an approach and framework for designing, implementing, monitoring, maintaining, and improving information security consistent with the organizational culture;

3. visible support and commitment from all levels of management, especially top management;

4. an understanding of information asset protection requirements achieved through the application of information security risk management ;

5. an effective information security awareness, training, and education program informing all employees and other relevant parties of their information security obligations set forth in the information security policies, standards, etc., and motivating them to act accordingly;

6. an effective information security incident management process;

7. an effective business continuity management approach; and

8, a measurement system used to evaluate performance in information security management and feedback suggestions for improvement. An ISMS increases the likelihood that an organization will consistently achieve the critical success factors required to protect its information assets.

Back to Home Page

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion are also welcome.

 

ISO 27001:2013 Information Security Management System

by Pretesh Biswas

Overview of an Information Security Management System

Information security is the protection of information to ensure:

  • Confidentiality: ensuring that the information is accessible only to those authorized to access it.
  • Integrity: ensuring that the information is accurate and complete and that the information is not modified without authorization.
  • Availability: ensuring that the information is accessible to authorized users when required.

Information security is achieved by applying a suitable set of controls (policies, processes, procedures, organizational structures, and software and hardware functions). An Information Security Management System (ISMS) is the way to protect and manage information based on a systematic business risk approach, to establish, implement, operate, monitor, review, maintain, and improve information security. It is an organizational approach to information security.
ISO publishes two standards that focus on an organization’s ISMS:

  • The code of practice standard: ISO 27002. This standard can be used as a starting point for developing an ISMS. It provides guidance for planning and implementing a program to protect information assets. It also provides a list of controls (safeguards) that you can consider implementing as part of your ISMS.
  • The management system standard: ISO 27001. This standard is the specification for an ISMS. It explains how to apply ISO/IEC 27002. It provides the standard against which certification is performed, including a list of required documents. An organization that seeks certification of its ISMS is examined against this standard.

The standards set forth the following practices:

  • All activities must follow a method. The method is arbitrary but must be well defined and documented.
  • A company or organization must document its own security goals. An auditor will verify whether these requirements are fulfilled.
  • All security measures used in the ISMS shall be implemented as the result of risk analysis in order to eliminate or reduce risks to an acceptable level.
  • The standard offers a set of security controls. It is up to the organization to choose which controls to implement based on the specific needs of their business.
  • A process must ensure the continuous verification of all elements of the security system through audits and reviews.
  • A process must ensure the continuous improvement of all elements of the information and security management system. (The ISO 27001 standard adopts the Plan-Do-Check-Act [PDCA] model as its basis and expects the model will be followed in an ISMS implementation.)

These practices form the framework within which you will establish an ISMS.

1 Purchase a copy of the ISO/IEC standards

Before establishing an ISMS and drafting the various documents for your ISMS, you should purchase copies of the pertinent ISO/IEC standards, namely:
a) The code of practice standard: ISO 27002. This standard can be used as a starting point for developing an ISMS. It provides guidance for planning implementing a program to protect information assets. It also provides a list of controls (safeguards) that you can consider implementing as part of your ISMS.
b) The management system standard: ISO/IEC 27001. This standard is the specification for an ISMS. It explains how to apply ISO 27002. It provides the standard against which certification is performed, including a list of required documents. An organization that seeks certification of its ISMS is examined against this standard.

2 Obtain management support

As described in ISO/IEC 27001, management plays an important role in the success of an ISMS.
What you need: Management responsibility section of ISO 27001. Management must make a commitment to the establishment, implementation, operation, monitoring, review, maintenance, and improvement of the ISMS. Commitment must include activities such as ensuring that the proper resources are available to work on the ISMS and that all employees affected by the ISMS have the proper training, awareness, and competency.
Results: Establishment of the following items demonstrates management commitment:

  • An information security policy; this policy can be a standalone document or part of an overall security manual that is used by an organization.
  • Information security objectives and plans; again this information can be a standalone document or part of an overall security manual that is used by an organization
  • Roles and responsibilities for information security; a list of the roles related to information security should be documented either in the organization’s job description documents or as part of the security manual or ISMS description documents.
  • Announcement or communication to the organization about the importance of adhering to the information security policy.
  • Sufficient resources to manage, develop, maintain, and implement the ISMS.

In addition, management will participate in the ISMS Plan-Do-Check-Act [PDCA] process, as described in ISO 27001 by:

  • Determining the acceptable level of risk. Evidence of this activity can be incorporated into the risk assessment documents, which are described later in this guide.
  • Conducting management reviews of the ISMS at planned intervals. Evidence of this activity can be part of the approval process for the documents in the ISMS.
  • Ensuring that personnel affected by the ISMS are provided with training, are competent for the roles and responsibilities they are assigned to fulfill, and are aware of those roles and responsibilities. Evidence of this activity can be through employee training records and employee review documents.

Example:
This example shows a possible policy statement with goals and objectives.

Example of Security Policy

3 Determine the scope of the ISMS

When management has made the appropriate commitments, you can begin to establish your ISMS. In this step, you should determine the extent to which you want the ISMS to apply to your organization.
What you need:
You can use several of the “result” documents that were created as part of step 2, such as:

  • The information security policy
  • The information security objectives and plans
  • The roles and responsibilities that are related to information security and were defined by the management

In addition, you will need:

  • Lists of the areas, locations, assets, and technologies of the organization that will be controlled by the ISMS.
  • What areas of your organization will be covered by the ISMS?
  • What are the characteristics of those areas; its locations, assets, technologies to be included in the ISMS?
  • Will you require your suppliers to abide by your ISMS?
  • Are there dependencies on other organizations? Should they be considered?

Your goals will be to cover the following:

  • the processes used to establish the scope and context of the ISMS.
  • the strategic and organizational context

Important: Keep your scope manageable. Consider including only parts of the organization, such as a logical or physical grouping within the organization. Large organizations might need several Information Security Management Systems in order to maintain manageability. For example, they might have one ISMS for their Finance department and the networks used by that department and a separate ISMS for their Software Development department and systems.
Results: A documented scope for your ISMS.
When you have determined the scope, you will need to document it, usually in a few statements or paragraphs. The documented scope often becomes one of the first sections of your organization’s Security Manual. Or, it might remain a standalone document in a set of ISMS documents that you plan to maintain. Often the scope, the security policy, and the security objectives are combined into one document.

Example

Example of Scope Statements

4 Identify applicable legislation

After you have determined the scope, identify any regulatory or legislative standards that apply to the areas you plan to cover with the ISMS. Such standards might come from the industry in which your organization works or from state, local, or federal governments, or international regulatory bodies.
What you need: Up-to-date regulatory or legislative standards that might be applicable to your organization. You might find it helpful to have input and review from lawyers or specialists who are knowledgeable about the standards.
Results: Additional statements in the scope of the ISMS. If your ISMS will incorporate more than two or three legislative or regulatory standards, you might also create a separate document or appendix in the Security Manual that lists all of the applicable standards and details about the standards.
Example: The text added to the scope statement as a result of identifying applicable legislation is shown in the following example.

Scope and Purpose
The company is committed to protecting its information and that of its customers. To achieve this goal, the company has implemented an Information Security Management System in accordance with ISO 27001: 2013 and the rules and regulations that are part of Information Technology Act, 2000 also know as IT Act. 
The company’s ISMS is applicable to the following areas of the business:
• Finance department
• Internal IT systems and networks used for back-end business (such as email, timesheets, contract development and storage, and report writing)
(Note: IT systems and networks on which company software is developed and stored are part of the Software Development ISMS.)

 Example of Additional Scope Text

5 Define a method of risk assessment

Risk assessment is the process of identifying risks by analyzing threats to, impacts on, and vulnerabilities of information and information systems and processing facilities, and the likelihood of their occurrence. Choosing a risk assessment method is one of the most important parts of establishing an ISMS. To meet the requirements of ISO 27001, you will need to define and document a method of risk assessment and then use it to assess the risk to your identified information assets, make decisions about which risks are intolerable and therefore need to be mitigated, and manage the residual risks through carefully considered policies, procedures, and controls.
ISO does not specify the risk assessment method you should use; however, it does state that you must use a method that enables you to complete the following tasks:

  • Evaluate risk based on levels of confidentiality, integrity, and availability. Some risk assessment methods provide a matrix that defines levels of confidentiality, integrity, and availability and provides guidance as to when and how those levels should be applied, as shown in the following table:
  • Set objectives to reduce risk to an acceptable level
  • Determine criteria for accepting the risk
  • Evaluate risk treatment options.

There are many risk assessment methods you can choose from, such as those that are prevalent in your industry. For example, if your company is in the oil industry, you might find there are risk assessment methods related to that industry.

When you have completed this step, you should have a document that explains how your organization will assess risk, including:

  • the organization’s approach to information security risk management
  • criteria for information security risk evaluation and the degree of assurance required

6 Create an inventory of information assets to protect

To identify risks and the levels of risks associated with the information you want to protect, you first need to make a list of all of your information assets that are covered in the scope of the ISMS.
What you will need:
You will need the scope that you defined in step 3 and input from the organization that is defined in your scope regarding its information assets.
Result:
When you have completed this step, you should have a list of the information assets to be protected and an owner for each of those assets. You might also want to identify where the information is located and how critical or difficult it would be to replace. This list should be part of the risk assessment methodology document that you created in the previous step.
Because you will need this list to document your risk assessment, you might want to group the assets into categories and then make a table of all the assets with columns for assessment information and the controls you choose to apply.
The following example shows an asset table.
Example:

Example of Asset Table with Placeholder Columns for Assessment Information

7 Identify risks

Next, for each asset you defined in the previous step, you will need to identify risks and classify them according to their severity and vulnerability. In addition, you will need to identify the impact that loss of confidentiality, integrity, and availability may have on the assets.
To begin identifying risks, you should start by identifying actual or potential threats and vulnerabilities for each asset. A threat is something that could cause harm. For example, a threat could be any of the following:

  • A declaration of the intent to inflict harm or misery
  • Potential to cause an unwanted incident, which may result in harm to a system or organization and its assets
  • The intentional, accidental, or man-made act that could inflict harm or an act of God (such as a hurricane or tsunami)

A vulnerability is a source or situation with a potential for harm (for example, a broken window is a vulnerability; it might encourage harm, such as a break-in). A risk is a combination of the likelihood and severity or frequency that a specific threat will occur.
What you will need:

  • The list of assets that you defined in the previous step
  • The risk assessment methodology you defined in step 5

For each asset, you should identify vulnerabilities that might exist for that asset and threats that could result from those vulnerabilities. It is often helpful to think about threats and vulnerabilities in pairs, with at least one pair for each asset and possibly multiple pairs for each asset.
Results:
For each asset, you will have a threat and vulnerability description and, using your Risk Assessment methodology, you will assign levels of confidentiality, integrity, and availability to that asset.
If you used a table for step 6, you can add this information to that table, as shown in the following example.
Example:
In the following example, the Risk Summary column describes the threat and vulnerability. The CIA profile classifies the asset’s confidentiality, integrity, and availability.

Example of Risk Identification

8 Assess the risks

After you have identified the risks and the levels of confidentiality, integrity, and availability, you will need to assign values to the risks. The values will help you determine if the risk is tolerable or not and whether you need to implement a control to either eliminate or reduce the risk. To assign values to risks, you need to consider:

  • The value of the asset being protected
  • The frequency with which the threat or vulnerability might occur
  • The damage that the risk might inflict on the company or its customers or partners

For example, you might assign values of Low, Medium, and High to your risks. To determine which value to assign, you might decide that if the value of an asset is high and the damage from a specified risk is high, the value of the risk should also be high, even though the potential frequency is low. Your Risk Assessment Methodology document should tell you what values to use and might also specify the circumstances under which specific values should be assigned. Also, be sure to refer to your Risk Assessment Methodology document to determine the implication of a certain risk value. For example, to keep your ISMS manageable, your Risk Assessment Methodology might specify that only risks with a value of Medium or High will require control in your ISMS. Based on your business needs and industry standards, risk will be assigned appropriate values.
What you will need:

  • Lists of assets and their associated risks and CIA levels, which you created in the previous step.
  • Possibly input from management as to what level of risk they are willing to accept for specific assets.

Results:
When you have completed your assessment, you will have identified which information assets have intolerable risk and therefore require controls. You should have a document (sometimes referred to as a Risk Assessment Report) that indicates the risk value for each asset. In the next step, you will identify which controls might be applicable for the assets that require control in order to reduce the risk to tolerable levels. This document can either be standalone or it can be part of an overall Risk Assessment document that contains your risk assessment methodology and this risk assessment.
Examples:
If you used a table similar to the one in the preceding examples, your result after completing this step might look like the following example:

Example of Risk Assessment

9 Identify applicable objectives and controls

Next, for the risks that you’ve determined to be intolerable, you must take one of the following actions:

  • decide to accept the risk, for example, actions are not possible because they are out of your control (such as natural disaster or political uprising) or are too expensive.
  • transfer the risk, for example, purchase insurance against the risk, subcontract the activity so that the risk is passed on to the subcontractor, etc.
  • reduce the risk to an acceptable level through the use of controls.

To reduce the risk, you should evaluate and identify appropriate controls. These controls might be controls that your organization already has in place or controls that are defined in the ISO 27002  standard.
(Note: An examination of the controls that you already have in place against the standard and then using the results to identify what controls are missing is commonly called a “gap analysis.”)
What you will need:

  • Annex A of ISO 27001. This appendix summarizes controls that you might want to choose from.
  • ISO 27002, which provides greater detail about the controls summarized in ISO 27001.
  • Procedures for existing corporate controls

Results:
You should end up with two documents by completing this step:

  • A Risk Treatment Plan
  • A Statement of Applicability

The Risk Treatment Plan documents the following:

  • the method selected for treating each risk (accept, transfer, reduce)
  • which controls are already in place
  • what additional controls are proposed
  •  the time frame over which the proposed controls are to be implemented

The Statement of Applicability (SOA) documents the control objectives and controls selected from Annex A. The Statement of Applicability is usually a large table in which each control from Annex A of ISO/IEC 27001 is listed with its description and corresponding columns that indicate whether that control was adopted by the organization, the justification for adopting or not adopting the control, and a reference to the location where the organization’s procedure for using that control is documented. The SOA can be part of the Risk Assessment document, but usually, it is a standalone document because it is lengthy and is listed as a required document in the standard. For additional help with creating a Risk Treatment Plan and a Statement of Applicability, refer to the two sets of examples that follow.

Examples of Risk Treatment Plan:
If you used a table as described in the preceding steps, the control analysis portion of your Risk Treatment Plan could be covered by the Control column and the Sufficient Control column, as shown in the following example. Any risks that you transfer to others or that you choose to accept as they are should also be recorded in your treatment plan.

The remaining Risk Treatment Plan requirements could be met by adding this table and by explaining the methods used for treating risk and the time frame in which the controls will be implemented to a Risk Assessment Methodology document, like the one you created in step 5.

Example of Statement of Applicability:

The following is an excerpt of a Statement of Applicability document. The Reference column identifies the location where the statement of policy or detailed procedure related to the implementation of the control is documented.

Example of Statement of Applicability

10 Set up policy, procedures and Documented Information to control risks

For each control that you define, you must have corresponding statements of policy or in some cases a detailed procedure. The procedure and policies are used by affected personnel so they understand their roles and so that the control can be implemented consistently. The documentation of the policy and procedures is a requirement of ISO 27001.
What you will need:
To help you identify which procedures you might need to document, refer to your Statement of Applicability. To help you write your procedures so that they are consistent in content and appearance, you might want to create some type of template for your procedure writers to use.
Results:
Additional policy and documented Information. (The number of documents you produce will depend on the requirements of your organization.) Some of these procedures might also generate records. For example, if you have a procedure that all visitors to your facility must sign a visitors log, the log itself becomes a record providing evidence that the procedure has been followed.
Example:
The number of policies, procedures, and records that you will require as part of your ISMS will depend on a number of factors, including the number of assets you need to protect and the complexity of the controls you need to implement. The example that follows shows a partial list of one organization’s set of documents:

Mandatory documents and records required by ISO 27001:2013

  • Scope of the ISMS (clause 4.3)
  • Information security policy and objectives (clauses 5.2 and 6.2)
  • Risk assessment and risk treatment methodology (clause 6.1.2)
  • Statement of Applicability (clause 6.1.3 d)
  • Risk treatment plan (clauses 6.1.3 e and 6.2)
  • Risk assessment report (clause 8.2)
  • Definition of security roles and responsibilities (clauses A.7.1.2 and A.13.2.4)
  • Inventory of assets (clause A.8.1.1)
  • Acceptable use of assets (clause A.8.1.3)
  • Access control policy (clause A.9.1.1)
  • Operating procedures for IT management (clause A.12.1.1)
  • Secure system engineering principles (clause A.14.2.5)
  • Supplier security policy (clause A.15.1.1)
  • Incident management procedure (clause A.16.1.5)
  • Business continuity procedures (clause A.17.1.2)
  • Statutory, regulatory, and contractual requirements (clause A.18.1.1)

And here are the mandatory records:

  • Records of training, skills, experience, and qualifications (clause 7.2)
  • Monitoring and measurement results (clause 9.1)
  • Internal audit program (clause 9.2)
  • Results of internal audits (clause 9.2)
  • Results of the management review (clause 9.3)
  • Results of corrective actions (clause 10.1)
  • Logs of user activities, exceptions, and security events (clauses A.12.4.1 and A.12.4.3)

Non-mandatory documents
There are numerous non-mandatory documents that can be used for ISO 27001 implementation, especially for the security controls from Annex A. However, I find these non-mandatory documents to be most commonly used:

  • Procedure for document control (clause 7.5)
  • Controls for managing records (clause 7.5)
  • Procedure for internal audit (clause 9.2)
  • Procedure for corrective action (clause 10.1)
  • Bring your own device (BYOD) policy (clause A.6.2.1)
  • Mobile device and teleworking policy (clause A.6.2.1)
  • Information classification policy (clauses A.8.2.1, A.8.2.2, and A.8.2.3)
  • Password policy (clauses A.9.2.1, A.9.2.2, A.9.2.4, A.9.3.1, and A.9.4.3)
  • Disposal and destruction policy (clauses A.8.3.2 and A.11.2.7)
  • Procedures for working in secure areas (clause A.11.1.5)
  • Clear desk and clear screen policy (clause A.11.2.9)
  • Change management policy (clauses A.12.1.2 and A.14.2.4)
  • Backup policy (clause A.12.3.1)
  • Information transfer policy (clauses A.13.2.1, A.13.2.2, and A.13.2.3)
  • Business impact analysis (clause A.17.1.1)
  • Exercising and testing plan (clause A.17.1.3)
  • Maintenance and review plan (clause A.17.1.3)
  • Business continuity strategy (clause A.17.2.1)

11 Allocate resources and train the staff

Adequate resources (people, time, money) should be allocated to the operation of the ISMS and all security controls. In addition, the staff who must work within the ISMS (maintaining it and its documentation and implementing its controls) must receive appropriate training. The success of the training program should be monitored to ensure that it is effective. Therefore, in addition to the training program, you should also establish a plan for how you will determine the effectiveness of the training.
What you will need:

  • A list of the employees who will work within the ISMS
  • All of the ISMS procedures to use for identifying what type of training is needed and which members of the staff or interested parties will require training
  • Management agreement to the resource allocation and the training plans.

Results:
Specific documentation is not required in the ISO/IEC standards. However, to provide evidence that resource planning and training has taken place, you should have some documentation that shows who has received training and what training they have received. In addition, you might want to include a section for each employee that lists what training they should be given. Also, you will probably have some type of procedure for determining how many people, how much money, and how much time needs to be allocated to the implementation and maintenance of your ISMS. It’s possible that this procedure already exists as part of your business operating procedures or that you will want to add an ISMS section to that existing documentation.

12 Monitor the implementation of the ISMS

To ensure that the ISMS is effective and remains current, suitable, adequate, and effective, ISO 27001 requires:

  • Management to review the ISMS at planned intervals. The review must include assessing opportunities for improvement, and the need for changes to the ISMS, including the security policy and security objectives, with specific attention to previous corrective or preventative actions and their effectiveness.
  • Periodic internal audits. The results of the reviews and audits must be documented and records related to the reviews and audits must be maintained.

What you will need:
To perform management reviews, ISO 27001 requires the following input:

  • results of ISMS internal and external audits and reviews
  • feedback from interested parties
  • techniques, products, or procedures which could be used in the organization to improve the effectiveness of the ISMS
  • preventative and corrective actions (including those that might have been identified in previous reviews or audits)
  • incident reports, for example, if there has been a security failure, a report that identifies what the failure was, when it occurred, and how it was handled and possibly corrected.
  • vulnerabilities or threats not adequately addressed in the previous risk assessment
  • follow-up actions from previous reviews
  • any organizational changes that could affect the ISMS
  • recommendations for improvement

To perform internal audits on a periodic basis, you need to define the scope, criteria, frequency, and methods. You also need the procedure (which should have been written as part of step 10) that identifies the responsibilities and requirements for planning and conducting the audits, and for reporting results and maintaining records.
Results:
The results of a management review should include decisions and actions related to:

  • Improvements to the ISMS
  • Modification of procedures that affect information security at all levels within the organization
  • Resource needs
  • The results of an internal audit should result in the identification of nonconformities and their related corrective actions or preventative actions. ISO 27001 lists the activity and record requirements related to corrective and preventative actions.

13 Prepare for the certification audit

If you plan to have your ISMS certified, you will need to conduct a full cycle of internal audits, management review, and activities in the PDCA process. The external auditor will first examine your ISMS documents to determine the scope and content of your ISMS. Then the auditor will examine the necessary records and evidence that you implement and practice what is stated in your ISMS.
What you will need:

  • All of the documents that you created in the preceding steps.
  • Records from at least one full cycle of management reviews, internal audits, and PDCA activities, and evidence of responses taken as the result of those reviews and audits.

Results:
The results of this preparation should be a set of documents that you can send to an auditor for review and a set of records and evidence that will demonstrate how efficiently and completely you have implemented your ISMS.

14 Ask for help

As you can see, establishing, implementing, and maintaining an ISMS can require a lot of work—especially in its formative stages. If you are new to management systems or specifically to information security management systems, you can consider hiring us to guide you through the process. Our familiarity with the requirements of an ISMS and the suggested controls in the IEO standards can save you time and money and will ensure that you will achieve effective security practices and possibly a successful ISMS certification.

ISO 27001:2013 structure

Clause 0: Introduction

In the previous version ISO 27001:2005, the PDCA model was in the Introduction section. In ISO 9001:2013, the section on the PDCA model has been removed. The reason for this is that the requirement is for continual improvement and PDCA is just one approach to meeting that requirement. There are other approaches, and organizations are now free to use them if they wish. The introduction also draws attention to the order in which requirements are presented, stating that the order does not reflect their importance or imply the order in which they are to be implemented. The Introduction no longer refers to any ‘model’, just requirements, and it now states explicitly the objective of an information security management system (ISMS) ‘preserve the confidentiality, integrity, and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed’. It also emphasizes that the ISMS is part of and integrated with the organization’s processes and overall management structure; this reinforces a key message – the ISMS is not a bolt-on to the business. It reinforces this by stating that information security is considered in the design of processes, information systems, and controls. The contents of an ISMS continues to be made up of the usual components i.e. Policy, Resources, Management Processes, Information security risk assessment and treatment, Statement of Applicability, Documented Information and ISM processes deemed relevant to the organization. There is the only small but significant difference: previously the standard could be used to assess conformance now it is to assess the organization’s ability to meet the organization’s own information security requirements. The compatibility clause remains and is tangibly demonstrated and reinforced by the adoption of Annex SL.

Clause 1: Scope

The purpose of this clause is to state the applicability of the standard through the requirements to establish, implement and continually improving an ISMS within the context of the organization. It goes on to require the assessment and treatment of information security risks tailored to the needs of the organization. This compares to the implementation of security controls in the 2005 edition. This, too, is a much shorter clause compared to the previous edition. In particular, there is no reference to the exclusion of controls in Annex A. Clause 1.2 Application (and exclusion) which was there in the previous version has been deleted. This is a significant change – exclusions are not acceptable.

Clause 2: Normative references

The only normative reference is to ISO/IEC 27000, Information technology — Security techniques — Information security management systems — Overview and vocabulary.

Clause 3: Terms and definitions

Unlike the 2005 edition, there are no terms and definitions included. All the common terms and definitions from Annex SL are included plus additions, changes, and deletions from the 2012 edition of ISO/IEC 27000. A comparison should be made and where necessary, further clarification sought from the other documents referenced. However, please ensure that you use a version of ISO/IEC 27000 that was published after ISO/IEC 27001:2013 otherwise it will not contain the correct terms or definitions. This is an important document to read. Many definitions, for example ‘management system’ and ‘control’, have been changed and now conform to the definitions given in the new ISO directives and ISO 31000. If a term is not defined in ISO/IEC 27000, please use the definition given in the Oxford English Dictionary. This is important, otherwise, confusion and misunderstanding may be the result

Clause 4: Context of the organization

This clause that in part addresses the depreciated concept of preventive action and in part establishes the context for the ISMS. It meets these objectives by drawing together relevant external and internal issues i.e. those that affect the organization’s ability to achieve the intended outcome of its ISMS with the requirements of interested parties to determine the scope of the ISMS. It should be noted that the term ‘issue’ covers not only problems, which would have been the subject of preventive action in the previous standard, but also important topics for the ISMS to address, such as any market assurance and governance goals that the organization might set for the ISMS.
Note that the term ‘requirement’ is a ‘need or expectation that is stated, generally implied or obligatory’. Combined with Clause 4.2, this in itself can be thought of as a governance requirement, as strictly speaking an ISMS that did not conform to generally-accepted public expectations could now be ruled non-conformant with the standard.
The final requirement (Clause 4.4) is to establish, implement, maintain and continually improve the ISMS in accordance with the requirements the standard.

Clause 5: Leadership

This clause places requirements on ‘top management’ which is the person or group of people who directs and controls the organization at the highest level. Note that if the organization that is the subject of the ISMS is part of a larger organization, then the term ‘top management’ refers to the smaller organization. The purpose of these requirements is to demonstrate leadership and commitment by leading from the top. A particular responsibility of top management is to establish the information security policy, and the standard defines the characteristics and properties that the policy is to include. Finally, the clause places requirements on top management to assign information security-relevant responsibilities and authorities, highlighting two particular roles concerning ISMS conformance to ISO  27001 and reporting on ISMS performance.

Clause 6: Planning

Clause 6.1.1 (General) works with Clauses 4.1 and 4.2 to complete the new way of dealing with preventive actions. The first part of this clause (i.e. down to and including 6.1.1 c)) concerns risk assessment whilst Clause 6.1.1 d) concerns risk treatment. As the assessment and treatment of information security risk is dealt with in Clauses 6.1.2 and 6.1.3, then organizations could use this clause to consider ISMS risks and opportunities.
Clause 6.1.2 (Information security risk assessment) specifically concerns the assessment of information security risk. In aligning with the principles and guidance given in ISO 31000, this clause removes the identification of assets, threats, and vulnerabilities as a prerequisite to risk identification. This widens the choice of risk assessment methods that an organization may use and still conforms to the standard. The clause also refers to ‘risk assessment acceptance criteria’, which allows criteria other than just a single level of risk. Risk acceptance criteria can now be expressed in terms other than levels, for example, the types of control used to treat risk. The clause refers to ‘risk owners’ rather than ‘asset owners’ and later requires their approval of the risk treatment plan and residual risks. In also requires organizations to assess consequence, likelihood, and levels of risk.

Clause 6.1.3, (Information security risk treatment) concerns the treatment of information security risk. It refers to the ‘determination’ of necessary controls rather than selecting controls from Annex A. Nevertheless, the standard retains the use of Annex A as a cross-check to make sure that no necessary control has been overlooked, and organizations are still required to produce a Statement of Applicability (SOA). The formulation and approval of the risk treatment plan is now part of this clause.
Clause 6.2, ( Information security objectives and planning to achieve them) concerns information security objectives. It uses the phrase “relevant functions and levels”, where here, the term ‘function’ refers to the functions of the organization, and the term ‘level’, its levels of management, of which ‘top management’ is the highest. The clause defines the properties that an organization’s information security objectives must possess.

Clause 7: Support

This clause begins with a requirement that organizations shall determine and provide the necessary resources to establish, implement, maintain and continually improve the ISMS. Simply expressed, this is a very powerful requirement covering all ISMS resource needs. The Support clause identifies what is required to establish, implement and maintain and continually improve an effective ISMS, including:

  • Resource requirements
  • Competence of people involved
  • Awareness of and communication with interested parties
  • Requirements for document management

Finally, there are requirements for ‘documented information’. The new standard refers to “documented information” rather than “documents and records” and requires that they are retained as evidence of competence These requirements relate to the creation and updating of documented information and to their control. There is no longer a list of documents you need to provide or particular names they must be given. The new revision puts the emphasis on the content rather than the name. Note that the requirements for documented information are presented in the clause to that they refer to. They are not summarized in a clause of their own, as they are in ISO/IEC 27001:2005.

Clause 8: Operation

The organization must plan, implement and control the processes needed to meet information security requirements and to implement the actions determined in the standard. The organization must perform information security risk assessments at planned intervals, and shall also implement the information security risk treatment plan. This clause deals with the execution of the plans and processes that are the subject of previous clauses. Organizations must plan and control the processes needed to meet their information security requirements including:

  • keeping documents
  • management of change
  • responding to adverse events
  • the control of any outsourced processes

Operation planning and control also mandate the carrying out of information security risk assessments at planned intervals and the implementation of an information security risk treatment plan.
Clause 8.1 deals with the execution of the actions determined in Clause 6.1, the achievement of the information security objectives and outsourced processes;
Clause 8.2 deals with the performance of information security risk assessments at planned intervals, or when significant changes are proposed or occur; and
Clause 8.3 deals with the implementation of the risk treatment plan.

Clause 9: Performance evaluation

The organization shall evaluate the information security performance and the effectiveness of the information security management system. The organization shall conduct internal audits at planned intervals to provide information on whether the information security management system conforms to the organization’s own requirements and to the International Standard requirements.

The first paragraph of Clause 9.1 (Monitoring, measurement, analysis, and evaluation) states the overall goals of the clause. As a general recommendation, determine what information you need to evaluate the information security performance and the effectiveness of your ISMS. Work backward from this ‘information need’ to determine what to measure and monitor, when who and how. There is little point in monitoring and making measurements just because your organization has the capability of doing so. Only monitor and measure if it supports the requirement to evaluate information security performance and ISMS effectiveness. Note that an organization may have several information needs, and these needs may change over time. For example, when an ISMS is relatively new, it may be important just to monitor the attendance at, say, information security awareness events. Once the intended rate has been achieved, the organization might look more towards the quality of the awareness event. It might do this by setting specific awareness objectives and determining the extent to which the attendees have understood what they have learned. Later still, the information need may extend to determine what impact this level of awareness has on information security for the organization.
Internal audits and management review continue to be key methods of reviewing the performance of the ISMS and tools for its continual improvement. he requirements include conducting internal audits at planned intervals, plan, establish, implement and maintain an audit programme(s), select auditors and conduct audits that ensure objectivity and impartiality of the audit process. Clause 9.2, (Internal audit) requires is similar to its counterpart in ISO  27001:2005. However, the requirement holding management responsible for ensuring that audit actions are taken without undue delay has been removed, as it is effectively covered by the requirements in Clause 10.1. The requirement that auditors shall not audit their own work has also been removed, as it is covered by the requirement to ensure objectivity and impartiality (Clause 9.2 e).
In Clause 9.3 (Management review),  rather than specify precise inputs and outputs, this clause now places requirements on the topics for consideration during the review. The requirement for reviews to be held at planned intervals remains but the requirement to hold the reviews at least once per year has been dropped.

Clause 10: Improvement

Due to the new way of handling preventive actions, there are no preventive action requirements in this clause. However, there are some new corrective action requirements. The first is to react to nonconformities and take action, as applicable, to control and correct the nonconformity and deal with the consequences. The second is to determine whether similar nonconformities exist, or could potentially occur. Although the concept of preventive action has evolved there is still a need to consider potential nonconformities, albeit as a consequence of an actual nonconformity. There is also a new requirement to ensure that corrective actions are appropriate to the effects of the nonconformities encountered. The requirement for continual improvement has been extended to cover the suitability and adequacy of the ISMS as well as its effectiveness, but it no longer specifies how an organization achieves this

ISO 27002:2013

The Information Security standard ISO 27002:2013 is the “Code of Practice for Information Security Controls”. The document provides best practice recommendations and guidance for organizations selecting and implementing information security controls within the process of initiating, implementing and maintaining an Information Security Management System (ISMS). The establishment and implementation of an ISMS depend on a strategic orientation of the organization and is influenced by a number of aspects including its needs, objectives, security requirements, the organizational processes used, the size and the structure of the organization. An ISMS such as specified in ISO 27001 is an integrated part of the organization’s processes and overall management structure, with the main objective to ensure the necessary levels of confidentiality, integrity, and availability of information. This objective is achieved by applying a supporting risk management process within the ISMS and by implementing a suite of information security controls as part of the risk treatment under the overall framework of a coherent management system. The normative requirements of ISMS are addressed in clauses 4 to 11 of 27001:2013 that define the ISMS. Furthermore, organizations need to consider the set of 144 controls which are found in Annex A of the same standard.
In ISO 27002, you will find more detailed guidance on the application of the controls of Annex A including areas such as policies, processes, procedures, organizational structures and software, and hardware functions. All these information security controls may need to be established, implemented, monitored, reviewed and improved, where necessary, to ensure that the specific established security and business objectives of the organization are met. ISO 27002 provides general guidance on the controls of ISO 27001 and should be combined and used with other standards of the information security management system family of standards, including ISO 27003 (implementation), ISO 27004 (measurement), and ISO 27005 (risk management).

ISO 27002 applies to all types and sizes of organizations, including public and private sectors, commercial and non-profit that collect, process, store and transmit information in many forms including electronic, physical and verbal. This standard should be used as a reference for the consideration of controls within the process of implementing an Information Security Management System based on ISO 27001, it implements commonly accepted information security controls and develops the organization’s own information security management guidelines. The standard contains 14 security control clauses, collectively containing a total of 35 main security categories and 114 controls.

In each section of the ISO 27002 standard, there is a security control category that contains:

  • a control objective stating what is to be achieved;
  • one or more controls that can be applied to achieve the control objective;
  • implementation guidance and any other pertinent information useful for understanding the controls and implementation process.

If you want to create the foundations of information security in your organization and devise its framework, you should use ISO 27001; whereas if you want to focus on the implementation controls, you should use ISO 27002. So by implementing ISO 27001 correctly, an organization will have a management system that will assist in efficiently planning, implementing, monitoring, reviewing and improving information security in scope. On the other hand, ISO 27002 can assist to implement and maintain controls to achieve objectives for all requirements as required by ISO 27001. For every risk situation identified in ISO 27001, ISO 27002 will give a set of controls on how to decrease the risks and how to maintain it at an acceptable level. 

Key clauses of ISO  27002:2013

ISO 27002 is organized into the following main clauses:
The standard contains 14 security control clauses, collectively containing a total of 35 main security categories and 114 controls.

  • Clause 5: Information Security Policies
  • Clause 6: Organization of Information Security
  • Clause 7: Human Resource Security
  • Clause 8: Asset Management
  • Clause 9: Access Control
  • Clause 10: Cryptography
  • Clause 11: Physical and Environmental Security
  • Clause 12: Operations Security
  • Clause 13: Communication Security
  • Clause 14: System Acquisition, Development, and Maintenance
  • Clause 15: Supplier Relationships
  • Clause 16: Information Security Incident Management
  • Clause 17: Information Security Aspects of Business Continuity Management
  • Clause 18: Compliance

Section 0: Introduction

This lays out the background, mentions three origins of information security requirements, notes that the standard offers generic and potentially incomplete guidance that should be interpreted in the organization’s context, mentions information and information system lifecycles, and points to ISO/IEC 27000 for the overall structure and glossary for ISO27k.

Section 1: Scope

The standard gives recommendations for those who are responsible for selecting, implementing and managing information security. It may or may not be used in support of an ISMS specified in ISO 27001.

Section 2: Normative references

ISO 27000 is the only standard considered absolutely indispensable for the use of ISO 27002. However, various other standards are mentioned in the standard, and there is a bibliography.

Section 3: Terms and definitions

All the specialist terms and definitions are now defined in ISO 27000 and most apply across the entire ISO27k family of standards.

Section 4: Structure of this standard

Security control clauses
Of the 21 sections or chapters of the standard, 14 specify control objectives and controls. These 14 are the ‘security control clauses’.
There is a standard structure within each control clause: one or more first-level subsections, each one stating a control objective, and each control objective are supported in turn by one or more stated controls, each control followed by the associated implementation guidance and, in some cases, additional explanatory notes. The amount of detail is responsible for the standard is nearly 90 A4 pages in length.
35 control objectives
ISO 27002 has some 35 control objectives (one per ’security control category’) concerning the need to protect the confidentiality, integrity, and availability of information. The control objectives are at a fairly high level and, in effect, comprise a generic functional requirements specification for an organization’s information security management architecture. Few would seriously dispute the validity of the control objectives, or, to put that another way, it would be difficult to argue that an organization need not satisfy the stated control objectives in general. However, some control objectives are not applicable in every case and their generic wording is unlikely to reflect the precise requirements of every organization, especially given the very wide range of organizations and industries to which the standard applies.  This is why ISO 27001 requires the SoA (Statement of Applicability), laying out unambiguously which information security controls are or are not required by the organization, as well as their implementation status.
114  controls
Each of the control objectives is supported by at least one control, giving a total of 114. However, the headline figure is somewhat misleading since the implementation guidance recommends numerous actual controls in the details. The control objective relating to the relatively simple subsection 9.4.2 “Secure log-on procedures”, for instance, is supported by choosing, implementing and using suitable authentication techniques, not disclosing sensitive information at log-on time, data entry validation, protection against brute-force attacks, logging, not transmitting passwords in clear over the network, session inactivity timeouts, and access time restrictions. Whether you consider that to be one or several controls is up to you. It could be argued that ISO 27002 recommends literally hundreds of distinct information security controls, although some support multiple control objectives, in other words, some controls have several purposes. Furthermore, the wording throughout the standard clearly states or implies that this is not a totally comprehensive set. An organization may have slightly different or completely novel information security control objectives, requiring other controls (sometimes known as ‘extended control sets’) in place of or in addition to those stated in the standard.

Section 5: Information security policies

The Information Security Policies clause addresses the need to define, publish and review different types of policies required for information security management

5.1 Management direction for information security

Objectives: To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations.
Management should define a set of policies to clarify their direction of, and support for, information security. At the top level, there should be an overall “information security policy” as specified in ISO 27001 section 5.2.

Section 6: Organization of information security

The Organization of Information Security clause addresses the need to define and allocate the necessary roles and responsibilities for information security management processes and activities. This includes controls related to the definition of information security roles and responsibilities, segregation of duties, contact with authorities, contact with special interest groups, information security in project management and mobile devices and teleworking.

6.1 Internal organization

Objectives: To establish a management framework, to initiate and control the implementation and operation of information security within the organization.
The organization should lay out the roles and responsibilities for information security, and allocate them to individuals. Where relevant, duties should be segregated across roles and individuals to avoid conflicts of interest and prevent inappropriate activities. There should be contacts with relevant external authorities (such as CERTs and special interest groups) on information security matters. Information security should be an integral part of the management of all types of project.

6.2 Mobile devices and teleworking

Objectives: To ensure the security of teleworking and the use of mobile devices.
There should be security policies and controls for mobile devices (such as laptops, tablet PCs, wearable ICT devices, smartphones, USB gadgets, and other Boys Toys) and teleworking (such as telecommuting, working-from-home, road-warriors, and remote/virtual workplaces).

Section 7: Human resource security

The Human Resource Security clause addresses the required controls for processes related to staff recruiting, their job during employment and after the termination of their contracts. These considerations should include information security coordination, allocation of information security responsibilities, authorization processes for information processing facilities, confidentiality agreements, contact with authorities, contact with special interest groups, independent review of information security, identification of risks related to external parties, addressing security when dealing with customers, addressing security on contractors’ agreements, etc.

7.1 Prior to employment

Objectives: To ensure that employees and contractors understand their responsibilities and are suitable for the roles for which they are considered.
Information security responsibilities should be taken into account when recruiting permanent employees, contractors and temporary staff (e.g. through adequate job descriptions, pre-employment screening) and included in contracts (e.g. terms and conditions of employment and other signed agreements defining security roles and responsibilities, compliance obligations, etc.).

7.2 During employment

Objectives: To ensure that employees and contractors are aware of and fulfill their information security responsibilities.
Managers should ensure that employees and contractors are made aware of and motivated to comply with their information security obligations. A formal disciplinary process is necessary to handle information security incidents allegedly caused by workers.

7.3 Termination and change of employment

Objectives: To protect the organization’s interests as part of the process of changing or terminating employment.
Security aspects of a person’s departure from the organization, or significant changes of roles within it, should be managed, such as returning corporate information and equipment in their possession, updating their access rights, and reminding them of their ongoing obligations under privacy and intellectual property laws, contractual terms etc. plus ethical expectations.

Section 8: Asset management

The Asset Management clause addresses the required responsibilities to be defined and allocated for the asset management processes and procedures. The owner of the assets and other parts involved in this matter should be identified to be held accountable for assets’ security, including classification, labeling, and handling of information; and information processing facilities should be identified and maintained. Moreover, this clause addresses controls on management of removable media, disposal of media, and physical media transfer.

8.1 Responsibility for assets

Objectives: To identify organizational assets and define appropriate protection responsibilities.
All information assets should be inventoried and owners should be identified to be held accountable for their security. ‘Acceptable use’ policies should be defined, and assets should be returned when people leave the organization.

8.2 Information classification

Objectives: To ensure that information receives an appropriate level of protection in accordance with its importance to the organization.
Information should be classified and labeled by its owners according to the security protection needed, and handled appropriately.

8.3 Media handling

Objectives: To prevent unauthorized disclosure, modification, removal or destruction of information stored on media.
Information storage media should be managed, controlled, moved and disposed of in such a way that the information content is not compromised.

Section 9: Access control

The Access controls clause addresses requirements to control access to information assets and information processing facilities. The controls are focused on the protection against accidental damage or loss, overheating, threats, etc. This requires a documented control policy and procedures, registration, removal and review of user access rights, including here physical access, network access and the control over privileged utilities and restriction of access to the program source code.

9.1 Business requirements of access control

Objectives: To limit access to information and information processing facilities.
The organization’s requirements to control access to information assets should be clearly documented in an access control policy and procedures. Network access and connections should be restricted.

9.2 User access management

Objectives: To ensure authorized user access and to prevent unauthorized access to systems and services.
The allocation of access rights to users should be controlled from initial user registration through to removal of access rights when no longer required, including special restrictions for privileged access rights and the management of passwords (now called “secret authentication information”) plus regular reviews and updates of access rights.

9.3 User responsibilities

Objectives: To make users accountable for safeguarding their authentication information.
Users should be made aware of their responsibilities towards maintaining effective access controls e.g. choosing strong passwords and keeping them confidential.

9.4 System and application access control

Objectives: To prevent unauthorized access to systems and applications.
Information access should be restricted in accordance with the access control policy e.g. through secure log-on, password management, control over privileged utilities and restricted access to the program source code.

Section 10: Cryptography

The Cryptography clause addresses policies on cryptographic controls for protection of information to ensure proper and effective use of cryptography in order to protect the confidentiality, authenticity, integrity, non-repudiation, and authentication of the information. It also includes the need for digital signatures and message authentication codes and cryptographic key management.

10.1 Cryptographic controls

Objectives: To ensure proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of information.
There should be a policy on the use of encryption, plus cryptographic authentication and integrity controls such as digital signatures and message authentication codes, and cryptographic key management.

Section 11: Physical and environmental security

The Physical and Environmental Security clause addresses the need to prevent unauthorized physical access, damage and interference to the organization’s information and information processing facilities. Controls cover to physically secure the perimeter of office rooms and facilities, protection against external and environmental threats, prevent loss, damage, theft or compromise of assets, protect the equipment from power failures, cabling should be protected from interception or damage, maintenance of equipment, etc.

11.1 Secure areas

Objectives: To prevent unauthorized physical access, damage and interference to the organization’s information and information processing facilities.
Defined physical perimeters and barriers, with physical entry controls and working procedures, should protect the premises, offices, rooms, delivery/loading areas, etc. against unauthorized access. Specialist advice should be sought regarding protection against fires, floods, earthquakes, bombs, etc.

11.2 Equipment

Objectives: To prevent loss, damage, theft or compromise of assets and interruption to the organization’s operations
“Equipment” (meaning ICT equipment, mostly) plus supporting utilities (such as power and air conditioning) and cabling should be secured and maintained. Equipment and information should not be taken off-site unless authorized and must be adequately protected both on and off-site. Information must be destroyed prior to storage media being disposed of or re-used. Unattended equipment must be secured and there should be a clear desk and clear screen policy.

Section 12: Operations security

The Operations security clause addresses the organization’s ability to ensure correct and secure operations. The controls cover the need for operational procedures and responsibilities, protection from malware, backup, logging and monitoring, control of operational software, technical vulnerability management, information systems audit considerations.

12.1 Operational procedures and responsibilities

Objectives: To ensure correct and secure operations of information processing facilities.
IT operating responsibilities and procedures should be documented. Changes to IT facilities and systems should be controlled. Capacity and performance should be managed. Development, test and operational systems should be separated.

12.2 Protection from malware

Objectives: To ensure that information and information processing facilities are protected against malware.
Malware controls are required, including user awareness.

12.3 Backup

Objectives: To protect against loss of data.  
Appropriate backups should be taken and retained in accordance with a backup policy.

12.4 Logging and monitoring

Objectives: To record events and generate evidence.
System user and administrator/operator activities, exceptions, faults and information security events should be logged and protected. Clocks should be synchronized.

12.5 Control of operational software

Objectives: To ensure the integrity of operational systems.
Software installation on operational systems should be controlled.

12.6 Technical vulnerability management

Objectives: To prevent exploitation of technical vulnerabilities.
Technical vulnerabilities should be patched, and there should be rules in place governing software installation by users.

12.7 Information systems audit considerations

Objectives: To minimize the impact of audit activities on operational systems.
IT audits should be planned and controlled to minimize adverse effects on production systems or inappropriate data access.

13 Communications security

The Communication Security clause addresses the organization’s ability to ensure the protection of information in systems and applications in networks and its supporting information processing facilities. Controls cover the security of information in networks and connected services from unauthorized access, transfer policies, and procedures, secure transfer of business information between the organization and external parties, the information involved in electronic messaging, the need for confidentiality or non-disclosure agreements.

13.1 Network security management

Objectives: To ensure the protection of information in networks and its supporting information processing facilities.
Networks and network services should be secured, for example by segregation.

13.2 Information transfer

Objectives: To maintain the security of information transferred within an organization and with any external entity.
There should be policies, procedures, and agreements (e.g. non-disclosure agreements) concerning information transfer to/from third parties, including electronic messaging.

Section 14: System acquisition, development, and maintenance

The System Acquisition, Development and Maintenance clause covers controls for identification, analyses and specification of information security requirements, securing application services in development and support processes, technical review restrictions on changes to software packages, secure system engineering principles, secure development environment, outsourced development, system security testing, system acceptance testing and protection of test data.

14.1 Security requirements of information systems

Objectives: To ensure that information security is an integral part of information systems across the entire lifecycle. This also includes the requirements for information systems which provide services over public networks.
Security control requirements should be analyzed and specified, including web applications and transactions.

14.2 Security in development and support processes

Objectives: To ensure that information security is designed and implemented within the development lifecycle of information systems.
Rules governing secure software/systems development should be defined as policy. Changes to systems (both applications and operating systems) should be controlled. Software packages should ideally not be modified, and secure system engineering principles should be followed. The development environment should be secured, and outsourced development should be controlled. System security should be tested and acceptance criteria defined to include security aspects.

14.3 Test data

Objectives: To ensure the protection of data used for testing.
Test data should be carefully selected/generated and controlled.

15: Supplier relationships

The Supplier Relationships clause addresses controls for supplier’s relationship issues, including here information security policies and procedures, addressing security within supplier agreements, communication, and awareness about technology supply chain and service delivery management.

15.1 Information security in supplier relationships

Objectives: To ensure the protection of the organization’s assets that is accessible by suppliers.
There should be policies, procedures, awareness, etc. to protect the organization’s information that is accessible to IT outsourcers and other external suppliers throughout the supply chain, agreed within the contracts or agreements.

15.2 Supplier service delivery management

Objectives: To maintain an agreed level of information security and service delivery in line with supplier agreements
Service delivery by external suppliers should be monitored, and reviewed/audited against the contracts/agreements. Service changes should be controlled.

Section 16: Information security incident management

The Information Security Incident Management clause covers controls for responsibilities and procedures, reporting information and security weaknesses, assessment of and decision on information security events, response to information security incidents, learning from information security incidents, and collection of evidence.

16.1 Management of information security incidents and improvements

Objectives: To ensure a consistent and effective approach to the management of information security incidents, including communication on security events and weaknesses.
There should be responsibilities and procedures to manage (report, assess, respond to and learn from) information security events, incidents and weaknesses consistently and effectively, and to collect forensic evidence.

Section 17: Information security aspects of business continuity management

The Business Continuity Management clause addresses the organization’s ability to counteract interruptions to normal operations, including the availability of information processing facilities, verify, review and evaluate information security continuity, implementing information security continuity, and planning information security continuity.

17.1 Information security continuity

Objectives: Information security continuity should be embedded in the organization’s business continuity management systems.
The continuity of information security should be planned, implemented and reviewed as an integral part of the organization’s business continuity management systems.

17.2 Redundancies

Objectives: To ensure availability of information processing facilities.
IT facilities should have sufficient redundancy to satisfy availability requirements.

Section 18: Compliance

The Compliance clause addresses the organization’s ability to remain in compliance with regulatory, statutory, contractual, and security requirements, including: identification of applicable legislation and contractual requirements, intellectual property rights, protection of records, privacy and protection of personally identifiable information, regulation of cryptographic controls, independent review of information security, compliance with security policies and standards, and technical compliance review.

18.1 Compliance with legal and contractual requirements

Objectives: To avoid breaches of legal, statutory, regulatory or contractual obligations related to information security and of any security requirements. 
The organization must identify and document its obligations to external authorities and other third parties in relation to information security, including intellectual property, [business] records, privacy/personally identifiable information and cryptography.

18.2 Information security reviews

Objectives: To ensure that information security is implemented and operated in accordance with the organizational policies and procedures.
The organization’s information security arrangements should be independently reviewed (audited) and reported to management. Managers should also routinely review employees’ and systems’ compliance with security policies, procedures etc. and initiate corrective actions where necessary.

 

OCP for Operation & Maintenance Of DG SET

1.PURPOSE:  To explain the points to be checked before starting DG set
2. SCOPE:  This work instruction is applicable to DG set
3. RESPONSIBILITY: HOD MNT.
4. INSTRUCTIONS: Refer to Manufacturer’s manual For DG set repair and maintenance.

5.ENVIRONMENTAL HEALTH AND SAFETY INSTRUCTION:

  1. Before entering into D.G room wear Earmuff /earplug.
  2. While doing maintenance wear hand gloves.
  3. Avoid open flame in D.G. room.

 6. OPERATIONAL CONTROL PLAN:-

Sr.No Parameter to be Monitored Spec. Freq. of Monitoring Method of monitoring Resp. Record
 1 Emission  Level in DG set PM- 150 mg/Nm3
SO2-50mg/Nm3
Once in Six Month External agency HOD MNT Report from an external agency
 2 Qty. of Diesel.  Daily Diesel record HOD MNT Diesel record
 3 Noise Level a) DG Set  75 dB Once in Three Month External agency HOD MNT dB record
4 Cleaning of duct Clean Once in month Visual HOD MNT P.M. record

 

7. RECORD REF.: As mentioned above.