SecReq
Notice bibliographique
Résumé
The goal of SecReq [2] is to assist all steps in security requirements elicitation, as well as providing mechanisms to trace security requirements from high-level security statements (security objectives) to rather secure design. The approach aims at bridging the gap between security best practises and the lack of security experience among developers and designers. SecReq combines three distinctive techniques that have been integrated to meet this goal: (1) Common Criteria [1] and its underlying security requirements elicitation and refinement process, (2) the HeRA tool [4] with its security-related heuristic rules, and (3) the UMLsec tool set [3] for security analysis and design. In order to let others reproduce our results, we share our data and tools here. Expert Classification of requirements: In order to train and evaluate heuristic classifiers that identify security-relevant requirements, we need pre-classified requirements. Download our Expert-Classification of ePurse-Specification. Training and Testdata: From the expert classification, we derive sets of classified requirements for training and evaluation. These are simple CSV files, for the three specifications in our evaluation: ePurse, the Common Electronic Purse Specification [6] CPN, the Customer Premises Network specification [7] GPS, the Global Platform Specification [8] Evaluation tool: In order to apply our training and evaluation datasets, we created a tool that manages the evaluation. It allows to load different datasets, apply them to a heuristic classifier, and evaluate the results. Please download and try our Evaluation Tool. Extract the Zip, start the secreqEvaluationTool.jar, and add one or more of the specifications from above via the file menu. Specify, which requirements should be used for training either manually or via the edit menu. Train and use the classifier via the Actions menu. Resize the window, to make the statistics in the bottom line visible. Use Tools - explain selected to analyse the data. If a requirement is selected, the tool displays the information it has about each word in the requirement. If no requirement is selected, the tool shows the trained database. To get a visualisation of the performance of the classifiers, use Actions - K-fold cross validation. The analysis uses the requirements already loaded, but ignores training and classifier selections. We used a Bayesian classifier with classic parameters for our evaluation. References ISO 15408:2007 Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 2, CCMB-2007-09-001, CCMB-2007-09-002 and CCMB-2007-09-003, September 2007. Siv Hilde Houmb, Shareeful Islam, Eric Knauss, Jan Jürjens, and Kurt Schneider. Eliciting Security Requirements and Tracing them to Design: An Integration of Common Criteria, Heuristics, and UMLsec. Requir. Eng., 15(1):63-93, March 2010. Jan Jürjens. Secure Systems Development with UML. Springer Academic Publishers, Heidelberg, 2005. Eric Knauss, Daniel Lübke, and Sebastian Meyer. Feedback-Driven Requirements Engineering: The Heuristic Requirements Assistant. In 31st International Conference on Software Engineering (ICSE 2009), pages 587-590, Vancouver, Canada, 2009. Knauss, E.; Houmb, S.; Schneider, K.; Islam, S. & Jürjens. Supporting Requirements Engineers in Recognising Security Issues. In Proceedings of 17th Intl. Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ'11), Springer, 2011 CEPSCO: Common Electronic Purse Specification (ePurse), http://web.archive.org/web/20070203044348/http://www.cepsco.com/ (accessed April 2007) TISPAN, ETSI: Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Services requirements and capabilities for customer networks connected to TISPAN NGN. Technical report, European Telecommunications Standards Institute GlobalPlatform: Global Platform Specification (GPS), http://www.globalplatform.org (accessed August 2010)
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 enseignantsNi 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.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,001 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,001 |
| Études des sciences et des technologies | 0,002 | 0,000 |
| Communication savante | 0,003 | 0,000 |
| Science ouverte | 0,004 | 0,004 |
| Intégrité de la recherche | 0,000 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,014 | 0,014 |
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.
score_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écouleClassification
machine, non validéePrédiction automatique; les deux têtes enseignantes s’accordent sur ce qui est montré ici.
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 ».