Abstract — Cloud computing environment gives people to share resources, services and information. This environment is adopted by large number of organizations, so the rapid transition towards the cloud has fuelled concerns on security perspective. Encryption algorithms play main role in solving such kind of problems in the cloud computing environment. This paper proposes the structure for cloud security with efficient security in communication system and AES based file encryption system. This security architecture can be easily applied on PaaS, IaaS and SaaS and one time password provides extra security in the authenticating users. This paper presents the security of whole cloud computing environment.

Keywords — AES, SHA3,Blowfish, Cloud Security Architecture, Cloud computing.

I. INTRODUCTION

Cloud computing is having the capacity to dispose off the prerequisites for setting up high cost computing framework and promises to provide flexible architecture which is accessible from anywhere. The data in the cloud computing resides over an arrangement network resources which enables position of the requirements for setting up costly data centers framework and information to be acquired via virtual machines and these serves might be arranged in any part of the world. The cloud computing environment is adopted by large number of organizations so the rapid transition towards the clouds has fuelled concerns on security perspective. There are number of risks and challenges that have emerged due to use of cloud computing. Cloud computing is still an advancing innovation technology that exchanges current innovating technology and figuring thoughts into utility like arrangements. The relocation diminishes the cost and time of creation and offers better execution and unwavering quality [1].Cloud computing is a network access to the pool of resources well-defined which are convenient and well defined which require the minimum effort. [2]The advantages of distributed computing incorporate diminishing the equipment and support cost, accessibility around globe, adaptability and to a great degree mechanized process. It conveys unfathomable advantages to both Individuals and ventures by decreasing the requirement for client association by concealing specialized points of interest, for example updates, licenses and support

from its clients. Cloud can like wises provide improved safety over single server arrangements subsequently cloud totals resources and permits licensed security individual while as the typical organizations are restricted with system and network admin who won’t be well learned about cyber security issues .With rising concerns regarding the cloud computing and security of data the prominent security algorithms especially symmetric algorithms could be widely used in cloud application services which involve encryption techniques. Cryptography is used in hiding information from intruders and storing it confidentially so that only those users and are able to whom it is intended for and communication this information securely. The use security algorithms minimize security concerns with the help of cryptographic and authenticating techniques, cryptography is the process of crafting message securely altering the data to be sent with encrypting the plain text by taking user data and then executing the reverse process called as decryption which is returning back to original text. The cryptography can resolve the problems in cloud computing regarding network data and server security.

Encryption is the fundamental tool for protecting sensitive information. The goal of cryptography is keeping data secure from unauthorized users. With the swift development in science of encryption, an innovative area of cryptography can be classified as symmetric key cryptography.[3] Single key, one key also known as symmetric key cryptography uses the same key at both encryption and decryption process. Due to the use single key for encrypting the big quantity of data can be processed at a very fast speed. [4] .There is no defined process within the cloud service providers for safeguarding and securing data from threats and attacks. The target of the cyber attackers is end user data which is being secured by the cloud using encryption techniques which are intended to make it impossible for the attacker to decrypt the cipher text. The long length of the key makes harder to decrypt the classified text and makes them secure as compared to short keys.

Presently lot of security models in the cloud security has been deployed but they are unable to secure the cloud computing environment completely [5][6][7]. A high level security model

2017 6th International Conference on Reliability, Infocom Technologies and Optimization (ICRITO) (Trends and Future Directions), Sep. 20-22, 2017, AIIT, Amity University Uttar Pradesh, Noida, India

530

is needed in E-commerce and other different kind of online businesses. The present security models are not able to provide security to the whole cloud computing environment but some of the security models are able to secure communication channel but are not cost effective[8][9]. There are some proposed models which deal with hardware encryption system for securing communication system which is very hard to implement and is only helpful in database system and does not deal with other security issues [10].

This work deals with the new security structure for cloud computing security which uses high ranked symmetric key cryptographic algorithms for securing the communication process. The files are encrypted with symmetric key crypto system and the concept of distributive key is used to provide the maximum security [11][12]. This model helps in solving main security issue related to communication between user and server and Blowfish algorithm is being used for that purpose.

II. RELATED WORK

With rise in the attacks, emphasis is by the clouds service providers at the users end to make data secure. The inconsistency in the selection of encryption decryption algorithms there has been given the low priority to the cloud performance. Cloud performance and data security can be achieved by using the appropriate cryptographic algorithm at end user. For unintentional and accidental use of algorithms, it is important to do the algorithm analysis to check the competency of that particular algorithm that may result in degradation of performance in encryption or decryption process. For applications which use real time data , an algorithm which might take long time would prove a hindrance for such applications such algorithms end up consuming a lot of power for computing and storage to execute, thus making the algorithm unusable in that environment.

There has been a lot of research in the field of cloud security and numerous security architectures has already been proposed. One of the proposed systems proposed by researchers is identification based security model but it’s not sufficient to provide security to whole cloud computing environment [13]. Identifying the actual user is not sufficient to provide security in cloud computing. An identified based mechanism is used which is the part of Yao’s Garbled circuit. It is used in securing data in cloud computing but its unable to provide security to whole cloud environment.[14][15].

Different encryption techniques are being used to secure cloud computing, AES encryption technique is used in lot of cloud security architectures but these models does not use the concept of distributed severs which makes them less secure and prone to attacks and only one successful attack is able to get control of the whole system. Some of these models provide secure communication but are not able to upload information in an encrypted form.[16][17][18]. Recently some other models are being research but they fail to meet the issues related to cloud computing environment.

III. PROPOSED ARCHITECTURE

We will use following encryption techniques in our propose model. The algorithms were selected on the basis of their performances on various parameters like encryption time decryption time memory usage, flexibility, scalability security AES for Secured file encryption.

AES for file Encryption Blowfish algorithm for securing communication [19][20]. SHA3 hashing to secure tables [21][22] One time password for authentication

Presently cloud security has become one of the greatest challenges to researchers all over the world, we have taken these issues in concern and tried to provide solutions to these issues. The data storage model for security in cloud computing is shown in figure 1

Fig. 1. Security Model

The users have to use the secure channel to the main system whether the user is new or old and the server computer is connected to data storage system. The servers in cloud computing are not dedicated but can be scaled as necessary. The proposed architecture uses blowfish algorithm to secure communication. The user requests for a file it is being served in the encrypted manner, encrypted with three fish algorithm , same applies with the password which are being used for the logging in the system. The files are later being decrypted on the receiving end with the blowfish algorithm resulting in the secure communication between user and system.

Every time the user wants to login he will require a onetime password. One time password keeps the user account secure from unauthorized access. The one time password is done randomly because the user defined passwords can be easily compromised. The newly generated password automatically erases the older password from the system and one password is for one time use only. The password is automatically sent to the registered mail account or the mobile number which will be verified for the authorized user. The generated password will be covered by the SHA 3 hashing to secure the tables. The

2017 6th International Conference on Reliability, Infocom Technologies and Optimization (ICRITO) (Trends and Future Directions), Sep. 20-22, 2017, AIIT, Amity University Uttar Pradesh, Noida, India

531

main purpose of this technique is to make system more secure and not to provide any loop holes for the unauthorized access.

Fig. 2. Security Model Archictecture

The user can first time only upload the file after connecting to the system but afterwards it can both upload and download the file. The uploaded file is being encrypted by AES encryption algorithm. The architecture uses 128 bit keys for encryption but we can also use 192 and 256 bits. The keys generated by the system are random and are used only once in the system. The encryption and decryption process is done by the same key. The SHA3 hashing technique is used to secure the user accounts which makes sure that the unauthorized user doesn’t gain access by checking the database table.

The login process makes sure whether the user is authentic or not. When user want to retrieve a file from the system, the main server serves the key which then matches the user account which is already being saved in the database secured with SHA3 hashing. The location of the encrypted file is only know to the main server. Figure 2 represents the proposed security architecture.

AES

AES symmetric block cipher feistel structure that means it uses same key for both encryption and decryption AES algorithm can only accept a block size of 128 bits and a choice of three a128, 192, 256 key length permuted with variable 10, 12 and 14 rounds.

The variable nature of Rijndeal provide it with a great security and the key size up to 256 gives it a resistance to the future attacks [23].

Blowfish

Blowfish is a feistel structure symmetric key algorithm. It has a 64 bit block size and the key varies from 32 to 448 bits it uses 16 rounds and has large key dependent s box. There are 4 S boxes in blowfish algorithm and same algorithm is used in inverse for decryption [24][25][26].

Blowfish security lies in the key size providing high level of security. It is invincible against different key attacks because of many round which are being used by master key making such attacks infeasible.

SHA3

Secure Hash Algorithm is the cryptographic algorithm producing hash values of 224, 256,348,512 bits by using internal 1600 bits.SHA3 can vary according to the earlier two versions requirement and length of the message is of infinite length which makes it powerful from the earlier two versions.

The sponge function used by SHA3 makes it more secure than SHA2 and SHA1 and it minimizes the chance of collision using large number of bits

IV. PERFORMANCE EVALUATION MATRIX

The experimental design was performed on laptop with core i7 processor on windows 10 environment with the input files ranging from 83.3 Kb to 1.54 Mb. The language used to check the space and complexity was java. Time and space complexity depends on lots of things like hardware, operating system, processors, etc. but we have only taken execution time into consideration. The objective we tried to achieve in terms of memory occupied by an algorithm during the course of execution was obtained by the methods like

getruntime().freememory() getruntime().totalmemory()

with the run time memory management options compiling heap memory, stack memory etc. The other objective was how much time an algorithm takes right from the input of a file to the desired output.

The evaluation parameters are Encryption time Decryption time Memory usage Flexibility Scalability Security

TABLE 1: ENCRYPTION TIME (MILLISECONDS)

KB AES DES 3DES BLOW FISH

RC4 IDE A

TEA

83.3 625 41 43 8 15 16 54 108 31 47 47 16 16 125 15 249 468 47 47 47 15 32 16 333 32 47 64 281 15 63 10 416 46 48 94 343 31 127 16 1370 141 110 243 78 47 78 41 2740 62 172 361 93 62 205 97 5480 78 296 749 156 63 325 170 10003 723 484 749 531 141 397 357 15483 798 690 1401 601 198 758 475 Average 300.

4 198. 2

397. 8

215. 4

60, 3

212. 6

125. 1

2017 6th International Conference on Reliability, Infocom Technologies and Optimization (ICRITO) (Trends and Future Directions), Sep. 20-22, 2017, AIIT, Amity University Uttar Pradesh, Noida, India

532

TABLE II: DECRYPTION TIME (MILLISECONDS)

KB AES DES 3DES BLOW FISH

RC4 IDEA TEA

83.3 24 10 25 17 5 16 15 108 15 16 31 10 6 943 16 249 16 32 31 15 4 31 10 333 16 46 17 16 7 31 12 416 10 47 125 17 10 47 16 1370 31 78 187 62 12 45 40 2740 47 141 359 78 17 129 96 5480 31 225 678 156 48 218 158 10003 62 484 1346 234 55 351 304 15483 88 680 1988 305 89 597 545 Average 34.4 178.6 497.6 91 25.3 155.9 121.2

TABLE III: MEMORY USAGE (KB)

Fig. 3. Encryption time in milliseconds

Fig. 4. Decryption Time milliseconds

Fig. 5. Memory Usage in kilobytes

Experimental results of encryption algorithms are shown which shows all algorithms use same text files for ten experiments. By analysing the table RC4 is taking less encryption time while as the 3DES is taking maximum encryption time. In the second table RC4 and AES are having very less decryption time while 3DES is having maximum of all the algorithms. (Table 3) depicts the memory usage of all the algorithms in which IDEA and TEA are having very less memory usage while as RC4 is taking the maximum memory of all the algorithms. During the analysis it was found that AES will be best among all the algorithms in terms of flexibility, security, memory performance and usage. Blowfish is the second best parameters such as security, flexibility, encryption decryption time, scalability and memory usage, so we have used AES and blowfish in our proposed architecture

V. LEVEL OF SECURITY

Level of security of a particular algorithm depends on key size, the greater the key size stronger the algorithm and encryption.

TALBE IV: LEVEL OF SECURITY

Encryption Algorithms

Plain Text/Cipher

Text)

