1、A formal mand risk assessment method for Security-CriticalReal-Time Embedded SystemsSiru Ni1; Yi Zhuang1; Jingjing Gu1; Ying Huo11College of Computer Science and Technology, Nanjing University of Aeronautics and Astronautics (College of Computer Science and Technology, No. 29 Jiangjun Rd., Nanjing,

2、Jiangsu, 210000, )s: nisr; zy16; gujingjing; huoyingAbstract Risk assessment at the early stage of software development can effectively reduce potentialsecurity flaws in the software, thus reduce the cost of testing and maintenance. However, there are veryfew standardized risk assessment methods tow

3、ards the design ms of security-critical RTESs(Real-TimeEmbeddedSystems).ThispaperdefinesaformalmcalledOMR(Object-Message-Role) using Z notation for the security-critical RTESs. Comparing with the existingms for RTESs, OMR is able to specify both the functional and security aspects of the system as a

4、nintegrated m, which directly provides the input for risk assessment. A risk assessment methodRAMES (Risk Assessment Method for Embedded Systems) based on OMR is then proposed. RAMES is complianced with the risk management process standardized by ISO 31000. To perform the risk analysis in RAMES, an

5、algorithm RAOMR is designed based on the analysis of the message flows andsecurity constraints in OMR. The illustration of a case study shows that RAMES is able to evaluate therisk level of the system m, and locate the high-risky objects and messages.KeywordsRisk Assessment; Security; Real-Time Embe

6、dded Systems; Formal Method; Z Notation1IntroductionDependability of software is defined as the ability to avoid failures that are more frequent and more severe than acceptable (Avizienis et al. 2004). Security of software means the ability to beattack-resistant, attack-tolerant, and attack-resilien

7、t (DHS 2006). According to ISO/IEC 25010 (2008),the attributes of software security includeity, integrity, non-repudiation,ability, etc.Security is a significant aspect of dependability, especially to RTESs (Real-Time Embedded Systems) which are applied in various critical scenarios and are more vul

8、nerable than general software. Evaluating vulnerabilities within the system designs is necessary to building secure RTESs. However, the security measures currently taken in the development process of RTESs to enssure data security are not sufficient, due to the increasing openness and interactivity

9、of such systems (DHS 2006). Run-time security mechanisms require system resources that are often scare in RTESs (DHS 2006) and therefore should only be applied to security-critical components.Risk assessment is one of the most common measures to ensuring software security. A lot of standards (AZ/NZS

10、 4360 2004; ISO/IEC 27002 2005; BSI 100-1 2005; ISO 31000 2009) andresearches (Zambon et al. 2011; Bernardi et al. 2011a; Cortellessa et al. 2005) regarding riskassessment methods have been issued in recent years around the world. Particularly, risk assessment ofsoftware ms at the early stage of the

11、 development process is an effective way of reducing the costof testing and maintenance, because it enables us to fix potential security flaws in the software ms1without modifications at the cevel. However, qutative risk assessment methods for RTESs arerarely considered in the current standards (Zam

12、bon et al. 2011; Bernardi et al. 2011a). To identify andevaluate risks of RTESs, it is significant to mtheir specialized elements as well as their securityconstraints. The existing ms for RTESs (OMG 2011; Feiler et al. 2006) are not applicable in ourscenario, because they lack either security elemen

13、ts or rigorous sems. Therefore, this paper isaiat designing a formal mfor security-critical RTESs and a corresponding qutative riskassessment method based on standardized procedures of risk management.The commonly used formal languages for building software security ms include Petri Net(Bernardi et

14、al. 2011a; Dutilleul et al. 2006), Markov M(Goseva-Popstojanova et al. 2003), Z(Chivers et al. 2009), Bayesian networks (Poolsappasit et al. 2012), Queuing Network (Cortellessa et al. 2005), Fuzzy Cognitive Maps (Szwed and Skrzyski 2014), Danger Theory (Sun 2011), Fuzzy Logic(Chen and Chen 2003; Lu

15、et al. 2013), etc. The combination of formal and semi-formal softwareming methods has been chosen by many researchers, because of the complementarity of the twocategories of methods (Bernardi et al. 2011b; Hahn and Fischer 2008). However, in most of the currentsecurity ming methods, the separation b

16、etween functional mand security mcan greatlyincrease the complexity of security analysis process (Qamar et al. 2011). The current ms for riskassessment are often established on the risk factors, such as likelihood and impact (Chivers et al. 2009),of mmsoftware components, to support the risk evaluat

17、ion. The disconnection between risk analysis s and software specifications makes it harder to combine risk assessment processes to theing phase of software.We desire to build a tightly-coupled security mfor RTESs, which can be derived fromexisting semi-formal ms to improve industrial usage of our me

18、thod. As one of the most descriptivelanguages, Z has great advantage of expressing constraints in the specification of state spaces andoperations (ISO/IEC 13568(E) 2002), thus is very suitable for building our security mandspecifying our risk analysis method. In our previous work (Ni et al. 2014), a

