Defining a Secure Software Process for Effective Security Planning

Chapter 22: Defining a Secure Software Process Info Security Planning Susan Lincke

Security Planning: An Applied Approach | 4/12/2025| 2 Standards we will look at: Two models with > 100 organizations participating in design Building Security In Maturity Model (BSIMM) 3 levels: Emerging, Maturing, Optimizing (and Level 0) Payment Card Industry Secure Software Standard (PCI SSS) Certifies payment card applications and devices

Security Planning: An Applied Approach | 4/12/2025| 3 BSIMM Versus OWASP SAMM Building Security In Maturity Model (BSIMM) OWASP Software Assurance Maturity Model (SAMM) Strategy & Metrics Policy & Compliance Education & Guidance Threat Assessment Security Requirements Secure Architecture Secure Build Secure Deployment Defect management Architecture Assessment Requirements-Driven Testing Security Testing Incident Mgmt. Environment Mgmt. Operational Mgmt. Strategy & Metrics Compliance & Policy Training Attack Models Security Features & Design Standards & Requirements Architectural Analysis Code Review Governance Governance Intelligence Secure Software Development Life Cycle Touchpoints Design Implementation Security Testing Verification Penetration Testing Software Environment Configuration Mgmt. & Vulnerability Mgmt. Deployment Operations

Security Planning: An Applied Approach | 4/12/2025| 4 Secure Software Initiative Governance Engineering Functions: Environment: Agile, lean processes Developing policies Dev-Ops: Development Operations Monitoring compliance Cloud s Continual Integration, continual delivery (CI/CD) Documenting risk Use of 3rdparty software, containers Communicating management direction. Goals: rapid delivery or feature velocity error avoidance software resiliency With CI/CD tools (e.g., Git Hub, Git Lab and OpenShift) vulnerabilities and remediations can be shared with external organizations.

Security Planning: An Applied Approach | 4/12/2025| 5 Secure Software Group Secure Development Software Group Secure Software Mgr Developers Secure Software Engineers Satellite

Security Planning: An Applied Approach | 4/12/2025| 6 Secure Software Group Secure Software Manager Secure Software Group Leads Secure Software Group: a centralized technical group Technical security guidance to organization: write security-related software Champion for secure software in executive management: evaluate third-party software educate top management monitor development projects define policy ensure developer training for security lead and prioritize secure software participate in design and code reviews. communicate issues to top mgmt identify regulatory requirements (with lawyers) monitor progress via metrics establishes service level agreements and contractual obligations evaluate PII requirements prepare data classification

Security Planning: An Applied Approach | 4/12/2025| 7 Satellite Satellite: security champions in development groups, who can represent security interests locally to each project. Available to Satellite: security portal listing security standards Inform as to appropriate open source software establish a standards review board

Security Planning: An Applied Approach | 4/12/2025| 8 Confidentiality Integrity Availability Secure UML SECURE PROGRAMMING & SECURE TEST

Security Planning: An Applied Approach | 4/12/2025| 9 Coding BSIMM recommends code reviews the basic maturity level, including: automated tools (e.g., static analysis) manual reviews of high-risk code all projects should go through code reviews tool mentors guide through automated reviews document reviews in centralized reporting mechanism

Security Planning: An Applied Approach | 4/12/2025| 10 Testing Test Stage Purpose is to: verify that the code fulfills the requirements validate that the code works as expected Bug Bar: (=Defect threshold) A minimum standard of acceptance is detailed and used in developing test plans for certification

Security Planning: An Applied Approach | 4/12/2025| 11 Segregation of Duties Code review: automated static analysis Manual review: high-risk code Development Primary goals differ: Developers: get code to work Quality control: find bugs. Formally test products Tests for security: boundary- value, fuzz testing Quality Control Configuration Management: Separation of code environments 1. Development approval -> Monitor logs and acts Provides feedback of defects in change control 2. Quality control approval -> Production 3. Production

