1. CSCE 548 Secure Software Development Security Operations

2. Reading This lecture: Next lecture:
Security Operations, McGraw: Chapter 9
Bridging the Gap between Software Development and Information Security, Kenneth R. van Wyk and Gary McGraw,
SANS, Software Security Institute,
Next lecture:
Review for Midterm
CSCE Farkas

3. Application of Touchpoints
External Review
3. Penetration
Testing
1. Code Review
(Tools)
6. Security Requirements
4. Risk-Based
Security Tests
2. Risk Analysis
7. Security
Operations
5. Abuse cases
2. Risk Analysis
Requirement and
Use cases
Architecture
and Design
Test Plans
Code
Tests and
Test Results
Feedback from
the Field
CSCE Farkas

4. Traditional Software Development
No information security consideration
Highly distributed among business units
Lack of understanding of technical security risks
CSCE Farkas

5. Don’t stand so close to me
Best Practices
Manageable number of simple activities
Should be applied throughout the software development process
Problem:
Software developers: lack of security domain knowledge  limited to functional security
Information security professionals: lack of understanding software  limited to reactive security techniques
CSCE Farkas

6. Software Security Best Practices
Abuse cases
Business risk analysis
Architectural risk analysis
Security functionality testing
Risk-driven testing
Code review
Penetration testing
Deployment and operations
CSCE Farkas

7. Deployment and Operations
Configuration and customization of software application’s deployment environment
Activities:
Network-component-level
Operating system-level
Application-level
CSCE Farkas

8. Abuse Cases Drive non-functional requirements and test scenarios
Need information security professionals to understand attacker’s mind
Collaboration between software developers and infosec people
CSCE Farkas

9. Business Risk Analysis
“Who cares”
Business stakeholders
Technology assessment  need software-level assessment
Answer security related questions: how much down time, cost of recovery, effect on reputation , etc.
CSCE Farkas

10. Architectural Risk Analysis
Assess the technical security exposures at system design-level
Evaluates business impact of technical risks
Infosec people: understanding of technology, e.g., application platform, frameworks, languages, functions, etc.
Real world feedback
CSCE Farkas

11. Security Testing
In addition to testing functional specifications and requirements, need test for risk-based attacks
Understand attacker’s way of thinking
CSCE Farkas

12. Code Review Requires knowledge of code
Need information about attacker’s way of thinking
CSCE Farkas

13. Penetration testing
System penetration testing: driven by previously identified risks
Outside  in activity
Application penetration testing
Inside  out activity
CSCE Farkas

14. Deployment and Operations
Configuration and customization of software application’s deployment environment
Fine tuning security functionality
Evaluate entire system’s security properties
Apply additional security capabilities if needed
CSCE Farkas

15. Who are the attackers?
Amateurs: regular users, who exploit the vulnerabilities of the computer system
Motivation: easy access to vulnerable resources
Crackers: attempt to access computing facilities for which they do not have the authorization
Motivation: enjoy challenge, curiosity
Career criminals: professionals who understand the computer system and its vulnerabilities
Motivation: personal gain (e.g., financial)
CSCE Farkas

16. Attacker’s Knowledge Insider Outsider
Understand organizational data, architecture, procedures, etc.
May understand software application
Physical access
Outsider
May not understand organizational information
May have software specific expertise
Use of tools and other resources
CSCE Farkas

17. Cyber Attacks Takes advantage of weakness in
Physical environment
Computer system
Software vulnerability
Human practices
Need to identify, remove, and tolerate vulnerabilities
CSCE Farkas

18. Vulnerability Monitoring
Identify security weaknesses
Methods:
Automated tools
Human walk-through
Surveillance
Audit
Background checks
CSCE Farkas

19. System Security Vulnerability
Software installation
Default values
Configurations and settings
Monitoring usage
Changes and new resources
Regular updates
Tools
Look for known vulnerabilities
CSCE Farkas

20. Red Team
Organized group of people attempting to penetrate the security safeguards of the system.
Assess the security of the system  future improvement
Requested or permitted by the owner to perform the assessment
Wide coverage: computer systems, physical resources, programming languages, operational practices, etc.
CSCE Farkas

21. Security Awareness and Training
Major weakness: users unawareness
Organizational effort
Educational effort
Customer training
Federal Trade Commission: program to educate customers about web scams
CSCE Farkas

22. Prevent VUlnerabilities
CSCE Farkas

23. Secure Programs How do we keep programs free from flaws?
How do we protect computing resources against programs that contain flaws?
CSCE Farkas

24. What is Secure? Characteristics that contribute to security
Who defines the characteristics?
Assessment of security
What is the basis for the assessment?
IEEE Standard for Software Verification and Validation, 2005
Bug, error, fault, …
CSCE Farkas

25. Proof of Program Correctness
Correctness: a given program computes a particular result, computes it correctly, and does nothing beyond what it is supposed to do.
Program verification:
Initial assertion about the inputs
Checking if the desired output is generated
Problems: correctness depends on how the program statements are translated into logical implications, difficult to use and not intuitive, less developed than code production
CSCE Farkas

26. Standards of Program Development
Software development organizations: specified software development practices
Administrative control over:
Design
Documentation, language, coding style
Programming
Testing
Configuration management
CSCE Farkas

27. Process Management Human aspects: difficult to judge in advance
How to assure that software is built in an orderly manner and that it leads to correct and secure product?
Process models: examine how and organization does something
CSCE Farkas

28. SANS: Secure Programming Skills Assessment
Aims to improve secure programming skills and knowledge
Allow employers to rate their programmers
Allow buyers of software and systems vendors to measure skills of developers
Allow programmers to identify their gaps in secure programming knowledge
Allow employers to evaluate job candidates and potential consultants
Provide incentive for universities to include secure coding in their curricula
CSCE Farkas

29. Security Engineering
CSCE Farkas

30. Security Process Models
Capability Maturity Model (CMM): address organizations not products
ISO 9001: similar to CMM
U.S. NSA: System Security Engineering CMM (SSE-CMM)
CSCE Farkas

31. SEE-CMM Aims to advance the Security Engineering discipline Goals:
Enable the selection of qualified security engineering providers
Support informed investment in security engineering practices
Provide capability-based assurance
CSCE Farkas

32. Maturity Levels
Define ordinal scale for measuring and evaluating process capability
Define incremental steps for improving process capability
CSCE Farkas

33. Capability Levels Initial
Repeatable: Requirements management, Software project planning, Software project tracking and oversight, Software quality assurance, etc.
Defined: Organization process focus, Organization process definition, Training program, Integrated software management, Software product engineering, etc.
Managed: Quantitative process management, Software quality management
Optimizing: Defect prevention, Technology change management, Process change management
CSCE Farkas

34. Maturity Levels
Informal: base practices, ad-hoc process, success depends on individual effort
Planned, tracked: plan, track and verify performance, disciplined performance
Well defined: define and perform standard process, coordinate practices
Quantitatively controlled: establish measurable quality goals, objectively manage performance
Continuously improving: improve organizational capability, improve process effectiveness
CSCE Farkas

35. Security Engineering Process Areas
Administer System Security Controls
Assess Operational Security Risk
Attack Security
Build Assurance Argument
Coordinate Security
Determine Security Vulnerabilities
Monitor System Security Posture
Provide Security Input
Specify Security Needs
Verify and Validate Security
CSCE Farkas

36. Evaluation Phases: Planning Phase: scope and plan
Preparation Phase: prepare evaluation team, questionnaire, collect evidence, analyze results
On-site phase: interview, establish findings, rating, report
Post-evaluation phase: report findings needs for improvement, manage results
Use of evaluation:
Organizations to hire developers
CSCE Farkas

37. Problems with SSE-CMM Does not guarantee good results
Need to ensure uniform evaluation
Need good understanding of model and its use
Does not eliminate the need for testing and evaluation
No guarantee of assurance
CSCE Farkas

38. Next Class Review for Midterm – July 18 8:30 – 10:30 am
CSCE Farkas