ADempiere ERP Business Suite

Hi community, I want to hear opinions here about the community wanted mechanism
____________________

FIRST QUESTION
To report SECURITY issues community prefers:

a) Public trackers
b) Private trackers (only visible to the original submitter as well as project members)
c) security@project.com e-mail private list - not everybody can subscribe to this list
d) other (please comment)

I don't want to repeat my opinions here, if you want to know what they are you can read them here:
http://sourceforge.net/forum/message.php?msg_id=4300425
http://sourceforge.net/forum/message.php?msg_id=4298077 (Final comments)
____________________

SECOND QUESTION:
If we decide to release security issues as private, how much time must we kept the security issue as private?
a) a prudent time after solved - allowing enough time for customers to patch their systems
b) an exact period of time (please comment how much do you think is enough)
c) other formula (please comment)
____________________

THIRD QUESTION:

If we decide to keep security issues as private, how to act in front of security leaks?

Please comment.
i.e.
what must we do if a tracker is released as public and community prefer it to be private?
what if security is released in a public webpage out of adempiere control (i.e. a blog) - by a member or non-member?
etc
____________________

Hey community, I really think this deserves to be discussed and we want to hear your opinions, if what you want to say it was already said, a simple "I agree with YYY opinion" is good - silence is not good ;-)

Regards,

Carlos Ruiz

Yes an important question, Carlos.

I can imagine talk of privacy make people think "What like microsoft's security policy?" Perhaps a better way to consider it is ... should we advertise security issues or not. I do not see advantage in that myself, but not advertising is not the same as not trying to keep it a secret.

So to Question 1 I would say:
Our *preference* should be to have people report via email to security@adempiere.org and once confirmed the security flaw information sent to a security mailing list. Not sure who security@adempiere.org should go to? All project members seems reasonable to me but ALL should be able to subscribe to the security mailing list.

Question2:
Well i think I'm not actually private ... an in between from advertising it and keeping it a secret. So Q2 doesn't apply... except that security mailing list subscribers are only notified when the flaw is confirmed.

Question3:
n/a. But if it's a website outside our control there is little we can do so no point worrying about it!


colin

Hi Colin, thank you very much for your quick answers, strong points (as normal).

I hope my comments can add some considerations:

> ALL should be able to subscribe to the security mailing list

Can we think also on some previous filtering? In other words, everyone is allowed, but we can confirm first the e-mail and interest on the subscription.

What I'm thinking on this issue is "how to avoid crackers subscribing to the security list?"

> Question2: Well i think I'm not actually private

OK, so, do you consider that after some time the security issue must be advertised publicly?

> Question3:
> n/a. But if it's a website outside our control there is little we can do so no point
> worrying about it!

Yes, we can (and must) do things:
About the person: We could do something if is a member of this community - i.e. a warm warning from community :-)
If it's not a member of the community - we can send him our security policy to explain the person community considerations.

And most important - about the security leak, we must act quickly in a responsible way for damage control, evaluate the risk, send a notice to installation on the risk detected and if there are ways to cover.


Regards,

Carlos Ruiz

Hi again Carlos,

>>confirm first the e-mail and interest on the subscription.
yes well the fact we would have an email address was a reason for me to suggest an mailing-list. Checking first who & why as a general practice seems like a sensible addition ok.

>>some time the security issue must be advertised publicly?
Well my first instinct was ... why *advertise* security problems ever?
but since you ask I've thought again and I can see how it would make sense, for example, to make a general statement to say; if you use 3.2 then apply this patch to close the following security flaws....

>> Yes, we can (and must) do things:
ah yes those suggestions all seem reasonable... I was considering a website that is some kind of hacker site... legally we have no rights to make them stop but your suggestions are indeed sensible.


colin

Hello,

