Apologies for the delay in setting up the users list. I spoke with
Emily and others on the team last week about getting this done and due
to a few other pressing tasks, we decided to wait for a couple weeks
until we had some bandwidth. We've decided to set up a new list called
"Mifos Help" which will be for anyone who is setting up or using Mifos
in production. This will be the place to share information and ask
questions about installing and deploying Mifos, troubleshooting
deployment issues, discussing best practices around the implementation
process, etc.
Below is a chart we put together describing the different categories of
discussions, which list they used to take place on and where they should
take place once we have the new list set up. If you (or anyone else)
has any final feedback before I set up the new lists this week, let me
know.
Thanks,
Aliya
Use/Need
User Group
Current List
Future List
Discussing code design/development of new features or bug fixes
Software development teams
Developer
Developer
Patch review notifications
Software development teams
Developer
Developer
Discussing design of new features to be developed
Software development teams/IT specialists/MFIs
Functional
Functional
Asking questions about current functionality
IT Specialists/MFIs
Functional
Functional
Investigating potential bugs in the system from a functional perspective
IT Specialists/Software developers
Functional/Developer
Functional
Asking technical questions about how to deploy Mifos in production
(software stack, server set up, etc)
IT Specialists
Developer
Help
Asking questions about data migration
IT Specialists
Developer/Functional
Help
Asking questions about how to create reports
IT Specialists
Developer
Help
Asking questions about deployment process (UAT, training, etc)
IT Specialists
Functional/developer
Help
Raising production issues/bugs (e.g. performance issues, logging issues,
functional issues, etc)
IT Specialists
Developer
Help
Asking questions about how to integrate Mifos with other systems
IT Specialists
Developer
Help
From: Graeme Ruthven [mailto:[EMAIL PROTECTED]
Sent: Friday, September 19, 2008 9:11 PM
To: 'Mifos functional discussions'
Subject: Re: [Mifos-functional] Discussion: Recommended IT Policies for
MFIs
Ryan
I think that this type of discussion is well worthwhile but, as you say,
we're getting way off-topic for either the developer or functional
lists.
Perhaps it's time to revisit the earlier threads about setting up a
users list? As you also say, gathering together ideas that will help
MFIs formulate their policies is a great idea and I'm sure that there
are many of us with general IT and business experience who can
contribute.
This discussion is getting a bit messy, with lots of topics being
discussed, with a wide range of general policy stuff and Mifos
specifics. Not to mention confusion from different email formats.
Can anyone suggest a better way of tracking the items - a wiki page
perhaps?
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Ryan Whitney
Sent: Friday, 19 September 2008 01:00
To: Mifos functional discussions
Subject: Re: [Mifos-functional] Discussion: Recommended IT
Policies for MFIs
On 9/18/08 11:10 AM, "Graeme Ruthven" <[EMAIL PROTECTED]> wrote:
> * Passwords
> * MFIs should require their employees to create
> strong passwords
Yes, and this can be enforced by Mifos.
Are you saying we have this feature in Mifos or its something we
could add? I'm thinking the latter in hopes I'm not that ignorant about
Mifos ;)
I don't believe that this is a feature, but it could be added if
required. Google suggests that suitable libraries are available.
> * Nobody should be writing passwords down
> anywhere (like on a piece of paper next to the
computer ;))
Awww... No yellow stickies? :-(
I always figured the answer to this is not to punish anyone who
you find doing that. Just walk around the office once a month and black
them out with sharpie. That out to get people's attention ;)
> * Enforce employees to choose a new password
> every 3,6, or 12 month
Again, can be enforced by Mifos, best through a configurable
option.
Another possible feature request, right? (Scaring me here ;))
Yep, I believe that would have to be a feature request. I should
have said "could", not "can"! A lot of applications, together with
Windows and Linux, are able to enforce password strength and expiry,
although this isn't always turned on.
> Obviously, some of these can be resolved technically
> (infrastructure setup, feature requests to mifos,
possibly
> reports - ie, one reporting the last time people
logged in),
> but its still good to have these written down.
I believe that a MFI should have a good security policy
and signing it
should be a condition of employment.
Where controls can be implemented by the software, this
should be done.
I agree 100%, which is why I brought this up. I'm realizing that
what we're doing here is more than just building MFI software, we're
having to help people run it safely and securely ;)
Hence my comment at the start. I totally agree. Perhaps a wiki
page on security to capture the various thoughts.
We need to be prepared for a wide range of opinions and some
healthy debate.
All logon attempts - failed and successful - should be
logged. See auth.log
on a Linux system or the Security log on a Windows
system. Timestamps should
be accurate to the second (or better) in case they need
to be correlated
with other events. Which implies that system clocks in
the network should
all be synchronised with a suitable time standard.
Simple to implement, but
often overlooked...
I'm not sure, but I believe we track that. Can someone else
confirm this?
I don't believe so. Table "personnel" has a "LAST_LOGIN" field
for each user, but this only records the date (of the last logon), which
I don't see as fine enough granularity.
I recommend that IP address is logged as well.
I would prefer to see a log along the lines of a Linux auth.log
as above. Surely there must be a Java library that supports syslog-type
output?
Another one I think should be addressed is segregation
of duties. A person
entering a request for a loan or payment should not be
allowed to approve or
disburse it. An entirely separate person must make the
approval or payment.
This means that, unless passwords have been shared in
violation of policy or
privilege escalation has occurred, the most basic form
of fraud requires two
people acting together.
I agree and disagree, this is a kind of gray area (and going to
sort of contradict something I said earlier...). The previous points
above are general IT policy questions, but this is more of a procedural
issue (And I'm a tech guy, not a MF expert... Not yet at least).
Certainly its something worth discussing, especially with how Mifos is
involved with the process, but I'd hesitate before I decided on any
absolutes like that.
I think Mifos's goals should be to provide the flexibility for
MFI's to model their processes and procedures as closely as possible**
and provide a detailed audit trail.
And in practice, I'm not sure I agree with your example either.
Take for instance a manager who oversees 50 loan officers, each who are
creating around 10 new loans a day, meaning he or she has somewhere
around 500 new loan accounts to approve everyday (a real scenario,
actually). Is the manager going to dig through every single one and
validate each one, does he or she know if every customer is real or not?
In that case, I don't think the manager is going to dig into
that detail and will most likely approve most loans unless they see
something that stands out. As the manager, he or she is still
responsible, but that would be the case whether they were the ones
approving the loans or not. What you are providing in this scenario is
a second set of eyes on a loan application (so it'd be a lot harder to
commit a fraud of taking out 15000 as opposed to a normal 150) and the
audit trail.
No software can guarantee against fraud, it can only help you
fight it. At some level you have to trust people underneath you ;)
(hhhmm, that makes me think of another topical question...). Either
way, providing some assistance on how MFIs will need to change their
processes and procedures is needed, but like I said, its a grey area. ;)
Fair enough - and your numbers are a bit scary! My observation
over the years is that sooner or later someone with access to money or
items of value will convince themselves that they are entitled to help
themselves.
As you say, a lot of it comes down to policies, processes and
procedures, so Mifos needs to maintain a good audit trail to assist
investigation should it be required.
Input from those managing the day-to-day operations in an MFI
would be invaluable.
** realizing of course that almost no software deployment can be
done without some changes to processes and procedures, so the goal here
is to minimize that as much as we can and still be relevant to a large
cross section of MFIs
Regards
Graeme
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Mifos-functional mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-functional
