On the balancing security against performance in

On the balancing security against performance in database systems Damian Rusinek1 , Bogdan Ksiezopolski1,2, Adam Wierzbicki2 1

Institute of Computer Science, Maria Curie-Sklodowska University, Lublin, Poland 2 Polish-Japanese Academy of Information Technology, Warsaw, Poland

Abstract. Balancing security against performance for IT systems is one of the most important issues to be solved. The quality of protection of systems can be achieved on different levels. One can choose factors which have a different impact on the overall system security. Traditionally, security engineers configure IT systems with the strongest possible security mechanisms. Unfortunately, the strongest protection can lead to unreasoned increase of the system load and finally influence system availability. In such a situation the quality of protection models which scale the protection level depending on the specific requirements can be used. In the article, we present the approach which enables balancing security against performance for database systems. The analysis is performed by Automated Quality of Protection Analysis (AQoPA) tool which allow automatic evaluation of system models which are created in the Quality of Protection Modelling Language (QoP-ML).

Keywords: quality of protection, security economics, modelling and protocol design, cryptographic protocols, security protocol analysis, network security

1

Introduction

The simultaneous analysis of the security and its influence on the system performance in IT systems is one of the most important topics to be solved. On one hand, the traditional approach assumes that implementation of the strongest security mechanisms makes the system as secure as possible. Unfortunately, on the other hand, such reasoning can lead to the overestimation of security measures which causes an unreasonable increase in the system load [7, 8, 22, 23]. The system performance is especially important in the systems with limited resources such as the wireless system networks or the mobile devices [5, 24]. Another example where such analysis should be considered is cloud architecture. The latest research indicates three main barriers for using cloud computing which are security, performance and availability [4]. Unfortunately, when the strongest security mechanisms are used, then it will decrease system performance and further influence system availability. This tendency is particularly noticeable in complex and distributed systems. Among other applications where balancing security against performance are most demanding are those which are using Peer-toPeer (P2P) protocols, due to their decentralized and distributed nature (for a

good overview, see [13]). Another example are application-layer multicast protocols that are a practical solution for streaming media delivery in the absence of network-layer support [25]. These practical applications are vulnerable to manin-the-middle attacks, require specialized authentication and access control [27], and have strong requirements for fairness [26]. The latest results show [10, 11] that in many cases the better way is to determine the required level of protection and adjust security measures to these security requirements [14]. Such approach is achieved by means of the Quality of Protection models where the security measures are evaluated according to their influence on the system security.

2

Related Work

In the literature the Quality of Protection (QoP) models were created for different purposes and have different features and limitations. Below the related research in this area is presented. S.Lindskog and E.Jonsson attempted to extend the security layers in a few Quality of Service (QoS) architectures [17]. Unfortunately, the descriptions of the methods are limited to the confidentiality of the data and based on different configurations of the cryptographic modules. C.S. Ong et al. in [19] present the QoP mechanisms, which define security levels depending on security parameters. These parameters are as follows: key length, block length and contents of an encrypted block of data. The article [21] presents an adaptable protocol concentrating on the authentication. By means of this protocol, one can change the version of the authentication protocol which finally changes the parameters of the asymmetric and symmetric ciphers. The article [6] introduces mechanisms for adaptable security which can be used for all security services. In this model the quality of protection depends on the risk level of the analysed processes. A.Luo et al. present the quality of protection analysis for the IP multimedia systems (IMS) in [16]. This approach presents the IMS performance evaluation using Queuing Networks and Stochastic Petri Nets. E. LeMay et al. create in [15] the adversary-driven, state-based system security evaluation, the method which quantitatively evaluates the strength of systems security. In the article [20] authors present the performance analysis of security aspects in the UML models. This approach takes as an input a UML model of the system designed by the UMLsec extension [2] of the UML modelling language. This UML model is annotated with the standard UML Profile for schedulability, performance and time and then analysed for performance. In the article [9] the Quality of Protection Modelling Language (QoP-ML) is introduced. It provides the modelling language for making abstraction of cryptographic protocols that put emphasis on the details concerning quality of protection. The intended use of QoP-ML is to represent the series of steps which are described as a cryptographic protocol. As mentioned above, during the QoP analysis one can not consider only primary cryptographic operations or basic communication steps. This analysis must be multilevel. The QoP-ML introduces the multilevel protocol analysis that extends the possibility of describing the

