So what to make of the OneLogin Security Incident?
So what to do when even the “experts” get hacked and potentially have lost confidence and your data.
Unfortunately in this case it is usernames and passwords (potentially), as it is not obvious what was removed or accessed, as a lot of data is encrypted at OneLogin.
The function of onelogin is of course to have a secure method of logging into your environment with one password/ authentication method.
so what is a user and an IT department to do with password management?
Don’t do what Sony did, and store your passwords in an excel file.
compliance standards require password management to be with a minimum set of parameters:
- at least a certain size (~10 or more) letters with a certain complexity (numbers and letters/specials)
- set lockout duration (i.e.) with an incorrect entry lock the access for 30 min.
- inactivity idleness lockouts
- unique ids and passwords (do not reuse)
- Do not reuse passwords across multiple entities
So why did you set up a oneLogin system? To make it easier to access a variety of platforms and networks. We did not expect for oneLogin to have a security problem which causes the very act of logging in securely to fail, as now the potential is there that the hackers have your userid and password, and since you have made it easier to access your network the whole network is accessible to hackers.
This is usually an acceptable risk for the most part, but if you had a computer system and database that is especially problematic if hacked I would set up a seperate authentication from the OneLogin setup, even though this makes things more difficult.
As I have discussed before Perfect security is not possible. Especially if you also want functionality.
The real question is what kind of Russian Roulette did you want to play for your business?
The game is this… (it depends on your situation of course) every day you are shooting a X barrel gun and if it actually has a bullet then a security event occurred. So the idea is to have a very large gun, with lots of barrels (like 500) so then at least the chance is low for a security event.
The funny thing with probability comes into being.
In a true 1 in 500 event, you may never actually hit it. The odds are that you will hit it once every 2 years or so. But we have another problem, how do we accurately represent our risk of the organization? How big is your “risk gun”?
I made these 1000 gun barrels units as well as a 500 gun barrel to try and represent what a physical Security risk gun would look like.
So Since Risk = Impact * Likelihood
The higher the impact is therefore your risk is higher.
If the impact is high risk is higher than where the impact is low. Now we get into the subjective gauge of likelihood. Here is where this setting can be fluid and can create many problems as circumstances change. As new malware is introduced and machines are not patched or other situations.
So RISK becomes a moving target that has to be assessed by an independent person so as to approximate it as best as possible under the circumstances. Here is where you figure out is it a risk of 1 in 1000(low) or 1 in 500(not low – but higher)
or 1 in 300 (medium) or a 1 in 150 (high) for each day.
So when you have a Single sign on application it better be checked for security otherwise the risk is greater since the impact is great.