Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

DeepSEC: Developers are from Mars, Compliance auditors are from Venus

Leave a comment Posted by on November 25, 2010

Developers are from Mars, Compliance auditors are from Venus Neelay S Shah, Rudolph Araujo

We all either love or hate compliance!

Provide guidance and best practices for software developement from a regulatory standpoint.

Target: Top 20 things a developer can do to stay on the right side of compliance.

Need for regulatory compliance

Many (in)famous cases, such as Heartland, TJX and others.

Lots of instances of personal data being leaked/stolen through lack of security…

Intent of regulatory compliance

Compliance is in place to prevent these kind of breaches and protect data

Reason for disconnect between regulations and developers

Regulations indicate the end goal and don’t talk about anything in-between

Language and context are directed towards the “legal” community and not developers

Impact of non-compliance

Fines, legal punishment, public embarrassment, lack of customer confidence, …

Approach of regulatory compliance

  • Physical security
  • Infrastructure security
  • Operational security
  • Application development security

Today we’ll be focusing in on Application development security

Compliance roadmap

  • PCI
  • European Union Data Protection Directive
  • Health Insurance Portability and Accountability Act (HIPPA)
  • Sarbanes-Oxley (SOX)
  • Basel II

How can developers connect their development and applications to these compliance regulations?

Data Protection in Storage and Transit

  • Does your company/application really NEED this information?
  • Can you get away with only storing partial data (e.g. only the last 4 digits of a CC number)
  • Stay away from home-grown crypto… there are plenty of libraries that provide known and tested functionality
  • Do you need to know the clear text data from a user. If not, hash it (e.g. password transmission)
  • If the data is sensitive, it should be masked in the UI
  • Where possible use OS functionality to enable encryption/security. Don’t reinvent the wheel!
  • Support or build in features to rotate encryption keys in the event of exposure (think about old data)
  • SSL should be used to protect data in transit
  • Use the strongest supported versions (SSLv3 / TLSv1.x) –> think about client support
  • Make sure to use official SSL certificates (no self-signed certs)
  • Validate the certificate (thick clients)

Authentication

  • Re-use existing, established Single-Sign On solutions (LDAP, AD, …)
  • Implement two-factor authentication for sensitive systems
  • Don’t use sensitive data from user identifiers
  • Ensure passwords are controlled (set password complexity, changes, …)

Authorization

  • Check if a user is authorized to perform an action
    • CRUD – create, read, update, delete
  • Don’t use hidden fields for transfer of data

User and Session Management

  • Implement password recovery that doesn’t reduce security of the application
  • Set initial passwords to random strings and enforce change at first connection
  • Use established session ID management (framework implemented)
  • Enable email notifications for user feedback of security issues
  • Enable inactivity time-out (15 minutes)

Data Validation

  • Enforce type, length, range and format on incoming data
  • Parametrize queries
  • Bind queries to prevent LDAP injection
  • Safe API / Frameworks to prevent command injection

Error and Exception Handling

  • Define custom error pages with generic statements (no stacktrace)
  • Handle all know exception types
  • Specific handlers, then catch-all

Auditing and Logging

  • Audit events to answer the question “Who did what to whom and when”
  • Log attempts (failed or successful) to required actions
  • ALL administrative actions
  • ALL login attempts (failed or successful)
  • Log metadata to ensure traceability
    • Date / Time
    • Source of the action
    • Subject (user) requesting the service
    • Result (success or failure)
  • Don’t log authentication data, sensitive data, personal information

Configuration Management

  • Support run-time configuration of audit logs
    • Log levels
    • Locations
    • Format

People and Process Recommendations

  • Train your staff
  • Establish secure coding guidelines
  • Don’t use productive data in test
  • Test your applications regularly
  • Check for updated components regularly
  • Talk overview –> HERE
Conference, Security , , , ,

Comments are closed.