state of the cryptographic protocol. Every single operation defined by the QoPML is described by the security metrics [18] which evaluate the impact of this operation on the overall system security [12] The article presents an analysis of performance versus security in data storage system. First, the QoP model of system which realize the service at different quality of protection level was created. Then, performance analysis has been conducted for various scenarios and the results were verified experimentally. The model, which was created in QoP-ML, is the first model that presents the use of language QoP-ML and analysis by AQoPA (Automated Quality of Protection Analysis) tool of the IT system using database systems. In presented case study performance refers to the time behaviour from performance efficiency category and to the availability from reliability category from ISO/IEC 25010 [1]. The metrics for performance are the response times and throughput rate which must meet the availability requirements (eg. response time under 500ms, ability to handle 100 sessions per hour). The quality of protection (QoP) is understood as the set of security properties (security category in ISO/IEC 25010) ensured by the system. Its quality is measures as the complexity of performing a successful attack on the cryptographic mechanisms ensuring selected properties. The complexity can be measured as the number of brute force checks in order to find the key (assuming that cryptographic primitives are ideal) or as the complexity of the best known attack on particular primitive (more practical approach). The level of protection can be different for the same set of properties depending on the cryptography mechanisms used and its parameters (eg. algorithm: aes, 3des, key size: 128, 256, mode: ecb, cbc).

3

Modelling of storage center in QoP-ML

Detailed and precise examination of different parameters and comprehensive analysis of IT systems is a challenging task. To solve a problem, it should be formulated by means of standardized methodologies and all relevant information should be collected. As the decision making action is a reproducible process, a more comprehensive view should be taken into account. The decision cycle includes four phases: problem definition (a decision situation dealing with difficulty or with an opportunity), model construction (for description of the real-world problem using specialized tools), identification and evaluation (identification and evaluation of possible solutions) and recommendation and implementation (examination, comparison and choice of potential solutions). Different solutions of a given problem can be considered and evaluated by means of QoP-ML approach and AQoPA evaluation. Such decision support system enables defining distinct scenarios and examination the obtained results. The scenarios also referred to as versions are possible sets of input parameters and characteristics of the modelled environment which allow analysis of consequences of decision alternatives with past experience in a context being described. The decision making cycle is useful in proper security management.

Properly designed, specialized, dedicated support system allows defining and modelling various scenarios differing in utilized security mechanisms and assessing its performance. The modelling of IT systems in the Quality of Protection Modelling Language consists of four successive stages: stage 1 - model creation, stage 2 - security metrics definition, stage 3 - scenarios definition and stage 4 - simulation. These stages refer to the methodology of creating QoP-ML models defined in the article [9] where the details about syntax and semantics can be found.

Stage 1: Model creation

Stage 2: Security metrics definition

Stage 3: Scenario Definition

Stage 4: Evaluation

Fig. 1: The four stages of QoP-ML modelling

In this section we present the QoP modelling and AQoPA analysis for storage center as the example of IT system. We analyse different configurations and scenarios of protocol retrieving and searching information from the database. One can imagine that the database stores the details of company customers (corporate network) while employees use devices (public network) with thin clients to obtain information about particular customers. In the analysis process we prepare different scenarios for searching and retrieving data from the database. The differences in scenarios come from different configurations of security mechanisms and assuring different sets of security attributes. We also examine the server load, depending on the number of concurrent client connections. Each scenario is tested for 100 simultaneous clients. 3.1

Scenarios

In the description of scenarios (Fig. 2, Fig. 3, Fig. 4, Fig. 5) we use the following notation:

IDA Q RES REQ(KQ )

-

KQ

-

KS,SKS P KA SKA {M }K {M }P KA {M }SKA H(M )

-

identification of site A, search query, search results, request for the key of the part of database selected by main query Q, the key that particular part (selected by query) of database is encrypted with, symmetric key shared by the S and SKS, public key of A, secret key of A, symmetric encryption of M with the key K, encryption of M with the public key of A, signature of M with the secret key of A, hash of M .

Scenario 1 In the first scenario the database is not encrypted and we analyse the protocol without security mechanisms. The protocol is shown in Fig. 2.

Scenario 1 Client

Server

C

S {IDC , Q} RES

Fig. 2: Protocol in Scenario 1.

