Program security - Defenses

 Prevention
 Cure
 Development controls
 Operating system controls
 Administrative controls
 Specifying
 Designing
 Coding
 Testing

◦ Modularity
◦ Mutual Suspicion
◦ Confinement
◦ Generic diversity
◦ Peer Reviews
 Dividing a task into subtasks
 Easier to trace a problem
 Each component
◦ Single purpose
 Performs one function
◦ Small
 Less amount of information
 structure and content
◦ Simple:
 Low degree of complexity
 Easy understand the purpose and
◦ Independent
 Task isolated from other modules
 Encapsulation
◦ Isolation

 Abstraction
◦ Information hiding
 Advantages of small, independent components
◦ Maintenance
◦ Understandability
◦ Reuse
◦ Correctness
◦ Testing
 Coupling
• Degree which a component depends on other components
 Cohesion
• Degree which a elements of a component bind on other

 high cohesion and low coupling

 Hiding detail
 Hiding complexity
 Sharing is minimized
 cannot easily and maliciously alter the
components
 Limited interfaces
 Limited covert channels
 Relationship between two programs
 Calling program suspect called program
 Called program suspect calling program
 Limited access
 Used by operating systems
 Strictly limited resources
 Product with separate components
 Increase Genetic Diversity
 Reduce tight integration
 Peer reviews
 Hazard analysis
 Testing
 Good design
 Prediction
 Static analysis
 Configuration management
 Analysis of mistakes
 Review
 Sharing a product
 Expose potential hazards
◦ hazard lists
◦ prevention or mitigation strategies
◦ continue throughout the life cycle

 Hazard and operability studies (HAZOP) Failure

modes and effects analysis (FMEA) and Fault tree
analysis (FTA)
 Unit testing
 Integration testing
 Acceptance test
 Function testing
 performance testing
 White box testing
◦ Test cases
 Black box testing
 Installation testing
 Philosophy of fault tolerance
 Policy for handling failures
 Design rationale and history
 Design patterns

◦ Anticipate faults
◦ Handle
◦ Maximize safety and security
 Passive fault detection
 Active fault detection
 Correcting fault
◦ Too risky
◦ Inconvenient
◦ Expensive
 Isolating the damage
 Minimizing disruption
 Retrying:
◦ Restoring the system
◦ Performing the service again
 Correcting
◦ Restoring the system
◦ Correcting
◦ Performing the service again
 Reporting
◦ Restoring the system
◦ Reporting the problem
◦ Not providing the service again
 Predict the risks
 Un expected events
 Decide controls
 Examine the design
 Performed before peer review
 Tools and techniques
 Aspects
◦ Control flow structure
◦ Data flow structure
◦ Data structure
 Control over the software changes during
development and maintenance

 Who makes which changes

◦ Corrective changes: Day-to-day functions
◦ Adaptive changes: modifications
◦ Perfective changes: perfecting existing functions
◦ Preventive changes: preventing from degrading
 Activities
◦ Configuration identification
◦ Configuration control and change management
◦ Configuration auditing
◦ Status accounting

 Configuration and change control board (CCB)

 Changes are evaluated for side effects
 Inventory of all components
◦ Code, DBMS, third-party software, libraries, test cases,
documents (baseline)
 Coordinate separate, related versions
◦ 16-bit and 32-bit processors
 Separate files
 Deltas
 Conditional compilation
 Confirms the baseline is complete and accurate
 Documentation
 Independent parties
 Document the components
◦ current version
◦ change history
◦ pending change requests
 Same mistake twice
 Document
◦ Failures
◦ Fixes
◦ Check list
 Operating systems
 Databases offer security

 Features
◦ Different access to different items
◦ Different kinds of users