A Formal Engineering Approach for Interweaving Functional and Security Requirements of RESTful Web APIs

RESTful Web API adoption has become ubiquitous with the proliferation of REST APIs in almost all domains with modern web applications embracing the micro-service architecture. This vibrant and expanding adoption of APIs, has made an increasing amount of data to be funneled through systems which require proper access management to ensure that web assets are secured. A RESTful API provides data using the HTTP protocol over the network, interacting with databases and other services and must preserve its security properties. Currently, practitioners are facing two major challenges for developing high quality secure RESTful APIs. One, REST is not a protocol. Instead, it is a set of guidelines that define how web resources can be designed and accessed over HTTP endpoints. There are a set of guidelines which stipulate how related resources should be structured using hierarchical URIs as well as how specific well-defined actions on those resources should be represented using different HTTP verbs. Whereas security has always been critical in the design of RESTful APIs, there are no clear formal models utilizing a secure-by-design approach that interweaves both the functional and security requirements. The other challenge is how to effectively utilize a model driven approach for constructing precise requirements and design specifications so that the security of a RESTFul API is considered as a concern that transcends across functionality rather than individual isolated operations.This thesis proposes a novel technique that encourages a model driven approach to specifying and verifying APIs functional and security requirements with the practical formal method SOFL (Structured-Object-Oriented Formal Language). Our proposed approach provides a generic 6 step model driven approach for designing security aware APIs by utilizing concepts of domain models, domain primitives, Ecore metamodel and SOFL. The first step involves generating a flat file with APIs resource listings. In this step, we extract resource definitions from an input RESTful API documentation written in RAML using an existing RAML parser. The output of this step is a flat file representing API resources as defined in the RAML input file. This step is fully automated. The second step involves automatic construction of an API resource graph that will work as a blue print for creating the target API domain model. The input for this step is the flat file generated from step 1 and the output is a directed graph (digraph) of API resource. We leverage on an algorithm which we created that takes a list of lists of API resource nodes and the defined API root resource node as an input, and constructs a digraph highlighting all the API resources as an output. In step 3, we use the generated digraph as a guide to manually define the API’s initial domain model as the target output with an aggregate root corresponding to the root node of the input digraph and the rest of the nodes corresponding to domain model entities. In actual sense, the generated digraph in step 2 is a barebone representation of the target domain model, but what is missing in the domain model at this stage in the distinction between containment and reference relationship between entities. The resulting domain model describes the entire ecosystem of the modeled API in the form of Domain Driven Design Concepts of aggregates, aggregate root, entities, entity relationships, value objects and aggregate boundaries. The fourth step, which takes our newly defined domain model as input, involves a threat modeling process using Attack Defense Trees (ADTrees) to identify potential security vulnerabilities in our API domain model and their countermeasures. aCountermeasures that can enforce secure constructs on the attributes and behavior of their associated domain entities are modeled as domain primitives. Domain primitives are distilled versions of value objects with proper invariants. These invariants enforce security constraints on the behavior of their associated entities in our API domain model. The output of this step is a complete refined domain model with additional security invariants from the threat modeling process defined as domain primitives in the refined domain model. This fourth step achieves our first interweaving of functional and security requirements in an implicit manner. The fifth step involves creating an Ecore metamodel that describes the structure of our API domain model. In this step, we rely on the refined domain model as input and create an Ecore metamodel that our refined domain model corresponds to, as an output. Specifically, this step encompasses structural modeling of our target RESTful API. The structural model describes the possible resource types, their attributes, and relations as well as their interface and representations. The sixth and the final step involves behavioral modeling. The input for this step is an Ecore metamodel from step 5 and the output is formal security aware RESTful API specifications in SOFL language. Our goal here is to define RESTful API behaviors that consist of actions corresponding to their respective HTTP verbs i.e., GET, POST, PUT, DELETE and PATCH. For example, CreateAction creates a new resource, an UpdateAction provides the capability to change the value of attributes and ReturnAction allows for response definition including the Representation and all metadata. To achieve behavioral modelling, we transform our API methods into SOFL processes. We take advantage of the expressive nature of SOFL processes to define our modeled API behaviors. We achieve the interweaving of functional and security requirements by injecting boolean formulas in post condition of SOFL processes. To verify whether the interweaved functional and security requirements implement all expected functions correctly and satisfy the desired security constraints, we can optionally perform specification testing. Since implicit specifications do not indicate algorithms for implementation but are rather expressed with predicate expressions involving pre and post conditions for any given specification, we can substitute all the variables involved a process with concrete values of their types with results and evaluate their results in the form of truth values true or false. When conducting specification testing, we apply SOFL process animation technique to obtain the set of concrete values of output variables for each process functional scenario. We analyse test results by comparing the evaluation results with an analysis criteria. An analysis criteria is a predicate expression representing the properties to be verified. If the evaluation results are consistent with the predicate expression, the analysis show consistency between the process specification and its associated requirement. We generate the test cases for both input and output variables based on the user requirements. The test cases generated are usually based on test targets which are predicate expressions, such as the pre and post conditions of a process. when testing for conformance of a process specification to its associated service operation, we only need to observe the execution results of the process by providing concrete input values to all of its functional scenarios and analyze their defining conditions relative to user requirements. We present an empirical case study for validating the practicality and usability of our model driven formal engineering approach by applying it in developing a Salon Booking System. A total of 32 services covering functionalities provided by the Salon Booking System API were developed. We defined process specifications for the API services with their respective security requirements. The security requirements were injected in the threat modeling and behavioral modeling phase of our approach. We test for the interweaving of functional and security requirements in the specifications generated by our approach by conducting tests relative to original RAML specifications. Failed tests were exhibited in cases where injected security measure like requirement of an object level access control is not respected i.e., object level access control is not checked. Our generated SOFL specification correctly rejects such case by returning an appropriate error message while the original RAML specification incorrectly dictates to accept such request, because it is not aware of such measure. We further demonstrate a technique for generating SOFL specifications from a domain model via model to text transformation. The model to text transformation technique semi-automates the generation of SOFL formal specification in step 6 of our proposed approach. The technique allows for isolation of dynamic and static sections of the generated specifications. This enables our technique to have the capability of preserving the static sections of the target specifications while updating the dynamic sections in response to the changes of the underlying domain model representing the RESTful API in design. Specifically, our contribution is provision of a systemic model driven formal engineering approach for design and development of secure RESTful web APIs. The proposed approach offers a six-step methodology covering both structural and behavioral modelling of APIs with a focus on security. The most distinguished merit of the model to text transformation is the utilization of the API’s domain model as well as a metamodel that the domain model corresponds to as the foundation for generation of formal SOFL specifications that is a representation of API’s functional and security requirements.博士(理学)法政大学 (Hosei University

Towards a Catalogue of Reusable Security Requirements, Vulnerabilities and Threats

Organizations are giving more importance to secure their systems due to the increasing number of cyber-attacks and inherent complexity. The aim of our work is help organizations plan and consider these security concerns from the very beginning, since the requirements and design phases, and not just later in the implementation or deployment phases. Consider security-by-design and security-by-default principles are good approaches to avoid rework costs or to mitigate security flaws. However, there is not yet a suitable approach to specify security requirements in a rigorous and systematic way. In this paper we propose an approach that allows the definition and specification of security-specific concerns like security requirements but also vulnerabilities, risks or threats. We discuss this approach based on two key parts: First, we introduce the RSLingo RSL language, that is a rigorous requirements specification language, and discuss how it is extended to support such security-specific concepts. Second, we claim the relevance for a catalogue of reusable security-specific specifications and then we show concrete examples of defining and using such specifications. The proposed catalogue can be easily used and extended by the community and involves currently 52 goals, 12 vulnerabilities and 31 risks; these concerns are defined into 9 packages each one representing a distinct asset

Management of Security Risks in the Enterprise Architecture using ArchiMate and Mal-activities

Turvalisuse tase on ettevõtte üks peamisi elemente, mida tuleb organisatsioonis kontrollida. Kui ettevõtte äri arengut modelleeritakse on eesmärgiks katkematu ettevõtlus, aga tihti ei võeta sellega arvesse turvanõudeid. Selliselt on aga infosüsteemi kõrget turvalisuse taset väga raske säilitada. Selles dokumendis käsitletakse lähenemisviisi, mis parandab julgeoleku vastumeetmeid, et selleläbi aidata ettevõtte arhitektuuri turvalisemaks muuta. Ettevõtte arhitektuurimudeli ja turvariski juhtimise vaheliste soeste leidmine toimub läbi Infosüsteemi turvariskide juhtimise domeeni mudeli (ISSRM). Ettevõtte arhitektuuri modelleerimiseks on kasutatud ArchiMate modelleerimiskeelt. Paljudest riskide kirjeldamise keeltest on sobilikum mal-activity (pahatahtlikute tegevuste) diagrammid, sest see aitab julgeoleku riskide juhtimist kõige paremini visualiseerida. Struktureeritud joondus aitab ülalnimetatud keelte vahelisi seoseid näidata ning annab informatsiooni kõige haavatavamate punktide kohta süsteemis. Turvalisuse taseme säilitamine aitab ettevõttel äritegevust viia sõltumatuks infosüsteemist. Selle dokumendi tulemuseks on ArchiMate ja Mal-activity diagrammide vahelised seostetabelid ja reeglid. Nende kahe keele vaheliseks seoseks on ISSRM. Kirjeldatud lähenemise valideerimine on läbi viidud ühe näite põhjal, mis on võetud CoCoME juhtumiuuringust. Näite põhjal on loodud mitmeid illustreerivaid pilte valideerimise kohta. Kõige viimasena on kirjeldatud meetodiga saadud tulemust võrreldud Grandy et.al. (2013) poolt arendatud lähenemisega. Võtmesõnad: Infosüsteem, Infosüsteemi turvariskide juhtimine, ettevõtte arhitektuur, ettevõtte arhitektuuri mudel, julgeoleku vastumeetmed, turvariskide juhtimine, riskidele orjenteeritud modelleerimiskeeled, ArchiMate, mal-activity diagrammid.Security level of the enterprise is one of the main elements that should be taken under control in the organization. It is difficult to maintain high security level of Information System. Since development of enterprise architecture is targeted on continues business flow modeling, it sometimes does not take into account security requirements. The paper provides an approach to improve security countermeasures to contribute with secure Enterprise Architecture. Filling the gap between Enterprise Architecture model and Security Risk Management is done through Information System Security Risk Management domain model (ISSRM). To build the Enterprise Architecture model, ArchiMate modelling language is being used. Among different risk-oriented languages, selection was done in favor of Mal-activity diagrams, which help to provide visual concept of Security Risk Management. Structured alignment can show the mapping between aforementioned terms and provide the information about most vulnerable points of the system. The maintenance of security level will help to make business flow independent from the state of Information System. The outcome of this paper is an alignment tables and rules between ArchiMate and Mal-activity diagrams. The mapping link between these two languages is ISSRM. Validation of our approach is done on the example, which is taken from CoCoME case study. It is shown on number of illustrative pictures. After getting the results, there is a comparison of the output between presented method and approach developed by Grandry et.al. (2013). Keywords: Information System, Information System Security Risk Management, Enterprise Architecture, Enterprise Architecture model, security countermeasures, Security Risk Management, risk-oriented modelling languages, ArchiMate, Mal-activity diagrams

Modeling Deception for Cyber Security

In the era of software-intensive, smart and connected systems, the growing power and so- phistication of cyber attacks poses increasing challenges to software security. The reactive posture of traditional security mechanisms, such as anti-virus and intrusion detection systems, has not been sufficient to combat a wide range of advanced persistent threats that currently jeopardize systems operation. To mitigate these extant threats, more ac- tive defensive approaches are necessary. Such approaches rely on the concept of actively hindering and deceiving attackers. Deceptive techniques allow for additional defense by thwarting attackers’ advances through the manipulation of their perceptions. Manipu- lation is achieved through the use of deceitful responses, feints, misdirection, and other falsehoods in a system. Of course, such deception mechanisms may result in side-effects that must be handled. Current methods for planning deception chiefly portray attempts to bridge military deception to cyber deception, providing only high-level instructions that largely ignore deception as part of the software security development life cycle. Con- sequently, little practical guidance is provided on how to engineering deception-based techniques for defense. This PhD thesis contributes with a systematic approach to specify and design cyber deception requirements, tactics, and strategies. This deception approach consists of (i) a multi-paradigm modeling for representing deception requirements, tac- tics, and strategies, (ii) a reference architecture to support the integration of deception strategies into system operation, and (iii) a method to guide engineers in deception mod- eling. A tool prototype, a case study, and an experimental evaluation show encouraging results for the application of the approach in practice. Finally, a conceptual coverage map- ping was developed to assess the expressivity of the deception modeling language created.Na era digital o crescente poder e sofisticação dos ataques cibernéticos apresenta constan- tes desafios para a segurança do software. A postura reativa dos mecanismos tradicionais de segurança, como os sistemas antivírus e de detecção de intrusão, não têm sido suficien- tes para combater a ampla gama de ameaças que comprometem a operação dos sistemas de software actuais. Para mitigar estas ameaças são necessárias abordagens ativas de defesa. Tais abordagens baseiam-se na ideia de adicionar mecanismos para enganar os adversários (do inglês deception). As técnicas de enganação (em português, "ato ou efeito de enganar, de induzir em erro; artimanha usada para iludir") contribuem para a defesa frustrando o avanço dos atacantes por manipulação das suas perceções. A manipula- ção é conseguida através de respostas enganadoras, de "fintas", ou indicações erróneas e outras falsidades adicionadas intencionalmente num sistema. É claro que esses meca- nismos de enganação podem resultar em efeitos colaterais que devem ser tratados. Os métodos atuais usados para enganar um atacante inspiram-se fundamentalmente nas técnicas da área militar, fornecendo apenas instruções de alto nível que ignoram, em grande parte, a enganação como parte do ciclo de vida do desenvolvimento de software seguro. Consequentemente, há poucas referências práticas em como gerar técnicas de defesa baseadas em enganação. Esta tese de doutoramento contribui com uma aborda- gem sistemática para especificar e desenhar requisitos, táticas e estratégias de enganação cibernéticas. Esta abordagem é composta por (i) uma modelação multi-paradigma para re- presentar requisitos, táticas e estratégias de enganação, (ii) uma arquitetura de referência para apoiar a integração de estratégias de enganação na operação dum sistema, e (iii) um método para orientar os engenheiros na modelação de enganação. Uma ferramenta protó- tipo, um estudo de caso e uma avaliação experimental mostram resultados encorajadores para a aplicação da abordagem na prática. Finalmente, a expressividade da linguagem de modelação de enganação é avaliada por um mapeamento de cobertura de conceitos

Modeling Security and Privacy Requirements for Mobile Applications: a Use Case-driven Approach

Defining and addressing security and privacy requirements in mobile apps is a significant challenge due to the high level of transparency regarding users' (private) information. In this paper, we propose, apply, and assess a modeling method that supports the specification of security and privacy requirements of mobile apps in a structured and analyzable form. Our motivation is that, in many contexts including mobile app development, use cases are common practice for the elicitation and analysis of functional requirements and should also be adapted for describing security requirements. We integrate and adapt an existing approach for modeling security and privacy requirements in terms of security threats, their mitigations, and their relations to use cases in a misuse case diagram. We introduce new security-related templates, i.e., a mitigation template and a misuse case template for specifying mitigation schemes and misuse case specifications in a structured and analyzable manner. Natural language processing can then be used to automatically detect and report inconsistencies among artifacts and between the templates and specifications. Since our approach supports stakeholders in precisely specifying and checking security threats, threat scenarios and their mitigations, it is expected to help with decision making and compliance with standards for improving security. We successfully applied our approach to industrial mobile apps and report lessons learned and results from structured interviews with engineers

Certifications of Critical Systems – The CECRIS Experience

In recent years, a considerable amount of effort has been devoted, both in industry and academia, to the development, validation and verification of critical systems, i.e. those systems whose malfunctions or failures reach a critical level both in terms of risks to human life as well as having a large economic impact.Certifications of Critical Systems – The CECRIS Experience documents the main insights on Cost Effective Verification and Validation processes that were gained during work in the European Research Project CECRIS (acronym for Certification of Critical Systems). The objective of the research was to tackle the challenges of certification by focusing on those aspects that turn out to be more difficult/important for current and future critical systems industry: the effective use of methodologies, processes and tools.The CECRIS project took a step forward in the growing field of development, verification and validation and certification of critical systems. It focused on the more difficult/important aspects of critical system development, verification and validation and certification process. Starting from both the scientific and industrial state of the art methodologies for system development and the impact of their usage on the verification and validation and certification of critical systems, the project aimed at developing strategies and techniques supported by automatic or semi-automatic tools and methods for these activities, setting guidelines to support engineers during the planning of the verification and validation phases

Certifications of Critical Systems – The CECRIS Experience

In recent years, a considerable amount of effort has been devoted, both in industry and academia, to the development, validation and verification of critical systems, i.e. those systems whose malfunctions or failures reach a critical level both in terms of risks to human life as well as having a large economic impact.Certifications of Critical Systems – The CECRIS Experience documents the main insights on Cost Effective Verification and Validation processes that were gained during work in the European Research Project CECRIS (acronym for Certification of Critical Systems). The objective of the research was to tackle the challenges of certification by focusing on those aspects that turn out to be more difficult/important for current and future critical systems industry: the effective use of methodologies, processes and tools.The CECRIS project took a step forward in the growing field of development, verification and validation and certification of critical systems. It focused on the more difficult/important aspects of critical system development, verification and validation and certification process. Starting from both the scientific and industrial state of the art methodologies for system development and the impact of their usage on the verification and validation and certification of critical systems, the project aimed at developing strategies and techniques supported by automatic or semi-automatic tools and methods for these activities, setting guidelines to support engineers during the planning of the verification and validation phases

Threat Modelling and Analysis of Web Application Attacks

There has been a rapid growth in the use of the Internet over the years with billions of businesses using it as a means of communication. The World Wide Web has served as the major tool for disseminating information which has resulted into the development of an architecture used in information sharing between remotely connected clients. A web application is a computer program that operates on web technologies and browsers to carry out assignments over the Internet. In designing a secured web application, it is essential to assess and model the viable threats. Threat Modelling is a process used to improve on the application security by pointing out threats and vulnerabilities, outlining mitigation measures to prevent or eliminate the effect of threats in a system. With the constant increase in the number of attacks on web applications, it has become essential to constantly improve on the existing threat models to increase the level of security posture of web applications for proactiveness and strategic goals in operational and application security. In this thesis, three different threat models; STRIDE, Kill Chain and Attack Tree were simulated and analyzed for SQL injection and Cross Site Scripting attacks using the Microsoft SDL threat modelling tool, Trike modelling tool and SeaMonster modelling tool respectively. This study would be useful for future research in developing a new and more efficient threat model based on the existing ones, it would also help organizations determine which of the models used in this research is best suited for the business’ security framework. The objective of this thesis is to analyze the three commonly used models, examining the strengths and weaknesses discovered during the simulation and compare the performances

Conception Assistée des Logiciels Sécurisés pour les Systèmes Embarqués

A vast majority of distributed embedded systems is concerned by security risks. The fact that applications may result poorly protected is partially due to methodological lacks in the engineering development process. More specifically, methodologies targeting formal verification may lack support to certain phases of the development process. Particularly, system modeling frameworks may be complex-to-use or not address security at all. Along with that, testing is not usually addressed by verification methodologies since formal verification and testing are considered as exclusive stages. Nevertheless, we believe that platform testing can be applied to ensure that properties formally verified in a model are truly endowed to the real system. Our contribution is made in the scope of a model-driven based methodology that, in particular, targets secure-by-design embedded systems. The methodology is an iterative process that pursues coverage of several engineering development phases and that relies upon existing security analysis techniques. Still in evolution, the methodology is mainly defined via a high level SysML profile named Avatar. The contribution specifically consists on extending Avatar so as to model security concerns and in formally defining a model transformation towards a verification framework. This contribution allows to conduct proofs on authenticity and confidentiality. We illustrate how a cryptographic protocol is partially secured by applying several methodology stages. In addition, it is described how Security Testing was conducted on an embedded prototype platform within the scope of an automotive project.Une vaste majorité de systèmes embarqués distribués sont concernés par des risques de sécurité. Le fait que les applications peuvent être mal protégées est partiellement à cause des manques méthodologiques dans le processus d’ingénierie de développement. Particulièrement, les méthodologies qui ciblent la vérification formelle peuvent manquer de support pour certaines étapes du processus de développement SW. Notamment, les cadres de modélisation peuvent être complexes à utiliser ou ne pas adresser la sécurité du tout. Avec cela, l’étape de tests n’est pas normalement abordée par les méthodologies de vérification formelle. Néanmoins, nous croyons que faire des tests sur la plateforme peut aider à assurer que les propriétés vérifiées dans le modèle sont véritablement préservées par le système embarqué. Notre contribution est faite dans le cadre d’une méthodologie nommée Avatar qui est basée sur les modèles et vise la sécurité dès la conception du système. La méthodologie est un processus itératif qui poursuit la couverture de plusieurs étapes du développement SW et qui s’appuie sur plusieurs techniques d’analyse de sécurité. La méthodologie compte avec un cadre de modélisation SysML. Notre contribution consiste notamment à étendre le cadre de modélisation Avatar afin d’aborder les aspects de sécurité et aussi à définir une transformation du modèle Avatar vers un cadre de vérification formel. Cette contribution permet d’effectuer preuves d’authenticité et confidentialité. Nous montrons comment un protocole cryptographique est partiellement sécurisé. Aussi, il est décrit comment les tests de sécurité ont été menés sur un prototype dans le cadre d’un projet véhiculaire

Application Security Verification Standard Compliance Analysis of a Low Code Development Platform

Low-code development platforms (LCDPs) are software development platforms that use artificial intelligence to help automate simple and routine tasks and make the software development process faster. By 2024, 60% of application development expect to be done using these platforms. Even though these platforms are gaining popularity, they have not been popular research topics, and their security features have not been assessed. One way to conduct such an assessment is by using Application Security Verification Standard (ASVS). ASVS is a community-driven security standard for web applications and services. ASVS is made of three requirement levels, and the security controls become more strict when moved up. ASVS is designed to give organizations a tool to develop and maintain more secure applications. One example of an LCDP is OutSystems, which is said to be “designed for the developers, by the developers”. OutSystems belongs to the Leader category in the 2021 release of Gartner® Magic QuadrantTM for Enterprise Low-Code Application Platforms. In this thesis, we will conduct a first of its kind compliance analysis between OutSystems and ASVS levels 1 and 2 to find out if and how compliant OutSystems is with the standard. This kind of compliance analysis has not been done before. Based on our analysis, we will do a “lessons learned” and write a guideline on how to evaluate LCDPs’ security features in the future. The results themselves show that OutSystems, for the most part, is compliant with ASVS. The biggest deficiencies in OutSystems are with authentication and input validation. We show that the deficiencies with authentication are trivial to fix, but meeting the requirements with the input validation requires some work. From the assessment, we learned that assessing LCDPs is not completely similar to a traditional security assessment. We learned that some functionalities are pre-made, and the developer can not customise them. We found that it is easier to evaluate first if the platform meets the requirement. If not, then see if the developer can do something about it