In the first step the client sends his/her identifier and search query to the server. The server finds the part of database that query refers to and executes the SELECT query using the remaining part of the query. The selected rows are sent back to the client in the second step. Scenario 2 In the second scenario we assume that the whole database is encrypted in order to protect it against data theft and leakage. However, the server must have access to the plaintext when executes search operations. We assume that the server can obtain the encryption key temporarily (for the time of one search operation) from Secure Keys Storage Server to decrypt the data and select a subset of records. The decryption of the whole database may take a long time therefore we assume that the database is indexed and divided into small parts of data (e.g. customers are divided based on the first letter of the last name). However, on the other hand, the database cannot be indexed in too much detail, because

an attacker may distinguish records according to the indexing information (e.g. there may be only one customer on the particular street). In this scenario the database was encrypted by means of the AES-128-CBC cipher. The protocol is presented in Fig. 3.

Scenario 2 Client C

Server

Secure Keys Storage

S

SKS

{IDC , Q} REQ(KQ ) {KQ }KS,SKS RES

Fig. 3: Protocol in Scenario 2.

In the first step the client sends his/her identifier and search query to the server. The server, in the second step, sends the request for the database key with the obtained query to the Secure Keys Storage Server. Secure Keys Storage Server selects the part of the database according to the subset of query containing the information about indexing (e.g. all customers with the last name staring with A). In the third step Server sends back the key, encrypted with the shared key KS,SKS , required for decrypting the appropriate part of the database. Server decrypts the selected database part and executes the database query using the rest of the search query. In the fourth step, the selected rows are sent back to the client. Scenario 3 The third scenario is the same as the second one, but different configuration is used. The database is encrypted with the AES-256-CBC cipher. Scenario 4 In the fourth scenario the database is not encrypted, but the cryptographic modules which ensure integrity and authentication are implemented. The protocol is presented in Fig. 4. In the first step the client sends his/her identifier and search query to the server. The server finds the part of database that search query refers to and executes the database query using the remaining part of the search query. Afterwards, the server calculates the hash of results and signs it with his/her private key. The selected rows and signed hash are sent back to the client in the fourth

Scenario 4 Client

Server

C

S {IDC , Q} {RES, {H(RES)}SKS }

Fig. 4: Protocol in Scenario 4.

step. For asymmetric operations there was used the RSA algorithm with the key of 2048 bits length. The hash was generated by the SHA-1 algorithm. Scenario 5 The difference between the fourth and fifth scenarios is that in the fifth scenario the database is encrypted with the AES-256-CBC cipher. The protocol is presented in Fig. 5.

Scenario 5 Client C

Server

Secure Keys Storage

S

SKS

{IDC , Q} REQ(KQ ) {KQ }KS,SKS {RES, {H(RES)}SKS }

Fig. 5: Protocol in Scenario 5.

In the first step the client sends his/her identifier and search query to the server. The server, in the second step, sends the request for the database key with obtained query to the Secure Keys Storage Server. Secure Keys Storage Server selects the part of the database according to the subset of query containing the information about indexing. In the third step Server sends back the key, encrypted with the shared key KS,SKS , required for decrypting the appropriate part of the database. The server decrypts the selected database part and executes the database query using the remaining part of the search query. Afterwards,

the server calculates the hash of results and signs it with his/her private key. The selected rows and signed hash are sent back to the client in the fourth step. In Table 1 a summary of security properties ensured by scenarios is presented. Table 1: Security properties ensured by analysed scenarios. Scenario Database Encryption Authentication Integrity 1 2 AES-128-CBC 3 AES-256-CBC 4 RSA-2048 SHA-1 5 AES-256-CBC RSA-2048 SHA-1

3.2

Stage 1 - Model Creation Stage

