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

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

Tag Archives: compliance

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

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
Advertisements

One bad day

I must admit that I don’t follow this kind of news as much as some other in the industry. However I recently became aware of the ongoing legal action by Merrick Bank against the IT consulting firm Savvis for negligence and negligent misrepresentation in certifying CardSystems as CISP compliant. This in itself wouldn’t be important news in my view as companies seem to sue each other at the drop of a hat in this day and age. However the details of the case interested me enough to read a little further.

The case came back into the limelight in the past few weeks after the federal district court in Missouri transferred the case to Arizona. To give the brief 30 second overview, Savvis was retained by CardSystems in 2004 to valid their systems as CISP (Cardholder Information Security Program*) compliant. Less than a year after being given the green light by Savvis, CardSystems was breached resulting in the compromise of up to 40 Million credit card numbers. This in turn cost Merrick Bank (a customer of CardSystems) over $16 Million in costs. Not a small amount by any means.

However, this is all in the past, and there are various places on the web where you can find much more in-depth information about the breach and the case. What I want to talk about is the validity of security checks and compliance. I’m a supporter of anything that convinces management to think about security. The debate about whether the PCI standard has helped or hindered security is something I’ll leave for the people who like to argue such things. However like any security check, penetration test, vulnerability scan or audit, the results (and therefore the compliance stamp that goes with it) is only going to tell you what the security was like at a single point in time. Having regular checks can help you build a view of your security over a longer period, but you can never say 100% what the company’s exposure was between 2 of time-points.

I’ll give you an example. If company ABC requests a penetration test of their systems, the people performing the test (XYZ Labs) can only check for known issues, configuration flaws, business logic flaws, published vulnerabilities, and sometimes unpublished vulnerabilities. Even if the company requests that XYZ Labs perform a regular test every 3 months they can never be sure that between penetration tests they remain 100% secure. It comes down to the simple fact that defending a network is much harder than attacking one. It’s a simple equation. To defend your systems you need to make sure that every system in that network (or that could be attached to that network) is fully protected, patched, properly configured and monitored 24 hours a day, 7 days a week 365 days a year. For an attacker to win, they simply need to find a single system on the network that has a weakness. That could be a configuration problem, an unpublished exploit (zero-day), or a weak link (social engineering, client-side attack, test system exposed to the internet). The possible attack vectors are wide and varied. They are also not all covered by the standard scanning techniques used by most Approved Scanning Vendors.

How does this fit with Savvis, CardSystems and Merrick Bank. It’s simple. Like any other IT Consultancy, Savvis were paid to come in and review security with CISP compliance in mind. They performed that action, certified CardSystems according to the standard and moved on. Savvis were not charged with maintaining the ongoing level of security at CardSystems in a hands on role. So does this mean that Savvis are now responsible for any future security blunder made by the IT staff at CardSystems. They may, or may not have been charged with scanning the network on a quarterly basis. However as anybody who’s compared a vulnerability scan to a Penetration test knows, scanning is only part of the battle. I’m not aware of any company doing compliance checks that offers a 12 month money back guarantee on your company’s security. How could they. After all, their security checks both on the audit side, as well as vulnerability scanning or penetration testing (if performed) can only show the current state of security within that organisation. If CardSystems was like any other company, they probably even worked especially hard during the Audit periods to improve the level of security and follow the processes exactly as they should. Showing their ‘A’ game to make sure that the compliance went smoothly. Some would say that a company will never be as compliant as it is during the Audit because of this very reason. It’s easy when nobody is looking over your shoulder to fall back into bad habits. I’ll do that change control tomorrow, it’s only a test box so no need to patch it as often. We’ve all done that at one time or another through laziness or pressure from management to fit in too much work before the long weekend.

I’m not a lawyer, and I don’t play one on television either (although I am available to audition should the right role come up). However I hate to see companies, like Savvis, get blamed for something that they could well have no control over. Then again, maybe the evidence in the case proves that Savvis is to blame. I can only go on the little information I have.

* For those not in the know, the CISP requirements were incorporated into an industry standard known as Payment Card Industry (PCI) Data Security Standard

Links (further reading) .:

http://blog.subjunctive.com/ –> Grave Concerns Blog
http://www.finextra.com/community/fullblog.aspx?id=2905 –> Finextra.com