Length Key Length (bits

No Rounds (bits)

DES 64 bit 56 16 3DES 64 bit 168 48 AES 128 bit 128,192,256 10,12, 14 BLOWFISH 64 bit 32-448 16 RC4 40 -2048 bits variable 256 IDEA 64bits 128 8.5 TEA 64bits 128 32 cycles

2017 6th International Conference on Reliability, Infocom Technologies and Optimization (ICRITO) (Trends and Future Directions), Sep. 20-22, 2017, AIIT, Amity University Uttar Pradesh, Noida, India

533

TABLE V: flexibility and scalability

Algorithm Flexibility Modification Comments DES No None No modifications are

supported by DES 3DES Yes 168 The DES key is

extended to 168 bits. AES Yes 128,192,256 The AES is

expandable and support modifications.

BLOWFISH Yes 32-448 The structure of BLOWFISH is extendable to 448 bits

RC4 Yes variable Modifications supported

IDEA No 128 No modifications supported.

TEA No 128 No modifications supported.

TABLE VI: ADVANTAGES OF PRAPOSED ARCITECTURE

Discussion points

Ways of ensuring security

Information leakage

probability

Complexi ty

Identification Based Model

Only identify the authorized person, so hacker can get access on database

Medium

Low

File encryption based Model

Key and file both remains in one server. So, getting access on one server helps to get all information

Medium

TABLE VII: ADVANTAGES OF PRAPOSED ARCITECTURE

Discussion points

Cost of establishing

and maintaining

Ensuring User Authentication

Security Breaking

probability

File encryption based Model

Medium

If key is chosen by user, then slightly authenticate users

Medium

Secured channel using model

High

Probably not maintained

Medium

Proposed Architecture

Medium

One time password system is used for user authentication

Lower than others

VI. CONCLUSION

This paper proposes a new security architecture for cloud security which uses symmetric cryptographic algorithms for encryption purposes. This architecture uses AES, Blowfish and SHA3 and one time password to secure the whole system. The proposed system is very secure which makes it difficult for intruders to get into the system because the intruders need to get control over all the servers. The execution time can be low because of the implementation of algorithms on different servers. In our future work we would like to find out the execution results which would help our proposed architecture to demonstrate with better results. We will work on different users and conditions to prove the efficiency of this architecture. We would also work on the lighter encryption techniques which will reduce the execution time of the proposed architecture.

REFERENCES

[1] Munir, Kashif, and Sellapan Palaniappan. "Framework for secure cloud computing." Advanced International Journal on Cloud Computing: Services and Architecture (IJCCSA) 3.2 (2013).

[2] Mell, Peter, and Timothy Grance. "The NIST Definition of Cloud Computing, Jan, 2011."

[3] Meyer, Carl H. "Cryptography-A state of the art review." CompEuro'89., 'VLSI and Computer Peripherals. VLSI and Microelectronic Applications in Intelligent Peripherals and their Interconnection Networks', Proceedings. IEEE, 1989.

[4] Krutz, Ronald L, and Russell Dean Vines. Cloud security: A comprehensive guide to secure cloud computing. Wiley Publishing, 2010..

[5] Bhadauria, Rohit, et al. "A survey on security issues in cloud computing." IEEE Communications Surveys and Tutorials (2011): 1-15.

[6] A Vouk, Mladen. "Cloud computing–issues, research and implementations." CIT. Journal of Computing and Information Technology 16.4 (2008): 235-246.

[7] Hu, Ye, et al. "Resource provisioning for cloud computing." Proceedings of the 2009 Conference of the Center for Advanced Studies on Collaborative Research. IBM Corp., 2009.

[8] Catteddu, Daniele. "Cloud Computing: benefits, risks and recommendations for information security." Web application security. Springer, Berlin, Heidelberg, 2010. 17-17.

[9] Chigozirim, Ajaegbu. "Towards building a secure cloud computing environment." International Journal of Advanced Research in Computer Science 3.4 (2012).

[10] Ngongang, Guy. "Cloud Computing Security." (2011). [11] Kanmani, P., and S. Anusha. "A novel integrity scheme for

secure cloud storage." Intelligent Systems and Control (ISCO), 2015 IEEE 9th International Conference on. IEEE, 2015..

[12] Kumar, Gunasekar, and Anirudh Chelikani. "Analysis of security issues in cloud based e-learning." (2011).

[13] Wu, Jiyi, et al. "Recent Advances in Cloud Security." JCP 6.10 (2011): 2156-2163.

[14] Shimbre, Nivedita, and Priya Deshpande. "Enhancing Distributed Data Storage Security for Cloud Computing Using TPA and AES Algorithm." Computing Communication Control and Automation (ICCUBEA), 2015 International Conference on. IEEE, 2015..

2017 6th International Conference on Reliability, Infocom Technologies and Optimization (ICRITO) (Trends and Future Directions), Sep. 20-22, 2017, AIIT, Amity University Uttar Pradesh, Noida, India

534

[15] Sadeghi, Ahmad-Reza, Thomas Schneider, and Marcel Winandy. "Token-based cloud computing." International Conference on Trust and Trustworthy Computing. Springer, Berlin, Heidelberg, 2010.

[16] A. Pandey, S. Som (2016), “Applications and Usage of Visual Cryptography: A Review” International Conference on “Reliability, Infocom Technologies and Optimizations (Trends and Future Directions) ICRITO 2016, 7-9 September 2016, IEEE Conference, indexed with SCOPUS, Amity University Uttar Pradesh, India, p.p. 375-381.

[17] Lenka, Sudhansu Ranjan, and Biswaranjan Nayak. "Enhancing Data Security in Cloud Computing Using RSA Encryption and MD5 Algorithm." International Journal of Computer Science Trends and Technology (IJCST)–Volume 2 (2014).

[18] Li, Hongwei, et al. "Identity-based authentication for cloud computing." Cloud computing (2009): 157-166.

[19] S. Som, S. Sinha, R. Kataria (2016) “Study On SQL Injection Attacks: Mode, Detection And Prevention”, International Journal of Engineering Applied Sciences and Technology, Indexed in Google Scholar, ICI etc., Impact Factor: 1.494, Vol. 1, Issue 8, ISSN No. 2455-2143, Pages 23-29, June - July 2016.

[20] Kaur, Manmeet, et al. "Comparison of TACIT Encryption Algorithm with Various Encryption Algorithms." International Journal of Electronics and Computer Science Engineering, page (1-10) (2012). (2006).

[21] Cheong, Hon-Sang, and Wai-Kong Lee. "Fast Implementation of Block Ciphers and PRNGs for Kepler GPU Architecture." IT Convergence and Security (ICITCS), 2015 5th International Conference on. IEEE, 2015.2015.

[22] Arshad, Alia, and Arshad Aziz. "Compact implementation of SHA3-512 on FPGA." Information Assurance and Cyber Security (CIACS), 2014 Conference on. IEEE, 2014.

[23] Meera, K., P. Krishna Sankar, and K. Sriram Kumar. "Redundant file finder, remover in mobile environment through SHA-3 algorithm." Electronics and Communication Systems (ICECS), 2015 2nd International Conference on. IEEE, 2015.

[24] Kumar, Ashish, and Vishal Arora. "Analyzing the performance and security by using SHA3 in WEP." Engineering and Technology (ICETECH), 2015 IEEE International Conference on. IEEE, 2015.

[25] Phul S., Som S., (2016) “Symmetric Cryptography using Multiple Access Circular Queues (MACQ)”, 2nd International Conference on Information and Communication Technology for Competitive Strategies (ICTCS-2016), Conference Proceedings by ACM – ICPS Proceedings Volume ISBN No 978-1-4503- 3962-9, 4 – 5 March, 2016.

[26] Schneier, B. "Blowfish: One Year Later." Dr. Dobbs Journal (1995).

[27] Singh, Simar Preet, and Raman Maini. "Comparison of data encryption algorithms." International Journal of Computer Science and Communication2.1 (2011): 125-127.

[28] Ajay Vikram Singh, Moushumi Chattopadhyaya, “Mitigation of DoS Attacks by Using Multiple Encryptions in MANET”, 2015 4th IEEE International Conference on Reliability, Infocom Technologies and Optimization (ICRITO) (Trends and Future Directions), 2015 at AUUP, NOIDA, India, September 02-04, 2015.

[29] Ajay Vikram Singh, Bani Singh, M. Afshar Alam, “Issues and Challenges associated with Secure QoS aware Routing in MANETs” , International Journal of Research and Reviews in Ad Hoc Networks (IJRRAN), Vol. 1, No. 3, pp. 73-76,ISSN:

2046-5106, Science Academy Publisher, United Kingdom, September 2011.

[30] Seema Nath, Subhranil Som (2017), “Security and Privacy Challenges: Internet of Things”, Indian Journal of Science and Technology, Scopus Indexed, included in 'Web of Science' and included in the list of journal recommended by UGC, Vol 10(3), DOI: 10.17485/ijst/2017/v10i3/110642, ISSN (Print) : 0974- 6846 ISSN (Online) : 0974-5645, January 2017.

View publication statsView publication stats

https://www.researchgate.net/publication/324928223

<< /ASCII85EncodePages false /AllowTransparency false /AutoPositionEPSFiles false /AutoRotatePages /None /Binding /Left /CalGrayProfile (Gray Gamma 2.2) /CalRGBProfile (sRGB IEC61966-2.1) /CalCMYKProfile (U.S. Web Coated \050SWOP\051 v2) /sRGBProfile (sRGB IEC61966-2.1) /CannotEmbedFontPolicy /Warning /CompatibilityLevel 1.4 /CompressObjects /Off /CompressPages true /ConvertImagesToIndexed true /PassThroughJPEGImages true /CreateJobTicket false /DefaultRenderingIntent /Default /DetectBlends true /DetectCurves 0.0000 /ColorConversionStrategy /LeaveColorUnchanged /DoThumbnails false /EmbedAllFonts true /EmbedOpenType false /ParseICCProfilesInComments true /EmbedJobOptions true /DSCReportingLevel 0 /EmitDSCWarnings false /EndPage -1 /ImageMemory 1048576 /LockDistillerParams true /MaxSubsetPct 100 /Optimize false /OPM 0 /ParseDSCComments false /ParseDSCCommentsForDocInfo false /PreserveCopyPage true /PreserveDICMYKValues true /PreserveEPSInfo false /PreserveFlatness true /PreserveHalftoneInfo true /PreserveOPIComments false /PreserveOverprintSettings true /StartPage 1 /SubsetFonts false /TransferFunctionInfo /Remove /UCRandBGInfo /Preserve /UsePrologue false /ColorSettingsFile () /AlwaysEmbed [ true /Arial-Black /Arial-BoldItalicMT /Arial-BoldMT /Arial-ItalicMT /ArialMT /ArialNarrow /ArialNarrow-Bold /ArialNarrow-BoldItalic /ArialNarrow-Italic /ArialUnicodeMS /BookAntiqua /BookAntiqua-Bold /BookAntiqua-BoldItalic /BookAntiqua-Italic /BookmanOldStyle /BookmanOldStyle-Bold /BookmanOldStyle-BoldItalic /BookmanOldStyle-Italic /BookshelfSymbolSeven /Century /CenturyGothic /CenturyGothic-Bold /CenturyGothic-BoldItalic /CenturyGothic-Italic /CenturySchoolbook /CenturySchoolbook-Bold /CenturySchoolbook-BoldItalic /CenturySchoolbook-Italic /ComicSansMS /ComicSansMS-Bold /CourierNewPS-BoldItalicMT /CourierNewPS-BoldMT /CourierNewPS-ItalicMT /CourierNewPSMT /EstrangeloEdessa /FranklinGothic-Medium /FranklinGothic-MediumItalic /Garamond /Garamond-Bold /Garamond-Italic /Gautami /Georgia /Georgia-Bold /Georgia-BoldItalic /Georgia-Italic /Haettenschweiler /Impact /Kartika /Latha /LetterGothicMT /LetterGothicMT-Bold /LetterGothicMT-BoldOblique /LetterGothicMT-Oblique /LucidaConsole /LucidaSans /LucidaSans-Demi /LucidaSans-DemiItalic /LucidaSans-Italic /LucidaSansUnicode /Mangal-Regular /MicrosoftSansSerif /MonotypeCorsiva /MSReferenceSansSerif /MSReferenceSpecialty /MVBoli /PalatinoLinotype-Bold /PalatinoLinotype-BoldItalic /PalatinoLinotype-Italic /PalatinoLinotype-Roman /Raavi /Shruti /Sylfaen /SymbolMT /Tahoma /Tahoma-Bold /TimesNewRomanMT-ExtraBold /TimesNewRomanPS-BoldItalicMT /TimesNewRomanPS-BoldMT /TimesNewRomanPS-ItalicMT /TimesNewRomanPSMT /Trebuchet-BoldItalic /TrebuchetMS /TrebuchetMS-Bold /TrebuchetMS-Italic /Tunga-Regular /Verdana /Verdana-Bold /Verdana-BoldItalic /Verdana-Italic /Vrinda /Webdings /Wingdings2 /Wingdings3 /Wingdings-Regular /ZWAdobeF ] /NeverEmbed [ true ] /AntiAliasColorImages false /CropColorImages true /ColorImageMinResolution 200 /ColorImageMinResolutionPolicy /OK /DownsampleColorImages true /ColorImageDownsampleType /Bicubic /ColorImageResolution 300 /ColorImageDepth -1 /ColorImageMinDownsampleDepth 1 /ColorImageDownsampleThreshold 1.50000 /EncodeColorImages true /ColorImageFilter /DCTEncode /AutoFilterColorImages false /ColorImageAutoFilterStrategy /JPEG /ColorACSImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /ColorImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /JPEG2000ColorACSImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >> /JPEG2000ColorImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >> /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 200 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages false /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /GrayImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /JPEG2000GrayACSImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >> /JPEG2000GrayImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >> /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 400 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 600 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict << /K -1 >> /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False /CreateJDFFile false /Description << /CHS <FEFF4f7f75288fd94e9b8bbe5b9a521b5efa7684002000410064006f006200650020005000440046002065876863900275284e8e55464e1a65876863768467e5770b548c62535370300260a853ef4ee54f7f75280020004100630072006f0062006100740020548c002000410064006f00620065002000520065006100640065007200200035002e003000204ee553ca66f49ad87248672c676562535f00521b5efa768400200050004400460020658768633002> /CHT <FEFF4f7f752890194e9b8a2d7f6e5efa7acb7684002000410064006f006200650020005000440046002065874ef69069752865bc666e901a554652d965874ef6768467e5770b548c52175370300260a853ef4ee54f7f75280020004100630072006f0062006100740020548c002000410064006f00620065002000520065006100640065007200200035002e003000204ee553ca66f49ad87248672c4f86958b555f5df25efa7acb76840020005000440046002065874ef63002> /DAN <FEFF004200720075006700200069006e0064007300740069006c006c0069006e006700650072006e0065002000740069006c0020006100740020006f007000720065007400740065002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e007400650072002c0020006400650072002000650067006e006500720020007300690067002000740069006c00200064006500740061006c006a006500720065007400200073006b00e60072006d007600690073006e0069006e00670020006f00670020007500640073006b007200690076006e0069006e006700200061006600200066006f0072007200650074006e0069006e006700730064006f006b0075006d0065006e007400650072002e0020004400650020006f007000720065007400740065006400650020005000440046002d0064006f006b0075006d0065006e0074006500720020006b0061006e002000e50062006e00650073002000690020004100630072006f00620061007400200065006c006c006500720020004100630072006f006200610074002000520065006100640065007200200035002e00300020006f00670020006e0079006500720065002e> /DEU <FEFF00560065007200770065006e00640065006e0020005300690065002000640069006500730065002000450069006e007300740065006c006c0075006e00670065006e0020007a0075006d002000450072007300740065006c006c0065006e00200076006f006e002000410064006f006200650020005000440046002d0044006f006b0075006d0065006e00740065006e002c00200075006d002000650069006e00650020007a0075007600650072006c00e40073007300690067006500200041006e007a006500690067006500200075006e00640020004100750073006700610062006500200076006f006e00200047006500730063006800e40066007400730064006f006b0075006d0065006e00740065006e0020007a0075002000650072007a00690065006c0065006e002e00200044006900650020005000440046002d0044006f006b0075006d0065006e007400650020006b00f6006e006e0065006e0020006d006900740020004100630072006f00620061007400200075006e0064002000520065006100640065007200200035002e003000200075006e00640020006800f600680065007200200067006500f600660066006e00650074002000770065007200640065006e002e> /ESP <FEFF005500740069006c0069006300650020006500730074006100200063006f006e0066006900670075007200610063006900f3006e0020007000610072006100200063007200650061007200200064006f00630075006d0065006e0074006f0073002000640065002000410064006f00620065002000500044004600200061006400650063007500610064006f007300200070006100720061002000760069007300750061006c0069007a00610063006900f3006e0020006500200069006d0070007200650073006900f3006e00200064006500200063006f006e006600690061006e007a006100200064006500200064006f00630075006d0065006e0074006f007300200063006f006d00650072006300690061006c00650073002e002000530065002000700075006500640065006e00200061006200720069007200200064006f00630075006d0065006e0074006f00730020005000440046002000630072006500610064006f007300200063006f006e0020004100630072006f006200610074002c002000410064006f00620065002000520065006100640065007200200035002e003000200079002000760065007200730069006f006e0065007300200070006f00730074006500720069006f007200650073002e> /FRA <FEFF005500740069006c006900730065007a00200063006500730020006f007000740069006f006e00730020006100660069006e00200064006500200063007200e900650072002000640065007300200064006f00630075006d0065006e00740073002000410064006f006200650020005000440046002000700072006f00660065007300730069006f006e006e0065006c007300200066006900610062006c0065007300200070006f007500720020006c0061002000760069007300750061006c00690073006100740069006f006e0020006500740020006c00270069006d007000720065007300730069006f006e002e0020004c0065007300200064006f00630075006d0065006e00740073002000500044004600200063007200e900e90073002000700065007500760065006e0074002000ea0074007200650020006f007500760065007200740073002000640061006e00730020004100630072006f006200610074002c002000610069006e00730069002000710075002700410064006f00620065002000520065006100640065007200200035002e0030002000650074002000760065007200730069006f006e007300200075006c007400e90072006900650075007200650073002e> /ITA (Utilizzare queste impostazioni per creare documenti Adobe PDF adatti per visualizzare e stampare documenti aziendali in modo affidabile. I documenti PDF creati possono essere aperti con Acrobat e Adobe Reader 5.0 e versioni successive.) /JPN <FEFF30d330b830cd30b9658766f8306e8868793a304a3088307353705237306b90693057305f002000410064006f0062006500200050004400460020658766f8306e4f5c6210306b4f7f75283057307e305930023053306e8a2d5b9a30674f5c62103055308c305f0020005000440046002030d530a130a430eb306f3001004100630072006f0062006100740020304a30883073002000410064006f00620065002000520065006100640065007200200035002e003000204ee5964d3067958b304f30533068304c3067304d307e305930023053306e8a2d5b9a3067306f30d530a930f330c8306e57cb30818fbc307f3092884c3044307e30593002> /KOR <FEFFc7740020c124c815c7440020c0acc6a9d558c5ec0020be44c988b2c8c2a40020bb38c11cb97c0020c548c815c801c73cb85c0020bcf4ace00020c778c1c4d558b2940020b3700020ac00c7a50020c801d569d55c002000410064006f0062006500200050004400460020bb38c11cb97c0020c791c131d569b2c8b2e4002e0020c774b807ac8c0020c791c131b41c00200050004400460020bb38c11cb2940020004100630072006f0062006100740020bc0f002000410064006f00620065002000520065006100640065007200200035002e00300020c774c0c1c5d0c11c0020c5f40020c2180020c788c2b5b2c8b2e4002e> /NLD (Gebruik deze instellingen om Adobe PDF-documenten te maken waarmee zakelijke documenten betrouwbaar kunnen worden weergegeven en afgedrukt. De gemaakte PDF-documenten kunnen worden geopend met Acrobat en Adobe Reader 5.0 en hoger.) /NOR <FEFF004200720075006b00200064006900730073006500200069006e006e007300740069006c006c0069006e00670065006e0065002000740069006c002000e50020006f0070007000720065007400740065002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e00740065007200200073006f006d002000650072002000650067006e0065007400200066006f00720020007000e5006c006900740065006c006900670020007600690073006e0069006e00670020006f00670020007500740073006b007200690066007400200061007600200066006f0072007200650074006e0069006e006700730064006f006b0075006d0065006e007400650072002e0020005000440046002d0064006f006b0075006d0065006e00740065006e00650020006b0061006e002000e50070006e00650073002000690020004100630072006f00620061007400200065006c006c00650072002000410064006f00620065002000520065006100640065007200200035002e003000200065006c006c00650072002e> /PTB <FEFF005500740069006c0069007a006500200065007300730061007300200063006f006e00660069006700750072006100e700f50065007300200064006500200066006f0072006d00610020006100200063007200690061007200200064006f00630075006d0065006e0074006f0073002000410064006f00620065002000500044004600200061006400650071007500610064006f00730020007000610072006100200061002000760069007300750061006c0069007a006100e700e3006f002000650020006100200069006d0070007200650073007300e3006f00200063006f006e0066006900e1007600650069007300200064006500200064006f00630075006d0065006e0074006f007300200063006f006d0065007200630069006100690073002e0020004f007300200064006f00630075006d0065006e0074006f00730020005000440046002000630072006900610064006f007300200070006f00640065006d0020007300650072002000610062006500720074006f007300200063006f006d0020006f0020004100630072006f006200610074002000650020006f002000410064006f00620065002000520065006100640065007200200035002e0030002000650020007600650072007300f50065007300200070006f00730074006500720069006f007200650073002e> /SUO <FEFF004b00e40079007400e40020006e00e40069007400e4002000610073006500740075006b007300690061002c0020006b0075006e0020006c0075006f0074002000410064006f0062006500200050004400460020002d0064006f006b0075006d0065006e007400740065006a0061002c0020006a006f0074006b006100200073006f0070006900760061007400200079007200690074007900730061007300690061006b00690072006a006f006a0065006e0020006c0075006f00740065007400740061007600610061006e0020006e00e400790074007400e4006d0069007300650065006e0020006a0061002000740075006c006f007300740061006d0069007300650065006e002e0020004c0075006f0064007500740020005000440046002d0064006f006b0075006d0065006e00740069007400200076006f0069006400610061006e0020006100760061007400610020004100630072006f0062006100740069006c006c00610020006a0061002000410064006f00620065002000520065006100640065007200200035002e0030003a006c006c00610020006a006100200075007500640065006d006d0069006c006c0061002e> /SVE <FEFF0041006e007600e4006e00640020006400650020006800e4007200200069006e0073007400e4006c006c006e0069006e006700610072006e00610020006f006d002000640075002000760069006c006c00200073006b006100700061002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e007400200073006f006d00200070006100730073006100720020006600f60072002000740069006c006c006600f60072006c00690074006c006900670020007600690073006e0069006e00670020006f006300680020007500740073006b007200690066007400650072002000610076002000610066006600e4007200730064006f006b0075006d0065006e0074002e002000200053006b006100700061006400650020005000440046002d0064006f006b0075006d0065006e00740020006b0061006e002000f600700070006e00610073002000690020004100630072006f0062006100740020006f00630068002000410064006f00620065002000520065006100640065007200200035002e00300020006f00630068002000730065006e006100720065002e> /ENU (Use these settings to create PDFs that match the "Required" settings for PDF Specification 4.01) >> >> setdistillerparams << /HWResolution [600 600] /PageSize [612.000 792.000] >> setpagedevice

New folder/Leveraging the Serverless Architecture for Securing Linux Containers.pdf

Leveraging the Serverless Architecture for Securing Linux Containers

Nilton Bila, Paolo Dettori, Ali Kanso, Yuji Watanabe*, Alaa Youssef IBM T.J. Watson Research Center

Yorktown Heights, NY, USA *IBM Research - Tokyo, IBM Japan Ltd.

{nilton, dettori, akanso, asyousse}@us.ibm.com, *[email protected]

Abstract— Linux containers present a lightweight solution to package applications into images and instantiate them in isolated environments. Such images may include vulnerabilities that can be exploited at runtime. A vulnerability scanning service can detect these vulnerabilities by periodically scanning the containers and their images for potential threats. When a threat is detected, an event may be generated to (1) quarantine or terminate the compromised container(s) and optionally (2) remedy the vulnerability by rebuilding a secure image. We believe that such event-driven process is a great fit to be implemented in a serverless architecture. In this paper we explore the design of an automated threat mitigation architecture based on OpenWhisk and Kubernetes.

Keywords—Linux containers, serverless architecture, Kubernetes, OpenWhisk, Docker, security analysis.

I. INTRODUCTION With the widespread adoption of cloud technologies,

workloads that were once served from on-premise servers, are now shifting to cloud-based execution environments [1]. Linux containers are accelerating this shift by presenting a compelling model for simplified packaging and deployment of applications. Linux containers sandbox applications using built-in kernel mechanisms called namespaces and cgroups. This allows for fast start-up times for containerized applications without penalizing the system performance by adding a virtualization layer. Unlike VMs, containers are instantiated based on lightweight images that include mainly the files and libraries constituting the containerized application [2]. While removing the virtual machine abstraction layer improves performance, it leaves the system more exposed to security threats due to sharing of a single operating system kernel among containers on the same host. As a result, container security is a major concern that has been the focus of recent studies [3, 4]. Containers can have built-in vulnerabilities based on their configuration (e.g. insecure remote shells enabled), or by including executable binaries with known security flaws. Such vulnerabilities can be discovered by vulnerability detection tools that scan container images at build time or images at rest in image registries. While DevOps best practices lean towards immutable containers, the reality is that many container owners apply updates to their running containers, which lead to the introduction of vulnerabilities, even when none were there initially. Moreover, databases of known vulnerabilities are updated periodically with new threat information, resulting in the need to monitor containers at runtime to identify and isolate newly discovered vulnerabilities.

Upon discovering vulnerable containers, state of the art vulnerability scanning tools notify devops professionals to take appropriate actions. This manual reaction may take a long time giving an ample opportunity for exploitation of the detected vulnerability. In large clusters, container clustering and management solutions like Kubernetes [6] and Docker Swarm [5] are used to manage the scheduling and life-cycle of containers. In fact, major cloud providers such as IBM, Microsoft, and Google offer users the ability to automatically deploy their own Kubernetes clusters on their clouds. However, existing container clustering solutions do not provide the mechanisms needed to deal with vulnerable containers. In this work, we seek to address this issue. We believe that users should have control over how security management is enforced on their containers without requiring additional, self-managed, infrastructure. We propose exposing a serveless archtiecture in the container cloud that allows the users to create their own security policies in a generic way. Those policies can be enforced by the serverless framework when a threat alert is triggered. This model alleviates the burden of implementing a security policy manager that would otherwise fall on the users. Another advantage of using the serverless archtiecture is that it maintains consistency by providing a centralized policy manager across multiple Kubernetes clusters. By maintaining the policies outside of the Kubernetes clusters, adding or removing clusters at runtime does not affect the existing user policies.

Our contributions for this work are as follows: first, we introduce API extensions to a Kubernetes based container runtime platform which enables quarantining of vulnerable containers and isolating them from the network while preserving their state for future forensics. Second, we introduce a lightweight policy manager based on a serverless framework, namely OpenWhisk [7], which enables DevOps and security professionals to rapidly develop ad hoc policies that enforce compliance and isolation of offending containers by reacting to events from a vulnerability detection engine and triggering actions that exercise the API extensions introduced above. And third, we extend a vulnerability scanning service to generate event feeds that trigger OpenWhisk policy execution. In this system, the serverless event listener, acting as a policy manager, links the event (vulnerability notice) generated by the vulnerability scanner to the action (quarantine or terminate) using a quickly rigged policy that can be easily modified or augmented to support new unforeseen security scenarios.

II. BACKGROUND Serverless architecture is a computing paradigm that

replaces always-on servers with ephmeral computing

environments that are created in response to events and removed after executing their tasks. Linux containers are a key enablers of this architecture due to their lighweight images, and fast startup times. Amazon AWS Lambda is well known example of a commercial implementation of the serverless architecture [8]. However Lambda is proprietary and platform specific. OpenWhisk on the other hand provides an open- source platform for implementing serverless services. In fact, OpenWhisk is an open source framework that implements a distributed, event-driven compute service. OpenWhisk runs application logic (actions) in response to events. Actions can be language specific functions or small custom binary code embedded in a Linux container. Application owners write stateless programs (called actions) and register these for invocation on specific event triggers. Event triggers are generated from feeds such as database writes or object store updates or through Web API invocations. Whenever an event is triggered, OpenWhisk instantly deploys and executes the appropriate actions. Each action runs in its own container, and once the action is completed the container is removed.

Kubernetes manages its containers 1 by using a master- worker architecture where a kubernetes agent runs on each cluster node (worker) and reports back to the kubernetes master. The master exposes a management API that can be leveraged by OpenWhisk to execute the remediation actions.

III. ARCHITECTURE Our goal is to introduce functionality to kubernetes that

enables the system to react to threats in an automated manner according to user-defined policies. OpenWhisk is a key enabler for this functionality since it allows the users to create their own policies in a generic way. In the context of securing a compromised container, the security enforcement service should support abrupt termination, graceful termination, or quarantining of containers. Graceful termination differs from the an abrupt one in that it preserves the container logs and the state of the container filesystem for future investigation after container termination. Quarantine is enforced by blocking any communication into and out of the compromised container.

A. Overall Architecture Our architecture is composed of four main components.

The vulnerability scanner (VS) is our threat detection component. When users deploy new kubernetes clusters, they register the clusters with the vulnerability scanner and install scanner agents in the clusters. When the scanner detects a threat, it posts a notification to the users’ registered OpenWhisk action which will determine the appropriate actions to take in order to mitigate the threat. The notification contains the identity of the container pods impacted by the threat. The OpenWhisk policy action invokes the appropriate Kubernetes API extension which will relay the operation to the Security Enforcement Operator (SEO). Figure 1 shows the overall architecture of our security enforcement platform that leverages the capabilities of the vulnerability scanner, third

1 In Kubernetes (K8s), pods abstract containers. A pod is a grouping of one or multiple containers that interact closely and share the same

fate.

party components like OpenWhisk, and extensions to Kubernetes APIs encoded in the SEO.

Figure 1. Overall automated threat mitigation architecture.

B. Vulnerability Scanning Container vulnerability scanning tools such as

Vulnerability Advisor [9], Docker Security Scanning [12] and CoreOS Clair [13] leverage online sources of vulnerabilities such as the Common Vulnerability Exposures database [14] and proprietary sources of threat intelligence to identify software vulnerabilities and insecure configurations. These knowledge bases evolve daily with new vulnerability discoveries which can lead containers that were previously deemed secure to become vulnerable.

Our vulnerability scanner leverages the capabilities of the Vulnerability Advisor to periodically scan running containers to discover vulnerabilities at creation time, new vulnerabilities disclosed during the containers life, and vulnerabilities introduced as a result of changes made to the running containers. This scan is performed by local vulnerability scanning agents that send container configuration information to the scanning service. Agents are deployed across all kubernetes cluster nodes. VS periodically ingests threat data from industry knowledge bases and evaluates them against the packages, files and configurations found in scanned containers. The scanner produces reports that identify specific software package versions in the container with disclosed vulnerabilities, and specific issues with the container configurations (e.g. insecure remote shell set up in the container.)

VS supports scans for multiple registered kubernetes clusters with installed agents and uses authentication tokens to restrict access to cluster data at the granularity of kubernetes namespaces. The scanner exposes RESTful APIs for access to vulerability reports for each container and implements a caller for OpenWhisk triggers exposed as Web APIs.

Scans produce new vulnerability findings and may trigger action invocations to the OpenWhisk API endpoints registered for the kubernetes cluster. These triggers carry small JSON documents that contain identifiers for the cluster and pods

impacted and a summary of the vulnerability findings. Figure 2 illustrates an example sequence of interactions between the various components used by our automated threat mitigation framework.

Figure 2. Example flow for threat mitigation.

C. Serverless Policies OpenWhisk provides a platform on which to implement ad-

hoc policies that automate remediation of newly discovered vulnerabilities or security issues in containers.

To implement ad-hoc VS security policies in OpenWhisk, users start by installing the security notices package in their OpenWhisk namespace. The security notices package sets up a trigger that policy actions can subscribe to and externalizes a Web API endpoint that acts as an event feed for the trigger. When VS scans a new container or image, it invokes the OpenWhisk Web API endpoint with the trigger belonging to the Kubernetes cluster owner.

import vs import kubernetes def main(params): findings = vs.get_findings(pod_id, timestamp) vulnerable_packages = findings['vulnerable_packages'] insecure_configs = findings['insecure_configurations'] if len(vulnerable_packages) > 0: kubernetes.snapshot(pod_id) kubernetes.terminate_graceful(pod_id) return {'text': 'Deleted pod ' + pod_id } if 'remote_shell_installed' in insecure_configs: kubernetes.quarantine(pod_id) return {'text': 'Quarantined pod ' + pod_id} return {'text': 'Container was not modified ' + pod_id}

Listing 1. A security policy that terminates or quarantines pods

according to the severity of security issues.

Listing 1 shows a policy that terminates a pod gracefully when software package vulnerabilities are found and quarantines the pod if the scan finding reveals that a remote shell server is installed. The action uses two modules for communication with the VS and the kubernetes cluster. The vs module invokes the get_findings API of VS to obtain a list of vulnerabilities and security findings for the pod. The kubernetes module invokes the Kubernetes Web APIs to terminate or quarantine a pod.

D. The Kubernetes Security Enforcement Operator In order to enforce the security recommendations sepecfied

in the OpenWhisk policies, we need an enforcement system with the ability to:

• communicate with every container engine in our cluster;

• isolate the containers beyond the scope of the container engine and Kubernetes;

• expose an API endpoint through which OpenWhisk can communicate its recommendations based on users’ policies.

Presently, Kubernetes does not support any feature for container quarantine, or termination based on security recommendations. Therefore we had to introduce this feature through a security enforcement system that extends Kubernetes APIs. Kubernetes supports the notion of third party resources (TPR) to extend its API with endpoints that can be monitoried by external components refered to as Operators. We designed our Security Enforcement Operator (SEO) by leveraging Kubernetes TPR. SEO is deployed on each cluster node where it constantly monitors the TPR API extension for new events. When OpenWhisk invokes the extension APIs to create a security recommendation Kubernetes event, the Operator executes the actions specified in the event, and reports back the execution results. Our Operator can terminate (abruptly or gracefully) or quarantine any given container in the Kubernetes cluster.

Figure 3. Security Enforcement Operator.

We deploy our SEO as a Kuberntes daemonset. A daemonset deployment ensures that every node in the Kubernetes cluster has at least one instance of the Operator running. Our Operator implements three interfaces as shown in Figure 3. The first interface interacts with the Kubernetes API- server by listening to the third party resources endpoint events (creation, deletion, update) invoked by the policy actions (executed by OpenWhisk). The second interface interacts with our container engine (Docker) in order to commit the container filesystem (thus persisting its content) and abruptly terminate containers running in pods. The third interface interacts directly with the networking plugin used by Kubernetes to manage the containers network configuration. Our SEO currently interacts with Calico, which isolates containers through a lower level mechanism (namely IP tables) in order to block any incoming/outgoing traffic related to an isolated environment.

IV. RELATED WORK The serverless architecture is still in its infancy, and

therefore the related work on using serverless in the context of securing containers is rather scarce. However the research on securing containers is an actively growing area. Barlev et al. [3] present a system protection tool called Starlight which implements a kernel module that intercepts local operations on each host and passes them to a local agent which in turn passes them to an event processor that analyzes the event and determines whether or not to alert the admin. Similar to our approach, this work uses a centralized approach for threat analysis, and can learn with time what rules to enforce. It targets applications like the container engine to detect host- escape attacks. However, this work does not perform container scanning to detect threats, hence a dormant threat will remain unnoticed until it is activated. Moreover that work does not leverage the use of serverless architecture to enhance efficiency nor does it implement actions to quarantine compromised containers. Mattetti et al. [4] present LiCShield which generates AppArmor profiles by tracing the container engine (Docker daemon) during the build and the execution of the containers. The profile generation process starts with a tracing phase by creating the container and tracing the kernel operations. The second phase consists of compiling the traces into AppArmor profiles for the container engine and the containers based on their images. LiCShield relates to our work from the aspect of targeting the same problem of securing Linux containers and the container engine. Nevertheless, LiCShield has the same limitations as Starlight, where it does not scan the containers for vulnerabilities, and therefore dormant threats will not be shielded against during the tracing phase. In fact we consider LiCShield and Starlight to be complementary to our work, since they also create security profiles for the container engine itself. We also believe that both works can leverage the serverless architecture to reduce their resource utilization. Catuogno and Galdi [10] present two models for defining the security properties of container-based systems, and argue that the two models are equivalent from the point of view of security threats. The authors also reached a conclusion that the security model adopted in Docker, if fully implemented, is adequate according to the criteria defined in the Common Criteria security certification. This work addresses broadly the criteria to secure containerized systems, which should be followed to ensure that the container host and docker engine are properly secured. The models compared in this paper provide a set of criteria to evaluate the security of a containerized system, however, these models provide general guidelines for configuring the system but they do not address services to detect and react to security vulnerabilities at runtime, which is the focus of our work.

In terms of using serverless-like architecture to introduce new functionalities in the cloud, McGrath et al. [11] present two cloud event applications: one applying Lambdefy framework to demonstrate the differing requirements between applications deployed to IaaS and applications deployed as a cloud event, and Media Management System for showing high scalability of image resizing tasks on Lambda. Similar to our

work, this paper addresses use of cloud event technology. However the focus of this paper is performance metrics and optimization aspect of cloud event application using Lambda, and its target is high-performance media management system. It does not address cloud event application to security vulnerability detection nor security for container-based systems.

V. CONCLUSION AND FUTURE WORK In this work we presented our serverless architecture for

securing Linux containers. Our approach provides continous scanning for containers. Upon the detection of vulnerabilities, our automated threat mitigation framework analyzes the vulnerability reports, and based on user defined polycies, triggers the proper action needed to mitigate and contain the threat within the compromised container. In our future work we will investigate the use of artificial intelligence (e.g. machine learning) to automatically generate the security policies based on the severity of the detected threats.

REFERENCES [1] R. John and J. F. Ransome. Cloud computing: implementation,

management, and security. CRC press, 2016.

[2] M. Dirk. "Docker: lightweight linux containers for consistent development and deployment." Linux Journal 2014.239 (2014)

[3] S. Barlev, Z. Basil, S. Kohanim, R. Peleg, S. Regev and A. Shulman- Peleg, "Secure yet usable: Protecting servers and Linux containers," in IBM Journal of Research and Development, vol. 60, no. 4, pp. 12:1- 12:10, July-Aug. 2016. doi: 10.1147/JRD.2016.2574138 keywords

[4] M. Mattetti, A. Shulman-Peleg, Y. Allouche, A. Corradi, S. Dolev and L. Foschini, "Securing the infrastructure and the workloads of linux containers," 2015 IEEE Conference on Communications and Network Security (CNS), Florence, 2015, pp. 559-567.

[5] Docker Swarm, online: https://docs.docker.com/engine/swarm/ accessed on March 27, 2017

[6] Kubernetes, online: https://kubernetes.io/ accessed on March 27, 2017 [7] OpenWhisk, online: https://developer.ibm.com/openwhisk/ accessed on

March 27, 2017

[8] D. Poccia, "AWS Lambda in Action: Event-Driven Serverless Applications", Manning Pubn, 2016. ISBN 1617293717, 9781617293719

[9] R. Koller, "Vulnerability Advisor – Secure your Dev + Ops across containers" https://www.ibm.com/blogs/bluemix/2016/11/vulnerability-advisor- secure-your-dev-ops-across-containers/

[10] L. Catuogno and C. Galdi, "On the Evaluation of Security Properties of Containerized Systems," 2016 15th International Conference on Ubiquitous Computing and Communications and 2016 International Symposium on Cyberspace and Security (IUCC-CSS), Granada, 2016, pp. 69-76.

[11] G. McGrath, J. Short, S. Ennis, B. Judson and P. Brenner, "Cloud Event Programming Paradigms: Applications and Analysis," 2016 IEEE 9th International Conference on Cloud Computing (CLOUD), San Francisco, CA, 2016, pp. 400-406.

[12] Docker Security Scanning, online: https://docs.docker.com/docker- cloud/builds/image-scan/ accessed on March 27, 2017.

[13] CoreOS Clair, online: https://github.com/coreos/clair accessed on March 27, 2017.

[14] Common Vulnerabilities Exposures, online: https://cve.mitre.org acessed on March 27, 2017.

<< /ASCII85EncodePages false /AllowTransparency false /AutoPositionEPSFiles true /AutoRotatePages /None /Binding /Left /CalGrayProfile (Gray Gamma 2.2) /CalRGBProfile (sRGB IEC61966-2.1) /CalCMYKProfile (U.S. Web Coated \050SWOP\051 v2) /sRGBProfile (sRGB IEC61966-2.1) /CannotEmbedFontPolicy /Error /CompatibilityLevel 1.7 /CompressObjects /Off /CompressPages true /ConvertImagesToIndexed true /PassThroughJPEGImages true /CreateJobTicket false /DefaultRenderingIntent /Default /DetectBlends true /DetectCurves 0.0000 /ColorConversionStrategy /LeaveColorUnchanged /DoThumbnails false /EmbedAllFonts true /EmbedOpenType false /ParseICCProfilesInComments true /EmbedJobOptions true /DSCReportingLevel 0 /EmitDSCWarnings false /EndPage -1 /ImageMemory 1048576 /LockDistillerParams true /MaxSubsetPct 100 /Optimize true /OPM 0 /ParseDSCComments false /ParseDSCCommentsForDocInfo true /PreserveCopyPage true /PreserveDICMYKValues true /PreserveEPSInfo false /PreserveFlatness true /PreserveHalftoneInfo true /PreserveOPIComments false /PreserveOverprintSettings true /StartPage 1 /SubsetFonts true /TransferFunctionInfo /Remove /UCRandBGInfo /Preserve /UsePrologue false /ColorSettingsFile () /AlwaysEmbed [ true /AbadiMT-CondensedLight /ACaslon-Italic /ACaslon-Regular /ACaslon-Semibold /ACaslon-SemiboldItalic /AdobeArabic-Bold /AdobeArabic-BoldItalic /AdobeArabic-Italic /AdobeArabic-Regular /AdobeHebrew-Bold /AdobeHebrew-BoldItalic /AdobeHebrew-Italic /AdobeHebrew-Regular /AdobeHeitiStd-Regular /AdobeMingStd-Light /AdobeMyungjoStd-Medium /AdobePiStd /AdobeSongStd-Light /AdobeThai-Bold /AdobeThai-BoldItalic /AdobeThai-Italic /AdobeThai-Regular /AGaramond-Bold /AGaramond-BoldItalic /AGaramond-Italic /AGaramond-Regular /AGaramond-Semibold /AGaramond-SemiboldItalic /AgencyFB-Bold /AgencyFB-Reg /AGOldFace-Outline /AharoniBold /Algerian /Americana /Americana-ExtraBold /AndaleMono /AndaleMonoIPA /AngsanaNew /AngsanaNew-Bold /AngsanaNew-BoldItalic /AngsanaNew-Italic /AngsanaUPC /AngsanaUPC-Bold /AngsanaUPC-BoldItalic /AngsanaUPC-Italic /Anna /ArialAlternative /ArialAlternativeSymbol /Arial-Black /Arial-BlackItalic /Arial-BoldItalicMT /Arial-BoldMT /Arial-ItalicMT /ArialMT /ArialMT-Black /ArialNarrow /ArialNarrow-Bold /ArialNarrow-BoldItalic /ArialNarrow-Italic /ArialRoundedMTBold /ArialUnicodeMS /ArrusBT-Bold /ArrusBT-BoldItalic /ArrusBT-Italic /ArrusBT-Roman /AvantGarde-Book /AvantGarde-BookOblique /AvantGarde-Demi /AvantGarde-DemiOblique /AvantGardeITCbyBT-Book /AvantGardeITCbyBT-BookOblique /BakerSignet /BankGothicBT-Medium /Barmeno-Bold /Barmeno-ExtraBold /Barmeno-Medium /Barmeno-Regular /Baskerville /BaskervilleBE-Italic /BaskervilleBE-Medium /BaskervilleBE-MediumItalic /BaskervilleBE-Regular /Baskerville-Bold /Baskerville-BoldItalic /Baskerville-Italic /BaskOldFace /Batang /BatangChe /Bauhaus93 /Bellevue /BellMT /BellMTBold /BellMTItalic /BerlingAntiqua-Bold /BerlingAntiqua-BoldItalic /BerlingAntiqua-Italic /BerlingAntiqua-Roman /BerlinSansFB-Bold /BerlinSansFBDemi-Bold /BerlinSansFB-Reg /BernardMT-Condensed /BernhardModernBT-Bold /BernhardModernBT-BoldItalic /BernhardModernBT-Italic /BernhardModernBT-Roman /BiffoMT /BinnerD /BinnerGothic /BlackadderITC-Regular /Blackoak /blex /blsy /Bodoni /Bodoni-Bold /Bodoni-BoldItalic /Bodoni-Italic /BodoniMT /BodoniMTBlack /BodoniMTBlack-Italic /BodoniMT-Bold /BodoniMT-BoldItalic /BodoniMTCondensed /BodoniMTCondensed-Bold /BodoniMTCondensed-BoldItalic /BodoniMTCondensed-Italic /BodoniMT-Italic /BodoniMTPosterCompressed /Bodoni-Poster /Bodoni-PosterCompressed /BookAntiqua /BookAntiqua-Bold /BookAntiqua-BoldItalic /BookAntiqua-Italic /Bookman-Demi /Bookman-DemiItalic /Bookman-Light /Bookman-LightItalic /BookmanOldStyle /BookmanOldStyle-Bold /BookmanOldStyle-BoldItalic /BookmanOldStyle-Italic /BookshelfSymbolOne-Regular /BookshelfSymbolSeven /BookshelfSymbolThree-Regular /BookshelfSymbolTwo-Regular /Botanical /Boton-Italic /Boton-Medium /Boton-MediumItalic /Boton-Regular /Boulevard /BradleyHandITC /Braggadocio /BritannicBold /Broadway /BrowalliaNew /BrowalliaNew-Bold /BrowalliaNew-BoldItalic /BrowalliaNew-Italic /BrowalliaUPC /BrowalliaUPC-Bold /BrowalliaUPC-BoldItalic /BrowalliaUPC-Italic /BrushScript /BrushScriptMT /CaflischScript-Bold /CaflischScript-Regular /Calibri /Calibri-Bold /Calibri-BoldItalic /Calibri-Italic /CalifornianFB-Bold /CalifornianFB-Italic /CalifornianFB-Reg /CalisMTBol /CalistoMT /CalistoMT-BoldItalic /CalistoMT-Italic /Cambria /Cambria-Bold /Cambria-BoldItalic /Cambria-Italic /CambriaMath /Candara /Candara-Bold /Candara-BoldItalic /Candara-Italic /Carta /CaslonOpenfaceBT-Regular /Castellar /CastellarMT /Centaur /Centaur-Italic /Century /CenturyGothic /CenturyGothic-Bold /CenturyGothic-BoldItalic /CenturyGothic-Italic /CenturySchL-Bold /CenturySchL-BoldItal /CenturySchL-Ital /CenturySchL-Roma /CenturySchoolbook /CenturySchoolbook-Bold /CenturySchoolbook-BoldItalic /CenturySchoolbook-Italic /CGTimes-Bold /CGTimes-BoldItalic /CGTimes-Italic /CGTimes-Regular /CharterBT-Bold /CharterBT-BoldItalic /CharterBT-Italic /CharterBT-Roman /CheltenhamITCbyBT-Bold /CheltenhamITCbyBT-BoldItalic /CheltenhamITCbyBT-Book /CheltenhamITCbyBT-BookItalic /Chiller-Regular /Cmb10 /CMB10 /Cmbsy10 /CMBSY10 /CMBSY5 /CMBSY6 /CMBSY7 /CMBSY8 /CMBSY9 /Cmbx10 /CMBX10 /Cmbx12 /CMBX12 /Cmbx5 /CMBX5 /Cmbx6 /CMBX6 /Cmbx7 /CMBX7 /Cmbx8 /CMBX8 /Cmbx9 /CMBX9 /Cmbxsl10 /CMBXSL10 /Cmbxti10 /CMBXTI10 /Cmcsc10 /CMCSC10 /Cmcsc8 /CMCSC8 /Cmcsc9 /CMCSC9 /Cmdunh10 /CMDUNH10 /Cmex10 /CMEX10 /CMEX7 /CMEX8 /CMEX9 /Cmff10 /CMFF10 /Cmfi10 /CMFI10 /Cmfib8 /CMFIB8 /Cminch /CMINCH /Cmitt10 /CMITT10 /Cmmi10 /CMMI10 /Cmmi12 /CMMI12 /Cmmi5 /CMMI5 /Cmmi6 /CMMI6 /Cmmi7 /CMMI7 /Cmmi8 /CMMI8 /Cmmi9 /CMMI9 /Cmmib10 /CMMIB10 /CMMIB5 /CMMIB6 /CMMIB7 /CMMIB8 /CMMIB9 /Cmr10 /CMR10 /Cmr12 /CMR12 /Cmr17 /CMR17 /Cmr5 /CMR5 /Cmr6 /CMR6 /Cmr7 /CMR7 /Cmr8 /CMR8 /Cmr9 /CMR9 /Cmsl10 /CMSL10 /Cmsl12 /CMSL12 /Cmsl8 /CMSL8 /Cmsl9 /CMSL9 /Cmsltt10 /CMSLTT10 /Cmss10 /CMSS10 /Cmss12 /CMSS12 /Cmss17 /CMSS17 /Cmss8 /CMSS8 /Cmss9 /CMSS9 /Cmssbx10 /CMSSBX10 /Cmssdc10 /CMSSDC10 /Cmssi10 /CMSSI10 /Cmssi12 /CMSSI12 /Cmssi17 /CMSSI17 /Cmssi8 /CMSSI8 /Cmssi9 /CMSSI9 /Cmssq8 /CMSSQ8 /Cmssqi8 /CMSSQI8 /Cmsy10 /CMSY10 /Cmsy5 /CMSY5 /Cmsy6 /CMSY6 /Cmsy7 /CMSY7 /Cmsy8 /CMSY8 /Cmsy9 /CMSY9 /Cmtcsc10 /CMTCSC10 /Cmtex10 /CMTEX10 /Cmtex8 /CMTEX8 /Cmtex9 /CMTEX9 /Cmti10 /CMTI10 /Cmti12 /CMTI12 /Cmti7 /CMTI7 /Cmti8 /CMTI8 /Cmti9 /CMTI9 /Cmtt10 /CMTT10 /Cmtt12 /CMTT12 /Cmtt8 /CMTT8 /Cmtt9 /CMTT9 /Cmu10 /CMU10 /Cmvtt10 /CMVTT10 /ColonnaMT /Colossalis-Bold /ComicSansMS /ComicSansMS-Bold /Consolas /Consolas-Bold /Consolas-BoldItalic /Consolas-Italic /Constantia /Constantia-Bold /Constantia-BoldItalic /Constantia-Italic /CooperBlack /CopperplateGothic-Bold /CopperplateGothic-Light /Copperplate-ThirtyThreeBC /Corbel /Corbel-Bold /Corbel-BoldItalic /Corbel-Italic /CordiaNew /CordiaNew-Bold /CordiaNew-BoldItalic /CordiaNew-Italic /CordiaUPC /CordiaUPC-Bold /CordiaUPC-BoldItalic /CordiaUPC-Italic /Courier /Courier-Bold /Courier-BoldOblique /CourierNewPS-BoldItalicMT /CourierNewPS-BoldMT /CourierNewPS-ItalicMT /CourierNewPSMT /Courier-Oblique /CourierStd /CourierStd-Bold /CourierStd-BoldOblique /CourierStd-Oblique /CourierX-Bold /CourierX-BoldOblique /CourierX-Oblique /CourierX-Regular /CreepyRegular /CurlzMT /David-Bold /David-Reg /DavidTransparent /Dcb10 /Dcbx10 /Dcbxsl10 /Dcbxti10 /Dccsc10 /Dcitt10 /Dcr10 /Desdemona /DilleniaUPC /DilleniaUPCBold /DilleniaUPCBoldItalic /DilleniaUPCItalic /Dingbats /DomCasual /Dotum /DotumChe /DoulosSIL /EdwardianScriptITC /Elephant-Italic /Elephant-Regular /EngraversGothicBT-Regular /EngraversMT /EraserDust /ErasITC-Bold /ErasITC-Demi /ErasITC-Light /ErasITC-Medium /ErieBlackPSMT /ErieLightPSMT /EriePSMT /EstrangeloEdessa /Euclid /Euclid-Bold /Euclid-BoldItalic /EuclidExtra /EuclidExtra-Bold /EuclidFraktur /EuclidFraktur-Bold /Euclid-Italic /EuclidMathOne /EuclidMathOne-Bold /EuclidMathTwo /EuclidMathTwo-Bold /EuclidSymbol /EuclidSymbol-Bold /EuclidSymbol-BoldItalic /EuclidSymbol-Italic /EucrosiaUPC /EucrosiaUPCBold /EucrosiaUPCBoldItalic /EucrosiaUPCItalic /EUEX10 /EUEX7 /EUEX8 /EUEX9 /EUFB10 /EUFB5 /EUFB7 /EUFM10 /EUFM5 /EUFM7 /EURB10 /EURB5 /EURB7 /EURM10 /EURM5 /EURM7 /EuroMono-Bold /EuroMono-BoldItalic /EuroMono-Italic /EuroMono-Regular /EuroSans-Bold /EuroSans-BoldItalic /EuroSans-Italic /EuroSans-Regular /EuroSerif-Bold /EuroSerif-BoldItalic /EuroSerif-Italic /EuroSerif-Regular /EUSB10 /EUSB5 /EUSB7 /EUSM10 /EUSM5 /EUSM7 /FelixTitlingMT /Fences /FencesPlain /FigaroMT /FixedMiriamTransparent /FootlightMTLight /Formata-Italic /Formata-Medium /Formata-MediumItalic /Formata-Regular /ForteMT /FranklinGothic-Book /FranklinGothic-BookItalic /FranklinGothic-Demi /FranklinGothic-DemiCond /FranklinGothic-DemiItalic /FranklinGothic-Heavy /FranklinGothic-HeavyItalic /FranklinGothicITCbyBT-Book /FranklinGothicITCbyBT-BookItal /FranklinGothicITCbyBT-Demi /FranklinGothicITCbyBT-DemiItal /FranklinGothic-Medium /FranklinGothic-MediumCond /FranklinGothic-MediumItalic /FrankRuehl /FreesiaUPC /FreesiaUPCBold /FreesiaUPCBoldItalic /FreesiaUPCItalic /FreestyleScript-Regular /FrenchScriptMT /Frutiger-Black /Frutiger-BlackCn /Frutiger-BlackItalic /Frutiger-Bold /Frutiger-BoldCn /Frutiger-BoldItalic /Frutiger-Cn /Frutiger-ExtraBlackCn /Frutiger-Italic /Frutiger-Light /Frutiger-LightCn /Frutiger-LightItalic /Frutiger-Roman /Frutiger-UltraBlack /Futura-Bold /Futura-BoldOblique /Futura-Book /Futura-BookOblique /FuturaBT-Bold /FuturaBT-BoldItalic /FuturaBT-Book /FuturaBT-BookItalic /FuturaBT-Medium /FuturaBT-MediumItalic /Futura-Light /Futura-LightOblique /GalliardITCbyBT-Bold /GalliardITCbyBT-BoldItalic /GalliardITCbyBT-Italic /GalliardITCbyBT-Roman /Garamond /Garamond-Bold /Garamond-BoldCondensed /Garamond-BoldCondensedItalic /Garamond-BoldItalic /Garamond-BookCondensed /Garamond-BookCondensedItalic /Garamond-Italic /Garamond-LightCondensed /Garamond-LightCondensedItalic /Gautami /GeometricSlab703BT-Light /GeometricSlab703BT-LightItalic /Georgia /Georgia-Bold /Georgia-BoldItalic /Georgia-Italic /GeorgiaRef /Giddyup /Giddyup-Thangs /Gigi-Regular /GillSans /GillSans-Bold /GillSans-BoldItalic /GillSans-Condensed /GillSans-CondensedBold /GillSans-Italic /GillSans-Light /GillSans-LightItalic /GillSansMT /GillSansMT-Bold /GillSansMT-BoldItalic /GillSansMT-Condensed /GillSansMT-ExtraCondensedBold /GillSansMT-Italic /GillSans-UltraBold /GillSans-UltraBoldCondensed /GloucesterMT-ExtraCondensed /Gothic-Thirteen /GoudyOldStyleBT-Bold /GoudyOldStyleBT-BoldItalic /GoudyOldStyleBT-Italic /GoudyOldStyleBT-Roman /GoudyOldStyleT-Bold /GoudyOldStyleT-Italic /GoudyOldStyleT-Regular /GoudyStout /GoudyTextMT-LombardicCapitals /GSIDefaultSymbols /Gulim /GulimChe /Gungsuh /GungsuhChe /Haettenschweiler /HarlowSolid /Harrington /Helvetica /Helvetica-Black /Helvetica-BlackOblique /Helvetica-Bold /Helvetica-BoldOblique /Helvetica-Condensed /Helvetica-Condensed-Black /Helvetica-Condensed-BlackObl /Helvetica-Condensed-Bold /Helvetica-Condensed-BoldObl /Helvetica-Condensed-Light /Helvetica-Condensed-LightObl /Helvetica-Condensed-Oblique /Helvetica-Fraction /Helvetica-Narrow /Helvetica-Narrow-Bold /Helvetica-Narrow-BoldOblique /Helvetica-Narrow-Oblique /Helvetica-Oblique /HighTowerText-Italic /HighTowerText-Reg /Humanist521BT-BoldCondensed /Humanist521BT-Light /Humanist521BT-LightItalic /Humanist521BT-RomanCondensed /Imago-ExtraBold /Impact /ImprintMT-Shadow /InformalRoman-Regular /IrisUPC /IrisUPCBold /IrisUPCBoldItalic /IrisUPCItalic /Ironwood /ItcEras-Medium /ItcKabel-Bold /ItcKabel-Book /ItcKabel-Demi /ItcKabel-Medium /ItcKabel-Ultra /JasmineUPC /JasmineUPC-Bold /JasmineUPC-BoldItalic /JasmineUPC-Italic /JoannaMT /JoannaMT-Italic /Jokerman-Regular /JuiceITC-Regular /Kartika /Kaufmann /KaufmannBT-Bold /KaufmannBT-Regular /KidTYPEPaint /KinoMT /KodchiangUPC /KodchiangUPC-Bold /KodchiangUPC-BoldItalic /KodchiangUPC-Italic /KorinnaITCbyBT-Regular /KristenITC-Regular /KrutiDev040Bold /KrutiDev040BoldItalic /KrutiDev040Condensed /KrutiDev040Italic /KrutiDev040Thin /KrutiDev040Wide /KrutiDev060 /KrutiDev060Bold /KrutiDev060BoldItalic /KrutiDev060Condensed /KrutiDev060Italic /KrutiDev060Thin /KrutiDev060Wide /KrutiDev070 /KrutiDev070Condensed /KrutiDev070Italic /KrutiDev070Thin /KrutiDev070Wide /KrutiDev080 /KrutiDev080Condensed /KrutiDev080Italic /KrutiDev080Wide /KrutiDev090 /KrutiDev090Bold /KrutiDev090BoldItalic /KrutiDev090Condensed /KrutiDev090Italic /KrutiDev090Thin /KrutiDev090Wide /KrutiDev100 /KrutiDev100Bold /KrutiDev100BoldItalic /KrutiDev100Condensed /KrutiDev100Italic /KrutiDev100Thin /KrutiDev100Wide /KrutiDev120 /KrutiDev120Condensed /KrutiDev120Thin /KrutiDev120Wide /KrutiDev130 /KrutiDev130Condensed /KrutiDev130Thin /KrutiDev130Wide /KunstlerScript /Latha /LatinWide /LetterGothic /LetterGothic-Bold /LetterGothic-BoldOblique /LetterGothic-BoldSlanted /LetterGothicMT /LetterGothicMT-Bold /LetterGothicMT-BoldOblique /LetterGothicMT-Oblique /LetterGothic-Slanted /LevenimMT /LevenimMTBold /LilyUPC /LilyUPCBold /LilyUPCBoldItalic /LilyUPCItalic /Lithos-Black /Lithos-Regular /LotusWPBox-Roman /LotusWPIcon-Roman /LotusWPIntA-Roman /LotusWPIntB-Roman /LotusWPType-Roman /LucidaBright /LucidaBright-Demi /LucidaBright-DemiItalic /LucidaBright-Italic /LucidaCalligraphy-Italic /LucidaConsole /LucidaFax /LucidaFax-Demi /LucidaFax-DemiItalic /LucidaFax-Italic /LucidaHandwriting-Italic /LucidaSans /LucidaSans-Demi /LucidaSans-DemiItalic /LucidaSans-Italic /LucidaSans-Typewriter /LucidaSans-TypewriterBold /LucidaSans-TypewriterBoldOblique /LucidaSans-TypewriterOblique /LucidaSansUnicode /Lydian /Magneto-Bold /MaiandraGD-Regular /Mangal-Regular /Map-Symbols /MathA /MathB /MathC /Mathematica1 /Mathematica1-Bold /Mathematica1Mono /Mathematica1Mono-Bold /Mathematica2 /Mathematica2-Bold /Mathematica2Mono /Mathematica2Mono-Bold /Mathematica3 /Mathematica3-Bold /Mathematica3Mono /Mathematica3Mono-Bold /Mathematica4 /Mathematica4-Bold /Mathematica4Mono /Mathematica4Mono-Bold /Mathematica5 /Mathematica5-Bold /Mathematica5Mono /Mathematica5Mono-Bold /Mathematica6 /Mathematica6Bold /Mathematica6Mono /Mathematica6MonoBold /Mathematica7 /Mathematica7Bold /Mathematica7Mono /Mathematica7MonoBold /MatisseITC-Regular /MaturaMTScriptCapitals /Mesquite /Mezz-Black /Mezz-Regular /MICR /MicrosoftSansSerif /MingLiU /Minion-BoldCondensed /Minion-BoldCondensedItalic /Minion-Condensed /Minion-CondensedItalic /Minion-Ornaments /MinionPro-Bold /MinionPro-BoldIt /MinionPro-It /MinionPro-Regular /Miriam /MiriamFixed /MiriamTransparent /Mistral /Modern-Regular /MonotypeCorsiva /MonotypeSorts /MSAM10 /MSAM5 /MSAM6 /MSAM7 /MSAM8 /MSAM9 /MSBM10 /MSBM5 /MSBM6 /MSBM7 /MSBM8 /MSBM9 /MS-Gothic /MSHei /MSLineDrawPSMT /MS-Mincho /MSOutlook /MS-PGothic /MS-PMincho /MSReference1 /MSReference2 /MSReferenceSansSerif /MSReferenceSansSerif-Bold /MSReferenceSansSerif-BoldItalic /MSReferenceSansSerif-Italic /MSReferenceSerif /MSReferenceSerif-Bold /MSReferenceSerif-BoldItalic /MSReferenceSerif-Italic /MSReferenceSpecialty /MSSong /MS-UIGothic /MT-Extra /MTExtraTiger /MT-Symbol /MT-Symbol-Italic /MVBoli /Myriad-Bold /Myriad-BoldItalic /Myriad-Italic /Myriad-Roman /Narkisim /NewCenturySchlbk-Bold /NewCenturySchlbk-BoldItalic /NewCenturySchlbk-Italic /NewCenturySchlbk-Roman /NewMilleniumSchlbk-BoldItalicSH /NewsGothic /NewsGothic-Bold /NewsGothicBT-Bold /NewsGothicBT-BoldItalic /NewsGothicBT-Italic /NewsGothicBT-Roman /NewsGothic-Condensed /NewsGothic-Italic /NewsGothicMT /NewsGothicMT-Bold /NewsGothicMT-Italic /NiagaraEngraved-Reg /NiagaraSolid-Reg /NimbusMonL-Bold /NimbusMonL-BoldObli /NimbusMonL-Regu /NimbusMonL-ReguObli /NimbusRomNo9L-Medi /NimbusRomNo9L-MediItal /NimbusRomNo9L-Regu /NimbusRomNo9L-ReguItal /NimbusSanL-Bold /NimbusSanL-BoldCond /NimbusSanL-BoldCondItal /NimbusSanL-BoldItal /NimbusSanL-Regu /NimbusSanL-ReguCond /NimbusSanL-ReguCondItal /NimbusSanL-ReguItal /Nimrod /Nimrod-Bold /Nimrod-BoldItalic /Nimrod-Italic /NSimSun /Nueva-BoldExtended /Nueva-BoldExtendedItalic /Nueva-Italic /Nueva-Roman /NuptialScript /OCRA /OCRA-Alternate /OCRAExtended /OCRB /OCRB-Alternate /OfficinaSans-Bold /OfficinaSans-BoldItalic /OfficinaSans-Book /OfficinaSans-BookItalic /OfficinaSerif-Bold /OfficinaSerif-BoldItalic /OfficinaSerif-Book /OfficinaSerif-BookItalic /OldEnglishTextMT /Onyx /OnyxBT-Regular /OzHandicraftBT-Roman /PalaceScriptMT /Palatino-Bold /Palatino-BoldItalic /Palatino-Italic /PalatinoLinotype-Bold /PalatinoLinotype-BoldItalic /PalatinoLinotype-Italic /PalatinoLinotype-Roman /Palatino-Roman /PapyrusPlain /Papyrus-Regular /Parchment-Regular /Parisian /ParkAvenue /Penumbra-SemiboldFlare /Penumbra-SemiboldSans /Penumbra-SemiboldSerif /PepitaMT /Perpetua /Perpetua-Bold /Perpetua-BoldItalic /Perpetua-Italic /PerpetuaTitlingMT-Bold /PerpetuaTitlingMT-Light /PhotinaCasualBlack /Playbill /PMingLiU /Poetica-SuppOrnaments /PoorRichard-Regular /PopplLaudatio-Italic /PopplLaudatio-Medium /PopplLaudatio-MediumItalic /PopplLaudatio-Regular /PrestigeElite /Pristina-Regular /PTBarnumBT-Regular /Raavi /RageItalic /Ravie /RefSpecialty /Ribbon131BT-Bold /Rockwell /Rockwell-Bold /Rockwell-BoldItalic /Rockwell-Condensed /Rockwell-CondensedBold /Rockwell-ExtraBold /Rockwell-Italic /Rockwell-Light /Rockwell-LightItalic /Rod /RodTransparent /RunicMT-Condensed /Sanvito-Light /Sanvito-Roman /ScriptC /ScriptMTBold /SegoeUI /SegoeUI-Bold /SegoeUI-BoldItalic /SegoeUI-Italic /Serpentine-BoldOblique /ShelleyVolanteBT-Regular /ShowcardGothic-Reg /Shruti /SILDoulosIPA /SimHei /SimSun /SimSun-PUA /SnapITC-Regular /StandardSymL /Stencil /StoneSans /StoneSans-Bold /StoneSans-BoldItalic /StoneSans-Italic /StoneSans-Semibold /StoneSans-SemiboldItalic /Stop /Swiss721BT-BlackExtended /Sylfaen /Symbol /SymbolMT /SymbolTiger /SymbolTigerExpert /Tahoma /Tahoma-Bold /Tci1 /Tci1Bold /Tci1BoldItalic /Tci1Italic /Tci2 /Tci2Bold /Tci2BoldItalic /Tci2Italic /Tci3 /Tci3Bold /Tci3BoldItalic /Tci3Italic /Tci4 /Tci4Bold /Tci4BoldItalic /Tci4Italic /TechnicalItalic /TechnicalPlain /Tekton /Tekton-Bold /TektonMM /Tempo-HeavyCondensed /Tempo-HeavyCondensedItalic /TempusSansITC /Tiger /TigerExpert /Times-Bold /Times-BoldItalic /Times-BoldItalicOsF /Times-BoldSC /Times-ExtraBold /Times-Italic /Times-ItalicOsF /TimesNewRomanMT-ExtraBold /TimesNewRomanPS-BoldItalicMT /TimesNewRomanPS-BoldMT /TimesNewRomanPS-ItalicMT /TimesNewRomanPSMT /Times-Roman /Times-RomanSC /Trajan-Bold /Trebuchet-BoldItalic /TrebuchetMS /TrebuchetMS-Bold /TrebuchetMS-Italic /Tunga-Regular /TwCenMT-Bold /TwCenMT-BoldItalic /TwCenMT-Condensed /TwCenMT-CondensedBold /TwCenMT-CondensedExtraBold /TwCenMT-CondensedMedium /TwCenMT-Italic /TwCenMT-Regular /Univers-Bold /Univers-BoldItalic /UniversCondensed-Bold /UniversCondensed-BoldItalic /UniversCondensed-Medium /UniversCondensed-MediumItalic /Univers-Medium /Univers-MediumItalic /URWBookmanL-DemiBold /URWBookmanL-DemiBoldItal /URWBookmanL-Ligh /URWBookmanL-LighItal /URWChanceryL-MediItal /URWGothicL-Book /URWGothicL-BookObli /URWGothicL-Demi /URWGothicL-DemiObli /URWPalladioL-Bold /URWPalladioL-BoldItal /URWPalladioL-Ital /URWPalladioL-Roma /USPSBarCode /VAGRounded-Black /VAGRounded-Bold /VAGRounded-Light /VAGRounded-Thin /Verdana /Verdana-Bold /Verdana-BoldItalic /Verdana-Italic /VerdanaRef /VinerHandITC /Viva-BoldExtraExtended /Vivaldii /Viva-LightCondensed /Viva-Regular /VladimirScript /Vrinda /Webdings /Westminster /Willow /Wingdings2 /Wingdings3 /Wingdings-Regular /WNCYB10 /WNCYI10 /WNCYR10 /WNCYSC10 /WNCYSS10 /WoodtypeOrnaments-One /WoodtypeOrnaments-Two /WP-ArabicScriptSihafa /WP-ArabicSihafa /WP-BoxDrawing /WP-CyrillicA /WP-CyrillicB /WP-GreekCentury /WP-GreekCourier /WP-GreekHelve /WP-HebrewDavid /WP-IconicSymbolsA /WP-IconicSymbolsB /WP-Japanese /WP-MathA /WP-MathB /WP-MathExtendedA /WP-MathExtendedB /WP-MultinationalAHelve /WP-MultinationalARoman /WP-MultinationalBCourier /WP-MultinationalBHelve /WP-MultinationalBRoman /WP-MultinationalCourier /WP-Phonetic /WPTypographicSymbols /XYATIP10 /XYBSQL10 /XYBTIP10 /XYCIRC10 /XYCMAT10 /XYCMBT10 /XYDASH10 /XYEUAT10 /XYEUBT10 /ZapfChancery-MediumItalic /ZapfDingbats /ZapfHumanist601BT-Bold /ZapfHumanist601BT-BoldItalic /ZapfHumanist601BT-Demi /ZapfHumanist601BT-DemiItalic /ZapfHumanist601BT-Italic /ZapfHumanist601BT-Roman /ZWAdobeF ] /NeverEmbed [ true ] /AntiAliasColorImages false /CropColorImages true /ColorImageMinResolution 150 /ColorImageMinResolutionPolicy /OK /DownsampleColorImages true /ColorImageDownsampleType /Bicubic /ColorImageResolution 300 /ColorImageDepth -1 /ColorImageMinDownsampleDepth 1 /ColorImageDownsampleThreshold 2.00333 /EncodeColorImages true /ColorImageFilter /DCTEncode /AutoFilterColorImages true /ColorImageAutoFilterStrategy /JPEG /ColorACSImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /ColorImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /JPEG2000ColorACSImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >> /JPEG2000ColorImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >> /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 150 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 2.00333 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /GrayImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /JPEG2000GrayACSImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >> /JPEG2000GrayImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >> /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 600 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.00167 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict << /K -1 >> /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False /CreateJDFFile false /Description << /ARA <FEFF06270633062A062E062F0645002006470630064700200627064406250639062F0627062F0627062A002006440625064606340627062100200648062B062706260642002000410064006F00620065002000500044004600200645062A064806270641064206290020064506390020064506420627064A064A0633002006390631063600200648063706280627063906290020062706440648062B0627062606420020062706440645062A062F062706480644062900200641064A00200645062C062706440627062A002006270644062306390645062706440020062706440645062E062A064406410629061B0020064A06450643064600200641062A062D00200648062B0627062606420020005000440046002006270644064506460634062306290020062806270633062A062E062F062706450020004100630072006F0062006100740020064800410064006F006200650020005200650061006400650072002006250635062F0627063100200035002E0030002006480627064406250635062F062706310627062A0020062706440623062D062F062B002E> /CHS <FEFF4f7f75288fd94e9b8bbe5b9a521b5efa7684002000410064006f006200650020005000440046002065876863900275284e8e55464e1a65876863768467e5770b548c62535370300260a853ef4ee54f7f75280020004100630072006f0062006100740020548c002000410064006f00620065002000520065006100640065007200200035002e003000204ee553ca66f49ad87248672c676562535f00521b5efa768400200050004400460020658768633002> /CHT <FEFF4f7f752890194e9b8a2d7f6e5efa7acb7684002000410064006f006200650020005000440046002065874ef69069752865bc666e901a554652d965874ef6768467e5770b548c52175370300260a853ef4ee54f7f75280020004100630072006f0062006100740020548c002000410064006f00620065002000520065006100640065007200200035002e003000204ee553ca66f49ad87248672c4f86958b555f5df25efa7acb76840020005000440046002065874ef63002> /CZE <FEFF005400610074006f0020006e006100730074006100760065006e00ed00200070006f0075017e0069006a007400650020006b0020007600790074007600e101590065006e00ed00200064006f006b0075006d0065006e0074016f002000410064006f006200650020005000440046002000760068006f0064006e00fd00630068002000700072006f002000730070006f006c00650068006c0069007600e90020007a006f006200720061007a006f007600e1006e00ed002000610020007400690073006b0020006f006200630068006f0064006e00ed0063006800200064006f006b0075006d0065006e0074016f002e002000200056007900740076006f01590065006e00e900200064006f006b0075006d0065006e007400790020005000440046002000620075006400650020006d006f017e006e00e90020006f007400650076015900ed007400200076002000700072006f006700720061006d0065006300680020004100630072006f00620061007400200061002000410064006f00620065002000520065006100640065007200200035002e0030002000610020006e006f0076011b006a016100ed00630068002e> /DAN <FEFF004200720075006700200069006e0064007300740069006c006c0069006e006700650072006e0065002000740069006c0020006100740020006f007000720065007400740065002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e007400650072002c0020006400650072002000650067006e006500720020007300690067002000740069006c00200064006500740061006c006a006500720065007400200073006b00e60072006d007600690073006e0069006e00670020006f00670020007500640073006b007200690076006e0069006e006700200061006600200066006f0072007200650074006e0069006e006700730064006f006b0075006d0065006e007400650072002e0020004400650020006f007000720065007400740065006400650020005000440046002d0064006f006b0075006d0065006e0074006500720020006b0061006e002000e50062006e00650073002000690020004100630072006f00620061007400200065006c006c006500720020004100630072006f006200610074002000520065006100640065007200200035002e00300020006f00670020006e0079006500720065002e> /DEU <FEFF00560065007200770065006e00640065006e0020005300690065002000640069006500730065002000450069006e007300740065006c006c0075006e00670065006e0020007a0075006d002000450072007300740065006c006c0065006e00200076006f006e002000410064006f006200650020005000440046002d0044006f006b0075006d0065006e00740065006e002c00200075006d002000650069006e00650020007a0075007600650072006c00e40073007300690067006500200041006e007a006500690067006500200075006e00640020004100750073006700610062006500200076006f006e00200047006500730063006800e40066007400730064006f006b0075006d0065006e00740065006e0020007a0075002000650072007a00690065006c0065006e002e00200044006900650020005000440046002d0044006f006b0075006d0065006e007400650020006b00f6006e006e0065006e0020006d006900740020004100630072006f00620061007400200075006e0064002000520065006100640065007200200035002e003000200075006e00640020006800f600680065007200200067006500f600660066006e00650074002000770065007200640065006e002e> /ESP <FEFF005500740069006c0069006300650020006500730074006100200063006f006e0066006900670075007200610063006900f3006e0020007000610072006100200063007200650061007200200064006f00630075006d0065006e0074006f0073002000640065002000410064006f00620065002000500044004600200061006400650063007500610064006f007300200070006100720061002000760069007300750061006c0069007a00610063006900f3006e0020006500200069006d0070007200650073006900f3006e00200064006500200063006f006e006600690061006e007a006100200064006500200064006f00630075006d0065006e0074006f007300200063006f006d00650072006300690061006c00650073002e002000530065002000700075006500640065006e00200061006200720069007200200064006f00630075006d0065006e0074006f00730020005000440046002000630072006500610064006f007300200063006f006e0020004100630072006f006200610074002c002000410064006f00620065002000520065006100640065007200200035002e003000200079002000760065007200730069006f006e0065007300200070006f00730074006500720069006f007200650073002e> /FRA <FEFF005500740069006c006900730065007a00200063006500730020006f007000740069006f006e00730020006100660069006e00200064006500200063007200e900650072002000640065007300200064006f00630075006d0065006e00740073002000410064006f006200650020005000440046002000700072006f00660065007300730069006f006e006e0065006c007300200066006900610062006c0065007300200070006f007500720020006c0061002000760069007300750061006c00690073006100740069006f006e0020006500740020006c00270069006d007000720065007300730069006f006e002e0020004c0065007300200064006f00630075006d0065006e00740073002000500044004600200063007200e900e90073002000700065007500760065006e0074002000ea0074007200650020006f007500760065007200740073002000640061006e00730020004100630072006f006200610074002c002000610069006e00730069002000710075002700410064006f00620065002000520065006100640065007200200035002e0030002000650074002000760065007200730069006f006e007300200075006c007400e90072006900650075007200650073002e> /GRE <FEFF03a703c103b703c303b903bc03bf03c003bf03b903ae03c303c403b5002003b103c503c403ad03c2002003c403b903c2002003c103c503b803bc03af03c303b503b903c2002003b303b903b1002003bd03b1002003b403b703bc03b903bf03c503c103b303ae03c303b503c403b5002003ad03b303b303c103b103c603b1002000410064006f006200650020005000440046002003ba03b103c403ac03bb03bb03b703bb03b1002003b303b903b1002003b103be03b903cc03c003b903c303c403b7002003c003c103bf03b203bf03bb03ae002003ba03b103b9002003b503ba03c403cd03c003c903c303b7002003b503c003b903c703b503b903c103b703bc03b103c403b903ba03ce03bd002003b503b303b303c103ac03c603c903bd002e0020002003a403b10020005000440046002003ad03b303b303c103b103c603b1002003c003bf03c5002003ad03c703b503c403b5002003b403b703bc03b903bf03c503c103b303ae03c303b503b9002003bc03c003bf03c103bf03cd03bd002003bd03b1002003b103bd03bf03b903c703c403bf03cd03bd002003bc03b5002003c403bf0020004100630072006f006200610074002c002003c403bf002000410064006f00620065002000520065006100640065007200200035002e0030002003ba03b103b9002003bc03b503c403b103b303b503bd03ad03c303c403b503c103b503c2002003b503ba03b403cc03c303b503b903c2002e> /HEB <FEFF05D405E905EA05DE05E905D5002005D105D405D205D305E805D505EA002005D005DC05D4002005DB05D305D9002005DC05D905E605D505E8002005DE05E105DE05DB05D9002000410064006F006200650020005000440046002005E205D105D505E8002005D405E605D205D4002005D505D405D305E405E105D4002005D005DE05D905E005D4002005E905DC002005DE05E105DE05DB05D905DD002005E205E105E705D905D905DD002E002005DE05E105DE05DB05D90020005000440046002005E905E005D505E605E805D5002005E005D905EA05E005D905DD002005DC05E405EA05D905D705D4002005D105D005DE05E605E205D505EA0020004100630072006F006200610074002005D5002D00410064006F00620065002000520065006100640065007200200035002E0030002005D505D205E805E105D005D505EA002005DE05EA05E705D305DE05D505EA002005D905D505EA05E8002E05D905D505EA05E8002E002D0033002C002005E205D905D905E005D5002005D105DE05D305E805D905DA002005DC05DE05E905EA05DE05E9002005E905DC0020004100630072006F006200610074002E002005DE05E105DE05DB05D90020005000440046002005E905E005D505E605E805D5002005E005D905EA05E005D905DD002005DC05E405EA05D905D705D4002005D105D005DE05E605E205D505EA0020004100630072006F006200610074002005D5002D00410064006F00620065002000520065006100640065007200200035002E0030002005D505D205E805E105D005D505EA002005DE05EA05E705D305DE05D505EA002005D905D505EA05E8002E> /HRV (Za stvaranje Adobe PDF dokumenata pogodnih za pouzdani prikaz i ispis poslovnih dokumenata koristite ove postavke. Stvoreni PDF dokumenti mogu se otvoriti Acrobat i Adobe Reader 5.0 i kasnijim verzijama.) /HUN <FEFF00410020006800690076006100740061006c006f007300200064006f006b0075006d0065006e00740075006d006f006b0020006d00650067006200ed007a00680061007400f30020006d0065006700740065006b0069006e007400e9007300e900720065002000e900730020006e0079006f006d00740061007400e1007300e10072006100200073007a00e1006e0074002000410064006f00620065002000500044004600200064006f006b0075006d0065006e00740075006d006f006b0061007400200065007a0065006b006b0065006c0020006100200062006500e1006c006c00ed007400e10073006f006b006b0061006c00200068006f007a006800610074006a00610020006c00e9007400720065002e0020002000410020006c00e90074007200650068006f007a006f00740074002000500044004600200064006f006b0075006d0065006e00740075006d006f006b00200061007a0020004100630072006f006200610074002000e9007300200061007a002000410064006f00620065002000520065006100640065007200200035002e0030002c0020007600610067007900200061007a002000610074007400f3006c0020006b00e9007301510062006200690020007600650072007a006900f3006b006b0061006c0020006e00790069007400680061007400f3006b0020006d00650067002e> /ITA (Utilizzare queste impostazioni per creare documenti Adobe PDF adatti per visualizzare e stampare documenti aziendali in modo affidabile. I documenti PDF creati possono essere aperti con Acrobat e Adobe Reader 5.0 e versioni successive.) /JPN <FEFF30d330b830cd30b9658766f8306e8868793a304a3088307353705237306b90693057305f002000410064006f0062006500200050004400460020658766f8306e4f5c6210306b4f7f75283057307e305930023053306e8a2d5b9a30674f5c62103055308c305f0020005000440046002030d530a130a430eb306f3001004100630072006f0062006100740020304a30883073002000410064006f00620065002000520065006100640065007200200035002e003000204ee5964d3067958b304f30533068304c3067304d307e305930023053306e8a2d5b9a3067306f30d530a930f330c8306e57cb30818fbc307f3092884c3044307e30593002> /KOR <FEFFc7740020c124c815c7440020c0acc6a9d558c5ec0020be44c988b2c8c2a40020bb38c11cb97c0020c548c815c801c73cb85c0020bcf4ace00020c778c1c4d558b2940020b3700020ac00c7a50020c801d569d55c002000410064006f0062006500200050004400460020bb38c11cb97c0020c791c131d569b2c8b2e4002e0020c774b807ac8c0020c791c131b41c00200050004400460020bb38c11cb2940020004100630072006f0062006100740020bc0f002000410064006f00620065002000520065006100640065007200200035002e00300020c774c0c1c5d0c11c0020c5f40020c2180020c788c2b5b2c8b2e4002e> /NLD (Gebruik deze instellingen om Adobe PDF-documenten te maken waarmee zakelijke documenten betrouwbaar kunnen worden weergegeven en afgedrukt. De gemaakte PDF-documenten kunnen worden geopend met Acrobat en Adobe Reader 5.0 en hoger.) /NOR <FEFF004200720075006b00200064006900730073006500200069006e006e007300740069006c006c0069006e00670065006e0065002000740069006c002000e50020006f0070007000720065007400740065002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e00740065007200200073006f006d002000650072002000650067006e0065007400200066006f00720020007000e5006c006900740065006c006900670020007600690073006e0069006e00670020006f00670020007500740073006b007200690066007400200061007600200066006f0072007200650074006e0069006e006700730064006f006b0075006d0065006e007400650072002e0020005000440046002d0064006f006b0075006d0065006e00740065006e00650020006b0061006e002000e50070006e00650073002000690020004100630072006f00620061007400200065006c006c00650072002000410064006f00620065002000520065006100640065007200200035002e003000200065006c006c00650072002e> /POL <FEFF0055007300740061007700690065006e0069006100200064006f002000740077006f0072007a0065006e0069006100200064006f006b0075006d0065006e007400f300770020005000440046002000700072007a0065007a006e00610063007a006f006e00790063006800200064006f0020006e00690065007a00610077006f0064006e00650067006f002000770079015b0077006900650074006c0061006e00690061002000690020006400720075006b006f00770061006e0069006100200064006f006b0075006d0065006e007400f300770020006600690072006d006f0077007900630068002e002000200044006f006b0075006d0065006e0074007900200050004400460020006d006f017c006e00610020006f007400770069006500720061010700200077002000700072006f006700720061006d006900650020004100630072006f00620061007400200069002000410064006f00620065002000520065006100640065007200200035002e0030002000690020006e006f00770073007a0079006d002e> /PTB <FEFF005500740069006c0069007a006500200065007300730061007300200063006f006e00660069006700750072006100e700f50065007300200064006500200066006f0072006d00610020006100200063007200690061007200200064006f00630075006d0065006e0074006f0073002000410064006f00620065002000500044004600200061006400650071007500610064006f00730020007000610072006100200061002000760069007300750061006c0069007a006100e700e3006f002000650020006100200069006d0070007200650073007300e3006f00200063006f006e0066006900e1007600650069007300200064006500200064006f00630075006d0065006e0074006f007300200063006f006d0065007200630069006100690073002e0020004f007300200064006f00630075006d0065006e0074006f00730020005000440046002000630072006900610064006f007300200070006f00640065006d0020007300650072002000610062006500720074006f007300200063006f006d0020006f0020004100630072006f006200610074002000650020006f002000410064006f00620065002000520065006100640065007200200035002e0030002000650020007600650072007300f50065007300200070006f00730074006500720069006f007200650073002e> /RUM <FEFF005500740069006c0069007a00610163006900200061006300650073007400650020007300650074010300720069002000700065006e007400720075002000610020006300720065006100200064006f00630075006d0065006e00740065002000410064006f006200650020005000440046002000610064006500630076006100740065002000700065006e007400720075002000760069007a00750061006c0069007a00610072006500610020015f006900200074006900700103007200690072006500610020006c0061002000630061006c006900740061007400650020007300750070006500720069006f0061007201030020006100200064006f00630075006d0065006e00740065006c006f007200200064006500200061006600610063006500720069002e002000200044006f00630075006d0065006e00740065006c00650020005000440046002000630072006500610074006500200070006f00740020006600690020006400650073006300680069007300650020006300750020004100630072006f006200610074002c002000410064006f00620065002000520065006100640065007200200035002e00300020015f00690020007600650072007300690075006e0069006c006500200075006c0074006500720069006f006100720065002e> /RUS <FEFF04180441043f043e043b044c04370443043904420435002004340430043d043d044b04350020043d0430044104420440043e0439043a043800200434043b044f00200441043e043704340430043d0438044f00200434043e043a0443043c0435043d0442043e0432002000410064006f006200650020005000440046002c0020043f043e04340445043e0434044f04490438044500200434043b044f0020043d0430043404350436043d043e0433043e0020043f0440043e0441043c043e044204400430002004380020043f04350447043004420438002004340435043b043e0432044b044500200434043e043a0443043c0435043d0442043e0432002e002000200421043e043704340430043d043d044b04350020005000440046002d0434043e043a0443043c0435043d0442044b0020043c043e0436043d043e0020043e0442043a0440044b043204300442044c002004410020043f043e043c043e0449044c044e0020004100630072006f00620061007400200438002000410064006f00620065002000520065006100640065007200200035002e00300020043800200431043e043b043504350020043f043e04370434043d043804450020043204350440044104380439002e> /SLV <FEFF005400650020006e006100730074006100760069007400760065002000750070006f0072006100620069007400650020007a00610020007500730074007600610072006a0061006e006a006500200064006f006b0075006d0065006e0074006f0076002000410064006f006200650020005000440046002c0020007000720069006d00650072006e006900680020007a00610020007a0061006e00650073006c006a00690076006f0020006f0067006c00650064006f00760061006e006a006500200069006e0020007400690073006b0061006e006a006500200070006f0073006c006f0076006e0069006800200064006f006b0075006d0065006e0074006f0076002e00200020005500730074007600610072006a0065006e006500200064006f006b0075006d0065006e0074006500200050004400460020006a00650020006d006f0067006f010d00650020006f0064007000720065007400690020007a0020004100630072006f00620061007400200069006e002000410064006f00620065002000520065006100640065007200200035002e003000200069006e0020006e006f00760065006a01610069006d002e> /SUO <FEFF004b00e40079007400e40020006e00e40069007400e4002000610073006500740075006b007300690061002c0020006b0075006e0020006c0075006f0074002000410064006f0062006500200050004400460020002d0064006f006b0075006d0065006e007400740065006a0061002c0020006a006f0074006b006100200073006f0070006900760061007400200079007200690074007900730061007300690061006b00690072006a006f006a0065006e0020006c0075006f00740065007400740061007600610061006e0020006e00e400790074007400e4006d0069007300650065006e0020006a0061002000740075006c006f007300740061006d0069007300650065006e002e0020004c0075006f0064007500740020005000440046002d0064006f006b0075006d0065006e00740069007400200076006f0069006400610061006e0020006100760061007400610020004100630072006f0062006100740069006c006c00610020006a0061002000410064006f00620065002000520065006100640065007200200035002e0030003a006c006c00610020006a006100200075007500640065006d006d0069006c006c0061002e> /SVE <FEFF0041006e007600e4006e00640020006400650020006800e4007200200069006e0073007400e4006c006c006e0069006e006700610072006e00610020006f006d002000640075002000760069006c006c00200073006b006100700061002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e007400200073006f006d00200070006100730073006100720020006600f60072002000740069006c006c006600f60072006c00690074006c006900670020007600690073006e0069006e00670020006f006300680020007500740073006b007200690066007400650072002000610076002000610066006600e4007200730064006f006b0075006d0065006e0074002e002000200053006b006100700061006400650020005000440046002d0064006f006b0075006d0065006e00740020006b0061006e002000f600700070006e00610073002000690020004100630072006f0062006100740020006f00630068002000410064006f00620065002000520065006100640065007200200035002e00300020006f00630068002000730065006e006100720065002e> /TUR <FEFF005400690063006100720069002000620065006c00670065006c006500720069006e0020006700fc00760065006e0069006c0069007200200062006900720020015f0065006b0069006c006400650020006700f6007200fc006e007400fc006c0065006e006d006500730069002000760065002000790061007a0064013100720131006c006d006100730131006e006100200075007900670075006e002000410064006f006200650020005000440046002000620065006c00670065006c0065007200690020006f006c0075015f007400750072006d0061006b0020006900e70069006e00200062007500200061007900610072006c0061007201310020006b0075006c006c0061006e0131006e002e00200020004f006c0075015f0074007500720075006c0061006e0020005000440046002000620065006c00670065006c0065007200690020004100630072006f006200610074002000760065002000410064006f00620065002000520065006100640065007200200035002e003000200076006500200073006f006e0072006100730131006e00640061006b00690020007300fc007200fc006d006c00650072006c00650020006100e70131006c006100620069006c00690072002e> /ENU (Use these settings to create Adobe PDF documents suitable for reliable viewing and printing of business documents. Created PDF documents can be opened with Acrobat and Adobe Reader 5.0 and later.) >> >> setdistillerparams << /HWResolution [600 600] /PageSize [612.000 792.000] >> setpagedevice

New folder/Predicting Critical Cloud Computing Security Issues using Artificial Neural (1).pdf

ITEE, 6 (2) pp. 40-45, APR 2017

ITEE Journal Information Technology & Electrical Engineering

ISSN: - 2306-708X

Volume 6, Issue 2 April 2017

Predicting Critical Cloud Computing Security Issues using Artificial Neural

Network (ANNs) Algorithms in Banking Organizations

Abdelrafe Elzamly1, Burairah Hussin 2, Samy S. Abu Naser3, Tadahiro Shibutani4, and Mohamed Doheir5

1Department of Computer Science, Al-Aqsa University, Gaza, Palestine 2 ,5 Information & Communication Technology, Universiti Teknikal Malaysia Melaka (UTeM), Malaysia

3Department Information Technology, Al-Azhar University, Gaza, Palestine 4Institute of Advanced Sciences, Yokohama National University, Yokohama, Japan

E-mail: [email protected]

ABSTRACT The aim of this study is to predict critical cloud computing security issues by using Artificial Neural Network (ANNs) algorithms.

However, we proposed the Levenberg–Marquardt based Back Propagation (LMBP) Algorithms to predict the performance for

cloud security level. Also LMBP algorithms can be used to estimate the performance of accuracy in predicting cloud security

level. ANNs are more efficiently used for improving performance and learning neural membership functions. Furthermore, we

used the cloud Delphi technique for data gathering and analysis it in this study. In this study, the samples of 40 panelists were

selected from inside and outside Malaysian banking organizations based on their experienced in banking cloud computing.

However, we have indicated that the LMBP is nonlinear optimization models which used to measure accuracy of the prediction

model, the Mean Square Error (MSE) are measured to determine the performance. The performance is goodness, if the MSE is

small as shown in Table 1. This work has been conducted on groups of cloud banking developers and IT managers. As future

work, we intend to combine another optimal technique with ANNs algorithms to predict and mitigate critical security cloud issues.

Though, positive prediction of critical cloud security issues is going to surge the probability of cloud banking success rate.

Keywords: Cloud banking organization, Cloud Computing, Cloud Security Issues, , Artificial Neural Network, Levenberg Marquardt Algorithm,

Back Propagation Algorithm,. 1. NTRODUCTION

Although much research and progress in the area of

cloud computing project, a lot of cloud computing projects

have a very high failure rate particularly when it is related to

the banking area. However, several serious cloud security

issues like data protection and integrity, quality of

services(QoS), Portability and Interoperability, and mobility

need to be controlled and mitigated before cloud computing

able to apply adoptive widely [1]. In addition, cloud

computing has several advantages but cloud computing in

banking organizations is suffering from a lot of cloud

security issues. The aim of cloud risk management is

identification and evaluation of cloud security issues at an

early stage to predict the cloud computing security level [2].

Today, cloud computing risk management became a mutual

practice amongst leading banking organization success. In

the increasing effort to improve development processes and

security; new studies have led to cloud computing risk area.

Risk management aids software project manager and team

to do improved decisions to mitigate cloud-computing risks.

The objective of this study is predicting performance for

cloud computing security issues using Levenberg–

Marquardt based Back Propagation (LMBP) algorithms.

2. LITERATURE REVIEW

Cloud computing risk management consists of

computing processes, methods and techniques that are

useful to mitigate cloud computing risk failure. Security

risk management is increasingly becoming significant

in a diversity of areas linked to information technology

(IT), for example: telecommunications, banking

information systems, cloud computing[3]. Moreover,

the cloud banking model is a resource management

modeling founded on economic philosophies. Its

function like commercial banks in loan and deposit

business [4]. Cloud security is a general subject and any

grouping of policies, controls, and technologies to

safeguard data, services and infrastructure from

conceivable attacks. Additionally, current researches

focused on providing security technologies, instead of

business features such as services stability, availability

and continuity [5]. This study is going to predict the

critical cloud issues in Malaysian banking

organizations. Actually, they presented the conceptual

framework for cloud security banking that involved

components for example security, legal, privacy,

compliance and regulatory issues of banking [6]. As

stated by previous studies we split the framework

modeling cloud computing to five phases as mobility

and banking application, Cloud Deployment Models

(CDM), cloud risk management models (CRMM),

Cloud Service Models (CSM), and cloud security model

(CSM) as follows: Firstly, mobility related to the

possibility of moving and taking place in diverse

locations and through multiple times using any kind of

portable devices like smart phones, Personal Digital

Assistants (PDAs) and wireless laptops. Nonetheless,

mobile banking related to any operation that linked to

banking services like balance check, payments and

receiving banking SMS via a mobile device, and

account transactions [7]. Secondly, CSM depend on

http://www.google.ps/url?sa=t&rct=j&q=utem&source=web&cd=1&cad=rja&sqi=2&ved=0CCYQFjAA&url=http%3A%2F%2Fwww.utem.edu.my%2F&ei=RijMUb5hk5OFB4icgdgP&usg=AFQjCNFlZUFAE2tsaeL4BcNGkSqnLEqnSw&bvm=bv.48340889,d.Yms

ITEE, 6 (2) pp. 40-45, APR 2017

ITEE Journal Information Technology & Electrical Engineering

ISSN: - 2306-708X

Volume 6, Issue 2 April 2017

some state of the art of web technologies like

Application Programming Interface (API), Web

Services, Web 2.0, and etc. [8]. Also, CSM is split into

four categories that are offered from a cloud provider:

Software as a Service (SaaS), Platform as a Service

(PaaS), Banking Process as a Service (BPaaS), and

Infrastructure as a Service (IaaS). Thirdly, CDM can be

split into four dissimilar types: Public cloud is made

obtainable to the general public or a huge industry group

and are possessed by a third party selling cloud services

[9]. Private Cloud is functioned and possessed by a

single organization or company that focuses on

controlling the mechanism of virtualizing resources and

automating services those are used and tailored by many

lines of business and essential groups [4]. Community

cloud falls among public and private clouds with regard

to the target set of consumers [10]. Community cloud,

this model is used by a specific group of community

within an organization that has the same worry,

objectives or security necessities [11]. Hybrid cloud

uses both public and private cloud methods, where it

smears the strategic notions of the services of public

cloud with the basis of the private cloud. Fourthly,

Cloud Risk Management (CRM): in Cloud computing,

risk required to be taken into consideration in all phases

of interactions and investigated at every service stage in

relation to the possessions that should be protected [12].

Besides, there are diverse types of risks that bank

management should be protected against. For numerous

banks, the main risk is credit risk but there are several

other risks that supervising authorities must notify

banks about connected criteria and require them to

follow [13]. There are eight phases for effective cloud

risk management like Cloud Risk Planning Phase

(CRPL), Cloud Risk Analysis (CRA) phase, Cloud Risk

Identification(CRI) phase, Cloud Risk

Prioritization(CRP) phase, Cloud Risk

Evaluation(CRE) phase, Cloud Risk Treatment(CRT)

phase includes four strategies for responding to cloud

risks: cloud risk mitigation, cloud risk avoidance, cloud

risk transfer, cloud risk elimination, cloud risk

acceptance, Cloud Risk Controlling(CRC) phase, and

Cloud Risk Communication & Documentation (CRCD)

phase. Finally, Cloud Security Issues Models (CSIM):

cloud security is a very common topic and any grouping

of policies, technologies, and controls to protect data,

infrastructure and services from possible attacks or

achieving business objectives all the security domains

should work in an effective manner [14].

3. CLOUD SECURITY ISSUES

Though, classification of critical security issues in

cloud banking is needed to be highlighted in this section

[15]: 3rd Party (Providers) and Policies Security Issues:

Lack of standards, Service Level Agreement (SLAs),

Governance, Legally and policy, Dependency, Lack of

transparency, Cloud service provider viability,

Malicious insiders, Regulatory compliance &

requirements, Shared technology issues, Unknown risk

profile, Trusted cloud, Abuse cloud computing;

Application and program (software) security issues:

Authentication, Authorization, Insecure Interfaces

API’s, Availability and Mobility, Portability and

Interoperability; Data and Information Security Issues:

Privacy, Confidentiality, Data Protection, Data

Limitations and Segregation, Data integrity and

scavenging, Data Location, Data Loss/Leakage,

Detection and Recovery, Hijacking of Account or

Service & Traffic; Security Control & Network Issues:

Information flow Controlling, Intrinsic Constrains of

Wireless Network, Network Access Schemes,

Bandwidth, Anonymity and Network Traffic Analysis,

Network Security, Virtual Network Protection, Limited

control, Distributed Denial of Service (DDoS),

Heterogeneity in Mobile cloud Devices, Platform

Reliability and Latency; Security and Service

Management Issues: Session Management,

Identity/Access Management, Quality of Service (QoS),

IT organizational changes; Physical Infrastructure

Security Issues: Flexibility Infrastructure, Single Point

to Attack and Failure, High-value cyber-attack targets,

the multi-tenancy, Scalability, Cost.

4. EMPIRICAL STRATEGY

The Delphi technique use to collect data as

qualified informants, so we focused on two cloud

developers groups and cloud IT managers in banking

organizations. In this regard the Delphi study is

modified to three phases like identifying, analyzing, and

evaluating as described in Figure 1. The data are

collected by secondary data and Delphi study. In current

study, the population samples of forty panelists were

chosen from inside and outside Malaysian banking

organizations according to their experienced in cloud

banking. Actually, we measure the probability of

occurrence according to a 10 scales (1= “very low

probability of occurrence risk” and 10 = “very high

probability of occurrence risk”), and the brutality of the

cloud security issues described on a 10 scales (1= “very

low influence risk” and 10 = “very high impact risk”.

Actually, we used Delphi techniques for data gathering

and analysis it in this study. However, we will begin a

list of cloud security issues based on secondary data,

experienced of cloud managers and cloud developers.

The Delphi method is collected data and aggregated of

cloud security issues. In fact, we divided the phases of

cloud Delphi technique into three phases such as

identifying, analyzing, and evaluating. However, we

illustrate the concept of Delphi technique for identifying

and classifying cloud security issues in Figure 1 as

follows:

Cloud Delphi Technique

Phase 1: Identifying  Collected data and aggregated of cloud

security issues.

 Select the experts from both inside and outside

the banking organization.

 Divide panelist to two groups cloud

ITEE, 6 (2) pp. 40-45, APR 2017

ITEE Journal Information Technology & Electrical Engineering

ISSN: - 2306-708X

Volume 6, Issue 2 April 2017

Figure 1: Illustrates the steps of cloud Delphi study of

collecting data [16]

5. METHODOLOGY (MATERIALS &

METHODS)

However, the data gathered for this study to be used

in the modelling is getting from the managers and cloud

developers in banking organizations. We propose

Artificial Neural Network (ANNs) for predicting cloud

security issues in banking organizations. In order to

manage and predict performance of cloud computing

security level, we can use artificial neural networks

methods. In order to establish the intelligent approaches,

first we need to model the relationship between cloud

computing issues. In addition, artificial neural networks

modelling are used as nonlinear statistical data model to

predict cloud-computing issues. Of course, IT managers

and cloud developers must use practical approaches,

methods, and tools to predict cloud security issues in

banking organization. Indeed, the back-propagation

algorithm is used in layered feed- forward ANNs where

the artificial neurons are structured in layers, and lead

their signals “forward”, and then the errors are

transmitted backwards. The neural network gets input

from input layers and yields the output to the output

layer and the processing can be done in hidden layers.

There must be only one input and output layer, however,

there may be an arbitrary number of hidden layers [17-

19]. Additionally, the BP algorithm should minimize

these errors, till the ANN learns the training data.

Typically the training initiates with random weights,

and the learning objective is to modify them so that the

error is reduced [17-19]. The design of procedures for

predicting cloud security issues using Levenberg-

Marquardt (LM) Based Back Propagation (BP)

Algorithm as follows:

1. Collect and prepare the data for cloud security issues based on Cloud Delphi Technique.

2. Assign an estimated probability of occurrence and severity of cloud security issues based on

security models.

3. Build a network analysis 4. Train the network: It generates the neural

network from a Cloud Delphi dataset with

known output data cases.

5. Test the network: A trained neural networks are used to test how well it does at prediction of

known and new output values.

6. Predict cloud security issues based models by using artificial neural networks for evaluating

the performance impact of CSI. A trained neural

network is used to predict unknown output

value.

6. RESULTS AND DISCUSSION

Indeed, we used the Levenberg–Marquardt based

Back Propagation (LMBP) Algorithms, as nonlinear

optimization to predict the performance. So we illustrate

the mean square error and Regression (R) values for the

Training, Validation and Testing as in Table 1.

Table 1 Illustrates the MSE and Regression values for the

three types Types Samples Training

data

(input)%

MSE R

Training 28 70% 4.94160×e-7 9.95213×e-1

Validation 6 15% 8.75807×e-6 9.79262×e-1

Testing 6 15% 1.95378×e-5 9.49600×e-1

Table 1 shows that the overall Mean Square Error

which measure the average squared errors between the

output data and targets data and Regression (R) which

measure correlation between the actual outputs data and

targets data for training, validation and testing samples.

The accuracy of prediction is observed, when the values of

R are closest to 1. Hence, if the dataset was trained by using

(LMBP) Algorithms, the performance obtained was in 3 epochs with 10 hidden neurons yields. The results indicated

that the LMBP algorithms are very efficiently for testing and

training networks. Although, a two-layered feed forward

network hidden neurons and networks are trained using

LMBP Algorithms as shown in Figure 2.

ITEE, 6 (2) pp. 40-45, APR 2017

ITEE Journal Information Technology & Electrical Engineering

ISSN: - 2306-708X

Volume 6, Issue 2 April 2017

Figure 2 architecture and algorithms and progress of ANN

system

Figure 3 Performance of LMBP Algorithm (MSE vs.

Epochs)

Figure 4 error histogram with 20 bins based LMBP

Indeed, it is trained to measure the performance of networks

by using LMBP algorithms in Matlab R2013b.

Furthermore, we estimated the best validation performance

0.0000087581 at epoch 3 in Figure 3 and the error histogram

with 20 bins is illustrated in Figure 4. Therefore, regression

R values are measured the correlation between outputs and

targets. Hence, the results in the regression analysis plot are

perfect correlation between the outputs and targets as in

Figure 5. In addition, the one mean a close relation between

outputs and targets, zero a random relationship. LMBP is

nonlinear optimal models which used to measure accuracy

of the prediction model, the Mean Square Error (MSE) are

measured to determine the performance. The performance is

goodness, if the MSE is small.

Figure 5 Regression Analysis Plot - Levenber g-Marquardt

Backpropagation Algorithm

7. CONCLUSIONS

The concern of the study is to predict critical cloud

computing security issues using Artificial Neural

Network (ANNs) algorithms. However, we presented

the Levenberg–Marquardt based Back Propagation

(BP) Algorithms to predict the performance for cloud

security level. Also LMBP algorithm is applied to

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5

10 -10

10 -5

Best Validation Performance is 8.7581e-06 at epoch 3

M e

a n

S q

u a

r e

d E

r r o

r (m

s e

)

5 Epochs

Train

Validation

Test

Best

Error Histogram with 20 Bins

In s

ta n

c e

Errors = Targets - Outputs

-0 .0

0 4 9

-0 .0

0 4 1 8

-0 .0

0 3 4 5

-0 .0

0 2 7 2

-0 .0

0 2

-0 .0

0 1 2 7

-0 .0

0 0 5 5

0 .0

0 0 1 8 1

0 .0

0 0 9 0 7

0 .0

0 1 6 3 2

0 .0

0 2 3 5 8

0 .0

0 3 0 8 4

0 .0

0 3 8 1

0 .0

0 4 5 3 6

0 .0

0 5 2 6 2

0 .0

0 5 9 8 8

0 .0

0 6 7 1 4

0 .0

0 7 4 4

0 .0

0 8 1 6 6

0 .0

0 8 8 9 2

Training

Validation

Test

Zero Error

0.65 0.66 0.67 0.68 0.69 0.65

0.655

0.66

0.665

0.67

0.675

0.68

0.685

0.69

Target

O u

tp u

t ~

= 0

.9 7

* T

a r g

e t

+ 0

.0 2

Training: R=0.99521

Data

Fit

Y = T

0.65 0.66 0.67 0.68 0.69 0.65

0.655

0.66

0.665

0.67

0.675

0.68

0.685

0.69

Target

O u

tp u

t ~

= 1

.2 * T

a r g

e t

+ -

0 .1

Validation: R=0.97926

Data

Fit

Y = T

0.65 0.66 0.67 0.68 0.69 0.65

0.655

0.66

0.665

0.67

0.675

0.68

0.685

0.69

Target

O u

tp u

t ~

= 1

.3 * T

a r g

e t

+ -

0 .2

Test: R=0.9496

Data

Fit

Y = T

0.65 0.66 0.67 0.68 0.69 0.65

0.655

0.66

0.665

0.67

0.675

0.68

0.685

0.69

Target

O u

tp u

t ~

= 1

.1 * T

a r g

e t

+ -

0 .0

4 1

All: R=0.9596

Data

Fit

Y = T

ITEE, 6 (2) pp. 40-45, APR 2017

ITEE Journal Information Technology & Electrical Engineering

ISSN: - 2306-708X

Volume 6, Issue 2 April 2017

estimate and test the performance of accuracy for

predicting cloud security level. ANNs are more

efficiently used for improving performance and learning

neural membership functions. Indeed, the performance

of cloud security is analyzed by using LMBP to give the

best performance in the predicting models.

Furthermore, we used the cloud Delphi technique for

data gathering and analyzing it in this study. In this

study, the samples of 40 panelists were selected from

inside and outside Malaysian banking organizations based on their experienced in banking cloud computing.

However, we have indicated that the LMBP is nonlinear

optimal models which used to measure accuracy of the

prediction model and to reduce the error between the

actual outputs and targets for training process, the Mean

Square Error(MSE) are measured to determine the

performance. The performance is goodness, if the MSE

is small as shown in Table 1. As future work, we intend to use another optimal technique with Artificial Neural

Network algorithms to predict and mitigate critical

security cloud issues.

8. Acknowledgements

This work is organized by the Welfare Association in

Palestine; financially supported by the Arab Monetary

Fund, and Bank of Palestine under the program name

(Academic Fellowship Program Zamalah). The authors

also would like to thank Al-Aqsa University, Gaza,

Palestine and Faculty of Information & Communication

Technology, Universiti Teknikal Malaysia Melaka

(UTeM), Malaysia.

References

[1] D. Hoang and L. Chen, “Mobile Cloud for Assistive

Healthcare (MoCAsH),” in 2010 IEEE Asia-Pacific

Services Computing Conference Mobile, (2010), pp.

325–332.

[2] J. Miler and J. Górski, “Supporting Team Risk

Management in Software Procurement and

Development Projects,” in 4th National Conference

on Software Engineering, (2002), pp. 1–15.

[3] J. Mounzer, T. Alpcan, and N. Bambos, “Integrated

Security Risk Management for IT-Intensive

Organizations,” in 2010 Sixth International

Conference on Information Assurance and Security,

(2010), pp. 329–334.

[4] H. Li, Y. Pu, and J. Lu, “A Cloud Computing

Resource Pricing Strategy Research-based on

Resource Swarm Algorithm,” in 2012 International

Conference on Computer Science and Service

System, (2012), pp. 2217–2222.

[5] Z. Gao, Y. Li, H. Tang, and Z. Zhu, “Management

Process Based Cloud Service,” in International

Conference on Cyberspace Technology (CCT 2013),

(2013), pp. 278–281.

[6] M. Alemu and A. Omer, “Cloud Computing

Conceptual Security Framework for Banking

Industry,” J. Emerg. Trends Comput. Inf. Sci., vol.

5, no. 12, pp. 921–930, (2014).

[7] A. Alzahrani, N. Alalwan, and M. Sarrab, “Mobile

Cloud Computing: Advantage, Disadvantage and

Open Challenge,” in Proceedings of the 7th Euro

American Conference on Telematics and

Information Systems, (2014), pp. 4–7.

[8] E. Aruna, A. Shri, and A. Lakkshmanan, “Security

Concerns and Risk at Different Levels in Cloud

Computing,” in 2013 International Conference on

Green Computing, Communication and

Conservation of Energy (ICGCE), (2013), pp. 743–

746.

[9] K. Beckers, J.-C. Kuster, H. Schmidt, and S.

Faßbender, “Pattern-Based Support for Context

Establishment and Asset Identification of the ISO

27000 in the Field of Cloud Computing,” in 2011

Sixth International Conference on Availability,

Reliability and Security Pattern-Based, (2011), pp.

327–333.

[10] S. Goyal, “Public vs Private vs Hybrid vs

Community-Cloud Computing: A Critical Review,”

International Journal of Computer Network and

Information Security, vol. 6, no. 3. pp. 20–29,

(2014).

[11] A. Khrisna and Harlili, “Risk Management

Framework with COBIT 5 and Risk Management

Framework for Cloud Computing Integration,” in

2014 International Conference of Advanced

Informatics: Concept, Theory and Application

(ICAICTA) Risk, (2014), pp. 103–108.

[12] M. Kiran, M. Jiang, D. Armstrong, and K. Djemame,

“Towards a Service Lifecycle based Methodology

for Risk Assessment in Cloud Computing,” in 2011

Ninth IEEE International Conference on

Dependable, Autonomic and Secure Computing,

(2011), pp. 450–457.

[13] M. Ahmadalinejad and S. Hashemi, “A National

Model to Supervise on Virtual Banking Systems

through the Bank 2 . 0 Approach,” ACSIJ Adv.

Comput. Sci. an Int. J., vol. 4, no. 1, pp. 83–93,

(2015).

[14] F. Al-anzi, S. Yadav, and J. Soni, “Cloud

Computing: Security Model Comprising

Governance, Risk Management and Compliance,”

in 2014 International Conference on Data Mining

and Intelligent Computing (ICDMIC), (2014), pp.

1–6.

[15] A. Elzamly, B. Hussin, S. A. Naser, K. Khanfar, M.

Doheir, A. Selamat, and A. Rashed, “A New

Conceptual Framework Modelling for Cloud

Computing Risk Management in Banking

Organizations,” Int. J. Grid Distrib. Comput., vol. 9,

no. 9, pp. 137–154, (2016).

[16] A. Elzamly, B. Hussin, and B. ASH, “Classification

of Critical Cloud Computing Security Issues for

Banking Organizations: A Cloud Delphi Study,” Int.

J. Grid Distrib. Comput., vol. 9, no. 8, pp. 137–158,

(2016).

ITEE, 6 (2) pp. 40-45, APR 2017

ITEE Journal Information Technology & Electrical Engineering

ISSN: - 2306-708X

Volume 6, Issue 2 April 2017

[17] B. Ibrahim and A. Shanavas, “An Approach to

Predict SOA Security Vulnerabilities using Feed

Forward Artificial Neural Networks,” SIJ Trans.

Comput. Networks Commun. Eng., vol. 3, no. 4, pp.

54–58, (2015)

[18] S. Abu Naser, "Predicting learners performance

using artificial neural networks in linear

programming intelligent tutoring system."

International Journal of Artificial Intelligence &

Applications vol. 3, no. 2, pp.65-73, (2012) .

[19] S. Abu Naser, et al. "Predicting Student Performance

Using Artificial Neural Network: in the Faculty of

Engineering and Information Technology."

International Journal of Hybrid Information

Technology, vol. 8 no. 2, 221-228,(2015)

Authors’ information

Abdelrafe Elzamly, He got a Ph.D.

in Information and Communication

Technology from the Technical

University Malaysia Melaka (UTeM)

in 2016 with a record of about 20

publications. He received his Master

degree in Computer Information

Systems from the University of Banking and Financial

Sciences in 2006. He received his B.Sc. degree in Computer

from Al-Aqsa University, Gaza in 1999. He is currently

working as Assistant Professor in Al-Aqsa University as a

full time. Also, from 1999 to 2007 he worked as a part time

lecturer at the Islamic University in Gaza. Between 2010 and

2012 he worked as a Manager in the Mustafa Center for

Studies and Scientific Research in Gaza. His research

interests are in risk management, software and information

systems engineering, cloud computing security, and data

mining.

Burairah Hussin, He received his

Ph.D. degree in Management

Science-Condition Monitoring

Modelling, from the University of

Salford, UK in 2007. Before that, he

received a M.Sc. degree in

Numerical Analysis and

Programming from the University of Dundee, UK in 1998

and a B.Sc. degree in Computer Science from the University

of Technology Malaysia in 1996. He currently works as a

Professor at the Technical University Malaysia Melaka

(UTeM). He also worked as the Dean at the Faculty of

Information and Communication Technology, Technical

University of Malaysia Melaka (UTeM). His research

interests are in data analysis, data mining, maintenance

modelling, artificial intelligence, risk management,

numerical analysis, and computer network advising and

development.

Samy Abu Naser, He got a Ph.D. in

Computer Science from North

Dakota State University, USA in

1993. He received his M.Sc. Degree

in Computer Science from Western

Kentucky University, USA in 1989.

He received his B.Sc. Degree in

Computer Science from Western

Kentucky University, USA in 1987. He is currently working

as a professor in Al-Azhar University, he worked as the

Dean of the Faculty of Engineering and Information

Technology in AL-Azhar University, he worked as Deputy

Vice President for Planning & Quality Assurance, and he

worked as a deputy dean of the Faculty of Engineering and

Information Technology in Al- Azhar University. His

research interests are in data mining, artificial intelligent,

and risk management.

Tadahiro Shibutani, He received

the Ph.D. degree in mechanical

engineering from Kyoto

University, Kyoto, Japan, in 2000.

He was a Visiting Scholar with the

Center of Advanced Life Cycle

Engineering, University of

Maryland, in 2007. He is currently Associate Professor of

Center for Creation of Symbiosis Society with Risk with

Yokohama National University, Yokohama, Japan. His

research interests include physics of failure, health

monitoring, and risk management for engineering systems.

Mohamed Doheir, He is currently a

PhD candidate in Health Care

Management in University Technical

Malaysia Malaka (UTeM). He

received his M. Sc. degree in Internet

working Technology from University

Technical Malaysia Malaka (UTeM) in

2012. He received his B.Sc. Degree in Educational

Computer Science from Al Aqsa University- Gaza, Palestine

in 2006. His research interests are in Health care, Cloud

Computing and Network Simulation.

New folder/Securing Cloud via Serverless Design Patterns.pdf

Go Serverless: Securing Cloud via Serverless Design Patterns

Sanghyun Hong∗

University of Maryland Abhinav Srivastava

Frame.io William Shambrook

Frame.io Tudor Dumitras,

University of Maryland

Abstract Due to the shared responsibility model of clouds, ten- ants have to manage the security of their workloads and data. Developing security solutions using VMs or con- tainers creates further problems as these resources also need to be secured. In this paper, we advocate for tak- ing a serverless approach by proposing six serverless de- sign patterns to build security services in the cloud. For each design pattern, we describe the key advantages and present applications and services utilizing the pattern. Using the proposed patterns as building blocks, we intro- duce a threat-intelligence platform that collects logs from various sources, alerts malicious activities, and takes ac- tions against such behaviors. We also discuss the limi- tations of serverless design and how future implementa- tions can overcome those limitations.

1 Introduction

Cloud providers such as Amazon Web Services (AWS), Microsoft Azure, and IBM Cloud offer a shared respon- sibility model when it comes to security in the cloud. In this model, the cloud provider manages the security of the physical infrastructure and hypervisors; the tenants are responsible for the security of resources, workloads, and data. Given that security is one of the leading con- cerns in the broader adoption of cloud computing, cloud providers offer many security services to help tenants meet their security and compliance requirements. To this end, providers offer services such as vulnerability scan- ning, configuration change detection, and stateful fire- walls to protect tenant resources and critical workloads.

While these cloud security services help tenants to some extent, tenants still have to go through the tedious process of developing security automation, misuse detec- tion, intrusion detection, virus scanning, etc., before they execute their code securely in the cloud. Developing this

∗This work has been performed during the internship at Frame.io.

security infrastructure using VMs or containers exacer- bate the problem as now these resources require simi- lar protection themselves. Serverless architecture helps solve this last mile problem.

Serverless architecture, aka Function-as-a-Service (FaaS), simplifies the code deployment and eliminates the need for system administration, allowing developers to focus on the core security logic without creating addi- tional overhead by instantiating resources such as VMs or containers in the monitoring infrastructure. In this programming model, developers execute their logic in the form of functions and submit to the cloud provider to run the task in a shared runtime environment; cloud providers manage the scalability needs of the function by running multiple functions in parallel. Due to the sim- plicity and ease of deployment, many serverless archi- tecture has been proposed [27, 29, 33, 35, 39, 41]. While the past works focus on the design, implementation, and security of serverless architecture itself [4], in this work, we focus on how serverless architecture can help cloud developers and security operation personnel to develop a variety of security services in a scalable manner by ad- hering to simple design patterns.

Based on our extensive experience in developing serverless applications, we have identified six design pat- terns for serverless architectures: periodic invocation, event-driven, data transformation, data streaming, state machine, and bundling multiple patterns (Sec. 2). These design patterns allow developers to create many security services such as virus scanning, compliance checking, and incident response. For each pattern, we discuss: 1) how the design pattern is composed, 2) what are the ad- vantages compared to non-serverless designs, and 3) pro- vide examples of a few services that the pattern can help build. Using the fundamental patterns as building blocks, we also propose a threat-intelligence platform for the cloud that analyzes many data sources, generates alerts on suspicious activities and automatically takes respon- sive actions to recover from attacks (Sec. 3).

