In our one of the project we have to meet all 21 CFR Part 11 Requirements. The system has to be designed using Java, MySQL. Through the basic concept I came to know that 21 CFR Part 11 Req. mainly emphasis on following:
Digital Signature
Audit Trails
Security/Validation of the system.
Can anyone have an idea how they can be achieved wrt 21 CFR ... specifically about best practice for Audit Trails and digital signature
Thanks
[Disclosure: I work for CoSign]
Meeting 21 CFR Part 11 requirements is a big job. I suggest that you outsource it to a vendor. CoSign is used in over 100 Part 11 compliant installations. It includes a FIPS certified tamper-proof hardware appliance for securely storing the private keys.
Because the CoSign appliance is self-contained, it also enables you to limit the scope (and expense and time) of your part 11 compliance project. See CoSign info on part 11 compliance.
The CoSign Signature Web Agent is easy to integrate into your app using https calls to sign and verify your docs.
Re: audit trails-- the CFR Part 11 faq has some info on this. But if you work in a regulated industry (Life Sciences, Healthcare, etc) that needs part 11 compliance, then you should talk with your legal department to ensure that you meet the requirements per the regulations. Or outsource the issue.
Related
I am writing a software which sells certain service to it's user. I am aware of hundreds of different invoicing tools around - Freshbooks, Invocie machine, Xero, SortMyBooks are just to name a few. They all have an API but integrating with each is so much work.
Is there any protocol or indicative to create a universal data exchange protocol, which would allow user to specify invoicing system of their choice on my software and have two product communicate seamlessly without prior knowledge of each-other existence?
Of course this issue goes beyond invoicing. How to connect time reporting tool with thousand of project-tracking portals? How to exchange task between Getflow and Taskify?
p.s. I'm not asking on "Webapps" because it's clearly more focused on the user-side of web apps.
There are several standard EDI formats for invoicing, including (but not limited to) EDIFACT's INVOIC message, ANSI X12's 810 message, as well as more proprietary XML formats such as VISA's
Has anyone written XACML Implementations other than the Sun XACML Implementation and XEngine?
Who uses them in their products?
Which vendors provide a PDP? I read something about a WebLogic XACML Provider. What other products support XACML?
This has been answered on the XACML TC list already: http://markmail.org/message/w7msffsbi6qzgfoj
XACML is used in a wide variety of industries today. Trying to summarize what's been said
There are 2 types of implementations today:
open-source implementations
They are either backed by commercial organizations, foundations, or universities.
These include:
(Sun-backed) SunXACML (http://sunxacml.sourceforge.net/) - very much dead on its own but used in other products such as WS02's offering (see below)
(R&D-backed) SICSACML (http://www.sics.se/node/2465) backed by SICS, the Swedish Institute for Computer Science, and now taken up by Axiomatics (www.axiomatics.com)
(University-backed) Heras AF (http://www.herasaf.org/heras-af-xacml.html): Orange is using their product. Orange is one of the leading telecommunications providers in Europe.
WS02 is a company that was born from the Apache Synapse project and expanded into different areas successfully including XACML by using the initial SunXACML implementation (http://wso2.org/library/identity-server/user-management/xacml). I am not sure they have customers using XACML today.
Enterprise XACML (http://code.google.com/p/enterprise-java-xacml/) but not updates in nearly a year
Brad Cox also a neat approach to implementing XACML as described in his blog and paper at http://bradjcox.blogspot.com/
Commercial products
Oracle OES provides a SunXACML-based XACML 2.0 implementation. It is hard to know whether OES customers are using XACML features.
IBM Tivoli Security Policy Manager
Axiomatics Policy Server took SICSACML and marketed it in 2006 - their product fully implements XACML 3.0. Their customers include "one of the world's largest bank", Paypal, Bell Helicopter, Swedish National Healthcare service, SOS Alarm, and DATEV eG as listed at www.axiomatics.com/customers.html
There are other vendors such as Jericho Systems and Nextlabs that offer XACML. Also Securent (later bought by CISCO) had a XACML offering.
Lastly I recommend you visit the XACML TC (http://www.oasis-open.org/committees/xacml/) where you can see its contributing members. Those include Oracle, Axiomatics, Boeing, Veterans Administration, EMC who are regular contributors.
I'm a member of the team at IBM that builds a security policy management solution, including XACML for authorization policy; and I used to be the team lead for the XACML runtime component itself. The product is called Tivoli Security Policy Manager, and is definitely under active development.
WebLogic used to be built by BEA, before they were acquired by Oracle. I'm not sure if Oracle still sells it or not.
Axiomatics also has a XACML solution, as does Jericho Systems.
WSO2 Identity Server (http://wso2.org/) is a open source entitlement engine which is based on the sunxacml. WSO2 Identity Server contains a nice XACML UI policy editor which can be easily used to create complex XACML policies. There is a PIP layer to plug any attribute finder module with it. Therefore you are able to find your attribute from any database, LDAP user store , web services and many more .... Also there are decision caching, policy caching and PIP level attribute caching to improve the performance. You can refer the implementation source code from here [1]
[1] https://svn.wso2.org/repos/wso2/branches/carbon/3.2.0/components/identity/org.wso2.carbon.identity.entitlement/
DATEV (a german IT service provider w 5800 employees) announced in 2010 that they will use XACML. Swedish software company Axiomatics will develop a Datev version of its identity management solution.
XACML implementations (Sun, XEngine, and EnterpriseXACML) are currently interpeters, which makes it hard to debug how a decision was reached since debuggers show the interpreter's internal code, not the policy itself.
I've written a compiler for DOD/DISA that transforms XACML directly to Java code. The goal was making policies easier to understand, not speed, but it is gratifying that compiled policies run in about a tenth the space and time as Sun's interpreter.
The compiler has now been verified by using the same Oasis compliance tests that Sun's interpreter uses. Out of ~400 tests, it passes all but 8. Current problem areas are cases the standard isn't clear on; Subject Categories and PolicySet IdReferences to name two.
I'm wiring it up as a SAML-P service this weekend. Release plans aren't final yet but we'll probably release it as open source on forge.mil as soon as the SOA version stabilizes.
Note added: There's a link to an AFCEA paper about it at http://bradjcox.blogspot.com/2011/03/compiling-xacml-to-java-source.html
BiTKOO (http://bitkoo.com) has XACML 3.0 integrated into its Keystone family of authorization management products. I'm the architect of BiTKOO's XACML core technologies (PDP, PAP, PEP).
A wide variety of organizations are now using XACML based solutions for authorization management. Most are large organizations - government agencies (foreign, domestic, military, and state), universities, media companies, industrial companies, etc.
I'm aware that this questions was posted a few years ago but it can be relevant right now to people looking for open source XACML implementations.
The project AuthZForce provide an opensource XACML 3.0 implementation with a multi tenant REST API along with a java based API. It also provide an XACML SDK.
AuthZForce is available on github, on the OW2 repository and a docker container as well as a debian package are available
http://github.com/authzforce
https://tuleap.ow2.org/projects/AuthzForce/
I'm one of the core developper of the project so feel free to reach me if you have any questions.
This may not be helpful as it's not a COTS product, but it may be of interest to you or others.
There is an open-source XACML implementation at http://code.google.com/p/enterprise-java-xacml/ which I've used recently. It covers the entire specification and has pretty decent policy evaluation performance considering it's not optimised.
You can have a look at http://www.herasaf.org/ . It is a highly developed open source project (Although I don't know which license they are under) I looks really promising, but there is still a lot of work to do.
If you are looking for an alternative to Sun XACML you should really have a look at HERAS-AF (www.herasaf.org). It's a very active project and their support is very good and fast responding (e.g. forum.herasaf.org). Code is in good quality and it provides very much extension points. The API is clear and very easy to use. Have a look at the getting started guide. It is developed and published under Apache2 license.
OpenAM, an open source access management and web Single Sign On solution, previously known as OpenSSO, provides a PDP and has support for XACML 3.0 for importing and exporting policies.
More information at openam.forgerock.org.
PicketBoxXACML, formerly JBossXacml also wraps SunXacml's implementation and provides an updated PDP. There's not alot of documentation out there on it, but it's open source.
Hi you might also want to have a look at ViewDS identity Solutions (see http://www.viewds.com). ViewDS have two XACML solutions. Access Sentinel which provides for externalised authorisation services with a PDP/PIP and two PAPs (DortNet & Java) and a variety of PIPS. Their product also supports Delegation, Roles Management & obligations. ViewDS Identity Solutions also have an LDAP Directory with its own integrated searching and matching engine and have XACML enabled the Directory. That is they use XACML to provide the Policy based authorisation system for accessing Directory information over the Web.
Here's an interesting discussion at Forrester blog http://blogs.forrester.com/andras_cser/13-05-07-xacml_is_dead that actually updates the state of XACML as of 2013. Be sure to read the comments as well.
As part of a PCI-DSS audit we are looking into our improving our coding standards in the area of security, with a view to ensuring that all developers understand the importance of this area.
How do you approach this topic within your organisation?
As an aside we are writing public-facing web apps in .NET 3.5 that accept payment by credit/debit card.
There are so many different ways to break security. You can expect infinite attackers. You have to stop them all - even attacks that haven't been invented yet. It's hard. Some ideas:
Developers need to understand well known secure software development guidelines. Howard & Le Blanc "Writing Secure Code" is a good start.
But being good rule-followers is only half the point. It's just as important to be able to think like an attacker. In any situation (not only software-related), think about what the vulnerabilities are. You need to understand some of those weird ways that people can attack systems - monitoring power consumption, speed of calculation, random number weaknesses, protocol weaknesses, human system weaknesses, etc. Giving developers freedom and creative opportunities to explore these is important.
Use checklist approaches such as OWASP (http://www.owasp.org/index.php/Main_Page).
Use independent evaluation (eg. http://www.commoncriteriaportal.org/thecc.html). Even if such evaluation is too expensive, design & document as though you were going to use it.
Make sure your security argument is expressed clearly. The common criteria Security Target is a good format. For serious systems, a formal description can also be useful. Be clear about any assumptions or secrets you rely on. Monitor security trends, and frequently re-examine threats and countermeasures to make sure that they're up to date.
Examine the incentives around your software development people and processes. Make sure that the rewards are in the right place. Don't make it tempting for developers to hide problems.
Consider asking your QSA or ASV to provide some training to your developers.
Security basically falls into one or more of three domains:
1) Inside users
2) Network infrastructure
3) Client side scripting
That list is written in order of severity, which opposite the order to violation probability. Here are the proper management solutions form a very broad perspective:
The only solution to prevent violations from the inside user is to educate the user, enforce awareness of company policies, limit user freedoms, and monitor user activities. This is extremely important as this is where the most severe security violations always occur whether malicious or unintentional.
Network infrastructure is the traditional domain of information security. Two years ago security experts would not consider looking anywhere else for security management. Some basic strategies are to use NAT for all internal IP addresses, enable port security in your network switches, physically separate services onto separate hardware and carefully protect access to those services ever after everything is buried behind the firewall. Protect your database from code injection. Use IPSEC to reach all automation services behind the firewall and limit points of access to known points behind an IDS or IPS. Basically, limit access to everything, encrypt that access, and inherently trust every access request is potentially malicious.
Over 95% of reported security vulnerabilities are related to client side scripting from the web and about 70% of those target memory corruption, such as buffer overflows. Disable ActiveX and require administrator privileges to activate ActiveX. Patch all software that executes any sort of client side scripting in a test lab no later than 48 hours after the patches are released from the vendor. If the tests do not show interference to the companies authorized software configuration then deploy the patches immediately. The only solution for memory corruption vulnerabilities is to patch your software. This software may include: Java client software, Flash, Acrobat, all web browsers, all email clients, and so forth.
As far as ensuring your developers are compliant with PCI accreditation ensure they and their management are educated to understand the importance security. Most web servers, even large corporate client facing web servers, are never patched. Those that are patched may take months to be patched after they are discovered to be vulnerable. That is a technology problem, but even more important is that is a gross management failure. Web developers must be made to understand that client side scripting is inherently open to exploitation, even JavaScript. This problem is easily realized with the advance of AJAX since information can by dynamically injected to an anonymous third party in violation of the same origin policy and completely bypass the encryption provided by SSL. The bottom line is that Web 2.0 technologies are inherently insecure and those fundamental problems cannot be solved without defeating the benefits of the technology.
When all else fails hire some CISSP certified security managers who have the management experience to have the balls to speak directly to your company executives. If your leadership is not willing to take security seriously then your company will never meet PCI compliance.
Has anyone got practical experience or a reference for a scheme that implements a key management scheme that would comply with the PCI DSS security standard?
There are obviously quite a few implementations around given the number of companies compliant with PCI DSS but trying to find details of them is tough. When it gets down to storing private data the discussion normally stops at which encryption algorithm to use. After that there's normally a statement about appropriately storing the private key but no discussion about practical ways to do it or things like periodically changing the key or providing the key to applications etc.
Specificlly I'm interested in thee requirements from sections 3.5 and 3.6 of the PCI DSS standard.
3.5.2 Store cryptographic keys securely in the fewest possible locations and forms.
3.6.a Verify the existence of key-management procedures for keys used for encryption of cardholder data. Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.
3.6.4 Verify that key-management procedures are implemented to require periodic key changes at least annually.
I've had a look at the NIST Cryptographic publications as the PCI DSS requirements document suggests but apart from recent notes of a Cryptographic Key Management Workshop there doesn't appear to be much there in the way of real implementable schemes or standards.
As to what I'm trying to do it's not:
Store passwords + salts as one way hashes for authentication,
Choose a strong symmteric algorithm for data encryption,
Avoid needing to store private data in the first place.
Avoid the need for key management with other mechanisms: physical security, database security, dragons and wizards etc.
All of which are valid concerns but in this case are not the answer. The nuts and bolts of my requirements are in a different SO question .Net Design pattern for storing and retrieving sensitive per user data but it all boils down to key management hence this more refined question.
I'm familiar with the pain you're going through. We struggled to update an old EFT system towards PCI compliance. Key management was certainly (from my software point of view) the most challenging part.
I think I also stumbled into the NIST Recommendations for Key Management that Martin posted, and got incredibly frustrated with the lack of concrete examples.
ANSI X9.17 - Financial Institution Key Management is probably the most relevant to your needs, with PCI-DSS. Good luck reading it though, the document is a massive collection of TLA's which I know I certainly struggled to read. (X9.17 is updated yearly, and latest version is now: NIST SP 800-57 Pt. 1 Rev. 4 )
When frustration turned to desperation I stumbled into The Electronic Money Mill which is a fictional tale, with a good number of relevant technical references. Chapter 17 discusses X9.17 and may help with the understanding.
From all this reference material I designed a key management system that our auditor was pleased with. The design documents are fairly lengthy, but in summary the idea is that you have your Data Encrypying Key protected by a Key Encrypting Key, and the Key Encrypting Key is stored on a physically separate box, itself protected by a Master Key.
My implementation was to have a Key Server application running on a windows box. This application required entry of two separate 'key server master keys' before it could be used. These keys would be known only to the key server administrators. These keys are xor'd together to generate the Master Key, which is stored only in protected memory whilst the application is running. Application can then automatically generate cryptographically strong Key Encrypting Keys, which are stored in encrypted form using the Master Key.
Applications that have a need for encryption will request a Key Encrypting Key from the Key Server. The KEK is used by the application to encrypt/decrypt the Data Encrypting Key, which can be stored securely with the application data.
Good luck. I hope you also find it an interesting challenge!
Have you seen NIST SP 800-57, Recommendation for Key Management?
I was asked implement a licensing schema for our product. They are very expensive products with few customers sparsely distributed around the world and basically every one of them has a design environment (a windows application installed on single windows machines, from 1 to 150 client machines per customer) and a web server that hosts production environment (1 to 8 machines per customer). Our product is licensed for server usage so customers can use any number of clients; we've decided not to license the server part (because it's subject to SLA agreements) but only the client, because, after some time without capability to use the client the system becomes basically useless.
Our basic assumption is that the customer is "honest enough" and only thing we would like to cover is stopping the client design environment if not properly licensed with a time expiration license.
I've evaluated different licensing product and they are or too expensive or too difficult to manage, so I've come up with this simple solution:
The license will be a simple signed XML file, signed using the standard XML Signature feature of w3c, using a private key that will be given to the admin department on a USB key; if they lose of copy it then the licensing schema will fail but it will be their fault
The client will open the license file on startup and check its validity using a public key embedded in the binaries
If license XML is valid and the data in it (expiration date and product name) are correct than the designer work; if not, an appropriate message will be shown
Any ideas about possible problems or how to improve the scenario?
I have yet to see a licensing scheme that wasn't broken in a few weeks provided there was sufficient interest. Your scheme looks very good (though be certain that if someone really wants to, they'll break it).
Whatever you do, you should follow Eric Sink's advice:
The goal should simply be to "keep
honest people honest". If we go
further than this, only two things
happen:
We fight a battle we cannot win. Those who want to cheat will succeed.
We hurt the honest users of our product by making it more difficult to
use.
Since you're implementing a license scheme for a program designed for corporate use, you can go even simpler and just keep some kind of id and expiration date along with a simple signature on the client and refuse to start if the license expired or signature failed. It's not that hard to break it, but no licensing scheme is and if you consider your customers honest, this will be more than enough.
It's not completely clear from your question how your scheme works. Does every instance of the client software have a different key? How long does the license last? Do you have a different key per customer? How is the license paid for? How is a license renewed?
If you are trying to control numbers of usages of the client code then only the first one above will do it.
At the end of the day, in the world you appear to inhabit, I suspect that you are going to have to live in trust that there are no blatant infringements of your license. Most decent sized organisations (which it sounds like your customers would be) have a responsibility not to infringe which can lead them to serious consequences if they break the license agreements. They will be audited on it periodically too and you probably have some statutory rights to go and check their usage (if not you should write it into your license agreement).
Where it becomes very dangerous for you is if the contents of the USB keys find their way onto the web. In that regard any scheme which uses a published key is vulnerable to a wilful disclosure of the secrets.
I'm certain there is a lot of literature on this subject, so it is probably worth you continuing your research.
BTW I'm not sure about your reference to SLAs in the middle part about your server licensing. Licensing and SLAs are very different. A license is the clients obligation an SLA is yours.
if you give them the private key, what is to prevent them from creating more signed XML files instead of buying additional licenses from you? or is it a site-license? if the latter, what is to prevent them from creating licenses for other people/sites?
in general, development licensing schemes tie the license to a particular machine using the MAC address and/or hard drive serial number, or sometimes just with an activation key (which is usually just a hash of the hardware info)
and typically the encoding is done with a private key that you keep secret, and the license is verified with a public key; the client never has the private key, otherwise they can - if so inclined - generate their own licenses
I agree with Steven A. Lowe (I don't have 15 reputation, so I couldn't vote him up).
This also seems too complicated. Do you want it to be unbreakable? you can't. Any sufficiently motivated guru would find a way around it.
Sometimes a simple licensing scheme works best:
I suggest a simple encrypted file that the admin puts somewhere the client can access - it would contain the client name and expiry date. You use the client name from the file in all printed reports (that's what most PHBs care About, that way they would not use the license that prints somebody else's name).