Just my 2 cents:
This is a OS project meaning that everyone around the world has access to source if s/he wishes to -that is an obscure point ;-). I wonder aren't there people around the world with enough knowledge to find the holes and abuse them?
As ADempiere grows, two community around it grow too. One the enthusiasts and the other one is the dark society of crackers and security abusers! Then what good is hiding security flaws from our customers and community while the dark society knows all about them. In fact, currently that soceity is not improtant at all, however we're going to face it sooner or later.
Allowing customers and community know about security holes, solves nearly nothing practical but I feel that it's their right to know what's wrong with the application they are using and investing on -considering the fact that the dark society is not part of the community and is not one of our customers and they are security masters.

So, I'd suggest keeping security flaws reports open to anyone as it's going to benefit us and improve the trust in the long run.

Warm regards,
Bahman

Thank you very much Bahman for your comments.

Trying to enhance the discussion, here are some links of security management on top open source projects:

Very interesting thread (similar to this one) followed in Linux with Linus participation:
http://kerneltrap.org/node/4540

<-- snippets from some Linus Torvalds words -->

I'd very happy with a "private" list in the sense that people wouldn't
feel pressured to fix it that day, and I think it makes sense to have some
policy where we don't necessarily make them public immediately in order to
give people the time to discuss them.

But it should be very clear that no entity (neither the reporter nor any
particular vendor/developer) can require silence, or ask for anything more
than "let's find the right solution". A purely _technical_ delay, in other
words, with no politics or other issues involved.

...