At the end, we discuss the limitations of current serverless architecture and how future research can over- come those limitations (Sec. 4). By sharing these design patterns with the wider research and development com- munity, we hope to encourage others to develop more se- curity applications using serverless architecture and ex- plore similar serverless design patterns in other areas.

1.1 AWS Lambda To focus our attention on one specific serverless archi- tecture, we only consider AWS Lambda [16] in the rest of this paper. AWS Lambda supports various runtime en- vironments, e.g., Python, Node.js, Java, Go, or C#, and is tightly integrated with the rest of the AWS ecosystem. Lambda functions have many advantages compared to the conventional server-oriented architectures such as:

• Deployment: The speed at which developers can go from code to executing it is much faster than using servers such as VMs or containers.

• Scalability: The Lambda allows thousands of concur- rent executions of a function out of the box, without any operational overhead to the cloud developers.

• Cost: Unlike traditional architectures using servers, where we need to pay for the running time of an in- stance, we only pay for the time when the code is exe- cuted by a Lambda.

• Integrations: Lambda can subscribe to various event sources such as CloudWatch [7], S3 [19], API Gate- way [5], SNS [10], and Kinesis [9].

• Stateless: Lambda functions are stateless, which pro- vides the simplicity in implementing security systems such as data analytic services that process records in- dividually. However, some security services, e.g., fire- walls, are stateful, thus, to implement such service us- ing Lambda will require an external database to main- tain states.

