COMP3357 Cyber Security

1. COMP3357 Cyber Security Richard Henson University of Worcester February2017

2. Week 4: Implementing and Managing a Security Policy • Objectives: • Explain the importance of having a system for managing information security • Explain, with examples, the balance of risk v cost in organisational security • Explain the complexity of decision-making on whether, or whether not, to spend on security • Identify the important roles in implementation of information security policy

3. Role of Advisor/Consultantafter agreement of policy • Putting policy into action is important as production of Information Security policy • often difficult to change “from within” • advisor/consultant had an important guidance role alongside e.g. IT manager when policy made! • role shouldn’t stop once policy has been agreed and filed…

4. Role of Adviser/Consultant in Implementation of Policy • Enforcement essential… • otherwise policy-making a worthless exercise! • Knowledge & experience really useful to an organisation developing for first time a secure online facility to meet business strategic needs • help develop procedures… • agreed at institutional level (senior mgt) • implemented by departments (middle mgt)

5. Implementation and Standards • Why do organisations get accredited to an information assurance standard? • actions required to get accredited ensure… • policy implementation processes in place • executed through “controls” • implementation is cyclical and lessons are learned from the failure of a control

6. Implementation of Policy (Technical) • Matter of operationalising the agreed technologies that CURRENTLY combat a particular threat • e.g. threat (1): unauthorised internal access • control: careful choice of parameters in GROUP POLICIES makes sure that Windows network users only have access to files & services they need • e.g. threat (2): unauthorised access via web • control: authenticate a secure site for buying online – check, read, approve server certificate

7. Implementation of Policy (Technical) • Good consultant… useful advice regarding: • embedding any new technologies into existing systems as seamlessly and transparently as possible! • bring about a set of procedures from the agreed policy and tools available/potentially available that should cover all eventualities…

8. Implementation of Procedures (People - 1) • Some (automated) procedures implemented by specialist IT/networking/backend staff: • will ensure security of servers and of data coming into/leaving the organisation • Procedures involving end-user security cannot be easily automated: • implemented by ALL staff • must UNDERSTAND • what new procedures are • crucial importance to the organisation • otherwise reluctant to change habits

9. Implementing of Procedures (People - 2) • Set of procedures distributed to end-users by email… • will have little effect! • people will resent being told to do it differently • often carry on in their own sweet way…

10. Implementing of Procedures (People - 3) • Senior Management must also provide the means to enforce policy through “carrot-and-stick” • penalties for not using procedures • reward for following policy through taking new procedures on-board • To do this fairly… needs a means of measuring whether employee is following new procedures

11. Impact at the Operational Level • New procedures may well affect work practices • impact of each needs to be carefully considered… • Pilot scheme first • carefully trialled at operational level… • time for retraining realistically assessed • accurate capital costing for roll-out • When lessons learned… • Sold positively to staff i.e: • YES, does mean learning new procedures • BUT, there’ll be less threat from viruses, pop-ups, etc.

12. Testing Implementation of Policy • A wise manager will not impose something new on employees without checking first that it is WORKABLE • pilot with a small group first… • get feedback… • learn lessons… • make changes (if needed) • devise a PLAN for roll out across the organisation

13. Selling the new procedures • Most policies implemented on a departmental basis • job of enforcement may be through departmental line managers • To enforce a policy, line managers must be able to understand it! • first stage should be EDUCATION of the managers • will be time issues, so centrally managed

14. Selling the Policy • Once the penny drops, managers will be aware it will mean changes to working practices… • need to assure about training • need be assured that it is worth doing: • for the individual employee • for the department • for the whole organisation

15. Reviewing the Policy/Procedures • If the problem is understood at a conceptual level… • POLICY changes shouldn’t be necessary • However… • security technology does not stand still! • PROCEDURES may need to be revised… • every year? every six months? • whenever a new threat becomes apparent? • balance!!

16. Assessment of Risk to Information as a result of threats • Risk Assessment well understood as a discipline for e.g. Health & Safety • Less well understood regarding IT matters (!) • Could be of two types: • qualitative (e.g. high, medium, low) • quantitative (e.g. 73% of a breach in the next two years)

17. The Nature of Risk • Can be a highly academic matter: • mathematics and complex theories • in practice better not to engage in such matters with organisations! • just understand basic concepts, and apply them! • also defend your risk analysis work against fallacies resulting from a “academic” approach • Quantitative risk assessment usually gives more useful information than qualitative

18. Safe Ground for Quantitative Risk Assessment • Stick to matters of: • predictions • probability • subjectivity • precision • accuracy • criticisms of quantitative analysis? • weaknesses in those arguments?

19. Possible or Probable? • Risk analyst may consider all the bad things that could happen when conducting an assessment… • list of POSSIBLE (qualitative risk) scenarios everything everyone on the team could think of that might go wrong? • But only “possible” (not enough!) • usually better to focus on probabilities… • need at least to be part of the analysis

20. Differences between Probability and Possibility • Normal Russian roulette (“game”) • one or more people use a gun with at least one empty chamber • each in turn manually roll the ammunition holder before letting it randomly fall to rest • then point at head • pull the trigger • big risk… ? Qualitative or Quantitative?

21. Russian Roulette with a further twist! • “Players” get to pick: • a six shot revolver • semi-automatic pistol • Which would you choose? • approaching risk analysis as purely a possibility issue… • either gun is an equivalent choice • either gun will possibly land a bullet in your brain!” • BUT… of course the risks are different!!”

22. Risk Analysis • Six-shot revolver… • probability is 1 in 6 • about an 83% chance of surviving! • Semi-automatic pistol… • probability close to zero • it could jam or the bullet could be a dud • Conclusion • possibility perspective not at all helpful in making a good decision! • death 100% possible with either weapon

23. Useful Risk Assessment • Think what events are possible • only as a means of surfacing events • Analyze probability for each… • decisions informed by probabilities, NOT possibilities! • Some low probability risk scenarios that will need to be accounted for • most organizations have found a way to deal with them…

24. Risk Scenario • What is the risk an organisation could lose their data center in a natural disaster?

25. Analysis, Assessment, Management • If an organisation wishing to protect its data center decides to go tracking meteors… • perhaps their risk management isn’t at the right level... (!) • BUT… quantitative analysis can be difficult, especially if there isn’t much empirical data available • treat hit by meteor as a possibility • not distinguish it from a likelihood perspective

26. Another Risk Scenario • No hard data on instances of network managers compromising sensitive information • Conclusion… this is “possible” • could be a million times per year • one per year • not making a distinction between options means no prioritization for that risk

27. Probability, Likelihood & Frequency • e.g Weather Forecasting… • Often given as over five days • 63% chance it would rain sometime during the upcoming week? • But doesn’t tell us which day it’s most likely to rain! • without a more information about times, we can’t make good decisions

28. Time and Frequency • What if no time-frame reference at all (ie just 63% chance of rain…”) • even worse than before • wouldn’t know if the 63% applied to Wednesday, the whole week, that month, whenever! • Likelihood without context (like data without context..) is not useful as information

29. Economics of Information Security • Academic research area • seeking to produce economic models for organisations to attribute value to data • Back to basics of Information Security: • Confidentiality • consequences of losing data…??? • Integrity • consequence of having data interfered with…