Search icon CANCEL
Subscription
0
Cart icon
Cart
Close icon
You have no products in your basket yet
Save more on your purchases!
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletters
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Security-Driven Software Development

You're reading from  Security-Driven Software Development

Product type Book
Published in Mar 2024
Publisher Packt
ISBN-13 9781835462836
Pages 262 pages
Edition 1st Edition
Languages
Author (1):
Aspen Olmsted Aspen Olmsted
Profile icon Aspen Olmsted
Toc

Table of Contents (20) Chapters close

Preface 1. Part 1: Modeling a Secure Application
2. Chapter 1: Security Principles 3. Chapter 2: Designing a Secure Functional Model 4. Chapter 3: Designing a Secure Object Model 5. Chapter 4: Designing a Secure Dynamic Model 6. Chapter 5: Designing a Secure System Model 7. Chapter 6: Threat Modeling 8. Part 2: Mitigating Risks in Implementation
9. Chapter 7: Authentication and Authorization 10. Chapter 8: Input Validation and Sanitization 11. Chapter 9: Standard Web Application Vulnerabilities 12. Chapter 10: Database Security 13. Part 3: Security Validation
14. Chapter 11: Unit Testing 15. Chapter 12: Regression Testing 16. Chapter 13: Integration, System, and Acceptance Testing 17. Chapter 14: Software Penetration Testing 18. Index 19. Other Books You May Enjoy

Stereotypes

UML allows you to extend and customize its standard notations and semantics through stereotypes. Stereotypes are a way to add domain-specific or application-specific information to your UML models. When representing security requirements in UML, you can use stereotypes to indicate specific security-related elements or aspects within your diagrams. Developers use common stereotypes, but it is essential to realize you can build your own and are not limited to the common ones. Here are some common UML stereotypes and how they can be used to represent security requirements:

  • <<security>>: This stereotype can be applied to various UML elements to indicate that they have security implications. Here are some examples:
    • A class with <<security>> stereotype might imply that it contains sensitive data or requires access control
    • A use case with <<security>> stereotype may indicate that it involves authentication or authorization
  • <&lt...
lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €14.99/month. Cancel anytime}