Updates from August, 2014

  • How to achieve Business Continuity ISO 22301 Implementation – ISO 22301 certification? 

    Business continuity (BC) is about bringing back your business post crisis or a disaster situation. BC is about managing ‘black swan’ events in your organisation – something that you never expected. However there is a scope – defined in terms of outages. You can chiefly plan against four outage scenarios – namely site outage, people or skill outage, technology outage and vendor outage. Can you think of anything else – please write to me!

    Here are the key requirements that ISO 22301 demands that must be done to demonstrate a formal business continuity management system leading to successful certification.

    Step 1 – Business Impact Analysis (BIA)  – BIA is the assessment of what is most important of to your business and how long can you survive without it without losing any revenue. If you are a Bank you may say my customers are unwilling to wait outside the ATM if they are not getting cash. Apply the same logic for your customers and ask them to how long can they wait. You have two values from this analysis  – Your Revenue generating services (RGS) and maximum acceptable outage(MAO). Both of these – will determine your business continuity plan (BCP). They will answer ‘what to restore’ and ‘how fast’?

    Step 2 – Risk Assessment is the assessment of how prepared are you for ensuring availability. It identifies your single point of failures in all four capabilities – namely site outage, people or skill outage, technology outage and vendor outage. It questions are you are prepared or you need a plan. The flaws identified are fed into a plan strategy.

    Step 3 – Business Continuity Strategy is your choice based on budget of what you wish to address. This is also a choice where a likely failure is imminent. For each outage scenario – there are options. For example for technology outage – you have redundancy, cold site, warm site and hot site.

    Step 4 – BC Plans including incident management structure – who will invoke the plans, incident wise plans and continuity plans based on outages – reflect the list of plans against each scenario , who will do what, and how fast we will recover. Documented plans reflect your organisations’ formal approach. No documentation = no certification = no formal ‘intent’.

    Step 5 – BC Testing the above list of plans is the next step as well as most crucial. No testing = No BC. Testing approaches start from Table Top exercises (least expensive) to Switching off the mains (most expensive) – all options are available depending upon the confidence you wish to have. Additionally test whether your plans will ensure the same time as defined in the MAO.

    Step 6 – Internal Audit – If you are seeking ISO 22301 also perform an internal audit against all requirements as well as compliance against the MAO objectives will ensure the auditors do not question your overall business continuity objectives.

    Step 7 – Communication and training are additional elements to ensure your ROI on BC. More People awareness equals more aware ‘junta’, thereby ensuring least opportunity of failure.

    Hope you liked the article

     
  • How to calculate your Business Continuity budget? 

    Premise: Business continuity is about your recovery of your business post crisis not before. Insurance does not recover business, it recovers losses or existing investment.

    The true recovery is your ability to continue your business as before. Put simply your business should be able to generate same sales as planned as before.

    So how to calculate your business continuity budget?

    We use this is a benchmark. See if this works for you.

    In order to do this, first assess your current insurance strategy.

    To make this simpler we take the case of an individual life insurance.  If your life insured value is 1 crore (or 10 million) and your annual premium is 250,000/- the percent you pay to 2.5% per year.

    Note this amount is for your family members to receive typically after you are gone. It is not the price for ensuring for your continuity, which is your own life. Your life continues when you yourself can ensure your annual compensation.

    Today every business has set of insurance policies. Get all the policies together. Get the annual premium together and annual insured value. Remember that you recover the losses not your business. But the ratio of  premium to insured value gives an indicator – a percent.

    The percent is your existing risk appetite. Apply this appetite/percent to your sales. This value is your business continuity budget.

    An example with numbers!

    Lets say your combined percent of premium to recovery is 2.5%. So if your sales turnover is 10 crores (or 100 million), then your business continuity must be 25,00,000 or 2.5m. Since you are already paying tax premium deduct this from 2.5m and what you get is the remaining budget for business continuity.

    You can do the annual calculation of business continuity at the end of the financial year, which will then set the target for the next year.

    Summary

    (1) Identify your insurance cost or insurance premium per year

    (2) Identify your insured value

    (3) Divide 1 by 2 into percentage terms. You have a percentage.

    (4) Apply the percentage to your sales turnover from the last financial year. You have the business continuity budget for the next year.

    (5) Deduct the existing annual premiums (1) from (4) – you get the balance value.

    We deduct (1) from (4) because (1) represent a part of your risk management strategy.

    This is your pending budget for business continuity for this year.

    Hope this helps!

     
  • How IT service management works and how to kick start the program? 

    If you are concerned about IT service delivery and its impact to your business – this is for you!

    IT service management system (ITSM) practices brings speed and business alignment to the IT service delivery. Implementation of ITSM should result in IT service delivery improvement (I call it speed) by 30-50% if not more.

    The journey begins with a simple agreement between business and IT using a service catalogue. Service catalogue is synonymous to any other catalogue that you are aware – it is an outcome of an agreement between an IT  customer (a user group) and a vendor in this case IT team.

    ITSM implementation fulfils different stakeholder interests.

    For the CEO it means IT organisation is delivering in alignment with business. The implementation of ITSM ensures customer ‘voice’ in designing and delivery of IT services. Customer satisfaction is assured through processes such as Business relationship management. Financial Control is assured through processes such as Budgeting and Accounting.

    For the CIO it brings an order to the house. Each service in the service catalogue is aligned with the 15 processes(see below). In fact every time a new service is to be added the CIO or the IT service delivery manager thinks of these 15 processes as part of the service design. Alignment of the IT service delivery to the processes bring robustness and risk control.

    Processes such as configuration management database (CMDB) and known error  database (KED) form the foundation of IT delivery. CMDB helps in improving response time for change and release. KED helps in resolving incidents and problem faster.

    For the Technical administrator it means alignment with number of good practices of change management, configuration management, release management practices. No more does ‘ i know the technical guy’ so ‘I will get my work done’ – everyone speaks the language of ticket, service, response time and resolution time.

    Not sure how to start? Start with your service catalogue – it is the beginning!

    ISO 20000 Processess that you pick and chose as applicable for your business

    Design and development of new or changed services
    Transition of new or changed services
    Service level management
    Service reporting
    Service continuity and availability management
    Budgeting and accounting for services
    Capacity management
    Information security management
    Business relationship management
    Supplier management
    Incident and service request management
    Problem management
    Configuration management
    Change management
    Release and deployment management

    If you are seeking formal ISO 20000 compliance all the processes apply.

    Hope this helps.

     
  • ISO 27001 2013 migration roadmap 

    Your organization is  currently ISO 27001 2005 certified and looking for direction for ISO 27001 2013 up-gradation?

    Look no further! Here are some of the key steps you need to take to migrate to the new standard:

    In a previous blog we have mentioned the key differences between ISO 27001 2005 and 2013 version.

    Step 1 – You need information security context register or any other similar name that lists organization’s key strategic issues, risk and external and internal requirements for information security. In a way this document is an input the selection of your scope. What this means is that if you are the security manager, ensure information security is aligned with business objective, and that it leads to  selection of the right scope for ISO 27001 certification.

    Step 2 – ISO 27001 114 control gap analysis. This will result in identifying additional security controls that are applicable to your business and which requires to implemented. Controls such as security in project management is definitely something new in the new ISO 27001 2013 standard. Your gap analysis will show the additional controls that need to be implemented. There are nearly 15 such new controls that requires implementation.

    Step 3 – Implement the identified gaps.  This would involve policy writing skills, training and seeking records from respective teams who have the responsibility of this implementation.

    Step 4 – The new standard enforces the need for ‘risk ownership’, ‘communication’, and ‘accountability’. Establish these processes based on how you understand these terms. One such approach is to divide the statement of applicability (SOA) controls between organisational teams, and call them as control/risk owners.

    Step 5 – Security Performance dashboard is an additional requirement which needs to be implemented. The reporting enforces a higher degree of ownership among teams guarding the organization.

    Step 6 – Completing key procedural documentation in line with the ISO 27001 2013 requirement. An example could be writing the ISMS Manual in line with the standard requirement.

    Step 7 – Internal Audit. This will ensure that the old and new policies are implemented successfully.

    Step 8 – Management Review. If there are no major findings in internal audit go ahead and apply for an upgrade.

    Attempt is made to make the ISO 27001 2013 migration simplistic.

    Organization complexities such as number of locations, technology, vendor complexities, security compliance responsibilities, lack of policy writing skills, may result in delay in migration.

    Hope this helps!

     
  • Security in Project Management 

    One of the new requirements in ISO 27001 2013 is considering security in project management. The standard clause is as follows:

    “A.6.1.5 – Information security in project management  – Information security shall be addressed in project management, regardless of the type of the project”

    Source: ISO 27001-2013

    The implication of this clause applies to all types of projects and not simply ‘IT’ projects. This can be also be interpreted as security ‘of the project, by the project and for the project’.

    In any organisation there are several business units and teams with multiple focus areas working in unison to fulfil business objectives. Depending on the type of business your departments can be core customer facing services, revenue generating services, manufacturing, Information Technology, application development, Physical security, Human resources, legal and Finance department(not exhaustive). The work ‘project’ has different meaning to each of them.

    How to implement?

    In order to implement this clause organisations can take several approaches.

    One approach is to involve security manager (if you have one) in each and every project. This way every time a team conceptualises a project – the security manager is involved in assessment and articulation of security requirement.

    The other approach is to help and make managers trained on security requirement analysis as part of any project requirement.

    Irrespective of who or how an organisation implements this, the ability to correlate with one or more of the ISO 27001 114 controls should be understood. A direct question can be – ‘does the project need additional security to be implemented’? A simplistic view could be physical, technical, human resource or procedural requirements. A more complex view such as product implementation or an application development may require more step by step documentation of issues.

    The process implementation is evident when teams managing projects are able to articulate there security requirements which will take the form people, process or technology changes.

    If the clause is implemented correctly this will address security at the design phase. This will also minimise (if not completely eliminate) security as an afterthought.

    Hope this help!

     
  • Primer for CEO – How Business Continuity Management Works? 

    Listed below are key steps for a comprehensive business continuity program.

    1. Identification of mission critical activities that needs a continuity plan. In order to assess the requirement for BCP, one needs to understand enterprise context. We divide an organisation unit into mission critical teams/services such as revenue generating services (RGS) for profit making businesses, customer facing services for non-profit, essential infrastructure services (EIS) such as power, utilities, IT and security, and delayed start services (DSS) – services that can wait during emergency. This assessment helps you prioritise recovery. EIS – first to recover, RGS – second to recover and DSS – last to recover.
    2. Maximum tolerable period of disruption (MTPOD) is a business term that determines the number of hours you are willing to be out of business. Different organisation/services have different degree of tolerance. For a bank it can be negligible for a service sector there can be little more . (Indicative not prescriptive). This term is important to agree as it determines the speed of recovery strategies.
    3. Recovery time objective (RTO) – a measure of continuity planning. It answers question such as how fast ‘WE plan’ to recover’? This is generally set at 75% of the MTPOD value.
    4. Minimum service levels (MSL) – determine is the minimum service target post disaster. For organisations whose service delivery is customer facing, the question can be ‘what minimum services are to be guaranteed as per SLA agreed’?. As an organisation you may have 2 or more layers of recovery starting with minimum recovery – immediately and then scale up recovery
    5. Continuity Planning – Don’t plan for events (e.g. Fire) – plan for outages (building not available). Chances are that you already have event wise plans. Those plans are designed to prevent. Business continuity is planning for outages. They can be broadly 4. Site outage, people/skill outage, vendor outage and technology outages. (They can be more – but you got the point). You need plan for each. Assumption for planning is ‘all preventive controls have failed – now how do we restore?”
    6. Continuity Strategies – For each outage there are 2-3 options to choose from. People outage includes skill transfer, suitable vendor, or increasing manpower. Vendor outage planning include skill insourcing, alternative vendor and/or increase capacity from the same vendor. Location outage includes work from home, work from alternate location, work from reciprocal location. Technology outage includes warm, cold or hot site. Risk and budget drives your choice of options.
    7. Testing Strategies and Tests – Your testing is dependent on your continuity strategy. From table top/documents review to full-blown main power switch off – all options exist. Your test result should ensure recovery within RTO. Your BCP is as good (or bad as) as your testing success.
    8. Monitoring – Create a dashboard for monitoring. Dashboard items should include dynamic and static events. Dynamic events include acquisition of a new customer that may challenge all your existing business continuity metrics. Static events include testing results and whether they match designed RTO. Spend 30 minutes every month on the BCM dashboard and you have a great continuity plan in place.

    Hope this helps! Please share your feedback.

    Considering a business continuity plan? Call or write to us!

     
  • Preliminary Cybersecurity framework released by NIST to protect critical infrastructure 

    What is Critical infrastructure?

    Critical Infrastructure is defined as any system and assets, whether physical or virtual, so vital to the United States (and can be interpreted for any country) that the incapacity or destruction of such systems and assets would have a debilitating impact on cybersecurity, national economic security, national public health or safety, or any combination of those matters.

    The critical infrastructure community includes public and private owners and operators, and other supporting entities that play a role in securing the Nation’s infrastructure. Each sector performs critical functions that are supported by information technology (IT), industrial control systems (ICS) and, in many cases, both IT and ICS.To manage cybersecurity risks, a clear understanding of the security challenges and considerations specific to IT and ICS is required.

    (Source: NIST)

    What is the framework all about?

    The Framework provides a common language for expressing, understanding, and managing cybersecurity risk, both internally and externally. The Framework can be used to help identify and prioritize actions for reducing cybersecurity risk and is a tool for aligning policy, business, and technological approaches to managing that risk. Different types of entities — including sectors, organizations, and associations — can use the Framework for different means, including the creation of common Profiles.

    How is this relevant to your organization?

    If you have critical infrastructure this is definitely for you.

    Every other organization can use the document (in its spirit) to associate the core framework to its existing security framework. The document provides a easy framework for Identify, Protect, Detect, Respond, Recover any core infrastructure.

    What is there for the security professional/CISO/ISMS Managers?

    The use of multiple standards – ISO 27001, NIST SP – 800-53,  COBIT, ISA 99.02.01 shows the depth of the document.

    Use the document to enhance your security posture. Use the Core framework and references for benchmarking existing security resiliences. It is a worthwhile effort.

    Download and read the document here – http://www.nist.gov/itl/cybersecurity-102213.cfm

     
  • Difference between ISO 27001: 2013 and ISO 27001:2005 

    ISO 27001: 2013 was released in September 2013

    Here are some of the high-impact changes:

    Change 1 – Standard is closer to enterprise risk management. The fact that information protection cannot remain aloof from organisation risk is well articulated in the new standard and is reflected in almost each management section clauses.

    Change 2 – There is an insistence on understanding information from a business perspective. References of enterprise ‘context’ in the new standard means that you see information from a business success or failure. Equally important is identification of external and internal issues in the success and failure of information security management.

    Change 3 – Scope definition is derived from organisation context rather than merely  a physical or a logical boundary. In the iso 27001 – 2005  standard you could chose a subset of the organisation as a scope (such as Information technology team) but in the new standard merely picking up a team for scope may be difficult as thus has to be aligned with business strategy. Leaving a strategic team facing customer may not therefore be easy and therefore MUST be included in the scope statement.

    Change 4 – Replacement of ‘Management commitment’ with ‘ Leadership’ – again an alignment with ISO 31000. In the past certain organizations have has CIOs signing the information security policy, this would be a thing of the past with the new standard.

    Change 5 – Risk assessment and risk treatment – the foundation of the subject – are clearer, elaborate and more objective. A section of information security objectives is very specific:

    ‘When planning how to achieve its information security objectives, the organization shall 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

    Change 6 – clause 9 – performance evaluation covers three essential topics, namely

    9.1 Monitoring, measurement, analysis and evaluation
    9.2 Internal audit
    9.3 Management review

    The alignment of this three issues is unique and gives more teeth to the implementation. For clause 9.1 the organisation needs to define what they need to measure and monitor as the management system level. Clause 9.2 – internal audit then focuses on those specific measurements, and clause 9.3 – management review is further aligned to review the performance based on the  audit results.

    Change 7 – Changes in domains, control objectives and detail controls

    In Annex A there will be 14 domains, 35 control objectives and 114 detail controls. The number of domains have increased however the total number of controls have reduced, the latter is an optimisation effort. The grouping of earlier clauses seems to make a lot more sense.

    Some of the main clauses which are either new or are more specific in the new standard:

    A.6.1.4 Information security in project management – this is a new clause, consider security every time you do a project;
    A.6.2.1 Mobile device policy – more specific in ISO 27001: 2013 compared to ISO 27001: 2005
    A.8.3.3 Physical media transfer – more specific in ISO 27001: 2013 compared to ISO 27001: 2005
    A.9.2.1 User registration and de-registration – more specific in ISO 27001: 2013
    A.9.2.3 Management of secret authentication information of users – this focuses on handling sensitive authentication data such as a password
    A.9.2.5 Removal or adjustment of access rights – considers ‘adjustment’ of access
    A.9.3.1 Use of secret authentication information – insistence on a procedure and awareness
    A.9.4.4 Use of privileged utility programs – new name to the older clauses ‘use of system utilities’ in the previous standard
    A.13.2.1 Information transfer policies and procedures – new name to the older clause ‘policy on exchange of information’
    A.14.1.1 Security requirements analysis and specification – more elaborate clause description compared to the previous standard
    A.14.1.2 Securing applications services on public networks – more specific in ISO 27001: 2013 compared to ISO 27001: 2005
    A.14.1.3 Protecting application services transactions – more specific in ISO 27001: 2013 compared to ISO 27001: 2005
    A.14.2.1 Secure development policy – seeks to cover security in the entire development lifecycle, clearer more specific
    A.14.2.6 Secure development environment – this is a new clause
    A.14.2.8 System security testing – this is a new clause
    A.15 Supplier relationships – this is a new domain
    A.15.1.1 Information security policy for supplier relationships – this is a new clause
    A.15.1.2 Addressing security within supplier agreements – this is a new clause
    A.15.1.3 ICT supply chain – this is a new clause
    A.16.1.4 Assessment and decision of information security events – part of incident management this section is clearer
    A.16.1.5 Response to information security incidents – part of incident management this section is more specific to an escalation procedure
    A.17.1 Information security continuity – removes the ambiguity of the previous standard – clearly focuses on protection during continuity
    A.17.2.1 Availability of information processing facilities – part of A.17 Redundancy clause – this is a new requirement

    Summary

    Some of the major changes seem to be ‘alignment with business strategy’, a comprehensive ‘measurable framework’, ‘inclusion of supply chain management’, ‘secure development life cycle’ and a focused incident response process.

    ISO 27001: 2013 is released in September 2013, consider migrating for implementing the best practices. If you are currently certified to iso 27001 – 2005 you have time till September 2015 to migrate.

    Hope this helps!

    Considering migrating to iso 27001 – 2013?

     
  • ISO 27001 2013 Security Performance Dashboard 

    One of the key changes of iso 27001 – 2013 is the introduction of security performance framework in the management requirements. This is necessitated by the following ISO 27001 2013 Clauses

    5.2 – Policy

    Clause 6.2 – Information security objectives and planning to achieve them, and

    Clause 9.2 – Monitoring, measurement, analysis, and evaluation

    Here is how this can be achieved:

    With limited time in your hand, even if you spend 30 minutes in a month, you can review the performance of security using the following key issues.

    Irrespective of whether you are compliant to an international best practice such as ISO 27001 or not, these points will drive teams to be ahead in their security performance.

    1. New asset additions – Addition of new assets pose new challenges for security. Asset can be any new information, new intellectual property, new applications, new technology or physical infrastructure, and even a new service provider. Questioning new asset results in verifying whether adequate controls are in place to protect them.
    2. New risks identified – This follows the new asset additions, but new risks may be a result of other external factors beyond the scope of assets. New risks can be as a result of changes in business strategy, customer requirements, operating environments, legal requirements, hazards and/or financial changes – each of which may have an impact on the risk management. New risks are those that do not have a mitigation plan yet, but information about the risk is relevant for management for risk decisions.
    3. New controls added – this can be a result of recent decision to address a new risk. This can be a new technical, physical, procedural or personnel control. Note that a new control always is perceived negatively as it may be seen as an operations hindrance. So question how successful are these new controls and there implementations.
    4. Attack information – updates from log analysis especially gateway protection devices such as spoofing attacks, unauthorized access attempts to key applications, numbers of servers remaining un-patched despite a ‘critical’ patch release, number of theft attempts captured in CCTV – are some of attack information that helps management keeps track of number of break-in attempts. Consider both attacks within and outside the organization including physical area, industry sector as relevant. Sometimes this is just a trend information as you may not be able to prevent, but will be able to verify whether your Business Continuity Plan can handle such events in they really turn into incidents for you.
    5. Number of new vulnerabilities in the wild relevant to our infrastructure – Availability of independent vulnerability sources such as computer emergency response team (CERT) as well as original equipment manufacturer (OEM) reported vulnerabilities – provides huge information, therefore it is important to pick out vulnerabilities relevant to organizations’ own infrastructure. Having identified the relevant vulnerability and how you are tracking to closure would be of interest to management.
    6. Number of people trained in security – this may be both as part of the joining formalities and technical expertise. This is an indicator of how many are being made of organizations’ policies and gives confidence as to how many are left, if any. Training should also include technical skills as well as restoration skills.
    7. Number of reported vulnerabilities within the organization – this is an important indicator of how people participated in the security process and they are reporting incidents/weaknesses. Note that more people report an incident, more aware is your organization.
    8. Metric performance – if you are compliant to an international standard (such as ISO 27001) you are also required to receive performance of security metrics as part of regular reporting. Unlike previous points, in metrics the management has set a target for performance for a security process. Deviations from the target are a subject of root cause analysis (RCA) and should be investigated as part of the compliance process.

    If you are not getting these reports start asking, after all this a management driven system. Your oversight will drive security compliance to a newer level.

    Hope this helps!

     
  • What is common between McDonald and your IT department? 

    It is the catalog. If you don’t have one, create one.

    What is the ultimate goal for both McDonald and your IT department? The answer is perhaps deliver of goods (McDonald), and delivery of services (IT) and customer satisfaction. In case of IT, the customers are business users.

    A lack of visibility of what IT does has been a pain in most organisation and nothing can be much simpler but to start with a service catalog.

    A catalog is a simple definition in service terms. It consists of service name that business understands.

    Infrastructure Availability = calculate the number of maintenance hours you need per year, and using this link – http://uptime.is/ calculate your availability commitment

    Service Availability – Depending upon your office hours, define your support layers. For critical business such as banks, the definitions are banking hours, non banking hours, and Crisis hours.

    Application provisioning, desktop provisioning, user activation are just some of the simple names that IT delivers. For each such service define its availability/SLA target, available hours (for help desk), response time and resolution time in case of an incident, along with a name of person to contact in case of a specific service issue.

    By setting this in place and having an agreement with business users, it is the perfect beginning of a bond between customer (IT users) and service provider, in this case IT.

    Business need not know the intricacies involved, not is it interested.

    If you are a CIO create two service catalogs – one for business and one for your own technology teams.

    So if you have an application development team, database team, networking team or even a security team, demand service catalog from each of them on the same terms as business demands it  from you.

    Once should be able to see a clear cut alignment with business catalog and the internal catalog. You cannot have a business SLA of 99.9% and an internal team reporting anything less than that value, there will be a clear cut mismatch.

    How to create this document?

    Two steps:

    Step 1: Call for a meeting with all teams in a brain storming session and seek all the numbers. Put this in a dashboard and ask every technical team.

    Step 2: Present the document to business for their approval. Let them ask for more.

    Your steps can be in any order, but what will come out is a document that will be a benchmark for service quality.

    So next time you seek a customer satisfaction survey (CSAT), you can also see which service has more satisfaction level than others.

    This process will ensure that you are not far behind McDonald in guaranteeing customer satisfaction.

    Hope this helped!