Designing and Implementing Secure Software

1
Designing and Implementing Secure Software

• Dr. Andy Podgurski
• EECS Department
• Case Western Reserve University
• Cleveland, OH 44106

2
Sources

• Computer Security Art and Science by M. Bishop
• Secure Coding Principles and Practices by M. G.
  Graff and K. R. van Wyk
• Exploiting Software How to Break Code by G.
  Hoglund and G. McGraw
• Writing Secure Code by M. Howard and D. LeBlanc
• Attack Modeling for Information Security and
  Survivability by A.P. Moore, R.J. Ellison, and
  R.C. Linger
• Building Secure Software by J. Viega and G.
  McGraw

3
Security vulnerabilities in software

• Defects that permit attacker to cause software to
  violate its own requirements
• To attackers advantage
• To disadvantage of stakeholders
• Attacker controls degree of damage
• Attacker may probe for unknown vulnerabilities
• Attacker can choose which vulnerability to
  exploit and when to do so

4
Example buffer overflow attacks

• Software does not check size of input string
• Input is passed to function
• Attacker inputs specially crafted string
• Includes attack code
• Overwrites return address on function call stack
• On function return, attack code is executed
• If application runs in privileged mode, attacker
  can gain control of machine

5
Example application-specific exploit

• Insurers web site permits online application for
  auto insurance
• Consumer could print out certification of
  coverage
• Consumer could cancel coverage without charge
  within 30 days
• Insurer found that many consumers cancelled
  within one day
• Insurer discovered later that consumers were
  presenting certification to other insurers to get
  lower rates

6
Causes of security vulnerabilities

• Security vulnerabilities and ordinary defects
  arise from the same general causes, e.g.,
• High software complexity
• Poor software engineering practices
• Inadequate training
• Poor design decisions
• Insufficient resources
• Schedule pressure
• Human foibles

7
General types of attacks

• Interruption asset of a system is destroyed or
  becomes unavailable
• Interception unauthorized party gains access to
  an asset
• Tampering unauthorized party modifies an asset
• Resource usage attacker uses system resources
• Hijacking attacker gains control of system
• Fabrication unauthorized party inserts
  counterfeit objects into a system
• Masqerade attacker impersonates a legitimate
  user
• Repudiation user denies taking certain actions

8
Routes of attack

• Ports
• Services
• APIs
• Operating system, runtime system, and virtual
  machine vulnerabilities
• Third-party software
• Passwords
• Back doors
• Trojan horses
• Mobile code
• Inference channels
• Covert channels

9
Security policy

• Statement of what activities are allowed and what
  are not
• Addresses confidentiality, integrity, and
  availability
• May be formal or informal
• Based on explicit or implicit model of system
• Should be developed as part of software
  requirements analysis and specification

10
Example Java policy file

• grant signedBy "sysadmin", codeBase
  "file/home/sysadmin/"
• permission java.security.SecurityPermission
  "Security.insertProvider." permission
  java.security.SecurityPermission
  "Security.removeProvider."
• permission java.security.SecurityPermission
  "Security.setProperty."
• Only code signed by sysadmin and from directory
  /home/sysadmin can add or remove providers of a
  Security object or set its properties

11
Security mechanism

• Method, tool, or procedure for enforcing a
  security policy, e.g.,
• Development controls
• Internal program controls
• Operating system, runtime system, virtual machine
  controls
• User authentication
• Access controls
• Encryption
• Audit logs
• Operational controls
• Firewalls
• Intrusion detection systems

12
Achieving security

• Conditions for a system to be secure
• The security policy must address all threats
• The security mechanisms must implement all
  aspects of the security policy
• The mechanisms must be implemented and
  administered correctly

13
Development controls

• Security training
• Clear responsibility for security of assets
• Design and coding guidelines, checklists
• Threat modeling
• Design and code reviews/inspections
• Independent audits
• Security testing
• Change management
• Post deployment monitoring
• Root-cause defect analysis

14
Threat Modeling

• Used to identify highest security risks to
  software product
• Steps
• Decompose application
• Identify threats
• Rank threats by degree of risk
• Document threats

15
Example attack treeMoore, et al

• Unexpected Operator Attack Pattern
• Goal Exploit unexpected operator vulnerability
  to perform malicious function
• Precondition Attacker can execute certain
  programs on the target system
• Attack
• AND
• Identify executable program on ACME Web Server
  susceptible to unexpected operator vulnerability
• Identify (unexpected) operator that permits
  composing system calls
• Identify system call that would provide access to
  privileged account when executed with programs
  privilege
• Construct unexpected input by composing legal
  input value with system call using the unexpected
  operator
• Execute program on ACME Web server with
  unexpected input
• Postcondition Target system performs malicious
  function

16
General security principles

• Identify your assumptions
• Grant subjects only as many privileges as they
  require
• Use secure default configurations
• Dont rely on security features
• Assume attackers have access to your code

17
Principles of secure design

• Minimize ports of entry
• Employ defense in depth
• Employ strong authentication of users
• Assume external systems and components are
  insecure
• Validate user and programmatic input
• Check all requested actions against the security
  policy
• Beware executable input
• Minimize the amount of state information that
  software retains
• Monitor and limit resource usage
• Plan for failure
• Fail to a secure mode
• Maintain audit logs

18
Validating inputs

• Cleanse data
• Perform bounds checking
• Check
• Configuration files
• Command-line parameters
• URLs
• Web content
• Cookies
• Environment variables
• Filename references

19
Example Postfix mailerwww.postfix.org

• Replacement for Sendmail Mail Transfer Agent
  (MTA)
• Postfix daemons run at low privilege in chroot
  jail
• Separate processes used to insulate activities
  from each other
• Postfix programs run under control of Master
  daemon
• Mutually cooperating processes with no
  parent-child relationships to user processes
• No use of setuid
• Postfix programs dont trust contents of network
  data, queue files, or internal messages
• Sender-provided information is filtered
• Several defenses against large inputs
• Number of in-memory instances of objects limited

20
Operational controls

• Deploy multiple layers of security
• Enable only essential services
• Compartmentalize the environment
• Manage access rights carefully
• Use secure protocols
• Separate production data from management
  information
• Install all current security patches
• Establish recovery procedures
• Monitor for unauthorized activity

21
Caution

• It is inevitable that unknown security
  vulnerabilities will be present in deployed
  software
• Software, users, environments too complex to
  fully comprehend
• Environment and usage are subject to change

22
Post-deployment validation

• Security of deployed software should be
  investigated regularly
• Requires observing and analyzing its usage in the
  field
• Requires automated support

23
Application-based intrusion detection

• Misuse detection/signature analysis
• Applies only to known attacks
• Precise, efficient
• Anomaly detection
• Can detect novel attacks
• More false positives
• Costlier
• Entails off-line auditing of suspicious behavior
• Same approach can reveal ordinary defects