Security Planning: An Applied Approach | 4/12/2025| 12 Test Tools Fuzz testing generates random input to test exception handling and input validation. Vulnerability scanners test for web attacks: integer, float or string overflows, SQL injection and cross-site scripting Web spiders parse website(s) to find embedded links Follows all links recursively to determine full connectivity of a website. Finds cross-site scripting in websites Manual penetration tests are tailored for specific applications Actually break into the system Proxies and vulnerability scanners allow dynamic packet creation.

Security Planning: An Applied Approach | 4/12/2025| 13 Reliability Tests Reliability testing ensures software can survive unusual conditions: Simulate faults to debug error handling unusual operating conditions (e.g., cold or warm weather) load testing: many simultaneous users, to evaluate performance and bottlenecks low memory, low disk conditions insufficient privileges break connection before transaction completes Software may slow down but should not crash or generate incorrect results Software failures can impact human life For mission critical code, functions shall not fail; failure rate must be known.

Security Planning: An Applied Approach | 4/12/2025| 14 Third Party Code Third party code: Viewed as a quick way to coding but can be risky select highly trusted third-party code and inspect/vet it well Minimize code to include only required features; test well High maturity levels of BSIMM [BSIMM20] recommends: evaluate code within a jail or sandbox to quarantines untrusted program monitor with protocol analyzers to ensure that (e.g.,) only strong encryption algorithms are used

Security Planning: An Applied Approach | 4/12/2025| 15 Penetration Testing Manual penetration testing is essential requires knowledgeable penetration testers Tools can help in manual testing: Dynamic packet creation Proxy: intercepts commands and responses between the browser and the server, enabling the user to view and modify the packet before transmission BSIMM recommends: Internal AND external penetration testing Perform penetration testing periodically Penetration testers are provided information about the application Discovered security flaws are tracked in change control

Security Planning: An Applied Approach | 4/12/2025| 16 Web Testing Tools Product Features Paros Supports automated and dynamic manual testing OWASP Zed Attack Proxy (ZAP) Supports automated and dynamic manual testing Fortify Commercial product: supports static analysis and automated vulnerability scanning of traditional web and mobile interfaces Acunetix web vulnerability scanner Commercial product: feature set includes HTTP, SOAP, AJAX and flash content

Security Planning: An Applied Approach | 4/12/2025| 17 Bug Bar Example Bug Bar Standard for Tampering and Repudiation Permanent modification of any user data in a common scenario that persists after restarting the OS/application. Permanent modification of any user data in a specific scenario, or temporary modification of user data in a common scenario. Temporary modification of data in a specific scenario that does not persist after restarting the OS/application. Microsoft s Bug Bar Standard Measures effects of security defects Effects are most important and reliable attribute in measuring a security fault Defect levels include: high, moderate or low At Left: simplified sample for the Tampering and Repudiation threat category Severity High Moderate Low

Security Planning: An Applied Approach | 4/12/2025| 18 Certification & Accreditation Independent Testers Meets standard Certification Administrative process approves the product for production and use Ensure that complete products, including IT and non-IT components, operate properly in the full operational environment Accreditation

Security Planning: An Applied Approach | 4/12/2025| 19 Software Release and Deployment Software is properly configured, patched and monitored. Network and host computer are optimized for security Highly secure server applications are placed in own container or physical or virtual machine Deployment configuration is fully documented Code protected to ensure integrity Configuration lockdown: configuration, environment, data files inaccessible to users Attacks and logs are monitored Discovered defects tracked for fixing by development Developed software should be maintained and patched Regularly patch software the application relies on: O.S., database. Patched software should come with full documentation, including reason(s) for the patch

Security Planning: An Applied Approach | 4/12/2025| 20 Evil User Stories Test Cases AGILE DEVELOPMENT

Security Planning: An Applied Approach | 4/12/2025| 21 Agile Development Security training is important! Include Evil User Stories in every Sprint "As a hacker, I send bad data in forms, so I can modify the database in unauthorized ways." Analyze risk at start of sprint, backlog change Address Security features authentication, access control, input validation, output encoding, error/exception handling, encryption, data integrity, logging and alarms, and data communication security Review code for security: pairs or group review for critical code Test using code analyzers, fuzz testing, auto/manual penetration tests

