MS Access and PCI-DSS

[jWhytis]

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

 

[AccessVandal via AccessMonster.com]

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.

 

[jWhytis]

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

 

[AccessVandal via AccessMonster.com]

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.

 

[Tony Toews [MVP]]

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.

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/

 

[AccessVandal via AccessMonster.com]

lol, ok we should include Macs. Might as well in include "cottage cheese" .

 

[jWhytis]

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.

 

[david]

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)

 

[AccessVandal via AccessMonster.com]

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.

 

[jWhytis]

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]

Understood. As long as we are addressing those issues we can address we're
doing all that can be done.

 

[david]

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)

 

[jWhytis]

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.

 

[david]

To your question "what are you doing with the user name/password"

i answer "looking for a better way to conceal it."

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)

 

[Michael Hopewell]

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)

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

On Tuesday, December 22, 2009 11:03 PM AccessVandal via AccessMonster.com wrote:
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 is available and how
it protects the data and software.

There is nothing to prevent data loss/stolen/security breach even if the
company install firewalls, manned CCTVs, etc. There is 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.

jWhytis wrote: