openedge security against tampering

jurriaan

jurriaan

New Member
New certification demands for us contain a phrase 'information systems ... should be secured against tampering or loss'

Well, the loss part is easy to describe, but the tampering part is somewhat harder.

Is there an official OpenEdge document describing, for example, the use of CRC values in the database?
 
Does your certification authority provide more than a one-line description of the requirement? In my experience these efforts can go off into the weeds as everyone interprets the requirement based on their needs or agendas. Is this PCI DSS? If so I recommend you hire a knowledgeable consultant. Trying to do it yourself can get expensive and can lead to bad decisions.

What is an "information system" in this context? Is it the OpenEdge database? Is it the entire application solution that includes the database? Is it the server that houses the database? This isn't splitting hairs; these are important distinctions. If the system is the server, then you could interpret the assignment of strong user credentials on a least-required-privilege basis as "securing it against tampering" (although by whom?).

What does "should" mean? Is it synonymous with "must" or does it imply a recommendation rather than a requirement?

What does "secured against loss" mean? That all data is read-only? Or does it mean that loss is okay as long as it is a recoverable loss? (E.g. "we have good tested off-site DB and code backups and a warm spare DB kept current with AI files or OE Replication.")

Looking at _File and _Index will show you table and index CRC values (maybe; it depends on your Progress version). You can also see when those records last changed. And there are KB articles talking about which particular fields are used in the CRC calculation, though the articles may or may not be current in light of changes like multi-tenancy and table partitioning. But a CRC is not the same thing as an audit. It won't tell you anything about changes before the last one. It won't tell you if it changed to a different value and then changed back. And it won't tell you who made a change.
 
CRC values of the database schema can only tell you whether the schema has been changed. Unless you have an authentication, authorization set up that holds water and there is an audit trail that is tamper proof you might not pass a SOX-relevant or another audit by regulators or consultants that audit your company on their behalf.

Usually auditors want to see:
  • How are users authenticated. If they are not strongly authenticated, what are the password rules and how often do users need to change their password and how all this is enforced.
  • An authorization concept:
    • How does the system give access to the users with business rights ( via the application ) and how these privileges are granted and revoked.
    • How does the system give access to users with plattform rights ( which are usually required to do support or perform dba tasks )
      • Direct access to the database with a tool with which you can query/change the database by circumventing the application business logic - for example with something like Toad or Squirrel.
      • Direct access on the operating system
  • Possibly segregation of duty - developers are only allowed to access production systems for incident and problem management and may not hold permanent access rights. How is such a process set up - what are the escalation procedures.
  • An audit trail that can not be tampered with and which provides information on who did what when and probably why.
That are some of the question when the "information system" I am responsible for was audited the last time. You can bet your a** they the auditors will come up with something new the next time they show up.

But it does not make sense to be afraid of auditors. Usually when they audit something technical it is to provide sufficient evidence to their colleagues who are auditing the business processes so that the facts and figures that are process by the supporting information systems are correct so that for example a financial statement produced by an IT system is correct. I never looked at them as my enemies and tried to have an open conversation with them. If you approach an audit this way it might be a win win situation. They will get the evidence they need and you might learn something about threats to your application you might not have thought of.

Heavy Regards, RealHeavyDude.
 
All good questions. The certification is ISO 15189, it's the first iteration of that norm in our country, and there's lots of vague phrases. For example: our management is now responsible for the correct display of data we send out on all systems 'directly connected' to our 'information system'.

I have no idea what 'directly connected' means given we're running on a vmware server. We're getting a consultant in, and I'm looking forward to see what's what.
 
You must log in or register to reply here.
Back
Top