Security Planning: An Applied Approach | 4/12/2025| 22 Developing Evil User Stories <evil user> lazy employee incompetent employee evil employee Criminal evil customer thoughtless customer foreign nation-state evil hacker Hacktivist <do wrong> forget to incorrectly steal change... impersonate mistakenly implant replay break <a goal or issue> lost/incorrect deny sell change record obtain (service or info) lost destroy.., demonstrate embarrass

Security Planning: An Applied Approach | 4/12/2025| 23 Developing Security Stories <role> nurse <action> request info on A <condition> prevent social engineering detect fraud/collusion manager monitor <reports/metrics> establish permissions monitor <logs/events> enforce <authentication/ access control> check validate test document B info security staff system admin database prevent incorrect X detect <failure/attack> prevent inappropriate use of software system programmer tester manager enforce Y regulation prevent and log correct Z mistakes enforce W policy

Security Planning: An Applied Approach | 4/12/2025| 24 Example Evil User Stories: University Evil User Story Corresponding Security Story As a failing student, I use a password dictionary to break into a professor s grades to change my grade. prevent password guessing. As a budding script kiddie, I try different hacking tools on university websites for fun. addresses, find offending students and charge them. As a criminal cyber-hacker, I try to break into student accounts to learn their social security and credit card numbers. prevent exfiltration of data. Test Case Case 1: Test Learning Mgmt System (LMS) Login System Case 2: Test LMS Attack Logs As a system administrator, I require passwords to be 10 characters long and lock out accounts after 6 invalid attempts, to As a system administrator at the university, I monitor illegal accesses, note their IP As a network administrator, I partition the confidential zone within the firewall and monitor for specific, legal protocols to Case 3: Test Firewall Configuration Case 4: Test Registration Login System Case 5: Test grant budget vs. expense report As a professor with a grant, I am too busy to be careful that the money I spend is according to my grant contract. As a financial officer in charge of grants, I review grant expenses to ensure they are in line with the approved grant.

Security Planning: An Applied Approach | 4/12/2025| 25 Test Case: Test Purpose Test Case: Create Patient Information Test Case ID: 3 Test Purpose: 1. Ensure a valid new client can be entered into the system, and the appropriate tabs are created. 2. Ensure a duplicate entry is not created for an existing patient. 3. Ensure invalid data is detected, including wrong data types, overflow text, overflow math numbers, blank required fields, and inappropriate data. 4. Ensure logs are created for attacks, including overflow, business rule violations and SQL errors or injection. 5. Ensure encrypted transaction log is created documenting the transaction, and the author and time of the transaction. Primary Actors: Medical Administrator (Nurse, Doctor) Preconditions: The tester is at the main menu.

Security Planning: An Applied Approach | 4/12/2025| 26 Test Case: Flow of Events Flow of Events: 1. The test case begins when a Medical Admin selects Manage Patient or as an extension to Make Appointment 2. The Tester: enters last and first name for an existing patient and presses Create . 3. While the system finds a matching record 1. The system displays an error message: Match Exists , and requests the tester revise the information. 2. The tester changes the name to a new patient name. 4. The system displays multiple tabs, including Patient Information (Form 6.2, Patient Medical History (Form 6.3), and Patient Medical Information (Form 6.4). 5. The system renames the Create button into the Save button. 6. The tester enters inappropriate data types for each field of the new Patient and presses Save . 7. The system recognizes the invalid information and gives error messages. 8. The tester enters too much information for text strings or overflow data for arithmetic fields for each field of the new Patient and presses Save . 9. The system recognizes the overflow, gives error messages, and logs the error.

Security Planning: An Applied Approach | 4/12/2025| 27 10. The tester leaves some required fields empty for the new Patient and presses Save . 11. The system recognizes the lacking information and gives error messages. 12. The tester enters inappropriate information (violating business rules) for many fields of the new Patient and presses Save (e.g, illegal state, sex, number of children>10, illegal insurance, etc.) 13. The system recognizes the errors and gives error messages. 14. The tester enters SQL injection attack in many fields. 15. The system recognizes the attack, indicates an error, and logs the specific command executed. 16. The tester enters valid information for the new Patient and presses Save . 17. The system displays: Record Updated 18. The system creates a Patient Plan Management (Form 6.5) tab for Patients with health plans, or a Patient Bill Management tab for Patients without. 19. The tester confirms the creation of the new tabs and that a new encrypted transaction log saved the new patient record, including who and when the transaction was saved. 20. The tester confirms that SQL injection attacks and business rule violations are logged.

Security Planning: An Applied Approach | 4/12/2025| 28 Test Case: Postconditions Postconditions: 1. The new record has been saved into the test database. 2. For Patients with health plans, a Patient Plan Management tab is available with information about the Patient s plan. Management tab is provided. 3. Logs exist for attack conditions: SQL attacks and violation of business rules. 4. An encrypted transaction log includes the new records, including who and when the transaction occurred. For Patients without, a Patient Bill

Security Planning: An Applied Approach | 4/12/2025| 29 Shall payment card information be more secure than SSN, medical info, financial info? Secure Software Lifecycle Requirements and Assessment Procedures PAYMENT CARD INDUSTRY (PCI) SOFTWARE SECURITY FRAMEWORK (SSF)

Security Planning: An Applied Approach | 4/12/2025| 30 Security Governance Responsibility for secure software assigned by senior management: Allocate sufficient authority to enforce security policy Report back periodically with metrics on security goals and strategy. Maintain inventory of security standards and regulation, reviewed annually. Adopt a secure industry-standard process (e.g., BSIMM, ISO/IEC 27034, or OpenSAMM) to build security in. establish checkpoints to ensure security requirements are met agile stories , change management, code reviews, testing, and/or release criteria. Track checkpoints in order to quantify and reduce security vulnerabilities Maintain updated security training specific to developer s technologies Enforce assigned developer security responsibilities

Security Planning: An Applied Approach | 4/12/2025| 31 Threat and Vulnerability Identification Classify critical assets for confidentiality, integrity and availability. Evaluate threats using frameworks or reports: e.g., SANS or MITRE, industry risk, internal assessment, and/or academic papers. Evaluate and test third-party or open-source code for vulnerabilities. Justify, document, and approve threats and vulnerabilities at the appropriate levels Analyze and document controls using risk management documentation, feature lists, rigorous testing, monitoring of live systems, and/or a bug bounty program. Perform security testing throughout the lifecycle, including after software release Maintain an inventory of tests including documentation describing when and which tests were run, testing results, and identified vulnerabilities. Rate vulnerabilities for severity and criticality Fix and patch defects in a timely manner in released and production software.

Security Planning: An Applied Approach | 4/12/2025| 32 Secure Data Management Configuration management tracks all defects and changes to code including: security impact of a feature what changes were required who made the changes who authorized its release. Version control tracks files in each release. Configuration management advantages: protect software against unauthorized changes, secure intellectual property, ensure fixes carry through new releases, manage third-party software. Integrity checks, digitally signed certificates and periodic configuration management audits are useful to detect unauthorized changes to software.

Security Planning: An Applied Approach | 4/12/2025| 33 Secure Data Management Process, store, transmit, handle PCI in a minimal way according to documented business need Restrict access control privileges Enforce strong encryption protect access during processing Delete or render irretrievable any traces of the data after processing. Protect production data: shall not be accessible during debugging, testing or troubleshooting Maintain a clear process and inventory for tracking and approving the use of sensitive production data

Security Planning: An Applied Approach | 4/12/2025| 34 Secure Communications: To Stakeholders Guide software delivery to stakeholders Ensure system is securely installed, configured and managed Install proper libraries: encryption, random number generators Enable customer configuration: create/delete accounts, change passwords and permissions, and enable/disable services or features Include in vendor documentation detailed: secure installation instructions operation instructions each configuration and security-related option. Review and update documentation annually or when changes occur, and Communicate updates to customers.

Security Planning: An Applied Approach | 4/12/2025| 35 Secure Communications: Maintenance Maintain commercial software. Communication between software vendors and customers is two-way: vendors maintain and support their software, and work with customers or installers to properly operate the software. Vendors must use detailed notifications to: issue patches for vulnerabilities in a timely manner, issue directions for installation. describe patches/changes and the areas of impact, to enable customers to make informed decisions of when to implement fixes. Describe any security workarounds before fixes are available Vendors shall provide an email address for external communications, e.g., reported bugs from the research community or bug bounty program.

Security Planning: An Applied Approach | 4/12/2025| 36 Secure Communications: Certification The PCI certification process is rigorous involving review of documentation, interviews and observations. Required documentation during the certification audit includes threat and risk analysis, software architecture and design documentation, configuration and metadata information, testing results and defect data, source code, and policy documentation.

Security Planning: An Applied Approach | 4/12/2025| 37 Common Criteria Common Criteria (CC) (www.commoncriteriaportal.org) International standard for product development and testing, with a rating system between 1-7. Certifies access control devices, biometric devices, databases, smart card systems, key management systems and GDPR privacy-compliant products. Became international standard ISO/IEC 15408 Information security, cybersecurity and privacy protection Evaluation criteria for IT security CC replaces the Rainbow Series (including the Orange Book or Red Book) in American government contracts.

Security Planning: An Applied Approach | 4/12/2025| 38 CHECK YOUR UNDERSTANDING

Security Planning: An Applied Approach | 4/12/2025| 39 Vocabulary A system that tracks changes to software including impact, including what changes were required, who made the changes, and who authorized its release. Configuration Management Evil user story A technique used in agile development to describe an attack. Satellite A technique used in agile development to describe how to counter an attack. Secure Software Group A method of measuring the sophistication level of the software development process for handling security issues. Security story Segregation of Duties A department which leads security reviews and develops secure software and standards. Maturity Model A member of a development group with an interest or role in security guidance. The development, test and production environment use separate software and test data library systems.

Security Planning: An Applied Approach | 4/12/2025| 40 Vocabulary This tool develops random input to test handling of exceptions and incorrect input. Reliability Test This test technique ensures that software can survive unusual conditions, such as faults, errors, loading and low resources. Bug Bar Fuzz Test A test for untrusted programs, which quarantines the software to observe actions. A threshold level of security flaws is defined. Before release, software must meet this threshold. Sandbox This test uses inappropriate authorization to attempt to break into software. Version Control A feature of configuration management tracks files in a particular software release Pen Test

Security Planning: An Applied Approach | 4/12/2025| 41 Summary Building Security Into Software Designers and developers are trained in standard security practices High priority risks are analyzed, mitigated and fully documented Third-party software is thoroughly analyzed and vetted. Agile techniques include evil user stories, security stories, security tests Segregation of Duties include roles and configuration management: developers, testers, production Communications include detailed installation, configuration, patching, workarounds Knowledgeable testers perform competent penetration testing and use automated test tools for faster, more accurate testing. The code may still be released before all bugs are fixed, but the organization knows and approves of any security flaws that remain. Deployed software is monitored and defects are fixed in released code

Security Planning: An Applied Approach | 4/12/2025| 42 Within Security Plan document: Step 1: Develop Evil User Stories and Security Stories Step 2: Develop Test Cases appropriate to the Evil User Stories EXERCISE

Security Planning: An Applied Approach | 4/12/2025| 43 Developing Evil User Stories <evil user> lazy employee incompetent employee evil employee Criminal evil customer thoughtless customer foreign nation-state evil hacker Hacktivist <do wrong> forget to incorrectly steal change... impersonate mistakenly implant replay break <a goal or issue> lost/incorrect deny sell change record obtain (service or info) lost deny.., demonstrate embarrass

Security Planning: An Applied Approach | 4/12/2025| 44 Developing Security Stories <role> nurse <action> request info on A <condition> prevent social engineering detect fraud/collusion manager monitor <reports/metrics> establish permissions monitor <logs/events> enforce <authentication/ access control> check validate test document B info security staff system admin database prevent incorrect X detect <failure/attack> prevent inappropriate use of software system programmer tester manager enforce Y regulation prevent and log correct Z mistakes enforce W policy

Security Planning: An Applied Approach | 4/12/2025| 45 Example Evil User Stories: University Evil User Story Corresponding Security Story As a failing student, I use a password dictionary to break into a professor s grades to change my grade. prevent password guessing. As a budding script kiddie, I try different hacking tools on university websites for fun. addresses, find offending students and charge them. As a criminal cyber-hacker, I try to break into student accounts to learn their social security and credit card numbers. prevent exfiltration of data. Test Case Case 1: Test Learning Mgmt System (LMS) Login System Case 2: Test LMS Attack Logs As a system administrator, I require passwords to be 10 characters long and lock out accounts after 6 invalid attempts, to As a system administrator at the university, I monitor illegal accesses, note their IP As a network administrator, I partition the confidential zone within the firewall and monitor for specific, legal protocols to Case 3: Test Firewall Configuration Case 4: Test Registration Login System Case 5: Test grant budget vs. expense report As a professor with a grant, I am too busy to be careful that the money I spend is according to my grant contract. As a financial officer in charge of grants, I review grant expenses to ensure they are in line with the approved grant.

Security Planning: An Applied Approach | 4/12/2025| 46 Test Case: Test Purpose Test Case: Create Patient Information Test Case ID: 3 Test Purpose: 1. Ensure a valid new client can be entered into the system, and the appropriate tabs are created. 2. Ensure a duplicate entry is not created for an existing patient. 3. Ensure invalid data is detected, including wrong data types, overflow text, overflow math numbers, blank required fields, and inappropriate data. 4. Ensure logs are created for attacks, including overflow, business rule violations and SQL errors or injection. 5. Ensure encrypted transaction log is created documenting the transaction, and the author and time of the transaction. Primary Actors: Medical Administrator (Nurse, Doctor) Preconditions: The tester is at the main menu.

Security Planning: An Applied Approach | 4/12/2025| 47 Test Case: Flow of Events Flow of Events: 1. The test case begins when a Medical Admin selects Manage Patient or as an extension to Make Appointment 2. The Tester: enters last and first name for an existing patient and presses Create . 3. While the system finds a matching record 1. The system displays an error message: Match Exists , and requests the tester revise the information. 2. The tester changes the name to a new patient name. 4. The system displays multiple tabs, including Patient Information (Form 6.2, Patient Medical History (Form 6.3), and Patient Medical Information (Form 6.4). 5. The system renames the Create button into the Save button. 6. The tester enters inappropriate data types for each field of the new Patient and presses Save . 7. The system recognizes the invalid information and gives error messages. 8. The tester enters too much information for text strings or overflow data for arithmetic fields for each field of the new Patient and presses Save . 9. The system recognizes the overflow, gives error messages, and logs the error.

Security Planning: An Applied Approach | 4/12/2025| 48 10. The tester leaves some required fields empty for the new Patient and presses Save . 11. The system recognizes the lacking information and gives error messages. 12. The tester enters inappropriate information (violating business rules) for many fields of the new Patient and presses Save (e.g, illegal state, sex, number of children>10, illegal insurance, etc.) 13. The system recognizes the errors and gives error messages. 14. The tester enters SQL injection attack in many fields. 15. The system recognizes the attack, indicates an error, and logs the specific command executed. 16. The tester enters valid information for the new Patient and presses Save . 17. The system displays: Record Updated 18. The system creates a Patient Plan Management (Form 6.5) tab for Patients with health plans, or a Patient Bill Management tab for Patients without. 19. The tester confirms the creation of the new tabs and that a new encrypted transaction log saved the new patient record, including who and when the transaction was saved. 20. The tester confirms that SQL injection attacks and business rule violations are logged.

Security Planning: An Applied Approach | 4/12/2025| 49 Test Case: Postconditions Postconditions: 1. The new record has been saved into the test database. 2. For Patients with health plans, a Patient Plan Management tab is available with information about the Patient s plan. Management tab is provided. 3. Logs exist for attack conditions: SQL attacks and violation of business rules. 4. An encrypted transaction log includes the new records, including who and when the transaction occurred. For Patients without, a Patient Bill