1.2 AWS Lambda Security To provide security services using serverless design pat- terns, Lambda functions that facilitate serverless archi- tecture should be secure. As securing the services run- ning in the cloud follows the shared responsibility model, cloud providers ensure the security of a shared run- time environment and provide primitives that back the Lambda functions, whereas customers are responsible for securing their functions by using those resources.

Cloud Providers. Service providers are likely to have motivations and resources to invest heavily in the secu- rity of their infrastructure. A motivated attacker, for ex-

ample, can attempt to break into a host operating sys- tem (OS) or shared runtime environment to install mal- ware that monitors Lambda functions. To thwart such attacks, providers deploy state-of-the-art intrusion detec- tion and prevention systems [31]. Nevertheless, instead of compromising a host OS, an attacker can establish side-channels [44,45] to eavesdrop a user’s sensitive data being processed by a Lambda. For such cases, cloud providers utilize hardware-based solutions, e.g., Intel SGX [26, 32], that enable safe executions of Lambda functions with the compromised host OS or runtime. In addition, providers limit the execution time of Lambda functions for few minutes to make it difficult for attack- ers to probe and establish such channels. Customers. Securing the code running in a Lambda and the data coming in/out of the function is the responsi- bility of customers. Attackers have motivations to mod- ify users’ Lambda functions or eavesdrop the communi- cation between a Lambda function and data storage to steal customers’ sensitive information. Customers, for instance, can use access control policies such as AWS IAM [20] that provide temporary credentials for Lambda functions to communicate with other services and AWS key management service (KMS) to encrypt their secrets, making it harder for attackers to access the credentials. However, not all the attack scenarios are covered by these services, e.g., an attacker can utilize the vulnerabilities in a customer’s code or perform man-in-the-middle at- tacks by inserting malicious contents to Lambda mes- sages. In such cases, tenants can utilize other security products such as JSON web tokens (JWTs) to strengthen their Lambda functions. In Sec. 4, we further discuss improving the security of a Lambda.