This stage is divided into 4 phases: functions definition (phase 1), equations definition (phase 2), channels definition (phase 3) and protocol flow definition (phase 4). Below we are defining this structure for analysing the case study in this paper. Phase 1 - Functions definition In order to model the presented scenarios we define the functions which refer to the cryptographic operations required in the protocol. These functions are presented below. In the round bracket the description of these functions is presented. functions { fun nonce() (create nonce); fun fun fun fun fun fun fun fun fun fun fun fun fun fun

s_enc(data, key) (symmetric encryption of data with key); s_dec(data, key) (symmetric decryption of data with key); sign(data, s_key) (sign data with secret key s_key); a_enc(data, p_key) (asymmetric encryption of data with public key p_key); a_dec(data, s_key) (asymmetric decryption of data with secret key s_key); pkey(skey) (get public key for secret key skey); skey() (generate secret key); hash(data) (calculate hash of data); id_c() (generate identification of Client); query() (generate search query); database() (create non-encrypted database); key_request() (create key request); get_db_key(key) (retrieve key for database); select_rows(database, query) (get rows from database selected by query);

}

Phase 2 - Equations definition After defining the functions one can describe the relations between them. equations { eq s_dec(s_enc(data, key), key) = data; eq a_dec(a_enc(data, pkey(skey)), skey) = data; eq get_db_key(key) = key; }

The first equation says that the symmetric decryption of symmetrically encrypted data with the same key returns the encrypted data. The second equation is similar to the first one, but it concerns the asymmetric encryption and decryption. The difference is in the key. Data must be encrypted with the public key corresponding to its secret key. The third equation says that the function get db key returns its parameter. This function was used to show that there is a process of obtaining the key that may have influence on the system (ie. different mechanisms of retrieving and storing keys may cause differences in performance or quality of protection). Phase 3 - Channels definition In the presented example we define four channels with unlimited buffer on each channel. channels { channel ch1,ch2,ch3,ch4 (*); }

Phase 4 - Protocol Flow definition The last and the most important operation during the modelling process is abstracting the protocol flow. In the presented example we are analysing five scenarios of the above presented architecture. The protocol flow is defined by hosts. In our case study we have three hosts: Client, Server and Secure Keys Storage, all containing one process. Below we will present the QoP-ML model of the analysed case study. R = key_request(); out (ch3: R); in (ch4: E_TMP_DB_KEY); TMP_DB_KEY = s_dec( E_TMP_DB_KEY, K_S_SKS)[ AES,256,CBC,32B,1];

hosts { host Client(rr)(ch1, ch2) { #ID_C = id_c(); #QUERY = query(); } process Client1(ch1, ch2) { M1 = (ID_C, QUERY); out(ch1: M1); in(ch2: M2); } }

subprocess decrypt_aes_128_sim_100() { DB_PLAINTEXT = s_dec(DB, TMP_DB_KEY)[AES,128,CBC ,300MB,100]; }

host Server(rr)(ch1, ch2, ch3, ch4) { #DB_KEY = nonce(); #DB = s_enc(database(), DB_KEY); #SK_S = skey(); #K_S_SKS = nonce(); process Server1(ch1, ch2, ch3, ch4) { while(true) { in(ch1: M1);

subprocess decrypt_aes_256_sim_100() { DB_PLAINTEXT = s_dec(DB, TMP_DB_KEY)[AES,256,CBC ,300MB,100]; } subprocess get_db() { DB_PLAINTEXT = s_dec(DB, DB_KEY); }

QUERY = M1[1]; subprocess select_rows_100() { subprocess get_db_key(ch3, ch4) {

ROWS = select_rows( DB_PLAINTEXT, QUERY) [100];

} } host SecureKeysStorage(rr)(ch3, ch4) { #DB_KEY = nonce(); #K_S_SKS = nonce();

} subprocess get_rows() { M2 = ROWS; }

process Store1(ch3, ch4) {

subprocess get_rows_with_hash_and_signature_100 () { H = hash(ROWS)[SHA1,1MB,100]; SGN = sign(H, SK_S)[20B,RSA ,2048,100]; M2 = (ROWS,SGN); }

while (true) { in (ch3: Request); KEY = s_enc(get_db_key(DB_KEY), K_S_SKS)[AES,256,CBC,32B ,1]; out(ch4: KEY); } } }

out(ch2: M2);

}

}

3.3

Stage 2 - Security metrics definition

In the analysed case study we need security metrics for the following cryptographic operations: symmetric decryption of database (AES-128-CBC, AES-256CBC), symmetric encryption and decryption of symmetric key (AES-256-CBC), hash function (SHA-1) and signing (RSA-2048). We also need metrics for executing the SELECT query on the database. The metrics are obtained by running listed operations on the same device for which the analysis will be performed. All metrics (except symmetric encryption and decryption of key) are calculated for the database of the size approx. 300MB and the results size approximately 1MB. We calculated the metrics for 100 simultaneous number of clients. We conducted 10 tests and average is presented in Table 2. Each value represents the time (in ms) that operation takes to finish for one client.

