Model-based Design of Reusable Secure Connectors Michael Shin Hassan Gomaa Don Pathirage Department of Computer Science Department of Computer Science Department of Computer Science Texas Tech University George Mason University Texas Tech University Lubbock, Texas, USA Fairfax, Virginia, USA Lubbock, Texas, USA michael.shin@ttu.edu hgomaa@gmu.edu don.pathirage@ttu.edu Abstract—This paper describes the integration of security and constructed by composing security pattern components and communication patterns in reusable secure connectors that are communication pattern components. Integration of security incorporated in the model-based design of secure distributed patterns and communication patterns within a secure connector component-based software architectures. The secure connectors is provided by a security coordinator. Once a secure connector are designed separately from application components by reusing the appropriate communication pattern between components as is constructed, it can then be reused in different secure well as the security patterns required by these components. Each applications. secure connector is designed as a composite component that This paper describes the integration of security patterns and encapsulates both security pattern and communication pattern communication patterns within reusable secure connectors that components. Integration of security patterns and communication are used in distributed secure CBSAs using the UML notation. patterns within a secure connector is enabled by a security Each reusable secure connector in previous papers by the coordinator. The main advantage is that secure connectors can be authors [9, 10, 11] was described with one or more security reused in different secure applications. services accessed by a security coordinator, the template of Index Terms—Reusable secure connector, secure software which was not addressed. This paper extends the reusable architecture, component-based software architecture, secure software design, message communication patterns, security secure connectors in [9, 10, 11] by describing security patterns patterns, dynamic modeling, model-based design, UML. for security services and a pseudocode template for the high- level security coordinator that is customized for each secure connector based on the security pattern(s) selected. A security I. INTRODUCTION pattern addresses a specific security technique that realizes a A component-based software architecture (CBSA) [12] for security service. Reusable secure connectors make complex distributed applications is designed by means of components, software applications more maintainable by separating security which encapsulate the functionality of the application, and concerns from application concerns in the software connectors, which encapsulate the details of inter-component architectures. Reusable secure connectors described in this communication, such as asynchronous communication or paper are applied to the software architectures for electronic synchronous communication with reply. UML 2 provides a commerce applications. notation for modeling components, ports, provided and In this paper, section II describes related work, section III required interfaces in CBSAs [16]. A CBSA can be developed describes reusable secure connectors, section IV describes using a model-based design method as described in [5]. secure asynchronous message communication connector, Although connectors are typically used in CBSAs to followed by validation of reusable secure connectors in section encapsulate communication mechanisms between components, V. Section VI concludes the paper. this paper describes how security concerns can also be encapsulated in software connectors, which are referred to as II. RELATED WORK secure connectors, separately from application components that Related work focuses on approaches to designing software contain application logic. To effectively integrate security architectures for secure applications and patterns for distributed concerns with communication concerns, it is necessary to communication. The authors in [13] proposed SecureUML, design secure connectors that are both modular and reusable. which is a new modeling language based on UML for the Each secure connector is designed as a composite model-driven development of secure systems. Work has also component using CBSA concepts by reusing security pattern been proposed to provide an extension of UML called UMLsec components and communication pattern components, which are [14] that helps with the expression of security-relevant designed separately from each other. Each security pattern information within design diagrams. In Model-driven security component encapsulates a security pattern, such as symmetric [3], a system is modeled with its security requirements and encryption or digital signature. Each communication pattern security infrastructures are generated using the models. component encapsulates the communication pattern between Using connectors as the central construct, a distributed application components, such as synchronous or asynchronous CBSA in [5, 15] is composed of a set of components and a set message communication. A secure connector is then of connectors that can be used to connect the components. In [6], a connector centric approach is used to model, capture, and confidentiality security service can be realized by means of a enforce security. The security characteristics of a CBSA are symmetric encryption security pattern [4] or an asymmetric described and enforced using software connectors. Methods in encryption security pattern [4]. [1] propose SecArch to evaluate architectures with significant A security pattern is designed using one or two security security concerns. pattern components (SPCs), as depicted in Fig. 1. The Security patterns in [4, 7] address the broad range of confidentiality security service can be realized using the security issues that should be taken into account in the stages of symmetric encryption security pattern (Fig. 1a) [4], which is software development lifecycle. The authors describe the composed of the symmetric encryption encryptor and decryptor problem, context, solution, and implementation of security SPCs. The integrity security service can be realized with the patterns in a structured way with a template so that the hashing security pattern [4], which is designed with the hashing presentations are consistent. The security patterns can help signer SPC (Fig. 1d) and hashing verifier SPC (Fig. 1d). The developers to construct secure systems, even though the non-repudiation security service can be realized with the digital developers may not have security expertise. signature pattern [4], which is designed with the digital In recent work by the authors [9] described secure signature signer SPC (Fig. 1e) and digital signature verifier asynchronous and synchronous connectors for modeling the SPC (Fig. 1e). The authenticator and access control security software architectures for distributed applications and the patterns are realized respectively with the authenticator SPC design of reusable secure connectors that are structured into (Fig. 1b) [4] and the authorization SPC (Fig. 1c) [4]. Each port reusable security components and communication components. of a component is defined in terms of provided and/or required The authors in [11] address the design of secure connectors in interfaces [5]. Each security pattern component (Fig. 1) has a terms of maintainability and evolution, which are used in the provided port through which the component provides security design of secure software architectures. One of the authors has services to other components. Fig. 2 depicts the interfaces also investigated designing dynamically adaptable and provided by the ports of the SPCs in Fig. 1. recoverable connectors [17, 18]. ISEEncryptor «security pattern» ISEDecryptor «security pattern» III. REUSABLE SECURE CONNECTORS Symmetric Encryption Symmetric Encryption PSEEncryptor Encryptor PSEDecryptor Decryptor In a CBSA [12] for concurrent and distributed applications, a) Symmetric Encryption Security Pattern components address the functionality of an application whereas connectors focus on the communication between components. IAuthenticator «security pattern» IAuthorization «security pattern» Authenticator Authorization Thus, each component defines application logic that is PAuthenticator PAuthorization relatively independent of that provided by other components. A b) Authenticator Security Pattern c) Authorization Security Pattern connector acts on behalf of components in terms of IHashingVerifier IHashingSigner communication between components, encapsulating the details «security pattern» Hashing «security pattern» Hashing of inter-component communication. PHashingSigner Signer PHashingVerifier Verifier An approach for designing secure software architectures is d) Hashing Security Pattern to encapsulate security capabilities within connectors IDSSigner «security pattern» IDSVerifier «security pattern» Digital Digital separately from application components [8, 9]. The original Signature Signature Signer PDSVerifier Verifier role of connectors in the software architecture is to provide the PDSSigner e) Digital Signature Security Pattern mechanism for message communication between components Fig. 1. Security Pattern Components [12]. However, in this paper, the role of connectors is extended to become secure connectors by adding security patterns [4, 7] «interface» «interface» to the connectors. ISEEncryptor ISEDecryptor The secure connectors are designed using component-based encrypt (in message, in key, in decrypt (in encryptedMessage, in key, in Algorithm, out encryptedMessage) Algorithm, out message) concepts in which a secure connector is designed as a composite component that contains simple components that «interface» «interface» IAuthenticator IAuthorization encapsulate the security patterns and the message authenticate (in credentials, out result) authorize (in Identity, in object, out communication pattern. One or more security pattern permission) components are encapsulated in a secure connector to provide application components with one or more security services. «interface» IHashingSigner «interface» IHashingVerifier A. Design of Security Pattern Components sign (in message, in key, out messageDigest) verify (in message&messageDigest, in key, out verification) A security service is software functionality for realizing a security goal, such as authentication, authorization, «interface» IDSSigner «interface» IDSVerifier confidentiality, integrity, availability or non-repudiation, which sign (in message, in key, out verify (in message&signature, in key, can be implemented by means of different security techniques. signedMessage) out result) A security service can be realized by means of different security patterns, each of which addresses a specific security Fig. 2. Interfaces of Security Pattern Components technique that realizes a security service. For instance, a B. Design of Communication Pattern Components with each other. Each secure connector is labeled with the Although there are other types of communications between UML stereotype «secure connector» to clearly identify its role distributed components, typical message communication in the software architecture. A secure sender or receiver patterns between the components are synchronous message connector consists of a security coordinator, one or more communication with reply, synchronous message security objects, and a communication object [10]. communication without reply, asynchronous message A security coordinator, which is either a security sender communication, and bidirectional asynchronous message coordinator or a security receiver coordinator, is designed for communication [5]. Each communication pattern is designed integrating the communication pattern and security patterns with a sender communication pattern component (CPC) and a selected for a reusable secure connector. The security sender receiver communication pattern component (CPC), which are and receiver coordinators need to be designed for each reusable encapsulated in a secure sender connector and a secure receiver secure connector whenever a CPC and one or more SPCs are connector respectively. selected for the connector. In addition, a template for the high- In asynchronous message communication, an asynchronous level security coordinator can be designed for each message is sent from a sender component to a receiver communication pattern. The template is customized for each component and is stored in a queue if the receiver is busy. The reusable secure connector based on the security pattern(s) sender component can continue to send the next message to the selected. receiver component as long as the queue is not full. Fig. 3a Fig. 4 depicts the interfaces provided by the security sender depicts the Asynchronous Message Communication (AMC) coordinator (Fig. 6b) for a secure AMC connector. The Sender CPC and Asynchronous Message Communication senderSecurityPatternAttribute parameter in sendSecAsync() (AMC) Receiver CPC for the secure asynchronous message specifies the private key or secret key that is needed by security communication connector. The AMC Sender CPC (Fig. 3a) has pattern components to apply security services to a message, or the provided PAsyncMCSenderService port through which the the algorithm that a security pattern component should select Security Sender Coordinator component sends to the AMC for a security service. The pseudocode template for the Sender CPC a message being sent to the receiver application security sender coordinator is depicted in Fig. 5 in which the component, whereas it requests a service from the AMC security related code (in italics) is replaced by the pseudocode Receiver CPC via the required RNetwork port. Similarly, the for the security patterns selected for a secure AMC connector. AMC Receiver CPC (Fig. 3a) has the required Similarly, the pseudocode template for the Security Receiver RSecurityService port and provided PNetwork port. Fig. 3b Coordinator can be specified. depicts the interfaces provided by each port of the AMC Sender and Receiver communication pattern components «interface» (CPCs). ISecAsyncSenderService sendSecAsync (in messageName, in messageContent, in senderSecurityPatternAttribute) Fig. 4. Security Sender Coordinator Interfaces for Secure AMC Connector loop -- Wait for message from sender component; receive (SenderComponentMessageQ, message); Extract MessageName, MessageContent and SenderSecurityPatternAttribute from message; -- Apply security patterns to message content; while SecurityPatternsRequiredByMessageContent do Apply security pattern to message content; end while; Fig. 3. Asynchronous Message Communication Sender and Receiver Communication Pattern Components and their Interfaces -- Send message to AMC Sender CPC; AsynchronousMCSender.sendSecAsync (in MessageName, in C. Design of Security Coordinators MessageContent); A secure connector is designed by separately considering the message communication pattern and the security patterns end loop; required by application components. A secure connector is a Fig. 5. Pseudocode template for Security Sender Coordinator in Secure AMC distributed connector, which consists of a secure sender Connector connector and a secure receiver connector that communicate The secure connectors are constructed by reusing SPCs signature. The private key is managed by the security sender (Fig. 1 and Fig. 2) and CPCs (Fig. 3) with the security coordinator on behalf of an application sender component. The coordinator (Fig. 6b) being the component that integrates the Signer security component has the provided PDSSigner port to selected SPCs with the selected CPCs. Once one or more communicate with the provided PDSSigner port of the Digital security patterns required by an application component are Signature Signer SPC, and it also has the required determined, the corresponding SPCs are selected from the RSignatureAlgorithm to communicate with the Signature reusable SPCs (Fig. 1 and Fig. 2). Similarly, the required CPCs Algorithm security component, which generates the signature are selected from the reusable CPCs (Fig. 3) in accordance with of message. Fig. 8c depicts the interfaces for Signer and the communication pattern to be used between the application Signature Algorithm security components. components. Also, for the selected CPCs, the corresponding Similarly, the AMC Receiver Connector is designed as a security coordinator pseudocode template (Fig. 5) is composite component that encapsulates the Security Receiver customized to create the security coordinator component (Fig. Coordinator component, Symmetric Encryption Decryptor 6) for the selected security pattern component(s). The security SPC, Digital Signature Verifier SPC, and AMC Receiver CPC. coordinator component integrates the selected SPCs with the selected CPC by sequencing the interaction with those «secure connector» «communication pattern» RNetwork components. For the integration, the security coordinator SecureAsynchronousMC SenderConnector PAsyncMCSenderService AsynchronousMC Sender component has required ports through which it requests RAsyncMCSenderService RNetwork «security coordinator» security services from the SPCs and communicates with the SecuritySender RSEEncryptor «security pattern» Coordinator SymmetricEncryption CPC. Also the security coordinator components provide ports PSecAsyncSenderService PSEEncryptor Encryptor RDSSigner for receiving a service request message from or requesting a «security pattern» DigitalSignature service from an application component. PSecAsyncSenderService PDSSigner Signer a) Secure Asynchronous Message Communication Sender Connector IV. SECURE ASYNCHRONOUS MESSAGE COMMUNICATION CONNECTOR IAsyncMCSenderService RAsyncMCSenderService RSEEncryptor A. Design of Secure Asynchronous Message Communication PSecAsyncSenderService «security ISEEncryptor Connector coordinator» SecuritySender IDSSigner ISecAsyncSenderService Coordinator Suppose that a secure AMC connector provides application RDSSigner components with the Symmetric Encryption and Digital Signature security patterns between the sender and receiver b) Security Sender Coordinator and its Interface application components. This secure AMC connector is Fig. 6. Security Sender Coordinator and Secure Asynchronous Message composed of a secure AMC sender connector (Fig. 6a) and a Communication Sender Connector secure AMC receiver connector. The secure AMC sender loop connector (Fig. 6a) is designed as a composite component in which the Security Sender Coordinator component (Fig. 6b) -- Wait for message from sender component; receive (SenderComponentMessageQ, message); integrates the reusable Symmetric Encryption Encryptor and Extract MessageName, MessageContent, PrivateKey, SecretKey, and Algorithm from message; Digital Signature Signer SPCs (Fig. 1) for the confidentiality -- Apply security patterns to message content; and non-repudiation security with the reusable AMC Sender if MessageContent requires non-repudiation CPC (Fig. 3). then DigitalSignatureSigner.sign (in MessageContent, in PrivateKey, For integrating the components, the Security Sender out SignedMessageContent); Coordinator component (Fig. 6b) has a required RSEEncryptor MessageContent = SignedMessageContent; end if; port to communicate with a provided PSEEncryptor port of the if MessageContent requires confidentiality Symmetric Encryption Encryptor SPC, which encrypts then SymmetricEncryptionEncryptor.encrypt (in MessageContent, messages using the sender’s secret key and algorithm selected in SecretKey, in Algorithm, out EncryptedMessageContent); by the sender component, and it also has a required RDSSigner Message Content = EncryptedMessageContent; end if; port to communicate with a provided PDSSigner port of the Digital Signature Signer SPC, which signs a message using the -- Send message to AMC Sender CPC; AsynchronousMCSender.sendSecAsync (in MessageName, in MessageContent); sender’s private key. The signed and encrypted messages are sent to the receiver component. The pseudocode for the Secure end loop; Sender Coordinator component is customized from the pseudocode template (Fig. 5) and is depicted in Fig. 7. Fig. 7. Security Sender Coordinator for Secure AMC Communication Pattern and Symmetric Encryption Encryptor & Digital Signature Security Patterns The Digital Signature Signer SPC depicted in Fig. 8 is a composite component that is composed of the Signer and B. Example of Secure Asynchronous Message Communication Signature Algorithm security components. The Signer security Connector component encrypts a message using an application sender This section describes how a secure AMC connector can be component’s private key by calling the Signature Algorithm reused for different applications if the applications require the security component to create a signature, and then creates a same security services and asynchronous message signed message that contains the original message and the communication. Fig. 9 depicts the structural view of a reusable The secure AMC connector (Fig. 9) with Symmetric secure AMC connector with Symmetric Encryption security Encryption security pattern and Digital Signature security pattern and Digital Signature security pattern, which can be pattern can be reused for sending a purchase order in the B2C applied for confirming a shipment in a business to business electronic commerce application as well. The B2C application (B2B) electronic commerce application. When a Supplier is required for sending a purchase request from a customer component sends a shipment confirmation to a Delivery Order component to a supplier component in the B2C electronic Server, the shipment confirmation is signed by the Digital commerce application. Signature Signer SPC in the secure AMC sender connector assuming the Supplier Component requires a non-repudiation «security pattern» RSignatureAlgorithm DigitalSignature security service. The shipment confirmation and signature is Signer «security» «security» then encrypted by the Symmetric Encryption Encryptor SPC in Signer Signature Algorithm the secure AMC sender connector assuming it also requires a PDSSigner PSignatureAlgorithm confidentiality security service. The encrypted shipment PDSSinger confirmation and signature are decrypted by the Symmetric a) Digital Signature Signer Security Pattern ISignatureAlgorithm Encryption Decryptor SPC, and then sent to the Delivery Order «security» RSignatureAlgorithm «security» Signature Algorithm Server via the secure AMC receiver connector, which requests Signer ISignatureAlgorithm PSignatureAlgorithm the sender component’s public key from the Public Key IDSSigner PDSSigner Repository that is a certificate authority for public key b) Signer and Signature Algorithm Security Components infrastructure. The signature is verified by the secure AMC «interface» «interface» receiver connector with the sender’s public key. The behavioral IDSSigner ISignatureAlgorithm view of a reusable secure AMC connector can be depicted sign (in message, in key, out signedMessage) encrypt (in message, in key, out signature) using UML communication or sequence diagrams. An example c) Interfaces for Signer and Signature Algorithm Security Components is described in [11] for confidentiality and non-repudiation Fig. 8. Signer and Signature Algorithm Security Components in Digital security services. Signature Signer Security Pattern Component and their Interfaces «secure connector» «security pattern» SecureAMC «communication aPublicKey SenderConnector PAsyncMCSenderService pattern» Repository AsynchronousMC RNetwork Sender PPKRepository «security pattern» RNetwork SymmetricEncryptionEncryptor RAsyncMCSenderService RSEEncryptor «security» PNetwork RPKRepository «security Encryptor coordinator» SecuritySender PSEEncryptor REncryption «secure Coordinator PSEEncryptor Algorithm connector» SecureAMC PSecAsync RDSSigner PEncryption Receiver SenderService «security» Algorithm Connector Encryption Algorithm RSecAsync Receiver «security pattern» DigitalSignatureSigner Service RSignature Algorithm «security» «security» Signature PSecAsync Signer PDSSigner PSignature Algorithm Receiver Algorithm Service PDSSigner «application PSecAsyncSenderService component» DeliveryOrder RSecAsyncSenderService Server «application component» Supplier Fig. 9. Applying Secure AMC Connector with Symmetric Encryption and Digital Signature security patterns in B2B application the average communication time is 46.7 milliseconds (ms) for V. VALIDATION OF REUSABLE SECURE CONNECTORS secure synchronous message communication with reply, and 57 ms for secure asynchronous message communication. Secure A. Reusability of Secure Connectors AMC takes more time than secure SMCWR because it The reusable secure connectors have been implemented consumes processing time for generating/verifying digital using object-oriented programming in Java. The secure AMC signatures in a public key infrastructure. The third and fourth connector was implemented with four threads for each of columns of Table 1 show the average communication times for security sender coordinator component, AMC sender the corresponding patterns using the without security pattern communication pattern component, security receiver approach and without secure connector approach respectively. coordinator component, and AMC receiver communication The fifth column of Table 1 indicates that the time difference pattern component. A sender component and a receiver between the with secure connector approach and the without component for the secure AMC were implemented using each security pattern approach is highly significant. This is because separate thread. Also, a message queue was implemented and with secure connector approach provides application placed between threads (for example, a message queue between components with security patterns such as confidentiality and the sender component thread and security sender coordinator non-repudiation. The security patterns in the with secure component thread, and a message queue between the security connector approach consume processing time for sender coordinator component thread and the AMC sender encrypting/decrypting messages and/or generating/verifying communication pattern component thread). The secure AMC digital signatures, whereas the without security pattern communication was implemented with 6 threads and 5 message approach is much faster due to it providing no security. Thus, buffers. Similarly, the secure synchronous message the additional processing time taken by the with secure communication with reply (SMCWR) connector was connector approach is to make applications secure in implemented. comparison to insecure applications developed using the The implementation of the secure AMC connector and the without security pattern approach. secure SMCWR connector were applied to different Comparing the performance of the without secure applications. The secure asynchronous message connector and with secure connector approaches shows that communication connector was implemented and reused for there is no significant difference in the runtime performance of Confirm Shipment (B2B) and Purchase Order (B2C) use cases. the two approaches. The time difference between the two The secure SMCWR connector was implemented and reused approaches (sixth column in Table 1) ranges from less than 0.6 for the ATM, B2B, and B2C applications, in particular to ms to 1 ms. Both approaches provide applications with security implement use cases such as PIN validation (ATM), Browse patterns, but the with secure connector approach separates Catalog and Place Requisition (B2B), and Pay Product (B2C). security patterns from application logic, so that it leads to B. Performance Overhead of Reusable Secure Connectors secure software architectures that are more maintainable and evolvable than the without secure connector approach. This section describes the performance analysis of secure applications using the secure connectors and compares them Table 1: Performance comparison of the with secure connector with secure applications executing the same message approach, without security pattern approach, and without secure communication patterns but using other approaches for connector approach providing or not providing security. The three approaches TIME TIME DIFFERENCE DIFFERENCE compared in this section are the (1) with secure connector BETWEEN BETWEEN approach, for secure applications that use the approach WITH WITH SECURE SECURE described in this paper; (2) without security pattern approach, CONNECTOR CONNECTOR APPROACH APPROACH for applications that do not provide any security; (3) without AND AND secure connector approach, for secure applications in which WITH WITHOUT WITHOUT WITHOUT WITHOUT SECURE SECURITY SECURE SECURITY SECURE security patterns are mingled with the application logic. The COMMUNICATION CONNECTOR PATTERN CONNECTOR PATTERN CONNECTOR PATTERN APPROACH APPROACH APPROACH APPROAHC APPROACH underlying difference between the with secure connector and without secure connector approaches is that the security SYNCHRONOUS 46.7 MS 17.8 MS 46.1 MS 28.9 MS 0.6 MS patterns in the without secure connector approach are MESSAGE COMMUNICATION implemented within application components along with WITH REPLY application logic, whereas the with secure connector approach (SMCWR) has separated the security patterns from application ASYNCHRONOUS 57.0 MS 8.9 MS 56.0 MS 48.1 MS 1.0 MS components and implemented them as secure connectors. The MESSAGE COMMUNICATION without security pattern approach implements the application (AMC) logic without any security patterns. Table 1 shows the average time of multiple message VI. CONCLUSIONS communications and a comparison between the with secure A secure connector can be reused in different applications if connector approach, without security pattern approach, and it matches the security and communication patterns required without secure connector approach. For the with secure between application components. Reusable secure connectors connector approach, the second column of Table 1 shows that are designed as composite components using model-based [6] Ren, J., Taylor, R., Dourish, P., Redmiles, D., 2005. Towards CBSA concepts, which are designed by reusing security pattern An Architectural Treatment of Software Security: A Connector- components providing security services required by application Centric Approach, Proceedings of the Workshop on Software components as well as communication pattern components for Engineering for Secure Systems, St. Louis, MI, USA, May . transmission of secure messages and responses between [7] Schumacher, M., Fernandez, E. B., Hybertson, D., Buschmann, components. Integration of security and communication F., Sommerlad, P., 2006. Security Patterns, Wiley. patterns within secure connectors is provided by security [8] Shin, M. E., Gomaa, H., 2007. Software Modeling of Evolution coordinators. In particular, this paper contributes to the to a Secure Application: From Requirements Model to Software reusable secure connectors by providing security patterns for Architecture, Science of Computer Programming, Volume 66, Issue 1, pp. 60-70. security services, integrating security patterns and communication patterns within secure connectors, and by [9] Shin, M. E., Malhotra, B., Gomaa, H., Kang, T., 2012. Connectors for Secure Software Architectures, 24th providing a pseudocode template for the high-level security International Conference on Software Engineering and coordinator that can be customized for each secure connector. Knowledge Engineering (SEKE’2012), San Francisco, July 1-3. To validate this approach, secure connectors were implemented [10] Shin, M. E., Gomaa, H., Pathirage, D., 2016. Reusable Secure for two electronic commerce applications and an ATM Connectors for Secure Software Architecture, 15th International application. A performance evaluation was also carried out Conference on Software Reuse, June 2016, Limassol, Cyprus. comparing approaches with and without secure connectors. [11] Shin, M. E., Gomaa, H., Pathirage, D., Baker, C., Malhotra, B., This paragraph describes future research for secure 2016. Design of Secure Software Architectures with Secure connectors. Component-based secure connectors might be Connectors, International Journal of Software Engineering and mapped to aspect-oriented secure connectors [2] by considering Knowledge Engineering, Vol. 26, No. 5, pp 769–805. the relationships between the ports/interfaces of components [12] Taylor, R. N., Medvidovic, N., Dashofy, E. M., 2010. Software and the pointcuts/advices of aspects. Future work also includes Architecture: Foundations, Theory, and Practice, Wiley & Sons. extending the reusable secure connector approach to [13] Lodderstedt, T., Basin, D., Doser, J., 2002. SecureUML: A incorporate additional communication and security patterns. UML-Based Modeling Language for Model-Driven Security, Intl. Conf. on the Unified Modeling Language, London, UK. ACKNOWLEDGMENT [14] Jürjens, J., 2002. UMLsec: Extending UML for Secure Systems Gomaa’s research is supported by the Air Force Office of Development, Fifth International Conference on the Unified Scientific Research under grant number FA9550-16-1-0030. Modeling Language, London, UK. [15] Gomaa, H., Menasce, D. A., Shin, M. E., 2001. Reusable REFERENCES Component Patterns for Distributed Software Architectures, [1] Al-Azzani, S., Bahsoon, R., 2012. SecArch: Architecture-level Proceedings of ACM Symposium on Software Reusability, Evaluation and Testing for Security, Software Architecture ACM Press, Pages 69-77, Toronto, Canada, May. (WICSA) and European Conference on Software Architecture [16] Rumbaugh, J., Booch, G., Jacobson, I., 2004. The Unified (ECSA), Joint Working IEEE/IFIP Conference on, August. Modeling Language Reference Manual, Addison-Wesley. [2] Baker, C., Shin M., 2014. Aspect-Oriented Secure Connectors [17] H. Gomaa, K. Hashimoto, M. Kim, S. Malek, and D. A. for Implementation of Secure Software Architecture, Menascé, “Software Adaptation Patterns for Service-oriented International Conference on Software Engineering and Architectures,” Proceedings ACM Symposium on Applied Knowledge Engineering (SEKE’2014), Vancouver, Canada, Computing, Sierre, Switzerland, March 2010. July 1-3. [18] E. Albassam, H. Gomaa, and D. A. Menascé, “Model-based [3] Basin, D., Clavel, M., Egea, M., 2011. A Decade of Model- Recovery Connectors for Self-adaptation and Self-healing: Driven Security, 16th ACM symposium on Access control Design and Experimentation,” in Software Technologies, models and technologies, Innsbruck, Austria, June 15-17. Revised Selected Papers from the 11th International Joint [4] Fernandez, E. B., 2013. Security Patterns in Practice, Wiley. Conference, ICSOFT 2016, Lisbon, Portugal, July, 2016; [5] Gomaa, H., 2011. Software Modeling and Design: UML, Use Published by Springer, CCIS 743 pp. 108-131, 2017. Cases, Patterns, and Software Architectures, Cambridge University Press.