I'm not saying that we'd _have_ to go public after five days. I'm saying
that after that, there would be nothing holding it back (but maybe the
technical discussion on how to _fix_ it is still on-going, and that might
make people just not announce it until they're ready).

...

Which to me implies that while what I personally _want_ is total openness,
that's not necessarily what makes the most sense in real life.

<-- end of snippets -->



Reporting security problems with Apache
http://httpd.apache.org/security_report.html

Postgres security information
http://www.postgresql.org/support/security.html

Mozilla
http://www.mozilla.org/security/

Regards,

Carlos Ruiz

I think the security question is most applicable for 'open' systems where it is accesible via the web. Such systems are not the norm among ERP users. Then there are more local users and the next level will be internal hacking.

What i've been proposing is that we take this in stride (as with any other app be they OS or so) and proactively look at it as a necessary add-on service that we must give our customers.

We can lay this out in part of our SLA as a security option describing the vulneraiblity of OS (which i remember, as Bahman tried to put it, as one of the reasons or FUD of not going OS as client codes been 'known' to the dark side). So it is perfectly logical to address this FUD as such - Yes, your source is open to hackers and we conuter that with a general plan, which includes on call warranty service, private prevention service of ensuring disaster recovery and forensic detection. AFAIK, many serious Linus-based system users hire Linux hackers to add some black bo into the systems as best final measure.

I remembered been a project manager before for a financial banking institution that has in place passive surveilance systems that monitored from the incoming cisco router right up to the firewall level but that wasn't enough. The client purchased an active human based one that looks at the flags of ICMP readouts and call up literally the client who then call me up in the middle of the night asking for decision on whether to block of an IP range from Eastern Europe. They were chronic mostly in my mind, but then they re paying for it.

To me security is a business. period. Irrespectve of OS. But especially so been OS, we have a charter to keep and that doesnt inlude delaying information. Even if the bazaar here decides it is ok to delay, i still suggest, "Why not let the final customer decide?" Moreover many users do not even advertise they are using this app. By us advertising security flaws shall make them wake up and call home *sniggers*.

What i mean to say is that this is an interesting subject and for someone to raise it up triggers alot of thoughts, but only if we keep to an optimistic line.

red1

Hello,

reading this thread, it came inmediately to my mind the "The Physicists" by the Swiss writer Friedrich Dürrematt, where he postulated among others these thesis:
- the worst twist is not forseeable, it arrives by chance
- what all concern, can only be solved by all
- every private attempt to solve the community's problems must fail
- reality shows up in paradox situations

And Abraham Lincoln's: "You can fool some people all of the time, you can fool all people some of the time, but you can't fool all people all of the time".

My conclusions, applying both thoughts to the present thread:
- everyone should be able to know all security issues. If someone has criminal energy he/she will find ways and means to hurt, and we all should work together to challenge that
- we can not hide information and should face problems as they come, but we should set up a mechanismn to handle and solve transparently security issues, facing reality as it is

Best regards,
Mario Calderon

I think that this kind of discussion can wait until we fix issues that 12 years old can find in couple hours.

We have to have some security before we can have security issues.

-kontro-

Greetings,

Publishing a security hole that can lead to stealing or corrupting financial data, without publishing the fix or how to monitor and protect against it, is irresponsible. There is a lot of latent dishonesty out there, people that have the inclination but not the initiative to cause harm. Handing them the tool and instructions to do it enables the latency to take action. Irresponsibility at this level will be met with accountability for the damages.

Thus a responsible process is necessary, such as described here: http://www.adempiere.com/wiki/index.php/Security_Policy

That covers the responsibility of the community, the developers, the providers, the users.

[+1] to implement the security committee and security@adempiere.org.

Regards,

Joel Stangeland

kontro,

While I agree with the lack of security in the compiere/adempiere core, I disagree with the way you approach this: you have not publish your proposal/idea on how to fix this and seek community feedback. This is not appropriate for a community project as communication with community is vital.

Regards,
Low

Hello,

Mario:
Thank you for the quotes; they really impressed me.
But one question; I don't understand what you mean exactly by
> but we should set up a mechanismn to handle and
> solve transparently security issues, facing
> reality as it is
You mean setting up a private security team or setting a public mechanism to discuss and solve the flaws?

Joel:
> Publishing a security hole that can lead to stealing
> or corrupting financial data, without publishing the
> fix or how to monitor and protect against it, is irresponsible.
Therefore you think that hiding a security flaw and not letting the customer know about it -until it is fixed- and letting him be the victim of some cracker while he doesn't know his system is being abused, is more responsible?
As someone else had mentioned on this thread -can't remember who-, the cracker will be always ahead of us and we cannot prevent the intrusion by hiding holes.
I believe it's the customers' right to know, we cannot decide instead of them.

Warm regards,
Bahman

Hi Bahman,

>hiding a security flaw
If we take this seriously, then the time that it is not published should be a couple of days. If it is something that cannot be fixed, or guarded against, and it will be an ongoing risk, then notice of that sort of thing can be given, and companies can decide what to do. Perhaps there may be some middle ground that allow publication of the risk without the details?

>not letting the customer know about it
There are two levels of involvement here that need to be understood:

1. Most companies using ADempiere have hired an implementor to provide services. Those implementors should take the initiative to be part of the security forum. Therefore nothing is hidden from those that need to know. A bug is reported, I find out about it, I remediate the issue or inform my customer's security team or IT Coordinator of the risk. The communication happens quietly and those that need to know do.

2. Those companies that implement for themselves can also join the security forum and be apprised of the risks.

There is no hiding as long as the process is clear and those who need to know can. The concern is much more about telling those that do not need to know.

>the cracker will be always ahead of us
Yes, exactly. Those cases are irrelevent, because there is no process that can stop that. Again my concern is the latent crook.

Follow this through. A US company using ADempiere stores 10,000 credit card numbers. Bahman publicly posts the instructions to exploit the data, and a bored kid on the shopfloor puts down his ipod long enough to read the instructions, crack out the credit card numbers, and goes on a shopping spree. Before long, he will be picked up, and when asked how he got the numbers, he will say Bahman told me. Where do you think the FBI will knock next?

As a trusted service provider, I have a responsibility to my clients. I cannot in good conscience condone that others post publicly the way in to their systems. I believe if you go to any company running ADempiere they will tell you exactly the same thing. Post the information to a security team, and notify those that have been approved to know.

Regards, Joel

I think the FBI will have a hard time entering Iran, let alone enter Bahman's house *sniggers*.

Still, i belong to the school of tot that transparency is the best security. The Pentagon released their info under FOIA. So did the Veterans Hospital on their Vista system. Think bout that. It cuts both ways. If more ppl know, more ppl can warn me first than that iPod kid - who could crack into our delayed telecast anyway, knowing that he is bored on the shopfloor and Joel put him there :D

About mail list for security, how about using a new SF maillist for added transparency? Moreover i have no admin staff to handle the .org under my present care.

Hello,

Thanks red1 for warning FBI about how dangerous I may be :-)

Joel, regarding your scenario about credit#, I don't understand what good is hiding information? How you think it benefits your customers? Let me explain better with my own story :-D
BEGIN
There's been a security flaw about credit# in ADempiere for a long time and crackers were using it for a long time too. Joel finds the flaw and reports it privately to the so-called security@adempiere.org. The security@adempiere.org decides that it takes about, for example, 7 days to fix it. After 7 days the hole is filled with barbed wire and is reported to public forums with the appropriate patch to fix it.
END
Now, tell me how did Joel helped his customer by privately reporting the flaw to security@adempiere.org? If he had reported it in a public forum, there would be some bored kid around -who had no knowledge or innovation to find out holes himself- who would use the report to penetrate the database. But, do you think that the dark society waited for Joel to find the flaw and report it?! So, what did Joel do? He prevented the bored kid -but could he stop the crackers?- at the cost of deciding instead of his customer.

Another point to add is part of the OS philosophy (I know you know it well, just a reminder): Softwares grow faster and stronger when many people can add ideas to and fix bugs in them. Just as we're doing about bugs in SF.net trackers. Security is no exception; if Bahman finds a flaw and security@adempiere.org decides that it takes X days to fix it, don't you think that if there'd be 30 persons working on it -instead of 10 members of security@adempiere.org if reported in a public manner- the fixing process might take X/2 days? Don't you think that the dark soceity's threat in X/2 days is much more critical than the bored kid's in X days?

Warm regards,
Bahman

wooaaa.. go easy on the x/n thing.. i am not that good in trigonometry remember? And i warned FBI about you cos i know that FBI do not operate outside USA. The CIA does. So i did not warn CIA about you. See how smart i am when it comes to protecting pals? I found out everything from X-Files, which i dont think u get there.

Joel which one is more irresponsible: The one who publish the hole or the one who sells systems knowing about security holes ?

My point is to force people face the facts. All core developers have known all the time that security holes exists - but they do not care.

I started discussion about security problems 5 months ago. Only effort to fix those have been wan profile which opens up even bigger problems.

We need change of attitude not any security teams. If security team contains these same people who have been ignoring whole issue all the time - how can it help ?

Sorry that I have to be hard on you folks, but I really think that we are fooling people all the time.

+1 For adding warning on all Adempiere web sites: "Do not use this software to store non-public information"

-kontro-

I think that publishing security holes is not good.
Though the source are open to any, very different is someone saying how to
exploit a hole before it is fixed.

So, my preferences:

Question 1: Option c), but if any can subscribe to the security mail list then add filter;
otherwise is the same as public way.

Question 2: Option a)
Maybe we must announce those patches as "Security Patch" to give them critical importance. I believe we musn't give details about the vulnerability, as they can give someone the capacity to exploit that. Only a summary title with the issue fixed could be sufficient.

Question 3:
I don't understand the question. If the issue was published, we only must work to fix it.

Regards,

Alejandro

Hi Timo,

>My point is to force people face the facts. All core developers have known all the time that security holes exists >but they do not care.
>
>I started discussion about security problems 5 months ago. Only effort to fix those have been wan profile which >opens up even bigger problems.
>
>We need change of attitude not any security teams. If security team contains these same people who have been ignoring whole issue all the time - how can it help ?
>
>Sorry that I have to be hard on you folks, but I really think that we are fooling people all the time.
>
>+1 For adding warning on all Adempiere web sites: "Do not use this software to store non-public information"

Timo, you started to use PUSH mechanism in order to get attention and results. I must say that no PUSH can make me to move my finger. The only reason is that noone pays me to PUSH me except my clients. If you find any security issue, please report it and announce it in dev or any other forum. I'm sure that you will get better results than just asking community to add warning that software is not good.

Yes, i know that passwords are not encrypted in DB and yes i fixed this for one project, but i still can't find the time to implement it for Adempiere. Am i guilty for this? Am i irresponsible or careless? Probably.. Who knows. Who can prove it. Is this the aim of Adempiere project? To prove who is careless and who is not. I do not think so. I'm here as part of Adempiere project and i see Adempiere as one big team. I'm part of it and you are part of it. If you have some ideas or proposals, please describe them or better make an example and commit it into SVN Server, i'm sure that developer and users will give you their comments.

Why do you try/want to frighten users?

Also, please remember that we inhertied many good and bad things from Compiere, so we still have work to do.

Kind regards,
Trifon

Hello!

I wish I could imagine a "permeable" way in wich all information can be put in and only filtered information can be retrieved, but I always end up in discrepancies.

In cases like this, we must apply (Red one: Maths again!) the "least common denominator", which seems unluckily to be totally openness in good and bad.

So, though I personally prefer private listings, I vote against them, because I believe it will not work in the end.

Thus (Bahman) I mean:
- no private listings
- implementation of a security commission who is in charge of the official stance to security issues (in a discreet handling as Alejandro suggests)
- dedicated security forum so everyone may inform and be informed

Ammending a quote from Churchill: "Openness is the worst form of communication -except for all those other forms that have been tried from time to time".

Regards,
Mario Calderon

> Joel which one is more irresponsible: The one who publish the hole or the
> one who sells systems knowing about security holes ?

> My point is to force people face the facts. All core developers have known
> all the time that security holes exists - but they do not care.

To force??? Agree with Trifon, you can't force us.
I'm also not moving a finger because you want to put Adempiere against a wall.
I can move my whole body because I like to do it, not because you force.
Bazaar can't be controlled, maybe steered - as you're trying to do in a way I don't share because I feel it irresponsible.

And you said that you're not using personal attacks?
Declaring ALL ADEMPIERE CORE DEVELOPERS AND VENDORS AS IRRESPONSIBLE is not a personal attack?

Excuse me, but I feel it personal. Because I'm a core developer and I'm not irresponsible.
I worry about security same as you, and even more than you - or at least I try to do it in a more constructive way.

But I also know that exposing a database password is not a big issue if you can control the way how users access the database.
I know from previous experiences that Oracle Forms expose database password in HTML code, but in a well secured system it doesn't matter because you can't access the database in other ways than configured by the DBA.

Yes, I know you're going to say again that you wanted to start another flame just to gain attention on your issue. But that's the problem, is not your issue, is not Kontro's problem, is a project problem, and must be solved with the help of all community, not just your way to solve problems - this is the intention of this thread, to hear opinions, to gain consensus, to analyze benefit/costs of opening all security problems, etc.

But maybe this discussion is not worthy according to your opinion. Instead this discussion we must put terrorist statements in all adempiere pages.

> I started discussion about security problems 5 months ago. Only effort to
> fix those have been wan profile which opens up even bigger problems.

So, you like to discuss, you like to exploit terrorist statements, but you don't like to contribute solutions, good way!!
I haven't seen one of your issues found on wan profile - sure I know it can have bigger problems, but I haven't read any contribution from you on this matter.

> We need change of attitude not any security teams. If security team
> contains these same people who have been ignoring whole issue all
> the time - how can it help ?