2 A Taxonomy of Serverless Design Patterns

In this section, we introduce a taxonomy of serverless design patterns that we realize using Lambda and primi- tives provided by AWS. We categorize serverless design patterns into six groups: 1) periodic invocation, 2) event- driven, 3) data transformation, 4) data streaming, 5) state machine, and 6) bundled pattern. We also discuss how these patterns can be used to build various security ser- vices.

2.1 DP1: Periodic Invocation Pattern A periodic invocation design pattern (see Figure 1) repre- sents the kind of models that invokes Lambda functions periodically by using schedulers such as cron in Unix op- erating systems or CloudWatch monitoring service [7]. Each Lambda function carries out a simple task and re- ports the execution results to notification channels such as asynchronous message buses or emails. For instance,

Figure 1: Periodic invocation pattern (DP1).

we can archive the data not accessed for an extended pe- riod of time into long-term backup storage, such as AWS cold storage service called Glacier, by using a Lambda function that scans the data using the LRU manner and copies them to the cold storage. The periodic invocation approach also allows cloud tenants to build applications that provide continuous compliance as required by sys- tem and organization controls (SOC2) [3] or cloud secu- rity alliance (CSA) [1]. Those applications periodically check the compliance status of resources, e.g., if any VM is subscribed to a security group that has SSH port open to all IPs (0.0.0.0/0). The compliance status is stored in a data store for later viewing and auditing purposes.

