Ericsson Review: Setting the standard: methodology counters security threats
2 likes3,097 views
This document discusses a new security assurance methodology called SECAM that was developed by 3GPP to address security issues in telecommunications networks and products as they transition to using more open IP technologies. SECAM establishes security requirements for both product development processes and the products themselves. It defines roles like manufacturers, purchasers, accreditors, and evaluators and the processes they follow. SECAM requirements are grouped by telecom functions and cover both development processes and product security. Products are evaluated in stages to test for compliance, basic vulnerabilities, and enhanced vulnerabilities. Manufacturers can become accredited and self-declare that their products meet the SECAM requirements.
Ericsson Review: Setting the standard: methodology counters security threats
- 1. The communications technology journal since 1924 Setting the standard: methodology counters security threats January 29, 2014 2014 • 1
- 2. Setting the standard: methodology counters security threats Security has become a central question for network operators and the global telecommunications industry. This is largely due to a shift to more open IP networks, as well as a diminishing dependence on obscure telecom protocols and isolated infrastructure to provide security. The concerns that arise from these developments need to be addressed holistically throughout product development life cycles from creation to termination. changers have been the availability of open source implementations of 3GPP radio protocols and the use of common platforms.Astheworldmovestowarda futureinwhichtheimpactofthesefac- tors becomes even greater, security has become a primary consideration of the telecommunicationsindustry. To preserve interoperability among products, existing 3GPP telecommuni- cations standards have been developed with a focus on protocols and equip- mentbehavior.Thesecurityelementsof thesestandardspreventattackersfrom misusing systems through the defined protocolsandinterfaces. However, the existing standards do not cover how to securely implement protocols and associated functionality in a product, or how to test any given implementation for vulnerabilities. Neither do the standards specify how to secure the proprietary interfaces of aproductorhowsecurity-relatedissues should be managed throughout the product life cycle. In other words, secu- rity assurance is not part of the 3GPP standards. As demands for tougher security measures now tend to be discussed on a national level, the risk that different countrieswilldevelopdivergingcollec- tions of security requirements is high. This kind of fragmentation may not only make networks more expensive, but it jeopardizes interoperability and threatens subscriber access to network servicesandcapabilities. As this new threat landscape has become more evident and clearer to both governments and the telecom- munications industry, the demand for strongersecurityrequirementsoncom- municationsequipmenthasrisen,with specific emphasis on telecommunica- tionsequipment. Ideally,thestandardsthatgovernthe telecommunications industry should provide sufficient security functional- itytocombatanynewthreats.However, traditional telecom networks have offered a limited set of functionality, whichhasineffectprovidedthemwith protection.Devicesrunningonisolated infrastructurearebynaturelessvulner- able than networked ones. Mobile tele- com networks have an additional layer of protection provided by the many and very detailed telecom specifica- tions. This situation has now changed dramatically. In parallel with the transition to IP technology, the game KARL NORRMAN, PATRIK TEPPO, KEIJO MONONEN AND MATS NILSSON BOX A Terms and abbreviations CCRA Common Criteria Recognition Agreement eNodeB evolved NodeB IEC International Electrotechnical Commission ISO International Organization for Standardization MME Mobility Management Entity RNC radio network controller SCAS Security Assurance Specification SECAM Security Assurance Methodology SRM security reliability model USIM Universal Subscriber Identity Module Over the past decade, the number of attacks on IT and communications systems has risen drastically. This increase has gone hand in hand with a massive rise in the use of communications systems for everything from utilities and public health, to transportation and everyday communication. Ericsson refers to this as the Networked Society, and within it, networks serve as critical infrastructure that is fundamental for economic and social development. However, it also leaves society more vulnerable to cyber threats, both malicious and those arising from carelessness and a lack of awareness – it is this situation that needs to be addressed. 2 ERICSSON REVIEW • JANUARY 29, 2014 Building trust
- 3. Tocounteractthesepotentialthreats to operator revenue, the best approach to addressing security issues is one that isglobalandrootedinstandardization. Standardizationactivities In mid-2012, Ericsson initiated a 3GPP initiative to stay ahead of the new secu- ritychallenges.Theobjectiveofthisini- tiative was to develop a set of security assurance requirements better suited for a world of ubiquitous connectivity, including a methodology to create the requirements, and a process to ensure that commercial products meet the desiredlevelofsecurity. For the methodology part, the ini- tial idea was to reuse the ISO/IEC 15408 standard Common Criteria1 . This approach is often used in conjunc- tion with product certification pro- cesses, such as the Common Criteria Recognition Agreement (CCRA), under which product evaluations and protec- tion profiles are performed to high and consistentstandards. However, 3GPP perceived the Common Criteria methodology to be toocomplexanddecidedtodesignanew andlighterone,whichwouldbetailored to meet the needs of the telecom indus- try – but borrowing from Common Criteriawhenappropriate. The new approach goes under the name of Security Assurance Methodology (SECAM), and its study phase has been completed and documented in a 3GPP Technical Report2 .Theformalizationofthemeth- odology is documented in the 3GPP TechnicalReport3 . Thenewmethodology The aim of any security assurance methodology–andSECAMisnoexcep- tion–istoprovideuserswiththeassur- ance that commercial products fulfill the security goals defined by the prod- uct’s intended use, at a predetermined levelofsecurity. Manufacturers,purchasersandusers often refer to products as being secure. Thetruemeaningofsuchastatementis thataproductmeetsagivensetofsecu- rity requirements, which in the worst case are implicit. But even if a product explicitly fulfills a defined set of secu- rity requirements, it may still contain vulnerabilities–itissimplynotpossible todefineeverysinglewayaproductcan bemisused.Securityrequirementscan be defined in a negative manner, for example: it shall not be possible for an unauthorized agent to modify the sys- temconfiguration. However,thereisnowaytoprovethat a product meets such a requirement. There may be ways for an unauthor- ized agent to modify system configu- ration that are not known at the time ofevaluation. SECAM differs from previous 3GPP standards in that it establishes security requirements not just for products but alsoforthedevelopmentprocessusedto manufacturethem. The methodology applies the follow- ing concept of assurance: an accreditor verifies that a manufacturer is capable of producing products to a given set of security requirements, thus eliminat- ing the need to issue certificates on a per product basis. This approach is in contrasttotheoneadoptedbyCommon Criteria, in which each product is typi- cally evaluated and certified by a third party,andwhereaccreditationrequire- ments relate to the evaluation process and thus fall on the third party and not themanufacturer. Roles,trustrelationships andrequirements SECAM includes a number of different roles, such as manufacturers and pur- chasers, and covers a number of trust relationships. Manufacturers build productsbasedonspecifications,while purchasers – in almost all cases opera- tors–trustthemanufacturertoadhere totheagreedsecurityrequirements. With SECAM, purchasers should be able to trust an accreditor’s indirect verification of a manufacturer’s devel- opment process. As the accreditor only verifies the development process, not the product itself, an additional role is needed to verify that products actually meetgivensecurityrequirements.This istheroleoftheevaluator,whichcould betakenonbyathirdparty.However,it is anticipated – and allowed by SECAM – that manufacturers will assume this role themselves once they have been verifiedbyanaccreditor. These roles and processes are illus- trated in Figure 1, and once all roles have been verified, purchasers will be abletotrustthesecurityofthedelivered commercialproducts. Theaccreditorwillreassesstheman- ufacturer’s product development Product specifications Product specifications ManufacturerManufacturer AccreditorAccreditor EvaluatorEvaluator PurchaserPurchaser Security assurance specifications Security assurance specifications Development Evaluation Purchaser acceptance decision FIGURE 1 SECAM process and roles 3 ERICSSON REVIEW • JANUARY 29, 2014
- 4. for eNodeBs as well as the group of plat- form and physical security require- ments. A product that provides both RNC and NodeB functionality can apply the specific requirement groups for these 3GPP functions, as well as the same platform and physical security requirementsastheeNodeB. Groups of requirements are brought together under the umbrella of a Security Assurance Specification (SCAS),which roughlycorresponds to a Protection Profile in Common Criteria. An SCAS is used as input to the product development process (see Figure 1), and asseveralrequirementgroupscanapply to a product, more than one SCAS may beappropriate. Along with the actual security requirements, an SCAS includes tests to ensure that these requirements are correctly implemented. So, a product thatpassesallofthetestsmeetsthecor- responding requirement. It may not alwaysbenecessaryforaproducttopass all tests in an SCAS, though all results shouldbereported. It is assumed that management of an SCAS will follow normal 3GPP pro- cedures. In other words, corrections or updates are handled by submitting a change request to 3GPP. Under the cur- rent 3GPP meeting schedule, updates canbeproposeduptofourtimesayear. Productdevelopmentprocessand evaluation Intheory,theproductdevelopmentand evaluation process consists of four lin- earsteps.Inthefirststep,theproductis developed, and then it is tested in steps two to four. Security assurance, how- ever, tends to be executed in an itera- tiveandpartiallyoverlappingfashion. To enable purchasers to reevaluate a product, manufacturers must provide thetestresultsfromtheevaluationpro- cessandthedocumentationdescribing the product in the context of the appli- cableSCASs.Ifaproductfailsatest,this shouldbedocumentedandclearlycom- municated to the purchaser. An over- view of the four steps of the product development and evaluation process is showninFigure 2. Throughouttheinitialproductdevel- opment, manufacturers should docu- ment how the requirements of each applicable SCAS correlate to specific processes at regular intervals to ensure that approved procedures continue to be followed. During these assessments, theaccreditorwillalsoverifythatman- ufacturersareabletofulfillthesetsecu- rity assurance requirements, and that theevaluatoriscapableofperforminga properevaluationoftheproduct. The specific security requirements that should be set for product develop- ment processes have yet to be decided. It has, however, been agreed that these requirements will be set by GSMA – which also acts as an accreditation authorityfor(U)SIMmanufacturers4 . Selfdeclaration Oncetheevaluationofaproductiscom- plete, manufacturers can issue a self declaration, which can be used by pur- chasers for guidance during their buy- ing process. A self declaration includes the results of product evaluations, as well as information about whether the manufacturer and the evaluator are accreditedornot. Usingthesecurityrequirementsand test results defined in the self declara- tion, purchasers can carry out their own product evaluation. If the results of such a reevaluation are not consis- tent with the self declaration, the pur- chasermayinitiateadisputeresolution process with the accreditor. Should the accreditor conclude that the accredited manufacturer and evaluator have not acted according to the requirements for the product development process, disciplinary action could be taken, the outcome of which could be the revoca- tionofaccreditationlicenses. Securityassurancerequirements There are two main types of security assurance requirements in SECAM; these two types are also part of the CommonCriteria.Thefirsttyperelates tothedevelopmentprocessandthesec- ondtoproducts. Some examples of requirements relating to the development process includethatthemanufacturershall: useappropriatedevelopment-site protection; deploysufficientversionand configurationmanagement; applysecurecodingguidelines;and ensurethatasuitablepatch managementprocessisinplace. Requirements related to products are definedby3GPPandcollectedingroups. Several different requirement groups could apply to one and the same prod- uct.Forexample,requirementsthatare specific to a particular 3GPP function, such as an RNC, a NodeB, or an eNodeB maybecollectedintoonegroup. Other requirements, such as those related to platform security and physi- cal protection of the implementation may be put into another group. The purpose of this separation is that same requirement groups may be applicable to several different products and can thereforebereused.Forexample,abase station that provides eNodeB function- ality can apply the requirement group Product specifications Product specifications Security assurance specifications Security assurance specifications Development Enhanced vulnerability analysis SCAS compliance testing Basic vulnerability testing FIGURE 2 Product development and evaluation process (according to SECAM) 4 ERICSSON REVIEW • JANUARY 29, 2014 Building trust
- 5. functions, assets or properties of the product.Thisdocumentationisreferred to as the SCAS instantiation and is SECAM’sclosestequivalenttoaSecurity Target in Common Criteria. The pri- marypurposeoftheSCASinstantiation istoprovidesufficientdetailtocarryout the required test activities: compliance testingandbasicandenhancedvulner- abilitytesting. Tests should be specified in such a waythataproducteitherpassesorfails –partialfulfillmentisnotanoption. Compliance testing includes, for example, verification that security configuration documentation exists, and that roles for operation and main- tenance personnel are properly docu- mented. Tool-driven and manual tests (in which a tester interacts with the product), such as verifying that access to the operations and maintenance function is authenticated, can also be includedintheSCAS. Basic vulnerability testing of a prod- uct consists of running a set of security testing tools. Port scanning is one such tool, and this test identifies open ports that should be closed. The testing pro- cess could also include the use of tools that exploit known vulnerabilities in both open and closed source software included in the product, as well as fuzz testingofprotocolimplementations. Enhanced vulnerability testing is a more thorough analysis and requires thatthetesterpossessesadeeperunder- standing of threat analysis and risk assessment than is needed for the pre- viousteststeps. Bynature,thistypeofanalysisishard to standardize, and 3GPP has decided to exclude it from the first stages of SECAM.Itmay,however,beincludedat a later stage, when SECAM has reached agreaterlevelofmaturity. SecurityassuranceatEricsson To ensure the correct level of security existsinitsproducts,Ericssonhasdevel- oped a security reliability model (SRM). This model provides a method to set ambition levels for security features and to ensure that an assigned level is achieved in the implementation of a product. SRM consists of three differ- ent areas, as shown in Figure 3. The processofsettingthesecurityambition levelisbasedonriskassessment. Within the SRM, security measures arefunctionalrequirementsdefinedfor products and are divided into different areas. Each area is further subdivided into levels, depending on the risks and threats associated with the product, so that an appropriate security level can besetforit. In the SRM, a standard set of secu- rity assurance activities – such as risk assessment – act to secure design rule compliance, adherence and vulnera- bility analysis, and configuration and patchmanagement.Theseactivitiesare a mandatory part of Ericsson’s process for product life cycle and are applied to allproductsindevelopment.Riskassess- mentisperformedearlyinthedevelop- mentphaseofaproduct,theoutcomeof whichdetermineswhatassuranceactiv- itiesneedtobeappliedlaterintheprod- uct-developmentprocess. The configuration and operation of security functions is documented in the customer product information. This documentation is also tested dur- ingthefunctionaltestingofthesecurity functions. Instructions and guidelines to support users on how to harden the productisalsopartoftheproductdocu- mentation,aswellasadescriptionofthe product environment (network, physi- cal and operational) and how it should be designed and implemented. All of this forms key parts of the documenta- tionrequiredbySCASsin3GPPSECAM. For Ericsson, the SRM is vital in our RD processes and provides us with a documentedapproachtoassurethatwe developsecureproducts.Allofwhichis in line with the self declaration that is includedintheSECAMprocess. Wayforward Thefirststepin2014intermsofSECAM developmentwillbefor3GPPtodevelop an SCAS for an MME5 and formally record the SECAM process in a perma- nent 3GPP document3 . In parallel with this activity, GSMA will begin to define therequirementsfortheproductdevel- opmentprocess,aswellasestablishthe accreditationauthority. Once these two activities have been completed,vendorsandGSMAwillrun apilottestcaseofSECAMevaluations. Ericsson engineers will continue to use their experience of working with the SRM to provide input to SECAM, andconversely,theSRMwillbealigned withSECAM.Andperhapsmostimpor- tantly,Ericssonwillcontinuetodevelop its SRM as a core feature to combat the constantly evolving threats to the communicationsindustry. Conclusions SECAM provides a framework to set security requirements that are appli- cable on a global scale. It also encom- passes security requirements and models for evaluating the quality of product development processes, as well as indirectly evaluating the qual- ity of commercial products. In addi- tion, the framework includes tests FIGURE 3 Three areas of an SRM Security reliability modelSecurity reliability model Security functions Security functions Security assurance Security assurance Security documentation Security documentation 5 ERICSSON REVIEW • JANUARY 29, 2014
- 6. toensurethatproductsfulfilltheset requirements. The SRM model puts Ericsson in a good position to fulfill the require- ments and help keep future networks secureastheytakeanevermorecentral roleinsociety. 1. ISO/IEC 15408-1, 2009, Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 1: Introduction and general model, available at: http://www.iso. org/iso/home/store/catalogue_ ics/catalogue_detail_ics. htm?csnumber=50341 2. 3GPP, Technical Report 33.805 V12.0.0, Study on security assurance methodology for 3GPP network products, available at: http://www.3gpp.org/ DynaReport/33805.htm 3. 3GPP, Technical Report 33.916, Security Assurance scheme for 3GPP Network Products for 3GPP network product classes, available at: http://www.3gpp.org/ DynaReport/33916.htm 4. GSMA, Security Accreditation Scheme,IncreasingU(SIM)security, lowering business risks, available at: http://www.gsma.com/ technicalprojects/fraud-security/ security-accreditation-scheme 5. 3GPP, Technical Report 33.116, Security Assurance Specification for 3GPP network product classes, available at: http://www.3gpp.org/ DynaReport/33116.htm References Patrik Teppo joined Ericsson in 1995 and is currently working as a security consultant and systems manager in the Network Security Competence Center at Ericsson Finland. He is the driver of Ericsson’s security reliability model (SRM) and provides back office support for 3GPP SECAM standardization. He holds a B.Sc. in software engineering from Blekinge Institute of Technology, Sweden. Karl Norrman joined Ericsson Research in 2001 to work in the area of security. His main focus is security protocols and architectures, software security and security assurance. He is currently Ericsson’s standardization coordinator for security in 3GPP (SA3 working group) and is the main delegate for the work on SECAM. He holds an M.Sc. in computer science from Stockholm University. Mats Nilsson is the director for Product Security within the CTO office. He coordinates the technology- and product-related security activities within Ericsson, including regulatory aspects. In this role, he initiated the 3GPP activities on security assurance and the SECAM standardization. Nilsson is a well- known industry veteran, having held a series of front-line positions within Ericsson since the 1990s, as well as serving as CEO for the Open Mobile Terminal Platform initiative. Keijo Mononen is the Head of the Ericsson Network Security Competence Center. His Competence Center is responsible for driving and supporting network security activities across all of Ericsson’s Business Units. Mononen has been with Ericsson for 23 years in various positions both in RD, the business line and service delivery. For the past 10 years he has worked with security in both RD and services. He holds an M.Sc. in computer science and engineering from Chalmers University of Technology, Gothenburg, Sweden. 6 ERICSSON REVIEW • JANUARY 29, 2014 Building trust
- 7. To bring you the best of Ericsson’s research world, our employees have been writing articles for Ericsson Review – our communications technology journal – since 1924. Today, Ericsson Review articles have a two-to- five year perspective and our objective is to provide you with up-to- date insights on how things are shaping up for the Networked Society. Address : Ericsson SE-164 83 Stockholm, Sweden Phone: +46 8 719 00 00 Publishing: Ericsson Review articles and additional material are pub ished on www.ericsson.com/review. Use the RSS feed to stay informed of the latest updates. Ericsson Technology Insights All Ericsson Review articles are available on the Ericsson Technology Insights app available for Android and iOS devices. The link for your device is on the Ericsson Review website:www ericsson.com/review. f you are viewing this digitally, you can: download from Google Play or download from the App Store Publisher: U f Ewaldsson Editorial board: Håkan Andersson, Hans Antvik, Ulrika Bergström, Joakim Cerwall, Deirdre P. Doyle, Dan Fahrman, Anita Frisell, Jonas Högberg, U f Jönsson, Magnus Karlsson, Cenk Kirbas, Sara Kullman, Kristin Lindqvist, Börje Lundwall, Hans Mickelsson, Ulf Olsson, Patrik Regårdh, Patrik Roséen and Gunnar Thrysin Editor: Deirdre P. Doyle deirdre.doyle@jgcommunication se Chief subeditor: Birgitte van den Muyzenberg Contributors: Paul Eade, Nathan Hegedus and Ian Nicholson, Art director and layout: Jessica Wiklund and Carola Pilarz Illustrations: Claes-Göran Andersson ISSN: 0014-0171 Volume: 91, 2014
- 8. Ericsson SE-164 83 Stockholm, Sweden Phone: + 46 10 719 0000 ISSN 0014-0171 284 23-3221 | Uen © Ericsson AB 2014