19、 formal mZ-MARTEis defined to describe and analyze dependability constraints of RTESs, combing Z and MARTE(Ming and Analysis of Real Time and Embedded systems) (OMG 2011). The schema ofdependability stereotypes is proposed to customize the attributes of dependability into state spaces, toenhance the

20、 descriptive ability towards Non-Functional Properties (NFPs).This paper defines OMR (Object-Message-Role), a formal mfor security-critical RTESs,based on the refinement of Z-MARTE dependability stereotypes. The attributes of OMRs mingelements have used the profiles of MARTE and SecureUML (Basin et

21、al. 2006) for reference. OMRprovides necessary information regarding both funcational structures and security strategies of thesystem. The basic structure of an OMR mcan be automatically extracted from the existingUML/MARTE/SecureUML diagrams. A risk assessment method RAMES (Risk Assessment Methodfo

22、r Embedded Systems) is designed by specializing each stage of teric risk management processpresented in ISO 31000 (2009). Risk analysis in the RAMES method is performed by a proposed algorithm RAOMR (Risk Analysis algorithm of OMR), using a common combination of risk factors to estimate the risk lev

23、el of each system components. The illustration of a case study shows that RAMES is able to effectively and efficiently evaluate the risk level of security-critical RTESs and locate thehigh-risky objects and messages for further security enhancement.The rest of this paper is organized as follows. In

24、Section 2, we define the OMR mforsecurity-critical RTESs. The risk assessment method RAMES based on the OMR mis presented inSection 3. In Section 4, we illustrate the risk analysis procedure of RAMES through a case study and2explain the results. In Section 5, the related work and some comparisons wi

25、th our method are given.We present thein Section 6.2OMRRTESs have been increasingly open and interactive. Their operating systems are tightly coupled with hardwares. As a result, the internal data in RTESs are more likely to be accessed illegally through existing interfaces than gereral software. In

26、 order to locate potential attack paths in the m , we needto specify both structure and transmission of the data (Chivers et al. 2009), namely, the functionalmof the system. Additional security strategies in both storage and transmission of the data must bespecified as the security mof the system. I

27、n Object-Oriented (OO) ms, objects are theinstations of classes, which provide interfaces to the data storage. The communications betweenobjects, on the other hand, determine the paths and constraints of the data transmission. In this section,we define a mwith three categories of elements: the Objec

28、t mis therefore called OMR (Object-Message-Role)., Message mand Rolem. The mZ is based on schema, a structure containing a declaration part and a predicate part. The former declares a group of variables and the latter describes their relations as invariants based on set theory and first-order logic.

29、 A dependability stereotype is specified by a group of attributes and their constraints as a schema (Ni et al. 2014). With the purpose of building a tightly-coupled system m , we embedd security-related stereotypes into the schemas of functional elements as declarations, tospecify security constrain

30、ts as invariants. In this section, we formally define the OMR m asschemas, specify necessary constraints within and between the Object, Message, and Role ms, andgive some explanations of how we can extract the basic elements from the corresponding elements inUML/MARTE/SecureUML m2.1 The Object M.The

31、 Object mis the basic functional mof secure RTESs, describing data structures, operations and their security-related structures. The objects in RTESs are distinguished as eithersoftware or hardware types, so that it is more convenient to assign their security strategies.Definition 1. The Object mspe

32、cifies the following elements:(1)Object Objects are denoted by a given set O. Object types are denoted by atypeOTYPE:OTYPE = soft|hardwhere soft denotes software resource types, and hard denotes hardware resource types.(2)AssetAssets are defined as valuable data with certain security attributes. The

33、y are stored inand transmitted by objects. Assets are denoted by a given set ASSET. Their security attributes include security concern, which is denoted by CONCERN, and security level, which is denoted by SL. The elements in SL must have a partial ordering relation to be ordered by certain operators

34、. Assume that x1,x2X, where elements in set X have a partial ordering relation, we denote by x1< x2 that x1 is prior to x2.Operation Operations are executed by objects. In order to emphasize on how they can effect the security attributes of assets, operations are defined as the combination of inp

35、ut/modified/output parameters. In particular, the modified parameters can either be input parameters or generated by the computation. All the parameters can either be in the local storage or received from another object. Therefore, each parameter is associated with the asset of at least one object.

36、Operations are denoted by a given set OP.3(3)(4) Security Policy of Objects The security policies of an object are set to enhance the datasecurity, that is, to protect the data from unauthorized disclosure or modification. We definethe degree ofof such policies as the security factor, which can be n

37、ormalized as aqutative value within the range of 0, 1. Moreover, we assume that the smaller itssecurity factor is, the betterthe security policy provides for the data. To give anillustration of security policies, the security policies of objects in this paper are denoted by a type SP:SP = en|ac|vewh

