MS Access and PCI-DSS

Discussion in 'Access Security' started by jWhytis, Dec 22, 2009.

  1. jWhytis

    jWhytis Guest

    Hello All,

    I have been tasked with reviewing my companies’ Access code to meet PCI-DSS
    standards. After some looking at the PCI documentation it appears I need to
    understand common code exploits within msAccess and make sure our development
    team is not introducing them. While I have found some general information on
    writing secure code I’ve found little on using msAccess in an environment
    that demands PCI code review.

    Can anyone point me in the right direction?

    Thanks,
    Jason
     
    jWhytis, Dec 22, 2009
    #1
    1. Advertisements

  2. IMO, it seems that it has nothing to do with an application software. Most of
    the standards refers to hardware, physical movement of staff, company
    operational procedures, etc.

    Application software security setup is determine by what's available and how
    it protects the data and software.

    There's nothing to prevent data loss/stolen/security breach even if the
    company install firewalls, manned CCTVs, etc. There's nothing to prevent
    rogue employees destroying or stealing data.

    I think the others may have more or others comments. Hope they can post their
    experiences.

    Note: The above is not written from a information security expert but written
    with common sense.
     
    AccessVandal via AccessMonster.com, Dec 23, 2009
    #2
    1. Advertisements

  3. jWhytis

    jWhytis Guest

    Thanks for the reply, unfortunatly it does have to do with the software.
    From the requirements of pci_dss_v1-2:
    6.3.7 Review of custom code prior to
    release to production or customers in
    order to identify any potential coding
    vulnerability
     
    jWhytis, Dec 23, 2009
    #3
  4. I don't think that's an issue. All application can prevent vulnerabilities.
    Take SQL injection attacks for example. In the past, many developers and
    programmers were not are aware of this but not today.

    Microsoft have a history of vulnerabilties, so are you saying that you want
    to dump MS software? Even you don't use MS, take Linux or Unix for example.
    They too have vulnerabilites, but of course given the volume of MS OS
    deployment against Unix/Linux vulnerabilities are much lesser.

    Two qoutes here.
    "My favorite superhero: ISO9000 Lad! He wins by merely describing how he
    might theoretically beat you, but he NEVER ACTUALLY DOES ANYTHING! Villains
    get utterly overwhelmed by the sheer multitude of paper documents he
    dispenses from his Compliance And Certification Apparatus (CACA), and just
    die under the weight of the bureaucratic load. - unknown"

    "Programming today is a race between software engineers striving to build
    bigger and better idiot-proof programs, and the Universe trying to produce
    bigger and better idiots. So far, the Universe is winning.
    - Rich Cook "

    I hope the qoutes makes some sense.
     
    AccessVandal via AccessMonster.com, Dec 24, 2009
    #4
  5. BTW Macs have just as many vulnerabilities as Windows.

    Tony
    --
    Tony Toews, Microsoft Access MVP
    Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
    Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
    For a convenient utility to keep your users FEs and other files
    updated see http://www.autofeupdater.com/
    Granite Fleet Manager http://www.granitefleet.com/
     
    Tony Toews [MVP], Dec 24, 2009
    #5
  6. lol, ok we should include Macs. Might as well in include "cottage cheese" :).
     
    AccessVandal via AccessMonster.com, Dec 24, 2009
    #6
  7. jWhytis

    jWhytis Guest

    The trick is to show you are reasonably aware of vulnerabilities, like sql
    injection, and are taking reasonable precautions against them. For web
    attacks lists of common exploits are a google search away. I'm looking for
    something similar for MS Access. Thinking its not an issue is the same as
    not thinking, and not thinking is not acceptable.
     
    jWhytis, Jan 8, 2010
    #7
  8. jWhytis

    david Guest

    It's best to think of Access like an actual book made of paper.
    You need to control access to the book. People who get to the
    book can destroy the book, or look at pages, or even photocopy
    the book. They don't need to find a code-exploit to do so.

    The book is written in Estonian, and most users don't actually
    understand it as such, which is good enough for some applications.
    Provided only trusted users are given access.

    -----
    Access is a layer over the database primitives of
    either the operating system or an ODBC server.

    This means that you do not have security independent
    of the operating system/server.

    The first security problem of Access is that the data is
    not securely protected from the users.

    A subset of that problem is that Access does not provide
    record-level security: individual records cannot be
    securely protected from a user.

    These are the well known exploits for Access.
    These are also the well known exploits for Jet/MDB,
    That is, Access has the same problem using any data source
    as it has using MDB's, and MDBs have the same problem
    using any front-end.


    These well-known-exploits mean that you can only use
    Access/ODBC or Access/Jet to the extent that you trust
    your users: Data cannot be securely protected from users.

    Data can be obscured. For many applications that is suitable.
    Data can be visible. For many applications that is suitable.
    Data can be changed. For many applications that is suitable.

    Data can be logged and audited, subject to the limitations above.


    Access is not generally used for outward-facing interfaces. To do
    so would expose Access to untrusted users, which would expose
    your data.

    Access is not subject to buffer overflow attacks, but that misses
    the point: a buffer overflow attack is used to escalate privileges:
    anyone who could attempt a buffer overflow attack has access,
    and must be a trusted user.

    This is generally true for all code exploits, which is why code
    exploits are not important for Access. Anyone who is in a position
    to use a code exploit already has access to the data, and must be
    a trusted user.

    Access is subject to SQL injection attacks. Any user who can
    do an SQL injection attack has access to the data, and must
    be a trusted user, but you do need to be minimally aware of
    that: http://xkcd.com/327/.


    Having said, that, Access can be used to hide data from
    trusted users. If you are using "workgroup security" to hide
    the data, you need to review the Access Security FAQ.

    (david)
     
    david, Jan 11, 2010
    #8
  9. I guess, the application designer will have to decide on the UI user
    friendliness against strict security. In the end of the day, it's who will
    win the end game. There will always be vulnerabilities.
     
    AccessVandal via AccessMonster.com, Jan 12, 2010
    #9
  10. jWhytis

    jWhytis Guest

    David,

    Thanks for the thoughtful reply. It highlights the issues involved in using
    MSAccess as a development platform. In my case I have a team of 4 developers
    using MSAccess mostly to provide a user interface to a SQL Server database.
    We have a thousand plus end users who each receive a copy of the current
    production code as an mde. Users are logged in using their windows
    credentials but are given db access under a single SQL account. They are
    limited by what they can and can not do by menu options in the front end tied
    to a home grow permissions system in the back end database. We know this
    isn’t ideal but MSAccess doesn’t play well with SQL using trusted logins or
    application roles. Even if we went to trusted logins we wouldn’t be able to
    provide row level security thru windows groups.

    So we depend on the compiled nature of the mde to protect our code and the
    menuing system to provide row level security to data but the actual account
    used for data access has much greater power than the user using it. Most of
    our users use our database thru a thin client and can not get a copy of the
    mde. After reviewing the list of web exploits and thinking about our
    particular situation I’ve come up with the following action items:

    1. Hide all objects in the distributed mde. While the users don’t have
    MSAccess on their desktops they do have excel and can browse database objects
    with it. While the linked tables will not allow them direct access to the
    database data some of the queries objects will. This is obfuscation rather
    than security but I believe it mitigates the problem well enough.
    2. Ensure all user input is properly filtered. Drop downs demand the user
    choose from a list, Date and number input is in fact what it should be and
    text entry be scanned for special characters. This will become an ongoing
    requirement of the code review process.
    3. Error handling is in place so users don’t receive message boxes
    containing information about the underlying code or odbc connection info.
    This also will become an ongoing requirement of the code review process.
    This is going to be a pain, I REALLY wish VBA would introduce a try..catch
    structure.

    There may be a few more things that come up. I’ll post back as changes
    warrant. Other thoughts are welcome.

    Cheers,
    Jason
     
    jWhytis, Jan 13, 2010
    #10
  11. jWhytis

    jWhytis Guest

    Understood. As long as we are addressing those issues we can address we're
    doing all that can be done.
     
    jWhytis, Jan 13, 2010
    #11
  12. jWhytis

    david Guest

    Looks good. You're are using a single Server account
    rather than the Windows Login? What are you
    doing about the User Name/Password?

    We used Windows Login. It doesn't give you better
    security, but it can give you better auditing.

    Also, note that there is an mde de-compiler available.

    By the way, I'm not sure what you think you mean when you
    say that Error handling is in place, but you wish VBA had
    a Try-Catch structure :~) The keywords are different, it is
    very flexible because it already includes three different (older)
    exception handling models, (so it can do pretty much everything
    and anything), the keywords for exception types handling are
    different, nesting is integrated into the language rather than bolted
    on, but it IS a Try-Catch structure.

    It doesn't catch ODBC message boxes, but that is because
    the ODBC message boxes are not exceptions: Access starts
    ODBC in a mode that generates message boxes rather than
    exceptions.

    (david)
     
    david, Jan 14, 2010
    #12
  13. jWhytis

    jWhytis Guest

    David,

    Thanks again!

    To your question "what are you doing with the user name/password" i answer
    "looking for a better way to conceal it.â€

    To your question about windows logins I’m not sure what you mean. I don’t
    want to use the user’s login because they would have rights to everything in
    the database thru Excel. Do you mean you are creating a single windows
    account and doing something like “run as†when you start up the Access app?

    As for error handling I can do everything I need to with “on errorâ€, it just
    takes a bit more planning to make it got the way I’d like.
     
    jWhytis, Jan 21, 2010
    #13
  14. jWhytis

    david Guest

    To your question "what are you doing with the user name/password"
    Yes, just so you are thinking about it.

    I don't have a solution either. We used unique logins because
    it gave easier audit results when each user had a unique login,
    it's not better security.

    Another way to use the Windows login is to put the MDE into
    the user profile, rather than Program Files.

    (david)
     
    david, Jan 22, 2010
    #14
  15. For PCI DSS, I assume that your application was considered in scope for the assessment from your QSA, because it is either involved with or directly connected to systems that process, store or transmit cardholder data.

    If it's not, then it's not in scope and you don't have to worry about PCI DSS.

    If it is in scope, there are some dangerous issue that is not PCI DSS compliant.

    I assume there is cardholder data in your SQL Server. If so, as any of your users can use your MDE to query the SQL Database you may be violating PCI DSS 8.5.16.a as anyone on the network can query your SQL Database directly (without your MDE) unless you have logically/physically segmented the SQL Server.

    For PCI DSS v1.2.1, you need to develop your software in according with section 6, emphasis on 6.3, 6.4 and 6.5. This ensures that there is proper secure development lifecycle (security throughout requirements, coding and QA) and change control, to prevent vulnerabilities.

    The other issue is patch management, which is PCI DSS 6.1 and 6.2.

    I only make those assumptions based on the current information provided. If the above has not been considered, you may be compromising your security.

    Michael
    (PCI QSA)









     
    Michael Hopewell, Feb 3, 2011
    #15
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.