MétaCan
Menu
Retour à la cohorte
Enregistrement W2504374816 · doi:10.4018/978-1-59904-090-5.ch016

Software Specification and Attack Languages

2007· book-chapter· en· W2504374816 sur OpenAlexaff
Mohammed Hussein

Notice bibliographique

RevueIGI Global eBooks · 2007
Typebook-chapter
Langueen
DomaineComputer Science
ThématiqueSoftware Engineering Research
Établissements canadiensQueen's University
Organismes subventionnairesnon disponible
Mots-clésComputer scienceProgramming languageSoftware engineeringSoftware security assuranceSoftware developmentSoftware requirements specificationSpecification languageSoftware constructionSoftwareComputer securityInformation securitySecurity service

Résumé

récupéré en direct d'OpenAlex

General-purpose software specification languages are introduced to model software by providing a better understanding of their characteristics. Nevertheless, these languages may fail to model some nonfunctional requirements such as security and safety. The necessity for simplifying the specification of nonfunctional requirements led to the development of domain-specific languages (e.g., attack description languages). Attack languages are employed to specify intrusion detection related aspects like intrusion signatures, normal behavior, alert correlation, and so forth. They provide language constructs and libraries that simplify the specification of the aforementioned intrusion detection aspects. Attack languages are used heavily due to the rapid growth of computer intrusions. The current trend in software development is to develop the core functionalities of the software based on the requirements expressed in general-purpose software specification languages. Then, attack languages and other security mechanisms are used to deal with security requirements. However, using two sets of languages may result in several disadvantages such as redundant and conflicting requirements (e.g., usability vs. security). Moreover, incorporating security at the latter stages of a software life cycle is more difficult and time consuming. Many research works propose the unification and reconciliation of software engineering and security engineering in various directions. These research efforts aim to enable developers to use the current software engineering tools and techniques to specify security requirements. In this chapter, we present a study on the classification of software specification languages and discuss the current state of the art regarding attack languages. Specification languages are categorized based on their features and their main purposes. A detailed comparison among attack languages is provided. We show the example extensions of the two software specification languages to include some features of the attack languages. We believe that extending certain types of software specification languages to express security aspects like attack descriptions is a major step towards unifying software and security engineering.

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.

Comment cette classification a été obtenuedéplier

Prédiction distillée sur la base complète

Imitation des enseignants

Ni prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.

score de la tête « metaresearch » (Codex)0,000
score de la tête « metaresearch » (Gemma)0,000
Version: codex-gemma-dda1882f352aStatut de validation: machine_predicted_unvalidated
Catégories candidatesMéta-épidémiologie (sens strict)
Catégories consensuellesaucune
DomaineSignal candidat: aucune · Signal consensuel: aucune
Devis d'étudeSignal candidat: Théorique ou conceptuel · Signal consensuel: aucune
GenreSignal candidat: Autre · Signal consensuel: Autre
Score de désaccord entre enseignants0,680
Score d'incertitude au seuil1,000

Scores Codex et Gemma par catégorie

CatégorieCodexGemma
Métarecherche0,0000,000
Méta-épidémiologie (sens strict)0,0000,000
Méta-épidémiologie (sens large)0,0000,000
Bibliométrie0,0000,000
Études des sciences et des technologies0,0000,000
Communication savante0,0000,000
Science ouverte0,0010,000
Intégrité de la recherche0,0000,000
Charge utile insuffisante (le modèle a refusé de juger)0,0000,000

Scores machine (provisoires)

Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.

Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.

Tête enseignante Opus0,040
Tête enseignante GPT0,301
Écart entre enseignants0,262 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validationscore_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle

Classification

machine, non validée

Prédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.

Devis d'étudeThéorique ou conceptuel
Domainenon disponible
GenreAutre

Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».

En bref

Citations2
Publié2007
Routes d'admission1
Résumé présentoui

Explorer davantage

Même revueIGI Global eBooksMême sujetSoftware Engineering ResearchTravaux en français237 207