I invited you to lead the security team but never received any answer.
Maybe with you on charge the things will be big different, not "THESE SAME PEOPLE" ignoring your terrorism trials.

> Sorry that I have to be hard on you folks, but I really think that
> we are fooling people all the time.

At least I'm not fooling people.
I keep saying my customers the security issues, I keep trying to show my customers how to avoid those security problems, and my customers decides with the best information.

> +1 For adding warning on all Adempiere web sites: "Do not use this
> software to store non-public information"

Just another terrorist contribution.

Regards,

Carlos Ruiz
(upset and angry again)

Hi All,

I would prefer to first capture security issue in a private tracker or mailing list. Just publish immediate any security issue received from anyone is bad because:
* It could be a false alarm
* Increase the chances of your customer begin attack
It is important to understand what the end users really want to know: not security issues with detail on how to exploit them but security issues with proper recommendation ( whether a workaround or patch exists, if not, what is the potential risk and precaution that the end user can take ).

As for how long we should keep it private, it should be just a few days before we should publish the security issue with proper advise. Bottom line is we need commitment from the community to help review any security issue raise, work on the problem and publish a proper security alert.

Regards,
Low

I think this call for an open discussion in Berlin (as i see Mario's name there) and hopefully we can agree to make it a more managed and yet transparent process. Surely one who reads Churchill knows more about putting out the fires. :P

Hi bahman,


> crackers were using it for a long time too

Good point bahman, I hadn't been thinking of that scenario. But again, to apply the security forum approach... As soon as that exploit was published in the security forum, I would know about it because I would watch it, and I could IMMEDIATELY go to the IT manager or executive sponsor of the companies I support and warn of the weakness and check to see if they were under attack. Same case if a company self-implements, the internal resource will belong to the security forum. Response time is just as fast as if the exploit were public. The stakeholders get the info they need just as promptly. Plus we don't feed the bad and lazy guys.

>at the cost of deciding instead of his customer

Non-existent in the scenario described above. The customer knew and decided.

>don't you think that if there'd be 30 persons working on it -instead of 10 members

No, I don't. Presumably, all those that cared enough/ knew enough to work on it would also belong to the security forum. So declaring it publicly helps the good guys=0, the dark forces=X*X.

I'm trying, but I just can't grasp any advantage. Also, for the purists... Openness can apply to the process just as much. As long as everyone knows how to participate and get the info they need, then everything is open. We don't give everyone commit access to the repository, that's being responsible and does not contradict openness. Neither does a good security policy.

FWIW, Joel

Hi Joel,

First let me thank you for sharing your ideas with me (and indeed with us) :-)

> No, I don't. Presumably, all those that cared enough/
> knew enough to work on it would also belong to the security
> forum. So declaring it publicly helps the good guys=0,
> the dark forces=X*X.
>
> I'm trying, but I just can't grasp any advantage...
I thought about the paragraph carefully. This is just my humble opinion about it:
To _me_, it looks like we're going to think the way Compiere did in case we take that approach, classifying the community to categories who are worth informing and caring and others who will learn and be informed _by time_. I think this is ignoring what a FOSS community is: Transparency. I believe, as IT history shows it is undeniable, the more people know about something the sooner it gets fixed.

If you find the open approach not advantageous, there is not any advantage in the semi-private approach too. It just makes customers and implementors feel more -imaginary- secure because the flaws are not on the open forums -no matter how the dark society was and is abusing those holes.

> As long as everyone knows how to ... get the info
> they need then everything is open.
If reports are to the so-called security@adempiere.org and are not announced until they are fixed (who knows how long does it takes), how _everyone_ can get the info they _want_?

One more thing to add: openness is our primary assumption. (http://www.adempiere.com/wiki/index.php/Project_Charter#Concept)
While there is no _strong_ evidence that it hurts customers in some way, it should not be ignored (and maybe even with the existence of such an evidence.)

Warm regards,
Bahman