Role of standards and evaluation criteria & non-technical topics ­ risk analysis, security manager, etc. PV018 Vašek Matyáš Broader scope of standards related to information security ˇ Audit standards ­ Financial audit ­ IS/IT audit ˇ IT security standards ˇ (Other) IT standards IT security standards ˇ Basic standards ­ OSI security architecture, entity authentication mechanisms ˇ Functional standards ­ how to use basic standards ˇ Evaluation criteria ˇ Industrial standards and methodologies ˇ Interpretative documentation ­ dictionaries, guidelines, etc. Classification of standards ˇ By publisher ­ Worldwide ­ ISO, ISO/IEC, CCITT/ITU ­ US ­ ANSI, NIST ­ EU ­ CEN, CENELEC, ECMA ­ Groups ­ IETF-RFC, IEEE ­ Industrial ­ RSA ­ PKCS ˇ By content/cover Basic cryptography standards ˇ Symmetric crypto ­ DES, AES ˇ Asymmetric crypto ­ encryption, signatures, key exchange and transfer ­ IEEE P1363 ­ Factoring-based, Discrete log based, Elliptic curve ­ NIST FIPS 186-3 ­ Digital Signature Standard ˇ Hash functions ­ SHA-1, RIPEMD, (MD5), SHA-512 Cryptographic algorithms ˇ Crucial to most systems ˇ National (self-)interests ˇ Decades of intentional avoidance of this topic for international standardization ˇ Crucial to DES importance ­ indirect support by missing a widely accepted better standards ˇ Therefore high expectations of AES Applied/Functional cryptography standards ˇ Digital certificates ­ X.509, ˇ PKCS ­ RSA, D-H, Certificate, Message, Private-Key, Attributes, Certificate Request, Crypto Token Interface & Information, ECC ˇ Security/Crypto protocols ­ Low level ­ basic standards (entity auth.) ­ ISO/IEC ­ Key Management 11770, Non-rep. 13888 ­ IETF ­ PKIX, IPSEC, S/MIME Cryptonessie ˇ New European Schemes for Signatures, Integrity, and Encryption ­ EU, start 2000, closed recently ˇ Block ciphers, stream ciphers ˇ Message authentication codes ˇ Hash functions ˇ Pseudorandom functions ˇ Asymmetric schemes for ­ Encryption ­ Signatures ­ Identification ˇ All two levels ­ standard/high; http://cryptonessie.org Other areas in ISO/IEC ˇ OSI security ­ subcommittee 6, 21 ˇ Smartcards ­ SC17 ˇ Message Handling Services ­ SC18 ˇ Security mechanisms ­ SC 27 ­ Group 1 ­ General documents ­ Requirements, Security Services, Guidelines ­ Group 2 ­ Majority of the (technical) work ­ Techniques and Mechanisms ­ Group 3 ­ Security evaluation criteria Application areas ˇ Banking security ­ Standards of ISO TC68 ­ ANSI X9 ­ authentication, key management, public-key cryptography ˇ Cryptographic modules ­ FIPS 140-1 (2) ˇ Trusted Third Parties ˇ Electronic payments Evaluation criteria ˇ USA ­ late 60s and 70s ­ need to minimize costs for individual evaluations ˇ 1985 ­ Trusted Computer System Evaluation Criteria ­ "Orange Book" ­ D class ­ no security ­ A1 ­ highest security (mathematical formalism) Development of criteria ˇ Europe ­ ITSEC ­ separation of functionality and assurance ˇ Canada ­ CTCPEC ­ functionality separated into confidentiality, integrity, accountability, and availability ˇ US ­ Federal Criteria ­ development halted ˇ Common Criteria ­ worldwide standard ­ ISO/IEC 15408 Common Criteria ˇ Interests of users, manufacturers, evaluators ˇ Target of evaluation (TOE) ­ what is (to be) evaluated ˇ Protection profile (smartcards, biometrics, etc.) ­ Catalogued as a self-standing evaluation document ˇ Security target (ST) ­ theoretical concept/aim ˇ Evaluation of TOE ­ is the reality corresponding to theory (ST)? ˇ Functional and Assurance requirements Importance of criteria ˇ Eases application and use of secure systems ­ easier comparison and choice-to-fit ˇ Eases specification of requirements ˇ Easier design and development BS7799 ˇ Code of Practice for Information Security Management ­ 1995 ˇ Specification for Information Security Management Systems ­ 1998 ˇ Update of both in 1999 ˇ ISO/IEC standard 17799 Information dominance 1. Aim: Reaching own information dominance: having the right information at the right place in the right time. 2. Aim (offensive): Limit the other party in reaching full information dominance. One step after another... 1. Risk analysis 2. Specification of security policy and security architecture 3. Design and implementation of security mechanisms 4. Support, maintenance, control, re- evaluation (back to 1...) Risk ˇ Risk ­ The probability that a particular threat will exploit a particular vulnerability of the system. ˇ Risk analysis ­ The process of identifying security risks, determining their magnitude, and identifying areas needing safeguards. Risk analysis is a part of risk management. Risk analysis ˇ Often rather risk assessment ­ less formal and rigorous process ˇ Quantitative vs. qualitative ˇ Quantitative ­ Easy to understand the results ­ Results usually in $$$ (risk exposure) ˇ Qualitative ­ Discrete scale (not $$$) ­ Easy to automate, not that easy to understand the results Analysis of IS in general ˇ Often based on BS7799 ˇ Comparison of risks and controls ­ Use of defined scale ­ Does not value assets ˇ Asset-based evaluation ­ For companies critically dependant on IT and those with a bit more complicated structure. A one-man shop can do things rather informally, comparing risks and controls. Risk analysis ­ ALE method ˇ Annual Loss Expectancy (sometimes called Estimated Annual Cost ­ EAC) ˇ ALE = SLE x ARO ˇ SLE ­ Single Loss Exposure ˇ ARO ­ Annualized Rate of Occurrence Problems of quantitative risk analysis ˇ Unreliability and inaccuracy of the data used. ˇ Probability is hardly precise. ˇ Expectations based on data from the past can lead to ungrounded complacency. ˇ Countermeasures and controls can address some events that are inter-related. Principle of qualitative risk analysis Low (10) Medium (50) High (100) High (1.0) Low (10) Medium (50) High (100) Medium (0.5) Low (5) Medium (25) High (50) Low (0.1) Low (1) Low (5) Low (5) Impact Probability Risk analysis ­ BPA ˇ Business Process Analysis ˇ Broader view of risks, not just IT ˇ Some IT risks might not be identified if they do possibly not impact a business process ˇ Outputs ­ map of processes and their descriptions ­ Table of risks (qualitative) and controls ­ Recommendations CRAMM ˇ 1985 ­ UK Government Risk Analysis and Management Method ˇ Structured three-stage approach ­ Identify and value assets ­ Assess the threats and vulnerabilities to the assets ­ Select appropriate recommended countermeasures ˇ Very complex analysis (need for time and trained specialists, use of special software). Risk analysis ­ notes ˇ Information collection ­ questionnaires, interviews ˇ Control of completeness ­ formal checks, experience of the evaluator (!!!) ˇ Processing of inputs (semi-automated) ˇ Report with suggestions for risk reduction or even elimination Incidents caused by ˇ Errors (not intended to happen): 50-70% ˇ Natural/utility influence: 10-15% ˇ Malicious software: 5-10% ˇ Intentional sabotage/attack/corruption by own/past employees/members: 10-20% ˇ External attackers: 1-5% Impact of incidents is yet another issue! Role of IT security manager ˇ Experience with IT security very important ˇ Art of persuasion critical! ˇ Experience: 60% management skills, 40% security expert skills ˇ Very demanding and challenging position ­ Criticized for incidents ­ Criticized for obstructions to "normal" processes ­ Can be appreciated for "nothing happening"? Security is not just prevention 1. Prevention (protection) 2. Detection 3. Reaction Security policy ˇ VERY IMPORTANT for improving the (IT) security in any company ˇ Company business goals IT goals IT security goals ˇ Helps with ­ Setting priorities (for IT, security departments) ˇ Long-term goals vs. short-term goals ˇ Improvement of services (vs.) company survival(!) ­ Getting management support and assuming direct responsibilities Security policy and company culture ˇ The best security mechanisms are useless without effective support of all parties involved ˇ End-users must be trained and interested ˇ Management must be involved (or better lead!) ˇ Security is a process, not a product ˇ Paper "Trends in Government Endorsed Security Product Evaluations", RE Smith http://csrc.nist.gov/nissc/2000/proceedings/papers/032.pdf Recommended reading this week