In this study we described the design and results of a systematic multivocal literature mapping of the security solutions that have been proposed for microservice-based systems. The study yielded 370 academic articles and 620 grey literature; duplicates removal and the application of exclusion criteria left 36 from the academic literature and 34 from the grey literature. The security solution(s) proposed in each article were classified into variations of standard security mechanisms (e.g., Access Control) and scopes (Info Management, Threat Modeling, etc), and were associated to security contexts (detect, mitigate/stop, react, recover from attack). Our research questions addressed frequency of publications, research methodologies, security mechanisms, and security contexts. Key findings were that (1) both kinds of literature differ in their preferred empirical research strategies (examples, experiments and case studies); (2) The solutions proposed in the 70 selected articles correspond to 15 classifications of security mechanisms and analyses; (3) the most mentioned security mechanisms are Authentication and Authorization; (4) around 2/3 of solutions focused on Mitigate/Stop attacks, but none on reacting and recovering from them, and (5) the methodologies used are mostly block diagrams and code, with little use of models or analysis. These findings hold for both grey and academic literature. This study is a first step towards providing secure software researchers and practitioners a comprehensive catalog of security solutions and mechanisms, and where the clear identification of the most used security solutions will simplify their reuse to address security problems while designing microservice-based systems.
We know that microservice-based systems promote agility and rapid business development. Some features, such as fast time-to-market, scalability and optimal response times, have encouraged stakeholders to get more involved in the development and implementation of microservices architectures in order to translate their business vision into the implementation of the architecture. We realized some techniques allow the inclusion of the stakeholders’ perspective in the design of microservice architectures, few proposals consider such perspectives in the selection and evaluation of technologies that implement microservice architectures. Indeed, the qualities that characterize microservice-based systems strongly depend on the suitable selection of technologies, such as application frameworks and platforms. We have proposed a collaborative technique that includes stakeholders and software architects to select and evaluate application frameworks and platforms to implement microservice-based systems. We evaluated the technique in an industrial case of design and implementation of an Ambient-Assisted Living (AAL) system, which combines microservice architecture and Internet-of-Medical-Things (IoMT) sensors.
Building Microservices Architecture (MSA)-based applications is immensely supported by using software testing fundamentals. With the increasing interest in the development of MSA-based applications, it is important to systematically identify, analyze, and classify the publication trends, research themes, approaches, tools, and challenges in the context of testing MSA-based applications. In order to know state of the art regarding testing and MSAs, we conducted a systematic mapping study.
The search yielded 2,481 articles, and 33 articles were finally selected as the primary studies with snowballing. The key findings are that (i) 5 research themes characterize testing approaches in MSA-based applications; (ii) integration and unit testing are the most popular testing approaches; and (iii) addressing the challenges in automated and inter-communication testing is gaining the interest of the community. Additionally, it emerges that there is a lack of dedicated tools to support testing for MSA-based applications, and the reasons and solutions behind the challenges in testing MSA-based applications need to be further explored.
Clinical software is a fundamental tool for supporting healthcare systems because it improves the quality of patient care and automatizes the most frequently performed clinical tasks. Nevertheless, since health systems include various components, such as supplies, transportation, laboratories, and interoperability, eliciting the most critical requirements for understanding the problem that the clinical software must solve is quite a complex task. Indeed, the requirement elicitation process may directly determine the success or failure of the clinical software. In this article, we present the D&I framework, a methodology that uses dissemination and implementation strategies to recommend guidelines for the elicitation of clinical software requirements. The objective of this framework is to support software developers in the identification of key requirements with the goal of more holistically understanding the problem to be solved by the clinical software. We evaluated the D&I framework with a real case study related to a bed management system. We employed a usability instrument with 50 clinicians to evaluate tasks in software modules that represent clinical priorities defined by stakeholders. The results indicate that the perception of usability by end-users is acceptable, suggesting that the evaluated tasks satisfy the established clinical priorities. The D&I framework provides a starting point for research and discussion about the contribution of dissemination and implementation strategies to the body of knowledge about requirement engineering.
There is no doubt that telemedicine is positioning itself as an alternative for medical consulting, especially in the pandemic times we live. Nevertheless, as telemedicine grows, so does the motivation to infringe these types of systems and perpetrate fraud.
In Chile, healthcare codes are increasingly being approved for telemedicine care . This is a significant advance for patients, but at the same time, it is a great challenge in terms of the confidentiality and privacy of patient data.
In order to have an overview of the current situation of reported security incidents in telemedicine, I have reviewed 46 public sources (press releases, blogs, web portals, forums, among others) to describe, in general, the factors surrounding security incidents in telemedicine. It is important to note that each information regarding security incidents can be investigated in detail. But, more specific data on these incidents is very restricted to the public (for obvious reasons, right?)
This overview aims to have a “starting point” for defining practices, guidelines, and policies to safeguard the confidentiality and privacy of telemedicine in Chile. Additionally, all efforts should be focused on reducing the most common security risks that exist in telemedicine, which are: (i) data integrity, (ii)confidentiality, (iii) availability, (iv) authentication, (v) traceability of transactions and (vi) attribution of acts .
Electronic Health Records (EHRs) are real-time, patient-centered records that instantly and securely make information available to authorized users. The information contained in EHRs is sensitive since, in general, it consists of the patient’s medical history (hospitalizations, treatments, illnesses, among others).
One of the most relevant aspects of EHRs is security. More specifically, Confidentiality and Privacy are critical attributes for security in EHRs. In this regard, assessing the security of EHRs (and systems, in general) is too complex. Security can be characterized from institutional policies to sophisticated attacks on software and critical infrastructure. Therefore, to help reduce this complexity, we are working on a quality model to evaluate the current state of EHR security to support security decision-making in software vendors and clinical facilities. The first version of this quality model was evaluated with 20 professionals from the Chilean healthcare industry.
We are improving the model and, at the same time, developing a platform that will allow us to automate this evaluation.
In the development of microservices-based systems, one of the typical questions that software developers ask is: Which technologies (such as frameworks and platforms) do I have to select to develop the microservices project? The market for frameworks and platforms to develop not only microservices-based systems but also all kinds of systems is too broad. So, What criteria should be used to select technologies? One “obvious” criterion is “the technology that is cheaper and takes less time”. But, this criterion is one of many that an architect should consider when developing a microservices-based system.
To help with this complex task, we have created a technique that allows evaluating sets of frameworks and platforms based on quality attributes.
This tool helps the software architect reduce the space of technological solutions in the market into a more specific set that allows her or him to satisfy the main non-functional requirements of a microservices project. To evaluate the technique, we used it in an industrial project, obtaining promising results.
Software Engineering can be applied in several fields, such as health. In this regard, there are many challenges that some health systems, such as Telehealth systems, promote in software development. Having said that, we investigated how Software Engineering helps to develop secure Telehealth systems. The findings of our research suggest that sophisticated requirements elicitation and the correct definition of software architectures are essential to satisfy security.
Software engineering literature describes several decision-making techniques for architectural design. However, the impact of the experience of those who use these techniques on their efficacy has been little explored.
We experimented with 24 IT practitioners in order to evaluate the impact of the experience of software architecture decision-making team members on the efficacy of TaSPeR (Tactics Selection Poker), a technique that supports architectural design decisions (inspired in the Planning Poker technique).
This research, led by Juan P. Brito, reveal that for teams with more experienced members the use of TaSPeR turned out to be harmful for the selection of software architecture tactics, in contrast to the more experienced teams, for which the use of TaSPeR was quite beneficial. Other key findings are discussed in the article.
This article was accepted in the International Conference of the Chilean Computer Science Society (SCCC).
Microservices architecture has become enormously popular because traditional monolithic architectures no longer meet the needs of scalability and rapid development cycle, and the success of some large companies in building and deploying services is a strong motivation for others to consider making the change.
However, performing the migration process is not trivial. Most systems acquire too many dependencies between their modules, and thus can’t be sensibly broken apart. It is for this reason that studies that provide information associated with the migration process to practitioners are necessary.
We have performed a rapid review to analyze the current state of the migration of monolith systems to microservices. In this investigation, led by Francisco Ponce, we discuss some key findings related to:
What techniques are used to migrate monolith systems to microservices?
What happens to databases during migration?
This article was accepted in the International Conference of the Chilean Computer Science Society (SCCC).