2.2 DP2: Event-Driven Pattern An event-driven design pattern, as described in Figure 2, is where a set of Lambda functions subscribe to events from cloud resources, such as accessing files in the object store or updating a table in the database. These events trigger the execution of the subscribed Lambda function passing the necessary context. Unlike the periodic invo- cation pattern, the event-driven approach can reduce the latency between the occurrence of events and the action taken by the invoked Lambda. For example, cloud ten- ants can implement an anti-virus application for the S3 object store that performs the virus scanning of uploaded files to S3 [42]. Once the file-upload event occurs, S3 in- vokes corresponding Lambda function that removes the malicious files based on its virus scanning results. In another use case, we can implement layer-7 intrusion de- tection systems by attaching Lambda functions to appli- cation load balancers [11]. Given that all web connec- tions are terminated at the load balancer, a Lambda func- tion, ingesting load balancer logs, has complete visibil- ity of incoming requests. We can perform two types of detections at the Lambda: 1) signature-based detection that identifies attacks such as SQL injection or cross-site scripting (XSS), and 2) anomaly-based detections that isolate malicious web requests, deviating from the nor-

Figure 2: Event-driven pattern (DP2).

Figure 3: Data transformation pattern (DP3).

mal behavior. The event-based design pattern has sev- eral advantages: 1) it minimizes the cost by invoking the Lambda function only when an event occurs, and 2) Lambda functions scale automatically based on the num- ber of events, providing a scalable design.

2.3 DP3: Data Transformation Pattern The ETL (extract-transform-load) data processing pipelines usually require three steps: 1) extract data from a data source, 2) transform data by using frame- works such as Apache Spark [25] or Flink [23], and 3) load the transformed data into a database. Realizing these ETL pipelines into the cloud environment presents several problems: it requires persistent execution of VMs or containers to process incoming data, and the data transformation code is not easy to update once deployed because it requires pausing the input data streams.

Using Lambda-based architecture, as shown in Fig- ure 3, solves these issues. The data processing tasks can be implemented as Lambda functions, and when the data is available, those Lambda functions perform transfor- mations and store the results. Lambda functions are not required to run persistently when there is no data, and it is quite easy to update a processing pipeline by only modifying target Lambda functions and redeploying it on the fly. Data processing pipelines that utilize Lambda functions provide various advantages in security because many security applications require data enrichment or change in the data format for further analysis. For ex- ample: suppose that we want to append the geolocations of IP addresses in incoming network packets using Max- Mind GeoIP Database [36]. In non-serverless data pro- cessing pipelines, we first store the original packets in a database, extract only IP fields from the stored data, and update the data in the database with the geolocation information. However, with the Lambda-based transfor- mation patterns, we can enrich the incoming data on the fly as it is available using Lambda, which does not de- mand any other database or data processing framework. In another example, Lambda functions can transform the data into the Apache Parquet [24] on the fly, which is a columnar structure [22], reducing the cost and query processing time of Amazon Athena [6].

Figure 4: Data streaming pattern (DP4).

2.4 DP4: Data Streaming Pattern

In the data streaming design pattern (see Figure 4), a Lambda function sits in the path of data stream and func- tions either as an aggregator or data partitioner. For ex- ample, a lambda can separate an incoming data-stream into multiple small streams (partition) or merge several incoming streams into one large data-stream (aggrega- tion). This partitioning functionality also helps Lambda act as a load balancer, which divides the data into many streams of the same size and transfer to multiple stream- ing services based on the size of incoming streams.

A data streaming pattern is useful to filter events from the data stream. For instance, we want to be notified im- mediately if an internal cloud API is invoked from mali- cious IP addresses. Unlike the traditional designs that re- quire the deployment of another data processing pipeline, we deploy a Lambda function in the API processing path, filter the request using IP addresses, and gener- ate alerts indicating whether there is suspicious traffic or not. Many ChatOps solutions such as Slack [40] provide seamless integrations with the programming languages used by Lambda, which makes it easier to receive secu- rity notifications.

2.5 DP5: State Machine Pattern

The state machine pattern in Figure 5 enables building a complex, stateful procedure by coordinating a collec- tion of discrete Lambda functions using a tool such as AWS Step Functions. This pattern provides several ad- vantages: 1) customers are not required to store states to cloud storage since Step Functions manage them seam- lessly and 2) do not need to scale entire pattern as tasks

Figure 5: State machine pattern (DP5). Note that we ex- tended data transformation pattern with a state machine.

Figure 6: Bundled pattern (DP6).

defined for each state can be scaled-up/down individu- ally.

As an example, in Figure 5, we make the data stream- ing pattern more stable by using a state machine. With a single Lambda function, a failure in delivering a batch of streaming data means the data will be lost, which could be the serious problem in security monitoring ser- vices. On the other hand, this state machine pattern can deal with this problem; the failure state from the data- processing Lambda function invokes another Lambda which tries the same request again until it succeeds. In addition, the state machine offers a try/catch mechanism so that we can invoke different functions depending on the failure reason.

2.6 DP6: Bundled Pattern The bundled pattern combines two or more of the pre- viously described patterns together by easily passing events sequentially between them. Conceptually, this is very much like UNIX pipelines, where each function is small, precise and does one thing, but the great power comes from chaining these together. As proposed in Fig- ure 6, a collection of functions forms a data processing pipeline, which combines the data-driven pattern (DP2) with the data streaming pattern (DP4).

2.7 Cost and Scalability Analysis Due to the time-bound execution (see Sec. 4), long dura- tion tasks are difficult to run by a Lambda function. In addition, for tasks that require short latency (5-10ms), the non-serverless architectures consisting of VMs or containers are better suited because the time to start a Lambda function (50-100ms) is significantly higher than that of running a VM or container [29]. Thus, when we compare the cost and scalability of serverless and non- serverless architecture, we consider tasks with the run- ning time between 100ms and 5min and expected latency between 50-100ms.

Cost Analysis. The task is to process load balancer logs, streaming 200 requests per minute, where each request has 5000 log entries, i.e., 1 million log entries per minute. If we use a Lambda function with 256Mb memory (suf- ficient to process this workload in memory) running 1 seconds for each request, it costs $37.74/month based on Lambda pricing [14]. However, once we serve requests

Figure 7: Proposed threat intelligence platform: the boxes with dashed-lines indicate what design pattern is used.

using 2 EC2 instances of the m5.large type equipped with 2CPUs and 8Gb memory [13], we need to pay $138.24/month1 In this case, the serverless implementa- tion is a lot cheaper than the non-serverless architecture. In addition, if the load is unpredictable and irregular, the cost of running instances can be a lot more than Lambda functions since the minimum number of containers or VMs are always required to run. However, if the Lambda function has to run one minute for each request, since the number of log entries per request is increased from 5,000 to 300,000 with the same configuration, the cost is $2,162.16/month, whereas the instances cost $138.24 (the same), which makes Lambda very expensive for the long-running tasks. The additional cost that we need to consider is the operational cost, which is not reflected in the above numbers. Lambda is a managed service that requires minimum administration and efforts to scale- up/down whereas containers and VMs are required to be configured with these scaling options. This saves time and effort of customers who operate large-scale infras- tructures for security services.

Scalability Analysis. Both non-serverless and serverless architecture can be scaled-up/down well with the regu- lar and predictable loads. However, with unpredictable loads, serverless patterns have better scalability as they can release the resources when there is no running task.

3 Serverless Threat-Intelligence Platform

To illustrate how these individual design patterns, as de- scribed in Sec. 2, can be combined to build security ser- vices, we propose a threat-intelligence platform that an- alyzes various data sources in the cloud, notifies suspi- cious events and takes responsive actions against them. Our proposed architecture, as illustrated in Figure 7, con- sists of three components: 1) data collection, 2) alert no- tifications, and 3) incident response workflows. In de-

1Note that the instance type is the cheapest EC2 General Purpose com- pute instance, and we run at least two instances in case of failures.

scribing the architecture of the threat-intelligence plat- form, we emphasize on the relevant serverless design patterns, as described in Sec. 2, pertaining to the func- tionality of components. Data Collection Component: The AWS cloud has many data sources, usually one for each cloud resource, that is exposed to tenants for performance, debugging, and security purposes. For example: application fire- wall [17], load balancer [11], S3 access logs [19], DNS [21], and API calls [12] are some of the log types that tenants can utilize. The data collection module uti- lizes multiple serverless patterns to collect the data from varying sources and stores them in a centralized loca- tion. As soon as the new data becomes available at those data sources, the event-driven pattern (DP2) attached to sources reads the new data and streams the incoming data into transformation/streaming sub-modules. The data transformation pattern (DP3) enriches the input data with additional information, such as by identifying the geolo- cation corresponding to an IP address in the data, and then the data streaming pipeline (DP4) streams the en- riched data into both S3 and Elasticsearch cluster. When a failure occurs in sending the data to either S3 or Elas- ticsearch, the state machine pattern (DP5) catches the failure and resends the failed entries by invoking another Lambda. Notification Component: The notification component incorporates both the periodic invocation (DP1) and event-driven (DP2) patterns to alert system operators and developers of suspicious activities against their cloud re- sources. For example: when the data collection compo- nent stores the API call data (collected by AWS Cloud- Trail) in S3, the event-driven Lambda function verifies if the API calls are invoked from outside the USA (which may signify in certain cases that the API keys used to invoke APIs are misused). On the other hand, there are attacks, where we need evidence to be collected for a certain period of time before we can detect them. For in- stance, detecting login brute force attacks requires ana- lyzing a number of failed login attempts over time. How-