38、ere en denotes the encryption policy, ac denotes the access control policy, and ve denotes the integrity verification policy.The declaration part of the schema of the Object mMOfObject contains six finite sets: (1)objects (Objects), (2) assets (Assets), (3) object types (OTypes), (4) operations (Ops

39、), (5) security levels (Sls), and (6) security concern (Concerns). It also contains five relations: (1) the relation between objects, assets, object types and operations (ObjectsAssigns), (2) the relation between assets and their security attributes (AssetsAssigns), (3) the relation between security

40、 policies and the assets they are applied on (Osps), (4) the relation between objects and their security policies (OspsAssigns), and (5)the relation between operations and their parameters (OpsAssigns).The predicate part of the schema MOfObject contains a consistency constraint, whichindicates that

41、when assigning a security policy (a, sp, c, spr) to an object o, the policy must exist in Osps, the asset a must belong to the asset set aset of o, and the security concern c must be consistent with the security concern of a, which is defined in AssetsAssigns. The schema of M OfObject isdefined as f

42、ollows.Some basic elements in the Object mcan be extracted from UML class diagrams andsequence diagrams. In the class diagram, the classes define the structures of objects, so that their attributes should be mapped to the assets, and their operations should be mapped to the operations ofthe correspo

43、nding Objects. In the sequence diagram, the objects should be mapped to the set of Objects.The elements that the UML/MARTE mcannot provide, such as the sets of Sls and Concerns, aswell as the constraints, should be manually specified.2.2 The Message MThe Message mdescribes data transmission as well

44、as their security-related structures. Thecommunication beween objects are determined by the possible executions of operations. Because the parameters of operations are associated with assets, we need to assign certain security policies to the4messages to protect the system from potential unauthorize

45、d data disclosure or modification.Definition 2. The Message mspecifies the following elements:(1) Message Messages are the means of communication between objects. The uniqueness of a message is determined by the combination of its source/target objects, the operation that sends it, and its content,

46、which can either be in the local storage or received from another object. Each content is associated with the asset of either the source or the target object of the message. Messages are denoted by a given set MSG.(2) Security Policy of Messages The security policies of a message are to protect its

47、content from potential unauthorized data disclosure or modification. The security policies ofmessages are defined the same as the security policies of objects.The declaration part of the schema of Message mMOfMsg contains a finite set ofmessages (Msgs). It also contains three relations: (1) the rela

48、tion between messages, objects, operationsand assets (MsgsAssigns), (2) the relation between security policies and the message contents they are applied on (Msps), and (3) the relation between messages and their security policies (MspsAssigns).The schema of MOfMsg is defined as follows.In the UML se

49、quence diagram, the messages between objects should be mapped to the set of MSG,while the corresponding classes of the objects should be mapped into the constraint MsgsAssigns. Therest of the Message m2.3 The Role Mshould be specified manually.The RBAC mechanism assigns a set of permissions to every

50、 role, which is a group of system users.A role basically decides how much information you are allowed to get or process. The Role m describes not only the above structures, but also the inheritance relations between roles.Definition 3. The Role mspecifies the following elements:(1)(2)User Users are

51、defined as exclusive identifications, which are denoted by a given set ID. RoleRoles are denoted by a given set ROLE. A role can inherit other roles only non-cyclically, in order to avoid the infinite expansions of schemas.Permission A permission is defined as an authority for a certain role to oper

52、ate on a certainresource, which in our case is an asset. Permissions are denoted by a given set PER.(3)Permission types are denote by atype PTYPE:PTYPE =|writewheredenotes the permission ofing, and write denotes the permission of writing.The declaration part of the schema of Role mMOfRole contains f

53、our finite sets: (1) users(Users), (2) roles (Roles), (3) permissions (Pers), and (4) permission types (PTypes). It also contains five relations: (1) the relation between assets and permissions (PersAssigns), (2) the relation between users and roles (UserAssigns), (3) the relation between roles and

54、permissions (RolesAssigns), (4) the inheritance relations between roles (Inherits), and (5) the relation between roles and permissionsconsidering the inheritances (InheritsAssigns).The predicate part of the schema MOfRole contains a consistency constraint regarding thenon-cyclical inheritance relati

55、ons of roles. The schema of M5OfRole is defined as follows.Some of the elements in the Role mcan be extracted from the SecureUML m. The sets ofRoles, Pers and PTypes are corresponding to the roles, permissions and their entity actions (Qamar et al.2011). The constraints PersAssigns, RolesAssigns and

56、 Inherits can also be extracted from the attributesof SecureUML m, while other constrains in the Role mshould be manually specified.2.4 Integrating OMR MWhen combining the Object, Message and Role m constraints between their related elements. The integrated ms, we must specify the consistencyof OMR

57、is defined as a schema, too.Definition 4. The OMR mis defined as follows:The declaration part of the schema of OMR mMOfOMR contains three state spaces:MOfObject, MOfMsg and MOfRole. The predicate part of the schema MOfOMRcontains three consistency constraint:(1) For an operation op of an object o, its input parameters must belong to the assets of o, and thecontents of the messages ids must belong to the output parameters.(2) For a message msg from so to to, its content m must be an asset of so, and the operation op that sends it must be an operation of so.(3) When assigning a security