Cloud MIS Security

[vikpaw]

That's basically the scenario we're looking at, where there are systems held external to the MIS, and the MIS is in the cloud.

I like the Google Authenticator method, because, the initial setup key can be complex and provided via a QR code, and then the username and password doesn't have to be horrendously difficult, "just complex enough" ( ) that they can remember it without writing it down.

Edited February 20, 2013 by vikpaw

[GREED]

I gotta say I am up there with @PhilNeal I am out of my depth currently but have learnt a lot just from reading all of these replies. Our dev team is working on a project with DFA right now for a customer, and this customer couldn't be more concerned about security... lets leave that one there. So will be interesting to see how that pans out later this year.

 

We are also working with DFA that is not part of the MIS, as I have said, and sits at a separate layer of security...

[Steven_Cleaver]

That's basically the scenario we're looking at, where there are systems held external to the MIS, and the MIS is in the cloud.

I like the Google Authenticator method, because, the initial setup key can be complex and provided via a QR code, and then the username and password doesn't have to be horrendously difficult, "just complex enough" () that they can remember it without writing it down.

 

Same want to make the DFA as simple for the user as possible one so it isn't a barrier for them using it and accessing the system and two so as you say it isn't something difficult that they have to write down. Still not fully convinced about only fully Cloud based MIS solutions for various reasons but best not raised here on this thread as this has been discussed many times and their are pro's and Con's for both.

 

Another reason we have done Dual Factor Authentication the way we have is we also have our Finance systems hosted internally which is not part of our MIS system and use the same method to secure DFA for this so in essence use the same method to DFA to multiple systems externally @PhilNeal and @GREED really glad MIS providers are looking at implementing DFA into their systems.

[vikpaw]

@GREED with Aspen's integration with Google , implementing with the Google Authenticator might make sense. Should be easy enough to add the table and offer it to those who want it.

I'd log a CR for SIMS I enough people are willing to support it.

[Steven_Cleaver]

Had a vague understanding of how Google Authenticator works, but have had a bit more of a look and looks very interesting, cheers Vikpaw.

[PhilNeal]

I can confirm that we have found a way of forcing a disconnection to Google Authenicator but I'm told that its far being well documented.

[vikpaw]

That's strange as I tht it was just a mechanism to authenticate you then pass you on to another service / process. I don't see how the authenticator is holding on to the user. However, google websites themselves do like to hang on to you and all your data, history, actions etc. so there could well be some odd functionality!

[PhilNeal]

That was our architect's view too!

[vikpaw]

So SIMS will be ported to Android shortly then ...

[PhillipHamlyn]

That's strange as I tht it was just a mechanism to authenticate you then pass you on to another service / process. I don't see how the authenticator is holding on to the user. However, google websites themselves do like to hang on to you and all your data, history, actions etc. so there could well be some odd functionality!

 

I suspect its doing Federated Authentication - essentially it issues your browser with a Cookie of a specific, given name, and services which comply with their FA will look at for that specific cookie on each call to their web services/web page. The consuming service or application then "accepts" the cookie as being a guarantor of the users identity. A problem if you turn off cookies of course. This is how most browser based SSO systems work, although Microsoft Windows based applications will tend to use the Windows Authentication system which isn't "federated" but "centralised".

[StacyLarkin]

All the possibilities I've seen mentioned apply to “Local Network” installed MIS Systems as well. If anyone within the school wants to hack the systems, they can...

 

There are many ways to make sure that cloud systems are secure, and systems are protected from attacks. Any certified (ISO/etc…) Data Centres have such securities in place anyway.

 

Cloud computing security - Wikipedia, the free encyclopedia

 

Also further security should come via MIS systems with user accounts. Like “Windows Accounts” do:

 

• Implement a strong password policy
  
• Force users to change their passwords in a given frequency (weekly/monthly/etc…)
  
• Lock accounts temporarily after a number of unsuccessful login attempts
  
• 2-level authentication
  

[Schoolcomms]

Cloud/SaaS Security is a big subject and this can’t be answered fully in a single post, but with respect to:

 

How does this work, if the MIS is in the cloud, and all staff are using dual factor? How does the third party or automated system authenticate in a way that's dual factor?

 

Two factor authentication applies more for human authentication – it is there to reduce the risk of people disclosing their password either by writing it down, just telling someone, or the original communication of the password being intercepted.

 

Typically when two systems communicate (over the internet) they will not use two factor authentication for each individual communication. Two factor authentication will be used once to set up the relationship between the two services and this authentication persists indefinitely. For example:

 

System A contains some data, System B wants to access System A to get that data.

 

• The owners of System B will ask System A for a Key/Certificate/Password – these are typically very long in comparison to human passwords to prevent brute force attacks and because there is no human data entry constraint.
  
• The owners of System A will generate the key and use a some form of two factor authentication to pass that key to the owners of System B (typically encrypt the keyfile, and call the owners of System B with the encryption password)
  
• The owners of System A will then use the key to authenticate when using the web services that System B provide to access the data.
  

 

 

This model assumes that the owners of System A trust that the owners of System B are capable of storing the key securely. Generally this is a moot point – if they don’t trust they can hold the key securely they probably don’t trust them to hold the actual data securely and therefore won’t want to give them access in the first place.

 

On top of this key exchange, there may then also be additional credentials required to access specific areas of data within System A. So for example if System A is a cloud MIS which holds data for multiple schools, the cloud MIS provider (or the school) may provide credentials to System B in order for System B to access that particular school’s data. This could be the school SIMS admin creating a username and password which is then provided to System B. The web services that System A provides to System B simply won’t require the second factor in the credentials to grant access (but they are requiring the key instead which has been securely delivered using two factor authentication).