ever, the Lambda functions attached to the incoming data streams can only see the evidence present in the current stream; it has no access to historical data. In this case, the periodic invocation design (DP1) solves the problem by periodically invoking a Lambda function, querying the data from our Elasticsearch cluster and extracting failed login attempts over time.

Incident-Response Component: This component re- sponds to attacks identified by the notification compo- nent. For example, it helps to automate the forensic anal- ysis of a compromised VM (or a container). When the notification component notifies on a compromised VM, the best incident response action is to quarantine the in- fected VM by blocking all incoming and outgoing traffic from it and to analyze the memory of the VM. The mem- ory analysis includes the installation of the kernel mod- ule such as LiME [2] into the compromised VM to ex- tract the memory dump and perform forensic actions by using the known tools such as Volatility [43]. This com- plete end-to-end incident response workflow requires a number of well-orchestrated Lambda functions, which can be achieved using the state machine pattern (DP5).

Cost and Scalability Analysis: To implement each component as a non-serverless architecture, few contain- ers or VMs will be essentially running all the time be- cause of the high spin-up time of a container or VM. Lambda functions can avoid such resource consumption by not being invoked when there is no data or incident. In terms of scalability, as each design pattern can be scaled-up/down individually, which is managed by cloud providers, the threat-intelligence platform in Figure 7 provides more flexibility when we want to add or remove data, notifications, or incident-response modules.

4 Discussion

Despite the versatile capabilities of the Lambda function, there are limitations that restrict our design choices. In this section, we describe the limits and discuss how to avoid them by using workarounds, followed by potential approaches that solve such limitations, systematically.

4.1 Resource Constraints Time-Bound Execution. Lambda functions have a max- imum execution time limit [15, 30, 37], which prohibits using Lambda for tasks that have an unknown duration as once the limit is reached, AWS will terminate the ex- ecution without waiting for the completion and any state will be lost. This limitation can be avoided by splitting the original task across multiple executions, which is not possible for all workloads. Thus, the proper solution is

to either increase the execution time limit or to automat- ically pass state between executions so that the task can continue in another execution with the previous state.

Lack of Computing Power. From prior experience with applications such as video encoding, the amount of com- puting power available to a Lambda function is insuffi- cient for CPU intensive workloads. CPU resources are also not directly configurable; instead, they are propor- tionally allocated depending on the amount of memory configured to a Lambda function. Thus, such workloads currently have to be executed inside VMs or containers. An ultimate solution for this problem is to make comput- ing resources configurable or to support a Lambda that uses powerful computing resources such as GPUs.

Disk Space. AWS limits you to 512MB of disk space under the “/tmp” directory exposed to a Lambda function which again restricts using Lambda for workloads like video encoding. There is also no documentation about whether the Lambda disk is encrypted. We would like to see the ability to increase this as a simple configuration option or a way to mount disks like AWS EBS or AWS EFS which would also allow encryption.

4.2 Limited Functionalities

Event Tracing. There is a lack of tooling to trace an event through an intricate serverless system to help with troubleshooting issues and to understand where the bot- tlenecks exist in the system. This also impacts handling suspicious activity analysis as it is hard to identify where the event has originated, and what other components that the event may have affected. Tools like Zipkin [46] and AWS X-Ray [18] provide the required database and vi- sualizations, but lack integrations with cloud services such as AWS Cloudwatch and AWS SNS to fully trace an event propagation. Since this limits the visibility of serverless systems, either the integrations with existing cloud services should be supported or cloud providers need to support such tools.

Security. AWS Lambda functions are offered as a man- aged service. However, there are no security services in- tegrated with the Lambda functions, currently. To de- velop secure function code, developers resort to security tools, such as bandit [38], integrated into continuous in- tegration/continuous deployment (CI/CD) pipeline that statically analyzes the function code to discover unsafe functions and security bugs. To prevent introducing se- curity bugs from third-party libraries [34], many Lambda functions only include AWS provided packages and li- braries. To allow seamless security to Lambda func- tions, AWS should integrate AWS Inspector [8] with the Lambda function that provides vulnerability scanning.

5 Conclusions

To ease the development of security services in the cloud, this paper describes six serverless design patterns that can be used to build serverless applications and services. In each design pattern, we highlighted the key advan- tages and presented several serverless applications. We also conceptually demonstrated that a large-scale secu- rity system for cloud can be composed of proposed de- sign patterns by introducing a threat-intelligence system. In addition, we described the limits of Lambda functions and provided ways to overcome them. We envision that the proposed serverless design patterns will revolutionize security systems in the cloud and become dominant by being a standard of serverless application development.

Acknowledgments

We thank the anonymous reviewers and our shepherd, Michael Swift, for their feedback.

References

[1] Cloud Controls Matrix - Cloud Security Alliance : Cloud Se- curity Alliance. https://cloudsecurityalliance.org/group/cloud- controls-matrix/# overview, 2018. [Accessed 03-10-2018].

[2] LiME - Linux Memory Extractor. https://github.com/ 504ensicsLabs/LiME, 2018. [Accessed 03-12-2018].

[3] System and Organization Controls: SOC Suite of Services. https: //www.aicpa.org/interestareas/frc/assuranceadvisoryservices/ sorhome.html, 2018. [Accessed 03-10-2018].

[4] ALPERNAS, K., FLANAGAN, C., FOULADI, S., RYZHYK, L., SAGIV, M., SCHMITZ, T., AND WINSTEIN, K. Secure server- less computing using dynamic information flow control. arXiv preprint arXiv:1802.08984 (2018).

[5] AMAZON WEB SERVICES. Amazon API Gateway. https://aws. amazon.com/api-gateway/, 2018. [Accessed 03-14-2018].

[6] AMAZON WEB SERVICES. Amazon Athena - Serverless Inter- active Query Service - AWS. https://aws.amazon.com/athena/, 2018. [Accessed 03-11-2018].

[7] AMAZON WEB SERVICES. Amazon CloudWatch - Cloud & Net- work Monitoring Services. https://aws.amazon.com/cloudwatch/, 2018. [Accessed 03-11-2018].

[8] AMAZON WEB SERVICES. Amazon Inspector. https://aws. amazon.com/inspector, 2018. [Accessed 03-15-2018].

[9] AMAZON WEB SERVICES. Amazon Kinesis. https://aws. amazon.com/kinesis/, 2018. [Accessed 03-12-2018].

[10] AMAZON WEB SERVICES. Amazon Simple Notification Ser- vices (SNS) — Event Notifications for Distributed Applications and Microservices — AWS. https://aws.amazon.com/sns/, 2018. [Accessed 03-12-2018].

[11] AMAZON WEB SERVICES. AWS — Elastic Load Balanc- ing - Cloud Network Load Balancer. https://aws.amazon.com/ elasticloadbalancing/, 2018. [Accessed 03-12-2018].

[12] AMAZON WEB SERVICES. AWS CloudTrail. https://aws. amazon.com/cloudtrail/, 2018. [Accessed 03-12-2018].

[13] AMAZON WEB SERVICES. AWS EC2 Pricing - AWS. https: //aws.amazon.com/ec2/pricing, 2018. [Accessed 05-10-2018].

[14] AMAZON WEB SERVICES. AWS Lambda - Pricing. https://aws. amazon.com/lambda/pricing, 2018. [Accessed 05-10-2018].

[15] AMAZON WEB SERVICES. AWS Lambda Limits - AWS Lambda - AWS Documentation. https://docs.aws.amazon.com/lambda/ latest/dg/limits.html, 2018. [Accessed 03-11-2018].

[16] AMAZON WEB SERVICES. AWS Lambda Serverless Compute - Amazon Web Services. https://aws.amazon.com/lambda/, 2018. [Accessed 02-21-2018].

[17] AMAZON WEB SERVICES. AWS WAF - Web Application Fire- wall. https://aws.amazon.com/waf/, 2018. [Accessed 03-12- 2018].

[18] AMAZON WEB SERVICES. AWS X-Ray Distributed Tracing System. https://aws.amazon.com/xray, 2018. [Accessed 03-14- 2018].

[19] AMAZON WEB SERVICES. Cloud Object Storage — Store & Retrive Data Anywhere — Amazon Simple Storage Service. https://aws.amazon.com/s3/, 2018. [Accessed 03-12-2018].

[20] AMAZON WEB SERVICES. Identity and Access Management (IAM) - Amazon Web Services (AWS). https://aws.amazon.com/ iam/, 2018. [Accessed 03-15-2018].

[21] AMAZON WEB SERVICES. Managed Cloud DNS - Domain Name System — AWS Route 53 — AWSl. https://aws.amazon. com/route53/, 2018. [Accessed 03-12-2018].

[22] AMAZON WEB SERVICES. Using Amazon Redshift Spectrum, Amazon Athena, and AWS Glue with Node.js in Production — AWS Big Data Blog. https://aws.amazon.com/blogs/big- data/using-amazon-redshift-spectrum-amazon-athena-and- aws-glue-with-node-js-in-production/, 2018. [Accessed 03-11-2018].

[23] APACHE SOFTWARE FOUNDATION. Apache Flink: Scalable Stream and Batch Data Processing. https://flink.apache.org/, 2018. [Accessed 03-11-2018].

[24] APACHE SOFTWARE FOUNDATION. Apache Parquet. https:// parquet.apache.org/, 2018. [Accessed 03-11-2018].

[25] APACHE SOFTWARE FOUNDATION. Apache Spark - Lighting- Fast Cluster Computing. https://spark.apache.org/, 2018. [Ac- cessed 03-11-2018].

[26] ARNAUTOV, S., TRACH, B., GREGOR, F., KNAUTH, T., MARTIN, A., PRIEBE, C., LIND, J., MUTHUKUMARAN, D., O’KEEFFE, D., STILLWELL, M., ET AL. Scone: Secure linux containers with intel sgx. In OSDI (2016), vol. 16, pp. 689–703.

[27] BALDINI, I., CASTRO, P., CHANG, K., CHENG, P., FINK, S., ISHAKIAN, V., MITCHELL, N., MUTHUSAMY, V., RABBAH, R., SLOMINSKI, A., ET AL. Serverless computing: Current trends and open problems. In Research Advances in Cloud Com- puting. Springer, 2017, pp. 1–20.

[28] ELASTICSEARCH. Open Source Search & Analytics Elastic- search — Elastic. https://www.elastic.co/, 2018. [Accessed 03- 12-2018].

[29] HENDRICKSON, S., STURDEVANT, S., HARTER, T., VENKATARAMANI, V., ARPACI-DUSSEAU, A. C., AND ARPACI-DUSSEAU, R. H. Serverless computation with openlambda. Elastic 60 (2016), 80.

[30] IBM CLOUD. System Details and Limits - IBM Cloud Docs. https://console.bluemix.net/docs/openwhisk/openwhisk reference.html, 2018. [Accessed 03-12-2018].

[31] JAIN, B., BAIG, M. B., ZHANG, D., PORTER, D. E., AND SION, R. Sok: Introspections on trust and the semantic gap. In Security and Privacy (SP), 2014 IEEE Symposium on (2014), IEEE, pp. 605–620.

https://cloudsecurityalliance.org/group/cloud-controls-matrix/#_overview

https://github.com/504ensicsLabs/LiME

https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/sorhome.html

https://aws.amazon.com/api-gateway/

https://aws.amazon.com/athena/

https://aws.amazon.com/cloudwatch/

https://aws.amazon.com/inspector

https://aws.amazon.com/kinesis/

https://aws.amazon.com/sns/

https://aws.amazon.com/elasticloadbalancing/

https://aws.amazon.com/cloudtrail/

https://aws.amazon.com/ec2/pricing

https://aws.amazon.com/lambda/pricing

https://docs.aws.amazon.com/lambda/latest/dg/limits.html

https://aws.amazon.com/lambda/

https://aws.amazon.com/waf/

https://aws.amazon.com/xray

https://aws.amazon.com/s3/

https://aws.amazon.com/iam/

https://aws.amazon.com/route53/

https://aws.amazon.com/blogs/big-data/using-amazon-redshift-spectrum-amazon-athena-and-aws-glue-with-node-js-in-production/

https://flink.apache.org/

https://parquet.apache.org/

https://spark.apache.org/

https://www.elastic.co/

https://console.bluemix.net/docs/openwhisk/openwhisk_reference.html

[32] JAIN, P., DESAI, S. J., SHIH, M.-W., KIM, T., KIM, S. M., LEE, J.-H., CHOI, C., SHIN, Y., KANG, B. B., AND HAN, D. Opensgx: An open platform for sgx research. In NDSS (2016).

[33] JONAS, E., PU, Q., VENKATARAMAN, S., STOICA, I., AND RECHT, B. Occupy the cloud: distributed computing for the 99%. In Proceedings of the 2017 Symposium on Cloud Com- puting (2017), ACM, pp. 445–451.

[34] KRUG AND JONES. Hacking Serverless Runtimes - Profiling Lambda, Azure, and More. https://www.blackhat.com/docs/us- 17/wednesday/us-17-Krug-Hacking-Severless-Runtimes.pdf, 2018. [Accessed 03-15-2018].

[35] MALAWSKI, M., GAJEK, A., ZIMA, A., BALIS, B., AND FIGIELA, K. Serverless execution of scientific workflows: Ex- periments with hyperflow, aws lambda and google cloud func- tions. Future Generation Computer Systems (2017).

[36] MAXMIND, INC. MaxMind GeoIP2. https://www.maxmind. com/en/geoip2-services-and-databases, 2018. [Accessed 03-11- 2018].

[37] MICROSOFT AZURE. Azure Functions scale and hosting — Microsoft Docs. https://docs.microsoft.com/en-us/azure/azure- functions/functions-scale#consumption-plan, 2018. [Accessed 04-27-2018].

[38] OPENSTACK. openstack/bandit: Python AST-based static an- alyzer from OpenStack Security Group. https://github.com/ openstack/bandit, 2018. [Accessed 03-15-2018].

[39] PÉREZ, A., MOLTÓ, G., CABALLER, M., AND CALATRAVA, A. Serverless computing for container-based architectures. Fu- ture Generation Computer Systems 83 (2018), 50–59.

[40] SLACK. Slack: Where work happens. https://slack.com/, 2018. [Accessed 03-11-2018].

[41] SPILLNER, J. Snafu: Function-as-a-service (faas) runtime design and implementation. arXiv preprint arXiv:1703.07562 (2017).

[42] UPSIDETM . S3 Anti-virus Scanning with Lambda and ClamAV. https://engineering.upside.com/s3-antivirus-scanning- with-lambda-and-clamav-7d33f9c5092e, 2018. [Accessed 03- 11-2018].

[43] VOLATILITY FOUNDATION. Volatility - An Advanced Memory Forensics Framework. https://github.com/volatilityfoundation/ volatility, 2018. [Accessed 03-12-2018].

[44] ZHANG, Y., JUELS, A., REITER, M. K., AND RISTENPART, T. Cross-vm side channels and their use to extract private keys. In Proceedings of the 2012 ACM conference on Computer and communications security (2012), ACM, pp. 305–316.

[45] ZHANG, Y., JUELS, A., REITER, M. K., AND RISTENPART, T. Cross-tenant side-channel attacks in paas clouds. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Commu- nications Security (2014), ACM, pp. 990–1003.

[46] ZIPKIN. OpenZipkin - A Distributed Tracing System. https:// zipkin.io, 2018. [Accessed 03-12-2018].

https://www.blackhat.com/docs/us-17/wednesday/us-17-Krug-Hacking-Severless-Runtimes.pdf

https://www.maxmind.com/en/geoip2-services-and-databases

https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale#consumption-plan

https://github.com/openstack/bandit

https://slack.com/

https://engineering.upside.com/s3-antivirus-scanning-with-lambda-and-clamav-7d33f9c5092e

https://github.com/volatilityfoundation/volatility

https://zipkin.io

Introduction

AWS Lambda
AWS Lambda Security

3=-0.6em A Taxonomy of Serverless Design Patterns

DP1: Periodic Invocation Pattern
DP2: Event-Driven Pattern
DP3: Data Transformation Pattern
DP4: Data Streaming Pattern
DP5: State Machine Pattern
DP6: Bundled Pattern
Cost and Scalability Analysis

Serverless Threat-Intelligence Platform
Discussion

Resource Constraints
Limited Functionalities

Conclusions

New folder/Securing Serverless Computing Challenges.pdf

Securing Serverless Computing: Challenges, Solutions, and Opportunities

Xing Li, Student Member, IEEE, Xue Leng, and Yan Chen, Fellow, IEEE

Abstract—Serverless computing is a new cloud service model that reduces both cloud providers’ and consumers’ costs through extremely agile development, operation, and charging mecha- nisms and has been widely applied since its emergence. Nev- ertheless, some characteristics of serverless computing, such as fragmented application boundaries, have raised new security challenges. Considerable literature work has been committed to addressing these challenges. Commercial and open-source server- less platforms implement many security measures to enhance serverless environments. This paper presents the first survey of serverless security that considers both literature work and industrial security measures. We summarize the primary security challenges, analyze corresponding solutions from the literature and industry, and identify potential research opportunities. Then, we conduct a gap analysis of the academic and industrial solu- tions as well as commercial and open-source serverless platforms’ security capabilities, and finally, we present a complete picture of current serverless security research.

Index Terms—Cloud Computing, Serverless Computing, Secu- rity, Survey.

I. INTRODUCTION

T HE development of cloud computing has driven variousservice model innovations, including serverless comput- ing. In this model, cloud providers are responsible for all server-related management tasks, such as resource allocation, service deployment, scaling, and monitoring, and an appli- cation is charged only for its execution time. As a result, consumers can avoid tedious management tasks, focus on the business code, and save costs by not paying for idle resources. These advantages in terms of efficiency and economy have led to the rapid development of serverless computing in recent years and have attracted extensive attention from both industry and academia. According to a recent report, the global serverless market size is estimated to grow to $21.1 billion by 2025 [1].

However, as a novel service model, serverless computing also has certain distinguishing features that present some challenges, leading to security and compliance concerns. For example, its agile and lightweight virtualization technologies may lead to weak isolation, and the ephemeral nature of its computing instances could increase the difficulty of se- curity management. In recent years, substantial efforts have

X. Li and X. Leng are with the College of Computer Science and Technology, Zhejiang University, Hangzhou, 310027, China (e-mail: [email protected]; lengxue [email protected]).

Y. Chen is with the Department of Computer Science, Northwestern University, Evanston, IL 60208, USA (e-mail: [email protected]).

This work has been submitted to the IEEE for possible publication. Copyright may be transferred without notice, after which this version may no longer be accessible.

been made to address these challenges. Related studies have arisen from academic research, commercial cloud providers, and thriving open-source communities and have considerably enhanced serverless security. Therefore, a systematic survey of current research progress is needed to provide a foundation for continuing security enhancement.

Some previous surveys of serverless computing have been conducted [2], [3]; however, they have three main drawbacks in revealing the current status of security research. In terms of subject matter, these surveys have extensively discussed the concepts, challenges, applications, and prospects of serverless computing but have not specifically targeted security. Re- garding content, the previous surveys have briefly introduced possible risks or attacks but have not systematically analyzed existing solutions and future directions of research. In terms of materials, these surveys have focused on literature work and have not considered the measures adopted in industry (i.e., commercial or open-source platforms); however, an academic focus alone is insufficient for a review of a widely applied cloud computing model such as serverless computing.

Therefore, a complete and systematic review of serverless security is urgently needed. To promote serverless computing and inspire new research, we present the first survey on server- less security whose horizon is expanded from academia alone to include industry. In this paper, we first introduce the concept and background of serverless computing (Section II). Starting from the unique characteristics of this service model, we then present a classification of the main security challenges and analyze their root causes. Subsequently, we review the state- of-the-art solutions proposed in the literature and adopted by popular serverless platforms for each challenge. Based on the degree to which these problems are solved, we note potential research opportunities (Section III–Section VI). Finally, we illustrate our findings in comparisons of the current academic and industrial solutions as well as commercial and open-source platforms (Section VII).

The main contributions of this work are as follows:

• A systematic summary of the challenges arising in secur- ing serverless computing is presented.

• A brief but comprehensive review of academic and in- dustrial solutions is provided.

• A set of promising potential research opportunities is proposed.

• A multiaspect gap analysis of the current research status is conducted.

ar X

iv :2

10 5.

12 58

1v 1

[ cs

.C R

] 2

5 M

ay 2

02 1

VM ...

Container Engine

Container Container Container

FaaS Runtime FaaS Runtime FaaS Runtime

Function A Function B Function C

Bare Metal Server

Virtual Machine

(a) FaaS Technology Stack (b) A Typical Serverless Application

Function A

\ Function D

API Gateway

Storage Service

Log Service

Scheduled Task

Application Boundary

End User

Other Clients Message Queue

SMS Service

Function B

Function C

: Functions : Backend Services: Trigger Events

Fig. 1: (a) A container-based FaaS technology stack. Typically, only the top-level function code is managed by customers. (b) The architecture of a serverless application that includes FaaS and BaaS components.

II. BACKGROUND AND OVERVIEW

A. Serverless Computing

Virtualization technology is the cornerstone of cloud ser- vices. Based on the platform-as-a-service (PaaS) model, the recent prosperity of lightweight virtualization (e.g., contain- ers) has given birth to a new model: function-as-a-service (FaaS). As shown in Figure 1 (a), in this model, customers develop and deploy small code pieces called functions in the cloud. These functions are deployed in lightweight virtualized environments such as containers and executed on platform- provided runtimes. Each function focuses on a different task, and multiple functions can be combined in an event-driven manner to realize complex business logic. Events that can activate the execution of functions are called triggers; these include but are not limited to HTTP requests, logs, storage events, and timers.

With lightweight virtualization, functions can be initialized extremely fast (usually within a few milliseconds). Therefore, providers can instantiate functions only when needed and flexibly scale them, thereby maximizing resource utilization. Consequently, functions usually have a short lifecycle. This agility is also beneficial to consumers. Since the occupied resources will be released when they are not in use, consumers need to pay only for functions’ actual execution time and do not need to reserve resources for emergencies.

Moreover, cloud providers offer dedicated services and application programming interfaces (APIs) for tasks such as storage, logging, and identity management. These services can help customers build and manage server-side logic, thus significantly accelerating application development and release. This service model is known as backend-as-a-service (BaaS).

Serverless computing is generally regarded as a combination of FaaS and BaaS. By undertaking all management tasks directly related to infrastructure resources, cloud providers make server-related details transparent to consumers. From the customer’s perspective, cloud applications are serverless — neither development, deployment, management, nor billing is server-centric. Figure 1 (b) illustrates the architecture of a typical serverless application.

Currently, serverless computing is widely applied. Major providers such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud have all launched serverless prod- ucts; a series of open-source platforms is also emerging.

Management Interface

Management Services

Infrastructure Resources

Storage . . .

MonitoringBackend Services Logging

Visualization

Authentication

. . .

Deployment Security…

Functions

Customer 2Customer 1

. . .

1 2

①

②

③

④

⑤

① --⑤ : Threats -- : Challenges 1 4

Fig. 2: Locations of threats and security challenges in the serverless computing framework.

Meanwhile, this new cloud service model has begun to be embraced in many scenarios, such as data processing and the Internet of Things (IoT) paradigm.

B. Threats and Security Challenges

As a multitenant cloud service model, serverless computing is susceptible to security threats that can be divided into five categories based on where they are launched. The first category consists of external attacks on applications from malicious users (¬), such as cross-site scripting attacks and injection attacks. Due to the unlimited scalability and the pay-as-you- go feature of serverless computing, denial of service attacks will lead to a substantial increase in the cost to application owners. The second comprises internal attacks on applications from malicious insiders (), such as illegal internal access and sniffing attacks. Adversaries in the internal network can even perceive sensitive information from the communication pattern and activity level of functions. For example, in a health monitoring application, a particular sequence of triggered functions may reflect a specific health condition of the patient [3]. The remaining three categories are horizontal attacks between tenants (®, e.g., side-channel attacks), vertical attacks on serverless infrastructures from malicious tenants (¯, e.g., container escape attacks), and vertical attacks on applications from malicious platforms (°).

To address these threats, the best practice is to build a defense-in-depth system to protect serverless applications and

TABLE I: The landscape of the survey, including security challenges and their root causes, proposed solutions, our reviews, and research opportunities.

Challenges Resource Isolation Security Monitoring Security Management Data Protection

Root Causes The weakness of lightweight virtualization technologies in isolation

The ephemerality of functions and the broken boundaries of serverless applications

