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