Table 2: Times of operations used in protocol (per one client). Security operation Execution time [ms] Decryption AES-128-CBC (300MB) 12132.50 Decryption AES-256-CBC (300MB) 12239.87 Encryption AES-256-CBC (32B) 8.54 Decryption AES-256-CBC (32B) 8.30 RSA2048 Signature 0.28 SHA-1 Hash 0.18 SQL Query 2235.59

The security metrics are defined for each device that is analysed. We have defined metrics for the device which we call Server and all hosts will use these metrics. They are divided into conf and data structures. The first one contains the list of device hardware and software that is important for QoP evaluation.

We have used a computer with twelve Intel Core i7 processors, Debian 7 as operating system and openssl 1.0.1c library for cryptographic operations. 3.4

Stage 3 - Scenarios definition

In the third stage we define scenarios which will be analysed. In our case study we have defined five scenarios which were described in the previous section. In this section the QoP-ML construction for this stage is presented. Due to page limit we present definition only of the scenario 5, the definition of the rest scenarios can be found on [28]. versions { version scenario_5 { set host Server(Server); set host SecureKeysStorage(Server); run host SecureKeysStorage(*) { run Store1(*) } run host Server(*) { run Server1(get_db_key,decrypt_aes_256_sim_100,select_rows_100, get_rows_with_hash_and_signature_100) } run host Client(*){100}[ch1, ch2] { run Client1(*) } } }

3.5

Stage 4 - Evaluation

The last step in the QoP-ML modelling and AQoPA analysis process is evaluation. It depends on the analysis modules which were enabled during the Scenarios Definition stage. In the article which introduces QoP-ML [9] one module was described and is called Time Analysis Module. This module is implemented in the AQoPA and can be used for the analysis of availability security service. By means of the Time Analysis Module one can calculate the total execution time of the selected host (TT otal ). In the presented paper the time analysis was performed for five previously described scenarios. After the AQoPA estimation the runtime of an actual implementation was conducted. We have created scripts for clients and a server that execute the selected scenario. We have used a computer with twelve Intel Core i7 processors, Debian 7 as operating system and openssl 1.0.1c library for cryptographic operations (the same as for the security metrics generation). Afterwards, each scenario was conducted for 100 simultaneous clients. The results of analysis are presented in Table 3. In this table we present the estimated execution time of the scenarios which were modelled in the AQoPA and the runtime of an actual implementation (experiment results) of these scenarios. All the scenarios were executed 10 times and the average was calculated. Comparing the results of the protocol runtime estimated in the AQoPA to the runtime of an

actual implementation one can conclude that the protocol runtime estimated in the AQoPA is in the range specified by the standard deviation. These results confirm the correctness of the modelling based on the AQoPA approach. Table 3: Total times of executing of the scenarios Scenario Estimated time Runtime of an actual Standard in AQoPA [ms] implementation [ms] deviation [ms] 1 223559.03 230145.65 29390 2 1438493.29 1523261.45 104389 3 1449230.09 1527315. 33 76762 4 223605.39 238870.36 27846 5 1449276.45 1534928.44 107408

During the analysis, one can notice that the most time consuming scenario is the fifth one where the data is encrypted by AES-256-CBC and the hash is generated and digitally signed. One can notice that similar results give second and third scenarios. These scenarios differ from each other only by hash and its digital signature generation, therefore one can conclude that adding these security mechanisms is less computationally expensive. The least computationally expensive is scenario number one where the database is not encrypted. The similar results are obtained from the fourth scenario which adds only hash and digital signature compared to the first scenario. One can conclude that comparing the first and fourth scenarios, the hash and its digital signature do not increase the system load significantly. The significant difference can be found comparing the first and the third scenarios. When the database is not encrypted, the server will generate the response for 100 simultaneous clients in 223559.03 ms. In the third scenario, where the database is encrypted with AES-256-CBC, the response for the clients will be generated in 1449230.09 ms. The difference between these scenarios is significant and the usage of the third scenario should be adapted to the specific security and functional requirements. 3.6

Server load