The distributed nature of func- tions and the fragmented appli- cation boundaries

Platforms’ control of the func- tion lifecycle and BaaS ser- vices’ participation in business logic

Literature Work

Virtual-machine-based secure containers, e.g., minimized VMMs [4] and unikernels [5]

Information flow mining and tracing, e.g., static analysis [6] and dynamic tracing [7], [8]

Advanced management capa- bilities, e.g., workflow-sensitive authorization [9] and secure container network stacks [10]

Hardware-based trusted execu- tion environments, e.g., protect- ing running code with Intel SGX [11], [12]

Industrial Solutions

Secure containers and network boundaries, e.g., Firecracker [4], gVisor, and VPCs

Security scanning and monitor- ing tools, e.g., Azure Monitor, AWS X-Ray, and DevSecOps tools

Fine-grained authentication and authorization, e.g., IAM sys- tems and role-based access con- trol

Encryption in transit and at rest, e.g., TLS/SSL, code/data en- cryption, and key management services

Status Well resolved Partially resolved Partially resolved Partially resolved

Research Opportunities

Secure containers with better isolation, better performance, and lower overhead

Nonintrusive tracing schemes and advanced insight capabil- ities such as diagnosis and forensics

Automatic security configura- tion and auditing tools

Other confidential computing solutions such as homomorphic encryption

platforms at multiple stages and levels. However, the flexibility and agility of serverless applications expose them to a series of security challenges in the process of achieving this goal. These challenges are concentrated in four aspects: resource isolation (¶), security monitoring (·), security management (¸), and data protection (¹). Figure 2 depicts the locations of the threats and challenges in the serverless framework.

C. Survey Methodology and Objects

To fully understand the current state of the art in serverless security technologies, we collected and investigated the solu- tions proposed in research work and the security mechanisms adopted in practice for serverless platforms. An overview of this survey is presented in Table I.

For the literature work, we collected 77 papers related to serverless security that have been published since 2014 (when the serverless concept emerged). We selected nine recent research papers published in high-reputation confer- ences or journals to showcase the academic world’s latest achievements. Moreover, we collected the security features of popular serverless platforms from their documentation. These platforms include the leading commercial platforms AWS Lambda, Google Cloud Functions, Azure Functions, Alibaba Cloud Function Compute, and IBM Cloud Functions as well as the popular open-source serverless frameworks OpenFaaS, Kubeless, Knative, Fission, Apache OpenWhisk, and Nuclio.

III. CHALLENGE 1: RESOURCE ISOLATION

Serverless computing relies on the dynamic release and reuse of software and hardware to improve resource utilization and reduce costs. Thus, there is a strong requirement for resource isolation, especially among multiple tenants.

However, this requirement conflicts with the weak isola- tion of lightweight virtualization, thereby giving rise to this challenge. Serverless computing requires swift and on-demand function initialization. To this end, lightweight virtualization technologies have been widely adopted. Unlike traditional virtual machines (VMs) with guest operating systems (OSs),

containers share the host’s OS kernel, and thus, their isolation is weak. Malicious consumers could employ this weakness to influence or attack other consumers located on the same host (e.g., via side-channel attacks). For example, Wang et al. [13] found that AWS Lambda suffers from performance isolation issues, and Azure Functions has placement vulnerabilities that facilitate side-channel attacks.

Literature Work. To enhance the isolation of lightweight virtualization technologies and address this challenge, pub- lished research focuses on VM-based solutions. Compared with containers, VMs can provide better security boundaries but require a longer time to initialize. Hence, researchers have attempted to make VMs more lightweight to meet the flexibility requirements of serverless computing. The basic idea is to reduce the size of the guest kernels, that is, remove unnecessary modules, to build “microVMs”, even keeping only the libraries that will be used [4], [5]. Moreover, Cadden et al. [5] employed unikernel snapshots to further accelerate initialization, and Agache et al. [4] minimized virtual machine monitors (VMMs) to reduce the trusted computing base. These microVMs have successfully reduced the initialization time to the millisecond level while providing VM-level isolation.

Industrial Solutions. Led by Amazon, Firecracker [4] has been applied in AWS Lambda. Moreover, all surveyed com- mercial serverless platforms except IBM Functions utilize their own secure container products. These containers enable advanced isolation by employing various techniques, such as microVMs (e.g., Firecracker) and container sandboxes (e.g., gVisor). Commercial platforms also provide mechanisms for network-layer isolation, such as virtual private clouds (VPCs).

Review and Analysis. Secure containers provide VM-level resource isolation and have become a standard mode of implementation in production environments. Therefore, we consider this challenge well resolved. However, due to hard- ware sharing, these approaches are still susceptible to side- channel attacks. Moreover, trade-offs remain between security and performance. For example, gVisor sacrifices significant performance for security (in particular, a 216× reduction in

file opening speed) [14]. Additionally, many existing efforts employ snapshots [15] or even memory sharing [5] to reduce the start-up time as much as possible, which also degrades security to a certain extent. Research Opportunities. Looking forward, serverless com- puting will embrace new secure containers if they offer progress in the following three dimensions: (1) security, achieving better isolation than VMs; (2) efficiency, providing performance closer to that of physical machines; and (3) lightweight computing, incurring lower overheads.

IV. CHALLENGE 2: SECURITY MONITORING

A serverless platform generally maintains a set of run- times for functions, including commonly used packages of the supported programming languages. Moreover, to meet diverse development needs, most providers also support cus- tom runtimes and even provide function marketplaces. The security risks posed by third-party packages and functions necessitate reliable monitoring capabilities to detect anomalies and determine the security status.

Furthermore, in a serverless environment, the ephemeral nature of functions and the broken application boundaries present new challenges. First, although the short-lived nature of functions reduces the attack surface, it also significantly narrows the window for developers to discover and diagnose problems. Second, as shown in Figure 1 (b), a serverless application may have multiple entry points due to a variety of triggers. These entry points, coupled with BaaS services, cause the boundaries of serverless applications to be fragmented and further increase the difficulty of monitoring. Moreover, lacking control over the execution environments and BaaS services, consumers must rely on the provided interfaces for monitoring, which may lead to incomplete views of the running status. For example, Lin et al. [7] noted that AWS Lambda’s monitoring granularity is relatively coarse, and the tracking paths are not continuous across BaaS services. Literature Work. To address this challenge, researchers have attempted to mine and track the information flows in serverless applications from both static and dynamic perspectives. Obetz et al. [6] proposed an augmented call graph that considers BaaS services and explained the feasibility of obtaining the graph through static analysis. To dynamically track where and how data flow, Datta et al. [8] placed an agent in each function’s container to proxy its network requests. These agents generated and propagated labels for inbound and out- bound traffic to record the flow of information and could also restrict functions’ behavior based on preconfigured policies. In addition, Lin et al. [7] proposed GammaRay, a dynamic tracking tool that can capture the causality of invocations across BaaS services to build complete trace graphs. Industrial Solutions. Commercial platforms provide various tools and interfaces to record, aggregate, display, and analyze monitoring data. Some can even serve as triggers for automatic function management. They also aim to gradually enable dis- tributed tracing while ensuring adequate performance. More- over, to further mitigate the impact of nonsecure third-party

components, providers recommend continuous security vali- dation in continuous integration and continuous deployment (CI/CD) pipelines and offer a series of tools, such as static vulnerability scanning and automatic penetration testing, for this purpose. Review and Analysis. The proposed dynamic methods solve the problem of the coarse-grained and incomplete nature of the existing monitoring schemes to a certain extent. For example, data-oriented tracing [8] can be integrated with traditional behavior-oriented mechanisms. Moreover, since functions have relatively low internal complexity, static-analysis-based meth- ods are feasible. These approaches could be an effective supplement to dynamic methods, which may introduce con- siderable runtime overhead. Following best practices in the development phase can also mitigate the threat posed by non- secure third-party components. Unfortunately, the information that can be obtained through static analysis is limited. Current dynamic solutions all require code instrumentation or agent embedding to enable end-to-end monitoring and tracking, resulting in high compilation and runtime overheads [7], [8]. Hence, we consider this challenge only partially resolved. Research Opportunities. The exploration of nonintrusive tracking schemes is a potential research opportunity. Fur- thermore, advanced insight capabilities are lacking in current platforms. These capabilities include assessing security status, predicting and diagnosing faults, and conducting detection and forensics for security events. With various triggers, server- less applications can naturally perform “feedback regulation” for self-management. Meanwhile, functions’ short lifecycles and massive logs impose high requirements on the speed of solutions. We believe this scenario represents a research opportunity where artificial intelligence (AI)-based methods might be beneficial.

V. CHALLENGE 3: SECURITY MANAGEMENT

Security management is a critical means for administrators to enforce security intentions and protect applications. As described in Subsection II-B, the diversity of the possible attacks in serverless environments necessitates comprehensive security management capabilities that can provide protection at multiple levels.

However, the fragmented application boundaries of server- less applications increase the difficulty of security manage- ment. The distributed nature of functions further exacerbates this challenge. On the one hand, functions must carefully inspect the input and output at all their entry points; failure to comply with this principle may lead to injection attacks. On the other hand, an external request may trigger communication among multiple functions and BaaS services, necessitating fine-grained authentication and authorization among functions and services. This task can be challenging for large-scale or complex applications. Literature Work. Traditional authentication and authorization mechanisms have been well studied. Building on this work, re- searchers are currently attempting to provide advanced security management capabilities at new levels. Sankaran et al. [9] built a workflow-sensitive authorization mechanism for serverless

applications. It proactively verifies external requests’ permis- sions for all functions involved in their workflows at the application entry point. Thus, applications can reject illegal requests as early as possible, thereby avoiding partial pro- cessing of illegal requests and reducing the potential attack surface. Moreover, Nam et al. [10] revealed a data leakage risk in container networks and redesigned a secure network stack to protect intercontainer communication. Specifically, the method verifies and filters out illegal requests based on the intercontainer dependencies and utilizes end-to-end direct forwarding to prevent traffic exposure. It even improves the container network’s performance.

Industrial Solutions. Based on various security policies, cloud providers have formulated “best practices” for security management. These policies act on multiple layers and mul- tiple resources and have the potential to provide promising management capabilities. For example, commercial platforms achieve well-defined identity authentication and fine-grained authorization with mature identity access management (IAM) systems. AWS Lambda even provides role-based policies, resource-based policies, access control lists, and other man- agement methods for consumers to choose among and flexibly combine.

Review and Analysis. Based on fine-grained security man- agement policies, existing solutions provide multilevel protec- tion for serverless applications. Providers also document best practices as guidance. However, a gap may inevitably exist between actual situations and the recommended best practices. First, both academic [9], [10] and industrial solutions require administrators to customize security policies in accordance with the application architecture and business logic. Although server management is the providers’ responsibility, the burden placed on consumers for security management has not been relieved but instead has been made even heavier: fine-grained policies require attentive design and careful configuration, which is a time-consuming and error-prone process. Second, providers’ marketing emphasizes only cost-effectiveness and convenience, making it easy for consumers to ignore their responsibility to ensure security. As mentioned above, any vio- lation of design principles and best practices may compromise applications’ security. In other words, current mechanisms do not reduce the complexity of security management. Applica- tions’ safety depends on the extent to which best practices are followed. Therefore, we consider this challenge partially resolved.

Research Opportunities. At present, the assistance of auto- mated tools is urgently needed. One possible research direction is automated security configuration. The ideal tool would be able to perceive an application’s architecture and status, extract the consumer’s security intentions, and provide support for policy configuration, maintenance, and updating. Another research direction concerns automated security audits, for which there is a growing market. The ideal tool is expected to not only check whether security measures are deployed but also evaluate the quality of these measures based on an appli- cation’s specific characteristics. We believe that the security risks posed by incorrect configurations can be alleviated by

advancing research in these two directions.

VI. CHALLENGE 4: DATA PROTECTION

Data security is the lifeline of cloud services. Unlike in other models, serverless providers control the whole application lifecycle (e.g., the deployment, scaling, execution, and termi- nation of functions) and the entire software stack. Moreover, as part of the application and business logic, BaaS services can directly access and process data. All these characteristics require consumers to have deep trust in the provider.

Nevertheless, whether during the execution of code in an uncontrolled environment or the processing of sensitive data through the platform’s services, privacy and compliance con- cerns may arise. To alleviate these concerns, platforms need to implement strict data protection measures to clearly and fully persuade consumers. Given the flexibility requirements of serverless environments, this task could be challenging, but it is essential for expanding the application scenarios of serverless computing. Literature Work. In addition to protecting data at rest or in transit through encryption, recent work has focused on protecting data in use. Researchers have attempted to estab- lish a trusted execution environment (TEE) for functions to relieve customers of the need to fully trust providers [11], [12]. Specifically, several approaches employ Intel SGX, a hardware-based mechanism that uses encrypted memory to protect running code and data from privileged software, even the OS. Moreover, Qiang et al. [11] proposed a two-way sandbox, that is, a WebAssembly sandbox nested in an SGX sandbox, to prevent a platform from accessing sensitive data processed by functions while also protecting the platform from untrusted code. Industrial Solutions. On the basis of their mature storage services and security management experience, commercial platforms provide adequate support for encryption in transit and at rest. This protection covers the files and code uploaded by customers as well as the environment variables of func- tions. Moreover, standard key management services (KMS) are provided to help customers handle secrets. Review and Analysis. Protecting data in use has become a significant dimension of cloud security. In this regard, current serverless research is focused on hardware-based TEEs, which still have many limitations, such as poor performance, diffi- culty with hardware heterogeneity, and running only in the user space. Moreover, these techniques have not yet been applied to serverless products. Therefore, we consider this challenge to be partially resolved. Research Opportunities. In recent years, many confidential computing solutions, such as homomorphic encryption and se- cure multiparty computation, have emerged for the protection of data in the cloud. Considering the limitations of the current solutions, the community is expected to appreciate further exploration and adoption of these techniques.

VII. GAP ANALYSIS

During our investigation, we obtained some interesting findings about the current research status of serverless secu-

TABLE II: A brief list of security mechanisms used in commercial serverless platforms.

Aspect Category AWS Lambda Google Azure Functions Alibaba Cloud IBMCloud Functions Function Compute Cloud Functions

Isolation System Firecracker gVisor Azure Container

Instances Alibaba Cloud

Sandbox Docker containers

Network VPC VPC Azure ASE VPC VPC

Monitoring Visualization Amazon CloudWatch Stackdriver Logging Azure Monitor CloudMonitor Sisdig Tracing AWS X-Ray Cloud Trace Application Insights Context objects Zipkin/Jaeger

Management

Authentication AWS IAM Cloud Functions IAM

Azure AD and third-party identities

Digital signatures IBM IAM

Authorization Role-based/resource- based access control

and other policies

Role-based access control

Encryption In Transit mTLS Google ALTS mTLS TLS on ingress TLS on ingress

At Rest Files, secrets, environment variables

All data, KMS All data, Key Vault Code, environment

variables, KMS Data, secrets

Tools Tools AWS Trusted Advisor Event Threat Detection (ETD)

DevSecOps tools, Azure AD Access Reviews

- -

TABLE III: A brief list of security mechanisms used in open-source serverless platforms.

Aspect Category OpenFaaS Kubeless Knative Fission OpenWhisk Nuclio

Isolation System Docker Docker Docker Docker Docker Docker Network K8s namespace K8s namespace K8s namespace K8s namespace K8s namespace K8s namespace

Monitoring Visualization Grafana Grafana Grafana Grafana Kamon Dashboard Tracing - - Zipkin/Jaeger Zipkin/Jaeger Zipkin/Jaeger -

Management Authentication OAuth2 Kong

authentication Istio

authentication DID key method

Self-hosted authentication

Authorization K8s RBAC K8s RBAC K8s/Istio RBAC K8s/Istio RBAC Support -

Encryption In Transit TLS on ingress TLS on ingress Istio mTLS Istio mTLS TLS on ingress TLS on ingress At Rest K8s secrets K8s secrets K8s secrets K8s secrets K8s secrets K8s secrets

rity, which may imply potential directions towards a better ecosystem.

A. Academic Solutions vs. Industrial Solutions

We compared the efforts in academia and industry from three perspectives: research interests, features of the solutions, and application status. As mentioned above, both academic and industrial solutions cover the four main security challenges. This consistency in research interests implies that the current research is in a healthy state.

Nonetheless, the solutions show different characteristics. Academic research tends to demonstrate the feasibility of using specific methods, especially new technologies, to solve particular problems. In contrast, the goal of commercial plat- forms is to be as secure as possible while ensuring stability. Thus, providers prefer methods that have been proven in long- term practice and usually combine several methods to achieve multilayer protection. In addition, research-led solutions often adopt a more holistic approach, from developer to platform. Without control over other parties, providers can promote their solutions only through guidelines or best practices.

Regarding application status, some of the reported academic research work has not yet been tested or applied in industry, as it is relatively new. We believe that open-source efforts from both academia and industry, such as publicly available research, real-world datasets, and standardized benchmarks, can help promote smooth adoption of newly emerging solu- tions.

B. Commercial Platforms vs. Open-Source Platforms

Various commercial and open-source serverless platforms have flourished thanks to the vigorous serverless computing market. During our investigation, we found considerable dif- ferences in security between these two kinds of platforms. We discuss and analyze this phenomenon in this section. Specifically, we compare the security measures adopted in commercial and open-source platforms in terms of five aspects: isolation, monitoring, management, encryption, and tools. The detailed results are listed in Table II and Table III.

First, most commercial platforms are equipped with self- developed secure containers and provide VPCs for network- level isolation. In terms of monitoring, they introduce their own specialized distributed tracing and monitoring prod- ucts into serverless scenarios and connect them to unified visualization consoles. Through security policies and IAM systems, these platforms provide mature authentication and authorization capabilities and support data encryption via storage services. Furthermore, their long-term investment and technological accumulation allow commercial platforms to provide many tools to assist customers, such as configuration recommendation and risk detection.

In contrast, most open-source platforms are built atop Ku- bernetes (K8s). Therefore, standard Docker containers and K8s namespace-based network isolation have become a general technical solution. For monitoring, these platforms usually integrate third-party tools or employ their infrastructures’ capabilities to avoid reinventing the wheel. Moreover, open- source platforms mainly rely on ingress gateways and infras-

tructures such as K8s and Istio to achieve security management and encryption in transit. The secret management task is also outsourced to the underlying K8s infrastructure. Similar to the monitoring aspect, open-source platforms usually do not provide security tools natively but support the integration of third-party tools such as Jenkins.

In terms of the above five aspects, the security measures of commercial platforms are all stronger than those of open- source platforms in terms of completeness and richness. The latter’s security capabilities mainly rely on infrastructure or third-party tools. Two main reasons for this difference exist. First, commercial platforms have richer cloud management experience and more capital and human resources, so they can leverage their existing security mechanisms and provide standardized features as BaaS services (e.g., IAM systems). Second, the development of open-source platforms is still rela- tively rudimentary. They focus more on realizing core features of serverless computing, such as agile application construction and automatic function scaling, rather than security features.

Mature and standardized open-source platforms can counter the vendor lock-in problem and stimulate community efforts and related work. Nevertheless, open-source platforms still have a long way to go to compete with commercial platforms in terms of security. This security lag also limits their applica- tion. Hence, more effort is needed to develop and standardize the security mechanisms of open-source serverless platforms. Although some have taken the lead (e.g., OpenFaaS), the competition among open-source serverless platforms is still fierce, and there is no de facto standard. From this perspective, unremitting efforts in developing security measures and the establishment of unique security capabilities therewith may become the key to gaining the dominant position.

VIII. CONCLUSION

This paper has presented a survey of both literature research and industrial solutions to elucidate the research status of techniques for securing serverless computing. Starting from the characteristics of serverless environments, we explained the origins of four main security challenges: resource isolation, security monitoring, security management, and data protection. Based on a review of existing solutions, we then identified pos- sible research directions. Finally, we compared academic and industrial solutions as well as current commercial and open- source serverless platforms and elaborated on our thoughts re- garding promising directions for establishing a better research and application ecosystem.

REFERENCES [1] MarketsandMarkets, “Serverless Architecture Market Size, Share and

Global Market Forecast to 2025,” 2020, accessed on 2021-03-15. [Online]. Available: http://bit.ly/serverless market

[2] E. Jonas, J. Schleier-Smith, V. Sreekanti, C.-C. Tsai, A. Khandelwal, Q. Pu, V. Shankar, J. Carreira, K. Krauth, N. Yadwadkar et al., “Cloud programming simplified: A berkeley view on serverless computing,” arXiv preprint arXiv:1902.03383, 2019.

[3] H. Shafiei, A. Khonsari, and P. Mousavi, “Serverless computing: A survey of opportunities, challenges and applications,” Jan 2020, accessed on 2021-03-15. [Online]. Available: engrxiv.org/u8xth

[4] A. Agache, M. Brooker, A. Iordache, A. Liguori, R. Neugebauer, P. Piwonka, and D.-M. Popa, “Firecracker: Lightweight virtualization for serverless applications,” in 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20), 2020, pp. 419–434.

[5] J. Cadden, T. Unger, Y. Awad, H. Dong, O. Krieger, and J. Appavoo, “Seuss: skip redundant paths to make serverless fast,” in Proceedings of the Fifteenth European Conference on Computer Systems, 2020, pp. 1–15.

[6] M. Obetz, S. Patterson, and A. Milanova, “Static call graph construction in aws lambda serverless applications,” in 11th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 19), 2019.

[7] W.-T. Lin, C. Krintz, R. Wolski, M. Zhang, X. Cai, T. Li, and W. Xu, “Tracking causal order in aws lambda applications,” in 2018 IEEE International Conference on Cloud Engineering (IC2E). IEEE, 2018, pp. 50–60.

[8] P. Datta, P. Kumar, T. Morris, M. Grace, A. Rahmati, and A. Bates, “Valve: Securing function workflows on serverless computing plat- forms,” in Proceedings of The Web Conference 2020, 2020, pp. 939–950.

[9] A. Sankaran, P. Datta, and A. Bates, “Workflow integration alleviates identity and access management in serverless computing,” in Annual Computer Security Applications Conference, 2020, pp. 496–509.

[10] J. Nam, S. Lee, H. Seo, P. Porras, V. Yegneswaran, and S. Shin, “Bastion: A security enforcement network stack for container networks,” in 2020 USENIX Annual Technical Conference (USENIX ATC 20), 2020, pp. 81–95.

[11] W. Qiang, Z. Dong, and H. Jin, “Se-lambda: Securing privacy-sensitive serverless applications using sgx enclave,” in International Conference on Security and Privacy in Communication Systems. Springer, 2018, pp. 451–470.

[12] S. Brenner and R. Kapitza, “Trust more, serverless,” in Proceedings of the 12th ACM International Conference on Systems and Storage, 2019, pp. 33–43.

[13] L. Wang, M. Li, Y. Zhang, T. Ristenpart, and M. Swift, “Peeking behind the curtains of serverless platforms,” in 2018 USENIX Annual Technical Conference (USENIX ATC 18), 2018, pp. 133–146.

[14] E. G. Young, P. Zhu, T. Caraza-Harter, A. C. Arpaci-Dusseau, and R. H. Arpaci-Dusseau, “The true cost of containing: A gvisor case study,” in 11th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 19), 2019.

[15] D. Ustiugov, P. Petrov, M. Kogias, E. Bugnion, and B. Grot, “Bench- marking, analysis, and optimization of serverless function snapshots,” in Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, 2021, pp. 559–572.

Xing Li [S’19] received a B.E. degree in software engineering from Shandong University, Jinan, China, in 2016. He is currently pursuing a Ph.D. degree in cybersecurity at Zhejiang University, Hangzhou, China. His research interests are focused on the security of cloud networking and applications.

Xue Leng received a Ph.D. degree in computer science and technology from Zhejiang University, Hangzhou, China, in 2020. Her research interests include security enhancement in SDN and performance optimization of microservices and service meshes.

Yan Chen [F’17] received a Ph.D. degree in computer science from the University of California at Berkeley, Berkeley, CA, USA, in 2003. He is currently a Professor with the Department of Computer Science, Northwestern University, Evanston, IL, USA. His research interests include network security, measurement, and diagnosis for large-scale networks and distributed systems.

http://bit.ly/serverless_market

engrxiv.org/u8xth

I Introduction
II Background and Overview

II-A Serverless Computing
II-B Threats and Security Challenges
II-C Survey Methodology and Objects

III Challenge 1: Resource Isolation
IV Challenge 2: Security Monitoring
V Challenge 3: Security Management
VI Challenge 4: Data Protection
VII Gap Analysis

VII-A Academic Solutions vs. Industrial Solutions
VII-B Commercial Platforms vs. Open-Source Platforms

VIII Conclusion
References
Biographies

Xing Li
Xue Leng
Yan Chen