We estimated the hourly server load of the storage center being proceeded by different scenarios. Utilizing results obtained by AQoPA along with those that have been estimated, we evaluated the number of clients (sessions) with different scenarios, the server is able to handle within an hour. Our assessment is quite straightforward: knowing that for the existing server, it takes 223.55 seconds to handle data in scenario 1, and using the simplest possible formula, (1 hour = 3600 seconds, so 3600s / 223.55s ≈ 16) one can say that within an hour server is able to deal with approximately 16 sessions (Figure 6). Analysing obtained results one can easily notice, that the storage server is able to handle data in scenario 1 and 4 faster than the same number of clients

CPU load 90% 350

Scenario 1, 4 Scenario 2, 3, 5

300

Number of connections

250

200

150

100

50

0 24

23

22

21

20

19

18

17

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

0

Time [hours]

Fig. 6: Server’s performance in our scenarios.

permitted to perform actions in scenarios 2, 3 and 5. Gathered results clearly indicate the relationship between the quality of protection of scenarios and consumption of server resources: the longer time the action needs to accomplish, the more server resources are going to be used. A server, which works longer, utilizes more resources, thereby consuming a greater amount of energy. 3.7

Scalability

The analysis allows us to create scenarios to cope with a situation that will require greater efficiency. Such events may include a sudden and significant increase in requests to the system or type of denial of service attack. In this case, the system may switch to the operation mode where the efficiency is greater than the security. The other solution to the need of high efficiency is scaling. However this can entail high costs while the idea of QoP is to extend the requirements list in SLA (Service-Level Agreement). To cost and quality of service (QoP) requirements one introduces the third which is the quality of protection. As the result, the trade-off between these three requirements is achieved by negotiations. On the other hand some security requirements may refer not only to the database but also to integrated systems (eg. authorization server). In such situation these systems can be the bottle-necks and the scaling of database would not solve the problem. Of course, the integrated systems could also be scaled (eg. by mirroring) but it would increase management complexity and even more the costs.

4

Conclusions

In the article we proposed the approach for balancing security against performance for IT systems. The proposed approach can automatically answer the question what is the influence of the ensured security properties on the overall system performance. Through this analysis you can make a trade off between the means of information protection and the required performance. Presenting high level of abstraction, having the possibility of maintaining processes and communication steps consistently, QoP-ML provides a flexible approach for modeling complex systems and performance of multilevel security analysis. The analysis from [29] showed the flexibility of the quality of protection modeling language and confirmed the fact that the multilevel analysis is crucial in modeling security systems. In the article the case study of the QoP-ML modelling and AQoPA analysis was presented. The analysis was performed for different versions of the cryptographic protocol which are searching and retrieving data from the database. We focus on one level of analysis which concerns the cryptographic functions related with the time analysis module. The evaluation was performed and the total protocols runtime was calculated. The protocols runtime estimated in the AQoPA was validated by the actual implementation of the protocols. This confirms the correctness of the modelling with QoP-ML and evaluating with AQoPA tool.

References 1. ISO: ”ISO/IEC 25010: Systems and Software EngineeringSystems and Software Quality Requirements and Evaluation (SQuaRE) – System and Software Quality Models”; 2011. 2. J¨ urjens J.: ”Secure System Development with UML”; Springer, 2007. 3. J¨ urjens J.: ”Tools for Secure Systems Development with UML”; International Journal on Software Tools for Technology Transfer, 9, 2007, 527-544. 4. J¨ urjens J.: ”Security and Compliance in Clouds”; IT-Compliance 2011, Berlin, 4th Pan-European Conference, 2011. 5. Ksiezopolski B., Kotulski Z.: ”On scalable security model for sensor networks protocols”; 22nd CIB-W78 Conference Information Technology in Construction, Dresden, 2005, p.463-469. 6. Ksiezopolski B., Kotulski Z.: ”Adaptable security mechanism for the dynamic environments”; Computers & Security 26, 2007, 246-255. 7. Ksiezopolski B., Kotulski Z., Szalachowski P.: ”Adaptive approach to network security”; Communications in Computer and Information Science, 39, 2009, 233-241. 8. Ksiezopolski B., Kotulski Z., Szalachowski P.: ”On QoP method for ensuring availability of the goal of cryptographic protocols in the real-time systems”; European Teletraffic Seminar, 2011, 195-202. 9. Ksiezopolski B.: ”QoP-ML: Quality of Protection modelling language for cryptographic protocols”; Computers & Security, 31(4), 2012, 569-596. 10. Ksiezopolski B., Rusinek D., Wierzbicki A.: ”On the modelling of Kerberos protocol in the Quality of Protection Modelling Language (QoP-ML)”; Annales UMCS Informatica AI XII, 4, 2012, 69-81.

11. Ksiezopolski B., Rusinek D., Wierzbicki A.: ”On the efficiency modelling of cryptographic protocols by means of the Quality of Protection Modelling Language (QoP-ML)”; Springer: Lecture Notes in Computer Science, 7804, 2013, 261-270. 12. Ksiezopolski B., Zurek T., Mokkas M.: ”Quality of Protection evaluation of security mechanisms”; The Scientific World Journal, Volume 2014 (2014), Article ID 725279, 18 pages 13. Khan J. I., Wierzbicki A.: ”Foundations of Peer-to-Peer Computing.” (2008). 14. Lambrinoudakis C., Gritzalis S., Dridi F., Pernul G.: ”Security requirements for e-government services: a methodological approach for developing a common PKIbased security policy”; Computers & Security, 2003, 26, 1873-1883. 15. LeMay E., Unkenholz W., Parks D.: ”Adversary-Driven State-Based System Security Evaluation”; In Workshop on Security Metrics, MetriSec 2010. 16. Luo A., Lin Ch., Wang K., Lei L., Liu Ch.: ”Quality of protection analysis and performance modelling in IP multimedia subsystem”; Computers Communications, 2009, 32, 1336-1345. 17. Lindskog S.: ”Modeling and Tuning Security from a Quality of Service Perspective”; PhD dissertation, Department of Computer Science and Engineering, Chalmers University of Technology, Goteborg, Sweden 2005. 18. Mazur K., Ksiezopolski B., Kotulski Z.: ”The Robust Measurement Method for Security Metrics Generation”; The Computer Journal, 2014 (in press). 19. Ong C.S., Nahrstedt K., Yuan W.: ”Quality of protection for mobile applications”; In IEEE International Conference on Multimedia & Expo 2003, 137-140. 20. Petriu D. C., Woodside C. M., Petriu D. B., Xu J., Israr T., Georg G., France R., Bieman J. M., Houmb S. H., J¨ urjens J.: ”Performance Analysis of Security Aspects in UML Models”; In Sixth International Workshop on Software and Performance 2007, Buenos Aires, Argentina, ACM. 21. Schneck P., Schwan K.: ”Authenticast: An Adaptive Protocol for HighPerformance, Secure Network Applications”; Technical Report GIT-CC-97-22, 1997. 22. Stubblefield A., Rubin A.D., Wallach Dan. S.: ”Managing the Performance Impact of Web Security”; Electronic Commerce Research, 5, 2005, 99116. 23. Sklavos N., Kitsos P., Papadopoulos K., Koufopavlou, O.: ”Design, Architecture and Performance Evaluation of the Wireless Transport Layer Security”; The Journal of Supercomputing, 36, 1, 2006, 33-50. 24. P.Szalachowski, B.Ksiezopolski, Z.Kotulski: On authentication method impact upon data sampling delay in Wireless Sensor Networks, CCIS v.79 , Computer Networks 2010, pp.280-289 25. Wierzbicki A., Szczepaniak R., Buszka M.: ”Application layer multicast for efficient peer-to-peer applications.” Internet Applications. WIAPP 2003. Proceedings. The Third IEEE Workshop on. IEEE, 2003. 26. Wierzbicki A.: ”The case for fairness of trust management.” Electronic Notes in Theoretical Computer Science 197.2 (2008): 73-89. 27. Wierzbicki A., Zwierko A., Kotulski A.: ”Authentication with controlled anonymity in P2P systems.” Parallel and Distributed Computing, Applications and Technologies, 2005. PDCAT 2005. Sixth International Conference on. IEEE, 2005. 28. The web page of the QoP-ML project: http://www.qopml.org 29. Mazur K., Ksiezopolski B., : ”Comparison and Assessment of Security Modeling Approaches in Terms of the QoP-ML”, 3rd Conference on Cryptography and Security Systems, CCIS v.448, pp. 178-192, 2014.